timestamp notation @gnupg.org

[MFPA]

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

Hi


On Monday 20 June 2011 at 5:07:25 AM, in
<mid:BANLkTi=HqRu-hejavVKwDU1PXFuSGSVGvQ at mail.gmail.com>, Jerome Baum
wrote:


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

Yes. We already said round the timestamp back to the start of the
current interval. That would be the beginning of the current hour, or
day, month, year, etc.


> How about YYYY-MM-DDT12:00/P1D?

Or (as previously mentioned) YYYY-MM-DDT23:00/P1D. Somebody with their
system set to a different time zone would see those.




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

Cool. That is what I thought you said before, but the "not changed"
confused me.



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

No, I mean that if the interval is (for example) one day, then it is
implicit that it means exactly one day plus zero years, zero months,
zero hours, etc.



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

I don't know. There may be a technical reason we've not thought of. Or
it may be desirable for clarity and simplicity. I just thought it
appropriate to raise the question.



> Why
> demand that the implementations should round down?

Without rounding it says "I signed this at 11:37 but it could have
been any time that day" and with rounding, it simply says "I signed it
some time that day."

Do you not think "11:37 but it could have been any time that day" will
just be perceived as "11:37 that day?"


> I
> can use the intervals to describe accuracy, not just to
> hide my time management.

What is the difference? Are they not different motivations to the same
end? (Both seek to broaden the interval for a signature time to
something longer than the current single second.)



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

Yes, of course. A week can start any day an individual or organisation
wants it to. To always pick the associated date as the start of the
one-week interval seems wrong to me. It may be appropriate to allow
the user to set what day their week starts (or even to allow a random
week that starts on the associated date or any of the six previous
days).




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

Does the OpenPGP standard allow tying together a signature notation
with altering the content of the signature packet (in this case by
possibly rounding off the timestamp)? I don't know.



> 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

I agree that the start of the interval needs to be precisely defined,
and so does either the length or the end of that interval.



> (besides the issue of the first example not having a
> timezone -- is "2011-06-20Z" valid?).

"Z" is valid for UTC. Otherwise it's the offset +hhmm or -hhmm.



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

Does that option exist with notations, or is it something you would
like added?



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

Some descriptions on the internet say so but I could not devine a
useful meaning. I have not purchased the original document.



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

The implementation has the timestamp field in the signature packet to
refer to, even if rounded, if it doesn't know what to do with the
notation.



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

That would preclude this scheme from being used to mask time
management.



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

Fair enough. And an implementation that doesn't know what to do with
this notation will display or ignore it.



- --
Best regards

MFPA                    mailto:expires2011 at ymail.com

Gypsy Dwarf Escapes Prison: Small Medium at large
-----BEGIN PGP SIGNATURE-----

iQE7BAEBCgClBQJN/7lwnhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf
a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC
OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB
MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pQHsEAJCb
Dv0h/tHLxvpMbjVCcL/JTMW0ltwTxbqzrx4eNUL0CyDIAKUDQBEmLIGQpbG/oolf
Cntm52S9h0g/cf8YaE27MAJ7x5YUDCr0u9oRQ49Czbne2OO8D+KnQpOCZMZEx3D/
jSTMyKiSl3aJXgq/NJsivqj5BFGt9QKxZml/2wFH
=XbXQ
-----END PGP SIGNATURE-----