[cabfpub] Urgent: BR Exceptions for Subordinate CA Certificates

[kirk_hall at trendmicro.com]

Trend Micro supports either option outlined by Kathleen to deal with the immediate problem.

When looking at a BR non-compliance issue, the first question is "Does it create a real and immediate vulnerability for users?"  To our thinking, the answer here is no.

The second question is, "Has the non-compliant CA presented an adequate plan for getting in compliance as soon as practicable?"  We think the answer here is yes.

For these reasons, we would support an exception to immediate compliance with the BRs listed below while Verizon moves to full compliance.  Remember that until 2012, the BRs were not applicable to CA operations.  As most of us CAs know, it can take months or even years for new infrastructure to be introduced to fully substitute for older infrastructure in a way that doesn't break customer and user applications -- and clearly we don't want to do that.   And as recent news stories have indicated, use of SSL (even slightly non-compliant SSL that does not pose its own security risks) is far superior to non-use of SSL.  

We have already allowed transition periods and exceptions for 60 month certs and certs for IP addresses and local host names in the BRs themselves in order to help move the SSL ecosystem to a stronger position, so there is ample precedent for making exceptions where sensible -- we think this falls in the same category.

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Kathleen Wilson
Sent: Thursday, October 31, 2013 12: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
<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>