Sean:
Agreed, the text in 3850bis and 3851bis needs to align. I have no problems with
support for smaller key sizes.
I expect constraints on key size to be implemented by the certificate issuer
anyway. If you get a 512 key in a cert you trust you must be able to use it,
no?
Tony
| -----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 Turner,
Sean P.
| Sent: May 5, 2008 4:58 PM
| To: 'Tony Capel'; 'Paul Hoffman'; ietf-smime(_at_)imc(_dot_)org
| Subject: RE: S/MIME v3.2 IDs key size text
|
|
|
| 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(_at_)comgate(_dot_)com]
| >Sent: Monday, May 05, 2008 4:09 PM
| >To: 'Paul Hoffman'; 'Turner, Sean P.'; ietf-smime(_at_)imc(_dot_)org
| >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(_at_)mail(_dot_)imc(_dot_)org
| >| [mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Paul
Hoffman
| >| Sent: May 3, 2008 10:08 PM
| >| To: Turner, Sean P.; ietf-smime(_at_)imc(_dot_)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.
| >|
| >
|