Series of minor questions about OpenPGP 4

[David Shaw]

I think at this point you should take the discussion to the ietf- 
openpgp list.  This is really the GnuPG users lists, and the questions  
are in-depth design questions for the protocol itself.

David

On Jan 27, 2009, at 10:27 AM, Peter Thomas wrote:

> 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 at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>