Re: ECC in OpenPGP -00.txt is posted as a draft

["David Crick" <dacrick@xxxxxxxxx>]

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