<div dir="ltr">On our recent call, there was some discussion about the crlDistributionPoints profile, and what was expected/acceptable, particularly with the profiles work.<div><br></div><div>For context, there are several ways you can encode a crlDistributionPoints extension when have more than one distributionPoint. The syntax ( <a href="https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.13">https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.13</a> ) is simple:</div><div><br></div><div><font face="monospace">   CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint<br><br>   DistributionPoint ::= SEQUENCE {<br>        distributionPoint       [0]     DistributionPointName OPTIONAL,<br>        reasons                 [1]     ReasonFlags OPTIONAL,<br>        cRLIssuer               [2]     GeneralNames OPTIONAL }<br><br>   DistributionPointName ::= CHOICE {<br>        fullName                [0]     GeneralNames,<br>        nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }</font><br></div><div><br></div><div>The challenge here is that with multiple URLs, you can:</div><div><ol><li>Encode each URL as a distinct DistributionPoint. The distributionPoint member will have a fullName field. The full name will contain a single URI GeneralName.</li><li>Encode each URL within a single DistributionPoint. The distributionPoint member will have a fullName field. The full name will contain multiple URI GeneralNames.</li></ol><div>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.</div></div><div><br></div><div>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.</div><div><ul><li>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)</li><li>Out of a corpus of 158,247,352 EE certs examined</li><ul><li>512 contain multiple distributionPoints and multiple fullNames</li><li>3,929 contain multiple fullNames</li><li>77,454,996 contain multiple distributionPoints<br></li></ul><li>For multiple distribution points, 56,262,848 of those 77,454,996 certs are from a <a href="https://crt.sh/?caid=157939">single CA certificate</a> (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.</li><ul><li>663,470 of the remaining 768,924 certs are from Let's Encrypt's <a href="https://crt.sh/?caid=126329">log monitoring CA</a>.</li><li>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.</li></ul><li>For multiple fullNames, 3,382 of that 3,929 (84%) were from <a href="https://crt.sh/?caid=1488">two</a> <a href="https://crt.sh/?caid=401">CAs</a> operated by the same entity - FNMT.</li><li>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.</li><ul><li><a href="https://crt.sh/?caid=29058">https://crt.sh/?caid=29058</a> for 282 certificates (still trusted)<br></li><li><a href="https://crt.sh/?caid=171937">https://crt.sh/?caid=171937</a> for 128 certificates (US Federal Bridge PKI chained)<br></li><li><a href="https://crt.sh/?caid=633">https://crt.sh/?caid=633</a> for 36 certificates (sunset by Microsoft)<br></li><li><a href="https://crt.sh/?caid=14985">https://crt.sh/?caid=14985</a> for 27 certificates (still trusted)<br></li><li><a href="https://crt.sh/?caid=24508">https://crt.sh/?caid=24508</a> for 22 certificates</li></ul></ul><div>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).</div><div><br></div><div>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 <a href="https://crt.sh/?caid=87">https://crt.sh/?caid=87</a> ), even if their overall CA hierarchy does not. I cut off CAs with fewer than 300 certs</div><div><ul><li>DFN-Verein - <a href="https://crt.sh/?id=25484751">https://crt.sh/?id=25484751</a></li><li>E-Tugra - <a href="https://crt.sh/?caid=111903">https://crt.sh/?caid=111903</a></li><li>Dhimyotis / Certigna - <a href="https://crt.sh/?id=40275882">https://crt.sh/?id=40275882</a></li><li>A.C. Camerfirma - <a href="https://crt.sh/?id=6527708">https://crt.sh/?id=6527708</a></li><li>Asseco D.S. - <a href="https://crt.sh/?id=7050616">https://crt.sh/?id=7050616</a></li><li>NETLOCK - <a href="https://crt.sh/?id=2275">https://crt.sh/?id=2275</a></li><li>První certifikační autorita, a.s - <a href="https://crt.sh/?id=12730796">https://crt.sh/?id=12730796</a></li></ul></div><div>Again, nothing here indicates something <i>wrong</i> - 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)</div></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>With respect to the other questions, namely:</div><div><ul><li>Are non-URI GeneralNames used in the Web PKI (e.g. directoryName as a GeneralName)</li><li>Is LDAP used in the Web PKI, despite it (intentionally) not being widely supported?</li></ul><div>Both of these types exist to support combining disparate trust frameworks, or only have meaning in local contexts.</div></div><div><br></div><div>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</div><div><ul><li>T-Systems with 4,125 certificates- <a href="https://crt.sh/?id=17569392">https://crt.sh/?id=17569392</a></li><li>FNMT with 3,382 certificates - <a href="https://crt.sh/?caid=401">https://crt.sh/?caid=401</a></li><li>Financijska agencija (Microsoft-only) with 282 certificates - <a href="https://crt.sh/?id=31073401">https://crt.sh/?id=31073401</a><br></li></ul><div>I believe this supports the assertion that profiles can be clarified as <b>only</b> 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.</div></div></div>