Like I said, expect to defend this in House and Senate hearings.
This is a restraint of trade. You are using your market power to impede
development of the market.
Mozilla corp made no complaint when VeriSign deployed Issuer LogoTypes.
On Tue, Jul 16, 2019 at 8:17 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> It seems to me that this discussion has veered away from the original
> question, which was seeking consent to "experiment" with logotypes in
> publicly-trusted certificates. I don't think there is much doubt that RFC
> 3709 has been and can be implemented, and as pointed out, it can be tested
> in private hierarchies. I fail to understand the point of this type of
> "experiment", especially when it leaves all of the difficult questions -
> such as global trademark validation and the potential to mislead users -
> unanswered. The risks of permitting such "experimentation" appear to far
> outweigh the benefits.
>
> The discussion has morphed into a question of a CA's right to encode
> additional information into a publicly-trusted certificate, beyond the
> common profile defined in the BRs, for use in a subset of Browsers or other
> client software. The argument here seems to be that BR 7.1.2.4(b)
> ("semantics that, if included, will mislead a Relying Party about the
> certificate information") can't be triggered if the user agent doesn't
> understand the data, or that there needs to be proof that the data is
> misleading (versus could be misleading) to trigger that clause. This seems
> like a much more difficult problem to solve, and one that doesn't need to
> be addressed in the context of the original question.
>
> Given this, and the fact that I believe it is in everyone's best interest
> to resolve the current ambiguity over Mozilla's policy on logotypes, I
> again propose to add logotype extensions to our Forbidden Practices[1], as
> follows:
>
> ** Logotype Extension **
> 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 will greatly appreciate additional feedback on my analysis and proposal.
>
> - Wayne
>
> [1] https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices
> [2]
>
> https://groups.google.com/d/msg/mozilla.dev.security.policy/nZoK5akw2c8/ZtF0WZY8AgAJ
>
> On Fri, Jul 12, 2019 at 2:26 PM Ryan Sleevi <r...@sleevi.com> wrote:
>
> > 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 <
> jeremy.row...@digicert.com>
> > 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 <
> 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
> >>
> >
> _______________________________________________
> 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
