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
Blake Ramsdell wrote:
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