<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 11, 2016 at 5:26 PM, 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 class="HOEnZb"><div class="h5"><br>
</div></div>You are conflating two things here.  "it's perfectly acceptable for the domain operator to be distinct from the certificate applicant” - Yes.  Akamai or Fastly (or any CDN) can apply for a certificate for a domain registered to one of their customers.  They can even get an OV certificate naming Akamai or Fastly as the organization with customer domain in the SAN.  We have covered this several times.<br></blockquote><div><br></div><div>No, I wasn't conflating them, but perhaps I used imprecise terms that I thought would have been clearer, due to the reference of CAA. In this case, I'm talking about the DNS admin being distinct party from the certificate applicant. That is, if we expect the DNS admin to always be the certificate applicant, then the concerns with respect to CAA are unfounded. However, if they're distinct parties (e.g. the marketing department vs the IT department), as has been advanced as a reason to soft-fail CAA, then we know that there is an internal need for the DNS team to know what the marketing team is doing in a discoverable way.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
"OK to issue certificates not necessarily approved by a central 'policy' team or other business controls” - You will note that I specifically said that I think that CAs should be required to allow registrants to restrict who can authorize issuance.  Right now the BRs have, in section 3.2.5, a similar ability to restrict who can request (apply) for a given Applicant, but there is nothing for domain registrants.  I support hard-fail for CAA which, when combined with registrant dictated approval restrictions, would provide the ability to implement strong business controls.<br></blockquote><div><br></div><div>Given that we don't have hard-fail for CAA (yet), I don't think this problem is solved. It does suggest that this policy only becomes workable with hard-fail with CAA, and with an appropriate policy that can dictate either who can apply or *how* they can apply (e.g. to only allow WHOIS-based contact, rather than file-based).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think you are missing a very reasonable course of action — the <a href="http://example.com" rel="noreferrer" target="_blank">example.com</a> registrant asks the CA to have the subscriber for the unknown certificate contact <a href="mailto:somebody@example.com">somebody@example.com</a>.  In this manner the CA does not provide customer information to a third party without the customer’s consent but there is an opportunity to initiate communication to collaborate to see if revocation is the right answer.  If course if there is no contact then the registrant may request revocation.<br></blockquote><div><br></div><div>It's only reasonable if it's required to be supported ;)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Consider the malicious example where Bob[1] registers <a href="http://sultanofqumarblows.me" rel="noreferrer" target="_blank">sultanofqumarblows.me</a> via a proxy service.  The Qumari government prevails on the Montenegrin government to transfer the domain to the Qumaris.  Now they want to go after Bob so they contact the CA that issued the certificate for <a href="http://www.sultanofqumarblows.me" rel="noreferrer" target="_blank">www.sultanofqumarblows.me</a> and request applicant information.  Should the CA be required to disclose their customer information?<br></blockquote><div><br></div><div>To be clear, I absolutely think there are a number of problems - both with the disclosure of applicant information and domain - under adversarial models. That's part of the problem with redaction, but also recourse - determining who is authorized to know about a certificate.</div><div><br></div><div>I'm much less concerned with disclosing applicant information - I don't think that's particularly germane to the use case (redaction) - but I agree that, if we accept the threat model that those supporting redaction advocate, this is problematic.</div><div><br></div><div>However, if we take the view, as I do, that all publicly-trusted certificates should be publicly disclosed, then I don't think there's any issue here with disclosure of the certificate, nor do I think there's any need to disclose applicant information (at present) </div></div></div></div>