[Servercert-wg] Subject name requirements for CA Certificates

Tue Oct 22 09:04:48 MST 2019

Ryan and all,

I’d like to continue the discussion about Cross Certificates.

For starters, I’m not able to find a specific statement that Cross Certificates are Subordinate CA certificates. 

Section 1.6.1 Definitions of related terms:

Cross Certificate:   A certificate that is used to establish a trust relationship between two Root CAs.

Publicly-Trusted Certificate:  A Certificate that is trusted by virtue of the fact that its corresponding Root Certificate is distributed as a trust anchor in widely-available application software.

Root CA:  The top level Certification Authority whose Root Certificate is distributed by Application Software Suppliers and that issues Subordinate CA Certificates.  

Root Certificate:  The self-signed Certificate issued by the Root CA to identify itself and to facilitate verification of Certificates issued to its Subordinate CAs.

Subordinate CA:  A Certification Authority whose Certificate is signed by the Root CA, or another Subordinate CA.

Each type of certificate are explicitly defined which implies the Cross certificate is different from a subordinate CA certificate.

When searching the BRs for Cross certificate, I found these two references which further the case that Cross Certificates are not the same as either Root CA certificates or Subordinate CA certificates:

a) Section “6.1.7 Key Usage Purposes” states:

Private Keys corresponding to Root Certificates MUST NOT be used to sign Certificates except in the following cases:

  2. Certificates for Subordinate CAs and Cross Certificates.

which implies subordinate CAs are different from Cross Certificates by calling them out separately vs just referencing “Subordinate CA Certificates”

b) Section “7.1.3 Algorithm Object Identifiers” makes this statement which implies Roots are different from Cross Certificates, and also different from Subordinate CA certificates since this is an explicit exclusion for Cross Certificates:

Effective 1 January 2016, CAs MUST NOT issue any new Subscriber certificates or Subordinate CA certificates using the SHA-1 hash algorithm. CAs MAY continue to sign certificates to verify OCSP responses using SHA1 until 1 January 2017. This Section 7.1.3 does not apply to Root CA or CA cross certificates. CAs MAY continue to use their existing SHA-1 Root Certificates. SHA-2 Subscriber certificates SHOULD NOT chain up to a SHA-1 Subordinate CA Certificate

RFC 5280 also calls out these 3 types of CA certificates ( Self signed, Self-issued and Cross-certificates), so I think we can all agree that there are 3 different types of CA Certificates

When looking at the requirements for what must be in Root and CA certificates, we have the following subsections in 7.1.4:

“7.1.4.1 Issuer Information”:  This just says that the Certificate Issuer Distinguished Name field MUST match the Subject DN of the Issuing CA.

“7.1.4.2: Subscriber certificates”: Not applicable to CA issuance

“7.1.4.3: Subject Information – Root Certificates and Subordinate CA Certificates”: This only applies to Roots and Subordinate CAs, but not to Cross Certificates (or else they would be specifically listed as elsewhere in the BRs).

So, there does not appear to be a specific requirement placed on Cross Certificates other than 7.1.4.1, which makes sense – a cross certificate establishes trust between 2 Roots and the subject and issuer DN must match that of the roots being cross certified.

Anyway, back to the topic,  I raised this question: 

*	b) what can/must go into a Cross Certificate as this is different and driven exclusively by the DN of the 2 roots being cross certified

And Ryan replied https://cabforum.org/pipermail/servercert-wg/2019-October/001187.html

For (b), I agree that it's going to be a tricky conversation.

The language here needs to be very precise; just saying "Cross Certificate" here opens up a lot of loopholes for interpretation, which can be used to abuse the permissiveness and lead to the wrong result. For example, if we just said "cross certificate", we could end up with a situation where someone who wants to stick arbitrary stuff in certificates would first generate a self-signed version of that certificate, with junk in the DN. They would then rely on a loophole (such as "CAs may sign non-compliant DNs, provided they are for the purposes of a cross-certificate" or some sort), and issue an intermediate with that junk in it! That's just one obvious example of how one might "abuse" (if malicious) or "misinterpret" (if benign) attempts at a carve-out.

In your example I agree we don’t want to let any old root to be used in Cross Certificates, so we need to constrain which roots can be cross certified.  I think we’re already partly there because the Roots that can be in a Cross Certificate to those that are “distributed by Application Software Suppliers”.  This precludes random self-signed roots for being used, but probably isn’t sufficiently strong for Apple, Mozilla, Microsoft and Google root programs (could be a small Application Software Supplier with little to no oversight of their root program).

Root CA:  The top level Certification Authority whose Root Certificate is distributed by Application Software Suppliers and that issues Subordinate CA Certificates.  

Root Certificate:  The self-signed Certificate issued by the Root CA to identify itself and to facilitate verification of Certificates issued to its Subordinate CAs.

How do we lock down the type of Roots which can be used in a Cross Certificate?

Is it acceptable to say that if the Root CA is a member of the CA/Browser Forum that is sufficient?

*	Root CA:- The member organization operates a certification authority that has a current and successful WebTrust for CAs, or ETSI 102042 or ETSI 101456 audit report prepared by a properly-qualified auditor, and that actively issues certificates to subordinate CAs that, in turn, actively issue certificates to Web servers that are openly accessible from the Internet using any one of the mainstream browsers.

We could update the definition of Cross Certificate to include similar language:

Cross Certificate:   A certificate that is used to establish a trust relationship between two Root CAs where both Root CAs operate a certification authority that has a current and successful WebTrust for CAs, or ETSI 102042 or ETSI 101456 audit report prepared by a properly-qualified auditor, and that actively issues certificates to subordinate CAs that, in turn, actively issue certificates to Web servers that are openly accessible from the Internet using any one of the mainstream browsers

Does this adequately address the topic? 

From: Ryan Sleevi <sleevi at google.com> 
Sent: Friday, October 11, 2019 10:21 AM
To: Doug Beattie <doug.beattie at globalsign.com>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] Subject name requirements for CA Certificates

On Fri, Oct 11, 2019 at 9:50 AM Doug Beattie <doug.beattie at globalsign.com <mailto:doug.beattie at globalsign.com> > wrote:

Getting back to Ryan’s initial post that subordinate CAs are being issued with more than the 3 field listed in Section 7.1.4.3.1.  Is it time to discuss the topic with the intent (at least from the CA perspective) that we propose a ballot that permits additional fields such as OU, S, and L to permit relying parties to have a better and more detailed understanding of the CA entity issuing the certificates?

By the way, Root program members weren’t listed in Ryan’s email and some of them are also at fault for not following the strict default DENY for CA subject DN:

I appreciate the enthusiasm, but unfortunately, I think you overlooked an important detail in that analysis.

You want to look after Ballot 199 was voted in, because prior to that, there rules were different. You can find the review notice at https://cabforum.org/pipermail/public/2017-May/010984.html , which the rules came into effect 2017-06-08.

This means the only violation is https://crt.sh/?id=1600419523 <https://crt.sh/?id=1600419523&opt=cablint> &opt=cablint . While this is a good example, it doesn't quite match your description of who is responsible. This is because the "Issuer" of the certificate is the responsible CA, not the "Subject". Sectigo is the issuer here, so this is a Sectigo issue, not an Apple issue. Similarly, the Microsoft example you provided is not a Microsoft issue - DigiCert issued those certificates (even though they were totally fine and compliant, when they were issued)

That said, I really appreciate you checking the results here. I think it's a great thing to do, because I totally make mistakes here, and the great thing about CT is folks can point out if I've overlooked something in my analysis. It's also a great example of how the requirements change over time, and why it's so important for CAs to carefully examine those changes and implications, whether they be to root program policies or to the BRs. This is exactly what my original message was looking at: trying to understand why some changes aren't adopted, with the seeming answer being that "Folks are reading with Default-Allow, rather than Default-Deny", and wanting to fix that issue at the source. 

If we can get that clearer: that the BRs as a whole are Default-Deny, then the only issues that should hopefully remain are "CAs not paying attention to the requirements", rather than "CAs coming to different conclusions about the expectations", and that works much better for everyone (... well, except those ignoring the changes :P) 

I think we need to formalize this in the BRs via ballot so that it’s clear to everyone:

a.	what can go into a Subordinate CA certificate and 
b.	what can/must go into a Cross Certificate as this is different and driven exclusively by the DN of the 2 roots being cross certified)

There is whole hearted agreement here that we should clarify this, and any other case, via Ballot, so that it's absolutely clear. You can see I tried to lay out a hopefully uncontroversial plan in https://cabforum.org/pipermail/servercert-wg/2019-October/001178.html , including our willingness to overlook these violations, provided we can make forward progress here in the Forum.

It's important, however, that we don't treat this as a one-off problem, which we can see with SC16 failing to fix the systemic issue. We should make it clear that what isn't permitted is forbidden, and then we can make sure that it's clear that anything that might be inadvertently forbidden is permitted. So I think your (a) is a part of that effort - but fixing (a) won't fix the systemic issue, and we should and need to fix that, to avoid issues continuing to crop-up, like Curt mentioned. As I mentioned in the above thread, if we're making progress on the systemic issue, we're totally willing to overlook the (a) issue being highlighted here, until we can get something comprehensive in place.

For (b), I agree that it's going to be a tricky conversation.

The language here needs to be very precise; just saying "Cross Certificate" here opens up a lot of loopholes for interpretation, which can be used to abuse the permissiveness and lead to the wrong result. For example, if we just said "cross certificate", we could end up with a situation where someone who wants to stick arbitrary stuff in certificates would first generate a self-signed version of that certificate, with junk in the DN. They would then rely on a loophole (such as "CAs may sign non-compliant DNs, provided they are for the purposes of a cross-certificate" or some sort), and issue an intermediate with that junk in it! That's just one obvious example of how one might "abuse" (if malicious) or "misinterpret" (if benign) attempts at a carve-out.

There's a broader question hidden here about whether such cross-certificates are necessarily good for the ecosystem, especially when they effectively hinder the promotion of a reasonable profile for intermediates and roots. It admittedly does make it easier for CA operators, because it means as few changes to their systems and past operating practices, but it's not clear that such a lack of agility is good for users or the ecosystem.

I think there's a totally reasonable middle ground here, to make sure we don't get lost in the weeds here or have to hash that stuff out now. For example, I can totally see a path where, instead of wholesale forbidding such cross-certificates, we instead allowing cross-certificates to be issued with non-compliant DNs, but only if they meet certain conditions (e.g. if the validity period is 3 years or less, and only if issued within the next two years). That would give us two years to discuss the tradeoffs and determine whether to permanently enshrine it, or to encourage alternative practices, and makes it so that if things need to change, they might be reasonably implementable by clients in 2025, quite some time away.

This sort of natural sunset is a good example of applying a strategy of "why". I don't think this approach is dispositive towards the result: after all, I think it's totally valid that the answer may be "This is good and we should permanently allow it" - rather than having to worry about taking it out later. It also allows for the possibility of "We're still discussing this, we're making good progress but it's tricky, let's allow it for another year while we work out the details". This sort of approach helps make sure we're all making progress, and constantly asking the right question: "Why". But it also makes sure that we're able to make progress on this, and have the discussion that's needed to get to the conclusion; punting the discussion, but not indefinitely so.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191022/6650015d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5701 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191022/6650015d/attachment-0001.p7s>