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
Fwd: Logotype extensions
[Fixing the From to match list membership] 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
Fwd: 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. -- Website: http://hallambaker.com/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Logotype extensions
[Fixing the From] n 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. -- Website: http://hallambaker.com/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DarkMatter Concerns
On 11/07/2019 03:38, Matthew Hardeman wrote: I used the parallel to racism in finance because it's exceedingly well documented that strong objective systems of risk management and decisioning led to better overall financial outcomes AND significantly opened the door to credit (aka trust) to otherwise improperly maligned and underserved communities. (for the avoidance of doubt: writing in a personal capacity - although I work for Mozilla I have nothing to do with this decision.) Financial credit really isn't "aka trust". The "strong objective system of risk management and decisioning" includes the ability to risk manage (e.g. in determining the amount of credit, the interest rate, including a guarantor, including a security, requiring certain types of insurance so the creditor doesn't lose out if the debtor dies, ...), and there's no way for a trust store to "risk manage" a CA in any of those ways. Mozilla can't limit issuance to a certain number of certificates, or a certain set of domains, or set financial penalties for misissuance, or ... Additionally, the repayments to credit once an agreement is struck provide complete information about current performance of the debtor, which there isn't in the CA world. And should repayments stop, the lender normally has some means of recuperating losses (whether that's through the object which secured the loan, through the guarantor, or the court/bailiff system), and the only people affected are the lender and the debtor (and guarantor, if any). None of that is true for a trust store, either, where the people affected by a "default" are the relying parties. If we're going to make a comparison to finance, this is more akin to Mozilla being asked to sign up as guarantor for every CA, in a huge loan that's being extended by all the users of their trust store. Any financial adviser worth their salt will tell you never to be a guarantor for anybody unless you're very, very sure of that person, because you have effectively no recourse if the debtor leaves you holding the bag. ~ Gijs ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DarkMatter Concerns
As an ordinary user from.Russia, I am very glad that DarkMatter is rejected in this thread. If for example there are complaints about some kind of plastic surgeon, then it is better to refuse the operation than to immediately start trying on yourself having believed his documents and risking to get a crooked face... Sincerely, Andrew. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
