Bill Stewart writes, regarding signature subpackets:
2 - signature creation time [And a bunch of similar good
entries]
4 - exportable [This isn't ITAR - this indicates whether
the signature can be transmitted to other people or is
for your own use only. So don't panic :-)]
10 - The Infamous Additional Recipient Request
16 - Issuer KeyID - Sounds Ominous and Not documented!
Issuer keyid is what tells you who issued the signature. This information
is in V3 signatures as well.
12 - Revocation Key - Only for self-signatures(??)
so you can revoke your key after losing your key
21 - Preferred hash algorithms
22 - Preferred compression algorithms
23 - key server preferences
24 - preferred key server - presumably the Signer's preference
for finding further data about the Signer's key?
Bit 7 - Criticality Bit - [Semantics: I don't quite understand it?
Reject Key If you don't support the Subpacket Type,
or reject the signature rather than the whole key?]
The criticality bit is intended to have two different meanings:
- On a self-signature, ignore the key if you don't understand the
subpacket type. This is because the self-signature may be
saying something important qualifying the meaning of the key or
how it is intended to be used by the owner. If you don't know
what he's saying, it's safest not to use the key.
- On other signatures, ignore the signature if you don't understand
the subpacket type. The idea is that you understand the uses of
the key that the owner specifies, but you don't understand what
someone else is saying about the key. You ignore the whole
signature by this other person because the subpacket may qualify
the meaning of the signature (it may not be an identity
signature, for example).
So the Infamous Additional Recipient Request is just a subpacket of known
length,
in a table of zero or more extension-like subpackets,
and the description of the Criticality Bit seems to imply that it's
ok to have subpacket types that aren't recognized
and can be skipped over because their lengths are known.
So that's the good news.
The bad news is that, while the Criticality Bit is only sketchily documented,
it sounds like part of a CMRist plot, to make use of the ARR mandatory if the
recipient requests it (there _is_ the semantics issue of what the program
should do if it understands the Additional Recipient Request and doesn't
feel like cooperating :-)
The critical bit is intended to provide guidelines for the case where you
don't recognize the subpacket type. It does not apply to cases where you
recognize the subpacket but are choosing to ignore it. So it is irrelevant
to the issue of the ARR subpacket.
The ugly news is that Additional Recipient Requests are a really weird thing
to attach to a signature, rather than part of the key itself -
I suppose that makes it easier for the Corporate Security Bureaucrats to
request,
rather than having some special case part of the key generation, which would
be uglier, but it's still a strange place to put it.
Putting information in a self-signature allows the user to modify it
without invalidating all of the other signatures he has collected on
his key. Preferred algorithms are another example where this may be
very useful.
But in conjunction with the Criticality Bit, this extension method is a
Denial Of Service Attack - unless I'm misunderstanding the bit,
if the bit is set and the subpacket type is unrecognized, the recipient
is supposed to reject the entire key packet and not just the signature packet
-
does this mean that somebody can sign your key with a Critically Bogus
Subpacket
and prevent anybody from using your key? (e.g. by signing a keyserver key...)
No, because this would be the second case above. All they can do is to
make you ignore their signature, so they would accomplish nothing by it.
Hal