[cabfpub] Urgent: BR Exceptions for Subordinate CA Certificates

[Dean Coclin]

Given the scenarios below, I think the best option for Verizon is #1 (name constraints). Although the exact format of the name constrains doesn't meet BR guidelines, it looks like Mozilla is ok with it and I assume other browsers will be as well. 

As you know the CABF, as an organization of browsers and certificate authorities, doesn't have authority to grant "exceptions" so this request is really out of scope. However, I think we (the CABF) should weigh in with our "opinion" so that later, browsers, auditors and others can reference that.

Also, please don't take my comments as CAB Forum co-chair to be a "decision" of the CABF.

Thanks,
Dean



-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Kathleen Wilson
Sent: Thursday, October 31, 2013 3:36 PM
To: CABFPub
Subject: [cabfpub] Urgent: BR Exceptions for Subordinate CA Certificates

All,

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 instantaneously.

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.

Regards,
Kathleen

_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public