[Servercert-wg] Subject name requirements for CA Certificates

[Ryan Sleevi]

On Tue, Oct 22, 2019 at 12:04 PM Doug Beattie <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.

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.

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
- 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
- 4.9.1.2 (reasons for revocation) would not apply, as they're only
applicable to Subordinate CA Certificates
- 4.9.7 would not apply - no CRLs need to be provided
- 4.9.10 would not apply - no OCSP needs to be provided
- 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
- 6.1.5 would not apply - no key size restrictions

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


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

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.

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.

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

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/acbe8e4f/attachment.html>