Kurt, As for why transparency information should be published in a place that is under the CAs control, there are arguments to be made for both ways but I believe that doing so would make it practical for real-time data, or near real-time data to be represented and would allow for the data to be machine readable which would enable the data to be used for analyzing the CAs. Mozilla already requires CAs to publish URLs to CRLs and other objects so it seems that this is consistent with that practice as well. With that said I would argue as Mozilla has made no statement on this topic it's too early to discuss implementation details though.
Regarding the question of if we need CAs that issue a few certificates, I do think that is a good question but I think it is outside the scope of the topic of this thread. I will say that I believe there are cases for local CAs and emerging CAs so this is not as cut and dry as some might think. I also do not think that this thread is the right place to learn about the size, shape, and nature of the webPKI and it is most appropriate to stay focused on its topic, namely the concerning behavior, and possibly move the discussion to other efforts like Recommended Best practices or updating the root program requirements. That said here are a few resources that might help you understand the space better: - CCADB.org aggregates a lot of useful data that helps one understand the size and shape of the WebPKI. There are also sites that index CT logs to provide useful information, you can learn more about Certificate Transparency and some of the projects that do use this information at certificate.transparency.dev. Censys is one of the most flexible and complete. - CCADB.org also contains a list of all root and intermediate certificates. <https://ccadb-public.secure.force.com/ccadb/AllCertificateRecordsCSVFormat>I do not have a count of certificates as I don't see much use in it as the security domains they operate in (aka the policies and practices of the organizations) is really the important thing. In many respects, more CAs are better as it suggests the possibility of many security domains in use (reduced surface area). - One that is not listed as a monitor that used to be a great reliable resource is Merkle.Town, which has a few issues right now and I believe they will be fixed but it is still useful. In particular, it is interesting to know that the WebPKI currently operates at about 71 certificates per second and certificates expire at about 66 certificates per second. - I also use both CT and CCADB data to produce a quick market analysis Google <https://docs.google.com/spreadsheets/d/1gshICFyR6dtql-oB9uogKEvb2HarjEVLkrqGxYzb1C4> Sheets. It helps me keep an eye on how the CA market is changing <https://docs.google.com/spreadsheets/d/1gshICFyR6dtql-oB9uogKEvb2HarjEVLkrqGxYzb1C4>. I also published a blog post <https://unmitigatedrisk.com/?p=673> with the methodology I use. As I am referring to this earlier I mentioned the number of CAs off the top of my head I tried to generalize it (approaching 100) the actual number is around 85 based on the Microsoft Root Program as per the related CCADB.org dataset. If you have more questions on the size, nature, and monitoring of the ecosystem I think it would be best to start a new thread. With that said I would say there the WebPKI is more transparent than it has ever been for those that care to look. That is why I wanted to call out this one area where there is clearly a lack of transparency on a practice that is in use today that is clearly not aligned with Mozillas mission, which the Mozilla root program should be squarely supporting via its requirements and guidance to participants in this ecosystem. Ryan On Thu, Mar 2, 2023 at 6:45 PM Kurt Seifried <[email protected]> wrote: > > > On Thu, Mar 2, 2023 at 5:49 PM Ryan Hurst <[email protected]> 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) > [email protected] > -- 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/CALVZKwY6UtSRDUABtMd%2BRRx0%3Dy73_gDejB4-OWFnbH679rtT%2Bg%40mail.gmail.com.
