David Crick wrote:
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."
I find implicit rules of the RFC 4880 controversial. They could have
been like this: if there is no encryption keys preferences, only then
3DES is implicitly present. That is, it would be limited to old keys. I
would favor explicit rules, if possible.
Besides, even without this thought, I don't see how your latest proposal
gives an ECC public key holder a mechanism to block transmission with
3DES (because 3DES sneaks in as an alg. for ECC keys, it may be chosen
by the sender).