[cabfpub] Urgent: BR Exceptions for Subordinate CA Certificates

Kathleen Wilson kwilson at mozilla.com
Thu Oct 31 19:35:53 UTC 2013


An unfortunate series of circumstances has led to us being presented 
with a short deadline to find a solution to a problem. For reasons 
explained below, CABF consensus on the way forward is earnestly sought. 
So we hope you will be able to give this issue prompt attention and that 
we can find a way forward together. The aim here is to agree to a best 
practice solution which averts widespread breakage and which commands 
the assent of the industry.

Verizon has been working to replace a subordinate CA certificate that 
they cross-signed with the Swiss Government (BIT) in 2010. In doing so, 
they wish naturally to be fully compliant with the BRs and the 
requirements of the root programs. They ran into temporary technical 
problems with DirectoryName constraints, but we think those are now in 
the process of being solved. However, there are various compliance 
questions in regards to this hierarchy that they would like CAB Forum 
guidance on before re-issuing the cross-cert. Note that the current 
cross-signed certificate expires on November 2, 2013, so we are 
requesting your prompt attention to this.

These are the issues in play:

* BR 9.1.3 says that the Issuer Organization Name (O) field must not 
contain a generic designation. The BIT legacy roots have the DN 
"o=admin,c=CH". However, Swiss law apparently reserves this particular 
string as a 'brand' to BIT. And, of course, this root was created long 
before the BRs were thought of.

* These older roots have been audited in the past, but BIT now wishes to 
focus their audit resources on the PKI containing the new roots. 
Therefore they have chosen to use technical constraints rather than 
audit for the new intermediate.

* The current cross certificate issued in 2010 contains no constraints, 
other than path length constraint of zero.

* To name constrain the intermediate certificate according to BR 9.7, 
the certificate will need to contain a constraint permitting a directory 
name of "o=admin,c=CH", in order to support the existing certificates.

* The SSL leaf certificates were issued by BIT directly from the older 
roots (the cross-cert makes a chain of three), and they don't have a SAN 
for their CN. BIT is working to update their issuance practices as they 
are applying for inclusion in the Mozilla root store. With regards to 
the direct root issuance, Verizon plans to set path length constraint of 
1 to permit BIT to create an operational issuer and re-issue the subject 
certificates once the crisis is averted.

After much hurried discussion, we see two options for moving forward:

1) Allow the name constraints to contain a DirectoryName constraint for 
"o=admin,c=CH". The justification here is that "o=admin,c=CH" is a DBA 
enacted by Swiss legislation, and so valid under BR section 9.2.4, which 
we would consider applied both to the Subject and Issuer DNs.

2) As a fallback to option 1, reissue an identical cross-signed 
certificate with a later expiration date. This would mean no name 
constraints - i.e. a temporary dispensation from the BRs. Mozilla is not 
requiring technical constraint until May 15th, 2014, so we propose that 
expiry date. This time frame will allow for further careful discussion 
of long-term solutions.

Other suggestions are very welcome, but please share your opinion on the 
two options presented. The cross-cert expires on November 2nd 
(Saturday), and a replacement cert clearly cannot be deployed 

Note that if CABF reaches consensus on option 1 today, option 2 may 
still be needed if Verizon hits an unexpected interop issue.

All, if you become aware of a technical issue that has the potential to 
have a similarly large negative impact on end-users, please do not 
hesitate to share your concerns so that the issue can be dealt with 
before it becomes an emergency.


More information about the Public mailing list