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]>
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]>
> *Sent:* Wednesday, April 19, 2023 7:45 PM
> *To:* CCADB Public <[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].
> 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].
To view this discussion on the web visit 
https://groups.google.com/a/ccadb.org/d/msgid/public/CAPSmj0R7qWBX7GEko7L5c3D0mhvRox%3DF6ydAJHgb2%3DU0JxbGmg%40mail.gmail.com.

Reply via email to