Problem with faked-system-time option

[Jerome Baum]

>>>>> 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. <snip by JB>
>
> Forget the word notary.  Just erase it from your head.  If you don't like the analogy, then don't use it.

Do you not agree that a bad analogy is going to cause confusion? It
already has, and likely will continue to. If the signature is
analogous to a notary signature, then other implementations will
interpret it that way. I won't forget the word notary because it's in
the standard. If it's not applicable, it shouldn't be in there. It's
in there, so there is a gap between the intention and the wording of
the standard w.r.t. 0x50. So, we shouldn't use it a.t.m. as it's
"unclear".

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

So I'm signing that the signature hasn't been changed, or that I am
the owner or author of the signature? Is that *really* what I mean
with a timestamp signature? Because the standard says that's what 0x00
"usually" means.

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

Don't interpret that into what I said. You may sign either the data or
the signature, but that should be explicit -- you should be signing
the signature if you saw the signature, and the data if you saw the
data (rather, it is your choice). If we use 0x50 that means it's not
your choice, as you can only sign the signature. So, how do you sign
(i.e. timestamp) data that isn't already signed by someone else?

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

But you can't sign data.

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

Exactly my point. If 0x40 is not clear enough (per others), and 0x50
isn't clear enough (per me), and a notation can be used right now with
any requests for clarification/interpretation and can be marked
critical or non-critical and be appropriately handled by existing
implementations, and if we can use it to promote notations in general,
then we should use it.

I think the general consensus seems to be on a notation anyway (as far
as there is concensus), so let's just focus on specifying the notation
more closely. Assuming Werner's confirmation, we are at this state:

1. timestamp-only at gnupg.org. If this notation exists on the signature,
that indicates it is a timestamp signature.

1 a. Should we set this notation critical, non-critical, or user's
choice? We also had the suggestion of doing two signatures, one w/
critical and one w/out. The idea was that the user will be inclined to
look more closely.

2. Suggestion: timestamp-resolution at gnupg.org. Value is number of
seconds of error in both directions.

2 a. Thinking about it, this should be two notations:
timestamp-error at gnupg.org, and timestamp-resolution at gnupg.org (the
difference being: error = clock drift, while resolution = fixed
intervals, e.g. for datestamps resolution would be 86400 and timestamp
would be at 00:00).

2 b. Need a more formal spec on how this works (how is the interval defined).

3. Other stuff?

-- 
Jerome Baum
tel +49-1578-8434336
email jerome at jeromebaum.com
web www.jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA