Re: [Fwd: I-D ACTION:draft-ietf-smime-3851bis-09.txt]

[Sean Turner <[e-mail]>]

I did receive some comments on this draft at the last second.  Two were 
on the key size text:

- SHOULD- on 1024-bit DSA key ought to be SHOULD
- In 4.3: 1023 <= key size <= 2048 : MUST   needs to be
           1024 <= key size <= 2048 : MUST

(this is the same rationale as for 3850bis) The 1st one I think is a 
good suggestion because SHOULD- on a key size doesn't seem to make much 
sense to me especially in the light of DSA with SHA-256 being a SHOULD+.

The 2nd one is editorial because we can't have two different 
requirements for the same key size.

I also received some other non-key size related comments:

- RSA-PSS should be replaced with RSASSA-PSS
- RSA-OAEP should be replaced with RSAES-OESP
- RSASA-PSS in references should be RSASSA-PSS
- Change noted to 3.2.2 not implemented and should also
   be applied to 3.6 (replace encrypted with enveloped)
- Rephrase the last sentence in the 2nd para of 2.3:

OLD:

As AES 128 CBC is the mandatory to implement content encryption 
algorithm thus, when DH ephemeral-static is supported, AES-128 key wrap 
algorithm MUST also be supported.

NEW:

As AES-128 CBC is the mandatory to implement content encryption 
algorithm, the AES-128 key wrap algorithm MUST also be supported when DH 
ephemeral-static is used

- Rephrase 1st sentence in 4th of Security Considerations

OLD:

The choice of 2048 bits as the RSA asymmetric key size in this 
specification is based on the desire to provide 100 bits of security.

NEW:

The choice of 2048 bits as the RSA asymmetric key size in this 
specification is based on the desire to provide 112 bits of security.

All but the last I consider editorial and will incorporate.  For the 
last one, instead of replacing 100 with 112 I'd like to make it say "at 
least 100 bits of security".  I think this is what we intended though 
technically a 2048-bit key size does offer 112 bits of security.

Unless there's strong objections to these resolutions I'll post a new 
version of this ID Friday afternoon for Tim to continue processing.

spt

Sean Turner wrote:
> 
> To date, I have received no comments on this version of the ID.
> 
> spt
> 
> Sean Turner wrote:
>> This ID incorporates comments necessary to resolve IESG DISCUSSES, one 
>> IETF LC comment I missed, and incorporates key size text from our Area 
>> Directory.  The changes were in some cases significant and as a result 
>> I'm asking for a one week comment period that will end 22 April 2009 @ 
>> 8am EST.
>>
>> spt
> 
>