BRs: Clarify how SRVName subjectAltNames should behave

[sleevi]

During the discussion on 2022-04-22 of the draft certificate profile work of the validation subcommittee, one area that was identified was that the requirements of Mozilla's Root Program, with respect to nameConstraints and technically constrained sub-CAs, is a superset of the requirements reflected in the Baseline Requirements.

In particular, Mozilla requires restrictions around rfc822Name and SRVName in order to be considered technically constrained and thus fully out of scope of their program. During the call, the discussion highlighted this was intentional, in order to prevent compatibility or security risks to Mozilla users if/when support for SRVNames is introduced for TLS or the adoption of S/MIME BRs.

At issue is the fact that a CA that is technically constrained by the BRs today (via dNSName, iPAddress, and directoryName constraints) would, if clients supported SRVNames, be able to issue arbitrary SRVNames without being constrained in the same way. Given that, like DNS, SRVNames also contain a host name, this is certainly at odds with the goals of technically constrained. By constraining SRVNames as well, such sub-CAs can be effectively constrained.

The draft profile work is proposing allowing both rfc822Name and SRVName name constraints to be added to sub-CAs issued by CAs subject to the Baseline Requirements, but with the requirement that the CA MUST appropriately validate the domain name portion of these fields.

While this explicitly would not permit the issuance of these SANs, which are presently forbidden by the BRs and still proposed to be forbidden, as part of the new profiles work, this issue is to track the work that can be done in parallel or subsequently to allow such issuance, as well as to work out what issues clients may have to support such names securely.

[sleevi]

New discussion thread related to this issue