Subject: RFC 3280 bug in name constraints

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 5 May 2004 22:07:19 +0100

If someone is keeping record of bugs for future update of RFC 3280 I
have a small one to file about name constraints.

In section 4.2.1.11, starting at bottom of page 38:

   When rfc822 names are constrained, but the

   certificate does not include a subject alternative name, the rfc822

   name constraint MUST be applied to the attribute of type EmailAddress

   in the subject distinguished name.

Suppose/suggest that the intended meaning is:

   When rfc822 names are constrained, but the certificate does not 

   include an rfc822Name in a subject alternative name extension, the
rfc822

   name constraint MUST be applied to the attribute of type EmailAddress

   in the subject distinguished name.

Rationale:

Why would the constraint NOT apply to EmailAddress just because there is
a SubjAltName extension with e.g. just some unrelated other name
component present?

/Stefan

---

From: Steve Hanna <[email-masked]>
Date: Thu, 06 May 2004 10:35:08 -0400

I agree. In fact, I don't see why you wouldn't
apply name constraints to an EmailAddress attribute
in a subject DN even if there *is* an rfc822Name
in a subject alternative name. I suggest that
the text be revised to say:

    An rfc822 name constraint MUST be applied to an
    attribute of type EmailAddress in the subject
    distinguished name.

However, I'm willing to back down on this if
people feel it's too strict. My concern is that
a certificate with an email address in the
subject DN prohibited by name constraints will
be allowed because it also contains a permissible
email address in the subject alternative name.
I suspect many applications will not understand
this and will accept the email address in the
subject DN. In fact, RFC 2632 and its successor
don't contain any warning about this.

Thanks,

Steve

Stefan Santesson wrote:
>    include an rfc822Name in a subject alternative name extension, the rfc822
>