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.
|