[Servercert-wg] Subject name requirements for CA Certificates

[Ryan Sleevi]

On Tue, Oct 22, 2019 at 3:23 PM Doug Beattie <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/33ca20e5/attachment.html>