<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 9, 2016, at 9:46 AM, Ryan Sleevi <<a href="mailto:sleevi@google.com" class="">sleevi@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Nov 9, 2016 at 9:34 AM, Peter Bowen <span dir="ltr" class=""><<a href="mailto:pzb@amzn.com" target="_blank" class="">pzb@amzn.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">Ryan,</div><div class=""><br class=""></div><div class="">I presume Google has internal controls in place that cover who can sign contracts and under what circumstances. I am inclined to side with Bruce on this one — a signed contract should be prima facie evidence of authorized issuance when the domain registrant is the signer.</div></div></blockquote><div class=""><br class=""></div><div class="">What steps, if any, should we expect you or Bruce to evaluate the validity of that signed contract? That is, what prevents anyone with an @<a href="http://google.com/" class="">google.com</a> e-mail address from signing that contract? I suspect the answer is "Well, that'd be a fireable offense" is the answer, but surely, you would likely consider that unsatisfying.</div></div></div></div></div></blockquote><div><br class=""></div><div>I honestly don’t find that answer unsatisfying. This is a legal question, not a technical one. Why is contract validity for certificate issuance any different from contracts for anything else?</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">For example, what controls in the BRs/EVGs exist to allow Google to notify Entrust of who is authorized to sign contracts? As currently worded, we can only provide that information if we first sign a contract with Entrust - which seems sort of circular, don't you suppose?</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">I think we should add clear notification requirements and domain registrant rights to the BRs, but I think allowing contract signature is a reasonable mitigation. Maybe we tie validation in this case to the EV guidelines — that is the CA must follow the EV guidelines to confirm the contract? Maybe also require CT logging of the CA certificate prior to issuing end-entity certificates and possibly require a waiting period before issuing EE certs?</div></div></blockquote><div class=""><br class=""></div><div class="">What "CA certificate" are you talking about here? Are you imagining technically constrained as an additional clause? Otherwise, we're simply talking about "Enterprise RA" scenarios, right?</div></div></div></div></div></blockquote><div><br class=""></div><div>I got the threads crossed. I thought this was about Tech Constrained SubCAs.</div><div><br class=""></div><div>As I previously suggested, we would also support the Enterprise RA scenario when there is requirement to “call your shot” for which domains are authorized by publicly logging a declaration of delegation to the Enterprise RA.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">The objective we all have here is to do the right thing for customers. Browsers (including Chrome) roll things out gradually and have rollback options. Can we have that here, have a way to require CAA checking but have a “rollback” option in the form of contracts with public notification when such rollback action is being taken?</div></div></blockquote><div class=""><br class=""></div><div class="">While I appreciate the comparison, I do think it's unfair to suggest this is done for everything. Why isn't a secondary ballot a suitable rollback? If we extend your metaphor, browsers don't hide every behaviour change behind a feature flag - they release it, and if it breaks something beyond what was accepted/tolerble, they ship a new release restoring the behaviour, and then evaluate how they can learn from it. This moves us into actual action territory, rather than being mired in FUD and trying to avoid learning about real issues versus imaginary ones. </div></div><br class=""></div></div>
</div></blockquote></div><br class=""></body></html>