timestamp notation @gnupg.org

[Jerome Baum]

>> The point is, if there's no timezone noted down in the
>> interval, there is no way to know what the timezone was
>> when the person made the signature. We're talking about
>> data at rest, that could be interpreted many years
>> later, and it'll be difficult to "guess" the timezone
>> then. Plus, it shouldn't be a guess anyway.
>
> We know the timestamp, rounded back to the start of the interval; that
> is recorded in the timestamp field. We know the length of the interval
> (/P1D, /P1M, or whatever), that will be recorded in the interval
> field. Those two pieces of information uniquely define the interval
> without the need for guesswork and without the need to know the
> signer's local timezone.

Wait. Are you assuming my interval will always be YYYY-MM-DD/P1D etc.?
How about YYYY-MM-DDT12:00/P1D?

>> Right. Local display vs. recording. I'll just summarize
>> again:
>
>> 1. Interval is recorded as an ISO 8601 interval, and
>> must be unambiguous (i.e. contain a proper timezone for
>> each timestamp).
>
> As already mentioned, I do not see the need for a timezone. I'm not
> against including one if there a need can be demonstrated.

See above.

>> 2. OpenPGP's timestamp is not changed (seconds since
>> epoch UTC).
>
> Unless the timestamp is rounded back to the start of the interval, it
> still reveals (potentially sensitive) information about the signer's
> time management.

By "not changed" I mean "the interpretation is not changed, the byte
format is not changed, etc." -- if the signer wants to round down,
they may. This is the loss of accuracy described in the
timestamp-interval field. That does not change the precision of the
timestamp field, nor does it change the fact that it is seconds since
epoch ("UTC", but that is per definition of epoch).

>> In terms of moving forward, I think the ISO 8601
>> ambiguity of lower precision in an interval is
>> something we need to resolve. Since we're introducing
>> the interval to allow for lower precision (e.g. round
>> to the start of the day), I think the interval itself
>> should have full precision. We would interpret any
>> dropped components as zeros/ones resp. ("01" for
>> months/days, "00" for hours, minutes, seconds,
>> fractional seconds).
>
> I think that is implicit.

You've been arguing that ISO 8601 does not state this implicitly. Or
did I misunderstand what you meant with "2010-01-01 can be any time
during that day"?

> However, what intervals may be allowable? If
> the interval is one hour/day/month/year then we round to the start of
> the current one. If the interval is one week, which day does the week
> start? Do we allow a period of two hours/months etc. and if so, where do
> we round back to? What about ten years?

Why restrict the intervals that are allowable? Why demand that the
implementations should round down? I can use the intervals to describe
accuracy, not just to hide my time management.

As for P1W, remember that there will be an associated date:
"2011-06-16/P1W" is one week, from Thursday to Wednesday.

>> 2. Suggestion: timestamp-interval at gnupg.org.
>
> Somewhere along the line I interpreted the suggestion as adding a
> timestamp-interval field to the signature packet, and rounding the
> timestamp field down to the start of that interval.

No, just a notation. Also, rounding down is something the
implementations can do, if they choose to (e.g. through a user
option). This does not change the encoding.

>> Value is
>> an ISO 8601 time interval during which the timestamp
>> was made, leaving no room for interpretation of the
>> interval, but making it the signer's duty to compute
>> this interval.
>
> You mean actually computing <start of interval>/P<length of interval>
> (or alternatively <start of interval>/<end of interval>) and placing
> it in a signature notation for each signature or batch of signatures?
> Automation would be needed for many people to take this up. Or at the
> very least, using long intervals so that the notation needs editing
> infrequently. (-;

That note about it being the signer's duty doesn't really need to be
said. The interval computation must obviously be the signer's duty, as
the interval will contain a date. Whether the implementation computes
this, the user sets it in the notation explicitly, the user sets a
huge interval in the configuration, or something else happens, isn't
something we're interested in -- that's the implementation and
interface level.

However, of course we need to consider this in context. I would say an
interval -- as opposed to a duration -- is ideal, as it leaves no room
for interpretation. Think "2011-06-20/P1W" vs. timestamp =
"2011-06-20T12:00:00Z" and duration = "P1W" -- one is ambiguous as to
when the week starts, the other is not (besides the issue of the first
example not having a timezone -- is "2011-06-20Z" valid?).

>> 2 a. Non-critical.
>
> Is the effect of this that the interval is simply ignored by an app
> that doesn't understand it? Would it look like the signature was
> created at the start of the interval or the actual clock time it was
> signed?

It would look like whatever is in the packet's timestamp field. This
could be rounded down, left at the original value, etc. The point with
a non-critical notation is that we've had some good arguments against
a critical one. For instance, it'll just break all your signatures for
current implementations.

Another option: "Usually non-critical, but up to the implementation."
This way the user/implementation can choose whether or not the
interval/inaccuracy is important enough to go in as critical, or if
it's just a "helpful note".

>> 2 b. Must have a timezone associated for each
>> timestamp. "Z", "+0100", etc. As a safe-guard for
>> broken implementations, should we assume an implied "Z"
>> if there is no timezone?
>
> Rather than an assumed "Z" we should have a marker that indicates we
> do not know the time zone. This is one of those cases where the
> technology can't guess for the user. I think the ISO 8601 solution to
> ambiguous or unknown timezone is to use "-0000." I didn't understand
> how that was different from "+0000" or "Z" when I read it.

Wait, ISO 8601 says that if there's no timezone at all, then it's just
"local time" (i.e. unknown to us). I would have thought "-0000" is
exactly the same as "Z" and "+0000". Are you saying the standard has a
different meaning for "-0000"?

However, good point. Let's say "Must have a timezone...", but leave it
up to the interpretation to inform the user when there is no timezone,
or even reject it entirely. The protocol just has to say what's a
valid value ("Must have a timezone...") and the implementation can
handle "what happens if I get a 'mostly valid' packet?" situations.

>> 2 c. Local display/interaction is something the
>> implementations will sort out. We recommend at least
>> the obvious "canonical" options of local timezone and
>> UTC display.
>
> I would suggest three options: UTC, the local timezone of the user
> viewing the signature, and the timezone stated in the interval field.

Okay, let's suggest those three. It's advisory anyway, which is all we
can demand.

>> Practically, after parsing the interval
>> into two timestamps, handling would be similar to the
>> OpenPGP timestamp field (except that isn't enriched
>> with the timezone, which you could use to enhance the
>> output). Often enough, this boils down to "whatever the
>> locale is configured to do" and that sounds in line
>> with *NIX philosophy.
>
> Fair enough. But if it is simply a signature notation, how/why does it
> get parsed at all rather than simply displayed? Are you suggesting the
> value recorded in the OpenPGP timestamp field in the signature packet
> is rounded back to the start of the interval before recording, or left
> intact?

Left intact. I would say we parse it because
"20110620154236Z/P1D2H1M7S" is not too easy on the eyes. :) It's also
the reason why implementations tend to parse the timestamp field and
display it as a date, rather than displaying "1308542795".

However, it is again up to the implementations. All we specify is what
format to use and how to interpret it, input and output interfaces are
implementation-specific and we can only advise as to what we think is
best for the user/what is most "canonical".

-- 
Jerome Baum
tel +49-1578-8434336
email jerome at jeromebaum.com
web www.jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA