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) On Tuesday, August 3, 2021 at 10:26:50 AM UTC-7 Ryan Hurst wrote: > 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/bd6e884c-9c34-494a-9f20-002380280e12n%40mozilla.org.
