RE: S/MIME v3.2 IDs key size text

["Turner, Sean P." <turners@xxxxxxxx>]

Tony,

There was a comment from Paul against the text you cite from 3850bis. He
objected to moving the lower bounds from 512 to 1024. I figured I'd post
both -02 drafts once we knocked this issue out.

spt

>-----Original Message-----
>From: Tony Capel [mailto:capel@xxxxxxxxxxx] 
>Sent: Monday, May 05, 2008 4:09 PM
>To: 'Paul Hoffman'; 'Turner, Sean P.'; ietf-smime@xxxxxxx
>Subject: RE: S/MIME v3.2 IDs key size text
>
>All:
>
>I agree that deleting " namely 1024 bits" from the first 
>sentence of the proposed security considerations section 
>paragraph is good.  The second "1024"
>in the proposed paragraph is not a problem for me since it is 
>not "normative".
>
>With respect to section 4.1 (Key Pair Generation).  Is it 
>intended to change the title of this section?  The second 
>paragraph of the current text in 3851bis-01.txt begins "If an 
>S/MIME agent needs to generate ...".  So if the S/MIME agent 
>does NOT need to generate keys (and this is typically the 
>case, most enrollment & key generation are done externally to 
>messaging clients) the balance of this paragraph (which 
>mentions the key sizes) is not normative (as currently drafted 
>- its quite possible that the last sentence of this paragraph 
>should have been in a separate paragraph).  Key generation 
>requirements are normally (hopefully!) cited in the 
>corresponding CP, where things such as required key sizes, 
>where they are generated (locally or at the CA), FIPS-140 
>Level, etc. should be (!!) explicitly identified.  Maybe the 
>second paragraph of
>4.1 could be replaced with a simple statement:
>
>"If an S/MIME agent needs to generate one or more key pairs, 
>each SHOULD be generated according to the corresponding 
>certificate policy, refer for example to [RFC3647]."
>
>The proposed text, and the discussion so far, is really 
>speaking about "what range of RSA key sizes" needs to be 
>supported.  We are NOT providing security advice, we are just 
>trying to ensure that most smime v3.2 implementations will 
>interwork in the typical environments expected "in the wild" 
>(and special environments will be understood by purchasers 
>anyway, so we likely need not worry about high security 
>applications - only the general "public"
>environments). 
>
>A similar issue is already addressed in CERT v3.2 ( 
>draft-ietf-smime-3850bis-01.txt ) in Section 4.3 for 
>certificate  validation.
>We might consider copying the last sentence of CERT v3.2 Sec 
>4.3 to the end of sections 2.2 and 2.3 (just before the Notes):
>
>   "Key sizes from 1024 bits to 2048 bits MUST be supported." 
>
>This would also have the advantage of aligning CERT and MSG.
>
>Tony
>
>
>| -----Original Message-----
>| From: owner-ietf-smime@xxxxxxxxxxxx
>| [mailto:owner-ietf-smime@xxxxxxxxxxxx] On Behalf Of Paul Hoffman
>| Sent: May 3, 2008 10:08 PM
>| To: Turner, Sean P.; ietf-smime@xxxxxxx
>| Subject: RE: S/MIME v3.2 IDs key size text
>| 
>| 
>| 
>| At 8:51 PM -0400 5/3/08, Turner, Sean P. wrote:
>| >I think if we struck ", namely 1024 bits" from the text in
>| the security
>| >considerations that it's still a true statement and we 
>won't have to 
>| >change it every time we update the spec.
>| 
>| I'm OK with that, but I also feel that if we're updating the minimum 
>| mandatory signing length, it is trivial to update the Security 
>| Considerations as well.
>| 
>