On Sat, 2009-01-31 at 22:36 -0500, David Shaw wrote:
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.
Ok,.. but this is not really possible due to the keyservers,... they'd
bring it back, correct?
Now what would e.g. gnupg do if it enounters:
Subkey
0x18 subkey binding (timestamp 1)
0x28 subkey revocation (timestamp 2)
0x18 subkey binding (timestamp 3)
?
Or what if it for example has:
Subkey
0x18 subkey binding (timestamp 3)
And with via an update from the keyservers it gets:
0x18 subkey binding (timestamp 1)
0x28 subkey revocation (timestamp 2)
in addition.
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.
Ok I see. While I don't consider this to be a big problem in practice, I
think that this is an aesthetic problem with the spec as even an, in the
strict sense, conforming application could run into this problem.
I think this underlines Peter's and my point of view, that some future
RFC should clarify all this:
1. What MUST an implementation do with multiple self-sigs (and not what
is it RECOMMENDED to do).
2. Revocations SHOULD contain signature target subpackets.
3. And specifying the a revocation signature always applies to the
signature most recently to its own timestamp
(Of course 3. would be implied by 1.)
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.
Yea, of course,.. I fully know and agree with you! Please don't think
that I want to be annoying or offend your something like this :-)
I'm just a perfectionist ;-)
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.
I meant:
If I do a 0x30 certification revocation it _either_ applies only to
0x10s and 0x11s and 0x12s and 0x13s ... _or_ to 0x1Fs.
These two groups cannot be mixed, as they're calculated over different
data, and thus the revocation signature too.
Ok,... I think we have the same opinion now (ok, one of us is a little
bit more pedantic,.. don't wanna say names,..let's call him "Christoph
M." ;-) ) so we can stop this discussion here ^^.
Greets,
--
Christoph Anton Mitterer
Ludwig-Maximilians-Universität München
christoph(_dot_)anton(_dot_)mitterer(_at_)physik(_dot_)uni-muenchen(_dot_)de
mail(_at_)christoph(_dot_)anton(_dot_)mitterer(_dot_)name
smime.p7s
Description: S/MIME cryptographic signature