Subject: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt

From: "Blake Ramsdell" <[email-masked]>
Date: Sun, 22 Feb 2004 17:31:11 -0800

This message initiates an SMIME Working Group Last Call on the document:

	Title		: S/MIME Version 3.1 Certificate Handling
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-rfc2632bis-05.txt
	Pages		: 13
	Date		: 2004-2-17

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

The purpose of this WG Last Call is to ensure that the Working Group has
achieved consensus that the document is suitable for publication as a
Proposed Standard.

Please review the document for both technical and editorial problems.
Technical issues should be discussed on this list.  Editorial issues may
be sent to the document editor.

The Last Call period will end on Monday, March 8, 2004.

Upon completion of the last call, the WG chairs will take action based
upon the consensus of the WG. Possible actions include:

   1) recommending to the IETF Security Area Directors
      that the document, after possible editorial or
      other minor changes, be considered by the IESG
      for publication as a Standard Track RFC
      (which generally involves an IETF-wide Last Call); or

   2) requiring that outstanding issues be adequately
      addressed prior to further action (including,
      possibly, another WG Last Call).

Remember that it is our responsibility as Working Group members to
ensure the quality of our documents and of the Internet Standards
process.  So, please read and comment!

Blake
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com

---

From: "David P. Kemp" <[email-masked]>
Date: Tue, 24 Feb 2004 17:25:59 -0500

Blake,

Thanks for clarifying the requirement to support certificates
without email addresses.

Comments:

1.  Section 2.3 para 4: "Agents MAY send CA certificates, that is,
certificates that are self-signed and can be considered the "root"
of other chains."   This incorrectly implies that the only kind
of CA cert is the self-signed kind.  Suggest "Agents MAY send
CA certificates that are self-signed and ..."

2.  Section 4.4 paragraph 2: Why must sending and receiving
agents correctly handle the listed extensions only when they
appear in end-entity certificates?  Suggest that sending and
receiving agents MUST correctly (i.e. in accordance with RFC 3280)
handle the basic constraints, key usage, AKI, SKI, and SAN extensions
in end-entity *and CA* certificates.

3.  Section 4.4.1 paragraph 3: "Certificates SHOULD contain a
basicConstraints extension in CA certificates and SHOULD NOT contain
that extension in end entity certificates."  In order to avoid
inconsistency with PKIX, change to "Certificates MUST contain a
basicConstraints extension in CA certificates and SHOULD NOT contain
that extension in end entity certificates."  In other words, a
sending and receiving agent is non-compliant if it accepts
a v3 certificate without the basicConstraints extension as a CA
certificate.

Dave