Subject: Re: Key Sizes in S/MIME v3.2

From: "Denis Pinkas" <[email-masked]>
Date: Wed, 20 Feb 2008 17:34:03 +0100

>How about for 3851bis: A user agent SHOULD generate RSA key pairs at a
>minimum key size of 1024 bits.  A user agent MUST NOT generate RSA key pairs
>less than 1024 bits long.

With these two sentences there is no more room for key sizes less than 1024 bits.
768 bits is still fully adequate, even we can recommend to use 1024 bits as the minimum.

Denis

>I'll move the 768 back to 512 as suggested by Simon.
>
>spt
>>-----Original Message-----
>>From: Russ Housley [mailto:[email-masked]] 
>>Sent: Wednesday, February 20, 2008 9:16 AM
>>To: Turner, Sean P.
>>Cc: [email-masked]
>>Subject: RE: Key Sizes in S/MIME v3.2
>>
>>Sean:
>>
>>Given the proposed text, it sounds like you really want to say 
>>that key sizes from 768 to 2048 bits must be supported, even 
>>though you are recommending 1024 bits as the minimum for newly 
>>generated keys.
>>
>>Russ
>>
>>At 07:17 AM 2/20/2008, Turner, Sean P. wrote:
>>
>>>I should have been clearer.
>>>
>>>RFC 3850 current says (sec 4.3):
>>>
>>>  Key sizes from 512 bits to 2048 bits MUST be supported.
>>>
>>>Suggesting it be replaced with:
>>>
>>>  Key sizes from 1024 bits to 2048 bits MUST be supported.
>>>
>>>Here are the suggested changes RFC 3851 (sec 4.1):
>>>
>>>  If an S/MIME agent needs to generate an RSA key pair,  then the 
>>> S/MIME agent or some related administrative  utility or function 
>>> SHOULD generate RSA key pairs  using the following 
>>guidelines.  A user 
>>> agent SHOULD  generate RSA key pairs at a minimum key size of 1024
>>>                                          was 768 ^^^^  bits.  A user 
>>> agent MUST NOT generate RSA key pairs  less than 768 bits long. 
>>> Creating keys longer than
>>>            ^^^ was 512
>>>  1024 bits can cause some older S/MIME receiving agents  to not be 
>>> able to verify signatures, but gives better  security and is 
>>therefore 
>>> valuable.  A receiving agent  SHOULD be able to verify 
>>signatures with 
>>> keys of any  size over 768 bits. Some agents created in the United
>>>            ^^^ was 512
>>>  States have chosen to create 512 bit keys in order to  get more 
>>> advantageous export licenses.  However, 512  bit keys are considered 
>>> by many to be cryptographically  insecure. Implementers SHOULD be 
>>> aware that multiple
>>>  (active) key pairs can be associated with a single  
>>individual.  For 
>>> example, one key pair can be used  to support 
>>confidentiality, while a 
>>> different key pair  can be used for authentication.
>>>
>>>Thoughts?
>>>
>>>spt
>>>
>>> >-----Original Message-----
>>> >From: [email-masked]
>>> >[mailto:[email-masked]] On Behalf Of Paul Hoffman
>>> >Sent: Tuesday, February 19, 2008 1:42 PM
>>> >To: Turner, Sean P.; [email-masked]
>>> >Subject: Re: Key Sizes in S/MIME v3.2
>>> >
>>> >
>>> >At 11:34 AM -0500 2/19/08, Turner, Sean P. wrote:
>>> >>  >From the mail discussion we had in December, it's pretty
>>> >clear to me
>>> >>that key sizes from 1024-2048 ought to be the MUST and other
>>> >key sizes are MAY.
>>> >>I'm suggesting the following text:
>>> >>
>>> >>Key sizes from 1024 bits to 2048 buts MUST be supported. 
>>Keys sizes 
>>> >>larger than 2048 MAY be supported.
>>> >
>>> >Sure.
>>> >
>>> >>Should we put a MUST NOT or SHOULD NOT in for key sizes
>>> >smaller than 1024?
>>> >
>>> >MUST NOT or SHOULD NOT *what*? Generate, or validate?
>>> >
>>
>
>

Regards,

Denis Pinkas

---

From: "Turner, Sean P." <[email-masked]>
Date: Wed, 20 Feb 2008 12:10:44 -0500

As I dig around, I find that 1024 is pretty much the minimum that is
recommended. Both NIST (SP 800-78) and RSA
(http://www.rsa.com/rsalabs/node.asp?id=2004) recommend at least 1024 now.
Also, I'm not sure I've ever actually seen a 768-bit key in a certificate -
all I've seen for years now is 1024.

spt 

>[mailto:[email-masked]] On Behalf Of Denis Pinkas
>Sent: Wednesday, February 20, 2008 11:34 AM
>To: [email-masked]
>>minimum key size of 1024 bits.  A user agent MUST NOT 
>generate RSA key 
>>pairs less than 1024 bits long.
>
>>>Given the proposed text, it sounds like you really want to say that 
>>>key sizes from 768 to 2048 bits must be supported, even 
>though you are 
>>>recommending 1024 bits as the minimum for newly generated keys.
>>>
>>>Russ
>>>
>>>>                                          was 768 ^^^^  
>bits.  A user

---

From: Russ Housley <[email-masked]>
Date: Wed, 20 Feb 2008 13:38:54 -0500

The point is that we should be able to validate a signature that was 
generated by a key pair that was generated under the previous recommendations.

Russ

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 21 Feb 2008 06:58:46 -0500

Maybe the DSSC draft could be of use here:
http://tools.ietf.org/html/draft-ietf-ltans-dssc-01.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Wednesday, February 20, 2008 1:39 PM
To: Turner, Sean P.; 'Denis Pinkas'; [email-masked]
Subject: RE: Key Sizes in S/MIME v3.2

The point is that we should be able to validate a signature that was
generated by a key pair that was generated under the previous
recommendations.

Russ

At 12:10 PM 2/20/2008, Turner, Sean P. wrote:

>Also, I'm not sure I've ever actually seen a 768-bit key in a 
>certificate - all I've seen for years now is 1024.
>
>spt
>

> >>>>  1024 bits can cause some older S/MIME receiving agents  to not 
> >>>> be able to verify signatures, but gives better  security and is
> >>>therefore