Problem with faked-system-time option

[David Shaw]

On Jun 15, 2011, at 11:23 PM, Jerome Baum wrote:

>>>> The 0x50 signature should not be interpreted as the output of a real-world notary
>>> 
>>> Who says that?
>> 
>> RFC-4880 says that.  And speaking as the person who suggested it, I can tell you my intent ;)
> 
> Fom <http://tools.ietf.org/html/rfc4880>:
> 
> Referring to 0x50: "It is analogous to a notary seal on the signed data."
> 
>> The draft spec actually called it a "notary signature", but after discussion, the name was intentionally changed to "Third-Party Confirmation signature" explicitly to avoid any confusion with a real-world notary or what they do.  The word notary is just an analogy.
> 
> Yeah and that was my point. The analogy is bad because a notary
> doesn't just timestamp. That's not even the main purpose of a notary
> (at least here in DE). Having the 0x50 signature on another signature
> packet is definitely not helpful -- what part of the signature are you
> asserting? The timestamp? There's a timestamp in the 0x50. The
> validity signing key? No (per you). The mental state that the signer
> was in? No (per you). The data and time? Yes, if we use this for
> timestamping. But then, why am I not signing the data and asserting
> the timestamp in my 0x50 signature packet?

Forget the word notary.  Just erase it from your head.  If you don't like the analogy, then don't use it.  It's just a third-party confirmation signature.  It means only that a third party wants to make a signature on a signature.  It's just like 0x00, except where the data is a signature packet.

The reason you might want a signature on a signature is because the 0x50 gives you something really useful in the context of time stamping: it means the stamper entity/process/person doesn't need to see the original data.  I can sign the data myself, then send the signature alone to the stamper.  The stamper then signs my signature, using the notation we've already discussed to indicate they are making a timestamp alone.

As you phrase the question, the stamper needs to see the original data ("why am I not signing the data").  That's not always desirable.

As I noted before, you can more or less create this by sending hashes around and timestamp-notation signing them, but 0x50 is cleaner and easier to machine parse.

It doesn't matter in any event.  0x50 isn't implemented in any deployed code any more than 0x40 is.  I'd use a notation.

David