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 On Tuesday, August 3, 2021 at 9:22:27 AM UTC-7 [email protected] wrote: > 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 > > -- You received this message because you are subscribed to the Google Groups "[email protected]" 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/mozilla.org/d/msgid/dev-security-policy/e1519dfe-f2c4-48e6-bc34-d55e3f3fc6adn%40mozilla.org.
