Series of minor questions about OpenPGP 4

[Peter Thomas <[e-mail]>]

Hello list.

As you can see from the subject this is already the 4th email in a
series of questions about OpenPGP (and in some cases gnupg).
After the first three David Shaw, who perfectly answered my questions
so far (lots of thanks again), asked me to move here, as it became
more and more OpenPGP specific.
For those who are interested (the previous ones also contained
questions about OpenPGP itself, and some very great answers) you can
find the other ones here:
http://lists.gnupg.org/pipermail/gnupg-users/2009-January/035445.html
http://lists.gnupg.org/pipermail/gnupg-users/2009-January/035458.html
http://lists.gnupg.org/pipermail/gnupg-users/2009-January/035467.html


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