On Thu, Jul 11, 2019 at 12:19 PM Wayne Thayer <wtha...@mozilla.com> 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 dates and policy identifiers. If you want to avoid trusting legacy certs, all you would need to do is to ignore logotypes in certificates issued before the issuing rules become effective. Since the early adopters would almost certainly be a small, highly motivated group, they would probably get their revalidation done and certificates re-issued to comply. -- Website: http://hallambaker.com/ _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
