Hello. This time it's all about signature subpackets: Sorry that this got longer, but I think these points are all somehow connected. So feel free to split up as you like :-) I know that these questions are more about OpenPGP itself than gnupg, but perhaps you, David, can have a look at them here, before I post it on their mailing list (don't want to look stupid there ^^ and I'm still quite new in OpenPGP's standard).
1) gnupg (and as far as I can see other implementations, too) don't set the critical bit on much signature subpackets by default. The RFC (AFAIK) doesn't demand any subpacket to be understood by applications. Unknown subpackets should be ignored, except the critical bit is set. Correct so far? Now when I go through the currently defined signature subpackets, I see several which are or at least could be critical for security and for the correct evaluation of signatures: 2, 3: a signature might not be valid yet, or might be expired already 7: an attacker might manage to revoke an irrevocable signature 9: they key is expired and the owner does not want it to be used any longer (maybe also due to security reasons) 12: if an implementation doesn't understand this, it might not notice, that a key/UID is already revoked 26: the policy may contain critical information for security (e.g. "this key signs any applicant without validating his personal data) 27: it might be a security issue, if a key that was marked for certification-only (0x01) has signed some casual data 31: required for revocation signatures and thus possibly security critical 32: required for the signing subkey backsigs (0x19) I'd even consider the following as critical: 28: the signer might want to express that a specific role/UID made the signature, and this might be security critical depending on the policy Of course no one can force the user to actually read and follow these subpackets (the policy (26) is the best example for this ^^), but wouldn't it make sense that the RFC _REQUIRES_ these subpackets to be understood by conforming implementations? Just an idea, though :-) 2) Selfsignatures and possible ambiguities: In an email before David told me that it's fully ok that some signature subpackets are on 0x13 and/or 0x1F self signatures. I said I'll come back to this; here it is. The RFC is very clear (5.2.3.3) about which signature types may be self-signatures, namely 0x10-0x13, 0x1F and 0x18 (I assume 0x19 is let out, as it's made by the subkey, right?). This chapter also says that an implementation should interpret it as narrowly as possible. a) That's by the way the first "problem" which _could_ lead to secrutiy issues, as the standard doesn't define for every case what "as narrowly as possible" mean. Of course everyone could say "just follow the common human sense" but this is always problematic, isn't it? ;-) b) What for example, if a 0x13 and a 0x1F have conflicting key expiration times? Should an implementation use the time in the most recent of the two? Should it use the information from the 0x1F, as key expiration time is "clearly" related to the key, and not the the User ID? Should it just use the smallest value of the two? Should it use the value accordingly by which the key was found (if by Key ID -> use 0x1F, if by User ID -> use 0x13). One can easily think of similar examples for other subpacket types, and its easy to think of examples where this could lead to security problems (Imagine a user resets the expiration time of his key to denote that it should not longer be used. His implementation updates only the 0x13 self-signature but not the "unlimited" in the 0x1F, made by some other implementation. A third implementation may now choose the "right one" or not.) c) It's nowhere clearly specified if and what meaning these supackets have on the subkey binding self-signature (0x18) A solution would be, that the RFC clearly specifies which subpackets MAY go to which self-signature, which one takes priority, and for which the implementation is allowed to choose itself (e.g. according to the way the key was found). btw: The example on page 27 "If the key is located via Key ID => use the subpacket from the primary User ID self-signature also shows the conflict with 0x1F signatures that could arise in that case. 3) This is probably clear for everybody, but the part on revocation signatures should perhaps highlight, that all subpackets in revoked signatures MUST NOT be used, e.g. imagine the key expiration time is only stored in an 0x1F and not in any 0x10-0x13. If that 0x1F gets revoked, the key has no longer an expiration time. btw: Is it specified what happens when possibly security critical subpackets like the expiration time or key usage are absent? 4) In chapter 5.2.3.3 it is explicitly allowed that the key expiration time is reset by a user (of course this cannot be prevented as the key expiration time is no longer part of the key itself). Isn't this possibility comparable to revoke a revocation? I mean the creators states: "This key SHOULD NOT be used after <key expiration>." for example because he thinks an RSA786 key SHOULD no longer be used in 10 years. An attacker might simply revoke this (implicit) revocation by issuing a new self-signature with an updated date. 5) Chapter 5.2.3.3. also says what should happen when multiple self-signatures are encountered by an implementation. Wouldn't it be more secure to require that ONLY the most recent self signature of a given type (per primary key in the case of 0x1F, per User ID in the case of 0x10-0x13 and per subkey in the case of 0x18) may be used and if that one could not be parsed (e.g. because of unknown subpackets with the critical bit set) no self-signature MUST be considered as valid? My idea is about this: Imagine a very old self-signature that still uses MD5 (which is now broken, isn't it?) and a newer (in the sense of it's signature creation time) self-signature which uses say SHA512. Both self-signatures specify a designated revoker (subpacket 12). Now an implementation doesn't understand SHA512 signatures and thus uses the older one with MD5 (as far as I understand the RFC allows to do so). But than one is probably a forged one by an attacker which doesn't contain the subpacket 12. See what I mean? I think it's quite easy to create similar examples with other subpackets involved. So a solution would be that the RFC requires, that always and only the most recent self-signature is used. Ok,.. enough for now,.. but I fear that I'm still not finished :-( Is it possible to donate a few bugs to gnupg in order to compensate the time you spend for answering my questions? Cheerio, Peter _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
