i. Can we migrate Tag 18 to a MUST support, or at least a MUST read?
Something like:
A conforming implementation MUST support decryption of this
packet.
I'm putting this in, but I note that makes the minimal implementation
larger. Since not one person has squealed, I'm hearing rough consensus
in that silence.
ii. It seems that section 5.13 duplicates much of the special
CFB processing rules, except for a caveat at the end. Maybe
duplication is needed here for care reasons, or maybe this could
more readily refer to "12.7. OpenPGP CFB mode" Just a thought.
I put a note in. However, there's a small difference between the MDC
and the other version. The MDC version doesn't resync the CFB chain.
Although I think it could be tidied up more:
Any failure of the MDC indicates that the message has been
modified and MUST be treated as a security problem.
Failures include a difference in the hash values, but also
the absence of an MDC packet, or an MDC packet in any
position other than the end of the plaintext. Any failure
SHOULD be reported to the user.
I took this language and broke it out into its own paragraph.
13. Security Considerations
* This specification uses Public Key Cryptography technologies.
Possession of the private key portion of a public-private key
pair is assumed to be controlled by the proper party or parties.
iv. This seems unworthy of stating, but either way, might be better
written:
* This specification uses Public Key Cryptography technologies.
It is assumed that the private key portion of a public-private
key
pair is controlled and secured by the proper party or parties.
I think this particular warning dates all the way back to 1991, but I'm
not sure. I'd go for taking it out, myself, because I agree it to be a
"Well, Duh!" comment. However, I also remember it being Extremely
Important to someone back in the Crypto Wars.
I'm taking your rewrite.
Jon