<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 29, 2018 at 3:16 PM, Mike Reilly (WDG) <span dir="ltr"><<a href="mailto:Mike.Reilly@microsoft.com" target="_blank">Mike.Reilly@microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div class="gmail-m_2636573318802803527WordSection1">
<p class="MsoNormal">Ryan, I definitely agree there is a security risk with 3.2.2.4.1 and any other validation method entirely dependent on a “trust us” model. I did see the specifics Jeremy shared about the problems with method 1 in an earlier thread. You
mention in your first reply that “<i>To date, <u>Entrust has not provided</u> any of the requested details about its use of 3.2.2.4.1, the prevalence, and the potential impact</i>” and then later state “<i>the security risk posed by the arbitrariness allowed,
<u>which Entrust has specifically demonstrated</u> their systems are vulnerable to, presents an unacceptably large risk to our users.”
<u></u><u></u></i></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Did I miss a post by Entrust where they specifically provided this security risk detail?
<u>Bruce</u> do you have this info? </p></div></div></blockquote><div><br></div><div>Entrust has not themselves identified the security risk, although it has been pointed out by others.</div><div><br></div><div>To recap the conversation to date:</div><div>- Jeremy Rowley of DigiCert points out the inherent security risks, as written - <a href="https://cabforum.org/pipermail/public/2017-December/012660.html">https://cabforum.org/pipermail/public/2017-December/012660.html</a></div><div> - And further expanded on this in <a href="https://cabforum.org/pipermail/public/2018-January/012683.html">https://cabforum.org/pipermail/public/2018-January/012683.html</a></div><div>- Bruce Morton of Entrust details how Entrust performs this validation - <a href="https://cabforum.org/pipermail/public/2018-January/012691.html">https://cabforum.org/pipermail/public/2018-January/012691.html</a><br></div><div> - Potential problem shared by Jeremy Rowley - <a href="https://cabforum.org/pipermail/public/2018-January/012694.html">https://cabforum.org/pipermail/public/2018-January/012694.html</a></div><div> - Potential problem shared by Ryan Sleevi - <a href="https://cabforum.org/pipermail/public/2018-January/012697.html">https://cabforum.org/pipermail/public/2018-January/012697.html</a></div><div> - Potential problem shared by Jonathan Rudenberg - <a href="https://cabforum.org/pipermail/public/2018-January/012816.html">https://cabforum.org/pipermail/public/2018-January/012816.html</a> / <a href="https://cabforum.org/pipermail/public/2018-January/012835.html">https://cabforum.org/pipermail/public/2018-January/012835.html</a></div><div> - Potential problem shared by Geoff Keating - <a href="https://cabforum.org/pipermail/public/2018-January/012836.html">https://cabforum.org/pipermail/public/2018-January/012836.html</a></div><div> - Potential problem shared by Ryan Sleevi - <a href="https://cabforum.org/pipermail/public/2018-January/012834.html">https://cabforum.org/pipermail/public/2018-January/012834.html</a></div><div><br></div><div>During that discussion, the case of how to handle CAs that are registrars was raised - and addressed (e.g. <a href="https://cabforum.org/pipermail/public/2018-January/012729.html">https://cabforum.org/pipermail/public/2018-January/012729.html</a> ) - the same as situations for handling TLDs that do not operate WHOIS services ( <a href="https://cabforum.org/pipermail/public/2018-January/012712.html">https://cabforum.org/pipermail/public/2018-January/012712.html</a> )</div><div><br></div><div>Further, during the discussion of Entrust's application of 3.2.2.4.1, it was clear that part of that process involved a contact with the organization (per 3.2.5). However, that contact is using unvetted information, since it simply uses a Reliable Method of Communication. Gervase Markham proposed that the concerns could be addressed by contacting the domain holder based on the domain information - <a href="https://cabforum.org/pipermail/public/2018-January/012828.html">https://cabforum.org/pipermail/public/2018-January/012828.html</a> - which is just an application of 3.2.2.4.2/.3 - <a href="https://cabforum.org/pipermail/public/2018-January/012833.html">https://cabforum.org/pipermail/public/2018-January/012833.html</a></div><div><br></div><div>I believe we can comfortably state that the amount of effort, and level of communication, remains the same in the removal of 3.2.2.4.1 (as proposed to 218, which the addition of .12 and clarifications). So CAs that report it as significant work are questionable, because it implies that they're doing less work than those existing methods - which should understandably be concerning, since 3.2.5 requires at least one customer engagement.</div><div><br></div><div>If we want to measure impact to the existing ecosystem, we'd need to measure how many existing certificates are being reused with that less-than-reliable information, which indicates an upper-bound of potential revalidations - although given that these may be reusing information for a domain (e.g. issuing multiple subdomains), it's likely that the actual impact will be several orders of magnitude less. We can then measure this against the total issuance volume within the ecosystem.</div><div><br></div><div>To date, information about that has not been shared - although most recently requested in <a href="https://cabforum.org/pipermail/public/2018-January/012834.html">https://cabforum.org/pipermail/public/2018-January/012834.html</a> - and it's very likely that there's an explanation for why that is, given that this reason was offered previously by Entrust - <a href="https://cabforum.org/pipermail/public/2017-May/010850.html">https://cabforum.org/pipermail/public/2017-May/010850.html</a> - which is that they only maintain these records in vetting files, rather than being accessible or queryable information. It's unclear whether, in light of 190, this has changed, but since it only requires that the CA record this information 'somehow', rather than the proposed programattic method I offered in May 2017 - <a href="https://cabforum.org/pipermail/public/2017-May/010848.html">https://cabforum.org/pipermail/public/2017-May/010848.html</a> - it's not unreasonable to believe so, nor a violation of the BRs today to do so.</div><div><br></div><div>I hope this demonstrates the core facts:</div><div>- The method, as specifically documented by Entrust, does not provide sufficient assurance, nor are they the only CA to have done this (c.f. Symantec)</div><div>- The large scale risks (for ccTLDs and CAs-as-Registrars) are already mitigated in Ballot 218</div><div>- No data has been shared, by any CA, that provides any actionable information regarding their use of 3.2.2.4.1 and the potential impact. We know that some CAs employ this method, we know that it will imply some degree of revalidation, but no objective or actionable discussion about the impact or data to support further delays has been shared.</div><div><br></div><div>I'm sensitive to the notion that changes in the BRs may impact those who don't participate in the discussions, but I am uncomfortable allowing the spectre of 'what if' to haunt us. This is further emphasized by the fact that the information about what CAs use what methods should already be available within their CP/CPS, as per both the BRs and various Root Programs. So if someone wanted to argue about the potential impact, using objective data, that data is readily available for them to collect and present. The abstract hypothetical, however, is uncompelling.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_2636573318802803527WordSection1"><p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">It sounds like all of us agree this risk needs to be mitigated and that some CAs are more capable than others to react to a change in validation method used. I’m trying to get a feel for how much of our ecosystem (either # CAs, % of customer
base or % of certs) relies on method 1 and what impact or disruption is caused to customers (both individual and enterprise) if a significant part of the CA community can’t respond quickly and efficiently to the change. This may support a more deliberate
implementation for the good of the entire ecosystem vs. just a few CAs or one Browser.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Given Tim sent out Ballot 218 version 2 for discussion with an implementation date of August 2018 it sounds like Google would vote “no” if it went to vote. I suppose how each CA votes would be illustrative of how much of the ecosystem
is ready for an August implementation. </p></div></div></blockquote><div><br></div><div>No, we'd vote Yes - for the Baseline Requirements, August is certainly a low-end of a date. Later than August would be a No. But I don't think a "Yes" vote is indicative of support for August being the latest valid date - merely, the latest acceptable date for the BRs to reflect that.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_2636573318802803527WordSection1"><p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I’d really like to see the f2f meetings used to discuss these type of ballots and given #43 is a month away the timing seems appropriate. Discussion could continue for another month via email and teleconference and perhaps a better view
of the business impact to customers could be assessed against the security risk of a graceful implementation. </p></div></div></blockquote><div><br></div><div>While I'm certainly appreciative of the Forum to discuss these things, I think with respect to Bruce's specific request that Root Programs hold off taking steps to protect their users until the Forum has consensus is not reflective of the product or security needs, and thus untenable. I think it also reflects poorly on the Forum if we cannot come to consensus on security-critical changes.</div></div></div></div>