Ian wrote:
Hmmm... you raise an interesting point. I had thought that this
was going to be a new document, and as it is not referred to in
the existing core RFC, then ECC/Suite B was going to be a MAY by
definition.
Within that new (MAY) document, there would be several choices
for MUST, SHOULD, MAY, etc.
Or so I thought ... but I'm not fully aware of how these things interact.
and further:
I don't see how we can simplify past dropping 192.
OK, if you are happy to carry on this discussion ... what are the
reasons for including the 128-bit profile?
assuming the may -> whatever chain above holds, what about:
MAY implement ECC
o MUST implement AES256-SHA384-384ECC
o SHOULD implement AES128-SHA256-256ECC
o MAY implement AES256-SHA512-521ECC
[and/or any other combinations, but these might be "unbalanced"]
we currently *have* 3072 RSA/DSA strength (or 4096 RSA/ElG for
those wanting a bit of extra headroom); higher size DSA isn't in
any [e.g. NIST] standard, and >=4K RSA/ElG public key ops begin
to take a noticeable time even on my desktop (so while 7K RSA
keys are a simple source-change in GnuPG, ECC would definitely
make sense to achieve a balanced crypto system at this strength).
Now, for "embedded"/constrained systems there may only be the
chance to do AES128-SHA256-256ECC, which would conflict with my
"SHOULD" suggestion above. So there would probably be scope for
the AES128 set to be a SHOULD as well, or even the MUST instead.
To be honest I think having AES256-SHA384-384ECC *and*
AES128-SHA256-256ECC in *some* form of MUST/SHOULD *is*
desirable: it covers both the two "Suite B" available
balanced set of algorithms, which may be important to
some people (and is certainly more "marketable" anyway).
I wouldn't personally "protest" if AES256-SHA512-521ECC
were also included, but I think anything more than these
three balanced sets is "silly."