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
            • Re: Log... Phillip Hallam-Baker via dev-security-policy
            • Fwd: Lo... Phillip Hallam-Baker via dev-security-policy
            • Re: Log... Wayne Thayer via dev-security-policy
            • Re: Log... Phillip Hallam-Baker via dev-security-policy
            • Re: Log... Wayne Thayer via dev-security-policy
            • Re: Log... Phillip Hallam-Baker via dev-security-policy
            • Logotyp... Phillip Hallam-Baker via dev-security-policy
            • Re: Log... Wayne Thayer via dev-security-policy
            • Re: Log... Phillip Hallam-Baker via dev-security-policy
            • RE: Log... Doug Beattie via dev-security-policy
            • Re: Log... Ryan Sleevi via dev-security-policy
            • RE: Log... Jeremy Rowley via dev-security-policy
            • Re: Log... Ryan Sleevi via dev-security-policy
            • Re: Log... Wayne Thayer via dev-security-policy
            • Re: Log... Phillip Hallam-Baker via dev-security-policy
            • Fwd: Lo... Phillip Hallam-Baker via dev-security-policy
          • Re: Logotype... kirkhalloregon--- via dev-security-policy
            • Re: Log... Corey Bonnell via dev-security-policy
  • Re: Logotype extensions kirkhalloregon--- via dev-security-policy

Reply via email to