<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 9, 2016 at 9:34 AM, Peter Bowen <span dir="ltr"><<a href="mailto:pzb@amzn.com" target="_blank">pzb@amzn.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Ryan,</div><div><br></div><div>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><br></div><div>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">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><br></div><div>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> </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"><div>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><br></div><div>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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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><br></div><div>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></div></div>