* I like David Crick's suggestion of a preference that says, "I'm
going to be strict about Suite B." This is a legislative solution, and
it would work well, it's simple, and elegant. End of story.
are you referring to a "key" or "application" preference (or both?!)
* Test, for interop purposes, 3DES with Suite B.
sounds sound
If you don't like this, you could do what David Crick suggested,
but with reverse polarity. I mean that instead of having an "--enforce-
suiteB" option, you have a "--loose-suiteB" option that you have to do
to allow anything that's not strict.
Note that these are not exclusive. You can do both.
So are you saying we have:
o Strict Suite B key flag ("legislative"; allows recipient to specify strongly)
*plus* (potentially out of scope of the [legistlative] spec?)
o an --enforce-suiteB application flag (self-evident)
o a --loose-suiteB application flag (but can it override a key-flag? - or
are you using this instead of a keyflag)
Even better would be for implementations to just not offer an
alternative.
yes!
If all applications were to by default add AES (one or both) to
the head of any ECC generated keys, *and* prefer AES over
3DES as implicit, *but* still be able to "understand" messages
that are encrypted by non-AES ciphers.