timestamp notation @gnupg.org

[MFPA]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


On Sunday 19 June 2011 at 7:26:53 PM, in
<mid:BANLkTinDtjif-5XaABv5sVOYEPCKttuxEA at mail.gmail.com>, Jerome Baum
wrote:

> Local display is something entirely different:

> 1. Protocol on the one hand (needs to be unambiguous);
> and

> 2. Local interaction on the other hand (can be local
> timezone, UTC, another timezone, who cares?).

Fair enough.



> 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.




> 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.



> 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.



> 3. Local display, of both the timestamp and interval,
> is out of the question for now.

You mean because we are only discussing how the interval is to be
recorded? Fair enough.



> 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. 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?



> So here's the new suggested spec:

> 1. timestamp-only at gnupg.org. Let's omit this part for
> the sake of a friendly discussion.

Agreed.



> 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.



> 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. (-;


> 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?


> 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.



> 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.



> 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?

- --
Best regards

MFPA                    mailto:expires2011 at ymail.com

Two rights do not make a wrong. They make an airplane.
-----BEGIN PGP SIGNATURE-----

iQE7BAEBCgClBQJN/piwnhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf
a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC
OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB
MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pIoQD/2To
OgxjCmW0Jat+acQKmHmzIs8eqxt0+GADveXWubVo28AwghnpBL4osyHJf4M5nVl4
lSDGgqPuf4s9ednELSivcj3H41Ei+2lQnupI6n3MZ3Te19d+36HMQRCojahxdgpq
Lr7dm/M4JP7I111btlDnK3qeDfbiL7YuKd+zGaC0
=ZCml
-----END PGP SIGNATURE-----