CCADB Proposal: Add field called Full CRL Issued By This CA

[Kathleen Wilson]

All,

Root store operators would like to easily find and use the URLs to the
Full CRLs for things like Mozilla’s CRLite. The BRs do not require CRL
URLs in end-entity certificates, and many CAs use partitioned CRLs for
end-entity certificates.

Proposal: Add field called 'Full CRL Issued By This CA'

- New field on intermediate certificate records which may be filled in
by CAs or root store operators when the certificate signs certificates
that do not contain CRL URLs or only contain URLs to partitioned CRLs.

- This field would be included in public-facing reports such as
http://ccadb-public.secure.force.com/ccadb/AllCertificateRecordsCSVFormat
so that it can be used programmatically by root store operators, and
could also be provided in crt.sh.

- Also add this field to root certificate records, even though only root
store operators can currently update root certificate records.


I will appreciate your input on this proposal.

Thanks,
Kathleen

[Kathleen Wilson]

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

[Ryan Hurst]

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

[Ryan Sleevi]

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?

[Corey Bonnell]

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

[Ryan Hurst]

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

[Ben Wilson]

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:

> 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
>

[Ryan Hurst]

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

[Corey Bonnell]

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 <bwi...@mozilla.com>
Sent: Thursday, November 19, 2020 6:14 PM
To: Ryan Hurst <ryan....@gmail.com>; Corey Bonnell <Corey....@digicert.com>
Cc: Mozilla <mozilla-dev-s...@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-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org> > wrote:

On Wednesday, November 18, 2020 at 8:26:50 PM UTC-8, Ryan Sleevi wrote:

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 <mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

[cli...@apple.com]

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