CCADB Update: New field JSON Array of Partitioned CRLs

[Kathleen Wilson]

All,

Now on root and intermediate certificate pages,  the ‘Pertaining to Certificates Issued by this CA’ section contains two fields:

1) Full CRL Issued By This CA

2) JSON Array of Partitioned CRLs

The new 'JSON Array of Partitioned CRLs' field is intended to be used when there is no full CRL, so CAs can provide a JSON array whose elements are URLs of partitioned, DER-encoded CRLs that when combined are the equivalent of a full CRL.
Example:
[ "http://cdn.example/crl-1.crl", "http://cdn.example/crl-2.crl" ]

I updated the ccadb.org website to add information about revocation fields: https://www.ccadb.org/cas/fields#revocation-information

The API for updating intermediate certificates has also been updated with this new field. (API documentation)

Note:  In the CA/Browser Forum virtual face-to-face meeting last March, Clint indicated that Apple plans to require that at least one of these two fields contain the full CRL information for non-TLS-issuing CAs. (Mozilla does not currently have any requirements pertaining to these two fields.)

Please let me know if you have any questions or concerns about these changes.

Thanks,

Kathleen

[Kathleen Wilson]

All,

For some CAs the 'JSON Array of Partitioned CRLs' field will need to allow for up to 20,000 characters.

Do any of you need the 'JSON Array of Partitioned CRLs' field to be larger than 20,000 characters?

Does it make sense to store such large arrays of partitioned CRL URLs directly in the CCADB? Or for such large arrays would it be better to allow for CAs to put their JSON arrays into a file and just provide the URL to that file containing the array?

Thanks,

Kathleen

[Ryan Sleevi]

On Fri, Jun 11, 2021 at 5:11 PM Kathleen Wilson <kwi...@mozilla.com> wrote:

Does it make sense to store such large arrays of partitioned CRL URLs directly in the CCADB? Or for such large arrays would it be better to allow for CAs to put their JSON arrays into a file and just provide the URL to that file containing the array?

The question of "array of URLs" vs "URL of array of URLs" came up during the previous discussion (I'm definitely team "Array of URLs")

To your question about size limitations: I think the history of the Web PKI has shown us that the more flexibility we allow, the greater the issues we discover later on. So I'm definitely team "pick a limit that Mozilla/CCADB members are willing to live with" (and even there, I'm team "small limit"), and then if/as CAs encounter issues, there can be discussion about the relative value of the use cases they're trying to address versus the risks/complexity to the community. I really appreciate Let's Encrypt's engagement in the previous discussion, because it touched on a lot of architectural design elements for CRL services that were very useful, not only for other CAs, but the community at large. Following that model for any changes/extensions to the field seems like a desirable outcome, and the interim can be met with a sensible limit. 

[Santiago Brox]

I may agree. But the question arises as to how and how often the information in CCADB should be updated as new partitioned CRLs are generated. I guess the most reasonable thing is to have an additional full CRL for non-tls certificates.

[Kathleen Wilson]

All,

The CCADB has been updated as follows:

• Updated the ‘JSON Array of Partitioned CRLs’ field to increase the maximum number of characters to 20,000.
• Updated the API to all for up to 20,000 characters in this field
  
• Renamed the ‘Pertaining to Certificates Issued by this CA’ section to ‘Pertaining to Non-TLS Certificates Issued by this CA’. Also updated the corresponding help text and the instructions at www.ccadb.org/cas/fields to indicate that these full CRL fields are currently intended for the full CRLs pertaining to Non-TLS certificates.

Thanks,

Kathleen

[Ryan Hurst]

Kathleen,

For clarity's sake, it may make sense to update the text to make it clear that this requirement extends to SXG certificates which some may presume are "non-TLS" which I believe would be an invalid interpretation.

I would also be interested to understand if you believe the non-TLS certificate limitation is currently intended to be the first phase of this requirement and similarly if there would be any issue if a CA included more than non-TLS certificates when they implemented this new requirement.

Ryan Hurst

[Kathleen Wilson]

Hi Ryan,

Thank you for your feedback.

How about ‘Pertaining to Certificates Issued by this CA that Cannot be used for TLS Server Authentication’?

If needed, we can add text to the top of that section explaining more. Just let me know what you think is needed to fully clarify.

You are correct... The non-TLS limitation is currently intended to be the first phase of this requirement. While root store operators can collect TLS CRL information from CT, it will be much better to have CAs provide it directly. So, as browsers improve their revocation checking, I expect our requirements in this area to also change.

I have a few questions for CAs about that...

1) Is it reasonable to have CAs provide full CRLs (or JSON arrays) for TLS-Server-Auth certificates that is separate from the full CRLs for everything else?

i.e. via different fields in the CCADB?

2) I would like to have non-overidable errors for TLS-Server-Auth certificates that have been revoked for the keyCompromise, cACompromise, and affiliationChanged CRL revocation reason codes. Currently CRL reason codes for TLS end-entity certs "SHOULD" be provided, but I would like the reason codes to be required under the applicable circumstances.

Do CAs currently use those reason codes when applicable?

Do you think the BRs need to further specify when those reason codes must and must not be used?

Thanks,

Kathleen

[Ryan Hurst]

Hi Kathleen,

I think your language works but I believe we have some language in other WebPKI related documentation that refers to the concept of "TLS capable" certificates. Adopting this language might be sufficient and be consistent with other wording in use. I believe this would make it clear that certificates like SGX that are "not TLS certificates" but are "TLS capable" are explicitly within scope.

As for your questions regarding the reasonableness of providing the full CRLs and/or the JSON array of all CRLs; I personally think it's doable as framed. 

Some thoughts on that since you asked..... providing full CRLs is problematic, especially when revoke/replace is used because the CRLs grow very quickly taxing all relying parties' bandwidth. Rolling issuing CAs regularly can create implicit creating CRL shards but is taxing for the CA to maintain due to manual nature of that process. This leads CAs down the path of CRL sharding, and the JSON array approach accommodates this pattern just fine. I would personally rather see a well-known location be published and that location be incorporated into CCADB vs putting the JSON itself in CCADB in that it complicates the rollout for CAs because they now maintain an online dependency on CCADB but the current proposal is workable.

Regarding your goal of non-overidable errors for a subset of reason codes; I think this is a laudable goal but reason codes have a number of problems I struggle with. 

The first in my experience the subscriber generally do not provide this information, unless forced to. The problem with this is that they don't necessarily understand what each means and may provide the wrong value and possibly choose a value that is not included in the enforced set of reasons and not get the expected behavior. A few years ago I wrote about this here: https://unmitigatedrisk.com/?p=583.

The second reason is that these codes in a blocking fashion introduce a user tax that impacts those that pay for internet based on usage and those that have slow internet. With that said the inclusion of reason codes is already needed for the mega CRLs that are deployed already so I do not worry about the impact of this requirement on CAs.

So to your specific questions:

1. Do CAs currently use those reason codes when applicable?

It is my belief that when provided to them they do include this information but it is unclear if they force providing this information.

2. Do you think the BRs need to further specify when those reason codes must and must not be used?

I do.

Ryan Hurst

[Dimitris Zacharopoulos]

On 20/7/2021 12:39 π.μ., Kathleen Wilson wrote:
> Renamed the ‘Pertaining to Certificates Issued by this CA’ section to
> ‘Pertaining to Non-TLS Certificates Issued by this CA’. Also updated
> the corresponding help text and the instructions at
> www.ccadb.org/cas/fields to indicate that these full CRL fields are
> currently intended for the full CRLs pertaining to Non-TLS certificates.

Dear Kathleen,

Does this mean that this field must be populated for CAs that are not
technically capable of issuing a TLS Certificate (i.e. Technically
Constrained in line with section 7.1.5 of the BRs)?

If I recall correctly, the Apple Root Program requires this field to be
populated for CAs issuing TLS Certificates and it made sense to extend
it for all CAs. Does this change also align with the Apple Root Program
that also uses CCADB?


Thanks,
Dimitris.

[Ryan Hurst]

It has been brought to my attention I did not explicitly declare that the comments, requests for clarifications, and opinions I shared on this thread were in a personal capacity, this was an oversight.

Ryan Hurst

(Personal)

[Clint Wilson]

Hi Dimitris,

The Apple Root Program intends to use this field for all certificates in the future, but our focus at the moment is on non-TLS certificates, so this change aligns well for us right now.

Cheers!
-Clint

> --
> You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
> To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/1fa515ca-bbf9-2ef6-8aac-6fe1682ee9f6%40it.auth.gr.