[Top] [All Lists]

Re: CMR as an extension _inside_ the standard (Re: CMR & ROT-13)

1997-11-22 21:55:16
That leaves us with the fourth option.  Say nothing and do not document it.
This of course will be problematic for programmers, as they test their
code against 5.x, and discover the strange packets.  

It may be that it doesn't cause a problem.

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.
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 (:-)
        Packet Tag    - indicates packet type, 0-15 (old) or 0-63 (new)
        Packet Length - optionally indeterminate
        Packet Body   - format and semantics depend on Packet Tag
A Transferable Key Packet probably has Public Key syntax Packet Tag = 6?
A Transferable Key Packet has
        One Public Key Packet
        Zero or more revocation signatures
        One or more User-ID-With-Optional-Signatures entities
        Zero or more Subkey-With-Signature entities
                ["entity" isn't a PGP Packet format, 
                it's a group of packets I've defined for
                increased syntactical precision]
A User-ID-With-Optional-Signatures entity is
        One UserID Packet
        Zero or more Signature_Packets
                [Semantics: These signature packets each sign the 
                concatenation of the public key, the user id, and signature 
A Subkey-With-Signature entity is
        One Subkey Packet
        Maybe[??] zero or more subkey revocation packets[??]
        One or more Signature_Packets
                [Semantics: These signature packets each sign the 
                concatenation of the public key, the subkey, and signature 
A Signature_Packet is a packet with PacketTag=2, 
        either Version 3 or Version 4 Signature Packet Format
A Version 4 Signature Packet contains
        Version Number (octet = 4)
        Signature Type (octet - e.g. binary, text, several keycerts, 
        Public Key Algorithm (octet - e.g. RSA, DSA, EG, ...)
        Hash Algorithm (octet - e.g. SHA-1, MD5, RIPEMD-160, ...)
        Octet Count for following hashed subpacket data (2 octets, weird format)
        Subpacket_Data_Entity - gets hashed
        Octet Count for following unhashed subpacket data (2 octets, weird 
        Subpacket_Data_Entity - doesn't get hashed
        Left-16-bits-of-signed-hash-value Field - for checking success
        Signature - Algorithm-specific collection of multi-precision integers
A Subpacket_Data_Entity - [My term.  Draft section]
        Length-Of-Subpacket-Set (two octets, probably packed format?)
        Zero or More Subpackets 
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
                2  - signature creation time  [And a bunch of similar good 
                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!
                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 
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 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 
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.  

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

Bill Stewart, stewarts(_at_)ix(_dot_)netcom(_dot_)com
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639