ietf-openpgp
[Top] [All Lists]

Re: Series of minor questions about OpenPGP 4

2009-01-28 14:44:52

Hello Peter -

I will answer your questions on the assumption that you are writing
OpenPGP compliant software. You are therefore asking about how you should
implement your software.

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 :-)

I would certainly encourage you to set the critical bit on these and
other signature subpackets that you view as critical to the security. You
might also want to require the critical bit to be set on those packets,
although that will impair interoperability.


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? ;-)

In your software, you should make your own judgements about this.

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).

I would encourage you to make sure your software does not create keys
which have this problem. If you do receive keys with this kind of
inconsistency, you should decide for yourself how to interpret it.
There is no one right answer for what to do with keys with this problem.

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.)

I hope you will write your software not to make this mistake.

c) It's nowhere clearly specified if and what meaning these supackets
have on the subkey binding self-signature (0x18)

You should probably not put subpackets into such signatures which do
not have clearly defined meanings.


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).

That is probably not going to happen. It took us many years to come up
with the latest RFC. I doubt that we would see another revision before
2012 at the earliest.

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.

I would recommend that your software follow this principle.

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.

If the attacker got the private key.

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?

I would encourage you to consider this design concept in your software.

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.

Again, there will be no new RFC, not for many years at least. You must
solve them in your software using the current RFC. If you want to ask
more specific and practically oriented questions, like, what should I
do when I see this kind of key, we can try to give you more specific
advice.

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?

Feel free to ask more, but I think on this list, for me at least the
information I can give you is limited to advice along the lines I have
outlined above. Maybe you can persuade David or someone else to change
his software to be more to your liking, or failing that you can write
your own to address your concerns.

Hal Finney