I would like to request for the adoption of change 3230 which is in code review for a long time.

This change extents the Name Constraint properties by adding the Excluded property for DNSDomains and both the permitted and excluded properties for EmailDomains, IPAddresses and DirectoryNames as specified for the GeneralName property in RFC5280.

The selected properties are required to create or validate a fully constrained certificate.

The change also improves the validation of Name Constraints in general and allows the parsing of certificates that have Name Constraints marked as cirtial.

https://go-review.googlesource.com/#/c/3230/

Change-Id: Idaa7abafec372d5eb444cad7ee2ea5794aee3424

To be able to validate all certificates issued according to the CA / Browser Forum Baseline Requirements the full set of name constraints need to be available in GO.

A recent version of the CA / Browser Forum Baseline Requirements states that Technical Constraints in Subordinate CA Certificates MUST be applied via Name Constraints. To support strong and strict certificate path validation and to allow users to see the actual constraints it's important that GO supports the required Name Constraints.

Section 9.7 of the baseline requirements states:

"If the Subordinate CA Certificate includes the id-kp-serverAuth extended key usage, then the Subordinate CA Certificate MUST include the Name Constraints X.509v3 extension with constraints on dNSName, iPAddress and DirectoryName as follows:-"

The full requirements can be found on: https://cabforum.org/baseline-requirements-documents/

The DirectoryName is also needed in some Microsoft environments. Forbidding all directory names would enforce domain validated certificates even if all certificates under a specific root are used and issued by the same organisation. Or could enforce all certificates to be issued with the same OV certificate details. Email addresses are not specifically handled by the CABForum because they don't cover client auth or s/mime certificates currently but likely to have the same requirements and make the set of constraints supported complete.