<div dir="ltr">So we discussed #2 in the context of 213, and prior to that, had similar discussions relating to the context of redaction (and unredaction).<div><br></div><div>I am not sure it's as cut and dry, in part, because of the challenges they present to subscribers. Imagine an entity like Google, which tries to very strictly control who and how validation is performed. By design, support for automated issuance systems on critical properties simply doesn't exist - there's no way you can complete an ACME HTTP-01 challenge on a Google domain, and would literally require new code to be written and globally deployed to be able to do so (with multiple checks and balances along the way).</div><div><br></div><div>Now assume someone performs a DNS hijack through a registrar compromise, temporarily obtains a certificate from one or more automated CAs that only support ACME HTTP-01, and then control of DNS is restored back to Google. How should revocation be authorized?</div><div><br></div><div>That is, the question that remained open in past conversations, and which is as of yet unresolved, is what methods a CA MUST support to authenticate revocation? Should CAs be required to support all of the validation methods in 3.2.2.4 for revocation (if so, then it's all the more reason to quickly get rid of the insecure methods, like .1 and .5, and work to strengthen the presently-weak methods, .6, .8, .9, .10, and 3.2.2.5)? Is it only that some MUST be supported? How does that work for the CAs that claim they only issue certificates based on proof of government identity documents in person - do they now also need to support these automated methods?</div><div><br></div><div>While I can understand your apprehension about the liability, isn't that liability fundamentally introduced by allowing CAs to issue the certificates in the first place? And should we err more on the side of presuming victimhood - and thus proactive revocation (to be mitigated with improved automation, presumably) - or should we adopt a stance that I believe you may be suggesting, which is to presume revocation is highly disruptive?</div><div><br></div><div>One way to remedy many of these concerns is to *only* allow certificates be issued via automated means. Revocation would be able to utilize those same means, and should there be an 'unauthorized' revocation, automation can recover from it. Of all the solutions from the discussions to date, it seems like that is the only one with clear winners on all sides of the equation - users, site operators, browsers, and CAs. This only works if all the automated methods are interoperable, though, but I think the IETF is making good progress there.</div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 22, 2018 at 9:03 PM, Josh Aas via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It can be very difficult for a CA to determine who is the legal owner<br>
of a domain, thus taking action (e.g. revoking) on that basis creates<br>
significant liability. The BRs should not introduce additional rules<br>
requiring such determinations.<br>
<br>
A couple of ideas that don't depend on determining legal ownership:<br>
<br>
1) Let anyone revoke a certificate if they can demonstrate control of<br>
the certificate's private key. Let's Encrypt does this, it has worked<br>
out well.<br>
<br>
2) Allow people to revoke certificates if they can re-validate for all<br>
of the domains in the cert. The Let's Encrypt API also allows this.<br>
<br>
Both of these methods are clearly defined and can be fully automated.<br>
<div><div class="h5"><br>
On Wed, Jan 3, 2018 at 10:59 AM, Wayne Thayer via Public<br>
<<a href="mailto:public@cabforum.org">public@cabforum.org</a>> wrote:<br>
> Matthias,<br>
><br>
> I think you've raised a valid point. I'm working on ballot 213 "Revocation<br>
> Timeline Extension" that makes changes to this section of the BRs, and I<br>
> will draft some language to attempt to address this. If you have any ideas<br>
> on how this requirement should be stated, please let me know.<br>
><br>
> Thanks,<br>
><br>
> Wayne<br>
>><br>
>><br>
>> I can't propose a ballot as I'm not a CAB member but adding the<br>
>> requirement of having to revoke certificates on the domain owner's request<br>
>> should probably be considered.<br>
>><br>
>><br>
><br>
><br>
><br>
</div></div>> ______________________________<wbr>_________________<br>
> Public mailing list<br>
> <a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
> <a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/<wbr>listinfo/public</a><br>
><br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
--<br>
Josh Aas<br>
Executive Director<br>
Internet Security Research Group<br>
Let's Encrypt: A Free, Automated, and Open CA<br>
______________________________<wbr>_________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/<wbr>listinfo/public</a><br>
</font></span></blockquote></div><br></div></div></div>