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

From: "Denis Pinkas" <[email-masked]>
Date: Wed, 20 Feb 2008 11:24:35 +0100

>Sean:
>
>> 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.
>
>s/buts/bits/
>
>>Should we put a MUST NOT or SHOULD NOT in for key sizes smaller than 1024?
>
>I think we ought to be forgiving on receive.  Thus, I suggest:
>Message originators SHOULD NOT use key sizes smaller than 1024 bits 
>for private key operations.

Recommendations for key sizes depend on the usage of the key.

If the private key is to be used to sign data in the context of an authentication service 
or a non repudiation service, then the private key shall resist during the validity 
period of the certificate (usually one to three years). 

If the key size has been chosen too small, there is no security breach: 
it is only needed to revoke the certificate.

If the private key is to be used to decrypt data, than the key should resist 
as long as the encrypted data should be kept confidential. 

RFC 3161 is using S-MIME. If the key is to be used for a Time Stamping Unit (TSU), 
it had better to resist quite longer and 2048 bits would be recommended. 

These kinds o recommendations should be included in the security considerations section.

As far as interoperability is concerned the current text is:
"A user agent SHOULD generate RSA key pairs at a minimum key size of 768 bits".

This key size is still safe for authentication and non repudiation and thus 
there is no reason to raise this value.

>Russ

Denis

---

From: Russ Housley <[email-masked]>
Date: Wed, 20 Feb 2008 09:09:29 -0500

>"A user agent SHOULD generate RSA key pairs at a minimum key size of 

This statement is in conflict with the consensus call that the WG 

Russ