ietf-openpgp
[Top] [All Lists]

Re: Series of minor questions about OpenPGP 4

2009-01-30 19:18:27

On Fri, Jan 30, 2009 at 8:59 PM, David Shaw <dshaw(_at_)jabberwocky(_dot_)com> 
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.
Ahhhh....
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?
Primary key
|->UID
|--->0x13 on that UID
|->Subkey
|--->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
|->UID2
|--->0x13 on that UID2
|->Subkey2
|--->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
signature..."
Does this now exactly mean,.. that it revokes ALL earlier user id
certification signatures?


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
the RFC?

Public Key
UID1
0x13 signature on that user ID (timestamp 1) (is not revoked by the 0x30 below)
UID2
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
timestamp 3
0x13 signature on that user ID (timestamp 4) (is not revoked by the 0x30 above)




Thanks for your help,
Peter