Hello all! I am speaking in behalf of certSIGN. Regarding the bullet "The CA has physical, monetary, or business nexus to a government of a country that[...] has a score less than 50 on the Corruption Perceptions Index", is correct our understanding that this bullet touches on any company that has a branch in a country that has a score less than 50 on the CPI? For example, all global big tech companies have branches in Romania (R&D, Support, Call Center, Sales etc). Our opinion is that if a CA is in this situation, but it proves to implement anti-corruption mechanisms, for example is ISO37001 certified, this criterion should not be applicable in this case.
Cristian Pe vineri, 3 martie 2023, la 06:27:44 UTC+2, Ryan Hurst a scris: > 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 <ku...@seifried.org> wrote: > >> >> >> On Thu, Mar 2, 2023 at 5:49 PM Ryan Hurst <ryan....@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) >> ku...@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/41599649-a470-4c11-abee-4c756c7e0bc3n%40mozilla.org.
