The language of the BRs is pretty permissive. Assuming Mozilla didn't update its policy, then issuance would be permitted if the CA can show that the following was false:
b. semantics that, if included, will mislead a Relying Party about the certificate information verified by the CA (such as including extendedKeyUsage value for a smart card, where the CA is not able to verify that the corresponding Private Key is confined to such hardware due to remote issuance).. I think this is section you are citing as prohibiting issuance correct? So as long as the CA can show that this is not true, then issuance is permitted under the current policy. -----Original Message----- From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> On Behalf Of Ryan Sleevi via dev-security-policy Sent: Friday, July 12, 2019 3:01 PM To: Doug Beattie <doug.beat...@globalsign.com> Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org>; Wayne Thayer <wtha...@mozilla.com> Subject: Re: Logotype extensions Alternatively: There is zero reason these should be included in publicly trusted certs used for TLS, and ample harm. It is not necessary nor essential to securing TLS, and that should remain the utmost priority. CAs that wish to issue such certificates can do so from alternate hierarchies. There is zero reason to assume the world of PKI is limited to TLS, and tremendous harm has been done to the ecosystem, as clearly and obviously demonstrated by the failures of CAs to correctly implement and validate the information in a certificate, or timely revoke them. The fact that were multiple CAs who issued certificates like “Some-State” is a damning indictment not just on those CAs, but in an industry that does not see such certificates as an existential threat to the CAs relevance. It is trivial to imagine how to issue such certificates from non-TLS hierarchies, and to have those still usable by clients. Any CA that can’t think of at least three ways to do that has no business in this industry - because it is truly basic application of existing technologies. The BRs do not permit this. Just like they don’t permit a lot of things that CAs are unfortunately doing. If the CA portion of the industry wants to improve things, such that a single CA could reasonably be believed to be competent enough to issue such certificates, let alone reasonably validate them (as this has been a global challenge for well over a hundred years), perhaps getting the basics right, and formalizing best practices in a way that the whole industry can improve, is a better starting point. I get some folks want to argue this is special, because they want it to be. This is no different than why it’s problematic to have payment terminals using publicly trusted TLS certs, no different than why having drone PKI use a different than profile than TLS, and why having certificate profiles like QWACs or PSD2 not be used for TLS. The quicker we internalize that, the better we can move to having useful and specialized PKIs, instead of the actively harmful attempts, actively dangerous, actively problematic to put it all in a single cert, which they were never intended to do. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
