On Wed, Jul 10, 2019 at 7:26 PM Phillip Hallam-Baker <[email protected]> wrote:
> > On Wed, Jul 10, 2019 at 6:11 PM Wayne Thayer <[email protected]> wrote: > >> On Wed, Jul 10, 2019 at 2:31 PM Phillip Hallam-Baker < >> [email protected]> wrote: >> >>> On Wed, Jul 10, 2019 at 4:54 PM Wayne Thayer via dev-security-policy < >>> [email protected]> 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 >>> 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. > > > [1] https://cabforum.org/2019/05/21/ballot-sc17-version-7-alternative-registration-numbers-for-ev-certificates/ [2] https://tools.ietf.org/html/draft-ietf-acme-tls-alpn-05 _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
