However, I do see the benefit of a feature. If it were to make into the
document I suggest to make it more generic and not Suite-B specific. The
following alternatives achieve the same what Davit proposed but are easier
do understand:
* this key has no implicit default algorithms
* this key replaces 3DES implicit algorithm with AES-128
This second one (AES-128 replaces 3DES) *really* appeals to me.
It should also further appeal to resource-constrained environments,
where (therefore) not having to implement (or use) 3DES would be
a bonus.
Actually, maybe we need to add / reconsider having a section
in the ECC doc that says
"if AES-128 is not explicitly in the set of preferred algorithms, then
it is implicitly added at the end. If neither AES-128 or 3DES are
explicitly listed, then both of them are implicitly added, with 3DES
last."
NB, this is weaker than the idea of a "strict suiteB flag" (my original
proposal), and slightly weaker than your "AES128 replaces 3DES."
David Crick wrote:
"11.3. Interoperability with Suite-B profile" currently states:
"If TripleDES is the only shared algorithms for a set
of recipients, no Suite-B compliant recipient can be added to the
mentioned recipient set."
but doesn't state how this may be enforced by the *recipient*
(who may not currently have a way of specifying this to the
sender).
I therefore have a suggestion:
implement a key-packet preference flag that says "strict SuiteB"
If this is set, then applications MUST NOT use any other cipher
other than one of the allowed AES sizes for that ECC key size.
This will allow us to disallow 3DES (and any other non-AES cipher)
by setting this key flag.
Independent of this, an application may additionally have an
--enforce-suiteB flag/checkbox
thoughts people?
(as an aside, re my "editorial [readability] changes," I might be
able to sit down and have a go at them on Monday or Tuesday.)