<div dir="ltr"><div>Hello,</div><div><br></div>While I greatly respect Cloudflare's and Facebook's security teams and believe they are sincere about protecting access to secure connections for vulnerable populations, their joint proposal for an "LV" (Legacy Validated) certificate seems really problematic in the long run.<div><br></div><div><a href="https://blog.cloudflare.com/sha-1-deprecation-no-browser-left-behind/">https://blog.cloudflare.com/sha-1-deprecation-no-browser-left-behind/</a></div><div><a href="https://www.facebook.com/notes/alex-stamos/the-sha-1-sunset/10153782990367929">https://www.facebook.com/notes/alex-stamos/the-sha-1-sunset/10153782990367929</a><br><div><div><br></div><div>At a basic level, this proposal asks CAs -- and the public web -- to take on prolonged systemic risk for an undefined period of time, without any proposals to address the root issue of legacy clients.</div><div><br></div><div>Some immediate concerns:</div><div><ul><li>Under any version of the LV proposal, CAs would be allowed to maintain code paths in their issuance infrastructure that support the SHA-1 algorithm. The criteria for enabling SHA-1 issuance would be based on promises/audits of the org wishing to obtain one, which means the SHA-1 issuance code would be relying on out-of-band factors (rather than an automatable algorithm) for determining whether SHA-1 is an acceptable signature algorithm for the requested certificate.</li></ul></div><div><ul><li>This proposal also adds operational constraints to site owners -- their eligibility for an LV cert requires them to maintain downgrade-proof, thoughtfully designed code to provide different certs to different clients. To the extent the BRs apply operational constraints to CAs, these are accompanied by a system of audits that provide some degree of assurance the operational constraints are being carried out. CloudFlare and Facebook have both released, or pledged to release, the code that executes their certificate-switching. </li></ul></div><ul><li>However, there are no assurances that the public code they release is in fact the code that is running in production. For the strength of LV issuance to meet the standards the CA/B Forum tries to uphold for other forms of validation, organizations requesting them would need to submit to an audit regime, along with defined consequences (and meaningful leverage) for a failed or qualified audit. Whether or not FB or CF are willing to enter such a regime, this adds additional complexity and resource cost -- and an entirely new class of political actors (beyond FB and CF).<br></li></ul><div><br></div><div>A healthier approach would be for affected companies to collaborate with other large/affected institutions to meaningfully address the long tail of legacy clients.</div><div><br></div><div>As challenging and expensive as that may sound, that is already the approach that some global internet companies are taking to provide internet access to populations that have trouble getting it. These are massive subsidies being given to parts of the world that need it, because businesses have seen that it is in their professional (and perhaps personal) interest to ensure that that happens. To the extent internet companies are coming to perceive legacy endpoints as a business risk, it doesn't sound unreasonable for them to pursue similar approaches.</div><div><br></div><div>And there will be time. Just as members of the CA/B Forum informed some of their enterprise customers that they should probably stock up on SHA-1 certificates before the deadline, this option is still open. These certs could be long-lived in duration (it looks like it can go up to 39 months, since the expiry deadline is a SHOULD NOT and not a SHALL NOT), and backups could likely be obtained at the same time to reduce risk. </div><div><br></div><div>While this is a rigid approach, it is an approach where affected stakeholders could absorb the risk, rather than place it on the ecosystem. And in 39 months, legacy client use will diminish regardless of the actions affected stakeholders take.<br></div><div><br></div><div>And at the very least, these SHA-1 certificates will provide a time buffer for the CA/B Forum to decide on future changes in a calmer setting.</div><div><br></div><div>Ryan Sleevi has proposed another approach, of allowing for name-constrained subordinate intermediates, along with the context of why this hasn't been allowed this far:</div><div><br></div><div><a href="https://twitter.com/sleevi_/status/674658891955703808">https://twitter.com/sleevi_/status/674658891955703808</a><br></div><div><br></div><div>Tackling legacy clients in remote, underserved, wartorn areas of the world is obviously a tremendous challenge. Inventing and deploying a new system in 3 weeks for reliably blessing specific companies to serve publicly trusted certificates also sounds like a tremendous challenge.</div><div><br></div><div>I recognize it's very easy for people and companies who don't directly serve vulnerable populations to not attribute enough weight to the on-the-ground political reality for those populations. However, pushing affected companies to channel their business and personal desires to help the vulnerable in a direction that improves those populations' long-term security seems to me like a far healthier reaction than adding weighty process, complexity, and risk to the global CA ecosystem.<br></div><div><br></div><div>-- Eric</div><div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><a href="https://konklone.com" target="_blank">konklone.com</a> | <a href="https://twitter.com/konklone" target="_blank">@konklone</a><br></div></div></div></div></div></div></div>
</div></div></div></div>