Bill Stewart wrote:
Jon's done a great job on the standard - I still find it hard to read,
partly because it's bottom-up rather than top-down, which makes it
easier to follow syntax and harder to follow semantics, and partly because
there's just a _lot_ of detail, and the newer features are pretty complex.
Yes, I was always afraid of that, which was part of the reason I was
concerned at getting the document out there. To be fair it was never
likely to be anything else, as the architecture of PGP evolved from
mysterious roots into the beast we now know and love.
I hope there is time left after these other discussions going on for the
WG to actually read the standard.
But if I do understand what's going on, the CMR support is just one entry
in a table that's needed anyway, plus a paragraph of apologies (:-),
and may be the primary motivation for one other feature.
If I can modifiy Jon's syntax description a bit:
A Packet is a record containing the following in a tersely encoded format (:-)
I'm sure ASN.1 would have been terser :-)
Packet Tag - indicates packet type, 0-15 (old) or 0-63 (new)
...
A Subpacket - [!!! FINALLY - THE FUN PART !!!]
Subpacket Length - (packed, one or two octets)
Subpacket Type-And-Criticality-Indicator - Octet
Subpacket Body - format is Subpacket Type dependent.
A Subpacket-Type-And-Criticality-Indicator Octet
Bits 0-6 - Subpacket Type, an entry from a table including
...
10 - The Infamous Additional Recipient Request
16 - Issuer KeyID - Sounds Ominous and Not documented!
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?]
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.
In a sense what you are proposing is that sub packet 10 is reserved, has
a length for skipping reasons, but no more. Yet another RFU number?
I'll have to think about that (it took me about two weeks to develop my
argument in the previous post - it's tricky stuff).
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 :-)
And the notion that one would not support the subpacket but would
support the bit - which you develop further below. I feel this is
intuitively a non-starter. Once a progammer (or whoever) decides the
subpacket(s) are not supported, then it is most likely the bit will be
ignored, just from the human effort of trying to work out what the
semantics of taking instructions from something you don't understand
are.
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.
I guess this is a consequence of asking the respondent to participate in
your recovery needs. Always likely to be clumsy as it bears no
relationship to normal communications models. The only model where I
can think of the respondent needing to play a part is secrets security,
where everyone is encouraged to report comrades with treacherous
thoughts.
I suppose the effect looked for is that the recoveree initiator should
sign their willfull acceptance so that the accessory responder can
authenticate the entrance of the recoveror into the protocol. The
special black box secret key generation methods would have been more
robust.
What I find the weirdest is that this system is at least deployed in
test arenas, and for all we know in real customer sites. Somehow, the
software engineering difficulties have been overcome, but I couldn't
begin to work out the ramifications of such. Auditing, provability,
reliability, ... my bind moggles!
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...)
Highly amusing :-) I'm sure there is an explanation on its way. In the
meantime, one could try it. I believe that pgp5.0 supports all the
above fields, and there are keyservers.
Well spotted! Thinking about it, there's something odd in the way the
signature tells the software where to pick up the key to check the
signature...
--
iang systemics.com
FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com