And they will mislead relying parties. Which is why you cannot use *this* particular extension. Sorry, that ship sailed in 2005.
A CA that would be remotely be considering exercising this clause would strongly benefit from checking with the Root stores they’re in, no matter the extension proposed. It’s also Subject Identifying Information. On Fri, Jul 12, 2019 at 5:11 PM Jeremy Rowley <[email protected]> wrote: > 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 <[email protected]> > On Behalf Of Ryan Sleevi via dev-security-policy > Sent: Friday, July 12, 2019 3:01 PM > To: Doug Beattie <[email protected]> > Cc: mozilla-dev-security-policy < > [email protected]>; Wayne Thayer < > [email protected]> > 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 > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
