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
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
