[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Series of minor questions about OpenPGP 4
On Fri, Jan 30, 2009 at 8:59 PM, David Shaw <dshaw@xxxxxxxxxxxxxxx> wrote:
>> Uhm? Why this? I'd thought it would only revoke the specifically
>> revoked signature, as "the signature is computed over the same data as
>> the certificate that it revokes".
>> Am I missing something?
> Take this example:
> User ID
> 0x10 signature on that user ID (timestamp 1)
> 0x10 signature on that user ID (timestamp 2)
> 0x30 revocation (timestamp 3)
> Which signature is being revoked? Without a signature target, it's
> not clear.
First of all,.. the different types of revocation signatures are NOT
calculated of the signature they revoke, but the data the signature to
be revoked was calculated over, right?
Ok then it's clear.
Why is it not simply calculated over the signature to be revoked?
But the following is still unclear:
a) when I use a 0x20 key revocation signature:
Am I correct that the explanation on page 21 says: A key having a
revocation signature is completely invalid including all it's UIDs,
subkeys, etc. and this cannot be undone in any way?
(Of course the subkeys could still be used attached to another primary.)
I mean the following doesn't work, right?
|--->0x13 on that UID
|--->0x18 on that subkey
now I add a:
|-> 0x20 key revocation at 12:00 making the key unusable (forever?)
at 13:00 I add new UID's/0x13s/Subkeys/0x18s
|--->0x13 on that UID2
|--->0x18 on that subkey2
But the whole thing would still be revoked, right?
b) when I use a 0x28 key revocation signature:
Does this (according to the RFC) make the subkey forever unusable, as
above with the 0x20s?
Or would issuing a subkey binding signature more recent than the 0x28
bring it (the subkey) back?
c) when I use a 0x30 certification revocation signautre.
Here the whole thing is different to a) and b) (as far as I understand).
The RFC says "This signature revokes an EARLIER User ID certification
Does this now exactly mean,.. that it revokes ALL earlier user id
> I can't speak to any other program, but GPG finds the latest
> (i.e. most recent) signature or revocation from the issuer. If that
> turns out to be a revocation, then there is effectively no signature.
> Note that using the example above (sig+sig+revoke), this would result
> in there being effectively no signature. That is intentional, not a
> bug: the second signature superseded the first signature, and then the
> revocation revoked the second. End result: no signature.
Ok I see.
And what does this now mean for my idea on how to force an
implementation to use only the most recent signatures?
Will the following work, as long as the signature creation times are
correct? And I mean would it be correct even when strictly following
0x13 signature on that user ID (timestamp 1) (is not revoked by the 0x30 below)
0x13 signature on that user ID (timestamp 1)
0x13 signature on that user ID (timestamp 2)
0x30 revocation (timestamp 3) (revokes every
0x10,0x11,0x12,0x13,0x1F on UID2 BUT NOT on UID1 BEFORE
0x13 signature on that user ID (timestamp 4) (is not revoked by the 0x30 above)
Thanks for your help,