The discussions we had on pre-submission version of the specification can
continue with the draft.
The submitted version doesn't (yet) have mention of the
proposed (and generally, it seems, well-received notion of)
a StrictSuiteB flag / flags. Discussions tailed off on this, but we
(still) need(ed) to give the whole interoperability thing a long
hard look, as per your last message on this topic.
Some comments from me on the (latest) submitted draft:
| While TripleDES ensures interoperability between applications
| complaint with OpenPGP and ECC specifications, it doesn't help
| interoperability with Suite-B profile. Suppose TripleDES is the
| only shared algorithm within a set of recipients. If Suite-B
| compliant recipient is added to the mentioned recipient set, the
| sender SHALL NOT send out a message.
shouldn't this be MUST NOT?
(continuing to quote section so people can see the context)
| This is because TripleDES is
| excluded from Suite-B and sending out two copies of the same
| message, one encrypted with TripleDES and another with AES-128 or
| AES-256, would mean that the same information that must have been
| protected with Suite-B compliant algorithm was protected instead
| with non-compliant TripleDES. This restriction covers other cases
| in which none of recipients' shared algorithms are allowed by
| Suite-B. One of available methods to a recipient to help ensure
| interoperability with Suite-B is to include one of two Suite-B
| symmetric algorithms, AES-128 or AES-256, or both, in the set of
| preferred algorithms.
(end of that section).
But how *on earth* are you going to "enforce" people NOT sending
two copies of the same message under different ciphers??!
Meanwhile, this new bit:
| While some statements in this specification refer to TripleDES
| algorithm, this is only done to help interoperability with existing
| application and already generated keys; AES-256 is the recommended
| alternative to TripleDES in all circumstances when AES-256 is
| available.
I (really) like, but probably needs to have added onto the end of it:
Note, however, that AES-128 is the MUST algorithm for OpenPGP ECC,
and may be preferred in more constrained environments. However,
AES-128 is not allowable when the larger Suite-B profiles are required,
so AES-256 may still need to be implemented for this interoperability.
(But, as I stated at the start of this email, this whole topic still needs
further thought.)