[Servercert-wg] Subject name requirements for CA Certificates

Tue Oct 22 12:23:41 MST 2019

I agree with you on:

- You can use that old Root to sign your new Root.

- You cannot use your new Root to sign your old Root.

But I don’t agree that you should “punish” CAs that have Roots created prior to Ballot 199 (and compliant) by not permitting them to cross sign those Roots with even older roots in order to establish a logical root migration plan. Roots included into multiple Root stores should be able to create cross certificates, and I’m willing to help refine the BRs to more clearly specify how Cross certificates should be treated by proposing the set of changes (and probably others) listed below in this email.  It’s important we explicitly state how to handle Cross Certificates, and I believe there are some requirements that apply to Subordinate CAs and not to Cross Certificates.

If we took that approach (make the BRs more clear on the requirements for Cross Certificates), would Google be willing to permit continued creation of Cross Certificates provided that both of them are in the Google and/or Mozilla trust store(s)?

Since Outlook is truly horrible in supporting in-line comments, I marked my comments with [doug] below.

Doug

From: Ryan Sleevi <sleevi at google.com> 
Sent: Tuesday, October 22, 2019 12:28 PM
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 Tue, Oct 22, 2019 at 12:04 PM Doug Beattie <doug.beattie at globalsign.com <mailto:doug.beattie at globalsign.com> > wrote:

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.

Thanks. I think this fits into the pattern of Default-Deny vs Default-Allow, so it's useful to have examples of this interpretation working in practice.

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.

I don't think that's really a fair or reasonable reading. If your view is that the definitions section is inherently non-overlapping, then we should resolve.

[doug] yes, we need to resolve.

I would hope it would be self-obvious that, even using this argument, a Cross Certificate is definitionally a subset of Subordinate CA, since a Cross Certificate is fundamentally signed by another Root CA or Subordinate CA. That's why I suggest, above, it's about (misreading) using a framing of Default-Allow.

[doug] I don’t agree on this topic.  First, a Cross certificate is defined to establish a trust relationship between two Root CAs, and far as this definition goes it does not support being signed by a Subordinate CA.  Perhaps I mis-interpreted your statement.  Second, the keys in the cross certificate are those from a Root, so key generation rules and audits for key generation are different from those of a Subordinate CA (more highly audited).  Assuming default deny (treating a Cross certificate like a Subordinate CA certificate) fails here.

[doug] The keys in a cross cert as well as the subject DN are those of a root, so in that regard, it seems more like a root than a subordinate CA.  If a Cross Certificate isn’t clearly defined, then you can default allow “assuming” it’s a Root, or a Subordinate CA, or make some judgement <dangerous>.  We need clear definitions and requirements for each type of CA certificates without making assumptions (default-allow, default-deny)

To show the inherent internal inconsistencies with such a conclusion, we can simply look and ask "Does that interpretation make sense, given the rest of the BRs?"

- 2.1 would not apply - CAs would not be required to make revocation information available for cross-certificates, as it's only applicable for Subordinate CA

[doug] Then that needs to be updated.

- Rules around validation for nameConstraints (3.2.2.4 / 3.2.2.5) would not apply, as they're only applicable to Subordinate CA certificates

[doug] We should be clear here.  If we want nameConstraints to be an option for cross certificates, then we should update the definition, otherwise it’s precluded.

- 4.9.1.2 (reasons for revocation) would not apply, as they're only applicable to Subordinate CA Certificates

[Doug] Right, we need a section for reasons to revoke a Cross Certificate, because I don’t think they are the same as a Subordinate CA.

- 4.9.7 would not apply - no CRLs need to be provided

[doug] Need to add “and Cross Certificates” so this is clear.

- 4.9.10 would not apply - no OCSP needs to be provided

[doug] Need to add “and Cross Certificates” so this is clear.

- 6.1.1.1 would not apply - there are no rules for key generation, since that only applies to Root CA Key Pairs or Subordinate CA key pairs, so that section is complete

[Doug] the keys in a cross certificate are those of a root, so that is covered

- 6.1.5 would not apply - no key size restrictions

[Doug] the keys in a cross certificate are those of a root, so that is covered.

You can continue reading and see it would lead to a nonsense interpretation.

[doug] I see lots of room for confusion when we’re not clearly specifying requirements, so we should clean this up and move away from the default-deny strategy.

[doug] Section 6.2.5 says that Parties other than the Subordinate CA SHALL NOT archive the Subordinate CA Private Keys without authorization by the Subordinate CA.  But, it’s really with authorization from the Root CA.

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

We've beat this horse before, you may recall. These are overlapping sets of certificates. A self-signed certificate is tautologically a self-issued certificate, for example. They are not distinct types, they are categorizations and sub-classes. A cross-certificate is a sub-class of a subordinate CA certificate, by definition. All self-signed certificates are self-issued, even though not all self-issued certificates are self-signed. All cross-certificates are subordinate certificates, even though not all subordinate certificates are cross-certificates.

[doug] where exactly is the definition that a cross certificate is a sub-class of a subordinate CA certificate?  Yes, a Root signs them both so at that level they are subordinate CA certificates, but the BRs go on to place more definitions on subordinate Certificates that may diverge from how cross certificates are defined and used in practice.

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.

I think it's important that this conclusion is predicated on a misunderstanding - that cross-certificates are not subordinate CA certificates.

[doug] I’m saying that a cross certificate is not exactly the same as a Subordinate CA certificate and we need to clearly define exactly what we mean.

7.1.4.3 applies. These are specific requirements that apply to Cross Certificates, a subset of CA certificates.

Does this adequately address the topic?

I think you failed to state the problem statement that you're trying to address.

I'll hopefully make it clear Google's expectations, which may provide sufficient insight.

[doug] This is fine, but unless this is documented in the BRs or a Root program, this isn’t useful way to place requirements on CAs.

1) A Cross Certificate is a sub-class of Subordinate CA certificate.

  * All existing requirements for Subordinate CA certificates apply to cross certificates, except as explicitly noted.

2) We expect all newly created Root CA Certificates and newly created Subordinate CA Certificates to comply with the Baseline Requirements

  * If a given keypair cannot be demonstrated to have been in compliance with the version of the BRs current at time of creation, and continually provided until issuance, we do not want it signed (i.e. the audit lifecycle quesiton)

3) We expect that Root CA Certificates, and the certificates they sign, will comply with the Baseline Requirements profile

  * Put explicitly: We do not want any *new* root sign any existing *old* root

[doug] great, I also agree that we should only sign new roots with old ones.

The natural consequence is an approach to PKI design that has "old certify new", but never "new certify old".

- If you have an existing Root CA Certificate which uses a name form that is not compliant with the Baseline Requirements, you MUST NOT cross-certify it.

- You can use that old Root to sign your new Root.

- You cannot use your new Root to sign your old Root.

This is the only logical path to make forward progress on aligning intermediates and roots to a common profile.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191022/4a097b03/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/4a097b03/attachment-0001.p7s>