Re: CCADB Proposal: Add field called Full CRL Issued By This CA
Hi Corey, From Apple’s perspective, the desire was first to have the field added to CCADB. From here, we’re planning on sending out a CA Communication notifying CAs that the field is available and requesting that CAs populate it. We are considering a requirement that Full CRLs be made available, but there are still issues to address and work out with the community prior to doing so. Our goal is to have CAs provide CRLs such that we can be confident all revoked leaf certificates and intermediate CAs which chain to Roots present in our program are represented by a CRL provided by the CA Organization. In many cases, a Full CRL is the most direct way of doing so, but a pointer to a full set of partitioned CRLs should also be sufficient as a secondary option. Thanks, -Clint On Thursday, November 19, 2020 at 12:27:55 PM UTC-8, corey@digicert.com wrote: > Hi Kathleen, > Thank you for posting the notification concerning the update to CCADB. I have > a follow-up question: in the discussion captured in > https://github.com/mozilla/pkipolicy/issues/218, it appears that there's a > desire for CAs to produce and publish complete CRLs for end-entity > certificates that lack CRLDP to a complete CRL. However, I have not seen any > concrete proposals/draft language for inclusion in 2.7.1 surrounding such a > requirement. Is the thinking that this CCADB field will first be added and > then in a subsequent Mozilla policy update, CAs will be required to publish > full CRLs (perhaps as part of a CA/B Forum ballot) and disclose the location > of such CRLs in CCADB? > > Thanks, > Corey > On Wednesday, November 18, 2020 at 6:07:32 PM UTC-5, Kathleen Wilson wrote: > > All, > > > > The following changes have been made in the CCADB: > > > > On Intermediate Cert pages: > > - Renamed section heading ‘Revocation Information’ to ‘Revocation > > Information for this Certificate’ > > - Added section called ‘Pertaining to Certificates Issued by this CA’ > > - Added 'Full CRL Issued By This CA' field to this new section. > > Note: CAs modify this field directly on intermediate cert pages. > > > > On Root Cert pages: > > - Added section called ‘Pertaining to Certificates Issued by this CA’ > > - Added 'Full CRL Issued By This CA' field to this new section. > > Note: Only root store operators may directly update root cert pages, so > > send email to your root store operator if you would like a URL added to > > this new field for a root cert. > > > > > > Coming soon: > > Add 'Full CRL Issued By This CA' column to report: > > http://ccadb-public.secure.force.com/ccadb/AllCertificateRecordsCSVFormat > > > > > > Thanks, > > Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: CCADB Proposal: Add field called Full CRL Issued By This CA
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 Sent: Thursday, November 19, 2020 6:14 PM To: Ryan Hurst ; Corey Bonnell Cc: Mozilla 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 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
Re: CCADB Proposal: Add field called Full CRL Issued By This CA
On Thursday, November 19, 2020 at 3:13:58 PM UTC-8, Ben Wilson wrote: > FWIW - Here is a recent post on this issue from JC Jones - > 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-secur...@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> 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-secur...@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > I think the JSON array approach works and it addresses the concerns I had, specifically: 1. How do we make sure Mozilla has all the revocation data when a sharded/partitioned CRL approach is used. 2. How do we not force those CCAs that are doing sharded/partitioned CRLs from having to also maintain full CRLs which can be VERY big which has logistic challenges to distribute reliably and usably. Maybe we can say such CAs provide a list to this JSON document in CCADB Full CRL field? Ryan ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 On Thu, Nov 19, 2020 at 4:00 PM Ryan Hurst via dev-security-policy < 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> 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 > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CCADB Proposal: Add field called Full CRL Issued By This CA
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> 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 https://lists.mozilla.org/listinfo/dev-security-policy
Re: CCADB Proposal: Add field called Full CRL Issued By This CA
Hi Kathleen, Thank you for posting the notification concerning the update to CCADB. I have a follow-up question: in the discussion captured in https://github.com/mozilla/pkipolicy/issues/218, it appears that there's a desire for CAs to produce and publish complete CRLs for end-entity certificates that lack CRLDP to a complete CRL. However, I have not seen any concrete proposals/draft language for inclusion in 2.7.1 surrounding such a requirement. Is the thinking that this CCADB field will first be added and then in a subsequent Mozilla policy update, CAs will be required to publish full CRLs (perhaps as part of a CA/B Forum ballot) and disclose the location of such CRLs in CCADB? Thanks, Corey On Wednesday, November 18, 2020 at 6:07:32 PM UTC-5, Kathleen Wilson wrote: > All, > > The following changes have been made in the CCADB: > > On Intermediate Cert pages: > - Renamed section heading ‘Revocation Information’ to ‘Revocation > Information for this Certificate’ > - Added section called ‘Pertaining to Certificates Issued by this CA’ > - Added 'Full CRL Issued By This CA' field to this new section. > Note: CAs modify this field directly on intermediate cert pages. > > On Root Cert pages: > - Added section called ‘Pertaining to Certificates Issued by this CA’ > - Added 'Full CRL Issued By This CA' field to this new section. > Note: Only root store operators may directly update root cert pages, so > send email to your root store operator if you would like a URL added to > this new field for a root cert. > > > Coming soon: > Add 'Full CRL Issued By This CA' column to report: > http://ccadb-public.secure.force.com/ccadb/AllCertificateRecordsCSVFormat > > > Thanks, > Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CCADB Proposal: Add field called Full CRL Issued By This CA
On Wed, Nov 18, 2020 at 7:57 PM Ryan Hurst via dev-security-policy < dev-security-policy@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? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CCADB Proposal: Add field called Full CRL Issued By This CA
On Wednesday, November 18, 2020 at 3:07:32 PM UTC-8, Kathleen Wilson wrote: > All, > > The following changes have been made in the CCADB: > > On Intermediate Cert pages: > - Renamed section heading ‘Revocation Information’ to ‘Revocation > Information for this Certificate’ > - Added section called ‘Pertaining to Certificates Issued by this CA’ > - Added 'Full CRL Issued By This CA' field to this new section. > Note: CAs modify this field directly on intermediate cert pages. > > On Root Cert pages: > - Added section called ‘Pertaining to Certificates Issued by this CA’ > - Added 'Full CRL Issued By This CA' field to this new section. > Note: Only root store operators may directly update root cert pages, so > send email to your root store operator if you would like a URL added to > this new field for a root cert. > > > Coming soon: > Add 'Full CRL Issued By This CA' column to report: > http://ccadb-public.secure.force.com/ccadb/AllCertificateRecordsCSVFormat > > > Thanks, > Kathleen 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? Ryan ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CCADB Proposal: Add field called Full CRL Issued By This CA
All, The following changes have been made in the CCADB: On Intermediate Cert pages: - Renamed section heading ‘Revocation Information’ to ‘Revocation Information for this Certificate’ - Added section called ‘Pertaining to Certificates Issued by this CA’ - Added 'Full CRL Issued By This CA' field to this new section. Note: CAs modify this field directly on intermediate cert pages. On Root Cert pages: - Added section called ‘Pertaining to Certificates Issued by this CA’ - Added 'Full CRL Issued By This CA' field to this new section. Note: Only root store operators may directly update root cert pages, so send email to your root store operator if you would like a URL added to this new field for a root cert. Coming soon: Add 'Full CRL Issued By This CA' column to report: http://ccadb-public.secure.force.com/ccadb/AllCertificateRecordsCSVFormat Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
