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

From: "Blake Ramsdell" <[email-masked]>
Date: Wed, 5 May 2004 22:08:56 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David P. Kemp
> Sent: Tuesday, February 24, 2004 2:26 PM
> To: Blake Ramsdell
> Cc: [email-masked]
> 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

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 07 May 2004 11:04:58 -0400

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

---

From: Russ Housley <[email-masked]>
Date: Fri, 07 May 2004 13:56:06 -0400

I agree with Dave Kemp's proposed text.

Russ