Paul:
1A) Both signing and verifying.
Verisign has been issuing both 1k and 2k single keypair certs for some
time, 2k is becoming common in many product specifications and recommended
by many reputable authorities.
I communicate today within a community of 2k and lower certificate holders
not 1K and lower holders. I have a 2k "off-the-shelf" cert from Verisign,
I cannot generate 1k signatures, so anyone I send to must be able to
verify 2k signatures. So verify 2k support is required today. It is true
that users who only intend to use 1k certs could get away with software
which cannot sign using 2k keys; but I think this is a pretty subtle
detail which would be lost in the noise of most specifications.
1B) And encryption and decryption as well.
Furthermore, since those Versign certs are single keypair, I need 2k
encrypt/decrypt since obviously the same keypair is used. Those using
multiple keypair infrastructures with separate signing and encryption
certs could use differing sizes, but in my experience the infrastructures
themselves tend to have the same specification for both sign and encrypt
(sign/verify and decrypt/encrypt).
For encryption of course the keysize is specified by the destination cert;
so if anyone in my community has 2k keys, I must be able to encrypt with
2k keys. So encrypt support for 2k keys is required today. Again, 1k
only support for decryption would be lost in the noise.
So if we wish to guarantee a minimum level of "out-of-the-box"
interoperability from a box which has a simplistic specification
"compliant to smime v3.2"; then we should include a mandate for 2k and
lower support for all operations to meet today's requirement.
2) Support beyond the mandatory.
I agree that support beyond 2k should be optional. I am sorry I misused
the word "SHOULD", I operate in several standardization arenas and rfc2119
is not a universal standard!! I meant OPTIONAL or MAY for the larger
sizes.
The reason for my identifying the specific 3k and 4k values was an attempt
to address an earlier thread where 4k and larger keysizes were proposed -
which led to a discussion of denial of service attacks by senders
specifying large keysizes - and then this led to comments about improper
modulus selection, etc. etc....
The origin of the earlier thread was concern about leaving larger keysizes
completely open (even as OPTIONAL). I prefer to leave this issue, if it
remains an issue, to Peter and the others who contributed to that thread.
(I would just note that in my reading 3k and 4k certs are mentioned, but
it is not clear to me that there is a future beyond 4k RSA with
competition from other algorithms.)
Tony
| -----Original Message-----
| From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
| [mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Paul
Hoffman
| Sent: May 2, 2008 5:44 PM
| To: ietf-smime(_at_)imc(_dot_)org
| Subject: RE: S/MIME v3.2 IDs key size text
|
|
|
| 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.
|