David Crick wrote:
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.
Given later comments by Derek and your subsequent replies, I think we
may need separate discussion on this. Without assumption that additional
key properties is the way to go and where this description should be, I
thought it will be helpful to submit more detailed proposal on how this
could be done and what are the issues we need to worry about. I will do
this before coming Monday. We can then have some sort of vote on this
subject.
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?
Will do.
(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??!
I meant to provide a warning to implementors that once crypto/messaging
layer detects sending conflict to a group of recipients, the conflict
cannot be resolved by sending two separate messages. While each of two
messages with appropriate subset of recipients can satisfy constrains of
crypto/messaging layer, this is not the right thing to do from the
point of view of information protection.
For example, I thought that the following message misses this point:
Len Sassaman wrote this in Mar 2008:
Breaking compatibility on the protocol level doesn't mean breaking it on
the actually application level. In a different thread, there as discussion
of people using "regular" DSA/EG keys and then adding a recipient who uses
ECC. So what? The application can encrypt twice, and send the properly
encrypted messages to the appropriate people.
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.)
I would say that, overall, AES-128 should remains the lowest common
denominator in this specification. It is needed to cover the mix of
recipients with smartcards, cellphones, etc. Hopefully, "TOP SECRET
Suite-B profile keys" will not be issued on constrained smartcards.
Another point, when TOP SECRET keys receive TOP SECRET information, this
is when AES-256 must be used, only TOP SECRET keys can be in the list of
recipients. AES-256 SHOULD be in the set of preferred algorithms on each
key in this case.