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.
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
andSRVName
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 forSRVName
s 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
, anddirectoryName
constraints) would, if clients supportedSRVName
s, be able to issue arbitrarySRVName
s without being constrained in the same way. Given that, like DNS,SRVName
s also contain a host name, this is certainly at odds with the goals of technically constrained. By constrainingSRVName
s as well, such sub-CAs can be effectively constrained.The draft profile work is proposing allowing both
rfc822Name
andSRVName
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.