You are saying there there is no way to remove 3DES from the set of
algorithm preferences, since it is implicitly there per RFC 4880.
If a key has {AES-128, AES-256} as a preference list, right now it is
effectively {AES-128, AES-256, 3DES}.
And I think it follows that the only logical intended action that your
proposal seeks is to break the transmission if one of recipients is an
ECC key that disallows 3DES, *if* 3DES is the only shared algorithm for
the given set of recipients per RFC 4880.
It is possible to keep this feature limited to the mode of operation of
the software (a command line option --cipher-algo, UI element, etc),
v.s. making it depend on the attribute of a key.
This assumes that both sides "agree" to use the Suite-B profile. This is
usually the case. Many other criteria must be met in order to be in
highly regulated Suite-B profile, especially for Top Secret or
classified category. These additional requirements include the type of
authentication to local keys (which AFAIK must be hardware protected
path authentication).
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
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.)