<div dir="ltr">Well I don;t like either option but providing an exception to allow the o=,c= approach seems better for the net as a whole.<div><br></div><div>Ryan<br><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Oct 31, 2013 at 12:35 PM, Kathleen Wilson <span dir="ltr"><<a href="mailto:kwilson@mozilla.com" target="_blank">kwilson@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
All,<br>
<br>
An unfortunate series of circumstances has led to us being presented<br>
with a short deadline to find a solution to a problem. For reasons<br>
explained below, CABF consensus on the way forward is earnestly sought.<br>
So we hope you will be able to give this issue prompt attention and that<br>
we can find a way forward together. The aim here is to agree to a best<br>
practice solution which averts widespread breakage and which commands<br>
the assent of the industry.<br>
<br>
Verizon has been working to replace a subordinate CA certificate that<br>
they cross-signed with the Swiss Government (BIT) in 2010. In doing so,<br>
they wish naturally to be fully compliant with the BRs and the<br>
requirements of the root programs. They ran into temporary technical<br>
problems with DirectoryName constraints, but we think those are now in<br>
the process of being solved. However, there are various compliance<br>
questions in regards to this hierarchy that they would like CAB Forum<br>
guidance on before re-issuing the cross-cert. Note that the current<br>
cross-signed certificate expires on November 2, 2013, so we are<br>
requesting your prompt attention to this.<br>
<br>
These are the issues in play:<br>
<br>
* BR 9.1.3 says that the Issuer Organization Name (O) field must not<br>
contain a generic designation. The BIT legacy roots have the DN<br>
"o=admin,c=CH". However, Swiss law apparently reserves this particular<br>
string as a 'brand' to BIT. And, of course, this root was created long<br>
before the BRs were thought of.<br>
<br>
* These older roots have been audited in the past, but BIT now wishes to<br>
focus their audit resources on the PKI containing the new roots.<br>
Therefore they have chosen to use technical constraints rather than<br>
audit for the new intermediate.<br>
<br>
* The current cross certificate issued in 2010 contains no constraints,<br>
other than path length constraint of zero.<br>
<br>
* To name constrain the intermediate certificate according to BR 9.7,<br>
the certificate will need to contain a constraint permitting a directory<br>
name of "o=admin,c=CH", in order to support the existing certificates.<br>
<br>
* The SSL leaf certificates were issued by BIT directly from the older<br>
roots (the cross-cert makes a chain of three), and they don't have a SAN<br>
for their CN. BIT is working to update their issuance practices as they<br>
are applying for inclusion in the Mozilla root store. With regards to<br>
the direct root issuance, Verizon plans to set path length constraint of<br>
1 to permit BIT to create an operational issuer and re-issue the subject<br>
certificates once the crisis is averted.<br>
<br>
After much hurried discussion, we see two options for moving forward:<br>
<br>
1) Allow the name constraints to contain a DirectoryName constraint for<br>
"o=admin,c=CH". The justification here is that "o=admin,c=CH" is a DBA<br>
enacted by Swiss legislation, and so valid under BR section 9.2.4, which<br>
we would consider applied both to the Subject and Issuer DNs.<br>
<br>
2) As a fallback to option 1, reissue an identical cross-signed<br>
certificate with a later expiration date. This would mean no name<br>
constraints - i.e. a temporary dispensation from the BRs. Mozilla is not<br>
requiring technical constraint until May 15th, 2014, so we propose that<br>
expiry date. This time frame will allow for further careful discussion<br>
of long-term solutions.<br>
<br>
Other suggestions are very welcome, but please share your opinion on the<br>
two options presented. The cross-cert expires on November 2nd<br>
(Saturday), and a replacement cert clearly cannot be deployed<br>
instantaneously.<br>
<br>
Note that if CABF reaches consensus on option 1 today, option 2 may<br>
still be needed if Verizon hits an unexpected interop issue.<br>
<br>
All, if you become aware of a technical issue that has the potential to<br>
have a similarly large negative impact on end-users, please do not<br>
hesitate to share your concerns so that the issue can be dealt with<br>
before it becomes an emergency.<br>
<br>
Regards,<br>
Kathleen<br>
<br>
_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
</blockquote></div><br></div></div></div>