Re: Logotype extensions
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 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
> >> 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
Re: Logotype extensions
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 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
> 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
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
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
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
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 beca
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 "MUST NOT" to "SHOULD NOT" reflects >>> the consensus reached in this thread. >>> >>> I also do not believe that publicly-trusted certificates are the safe >>> and prudent vehicle for "running the issue process before we actually try >>> to standardize it". >>> >> >> You are free to ignore any information in a certificate. But if you >> attempt to limit information in the certificate you are not intending to >> use in your product, you are arguably crossing the line. >> >> > It's quite clear from the discussions I've been involved in that at least > one goal for Logotypes is that Browsers process them. You implied so > yourself above by stating that this proposal would "prevent other browser > providers making use of LogoTypes." So you are now suggesting that Browsers > ignore this information while others are suggesting precisely the opposite. > Mozilla is free to make the choice to ignore it. If you want to go ahead and use your significant market power to prevent the logotypes being added to other browsers to use them and are confident that it is compliant with US anti-trust law, EU competition law (and the 27 member states) plus any other state you may have picked a fight with recently, well go ahead. In case you hadn't noticed, there is a storm brewing over 'big-tech' on capitol hill. It is not yet clear which issues are going to be picked up or by whom. It is not certain that the WebPKI will be the focus of that but I would not count on avoiding it. It would be prudent for every party with significant market power to constantly ask themselves if they would be comfortable justifying their positions in a House or Senate hearing. > If publicly-trusted certificates containing Logotypes are issued prior to > some agreement on the rules, then we have created a "legacy" problem and > made it more difficult for Browsers to support them. And again, there is a > simple solution to this problem: don't issue certs with Logotypes from a > Mozilla-trusted hierarchy until validation standards are in place. > Certificates have issue
Re: Logotype extensions
On Wed, Jul 10, 2019 at 7:26 PM Phillip Hallam-Baker wrote: > > On Wed, Jul 10, 2019 at 6:11 PM Wayne Thayer wrote: > >> On Wed, Jul 10, 2019 at 2:31 PM Phillip Hallam-Baker < >> ph...@hallambaker.com> wrote: >> >>> On Wed, Jul 10, 2019 at 4:54 PM Wayne Thayer via dev-security-policy < >>> dev-security-policy@lists.mozilla.org> wrote: >>> Russ, > Perhaps one of us is confused because I think we're saying the same thing - that rules around inclusion of Logotype extensions in publicly-trusted certs should be in place before CAs begin to use this extension. >>> >>> I don't see how your proposed ban on logotypes is consistent. What that >>> would do is set up a situation in which it was impossible for CABForum to >>> develop rules for logotypes because one of the browsers had already banned >>> their use. >>> >>> >> How exactly does a Browser banning the use of an extension prevent the >> CAB Forum from developing rules to govern the use of said extension? If >> anything, it would seem to encourage the CAB Forum to take on that work. >> Also, as has been discussed, it is quite reasonable to argue that the >> inclusion of this extension is already forbidden in a BR-compliant >> certificate. >> > > 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. 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. > > > > >> 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 "MUST NOT" to "SHOULD NOT" reflects >> the consensus reached in this thread. >> >> I also do not believe that publicly-trusted certificates are the safe and >> prudent vehicle for "running the issue process before we actually try to >> standardize it". >> > > You are free to ignore any information in a certificate. But if you > attempt to limit information in the certificate you are not intending to > use in your product, you are arguably crossing the line. > > It's quite clear from the discussions I've been involved in that at least one goal for Logotypes is that Browsers process them. You implied so yourself above by stating that this proposal would "prevent other browser providers making use of LogoTypes." So you are now suggesting that Browsers ignore this information while others are suggesting precisely the opposite. If publicly-trusted certificates containing Logotypes are issued prior to some agreement on the rules, then we have created a "legacy" problem and made it more difficult for Browsers to support them. And again, there is a simple solution to this problem: don't issue certs with Logotypes from a Mozilla-trusted hierarchy until validation standards are in place. > > >> I can't see Web browsing being the first place people are going to use >>> logotypes. I think they are going to be most useful in other applications. >>> And we actually have rather a lot of those appearing right now. But they >>> are Applets consisting of a thin layer on top of a browser and the logotype
Re: Logotype extensions
On Wed, Jul 10, 2019 at 6:11 PM Wayne Thayer wrote: > On Wed, Jul 10, 2019 at 2:31 PM Phillip Hallam-Baker < > ph...@hallambaker.com> wrote: > >> On Wed, Jul 10, 2019 at 4:54 PM Wayne Thayer via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >>> Russ, >>> >>> > >>> Perhaps one of us is confused because I think we're saying the same >>> thing - >>> that rules around inclusion of Logotype extensions in publicly-trusted >>> certs should be in place before CAs begin to use this extension. >>> >> >> I don't see how your proposed ban on logotypes is consistent. What that >> would do is set up a situation in which it was impossible for CABForum to >> develop rules for logotypes because one of the browsers had already banned >> their use. >> >> > How exactly does a Browser banning the use of an extension prevent the CAB > Forum from developing rules to govern the use of said extension? If > anything, it would seem to encourage the CAB Forum to take on that work. > Also, as has been discussed, it is quite reasonable to argue that the > inclusion of this extension is already forbidden in a BR-compliant > certificate. > 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. 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. > 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 "MUST NOT" to "SHOULD NOT" reflects the > consensus reached in this thread. > > I also do not believe that publicly-trusted certificates are the safe and > prudent vehicle for "running the issue process before we actually try to > standardize it". > You are free to ignore any information in a certificate. But if you attempt to limit information in the certificate you are not intending to use in your product, you are arguably crossing the line. > I can't see Web browsing being the first place people are going to use >> logotypes. I think they are going to be most useful in other applications. >> And we actually have rather a lot of those appearing right now. But they >> are Applets consisting of a thin layer on top of a browser and the logotype >> stuff is relevant to the thin layer rather than the substrate >> > > If the use case isn't server auth or email protection, then publicly > trusted certificates shouldn't be used. Full stop. How many times do we > need to learn that lesson? > That appears to be an even more problematic statement. There have always been more stakeholders than just the browser providers on the relying applications side. Those applets are competing with your product. Again, talk to your legal people. If you use your market power to limit the functionalities that your competitors can offer, you are going to have real problems. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Logotype extensions
On Wed, Jul 10, 2019 at 2:31 PM Phillip Hallam-Baker wrote: > On Wed, Jul 10, 2019 at 4:54 PM Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Russ, >> >> > >> Perhaps one of us is confused because I think we're saying the same thing >> - >> that rules around inclusion of Logotype extensions in publicly-trusted >> certs should be in place before CAs begin to use this extension. >> > > I don't see how your proposed ban on logotypes is consistent. What that > would do is set up a situation in which it was impossible for CABForum to > develop rules for logotypes because one of the browsers had already banned > their use. > > How exactly does a Browser banning the use of an extension prevent the CAB Forum from developing rules to govern the use of said extension? If anything, it would seem to encourage the CAB Forum to take on that work. Also, as has been discussed, it is quite reasonable to argue that the inclusion of this extension is already forbidden in a BR-compliant certificate. 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 "MUST NOT" to "SHOULD NOT" reflects the consensus reached in this thread. I also do not believe that publicly-trusted certificates are the safe and prudent vehicle for "running the issue process before we actually try to standardize it". I can't see Web browsing being the first place people are going to use > logotypes. I think they are going to be most useful in other applications. > And we actually have rather a lot of those appearing right now. But they > are Applets consisting of a thin layer on top of a browser and the logotype > stuff is relevant to the thin layer rather than the substrate. > > If the use case isn't server auth or email protection, then publicly trusted certificates shouldn't be used. Full stop. How many times do we need to learn that lesson? > For example, I have lots of gadgets in my house. Right now, every > different vendor who does an IoT device has to write their own app and run > their own service. And the managers are really happy with that at the > moment because they see it as all upside. > > I think they will soon discover that most devices that are being made to > Internet aren't actually very useful if the only thing they connect to is a > manufacturer site and those start to cost money to run. So I think we will > end up with an open interconnect approach to IoT in the end regardless of > what a bunch of marketing VPs think should happen. Razor and blades models > are really profitable but they are also vanishingly rare because the number > 2 and 3 companies have an easy way to enter the market by opening up. > > Authenticating those devices to the users who bought them, authenticating > the code updates. Those are areas where the logotypes can be really useful. > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Logotype extensions
On Wed, Jul 10, 2019 at 4:54 PM Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Russ, > > > > Perhaps one of us is confused because I think we're saying the same thing - > that rules around inclusion of Logotype extensions in publicly-trusted > certs should be in place before CAs begin to use this extension. > I don't see how your proposed ban on logotypes is consistent. What that would do is set up a situation in which it was impossible for CABForum to develop rules for logotypes because one of the browsers had already banned their use. 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 can't see Web browsing being the first place people are going to use logotypes. I think they are going to be most useful in other applications. And we actually have rather a lot of those appearing right now. But they are Applets consisting of a thin layer on top of a browser and the logotype stuff is relevant to the thin layer rather than the substrate. For example, I have lots of gadgets in my house. Right now, every different vendor who does an IoT device has to write their own app and run their own service. And the managers are really happy with that at the moment because they see it as all upside. I think they will soon discover that most devices that are being made to Internet aren't actually very useful if the only thing they connect to is a manufacturer site and those start to cost money to run. So I think we will end up with an open interconnect approach to IoT in the end regardless of what a bunch of marketing VPs think should happen. Razor and blades models are really profitable but they are also vanishingly rare because the number 2 and 3 companies have an easy way to enter the market by opening up. Authenticating those devices to the users who bought them, authenticating the code updates. Those are areas where the logotypes can be really useful. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Logotype extensions
Russ, On Wed, Jul 10, 2019 at 11:41 AM housley--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Friday, July 5, 2019 at 7:53:45 PM UTC-4, Wayne Thayer wrote: > > Based on this discussion, I propose adding the following statement to the > > Mozilla Forbidden Practices wiki page [1]: > > > > ** 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. > > > > Please respond if you have concerns with this change. As suggested in > this > > thread, we can discuss removing this restriction if/when a robust > > validation process emerges. > > > > - Wayne > > > > [1] https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices > > [2] > > > https://groups.google.com/d/msg/mozilla.dev.security.policy/nZoK5akw2c8/ZtF0WZY8AgAJ > > People find logos very helpful. That is why many browsers display a tiny > logo in the toolbar. > > I would suggest that a better way forward is to start the hard work on the > validation process. It will not be difficult for that to become more > robust and accessible than the logos in the toolbar. > > Perhaps one of us is confused because I think we're saying the same thing - that rules around inclusion of Logotype extensions in publicly-trusted certs should be in place before CAs begin to use this extension. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Logotype extensions
On Wed, Jul 10, 2019 at 2:41 PM housley--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Friday, July 5, 2019 at 7:53:45 PM UTC-4, Wayne Thayer wrote: > > Based on this discussion, I propose adding the following statement to the > > Mozilla Forbidden Practices wiki page [1]: > > > > ** 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. > > > > Please respond if you have concerns with this change. As suggested in > this > > thread, we can discuss removing this restriction if/when a robust > > validation process emerges. > > > > - Wayne > > > > [1] https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices > > [2] > > > https://groups.google.com/d/msg/mozilla.dev.security.policy/nZoK5akw2c8/ZtF0WZY8AgAJ > > People find logos very helpful. That is why many browsers display a tiny > logo in the toolbar. > > I would suggest that a better way forward is to start the hard work on the > validation process. It will not be difficult for that to become more > robust and accessible than the logos in the toolbar. > [I am not currently employed by a CA. Venture Cryptography does not operate one or plan to.] I agree with Russ. The Logotype extension has technical controls to protect the integrity of the referenced image by means of a digest value. I do find the discussion of the usability factors rather odd when I am looking at my browser tabs decorated with completely unauthenticated favicons. Why is it that browser providers have no problem putting that information in front of users? If Mozilla or Chrome or the like don't see the value of using the logotype information, don't. But if you were to attempt to prevent others making use of this capability, that looks a lot like anti-Trust to me. The validation scheme I proposed when we discussed this some years back was to build on the Madrid Treaty for registration of trademarks. International business is already having to deal with the issue of logos being used in multiple jurisdiction. It is a complex, difficult problem but one that the international system is very much aware of and working to address. They will take time but we can leave the hard issues to them. I see multiple separate security levels here: 1) Anyone can create a Web page that appears to look like Ethel's Bank 2) Ethel's Bank Carolina and Ethel's Bank Spain both have trademarks in their home countries and can register credentials showing they are Ethel's Bank. 3) When someone goes to Ethel's Bank online they are assured that it is the canonical Ethel's Bank and no other. There are obvious practical problems that make (3) unreachable. Not least the fact that one of the chief reasons that trademarks are often fractured geographically is that they were once part of a single business that split. Cadbury's chocolate sold in the US is made by a different company to that sold in the UK which is why some people import the genuine article at significant expense. But the security value lies in moving from level 1 to level 2. Stopping a few million Internet thieves easily setting up fake web sites that look By Ethel's bank is the important task. The issue of which Ethel's Bank is the real one is something they can sort out (expensively) between themselves, 20 paces with loaded lawyers. For the record, I am not sure that we can graft logotypes onto the current Web browser model as it stands. I agree with many of Ryan's criticisms, but not his conclusions. Our job is to make the Internet safe for the users. I am looking at using logotypes but in a very different interaction model. The Mesh does have a role for CAs but it is a very different role. I will be explaining that model elsewhere. But the basic idea here is that the proper role of the CA is primarily as an introducer. One of the reasons the Web model is fragile today is that every transaction is essentially independent as far as the client is concerned. The server has cookies that link the communications together but the client starts from scratch each time. So imagine that I have a Bookmarks catalog that I keep my financial service providers in and this acts as a local name provider for all of my Internet technology. When I add Ethel's bank to my Bookmarks catalog, I see the Ethel's bank logo as part of that interaction. A nice big fat logo, not a small one. And I give it my pet name 'Ethel'. And when I tell Siri, or Alexa or Cortana, 'call ethel', it call's Ethel's bank for me. Or if I type 'Ethel' into a toolbar, that is the priority. Given where we have come from, the CA will have to continue to do the trust management part of the WebPKI indefinitely. And I probably want the CA to also have the role of warning me when a party I previously trusted has defaulted in some way.
Re: Logotype extensions
On Wed, Jul 10, 2019 at 2:41 PM housley--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > People find logos very helpful. That is why many browsers display a tiny > logo in the toolbar. > Are you talking the favicon? An attacker controlled resource which should not be used for trust, and in many browsers, is no longer displayed in in the toolbar, except for sites the user has visited? > I would suggest that a better way forward is to start the hard work on the > validation process. It will not be difficult for that to become more > robust and accessible than the logos in the toolbar. > You're right, it would be fairly easy, because there is no such validation, nor is there need for it. Thus, it seems any suggestion at validation is significantly less robust, accessible, or useful. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Logotype extensions
On Friday, July 5, 2019 at 7:53:45 PM UTC-4, Wayne Thayer wrote: > Based on this discussion, I propose adding the following statement to the > Mozilla Forbidden Practices wiki page [1]: > > ** 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. > > Please respond if you have concerns with this change. As suggested in this > thread, we can discuss removing this restriction if/when a robust > validation process emerges. > > - Wayne > > [1] https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices > [2] > https://groups.google.com/d/msg/mozilla.dev.security.policy/nZoK5akw2c8/ZtF0WZY8AgAJ People find logos very helpful. That is why many browsers display a tiny logo in the toolbar. I would suggest that a better way forward is to start the hard work on the validation process. It will not be difficult for that to become more robust and accessible than the logos in the toolbar. Russ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Logotype extensions
On Fri, Jul 5, 2019 at 8:04 PM Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I think my biggest concern is that there hasn't actual been any proof that > this would mislead relying parties. You'd actual have to have Mozilla do > something with it first. I don’t think this is the only argument against, to be clear. In the context of the interoperable Web PKI, given the fact that the LogoType extension is itself insecure if processed, and there are clients that process it, do you think the ecosystem health argument is relevant? That is, the same as when NULs were embedded in Common Names - valid according to the specs, but results in insecure risk to clients. The general badness can apply to any extension in a cert. No actual risk > has been pointed out other than a CA may put something in a cert and a > relying part may view the cert somehow to see the information. This is > true with every extension, not just logo types. That’s not true. There’s been ample discussion of risk. Risk to relying parties that rely on the reproducibility of certificates, for example, running into issues with reproducing the logos. There was ample criticism of the specific proposal here in the IETF when this was standardized, from 2002-2003. Happy to provide links to those archives, but it’s worth realizing even then, the notion of LogoType in EEs, and Logos in particular, were seen as dangerous. For example, it’s technically impossible to constrain such certificates; does that mean Mozilla Policy should update to ensure that TCSCs are no longer seen as such for any CA that issues such certificates? There’s a fundamental ecosystem risk by introducing such information. It adds more challenges to timely revocation and replacement of the certificate. Perhaps a policy should be that no CA that has ever had delays in revocation, due to difficulties replacing certificates, should be allowed to issue such certificates? Just to reiterate: - It causes harm to extant software and users - It makes it harder to reissue and replace certificates - The CA intentionally is introducing risks and challenges to the appropriate disclosure of such certificates, to the point I think no extant CT Log could safely accept certificates from CAs that issued such certificates, and that would seem a perfectly reasonable CT Log decision. - It is unquestionably Subscriber information with no safe or reasonable way to reliably validate, especially in an unambiguous way - There is no reasonable way for potential victims of CA misissuance to check or verify. That is, there is no programmatic way that works to compare such certificates, and the notion of “Use ML” misses the idea of adversarial examples. The reality is that the Web PKI needs an allowlisted profile, because such additional information is actively harmful to a more secure, more reliable Web. You can find plenty of discussion, even two decades ago, about the value of having that information expressed separately - e.g. as has been discussed in the context of GLEIF, in which the identifier links to a separately maintained and updatable database. There are issues with that, for sure, as have also been discussed over the years. I am wholly supportive of the proposed policy change. It will actively be harmful to the Web ecosystem if CAs were to try to conflate TLS server certificates with such unnecessary information. > > From: dev-security-policy > on behalf of Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> > Sent: Friday, July 5, 2019 5:53:24 PM > To: mozilla-dev-security-policy > Subject: Re: Logotype extensions > > Based on this discussion, I propose adding the following statement to the > Mozilla Forbidden Practices wiki page [1]: > > ** 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. > > Please respond if you have concerns with this change. As suggested in this > thread, we can discuss removing this restriction if/when a robust > validation process emerges. > > - 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 Tue, Jun 18, 2019 at 6:47 AM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On 14/06/2019 18:54, Ryan Sleevi wrote: > > > On Fri, Jun 14, 2019 at 4:12 PM Jakob Bohm via dev-security-policy < > > > dev-security-policy@lists.mozilla.org> wrote: > > > > > >> In such a case, there are two o
Re: Logotype extensions
I think my biggest concern is that there hasn't actual been any proof that this would mislead relying parties. You'd actual have to have Mozilla do something with it first. The general badness can apply to any extension in a cert. No actual risk has been pointed out other than a CA may put something in a cert and a relying part may view the cert somehow to see the information. This is true with every extension, not just logo types. From: dev-security-policy on behalf of Wayne Thayer via dev-security-policy Sent: Friday, July 5, 2019 5:53:24 PM To: mozilla-dev-security-policy Subject: Re: Logotype extensions Based on this discussion, I propose adding the following statement to the Mozilla Forbidden Practices wiki page [1]: ** 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. Please respond if you have concerns with this change. As suggested in this thread, we can discuss removing this restriction if/when a robust validation process emerges. - 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 Tue, Jun 18, 2019 at 6:47 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 14/06/2019 18:54, Ryan Sleevi wrote: > > On Fri, Jun 14, 2019 at 4:12 PM Jakob Bohm via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > >> In such a case, there are two obvious solutions: > >> > >> A. Trademark owner (prompted by applicant) provides CA with an official > >> permission letter stating that Applicant is explicitly licensed to > >> mark the EV certificate for a specific list of SANs and and Subject > >> DNs with their specific trademark (This requires the CA to do some > >> validation of that letter, similar to what is done for domain > >> letters). > > > > > > This process has been forbidden since August 2018, as it is fundamentally > > insecure, especially as practiced by a number of CAs. The Legal Opinion > > Letter (LOL) has also been discussed at length with respect to a number > of > > problematic validations that have occurred, due to CAs failing to > exercise > > due diligence or their obligations under the NetSec requirements to > > adequately secure and authenticate the parties involved in validating > such > > letters. > > > > Well, that was unfortunate for the case where it is not straing parent- > child (e.g. trademark owned by a foundation and licensed to the company) > But ok, in that case the option is gone, and what follows below is moot: > > > > > Letter needs to be reissued for end-of-period cert > >> renewals, but not for unchanged early reissue where the cause is not > >> applicant loss of rights to items. For example, the if the > Heartbleed > >> incident had occurred mid-validity, the web server security teams > >> could get reissued certificates with uncompromised private keys > >> without repeating this time consuming validation step. > > > > > > EV certificates require explicit authorization by an authorized > > representative for each and every certificate issued. A key rotation > event > > is one to be especially defensive about, as an attacker may be attempting > > to bypass the validation procedures to rotate to an attacker-supplied > key. > > This was an intentional design by CAs, in an attempt to provide some > value > > over DV and OV certificates by the presumed difficulty in substituting > them. > > > > I was considering the trademark as a validated property of the subject > (similar to e.g. physical address), thus normally subject to the 825 day > reuse limit. My wording was intended to require stricter than current > BR revalidation for renewal within that 825 day limit. > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > ___ > 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
Re: Logotype extensions
Based on this discussion, I propose adding the following statement to the Mozilla Forbidden Practices wiki page [1]: ** 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. Please respond if you have concerns with this change. As suggested in this thread, we can discuss removing this restriction if/when a robust validation process emerges. - 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 Tue, Jun 18, 2019 at 6:47 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 14/06/2019 18:54, Ryan Sleevi wrote: > > On Fri, Jun 14, 2019 at 4:12 PM Jakob Bohm via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > >> In such a case, there are two obvious solutions: > >> > >> A. Trademark owner (prompted by applicant) provides CA with an official > >> permission letter stating that Applicant is explicitly licensed to > >> mark the EV certificate for a specific list of SANs and and Subject > >> DNs with their specific trademark (This requires the CA to do some > >> validation of that letter, similar to what is done for domain > >> letters). > > > > > > This process has been forbidden since August 2018, as it is fundamentally > > insecure, especially as practiced by a number of CAs. The Legal Opinion > > Letter (LOL) has also been discussed at length with respect to a number > of > > problematic validations that have occurred, due to CAs failing to > exercise > > due diligence or their obligations under the NetSec requirements to > > adequately secure and authenticate the parties involved in validating > such > > letters. > > > > Well, that was unfortunate for the case where it is not straing parent- > child (e.g. trademark owned by a foundation and licensed to the company) > But ok, in that case the option is gone, and what follows below is moot: > > > > > Letter needs to be reissued for end-of-period cert > >> renewals, but not for unchanged early reissue where the cause is not > >> applicant loss of rights to items. For example, the if the > Heartbleed > >> incident had occurred mid-validity, the web server security teams > >> could get reissued certificates with uncompromised private keys > >> without repeating this time consuming validation step. > > > > > > EV certificates require explicit authorization by an authorized > > representative for each and every certificate issued. A key rotation > event > > is one to be especially defensive about, as an attacker may be attempting > > to bypass the validation procedures to rotate to an attacker-supplied > key. > > This was an intentional design by CAs, in an attempt to provide some > value > > over DV and OV certificates by the presumed difficulty in substituting > them. > > > > I was considering the trademark as a validated property of the subject > (similar to e.g. physical address), thus normally subject to the 825 day > reuse limit. My wording was intended to require stricter than current > BR revalidation for renewal within that 825 day limit. > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > ___ > 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
Re: Logotype extensions
On 14/06/2019 18:54, Ryan Sleevi wrote: > On Fri, Jun 14, 2019 at 4:12 PM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> In such a case, there are two obvious solutions: >> >> A. Trademark owner (prompted by applicant) provides CA with an official >> permission letter stating that Applicant is explicitly licensed to >> mark the EV certificate for a specific list of SANs and and Subject >> DNs with their specific trademark (This requires the CA to do some >> validation of that letter, similar to what is done for domain >> letters). > > > This process has been forbidden since August 2018, as it is fundamentally > insecure, especially as practiced by a number of CAs. The Legal Opinion > Letter (LOL) has also been discussed at length with respect to a number of > problematic validations that have occurred, due to CAs failing to exercise > due diligence or their obligations under the NetSec requirements to > adequately secure and authenticate the parties involved in validating such > letters. > Well, that was unfortunate for the case where it is not straing parent- child (e.g. trademark owned by a foundation and licensed to the company) But ok, in that case the option is gone, and what follows below is moot: > > Letter needs to be reissued for end-of-period cert >> renewals, but not for unchanged early reissue where the cause is not >> applicant loss of rights to items. For example, the if the Heartbleed >> incident had occurred mid-validity, the web server security teams >> could get reissued certificates with uncompromised private keys >> without repeating this time consuming validation step. > > > EV certificates require explicit authorization by an authorized > representative for each and every certificate issued. A key rotation event > is one to be especially defensive about, as an attacker may be attempting > to bypass the validation procedures to rotate to an attacker-supplied key. > This was an intentional design by CAs, in an attempt to provide some value > over DV and OV certificates by the presumed difficulty in substituting them. > I was considering the trademark as a validated property of the subject (similar to e.g. physical address), thus normally subject to the 825 day reuse limit. My wording was intended to require stricter than current BR revalidation for renewal within that 825 day limit. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Logotype extensions
On Friday, June 14, 2019 at 1:31:12 PM UTC-4, kirkhal...@gmail.com wrote: > CAs already have rules allowing a Parent, Subsidiary, or Affiliate (all > defined terms) to obtain certs for domains owned by each other - so > Alphabet-Google, for example, can get certs for domains owned by each other. > So we would use the same rules to make certain the registered trademark owner > is a Parent, Subsidiary, or Affiliate of the EV cert Subject - we would use > information from the SEC or other government securities agencies (including > public filings), and/or other third party data that we have used for the past > 10 years to prove affiliation. Also, remember, we only do trademark > registration validation after we have completed EV validation, so we know who > our certificate customer is. Many companies put their IP assets in an > affiliated company for tax reasons - it should not be difficult to prove > affiliation. If we can't prove it, the logo will not go into the EV cert. Section 11 of the EV Guidelines has specific language for all cases where information for Parent/Subsidiary/Affiliate companies can be used for validation. Given that validation for trademarks/Logotype extensions is not specified anywhere in the BRs or EV Guidelines, there is no such language allowing the use of trademark data obtained from PSA companies in certificates. Additionally, as Ryan alluded to, it is reasonable to interpret the definition of Subject Identity Information to also encompass any certificate extensions which contain identity information about the Subject. Given this, I believe that EV Guidelines section 9.2.9 is applicable as the intent of that section is clear: no identity information can be included in an EV certificate unless the steps for validation and encoding are thoroughly specified in the EV Guidelines. To assert otherwise is to assert that well defined, rigorous validation steps are not needed for EV certificates. Thanks, Corey ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Logotype extensions
CAs already have rules allowing a Parent, Subsidiary, or Affiliate (all defined terms) to obtain certs for domains owned by each other - so Alphabet-Google, for example, can get certs for domains owned by each other. So we would use the same rules to make certain the registered trademark owner is a Parent, Subsidiary, or Affiliate of the EV cert Subject - we would use information from the SEC or other government securities agencies (including public filings), and/or other third party data that we have used for the past 10 years to prove affiliation. Also, remember, we only do trademark registration validation after we have completed EV validation, so we know who our certificate customer is. Many companies put their IP assets in an affiliated company for tax reasons - it should not be difficult to prove affiliation. If we can't prove it, the logo will not go into the EV cert. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Logotype extensions
On Fri, Jun 14, 2019 at 4:12 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > In such a case, there are two obvious solutions: > > A. Trademark owner (prompted by applicant) provides CA with an official >permission letter stating that Applicant is explicitly licensed to >mark the EV certificate for a specific list of SANs and and Subject >DNs with their specific trademark (This requires the CA to do some >validation of that letter, similar to what is done for domain >letters). This process has been forbidden since August 2018, as it is fundamentally insecure, especially as practiced by a number of CAs. The Legal Opinion Letter (LOL) has also been discussed at length with respect to a number of problematic validations that have occurred, due to CAs failing to exercise due diligence or their obligations under the NetSec requirements to adequately secure and authenticate the parties involved in validating such letters. Letter needs to be reissued for end-of-period cert >renewals, but not for unchanged early reissue where the cause is not >applicant loss of rights to items. For example, the if the Heartbleed >incident had occurred mid-validity, the web server security teams >could get reissued certificates with uncompromised private keys >without repeating this time consuming validation step. EV certificates require explicit authorization by an authorized representative for each and every certificate issued. A key rotation event is one to be especially defensive about, as an attacker may be attempting to bypass the validation procedures to rotate to an attacker-supplied key. This was an intentional design by CAs, in an attempt to provide some value over DV and OV certificates by the presumed difficulty in substituting them. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Logotype extensions
On 14/06/2019 04:16, Corey Bonnell wrote: On Thursday, June 13, 2019 at 2:04:48 AM UTC-4, kirkhal...@gmail.com wrote: On Tuesday, June 11, 2019 at 2:49:31 PM UTC+3, Jeremy Rowley wrote: We wanted to experiment a bit with logotype extensions and trademarks, but we heard from the CAB Forum that whether inclusion is allowed is subject a bit to interpretation by the browsers. >From the BRs section 7.1.2.4 "All other fields and extensions MUST be set in accordance with RFC 5280. The CA SHALL NOT issue a Certificate that contains a keyUsage flag, extendedKeyUsage value, Certificate extension, or other data not specified in section 7.1.2.1, 7.1.2.2, or 7.1.2.3 unless the CA is aware of a reason for including the data in the Certificate. CAs SHALL NOT issue a Certificate with: a. Extensions that do not apply in the context of the public Internet (such as an extendedKeyUsage value for a service that is only valid in the context of a privately managed network), unless: i. such value falls within an OID arc for which the Applicant demonstrates ownership, or ii. the Applicant can otherwise demonstrate the right to assert the data in a public context; or 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)." In this case, the logotype extension would have a trademark included (or link to a trademark). I think this allowed as: 1. There is a reason for including the data in the Certificate (to identify a verified trademark). Although you may disagree about the reason for needing this information, there is a not small number of people interested in figuring out how to better use identification information. No browser would be required to use the information (of course), but it would give organizations another way to manage certificates and identity information - one that is better (imo) than org information. 2. The cert applies in the context of the public Internet. Trademarks/identity information is already included in the BRs. 3. The trademark does not falls within an OID arc for which the Applicant demonstrates ownership (no OID included). 4. The Applicant can otherwise demonstrate the right to assert the data in a public context. If we vet ownership of the trademark with the appropriate office, there's no conflict there. 5. Semantics that, if included, will not 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). None of these examples are very close to the proposal. What I'm looking for is not a discussion on whether this is a good idea, but rather is it currently permitted under the BRs per Mozilla's interpretation. I'd like to have the "is this a good idea" discussion, but in a separate thread to avoid conflating permitted action compared to ideal action. Jeremy Jeremy is correct - including strongly verified registered trademarks via extensions in EV certs is permitted (i.e., not forbidden) by BR Section 7.1.2.4. Confirming registered trademarks (whether logos, word marks, or both in a combined mark) to include in an EV cert would be very easy for a CA. Here are the steps: 1. Complete EV validation of the Organization 2. Applicant sends CA its USPTO logo or wordmark Registration Number and SVG file of logo to include in EV cert CA validates: (a) Confirm logo and/or wordmark is registered to Organization in USPTO online data base, and (b) Compare USPTO image with SVG file received to confirm they are the same logo. 3. CA inserts (a) name of Trademark office with the logo and/or wordmark registration, (b) the Registration Number, and (c) the SVG file in the EV certificate to be available to browsers and applications to display if desired. Adding validated logos to EV certificates has the benefit of allowing browsers and apps to choose to display the logo (with registered word mark, if desired) in the UI, and would solve the concern that some have expressed that users don't always recognize the corporate name of a familiar brand when it's displayed in the current EV UI. For example, consider the EV website of the food chain "Subway" - www.subway.com. The current EV UI shows "Franchise World Headquarters, LLC [US]" which is correct but not very friendly for users. What if instead a browser or app displayed the verified trademark and/or word mark owned by Subway? See these two records from the US Patent and Trademark Office: http://tmsearch.uspto.gov/bin/showfield?f=doc=4804:6juyuh.2.20 http://tmsearch.uspto.gov/bin/showfield?f=doc=4804:6juyuh.2.14 Adding strongly verified marks to EV
Re: Logotype extensions
On Thu, Jun 13, 2019 at 2:04 AM kirkhalloregon--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Jeremy is correct - including strongly verified registered trademarks via > extensions in EV certs is permitted (i.e., not forbidden) by BR Section > 7.1.2.4. It's unclear to me if Jeremy was taking a position versus sharing an interpretation. I think it may be useful to frame it as an interpretation, and then to provide support and evidence for that interpretation, and whether or not you agree or disagree with other interpretations, and why. [In an official capacity] As Google shared during the recent CA/Browser Forum, our view is that such certificates violate Section 7.1.2.4, especially as proposed to be validated here, and as such, are misissuance. The proposed algorithm, as stated, does not meet the requirements of 7.1.2.4. Advocates in favor of finding an acceptable interpretation are welcome to attempting refinements to the algorithm in order to satisfy the requirements of the Baseline Requirements, but issuing as described will be misissuance and will require a CA incident report to be filed. With respect to logos in particular, our view is that there is a substantially higher bar here that needs to be met to avoid misleading Relying Parties and to provide the appropriate evidence of validation in an unambiguous fashion. [In a personal capacity] As mentioned in the CA/Browser Forum, this topic has been discussed in IETF [1], and the many obvious flaws in the proposal have been pointed out by a number of members of that community. While advocates for BIMI - which is proposed as applicable in the context of S/MIME - have not meaningfully addressed or even acknowledged these concerns, there is a broader consensus about the problems. As noted, the use of trademarks and logos, particularly as described, has a high likelihood of user confusion due to the necessary and inherent nature of global trademark usage [2]. Much as we recognize the necessary value to include the full jurisdiction information for incorporation - for example, the use of "Franchise World Headquarters LLC [US]" is known and has been shown to be misleading [3], even though expressly permitted. Among other things, the reason for this is that the country alone is not sufficient to disambiguate things, and requires the full jurisdiction display - which is problematic with respect to usability and accessibility. If we apply this principle with respect to logos, to avoid misleading relying parties, we would need to show specific trademark registration numbers and ensure users understood the appropriate distinction of trademark and wordmark registries, and their limitations. If users were to rely on only parts of this information, much as some have been mislead to do so with EV, we can see situations such as Stripe, where users are mislead by the partial information. It's important to note that even the advocates within BIMI for the inclusion of Logos have repeatedly made it clear that BIMI MUST NOT be used to reduce user confusion or be interpreted as a security technologies, because logos do not provide security benefits. To put it differently, the loudest current advocates for inclusion of logos in certificates make it clear that they will **mislead relying parties**, which is a position I strongly I agree with, and which, as noted above, is also Google's official position on this. BIMI advocates have made it clear that they do not believe this can improve security or trust, and that its value is purely as a marketing tool for brands, and that marketing value is useful for coercive value into getting such brands to invest in actual technologies that improve trust and safety (such as DKIM and DMARC). We must not lose sight of that. While I appreciate the attempt to resolve some of the past concerns around the global legal framework with respect to trademarks, by only allowing American companies to benefit, I think we can agree that form of cultural imperialism is not well-placed in a global Internet. Similarly, as many have highlighted, such an approach is fundamentally hostile to accessibility goals. For example, even if the misguided and unsupported assertion is that it improves security were true, then it fundamentally only improves security for users without vision impairments, for example. I can understand and appreciate arguments that some may be better than none, but I suspect our time would be better spent looking for ways to improve the security for all users, and on an Internet scale. I think, within this community, we are all strongly in support of ways to improve user security on the Web. As we all know and understand, the foundation for the Web security model is the origin - the scheme, host, and port. In the context of TLS, the role of certificates is to thus bind a public key to an origin, so that users and user agents can be reliably assured that they are talking to the correct origin, which
Re: Logotype extensions
On Tuesday, June 11, 2019 at 2:49:31 PM UTC+3, Jeremy Rowley wrote: > We wanted to experiment a bit with logotype extensions and trademarks, but > we heard from the CAB Forum that whether inclusion is allowed is subject a > bit to interpretation by the browsers. > > > > >From the BRs section 7.1.2.4 > > "All other fields and extensions MUST be set in accordance with RFC 5280. > The CA SHALL NOT issue a Certificate that contains a keyUsage flag, > extendedKeyUsage value, Certificate extension, or other data not specified > in section 7.1.2.1, 7.1.2.2, or 7.1.2.3 unless the CA is aware of a reason > for including the data in the Certificate. CAs SHALL NOT issue a Certificate > with: a. Extensions that do not apply in the context of the public Internet > (such as an extendedKeyUsage value for a service that is only valid in the > context of a privately managed network), unless: i. such value falls within > an OID arc for which the Applicant demonstrates ownership, or ii. the > Applicant can otherwise demonstrate the right to assert the data in a public > context; or 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)." > > > > In this case, the logotype extension would have a trademark included (or > link to a trademark). I think this allowed as: > > 1.There is a reason for including the data in the Certificate (to > identify a verified trademark). Although you may disagree about the reason > for needing this information, there is a not small number of people > interested in figuring out how to better use identification information. No > browser would be required to use the information (of course), but it would > give organizations another way to manage certificates and identity > information - one that is better (imo) than org information. > 2.The cert applies in the context of the public Internet. > Trademarks/identity information is already included in the BRs. > 3.The trademark does not falls within an OID arc for which the > Applicant demonstrates ownership (no OID included). > 4.The Applicant can otherwise demonstrate the right to assert the data > in a public context. If we vet ownership of the trademark with the > appropriate office, there's no conflict there. > 5.Semantics that, if included, will not 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). None of these examples are very close to the proposal. > > > > What I'm looking for is not a discussion on whether this is a good idea, but > rather is it currently permitted under the BRs per Mozilla's > interpretation. I'd like to have the "is this a good idea" discussion, but > in a separate thread to avoid conflating permitted action compared to ideal > action. > > > > Jeremy Sorry – the USPTO links for the Subway registered trademarks in my last message expired. Go to this search page http://tmsearch.uspto.gov/bin/gate.exe?f=searchss=4808:d53jqt.1.1 And search on these two Serial or Registration Numbers to see the Subway logo and word mark: 5373029 5601308 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Logotype extensions
On Tuesday, June 11, 2019 at 2:49:31 PM UTC+3, Jeremy Rowley wrote: > We wanted to experiment a bit with logotype extensions and trademarks, but > we heard from the CAB Forum that whether inclusion is allowed is subject a > bit to interpretation by the browsers. > > > > >From the BRs section 7.1.2.4 > > "All other fields and extensions MUST be set in accordance with RFC 5280. > The CA SHALL NOT issue a Certificate that contains a keyUsage flag, > extendedKeyUsage value, Certificate extension, or other data not specified > in section 7.1.2.1, 7.1.2.2, or 7.1.2.3 unless the CA is aware of a reason > for including the data in the Certificate. CAs SHALL NOT issue a Certificate > with: a. Extensions that do not apply in the context of the public Internet > (such as an extendedKeyUsage value for a service that is only valid in the > context of a privately managed network), unless: i. such value falls within > an OID arc for which the Applicant demonstrates ownership, or ii. the > Applicant can otherwise demonstrate the right to assert the data in a public > context; or 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)." > > > > In this case, the logotype extension would have a trademark included (or > link to a trademark). I think this allowed as: > > 1.There is a reason for including the data in the Certificate (to > identify a verified trademark). Although you may disagree about the reason > for needing this information, there is a not small number of people > interested in figuring out how to better use identification information. No > browser would be required to use the information (of course), but it would > give organizations another way to manage certificates and identity > information - one that is better (imo) than org information. > 2.The cert applies in the context of the public Internet. > Trademarks/identity information is already included in the BRs. > 3.The trademark does not falls within an OID arc for which the > Applicant demonstrates ownership (no OID included). > 4.The Applicant can otherwise demonstrate the right to assert the data > in a public context. If we vet ownership of the trademark with the > appropriate office, there's no conflict there. > 5.Semantics that, if included, will not 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). None of these examples are very close to the proposal. > > > > What I'm looking for is not a discussion on whether this is a good idea, but > rather is it currently permitted under the BRs per Mozilla's > interpretation. I'd like to have the "is this a good idea" discussion, but > in a separate thread to avoid conflating permitted action compared to ideal > action. > > > > Jeremy Jeremy is correct - including strongly verified registered trademarks via extensions in EV certs is permitted (i.e., not forbidden) by BR Section 7.1.2.4. Confirming registered trademarks (whether logos, word marks, or both in a combined mark) to include in an EV cert would be very easy for a CA. Here are the steps: 1. Complete EV validation of the Organization 2. Applicant sends CA its USPTO logo or wordmark Registration Number and SVG file of logo to include in EV cert CA validates: (a) Confirm logo and/or wordmark is registered to Organization in USPTO online data base, and (b) Compare USPTO image with SVG file received to confirm they are the same logo. 3. CA inserts (a) name of Trademark office with the logo and/or wordmark registration, (b) the Registration Number, and (c) the SVG file in the EV certificate to be available to browsers and applications to display if desired. Adding validated logos to EV certificates has the benefit of allowing browsers and apps to choose to display the logo (with registered word mark, if desired) in the UI, and would solve the concern that some have expressed that users don't always recognize the corporate name of a familiar brand when it's displayed in the current EV UI. For example, consider the EV website of the food chain "Subway" - www.subway.com. The current EV UI shows "Franchise World Headquarters, LLC [US]" which is correct but not very friendly for users. What if instead a browser or app displayed the verified trademark and/or word mark owned by Subway? See these two records from the US Patent and Trademark Office: http://tmsearch.uspto.gov/bin/showfield?f=doc=4804:6juyuh.2.20 http://tmsearch.uspto.gov/bin/showfield?f=doc=4804:6juyuh.2.14 Adding strongly verified marks to EV certificates would be a
Re: Logotype extensions
I agree with Corey. On Wed, Jun 12, 2019 at 4:28 AM Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > That argument applies to every extension not expressly permitted by the > BRs. Yup. It definitely puts the onus on the CA to demonstrate how they're not violating, and to put a clear and cogent argument forward as to how it meets that constraint. > Even if I just put a number in s private extension, a relying party could > be led to think jts their age. I think one way a CA would respond to a complaint that this was misissuance would be to refer to an appropriate specification or draft that defines how it is not. > Can we better define what could constitute as potentially misleading > extensions? Without that definition, this is the same as saying mo > additional extensions are allowed, which is clearly not the intent of the > existing language. Minimally, Subject Identity Information (or some modification therein to indicate it's applicable to the Subscriber/Applicant/Subject and not just the Certificate's Subject distinguishedName field) This would mean, for example, that any element of logoType, LEI, or alternative naming schemes would fundamentally be SII. The CA would have to demonstrate how the information included was verified, but also not applicable to the Subscriber/Applicant/Subject. The downside to this approach is that it's still not sufficient to address "stupidity". For example, I can imagine a CA would exploit such a language loophole by, say, including the Mozilla logo in a certificate for Google, arguing that they verified that the Mozilla logo had been verified as belonging to Mozilla. However, that should still be a 'clear' violation of 7.1.2.4(b). A more extreme version would be to argue that 7.1.2.4(b) would forbid anything without an appropriate definition for how that information is verified in a public context, and what those standards might be (e.g. W3C, IETF, ETSI?) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Logotype extensions
That argument applies to every extension not expressly permitted by the BRs. Even if I just put a number in s private extension, a relying party could be led to think jts their age. Can we better define what could constitute as potentially misleading extensions? Without that definition, this is the same as saying mo additional extensions are allowed, which is clearly not the intent of the existing language. From: dev-security-policy on behalf of Corey Bonnell via dev-security-policy Sent: Wednesday, June 12, 2019 4:52:39 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Logotype extensions On Tuesday, June 11, 2019 at 7:49:31 AM UTC-4, Jeremy Rowley wrote: > We wanted to experiment a bit with logotype extensions and trademarks, but > we heard from the CAB Forum that whether inclusion is allowed is subject a > bit to interpretation by the browsers. > > > > >From the BRs section 7.1.2.4 > > "All other fields and extensions MUST be set in accordance with RFC 5280. > The CA SHALL NOT issue a Certificate that contains a keyUsage flag, > extendedKeyUsage value, Certificate extension, or other data not specified > in section 7.1.2.1, 7.1.2.2, or 7.1.2.3 unless the CA is aware of a reason > for including the data in the Certificate. CAs SHALL NOT issue a Certificate > with: a. Extensions that do not apply in the context of the public Internet > (such as an extendedKeyUsage value for a service that is only valid in the > context of a privately managed network), unless: i. such value falls within > an OID arc for which the Applicant demonstrates ownership, or ii. the > Applicant can otherwise demonstrate the right to assert the data in a public > context; or 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)." > > > > In this case, the logotype extension would have a trademark included (or > link to a trademark). I think this allowed as: > > 1.There is a reason for including the data in the Certificate (to > identify a verified trademark). Although you may disagree about the reason > for needing this information, there is a not small number of people > interested in figuring out how to better use identification information. No > browser would be required to use the information (of course), but it would > give organizations another way to manage certificates and identity > information - one that is better (imo) than org information. > 2.The cert applies in the context of the public Internet. > Trademarks/identity information is already included in the BRs. > 3.The trademark does not falls within an OID arc for which the > Applicant demonstrates ownership (no OID included). > 4.The Applicant can otherwise demonstrate the right to assert the data > in a public context. If we vet ownership of the trademark with the > appropriate office, there's no conflict there. > 5.Semantics that, if included, will not 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). None of these examples are very close to the proposal. > > > > What I'm looking for is not a discussion on whether this is a good idea, but > rather is it currently permitted under the BRs per Mozilla's > interpretation. I'd like to have the "is this a good idea" discussion, but > in a separate thread to avoid conflating permitted action compared to ideal > action. > > > > Jeremy Absent policy surrounding the validation and encoding of Logotype data, I believe that the use of the Logotype extension to convey identity information may be fraught with security and privacy problems. A brief read of RFCs 3709 and 6170 raises several concerns: 1. Where are the image and audio assets stored? Will the CA allow for Applicants to specify an arbitrary URI for assets, or will the CA host them, or will the assets be encoded directly in the certificate using data URIs? The first two options have ramifications regarding client tracking, or even allowing attackers to suppress the retrieval of logo assets (thus providing for a potentially inconsistent UI between clients). This is compounded by the fact that the RFCs only allow retrieval via plaintext HTTP and FTP. I’m guessing the third option (“data” URI) is a non-starter due to certificate size limitations. 2. The RFCs do not put a hard requirement on the minimum size o
Re: Logotype extensions
On Tuesday, June 11, 2019 at 7:49:31 AM UTC-4, Jeremy Rowley wrote: > We wanted to experiment a bit with logotype extensions and trademarks, but > we heard from the CAB Forum that whether inclusion is allowed is subject a > bit to interpretation by the browsers. > > > > >From the BRs section 7.1.2.4 > > "All other fields and extensions MUST be set in accordance with RFC 5280. > The CA SHALL NOT issue a Certificate that contains a keyUsage flag, > extendedKeyUsage value, Certificate extension, or other data not specified > in section 7.1.2.1, 7.1.2.2, or 7.1.2.3 unless the CA is aware of a reason > for including the data in the Certificate. CAs SHALL NOT issue a Certificate > with: a. Extensions that do not apply in the context of the public Internet > (such as an extendedKeyUsage value for a service that is only valid in the > context of a privately managed network), unless: i. such value falls within > an OID arc for which the Applicant demonstrates ownership, or ii. the > Applicant can otherwise demonstrate the right to assert the data in a public > context; or 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)." > > > > In this case, the logotype extension would have a trademark included (or > link to a trademark). I think this allowed as: > > 1.There is a reason for including the data in the Certificate (to > identify a verified trademark). Although you may disagree about the reason > for needing this information, there is a not small number of people > interested in figuring out how to better use identification information. No > browser would be required to use the information (of course), but it would > give organizations another way to manage certificates and identity > information - one that is better (imo) than org information. > 2.The cert applies in the context of the public Internet. > Trademarks/identity information is already included in the BRs. > 3.The trademark does not falls within an OID arc for which the > Applicant demonstrates ownership (no OID included). > 4.The Applicant can otherwise demonstrate the right to assert the data > in a public context. If we vet ownership of the trademark with the > appropriate office, there's no conflict there. > 5.Semantics that, if included, will not 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). None of these examples are very close to the proposal. > > > > What I'm looking for is not a discussion on whether this is a good idea, but > rather is it currently permitted under the BRs per Mozilla's > interpretation. I'd like to have the "is this a good idea" discussion, but > in a separate thread to avoid conflating permitted action compared to ideal > action. > > > > Jeremy Absent policy surrounding the validation and encoding of Logotype data, I believe that the use of the Logotype extension to convey identity information may be fraught with security and privacy problems. A brief read of RFCs 3709 and 6170 raises several concerns: 1. Where are the image and audio assets stored? Will the CA allow for Applicants to specify an arbitrary URI for assets, or will the CA host them, or will the assets be encoded directly in the certificate using data URIs? The first two options have ramifications regarding client tracking, or even allowing attackers to suppress the retrieval of logo assets (thus providing for a potentially inconsistent UI between clients). This is compounded by the fact that the RFCs only allow retrieval via plaintext HTTP and FTP. I’m guessing the third option (“data” URI) is a non-starter due to certificate size limitations. 2. The RFCs do not put a hard requirement on the minimum size of images and length of audio files. What’s the minimum acceptable size of images to ensure that the trademark is clearly conveyed to Relying Parties? Is a 5-second clip from the Subject’s radio jingle sufficiently clear identity information? 3. Perhaps minor, but RFC 3709 specifies that clients MUST support SHA-1 for hashing assets. This is undesirable, especially given that attacks against SHA-1 are becoming increasingly practical. Given the concern about suppressing the retrieval of the trademark information and the lack of specification to ensure clear, unambiguous images/audio, I believe that 7.1.2.4.b is applicable here in that there is the possibility to mislead Relying Parties. As such, I believe that before CAs begin embedding the Logotype extension in certificates, the relevant RFCs need to be profiled (or
