On Thu, Jan 29, 2009 at 9:38 PM, David Shaw <dshaw(_at_)jabberwocky(_dot_)com>
wrote:
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".
Yes :-)
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.
Ok that's already great,.. what do you think about the other
subpackets that I've suggested for being critical in my initial post?
Would you for example change gpg, that for example it issues the
critical bit with the signature creation time, key expiration and key
usage, too?
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.
Ah, you're right ^^ I'm always messing this up.
But by the way: This would be another thing that one could think of in
future revisions of the RFC.
Policy-URI on self-signatures:
0x10-0x13: The policy that is used for signing, with the corresponding UserID.
0x1F: The global policy for the whole key, when signing anything
(especially other keys/UIDs) with that key
0x18: The policy used when making signatures with this key
Policy-URI on other signatures:
The policy under which this signature was issued. (Just like it is
interpreted now)
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.
Of course,.. and in principle this is fine,.. but I'd even go so far
to change this recommendation to a MUST.
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.
Hm, ok you're the expert :-)
I just thought that the subpackets from my initial posting would be
critical in ANY case ^^
Best wishes,
Peter