IETF Logo Mail Archive

Re: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt

Russ Housley <housley@vigilsec.com> Mon, 01 March 2004 05:48 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06991 for <smime-archive@lists.ietf.org>; Mon, 1 Mar 2004 00:48:03 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i215GQlL087936; Sun, 29 Feb 2004 21:16:26 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i215GP8N087935; Sun, 29 Feb 2004 21:16:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i215GOL7087929 for <ietf-smime@imc.org>; Sun, 29 Feb 2004 21:16:25 -0800 (PST) (envelope-from housley@vigilsec.com)
Received: (qmail 24615 invoked by uid 0); 1 Mar 2004 05:13:11 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (218.37.227.193) by woodstock.binhost.com with SMTP; 1 Mar 2004 05:13:11 -0000
Message-Id: <5.2.0.9.2.20040229235313.01f8f318@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 01 Mar 2004 00:16:27 -0500
To: Blake Ramsdell <blake@brutesquadlabs.com>, ietf-smime@imc.org
From: Russ Housley <housley@vigilsec.com>
Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50S wK3EZjypY2MKAAAAQAAAAAAi98FZ4k0O8A68DLlOuMwEAAAAA@brutesquadlabs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

Hare are seven comments.  I think number 6 is the most significant one, but 
none of them are show stoppers.

1.  Should Section 1.4 reference RFC 3369?

2.  Delete section 1.6 before the document is sent to the IESG.

3.  Section 2.4 probably should point out that ContentInfo is needed to 
encapsulate each of the protection content types.

4.  What compression algorithm MUST be implemented if CompressedData is 
supported?

5.  Section 2.5.2: s/SMIMECapabilities attribute should/SMIMECapabilities 
attribute SHOULD/

6.  Section 2.6:  the first two paragraphs are not clear.  S/MIME v3.1 MUST 
support both issuerAndSerialNumber and subjectKeyIdentifier for sending and 
receiving.

7.  Section 3.4.3.2: s/not currently supported in S/MIME/not currently 
recommended in S/MIME/

Russ

v2.23.0 | Report a Bug | By Email