On Sun, Feb 1, 2009 at 4:17 AM, David Shaw <dshaw(_at_)jabberwocky(_dot_)com>
wrote:
That's a good question. The RFC specifies that a subkey may have one
(and only one) binding signature, and zero or one revocations.
Wow,.. uhm could you please point me to the location that mandates this?
Section 11.1. But notice what that section is: Transferable Public Keys.
This doesn't really mean you *can't* re-sign a subkey. It just means that
once you *have* re-signed a subkey, you need to remove the old signature
(and revocation, if any) before you give the key to anyone else.
Uhm,.. ok I think I don't fully understand the whole issue.
As you've said, section 11.1 is just about transportation, and nothing more:
So in principle the following would be ok and allowed (AND they key
would be valid and ussable) by the standard:
Subkey
0x18 timestamp 1
0x28 timestamp 2 => revokes 0x18 from timestamp 1
0x18 timestamp 3
Right?
You just wouldn't be allowed to transport it.
But what does this actually mean? Would it follow from this, that if
an implementation or keyserver deletes the whole subkey, or just the
unrevoked part?
I must admit that I consider the standard to be a little bit unclear
in this issue, (don't take this personally of course ;-) ).
Not exactly - it revokes one signature. However if there is more than
one signature, the earlier signature should be superseded by the later
one.
I must apologize myself,.. but I don't understand this.
The RFC must somehow specify which of the earlier self-signatures is
revoked by it, or not? Or does it always revoke the MOST RECENT found
signature BEFORE its own timestamp? If so where is this specified (I'm
just curious, not that I wouldn't believe you ;-) )?
The RFC specifies the signature target which lets a revocation indicate
which signature is being revoked.
Ok with signature targets it's clear.... but we talk when having no
signature targets, which seems to be currently the case in all
implementations, right?
Aside from that, there is no indication
at all beyond that the revocation is issued over the same data as the
signature being revoked, and that it is dated after the original signature.
Ok,. but it MUST be an earlier one?
It's not most recent, it's not least recent, it's simply not specified.
Wow... this means in principle,... that there is a "hole" in the RFC,
for those cases where an implementation doesn't follow the
recommendation to use the most recent self-signature, or am I wrong?
I mean if an implementation follows the advice to only use the most
recent self-signature the following example would be ok:
UserID
0x13 timestamp 1
0x13 timestamp 2
0x30 timestamp 3
The key holder wants obviously that both is revoked and it works the following:
1st: the timestamp 1 sig is replaced ("revoked") by the timestamp 2 sig
2nd: no there's only one left (the timestamp2 sig) which is than
revoked by the timestamp 3 sig
Right so far?
Even with reordering the packets an attacker could do nothign, e.g.:
UserID
0x13 timestamp 1
0x30 timestamp 3
0x13 timestamp 2
This could still be resolved as above.
But if an implementation doesn't follow that advice we could end up
with the following:
UserID
0x13 timestamp 1
0x13 timestamp 2
0x30 timestamp 3
No which one is revoked by the timestamp 3 sig? #1 or #2?
Even in such a case an implementation could do stupid things:
UserID
0x13 timestamp 1
0x30 timestamp 2
0x13 timestamp 3
0x30 timestamp 4
It could think that #4 revokes #1 (it is an earlier signature), then
#2 would be ineffective and #3 would remain.
I think I'm a little bit confused now xD
Cheers and thanks in advance,
Peter