Dealing with SubCAs with many nameConstraints

[Stephen Davidson]

The use of DNS nameConstraints is a useful tool for restricting the scope of SSL issuance by external subCAs, and examples exist with hundreds of nameConstraints. However some subCA customers are reporting issues with some applications when using subCA certificates that include large numbers of nameConstraints.



A subCA customer has proposed the following solution to divide up the nameConstraints. They asked if we could issue them with three subCA certificates instead of one. The proposed solution would include one subCA certificate with all the nameConstraints (subCA A) and then two subCA certificates with subsets of the nameConstraints (subCA B and subCA C). The subCA certificates B and C would only be used in cases with known problems handling large nameConstraints pools.



- All three subCA certs would have the same public keys, Subject DNs and Subject Key IDs; and

- The subCAs would be different certs so have different serial numbers, thumbprints, and included nameConstraints.



I do not believe that this proposal poses concerns from an audit, security, or Mozilla compliance perspective. However I believe that the proposal may cause path building and validation issues for end users' browsers (for example if a user first encounters an SSL chained to subCA C and then later visits a site chained to subCA B; the certs have the same SKI but different included nameConstraints).



The customer believes they can mitigate these support issues by ensuring the majority of their users first encounter subCA A which includes all the nameConstraints found in subCA B and subCA C.



However, I am interested in feedback from the Mozilla community, including any experience on handling subCAs with large numbers of nameConstraints.



Many thanks in advance for any input.

[Ryan Sleevi]

On Monday, August 8, 2016 at 12:47:26 PM UTC-7, S Davidson wrote:
> However, I am interested in feedback from the Mozilla community, including any experience on handling subCAs with large numbers of nameConstraints.

My biggest concern relates to the re-use of the issuer name and key across multiple distinct certificates. That's a relative recipe for hell when constructing paths - particularly with the duplicate SKID. If you don't vary the validity period, you've got even more non-determinism.

Is there a reason this customer can't simply have two unique-subject intermediates to handle their various needs? Segment (Domain Set A) to Intermediate A, and (Domain Set B) to Intermediate B.

I would strongly discourage putting it all under one intermediate, even though I'm not aware of any explicit prohibition of this.