Ryan Sleevi <[email protected]> wrote: > On Mon, Nov 21, 2016 at 11:01 AM, Brian Smith <[email protected]> > wrote: > > Absolutely we should be encouraging them to proliferate. Every site that > is > > doing anything moderately complex and/or that wants to use key pinning > > should be using them. > > I do hope you can expand upon the former as to what you see. > As to the latter, key pinning is viable without the use of TCSCs.
A lot of people disagree, perhaps because they read the text after "WARNING:" in https://noncombatant.org/2015/05/01/about-http-public-key-pinning/. If nothing else, using your own intermediate can help avoid the problems with Google Chrome's implementation. (FWIW, Firefox's implementation also can be coerced into behaving as badly as Chrome's, in some situations, IIRC.) > > My hypothesis is that CAs would be willing to start selling such > > certificates under reasonable terms if they weren't held responsible for > > the things signed by such sub-CAs. It would be good to hear from CAs who > > would be interested in that to see if that is true. > > That would require a change to the BRs, right? So far, no CAs have > requested such a change, so why do you believe such CAs exist? > It would require changes to browsers' policies. Changing the BRs is one way to do that, but it seems like CAB Forum is non-functional right now so it might be better to simply route around the BRs. > Why should a technical document be blocked on the policy document? > Nobody said anything about blocking 6962-bis. Removing that one section is a smaller change in terms than the change Google made to the document just last week, as far as the practical considerations are concerned. Regardless, the argument for removing it is exactly your own arguments for why you don't want to do it in Chrome. Read your own emails to learn more about my technical objections to it. Cheers, Brian -- https://briansmith.org/ _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
