[cabfpub] Concerns with the proposal for LV certificates

Bowen, Peter pzb at amazon.com
Wed Dec 16 18:46:48 MST 2015


On 12/10/15, 2:12 PM, Ryan Sleevi <sleevi at google.com<mailto:sleevi at google.com>> wrote:
Among other issues I have with the LV proposal, as suggested, is that it fails to appreciate the economies of scale and how we got here. That is, it (in effect) calls the deprecation of SHA-1 short-sighted (or, worse, self-centered to serve Silicon Valley), and seeks to extend it. It does so with the caveat that every modern browser will or should disable SHA-1, and thus not be at risk.

However, the only reason we're able to get to a point where disabling SHA-1 is viable - which doesn't happen until 2017 and will still be painful - is precisely because SHA-1 is no longer permissible starting in 2016, and the Forum's adoption of the SHA-1 ballot gave clear signals to the industry and webmasters that SHA-1 itself is not viable/secure.

So, in effect, it presumes the benefits of the existing hard deprecation, while attempting to propose a soft deprecation - but this unfortunately doesn't offer a model for future deprecations, because without a hard deprecation, you suffer the first mover problem and can't get enough traction to secure the browser.

We'll inevitably see this with post-quantum crypto and the death of RSA and ECDSA, but I don't feel that LV offers a viable model forward, either for SHA-1 or future migrations.

I share many of the concerns raised by Eric, Andrew and Ryan, but also have a larger concern about the “LV” premise.

There are several different classes of validation today, but they are all points along a single axis.  DV, IV, OV, and EV certificates range from having an anonymous subscriber/subject identity to having a heavily verified identity.  However this only changes the attributes present in the subject distinguished names.  All the other properties of the certificate are the same.  This means that a client that simply implements the X.509/PKIX validation algorithm and requires the id-kp-serverAuth key usage has certain assurances.

LV would change this.  Clients would no longer be able to have an assurance of minimum standards simply by checking that a given certificate has a chain back to a BR-compliant root.  LV would introduce a second axis along which compliant certificates need to be mapped.  It would considerably increase the client complexity for those that do want to differentiate between different validation classes.

There are enough pitfalls today awaiting software developers trying to implement or use certification validation libraries.  The Forum should not create new ones.

Thanks,
Peter


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20151217/e1324627/attachment.html 


More information about the Public mailing list