]> OpenSSL

beck@obtuse.com

Cryptic Forest Software

mike@ounsworth.ca

Security LAMPS TLS PKIX X.509 name constraints The interaction of name constraint matching in and wildcard subject alternative names creates a gap in which an excluded name constraint cannot be relied upon to prevent the issuance of certificates usable for the excluded name. This document defines End Entity Name Restrictions (EENR), a new critical X.509 extension for CA certificates that constrains the dNSName Subject Alternative Name entries which may appear in end entity certificates issued beneath the CA. EENR specifies its own matching semantics, including for wildcard dNSName entries, so that it does not depend on application-defined interpretations. The extension is scoped to use in certificate path validation for TLS client and TLS server authentication. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the LAMPS Working Group mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction X.509 name constraints, defined in section 4.2.1.10, allow a CA certificate to restrict the names that may appear in any certificate beneath it in a certification path. Enforcement is performed during certification-path validation, per sections 6.1.3 and 6.1.4. For dNSName SubjectAlternativeName entries, 's matching algorithm is purely lexical: "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." Read literally, this treats * as an ordinary label and makes *.example.com satisfy a constraint of example.com exactly as host.example.com does. section 4.2.1.6 separately leaves the semantics of wildcards in subject alternative names undefined, requiring any application that uses them to define the semantics itself. supplies wildcard semantics for one application context, matching presented identifiers against reference identifiers in TLS, but its section 1.2 explicitly defers name constraints back to , creating a situation where neither specification defines its semantics. Name constraints can be used as either inclusionary or exclusionary. For example, consider a CA certificate with an excluded constraint of foo.example.com, signing an end entity certificate with a SAN of *.example.com. The apparent intent of the constraint is to prevent that CA from issuing certificates usable as foo.example.com. The SAN does not fall within the excluded subtree under 's matching, and the certificate passes name-constraint validation. The resulting end entity certificate can then be presented to TLS clients as the server identity for foo.example.com: section 6.3 defines *.example.com as a valid presented identifier matching the reference identifier foo.example.com. The constraint does what prescribes: it rejects a literal SAN of foo.example.com. It does not, however, prevent the CA from issuing certificates that can be used as foo.example.com. A future specification that defines wildcard semantics for name constraint matching cannot remedy this for the general case. Implementations conforming to as written today would remain conformant when applying the literal algorithm indefinitely, and any verifier predating such a clarification would continue to do so. Unless the CA can constrain its certificates to verifiers known to apply specific semantics, it cannot ensure that the verifiers eventually consuming them share any single interpretation. Criticality does not remedy this: deferred the wildcard portion of nameConstraints semantics, so the meaning of this critical extension can change without changing , and a verifier processing it conformantly may be applying semantics no longer current. A PKI that depends on excludedSubtrees for security therefore cannot rely on those exclusions being enforced consistently across the verifiers that will see its certificates. This document defines End Entity Name Restrictions (EENR), a new critical extension for CA certificates that constrains the dNSName Subject Alternative Names which may appear in end entity certificates issued beneath the CA. EENR is scoped exclusively to TLS client and TLS server authentication; this document does not address the analogous ambiguity for other application protocols that use X.509 certificates with dNSName SANs. Confining the extension to TLS allows its matching semantics to be specified completely within this document.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

The End Entity Name Restrictions Extension

Syntax The End Entity Name Restrictions extension is identified by the following object identifier: id-pe-eenr OBJECT IDENTIFIER ::= { TBD } The extension SHALL be encoded as follows: EndEntityNameRestrictions ::= SEQUENCE { permittedSubtrees [0] GeneralSubtrees OPTIONAL, excludedSubtrees [1] GeneralSubtrees OPTIONAL } The GeneralSubtrees, GeneralSubtree, and BaseDistance types are defined in section 4.2.1.10 and are reused here without modification. The base field of each GeneralSubtree MUST be of type dNSName; the use of any other general-name type renders the extension malformed. The minimum field of each GeneralSubtree MUST be 0 and the maximum field MUST be absent, matching the constraint that places on use of GeneralSubtree in the nameConstraints extension. The IANA registration request for id-pe-eenr appears in .

Use in CA Certificates The End Entity Name Restrictions extension MUST be used only in a CA certificate; it is an error to include it in a certificate with basicConstraints.cA=FALSE. Conforming CAs MUST mark the extension as critical. Both permittedSubtrees and excludedSubtrees are OPTIONAL. If both are absent, the extension is present but conveys no name-space restriction; the restrictions on end entity certificates defined in still apply by virtue of the extension's presence anywhere in the certification path. If permittedSubtrees is provided, it MUST contain at least one entry; if excludedSubtrees is provided, it MUST contain at least one entry. The dNSName value carried in the base field of each GeneralSubtree MUST NOT contain the DNS wildcard character *.

Propagation Through CA Certificates This extension is designed so that delegation can only narrow, never widen, the names a CA may authorize in subsequent end entity certificates. The propagation rules below require every CA certificate beneath an EENR-bearing CA to carry the cumulative restriction set in its own extension. If a CA certificate contains the End Entity Name Restrictions extension, every CA certificate that it issues, directly or transitively, MUST also contain the extension. Where the issuer's extension contains permittedSubtrees, the issued CA's extension MUST also contain permittedSubtrees. The issued CA's list MUST be equal to or a subset of the issuer's list; that is, every entry MUST be contained, per section 4.2.1.10, in some entry of the issuer's list. Entries MAY be omitted to narrow the permitted name space. Where the issuer's extension contains excludedSubtrees, the issued CA's extension MUST also contain excludedSubtrees. The issued CA's list MUST be equal to or a superset of the issuer's list; that is, every entry of the issuer's list MUST be contained, per section 4.2.1.10, in some entry of the issued CA's list. Additional entries MAY be added to broaden the excluded name space. A verifier MUST reject any certification path whose CA certificates do not satisfy these propagation rules.

Relationship to RFC 5280 Name Constraints The matching semantics defined by this document for dNSName entries differ from those of section 4.2.1.10, and a certification path that combines both would be subject to the matching ambiguity this extension is designed to eliminate. To avoid that, in any certification path containing the End Entity Name Restrictions extension, a CA certificate in that path MUST NOT include a nameConstraints extension whose permittedSubtrees or excludedSubtrees contains a dNSName form. A verifier MUST reject any certification path that violates this restriction.

Restrictions on End Entity Certificates When the End Entity Name Restrictions extension is present in any CA certificate in a certification path, every end entity certificate in that path MUST satisfy each of the following restrictions:

• The subject distinguished name MUST NOT contain a commonName (CN) attribute.
• The extended key usage extension MUST be present and MUST contain exactly one of the following key purpose identifiers, and no other:
  • id-kp-serverAuth (1.3.6.1.5.5.7.3.1) for TLS server authentication, or
  • id-kp-clientAuth (1.3.6.1.5.5.7.3.2) for TLS client authentication.
• The subject alternative name extension MUST be present and MUST contain at least one dNSName entry. The number of dNSName entries SHOULD NOT exceed 16; conforming applications MAY reject certificates with more to prevent denial-of-service.
• Each dNSName entry in the subject alternative name extension MUST conform to section 6.3.

A verifier MUST reject any certification path containing an end entity certificate that fails any of these restrictions.

Matching Semantics The End Entity Name Restrictions extension that applies to a given end entity certificate is the one carried by its immediate issuer. Because of the propagation rules in , that extension expresses the complete cumulative set of restrictions from the entire path above; no walking of the certification path is required. For each dNSName entry present in the end entity certificate's subject alternative name extension, the verifier MUST evaluate the restrictions in the immediate issuer's extension as follows:

• If permittedSubtrees is present, the dNSName entry MUST match at least one of those permitted subtree base values.
• For every entry in excludedSubtrees, the dNSName entry MUST NOT match that excluded subtree base value.

An excluded subtree base value (which contains no wildcard) is treated as the reference identifier, and the end entity certificate's dNSName entry (which is allowed to contain a wildcard in its leftmost label) as the presented identifier, with the wildcard semantics as per section 6.3. A permitted subtree base value (which contains no wildcard) is treated as the reference identifier, and the end entity certificate's dNSName entry (which is allowed to contain a wildcard in its leftmost label) as the presented identifier, as per section 6.3, excluding the wildcard semantics, meaning the wildcard label has no special meaning other than as a literal label. A verifier MUST reject any certification path for which a dNSName entry fails this evaluation.

Security Considerations The End Entity Name Restrictions extension is a critical X.509 extension. A verifier processing a certification path containing the extension either implements the matching semantics defined here exactly or rejects the path; no third option exists in which the extension is silently misinterpreted. This is what allows a CA to rely on it as a security control restricting the dNSName Subject Alternative Names in end entity certificates issued beneath it, for purposes of TLS client and TLS server authentication.

IANA Considerations This document defines one new object identifier for the End Entity Name Restrictions extension. IANA is requested to assign a value from the "SMI Security for PKIX Certificate Extension" registry (1.3.6.1.5.5.7.1) for the OID label id-pe-eenr. The assigned value is to be substituted for the placeholder in .

Decimal	Description	References
TBD	id-pe-eenr	this document

The reference in the table is to be replaced with the published RFC number upon publication.

References Normative References This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions. This document obsoletes RFC 6125. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References OpenSSL

Alternatives Considered

Amending RFC 5280 or RFC 9525 to define wildcard semantics The wildcard ambiguity could in principle be addressed by an update to section 4.2.1.10's matching algorithm, or by an update to to extend its wildcard semantics to name constraint matching (which section 1.2 currently defers to ). Either approach fails to give a CA reliable control over how its certificates will be evaluated. A verifier conforming to the specification as written today is not made non-conformant by any future update; a CA issuing a certificate cannot ensure that the verifiers consuming it have adopted the updated semantics, and would have no way to detect a verifier still applying the original algorithm.

Amending RFC 5280 with a critical marker extension The wildcard matching semantics defined in this draft could instead be defined in an update to section 4.2.1.10, paired with a new critical extension that a CA places in its certificates to require those updated semantics. A verifier that has not adopted the update does not recognize the marker and rejects the certificate as critical-and-unknown; a verifier that has adopted it applies the new matching to the existing nameConstraints extension. This gives the same enforcement guarantee as EENR without introducing a parallel constraint extension, at the cost of an revision. This approach could not deliver the end-entity hygiene improvements described in . It also commits to a single wildcard matching algorithm across every protocol that uses dNSName name constraints, on the assumption that 's semantics are appropriate for all of them.

Prohibiting wildcards in chains with excluded dNSName constraints The security failure caused by the matching ambiguity arises only when both wildcard dNSName SAN entries and dNSName excludedSubtrees are present in the same certification path: literal matching can accept a wildcard SAN whose TLS expansion covers a name the excluded subtree was intended to prevent. An amendment could prohibit this combination. Such an amendment suffers the same deployment problem as defining new semantics: a verifier that has not adopted it will not enforce the prohibition. Certificates issued under the old understanding remain vulnerable in proportion to the verifier population that has not been updated.

Just don't fix it Acknowledge the possibility that with the default matching semantics, wildcards will not match names in an excluded subtree name constraint that could in turn match the wildcard and be accepted for a TLS connection. Document that excluded name constraints should not be relied on to limit what a CA can sign for in any PKI where wildcards are not excluded from use by some other means. This is currently the approach being taken in . The limitation of this is that certificates used for TLS in the presence of wildcards may only be constrained reliably by using only permitted subtree entries.

Acknowledgments TODO acknowledge.