RE: Key Sizes in S/MIME v3.2

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.

I'll move the 768 back to 512 as suggested by Simon.

spt
> -----Original Message-----
> From: Russ Housley [mailto:housley(_at_)vigilsec(_dot_)com] 
> Sent: Wednesday, February 20, 2008 9:16 AM
> To: Turner, Sean P.
> Cc: ietf-smime(_at_)imc(_dot_)org
> 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: 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: Tuesday, February 19, 2008 1:42 PM
> > > To: Turner, Sean P.; ietf-smime(_at_)imc(_dot_)org
> > > 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?