[cabfpub] Urgent: BR Exceptions for Subordinate CA Certificates

Ryan Sleevi sleevi at google.com
Thu Oct 31 23:19:01 UTC 2013


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

I'm a bit curious on this. If the leafs are signed by BIT's (cross-signed)
root directly, why would a pathLen of 1 be necessary? A pathLen of 0 is all
that is needed to support this practice.

Are you suggesting that BIT is going to spin up a new intermediate and
re-issue all their existing certs from this intermediate, rather than the
root? This seems orthogonal to the presumed crisis at hand, but it just
helps to understand why this may have been brought up.


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

Is adding this NC simply to work around older platforms' issues with
nameConstraints? Nominally, an unconstrained name type shouldn't have
constraints applied to it - but I'm guessing this is related to the
previous discussion & Ryan (Hurst's) blogs on the matter.

The DirectoryName name constraints here for the directory name have little
bearing on the security of the leaf certificates. All that (really) matters
is the dNSName / iPAddress constraints.


>
> 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: <http://lists.cabforum.org/pipermail/public/attachments/20131031/e9d7feca/attachment-0003.html>


More information about the Public mailing list