in crypto/x509, parseNameConstraintsExtension parses each GeneralSubtree by reading only the base GeneralName and discarding any remaining fields in the inner SEQUENCE. as a result, a critical name constraints extension that includes minimum and/or maximum is accepted without error.
per RFC 5280 section 4.2.1.10, GeneralSubtree uses a strict profile for these fields (e.g. “minimum MUST be zero” and “maximum MUST be absent”), and if an application encounters a critical name constraints extension with other values it “MUST either process these fields or reject the certificate”. since crypto/x509 does not implement minimum/maximum semantics, the conformant behavior for critical extensions is to reject when these fields are present.
callsite: src/crypto/x509/parser.go in parseNameConstraintsExtension (as of a3688ab13e76762a168f43e91ca9422c847ee896), after parsing base from the GeneralSubtree SEQUENCE, remaining bytes are not checked.
expected: reject certificates with critical name constraints where any GeneralSubtree contains minimum/maximum (or more generally, where the GeneralSubtree SEQUENCE is not empty after parsing base).
actual: the certificate parses and x509.Verify succeeds even when minimum/maximum are present in the encoding.
proposed fix: after reading base, if the extension is critical and the inner SEQUENCE is not empty (!seq.Empty()), return an error (optionally, parse minimum and allow only 0, and always reject any maximum). this is a conformance/strictness improvement; it has no security impact because these fields have no defined semantics.
in
crypto/x509,parseNameConstraintsExtensionparses eachGeneralSubtreeby reading only thebaseGeneralNameand discarding any remaining fields in the innerSEQUENCE. as a result, a critical name constraints extension that includesminimumand/ormaximumis accepted without error.per RFC 5280 section 4.2.1.10,
GeneralSubtreeuses a strict profile for these fields (e.g. “minimum MUST be zero” and “maximum MUST be absent”), and if an application encounters a critical name constraints extension with other values it “MUST either process these fields or reject the certificate”. sincecrypto/x509does not implementminimum/maximumsemantics, the conformant behavior for critical extensions is to reject when these fields are present.callsite:
src/crypto/x509/parser.goinparseNameConstraintsExtension(as ofa3688ab13e76762a168f43e91ca9422c847ee896), after parsingbasefrom theGeneralSubtreeSEQUENCE, remaining bytes are not checked.expected: reject certificates with critical name constraints where any
GeneralSubtreecontainsminimum/maximum(or more generally, where theGeneralSubtreeSEQUENCEis not empty after parsingbase).actual: the certificate parses and
x509.Verifysucceeds even whenminimum/maximumare present in the encoding.proposed fix: after reading
base, if the extension is critical and the innerSEQUENCEis not empty (!seq.Empty()), return an error (optionally, parseminimumand allow only0, and always reject anymaximum). this is a conformance/strictness improvement; it has no security impact because these fields have no defined semantics.