[Servercert-wg] Subject name requirements for CA Certificates

Tue Oct 22 13:13:58 MST 2019

Ryan,

We’re saying the same thing as far as “older -> old -> new -> intermediate -> end entity".  New roots should be able to be cross signed only with older roots.  That is what we did and is consistent with your comments below, so totally agree.  

The unfortunate aspect of this is that the subject DN of our “old” root isn’t compliant with the current definition of Subordinate CA subject DN, thus the issue if/when we treat a Cross Certificate as a Subordinate CA certificate when it comes to naming requirements.  If this was not an issue, we wouldn’t be having this conversion.

I would certainly like to hear from others, CAs and Root program members on their view of this situation.   Does everybody feel that cross certificates between roots should be prohibited when the “old” root subject DN does not contain exactly C, Org and CN?  I have to assume this is a problem for more than just GlobalSign.

Doug

From: Ryan Sleevi <sleevi at google.com> 
Sent: Tuesday, October 22, 2019 3:51 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 3:23 PM Doug Beattie <doug.beattie at globalsign.com <mailto:doug.beattie at globalsign.com> > wrote:

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.

I disagree, and I think there are compelling technical alternatives that don't necessitate this compromise.

The suggestion here is that "old" should be able to sign "older", and I disagree that this is intrinsically necessary. The solution is to move your active issuing hierarchy to "new", have "old" certify "new", and have "older" certify "old". This creates a contiguous chain of trust, from new to old to older, and is exactly how PKI was intended to migrate hierarchies.

I can understand that there's likely a concrete problem GlobalSign is facing, and I'm totally on board with helping GlobalSign map out its hierarchy and needs. However, I disagree that "old" should sign "older" - and I cannot see that being good for our users, as it's the opposite direction for the ecosystem.

This is all the more relevant when we discuss post-quantum migration plans. The current approach that a number of CAs take - that the 'older' a root is, the more 'valuable' it is (e.g. because ubiquity) - often means that they place online issuance in the oldest root, then sign that with older roots, then sign those with newer roots, such that the chain is always "new -> old -> older -> intermediate -> end entity". That's quite literally the inverse of what we'd like to see. The path should be "older -> old -> new -> intermediate -> end entity".

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.

I'm sorry, that argument seems to be picking and choosing definitions.

RFC 5280 is clearer on this, unsurprisingly - CA certificates are lumped into three categories: cross-certificates, self-issued, and self-signed. In RFC 5280, a cross-certificate is any certificate whose Issuer != Subject - aka by definition, a Subordinate.

To wit, to the BRs, a Subordinate CA is a CA Certificate that is signed by a Root or another Subordinate. Unless you're arguing that a Root or Subordinate is not signing the Cross-Certificate, you cannot square your argument with the very definition you're citing.

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.

1) I disagree that we should remove from default-deny, because it is the only way to prevent inconsistent interpretations

2) I'm not aligned nor supportive with your suggestion that somehow, all the sections don't make sense and are at fault, and that we have no rules on Cross-Certificates. The interpretation you're offering which is not itself supported by the very definitions you're citing.

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

In RFC 5280? Section 3.2. Other CAs seem to have made perfect sense of this, judging by the CP/CPSes I've seen.

In the Baseline Requirements? The very definitions: Subordinate CA: A Certification Authority whose Certificate is signed by the Root CA, or another Subordinate CA.

The definition of Cross Certificates largely exists, today, both in the BRs and in the Root Programs, to allow certain limited permissiveness where otherwise more restrictive rules may apply. One exception is 3.2.6, in which it is the CA disclosing the cross-certificates issued /to it/, rather than the cross certificates /it has issued/.

You'll note that, in the browser alignment ballot, one of these exceptions is removed. And you'll note that I've offered a suggestion on how to remove the other exception. Combined, with the audit reporting ballot, this would wholly facilitate the removal of the definition, and by proxy, the confusion being captured here. That seems to be much more aligned with the existing browser/root program requirements.

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.

And I disagree, and while I'm supportive of bringing clarity to this, I want to be clear that a Cross Certificate is a definitional subset of Subordinate CA certificate, that all the rules of Subordinate CA certificates apply. Further, the rules of a Root Certificate *may also apply*, and that except as explicitly permitted, one must read with the most restrictive set of requirements. 

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

It is captured in the BRs, but I can understand that you're wanting to take the view that the definition of "Subordinate CA" is somehow non-exhaustive, or its inclusion within Definitions is somehow an implicit distinction of categorization rather than, as the section says, definitions.

I'm not sure how best to capture "Bad interpretations", because there will always be room to apply for them, but that doesn't make them good simply because they can be made.

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