-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of David P.
Kemp
Sent: Tuesday, February 24, 2004 2:26 PM
To: Blake Ramsdell
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt
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 ..."
Fixed.
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.
Fixed.
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.
I worry about this one, and did not change it. This is a material
softening of the language from PKIX. This has a serious impact on
implementations because it would force all CA certificates to be v1
certificates. I am fairly certain that the self-signed roots for many
current CAs (which I think fit in the definition of "CA certificates")
are v1 certificates, and thus cannot have this extension.
Blake