Subject: Re: Timestamp and 3rd party sig

From: [email-masked] (Daniel A. Nagy)
Date: Sun, 16 Jul 2006 20:38:41 +0200

In his message on Feb 17, 2005
http://www.imc.org/ietf-openpgp/mail-archive/msg09179.html
Rick van Rein raised two important questions only one of which has been
addressed (by W. Koch). Rick proposed changes to the definiton of timestamp
signatures (sig type 0x40) which have been neither rejected nor accepted. In
fact, they have not even been discussed.

I would suggest to revisit his suggestion as it clarifies the correct use of
this potentially very useful signature type. I do agree with explicitly
stating the purpose of the signature as in all other cases:

    0x40: Timestamp signature.
        The intention of this signature is to accurately record the time
        at which the timestamped data was seen by the timestamp-signing
        party.

While I see the wording of the additional paragraph a bit clumsy and perhaps
overly specific, some explanation about the calculation of the signature
would be helpful. Before proceeding with that, however, I would like to ask
if there are any implementations that constrain how such signatures should
be constructed and verified?

Another question that arises in the context of timestamps whether it is
worth defining another type (say, 0x41) for timestamping canonical text
documents analogously to the distinction between 0x00 and 0x01? My personal
opinion is that it is definitely worth doing. Thus, I would propose the
following wording:

    0x40: Timestamp signature of a binary document.
        The intention of this signature is to accurately record the time
        at which the timestamped binary data was seen by the timestamp-signing
        party.

    0x41: Timestamp signature of a canonical text document.
        The intention of this signature is to accurately record the time
        at which the timestampe text was seen by the timestamp-signing
        party. The signature is calculated over the text data with its
        line endings converted to <CR><LF>.

Since I am currently implementing an OpenPGP compliant timestamping service,
I would like to solicit opinions on the issue even without suggesting
immediate changes to the standard. In particular, I would like to know how
various implementations treat 0x40 signatures when encountering them during
signature verification?

Thank you in advance,

-- 
Daniel A. Nagy

---

From: "Greg Sabino Mullane" <[email-masked]>
Date: Sun, 16 Jul 2006 23:57:27 -0000

> Well, may I ask that all of those on this list that are actually
> actively reviewing drafts please speak up now and let me know.  Feel
> free to let me know off-list if you prefer.  Then I can show Sam that
> we've got a lot of active reviewers.

Count me as one.

> I should also note that while it's okay to assume "silence implies
> consent", it would be nice for our reviewers to periodically say "I've
> read this and I have found no issues."

I'm mostly in that camp, with a little bit of "while I *could* comment on
that, it's such a minor thing, no sense in stretching out this process any
longer." Perhaps I'll say "I've read this and have no comments at this
point in time." :)

- --
Greg Sabino Mullane [email-masked]
PGP Key: 0x14964AC8 200607161952
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

---

From: David Shaw <[email-masked]>
Date: Mon, 17 Jul 2006 16:33:02 -0400

> fact, they have not even been discussed.

I think it is too late to suggest changes to 2440bis at this point.
The document has gone past last call and is now in the hands of the
editor.

With regards to the 0x40 timestamp signature, Hal noted that PGP would
likely not verify it.  I can vouch that GnuPG will not verify it
either ("unknown signature class").

>         line endings converted to <CR><LF>.

0x40 has a long history.  It was actually mentioned in RFC-1991, but
marked as not yet implemented.  The thing that was the 1991 0x40
evolved into the 2440bis 0x50.  To my knowledge, 0x40 has never been
implemented.  In terms of the format, 2440bis more or less indicates
that (like 0x50), 0x40 is a signature over a signature, not over data,
binary or otherwise.

I think if you're looking for a timestamp signature, 0x40 isn't the
way to do it.  A notation subpacket would seem to be a much more
usable method.

David