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 <at> mail.imc.org 
| [mailto:owner-ietf-smime <at> mail.imc.org] On Behalf Of Paul Hoffman
| Sent: May 3, 2008 10:08 PM
| To: Turner, Sean P.; ietf-smime <at> imc.org
| 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.
|