At 2:35 PM -0400 5/2/08, Tony Capel wrote:
I think the minimum supported size needs to be 2048 because:
Please be more specific. Supported for what? Signing, verifying, or both?
1) Since at least April 2007 (over a year ago) Verisign has been issuing certs
with 2048 keys (I believe this is selectable when enrolling)
(although the root
cert is only 1024!).
2) NIST is recommending 2048 by end of 2008 for signatures and key
transport for
some apps [SP-800-78-1 Table 3.1].
3) Many/most hardware tokens (e.g. Safenet, Gem, Aladdin) are supporting 1024
and 2048 (only).
The wording clearly says that you should expect to validate larger
keys, which are covered by those three data points.
Your last point (hardware tokens signing at 1024) is exactly why I
think mandating the ability to sign at least 1024 bits is a good idea.
As far as going larger than 2048, in my brief survey, while there
appears to be
a small level of interest in 3072 (and even 4096), beyond that many
appear to be
recommending a switch to ECC because of the exponentially rising
power/cpu costs
for larger RSA sizes (e.g. NSA Suite B).
The current text encourages being able to verify at any level, not
just 1024 or even 2048.
So I would suggest making 2048 and smaller mandatory. And using a
sentence like:
" Note that receiving agents may see signatures whose key length is
longer than
2048
bits in the future, and support for lengths of 3072 and 4078 SHOULD
be provided
to verify those signatures."
I fully disagree. We are talking about interoperability here, not
best practice. We should not be mandating that receivers be able to
verify things that beyond what is mandated for signers. If you want
to change the length of what signers are required to do, that's fine,
I would want both sides to be accordance. But until then, saying "you
must be able to verify something larger than what you can sign"
doesn't make sense from an interoperability standpoint.
Also, we should not mandate SHOULD-level requirements for particular
size keys. For verification, specific bit-lengths are not important:
it is the maximum key length.
Or
"... for lengths up to and including 4078 SHOULD ..."
to address optional support.
This doesn't seem to be a good reading of RFC 2119.