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

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

Tony,

Inline...

spt

>-----Original Message-----
>From: owner-ietf-smime@xxxxxxxxxxxx 
>[mailto:owner-ietf-smime@xxxxxxxxxxxx] On Behalf Of Tony Capel
>Sent: Monday, May 05, 2008 5:34 PM
>To: 'Turner, Sean P.'; 'Paul Hoffman'; ietf-smime@xxxxxxx
>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@xxxxxxxxxxxx
>| [mailto:owner-ietf-smime@xxxxxxxxxxxx] On Behalf Of Turner, Sean P.
>| Sent: May 5, 2008 4:58 PM
>| To: 'Tony Capel'; 'Paul Hoffman'; ietf-smime@xxxxxxx
>| 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@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.
>| >| 
>| >
>| 
>