ietf-smime
[Top] [All Lists]

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

2004-05-07 08:05:19

Blake,

The intent wasn't to prohibit the use of v1 CA certificates; they
should be accepted.  The intent was for v3 certificates to align
with PKIX, where both basic constraints and key usage extensions
MUST be present in order to validate signatures on certificates
(i.e. be accepted as a CA).

I don't agree with PKIX; my personal opinion is that key usage
is necessary and sufficient, and basic constraints is just worthless
clutter unless the optional pathLenConstraint field is needed.
However, basic constraints is a MUST in RFC 3280 CA certificates,
and S/MIME applications should not accept certificates that are
not PKIX-conforming.

It would be best to delete Section 4.4.1 entirely, falling
back on section 4.4's "Interpretation and syntax for all
extensions MUST follow [KEYM], unless otherwise specified here."

But if RFC 2632bis does specify something about basic
constraints, that something may refine the meaning
of [KEYM] (RFC 3280), but should not conflict with it:

"Version 3 certificates MUST contain a basicConstraints extension
in CA certificates and SHOULD NOT contain that extension in end-
entity certificates."


Regards,
Dave



Blake Ramsdell wrote:

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