ietf-smime
[Top] [All Lists]

Re: 3850bis and 3851bis: proposed changes to cryptographic key sizes

2009-01-08 16:17:12

At 9:13 AM -0500 1/8/09, Tim Polk wrote:
Hi Alfred,

The lower bound was dropped for a couple of reasons.  Practically speaking,
any RSA/DSA keys smaller than 1024 bits offer little security.  
Setting any lower bound
seems to imply that there is a significant break point, and I did not want to 
give
that implication.  I also thought that implementations might want to set a more
aggressive bound (e.g., 768 bits) and leaving off the lower bound might
encourage making an explicit choice rather than supporting 512 because it
was specified in the table.

Perhaps the right thing would be to add one more sentence in each of the
security considerations sections.

For 3850bis:

Note that previous versions of this standard set the lower bound for RSA and 
DSA key
sizes at 512 bits; implementations that support verification of certificates 
or CRLs
generated with weak keys MUST NOT support RSA or DSA keys of less than 512 
bits.

For 3851bis:

Note that previous versions of this standard set the lower bound for RSA and 
DSA key
sizes at 512 bits; implementations that support verification of digital 
signatures
generated with weak keys MUST NOT support RSA or DSA keys of less than 512 
bits.

Would that address your concern?

I cannot say if it affects Alfred's concern, but I *strongly* object to such a 
normative change at this late date in the document cycle. Your original logic 
(don't imply a break point) is still valid. There may be perfectly valid local 
policy for a site to want to support shorter keys for historical reasons. We 
have already made it clear what the interoperability issues are, and we have 
set them based on security in the Internet context. The current wording 
obviously discourages anything under 1024 bits.