
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" dir="auto" class="">There are two possible reasons for limiting the validity interval<div class=""><br class=""></div><div class="">1) To limit the length of CRLs (or equivalent).</div><div class="">2) To enable changes to cryptographic algorithms or withdrawal of certain types of permitted algorithm class to take place more expeditiously.</div><div class=""><br class=""></div><div class="">We are told revocation isn’t the reason for the proposal. While limiting the validity interval of certs by 1/n also reduces data volumes associated with revocation by up to 1/n, it isn’t possible to do away with revocation entirely unless the validity interval is wound down to 7 days or less. </div><div class=""><br class=""></div><div class="">So that leaves us with the second.</div><div class=""><br class=""></div><div class="">No, making one change to one part of the WebPKI is not going to enable cryptographic agility. Right now we don’t have a successor algorithm to SHA-2 implemented anyway unless you count SHA-2-512 and given the length of certificates etc. there is really no performance reason to not use SHA-2-512 for PKIX cert chains anyway.</div><div class=""><br class=""></div><div class="">We are even worse off when it comes to public key algorithms. Due to various Patent FUD and Snowden etc. transition to ECC is pretty much stalled. And right now a much bigger concern than the risk someone will break RSA by factoring is that someone will build a Quantum Computer big enough to scare everyone about Public key in all its current forms.</div><div class=""><br class=""></div><div class="">The cost of the proposed change are significant for the type of enterprise that is not an IT based enterprise. </div><div class=""><br class=""></div><div class="">This looks to me like a big flashy change that will garner praise for the proposer who won’t see any negative impact at all and blame for CAs as their customers discover that they are going to have to make major changes to their operations.</div><div class=""><br class=""></div><div class="">I thought the goal was to make encryption easier. This change is going to make running https markedly harder for a large number of customers who have to be coached through the certificate installation process every time they do it. Automation isn’t currently an alternative and won’t be an alternative unless the automation code is fully integrated into the servers. </div><div class=""><br class=""></div><div class="">My hosting provider recently offered me a free cert from a competitor I won’t name, so I thought I would try it out on one of my sites. An hour later I had SSL up and running perfectly on that site. The only problem was that all my other sites hosted on the same service went down. So when I directed people to the <a href="http://prismproof.org" class="">prismproof.org</a> web site during my Mathematical Mesh talk, they were all getting an error message.</div><div class=""><br class=""></div><div class="">PKI in the real world is utterly unlike the Bay area experience. At one end of the scale you have people who have no technical expertise being coached on the telephone by the sales person and on the other you have F500 companies where the entire IT operation is driven by process and making any sort of change takes months or more.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">That said, even though the purpose of the proposal wasn’t revocation, the discussion of revocation highlights the fact that the lack of fully functioning hardfail revocation remains the major limitation in the WebPKI and we should fix that.</div><div class=""><br class=""></div><div class=""><br class=""></div></div></body></html>