As it stands right now, Suite-B is vaguely defined, thus there will be a
lot of questions as to what that Suite-B key is.
No, Suite B is very clearly defined:
384 ECC, 384 SHA hash, AES256 ("TOP SECRET")
256 ECC, 256 SHA had (384 also OK), AES128 (AES256 also OK) ("SECRET")
Our "problem" is that we are trying to layer an *ECC* spec
(of which Suite B is a *sub-set*, with specific restrictions)
on top of RFC4880.
Because of that, our "ECC OpenPGP" allows use of 3DES,
but this conflicts with the AES-only nature of the Suite B
subset of our ECC spec.
What do we loose if we
instead use "this key replaces TrippleDES implicit algorithm with AES-128"
notation? This would be beneficial for RSA keys too.
what if we have:
Alice: {AES256, AES128, AESover3DESflag [, 3DES implicitly]}
Bob: {3DES [, AES128 implicitly]}
Then Bob or his software could legitamately choose 3DES.
whereas:
Alice: ECC-384/521 key with {AES256, SuiteBOnly} and
Alice: ECC-256 key with { [AES128 implicit], SuiteBOnly}
would refuse to encrypt with anything except AES256 and
AES128 respectively.
(NB, we're going to hit the same thing with the hash when
- and I use "when" optimistically - Whirlpool gets added; a
SuiteB flag on the key would only allow the correct-sized
SHA2.
NB#2, I'm not entirely sure what "suiteb only" flag means if
you try to encrypt to an ECC key and a non-ECC key?)