[cabfpub] Urgent: BR Exceptions for Subordinate CA Certificates

Ryan Hurst ryan.hurst at globalsign.com
Thu Oct 31 12:52:50 MST 2013


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.

Ryan


On Thu, Oct 31, 2013 at 12:35 PM, Kathleen Wilson <kwilson at mozilla.com>wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20131031/8f7e3a39/attachment.html 


More information about the Public mailing list