[cabf_validation] crlDistributionPoints Encoding

[Ryan Sleevi]

On our recent call, there was some discussion about the
crlDistributionPoints profile, and what was expected/acceptable,
particularly with the profiles work.

For context, there are several ways you can encode a crlDistributionPoints
extension when have more than one distributionPoint. The syntax (
https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.13 ) is simple:

   CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint

   DistributionPoint ::= SEQUENCE {
        distributionPoint       [0]     DistributionPointName OPTIONAL,
        reasons                 [1]     ReasonFlags OPTIONAL,
        cRLIssuer               [2]     GeneralNames OPTIONAL }

   DistributionPointName ::= CHOICE {
        fullName                [0]     GeneralNames,
        nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }

The challenge here is that with multiple URLs, you can:

   1. Encode each URL as a distinct DistributionPoint. The
   distributionPoint member will have a fullName field. The full name will
   contain a single URI GeneralName.
   2. Encode each URL within a single DistributionPoint. The
   distributionPoint member will have a fullName field. The full name will
   contain multiple URI GeneralNames.

The BRs today require that the crlDP "MUST contain the HTTP URL of the CA’s
CRL service", and the goal is to clarify that wording. A number of CAs have
obviously interpreted that as a "minimum, not maximum"; that is, as long as
they include one such URL, they may include any other arbitrary URLs and/or
any other arbitrary types (whether that be other fullNames - such as
DirectoryName - or nameRelativeToCRLIssuer). It also doesn't specify other
fields, such as reasons that may or may not be set.

To that end, I did some crunching with CT, examining for certificates that
contain multiple distributionPoints and multiple fullNames. I did _not_
filter by browser trust, so that we could over count, not under-count. For
example, this will pick up things like MMD monitoring certificates from CT
logs, and will duplicate count for pre-certificates and actual certificates
(i.e. it will count as two certificates). That's OK - this is just about
determining the broad shape of risk.

   - Out of a corpus of 50,171 issuer names examined, there are 198 issuing
   CA certificates with unexpired leaf certificates that either have multiple
   distributionPoints or multiple names within fullName ("multiple fullNames",
   for future brevity)
   - Out of a corpus of 158,247,352 EE certs examined
      - 512 contain multiple distributionPoints and multiple fullNames
      - 3,929 contain multiple fullNames
      - 77,454,996 contain multiple distributionPoints
      - For multiple distribution points, 56,262,848 of those
   77,454,996 certs are from a single CA certificate
   <https://crt.sh/?caid=157939> (Cloudflare); but this is not surprising,
   because the top 10 issuer CA certificates (representing 76,686,042 of that
   77,454,996 certificates, or 99%) are all from CAs operated by DigiCert.
      - 663,470 of the remaining 768,924 certs are from Let's Encrypt's log
      monitoring CA <https://crt.sh/?caid=126329>.
      - This means only 105,454 certificates containing multiple
      distributionPoints (at an upperbound) are not from DigiCert-operated CAs.
      In practice, I believe this number is less, due to many branded sub-CAs
      under DigiCert hierarchies.
   - For multiple fullNames, 3,382 of that 3,929 (84%) were from two
   <https://crt.sh/?caid=1488> CAs <https://crt.sh/?caid=401> operated by
   the same entity - FNMT.
   - For multiple instances of both, it's a bit of a grab bag - but it
   tends to be CAs that are only participants In Microsoft's root store, and
   generally not BR compliant.
      - https://crt.sh/?caid=29058 for 282 certificates (still trusted)
      - https://crt.sh/?caid=171937 for 128 certificates (US Federal Bridge
      PKI chained)
      - https://crt.sh/?caid=633 for 36 certificates (sunset by Microsoft)
      - https://crt.sh/?caid=14985 for 27 certificates (still trusted)
      - https://crt.sh/?caid=24508 for 22 certificates

I mentioned 198 issuing CA certificates; that makes up 70 distinct
organization names (the O fields of the certs; ignoring the full DN of the
issuer).

Of that 70, the following CA organizations have, for the sub-CAs that have
ever issued multiple distributionPoints or nullNames, "100%" of their
counted issuance displaying multiple distributionPoints or multiple
fullNames, listed as the audited organization. That is, a CA may have 100%
of a given CA (e.g. Sectigo's https://crt.sh/?caid=87 ), even if their
overall CA hierarchy does not. I cut off CAs with fewer than 300 certs

   - DFN-Verein - https://crt.sh/?id=25484751
   - E-Tugra - https://crt.sh/?caid=111903
   - Dhimyotis / Certigna - https://crt.sh/?id=40275882
   - A.C. Camerfirma - https://crt.sh/?id=6527708
   - Asseco D.S. - https://crt.sh/?id=7050616
   - NETLOCK - https://crt.sh/?id=2275
   - První certifikační autorita, a.s - https://crt.sh/?id=12730796

Again, nothing here indicates something *wrong* - these are just exploring
the different ways of encoding, to understand what impact would be had on
the ecosystem by trying to align into a single, canonical form. It also
reflects that, at least for the Web PKI, we either don't need or don't
support some of the use cases enabled by the more complex extensions (e.g.
partial CRLs sharded by reason codes)

For example, if we adopted the multiple fullnames approach, we'd save four
bytes per additional URL. To do that, we'd need roughly 8 CAs to make a
change to their systems, with 1 CA being able to offer the biggest
bang-for-the-buck.

In terms of compatibility risk, I'm not aware of any risks with any
implementation I'm familiar with, but I do understand and appreciate there
might be concern, or superstition, or reasons lost to the mists of time.
The dearth of multiple fullName certs doesn't necessarily inspire
confidence, although it also isn't proof of the negative. I'd be curious to
hear if folks have more data in terms of compatibility risks.

For now, I'll update the profile draft to allow either-or - multiple
fullName or multiple distributionPoint. However, hopefully we can hear from
some of the CAs above about further aligning to a single canonical form,
preferably an efficient one.

With respect to the other questions, namely:

   - Are non-URI GeneralNames used in the Web PKI (e.g. directoryName as a
   GeneralName)
   - Is LDAP used in the Web PKI, despite it (intentionally) not being
   widely supported?

Both of these types exist to support combining disparate trust frameworks,
or only have meaning in local contexts.

I see roughly 8,174 certificates meeting that criteria (of having non-URI
GeneralName or non-HTTP URI). Of these, a sampling of CAs with > 100 certs
are

   - T-Systems with 4,125 certificates- https://crt.sh/?id=17569392
   - FNMT with 3,382 certificates - https://crt.sh/?caid=401
   - Financijska agencija (Microsoft-only) with 282 certificates -
   https://crt.sh/?id=31073401

I believe this supports the assertion that profiles can be clarified as
*only* permitting HTTP URIs here; that is, that the BRs correctly read that
the certificate MUST contain an HTTP URI, but does not permit it to contain
other forms of URIs or types of distribution points. This does not appear
to be a source of CA confusion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210728/2c7405b7/attachment.html>