Hi Daniel, As far as I’m aware, CCADB entries are not removed after the corresponding certificate expires/is revoked, so there’s a lot of old data present. In addition to CRL URIs, you’ll also find links to audit documents from 2017, etc. Definitely not useful for an RP making trust decisions today based on the data but may be useful when doing a historical analysis.
For those who care only about the set of unexpired/not revoked CA certificates (such as for your analysis), including the PEM text of the corresponding certificate, or at the very least the notBefore/notAfter values in the “AllCertificateRecordsCSVFormat” report would be useful. I know that I’ve had to write logic that correlates the information in the “AllCertificateRecordsCSVFormat” report with another data source to get the full picture at least a few times, and I imagine others have had to do the same thing as well. Thanks, Corey From: Daniel McCarney <[email protected]> Sent: Friday, April 21, 2023 11:43 AM To: Corey Bonnell <[email protected]> Cc: CCADB Public <[email protected]> Subject: Re: Broken CRL URLs in CCADB Hi Corey, > Any revocation artifacts issued by the CA in question have no value to the > RP, as the CA itself is not trusted. If the CRL data isn't useful to a relying party, and in some cases isn't even fetchable, is there value in continuing to include the CRL URL in the "AllCertificateRecordsCSVFormat" CSV report? Beyond the CRL question, maybe you can help me to understand why these issuers are included in the report at all. Thanks, On Fri, Apr 21, 2023 at 10:49 AM Corey Bonnell <[email protected] <mailto:[email protected]> > wrote: Hi Daniel, * Is there an expectation that CRL URLs for inactive issuers should remain accessible? If not it may be less confusing to prune the inaccessible content. I assume that “inactive” in this case means that all certificates issued to that CA (name, key tuple) and chain to an Apple- or Mozilla-trusted root are expired or revoked. Even if there were an expectation that such CAs continue to provide revocation information, I struggle to see how maintaining access to that CA’s published revocation information would be valuable to a Relying Party. Relying parties will perform certification path validation on presented certificate chains, and this will fail upon encountering no valid paths from that CA (name, key tuple) back to a trust anchor. Any revocation artifacts issued by the CA in question have no value to the RP, as the CA itself is not trusted. Thanks, Corey From: Daniel McCarney <[email protected] <mailto:[email protected]> > Sent: Wednesday, April 19, 2023 7:45 PM To: CCADB Public <[email protected] <mailto:[email protected]> > Subject: Broken CRL URLs in CCADB Hi folks, Earlier today I posted a message with the same subject[0] to MDSP when it's likely a discussion better suited for this mailing list. Thanks to Rob Stradling for redirecting me to the right place. Rob's replies on MDSP are also valuable, so I'm sad to have forked the discussion. As he notes I didn't do any filtering based on whether affected rows chain up to an active root in participating programs. Is there an expectation that CRL URLs for inactive issuers should remain accessible? If not it may be less confusing to prune the inaccessible content. Thanks, [0]: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/LvbtTeBXRnI/m/lGS4uefZAAAJ > > Hello MDSP community, > > I've been attempting to collect a dataset of CRLs by fetching each CRL URL > present in the "Full CRL Issued By This CA" and "JSON Array of Partitioned > CRLs" columns of the "all certificate records" CSV report available from > CCADB[0]. > > This has uncovered a handful of mis-configurations that I believe should be > remedied. They fall into three categories of failure: > > 1) CRL URLs that return a 403 Forbidden response. > 2) CRL URLs that return a 404 Not Found response. > 3) CRL URLs that return an x509 certificate, not a CRL. > > The failures affect four distinct CA owners: Sectigo, GlobalSign nv-sa, > Entrust, and Autoridad de Certificacion Firmaprofesional. > > I'm disappointed that this is still a problem given Andrew Ayer previously > shared similar results[1] back in September 2022. I would strongly encourage > affected CAs to invest in monitoring of disclosed CRL URLs so that it doesn't > fall to broader Mozilla community to do this work on a regular basis. > > Forbidden responses: > > * CA Owner: Sectigo > * Salesforce Record ID 001o000000poU6CAAU > * CRL URL: http://crl.nicecert.com/eBizNetworksCodeSigningCA.crl > * Salesforce Record ID 001o000000piSaqAAE > * CRL URL: http://crl.nicecert.com/eBizNetworksLASSLCA.crl > > Not found responses: > > * CA Owner: GlobalSign nv-sa > * Salesforce Record ID 0014o00001l1GHoAAM > * CRL URL: http://crl.globalsign.com/ca/gsatlaseccr5ovtlsca202012.crl > * Salesforce Record ID 0011J00001ha3YgQAI > * CRL URL: http://crl.globalsign.com/ca/dpdhlusercai5.crl > * Salesforce Record ID 0014o00001l1GGCAA2 > * CRL URL: http://crl.globalsign.com/ca/gsatlaseccr5dvtlsca202012.crl > * CA Owner: Entrust > * Salesforce Record ID 001o000000p2VbmAAE > * CRL URL: http://crl.entrust.net/class1.crl > > Not a CRL responses: > > * CA Owner: Autoridad de Certificacion Firmaprofesional > * Salesforce Record ID 0018Z00002nth12QAA > * CRL URL: http://crl.firmaprofesional.com/ica-a01-qwac.crt > * Salesforce Record ID 0018Z00002nth2KQAQ > * CRL URL: http://crl.firmaprofesional.com/ica-a02-noqwac.crt > > Thanks, > > - Daniel (@cpu) > > [0]: > https://ccadb-public.secure.force.com/ccadb/AllCertificateRecordsCSVFormat > [1]: > https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/Wm9Sf1AEbig/m/ANbMpBVFBwAJ -- You received this message because you are subscribed to the Google Groups "CCADB Public" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <mailto:[email protected]> . To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/44078b55-141b-4dc5-a7f9-c3e6a7bbaa90n%40ccadb.org <https://groups.google.com/a/ccadb.org/d/msgid/public/44078b55-141b-4dc5-a7f9-c3e6a7bbaa90n%40ccadb.org?utm_medium=email&utm_source=footer> . -- You received this message because you are subscribed to the Google Groups "CCADB Public" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <mailto:[email protected]> . To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CAPSmj0R7qWBX7GEko7L5c3D0mhvRox%3DF6ydAJHgb2%3DU0JxbGmg%40mail.gmail.com <https://groups.google.com/a/ccadb.org/d/msgid/public/CAPSmj0R7qWBX7GEko7L5c3D0mhvRox%3DF6ydAJHgb2%3DU0JxbGmg%40mail.gmail.com?utm_medium=email&utm_source=footer> . -- You received this message because you are subscribed to the Google Groups "CCADB Public" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/DM6PR14MB2186FCBF4A94B680BDF4CE7792609%40DM6PR14MB2186.namprd14.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
