[cabfpub] Urgent: BR Exceptions for Subordinate CA Certificates
Kathleen Wilson
kwilson at mozilla.com
Thu Oct 31 12:35:53 MST 2013
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
More information about the Public
mailing list