RE: Logotype extensions
We've beaten the stuffing out of Logotype, imho. - CAs want to add it - Root stores don't - The BRs permit it (probably). - I'll report you to the DoJ, - I'll revoke our Roots, - bla bla bla My personal view is that CAs should be able to include data in extensions as long as they document how they validate it in their CPS. I understand and agree that using existing Subject DN attributes is dangerous, but using custom extensions to convey data should be fine. If you understand how to decode it, then you understand what it is and to what extent you can trust it based on the CA CPS, right? Wayne, your initial proposal was this: Due to the risk of misleading Relying Parties and the lack of defined validation standards for information contained in this field, as discussed here [2], CAs MUST NOT include the RFC 3709 Logotype extension in CA or Subscriber certificates. I'm guessing you have concerns beyond just logos but picked on this one because of the thread. I think we should move on and: - work on a standardized way to represent Logos along with the associated validation of the contents. - apply this same logic (define standard validation rules and well-structured formatting) to other things that we need to include (or that we are already including like LEIs). I'm certain that there are even more industry uses for certain (not misleading) values in the OU, and those are excellent candidates for including in a uniform way, just like we did for PSD2 data. As long as we have a well defined data structure and a definition for how the data was validated, I don't believe that we should be concerned with how strongly the data was validated (leave that up to the application or person consuming the data based on the stated validation method). Doug -Original Message- From: dev-security-policy On Behalf Of Phillip Hallam-Baker via dev-security-policy Sent: Thursday, July 11, 2019 11:53 PM To: Wayne Thayer Cc: mozilla-dev-security-policy ; hous...@vigilsec.com Subject: Re: Logotype extensions On Thu, Jul 11, 2019 at 12:19 PM Wayne Thayer wrote: > On Wed, Jul 10, 2019 at 7:26 PM Phillip Hallam-Baker < > ph...@hallambaker.com> wrote: > >> Because then the Mozilla ban will be used to prevent any work on >> logotypes in CABForum and the lack of CABForum rules will be used as >> pretext for not removing the ban. >> >> I have been doing standards for 30 years. You know this is exactly >> how that game always plays out. >> > > Citation please? The last two examples I can recall of a Browser > clarifying or overriding CAB Forum policy are: > 1. banning organizationIdentifier - resulting in ballot SC17 [1] , > which properly defines the requirements for using this Subject attribute. > 2. banning domain validation method #10 - resulting in the ACME TLS > ALPN challenge [2], which is nearly through the standards process. > > In both examples, it appears that Browser policy encouraged the > development of standards. > It is what happened when I proposed logotypes ten years ago. > If you don't want to use the extension, that is fine. But if you > attempt >> to prohibit anything, ruin it by your lawyers first and ask them how >> it is not an a restriction on trade. >> >> It is one thing for CABForum to make that requirement, quite another >> for Mozilla to use its considerable market power to prevent other >> browser providers making use of LogoTypes. >> > > If this proposal applied to any certificate issued by a CA, I might > agree, but it doesn't. CAs are free to do whatever they want with > hierarchies that aren't trusted by Mozilla. It's not clear to me how a > CA would get a profile including a Logotype through a BR audit, but > that's beside the point. > Since Mozilla uses the same hierarchies that are used by all the other browsers and are the only hierarchies available, I see a clear restraint of trade issue. It is one thing for Mozilla to decide not to use certain data in the certificate, quite another to prohibit CAs from providing that data to other parties. The domain validation case is entirely different because the question there is how data Mozilla intends to rely on is validated. A better way to state the requirement is that CAs should only issue logotypes after CABForum has agreed validation criteria. But I think that would be a mistake at this point because we probably want to have experience of running the issue process before we actually try to standardize it. >>> I would be amenable to adding language that permits the use of the >>> Logotype extension after the CAB Forum has adopted rules governing its use. >>> I don't see that as a material change to my proposal because, either >>> way, we have the option to change Mozilla's position based on our >>> assessment of the rules established by the CAB Forum, as documented >>> in policy section 2.3 "Baseline Requirements Conformance". >>> >>> I do not believe that changing the "MUS
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
RE: Logotype extensions
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 On Behalf Of Ryan Sleevi via dev-security-policy Sent: Friday, July 12, 2019 3:01 PM To: Doug Beattie Cc: mozilla-dev-security-policy ; Wayne Thayer 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
Re: Logotype extensions
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 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 > On Behalf Of Ryan Sleevi via dev-security-policy > Sent: Friday, July 12, 2019 3:01 PM > To: Doug Beattie > 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 > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
