On Thu, Jan 29, 2009 at 06:42:22PM +0100, Peter Thomas wrote:
I would certainly encourage you to set the critical bit on these and
other signature subpackets that you view as critical to the security.
Unfortunately I have no idea how to do this with gnupg (my used
implementation)... perhaps David can comment on this. But even if
would do modifications to set the critical bit on them I fear
compatibility issues with other implementations.
That's basically the point of the critical bit. You can think of it
as a way to force a (quasi) compatibility break. The critical bit
means "This subpacket is so important to the signature that I'd rather
you treat the whole signature is invalid than you not understand this
subpacket".
For example, GPG sets the critical bit on signatures that have an
expiration date set. Thus, if the signature is read by an
implementation that doesn't understand expiring signatures, the whole
signature is invalid. This was deemed better than the alternative - a
"expired" signature being treated as still usable because the
recipient implementation didn't know to ignore it.
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.
But this is the point. Which have clearly defined meanings? Hast the
policy URI a meaning on 0x18s (e.g. as the policy for signatures made
by that subkey)?
It is the policy under which the subkey itself was certified. The
Policy URI for signatures made by that subkey would be in those
signatures.
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.
Oh my mistake,... an absent key expiration time means unlimited ;-)
Anyway I think the original problem remains,.. what is the semantical
meaning e.g. when there are different key expiration time values on
(perhaps even multiple) 0x13s and a 0x1F?
Section 5.2.3.3:
An implementation that encounters multiple self-signatures on the
same object may resolve the ambiguity in any way it sees fit, but
it is RECOMMENDED that priority be given to the most recent self-
signature.
I suspect that most software follows this recommendation. GPG does.
For example I'd like to see those possible (at leas in my opinion)
security critical subpackets to be REQUIRED by an future RFC. Of
course no one can force an implementation to really adhere to the
standard, but that's always the case.
The problem here is that what one use case requires as security
critical may not be what another one does. The critical bit is a more
flexible way for an implementation to require which subpackets are
understood.
David