Subject: Question about implementation of name constraints

From: Russ Housley <[email-masked]>
Date: Fri, 19 Sep 2008 16:15:54 -0400

First I want to provide some background from RFC 5280, then I have a 
three-part question for implementors.

In Section 4.2, we learn that the name constraints extension MUST be 
recognized:

     At a minimum, applications conforming to this profile MUST recognize
    the following extensions: key usage (Section 4.2.1.3), certificate
    policies (Section 4.2.1.4), subject alternative name (Section
    4.2.1.6), basic constraints (Section 4.2.1.9), name constraints
    (Section 4.2.1.10), policy constraints (Section 4.2.1.11), extended
    key usage (Section 4.2.1.12), and inhibit anyPolicy (Section
    4.2.1.14).

Then, in Section 4.2.1.10 we learn that the name constraints 
extension MUST only appear in CA certificates and that the 
constraints apply to both the subject name and the subject alt name:

    The name constraints extension, which MUST be used only in a CA
    certificate, indicates a name space within which all subject names in
    subsequent certificates in a certification path MUST be located.
    Restrictions apply to the subject distinguished name and apply to
    subject alternative names.  Restrictions apply only when the
    specified name form is present.  If no name of the type is in the
    certificate, the certificate is acceptable.

We also learn that the name constraints extension MUST be critical:

    ... Conforming CAs MUST mark this extension as
    critical and SHOULD NOT impose name constraints on the x400Address,
    ediPartyName, or registeredID name forms. ...

Section 4.2.1.10 also has some requirements for applications that use 
the certificate:

    Applications conforming to this profile MUST be able to process name
    constraints that are imposed on the directoryName name form and
    SHOULD be able to process name constraints that are imposed on the
    rfc822Name, uniformResourceIdentifier, dNSName, and iPAddress name
    forms.  If a name constraints extension that is marked as critical
    imposes constraints on a particular name form, and an instance of
    that name form appears in the subject field or subjectAltName
    extension of a subsequent certificate, then the application MUST
    either process the constraint or reject the certificate.

So, now my question to implementors.  I'm trying to find out what 
will really happen if a CA tries to use name constraints to constrain 
a domain name.

If your implementation encounters a certification path where one or 
more of the CA certificates includes a critical name constraints 
extension, will the implementation accept the certification path or 
reject it when:

(a) the directoryName form is constrained using the domainComponent attribute?

(b) the dNSName form is constrained?

(c) the uniformResourceIdentifier is constrained to a particular domain name?

For (b) and (c), I'm assuming the  following parts of RFC 5280 are followed:

    For URIs, the constraint applies to the host part of the name.  The
    constraint MUST be specified as a fully qualified domain name and MAY
    specify a host or a domain.  Examples would be "host.example.com" and
    ".example.com".  When the constraint begins with a period, it MAY be
    expanded with one or more labels.  That is, the constraint
    ".example.com" is satisfied by both host.example.com and
    my.host.example.com.  However, the constraint ".example.com" is not
    satisfied by "example.com".  When the constraint does not begin with
    a period, it specifies a host.  If a constraint is applied to the
    uniformResourceIdentifier name form and a subsequent certificate
    includes a subjectAltName extension with a uniformResourceIdentifier
    that does not include an authority component with a host name
    specified as a fully qualified domain name (e.g., if the URI either
    does not include an authority component or includes an authority
    component in which the host name is specified as an IP address), then
    the application MUST reject the certificate.

    DNS name restrictions are expressed as host.example.com.  Any DNS
    name that can be constructed by simply adding zero or more labels to
    the left-hand side of the name satisfies the name constraint.  For
    example, www.host.example.com would satisfy the constraint but
    host1.example.com would not.

Thanks for your help in advance,
   Russ

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 25 Sep 2008 05:20:16 +1200

Russ Housley <[email-masked]> writes:

>If your implementation encounters a certification path where one or more of
>the CA certificates includes a critical name constraints extension, will the
>implementation accept the certification path or reject it when:
>

Hmm, I'm not sure if I understand the question correctly but if you're asking
"will you apply name constraints from CA -> subject certs" then the answer is
"yes".

Peter.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 25 Sep 2008 02:04:44 +0100

Russ, here are some answers for Microsoft CAPI

> (a) the directoryName form is constrained using the domainComponent

If directoryName is constrained, then this does only constrain directoryName. It will not constrain any rfc822Name, URI or dNSName.

> (b) the dNSName form is constrained?

Then this will constrain dNSName

> (c) the uniformResourceIdentifier is constrained to a particular domain

Then this will constrain URIs

> For (b) and (c), I'm assuming the  following parts of RFC 5280 are
> followed (Leading dot = alows subsomain. no leading dot = host):

Yes, this logic is implemented.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Russ Housley
> Sent: den 19 september 2008 22:16
> To: [email-masked]
> Subject: Question about implementation of name constraints
>
>