[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Series of minor questions about OpenPGP 4




On Jan 31, 2009, at 7:29 PM, Christoph Anton Mitterer wrote:

Sorry, I haven't seen that Peter has nearly asked the same...

On Sat, 2009-01-31 at 16:39 -0500, David Shaw wrote:
btw: As far as I understand this works the following way:
- a 0x30 revokes ALL 0x10-0x13s and 0x1Fs with the SAME creator as the revocation signature AND with an earlier timestamp than the revocation
signature
BUT ONLY when calculated over the same data, which effectively means:
* Either all the 0x1Fs from the specific key (primary or sub)
* Or ALL 0x10,0x11,0x12,0x13s from the specific User ID
but NOT:
* from all User IDs or even all 0x10-0x13s and 0x1Fs


- a 0x28 revokes ALL 0x18s (and thus the embedded 0x19s) with the SAME creator as the revocation signature AND with an earlier timestamp than
the revocation signature
BUT ONLY when calculated over the same data, which effectively means:
* Only on the specific subkey, not from the other subkeys
I've seen you other mail that for subkeys this isn't possible at all, as
only one 0x18 and corresponding revocation is allowed.

Unless you strip off the old 0x18 and revocation.

- a 0x20 recovers everything and cannot be undone (with timestamp
tricks)

Is this correct?

Not exactly.  A revocation revokes *one* signature.  Given this:

  Signature (timestamp 1)
  Signature (timestamp 2)
  Revocation (timestamp 3)

The end result is no signature - but the reason is not because the
revocation has revoked both signatures.  The reason is because the
signature at timestamp 2 has replaced the signature at timestamp 1,
leaving this:

  Signature (timestamp 2)
  Revocation (timestamp 3)

And then the revocation revokes the one remaining signature.
OK I'm a little bit confused on how this works when an implementation
doesn't follow the recommendation to use the most recent self-sig,
because then it would matter whether "Revocation (timestamp 3)" applies
to "Signature (timestamp 1)" or "Signature (timestamp 2)".

If an implementation doesn't follow the recommendation, then most of the bets are off. You can't really predict what it will do. Will it decide that signature 2 is revoked, and thus act on signature 1? Maybe. Will it decide that signature 1 is revoked, and thus act on signature 2? Maybe.

Again, though, I have to stress that this is RFC pedantic nitpickery. In the real world, no implementation does this, as it would make little sense.

But I've seen that Peter has asked nearly the same before (this time
I've got his mail in time ;) ) and so I watch there for an answer.

But on more thing: What I wrote above, with the "classes" and that it
applies only to the specific UID,.. this is actually true, right?

I'm not sure I understand the question here.

David