Tony,
Inline...
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 Tony Capel
Sent: Monday, May 05, 2008 5:34 PM
To: 'Turner, Sean P.'; 'Paul Hoffman'; ietf-smime(_at_)imc(_dot_)org
Subject: RE: S/MIME v3.2 IDs key size text
Sean:
Agreed, the text in 3850bis and 3851bis needs to align. I
have no problems with support for smaller key sizes.
You got it. I was just trying to say we need to keep the two algined.
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?
Originally, I thought the answer really was no, but I think for interop with
v3 and v3.1 we need to say yes. If you get a 512 key in a cert from a source
you trust, then you can decide to not use it but it's not because you don't
trust the source it's because of some other reason. I can see where maybe
short lived certs are used because the info gets stale quickly, they need to
sign/verify really quickly, etc. I am a little concerned about the FIP-140
issue though.
Just a thought ... since we've now got a way to indicate + and - with
requirements should we apply it the key sizes in 3850bis? That way people
will have a hint that in the next update the shorter keys will likely become
not so welcome and large keys more so?
0 < key size < 511 : MUST NOT
512 < key size < 1023 : SHOULD-
1024 < key size < 2048 : MUST
2049 < key size < 4096 : MAY
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.
| >|
| >
|