Name Constraints Extension

The Name Constraints extension indicates to the relying party what namespaces are acceptable for the various hierarchical name forms such as DN, DNS names, URL, IP address, RFC 822 names, UPN, etc. The extension is only valid for a CA certificate.

There are two components for this as defined in https://tools.ietf.org/html/rfc5280#section-4.2.1.10 as:

Permitted Subtree(s): This field in the Name Constraints extension defines what namespaces for a given name form are permitted. If a certificate contains a name in the Subject field or SAN (Subject Alternative Name) extension outside the permitted set for a name form, the certificate may be rejected. The absence of permitted subtree(s) for a given name form means any name for that name form is permitted.

Excluded Subtree(s): This field in the Name Constraints extension defines what namespaces for a given name form are NOT permitted. If a certificate contains a name in Subject or SAN inside the excluded set for a name form, the certificate must be rejected. The absence of excluded subtree(s) for a given name form means no name for that name form is excluded.

Let’s take a look at the naming constraints defined in a CA certificate and what happens when we try and break the rules by attempting to enroll for a certificate against what we defined. While not part of the standard, a CA may prevent issuing certificates that go against name constraints as illustrated below:

CA Certificate

In compliance. The certificate below complies with naming constraints for RFC822:

Enrollment Failure as “*.jivsec.com” for DNS is listed as excluded.

Path Validation failure as this enrolled certificate does not adhere to the name constraints.

Enforcement
The enforcement of name constraints occurs at the relying party end during certification path validation as defined in https://tools.ietf.org/html/rfc5280#section-6.
On a high level:

1. If any of the names in the certificate does not fall in the permitted set for a given name form, the certificate may be rejected.
2. If any of the names in the certificates falls in an excluded set for a given name form, the certificate is rejected.  It’s important to note that the certificate must be rejected even if the name falls in the permitted set.

When would you use?

• While there are several use cases here are a couple examples:
  Preventing wildcards and subdomains – Depending on use case there are risks associated with wild cards i.e., creating new websites that could leverage the same certificate, difficulty with monitoring, etc. CA Administrators can configure name constraints for applications to prevent issuance of certificates containing the specific namespace within the certificate.
• Cross-certification – You can constrain a cross-certified PKI or subordinate PKI for name space that is appropriate for that PKI. Let’s say a company cross certifies another company, you can constrain the other company for its name spaces or if you want to constrain a subordinate division PKI to the subordinate division name space, you can do that as well.

Detail on defining and processing.
Additional detail on items such as how Permitted/Excluded subtree(s) are processed and defined can be found here X.509 Name Constraints certificate extension – all you should know – PKI Extensions (sysadmins.lv)

How do you implement this?
My next blog article will be a part 2 in which I will demonstrate a couple different methods to implement Name Constraints. Stay tuned!