Attributed metadata history

VU#573195: Go, OpenSSL, Apple, LibreSSL, pyca, wolfSSL Name-Constraint Inconsistency in RFC 5280 Implementation

Overview This note covers differences in how TLS libraries interpret X.509 Name Constraints. A certificate that one library accepts may be rejected by another. Some of those differences are defects; others follow from behavior that RFC 5280 does not fully specify. Description The observed differences concern DNS name comparison, IP address handling, URI-authority parsing, and wildcard matching. These include both implementation defects and behavior not fully specified by RFC 5280. DNS-name comparison. RFC 5280 requires case-insensitive matching for DNS names. GnuTLS compared some names' case-sensitivity at the time of reporting (CVE-2026-3833, later fixed in 3.8.13). A distinct Go report concerns case handling in wildcard parent-constraint lookup, not ordinary hostname comparison. IP address handling. RFC 5280 defines separate IPv4 and IPv6 encodings and does not say whether IPv4-mapped IPv6 addresses should be treated as IPv4. Some libraries treat the two forms as different, so a constraint written for one form may not apply to the other. URI-authority parsing. RFC 3986 allows optional userinfo before the host. Implementations differ on which host they extract when @, a colon, or a query or fragment is present. OpenSSL merged PR #30319 for an @ in the path, query, or fragment; a separate userinfo-colon report is not covered by that confirmation. Related differences have been reported in other libraries. A well-formed single @ is handled per RFC 3986 by most implementations. Wildcard matching. RFC 5280 does not define wildcard SAN semantics. Wildcard-related reports include LibreSSL and wolfSSL. pyca/cryptography checked DNS Name Constraints against certificate SANs but not the requested peer name (CVE-2026-34073, fixed in 46.0.6), as described in the linked vendor advisory. These differences come from independent design choices. Where the RFC is clear, some reports describe defects; where it is silent, disagreement is expected. No single library should be assumed correct for every deployment. Impact An attacker would need a trusted signature over chosen certificate fields, a reachable affected validation path, and an application that uses the accepted identity for authorization. Validator disagreement alone does not establish exploitation. Mixed service-mesh, CDN, or enterprise PKI environments may see different results for the same certificate. Detection is difficult because the certificate can be validly signed. Solution CERT/CC is coordinating with the affected projects: * Go's crypto/x509 * Apple's Security.framework * OpenSSL* * LibreSSL * pyca/cryptography * wolfSSL Operators who need high-assurance Name Constraints should test the validator they currently run against their deployment requirements, apply available updates, and keep leaf certificates to explicit SANs (Subject Alternative Names). A second validator helps only when it uses the same inputs and fails closed. Issuance policy and application-layer allow-lists remain useful complements where libraries differ. Acknowledgements Thanks to Oleh Konko for discovering and reporting these issues. This document was prepared with AI assistance by Timur Snoke. Supporting materials include test corpus v3.0.1 and VENDOR_MATRIX_2026-09-06.json (available to case participants; public links will follow agreed disclosure arrangements).

This record contains metadata and attribution only. It does not host, download, unpack, render, or execute malware samples.