On Thu, Mar 2, 2023 at 5:49 PM Ryan Hurst <ryan.hu...@gmail.com> wrote:
> I concur that censorship should be carried out transparently, with > comprehensive policies documented in their CPS and any applications of that > policy be published in a discoverable manner. For instance, when censorship > is the reason for an order being rejected, detailed errors should be > published, and possibly a CENSORED.TXT file could be published in a > well-known location, similar to how SECURITY.TXT is used to identify > security contacts. > I feel like transparency is key here, but I would suggest instead of scattering these all over the web, shouldn't root CA's tell Mozilla what their issuing/censorship/etc policy(s) are and have it as part of their document set with Mozilla? And if it changes they should update Mozilla. I feel like there is far too much "I got audited once, sure things change, maybe significantly (hey we bought a spyware company!), but I don't have to tell you. I just have to pass my next audit" > I also believe that when a CA serves only a narrow or specific community, > its CPS should explicitly state this. This raises questions about whether > such entities should be included in the Mozilla root program, which is > designed to serve the broader Mozilla community. However, that is a > separate discussion. > Has anyone taken the certificate transparency logs for root CA's and generated any stats? E.g. here's the ~140 root CA's, here's how many certs they issued for unique websites/code signing/email (we only have web data right?) in 2022, here's how many intermediate CA's they support, roughly how many certs they issued. I'm reminded of the CVE program where roughly one quarter of the CVE Numbering Authorities that ever existed have done <10 CVE ID's in their entire existence and another quarter have done 10-50. Out of 242,000 CVEs assigned (reserved/rejected/public). Do we really need root CA's that only issue a handful of certificates? I suspect for some, especially those run by governments, it is "cheaper" to become a root CA (and pay for audits which can be justified) than an intermediate CA (where you also have to pay a root CA). > Regardless of the outcome of this discussion, I think it is appropriate to > document Mozilla's stance. This could involve adding text on Concerning > Behavior, Recommending Best Practices, or updating the root program > requirements themselves. Given the various gray areas that exist in this > topic, It was my belief the non-binding nature of"Concerning Behavior" was > appropriate which is why I mentioned it here. This is because my > understanding is that this is a section of "considerations" not > "prohibitions". > I feel like we need to shine a light on a lot of this. I've been into SSL/TLS for over 2 decades ( https://it.slashdot.org/story/00/12/18/0759236/attacks-against-ssh-1-and-ssl was a good one, I miss the old days) and root CA's for over a decade (see list archives) and I can confidently say "I know barely anything and specific CA's? Less than barely anything". > > Ryan Hurst > -- Kurt Seifried (He/Him) k...@seifried.org -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CABqVa3803zMiN%2Br7WjRictWccyetxk-ME9Pu4TibAeUTj0V_JA%40mail.gmail.com.
