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

From: Sean Turner <[email-masked]>
Date: Tue, 14 Apr 2009 15:32:41 -0400

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

Subject: I-D ACTION:draft-ietf-smime-3851bis-09.txt
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Date: Tue, 7 Apr 2009 13:45:01 -0700 (PDT)
List-Id: <ietf-smime.imc.org>

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification
	Author(s)	: B. Ramsdell, S. Turner
	Filename	: draft-ietf-smime-3851bis-09.txt
	Pages		: 45
	Date		: 2009-4-7
	
This document defines Secure/Multipurpose Internet Mail Extensions 
   (S/MIME) version 3.2.  S/MIME provides a consistent way to send and 
   receive secure MIME data.  Digital signatures provide authentication, 
   message integrity, and non-repudiation with proof of origin. 
   Encryption provides data confidentiality.  Compression can be used to 
   reduce data size.  This document obsoletes RFC 3851.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-3851bis-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Sean Turner <[email-masked]>
Date: Tue, 21 Apr 2009 08:30:44 -0400

To date, I have received no comments on this version of the ID.

spt

---

From: Sean Turner <[email-masked]>
Date: Thu, 23 Apr 2009 16:43:16 -0400

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