Thanks for the additional context, Ben. Given the comment that you linked to, it appears that there’s a possibility that Mozilla will support sharded CRLs and that there may be logic included in the CRLLite crawler to timeout and remove the issuing CA from the crawler configuration if CRL-fetching times out.
I have a few follow-up questions and concerns: 1. As we know from the list of Problem Reporting Mechanisms produced from CCADB, the information provided by CAs is on a “best-effort” basis that carries no obligation by the CA to timely respond to requests if the Mechanism is not listed in section 1.5.2 of their CPS. What policy changes will be formulated to obligate the CA to provide accurate URL pointers in CCADB where CRL-based revocation information can be found for end-entity certificates that have no CRLDP extension? 2. What are the expectations regarding availability for such revocation information? Do the availability requirements in BR 4.10.2 stand for these CRLs even if such CRL pointers are not encoded in end-entity certificates? 3. Is the JSON-based sharding specification acceptable by the other Root Programs, or will CAs be required to produce complete CRLs for consumption by other Root Programs? 4. Given that CRLLite is not used in Thunderbird, it appears that the scope of disclosure is only for those CAs that are capable of TLS certificate issuance. Is this a correct assumption? Thanks, Corey From: Ben Wilson <bwil...@mozilla.com> Sent: Thursday, November 19, 2020 6:14 PM To: Ryan Hurst <ryan.hu...@gmail.com>; Corey Bonnell <corey.bonn...@digicert.com> Cc: Mozilla <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: CCADB Proposal: Add field called Full CRL Issued By This CA FWIW - Here is a recent post on this issue from JC Jones - https://github.com/mozilla/crlite/issues/43#issuecomment-726493990 <https://github.com/mozilla/crlite/issues/43#issuecomment-726493990> On Thu, Nov 19, 2020 at 4:00 PM Ryan Hurst via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: On Wednesday, November 18, 2020 at 8:26:50 PM UTC-8, Ryan Sleevi wrote: > On Wed, Nov 18, 2020 at 7:57 PM Ryan Hurst via dev-security-policy < > dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org> > > wrote: > > > Kathleen, > > > > This introduces an interesting question, how might Mozilla want to see > > partial CRLs be discoverable? Of course, they are pointed to by the > > associated CRLdp but is there a need for a manifest of these CRL shards > > that can be picked up by CCADB? > > > What's the use case for sharding a CRL when there's no CDP in the issued > certificates and the primary downloader is root stores? I think there may be some confusion. In my response to Kathleen's mail I stated " Of course, they are pointed to by the associated CRLdp", as such I am not suggesting there is a value to sharded/partitioned CRLs if not referenced by the CRLdp. The origin of my question is that as I remember the requirements, CAs do not have to produce a full and complete CRL. Specifically today, I believe they are allowed to produce partitioned CRLs, this is good because in some cases a full and complete CRL can be gigabytes in size. I assume the reason for adding the URL to a full, and I imagine complete, CRL is that Mozilla would like to use this information in its CRLLite feature. If so, and a CA partitions CRLs and does not produce a full and complete CRL how should the CA ensure Mozilla has the entire set of information it wants? Ryan _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
