> On Feb 24, 2017, at 1:34 PM, Gervase Markham <[email protected]> wrote: > > Hi Philip, > > This is a useful timeline. It may be missing a few items, though: > > On 24/02/17 09:58, philliph--- via Public wrote: >> The availability of HSMs is a concern but it is actually the very last >> but one on the critical path which is at present >> >> * NIST issues FIPS (done) >> * IETF publishes specification (started on this) >> * CABForum amends guidelines to permit use > > * OS vendors and crypto libraries add support > >> * Browsers add support >> * HSM vendors ship product >> * CAs issue certificates. > > There is also another item: "Root store policies amended to permit use". > However, where that goes and where the CAB Forum item goes is flexible; > both have to happen before "CAs issue certificates" but they don't > necessarily have to happen earlier than that. Having said that, I can > see a case for a CAB Forum "motion of intent" to set direction. What > algorithms other than SHA-3 would we want to include in such a motion?
There are many moving parts to the puzzle, agreed. The reason I left out the crypto libs is that it only requires them to add existing code. They can all add the same code in fact. A motion of intent sounds like a good way forward. The complicating factor is the ECC work which is the reason I have been waiting to launch this. My original plan was to propose Curve-X forst after the CURDLE WG was finished with their PKIX draft. That is now in WG last call. I was going to do SHA-3 second. Given the SHA-1 situation I think SHA-3 is more urgent. But my desired endpoint is to have SHA-3 and Curve-X in the acceptable algorithms. The issue with Curve-X is that right now the specs are completely new and so there are no implementations of the final spec anywhere. There are not even that many implementations of the Curve-X signature algorithm. We are clearly no ready to add Curve-X to the accepted algorithms but we could have a motion of intent to do so. And I think that would be very useful. The argument for Curve-X is in two parts, first, why move from our existing NIST curves? * Deployment of the NIST curves has been stalled due to the Snowden/BULLRUN/DUAL-EC-RNG fiasco. * The NIST curves are now quite old and they are based on a construction approach that is no longer considered to be state of the art. They are not rigid construction and they were constructed before the need to demonstrate the parameters are free from interference was understood. * The NIST curves compete with several others (Brainpool etc.) * The NIST curves require competent implementation to be secure. They are not robust against certain types of attack. The implementations could not use certain point compression techniques that improve security but were encumbered. * The international crypto community has possibly relied on NIST rather too much. It is important to remember that we are not just relying on an institution, we are relying on people and many if not most of the people we rely on are passed their civil service retirement point. The arguments for Curve-X are * The curves and the signature algorithm are entirely modern and state of the art. They have been thoroughly vetted and reviewed by a blue ribband panel of leading international cryptographers. * Curve25519 has a vast deployment base outside PKIX, much larger than the NIST curves. * Curve25519 and Curve 448 have market momentum. IETF is making them the de facto next generation public key algorithm as the successor to RSA. * The CFRG curve competition has effectively cleared all the competing curves from the board. The curve zoo of 30+ possibilities has been reduced to two clear choices. The main argument against is: * Quantum Cryptanalysis could render all this pointless. But since it would also take out RSA and is a hypothetical and we don’t have anything close to a QRC alternative, its not an argument against having a backup for RSA2048. I have little doubt that the industry will eventually settle on the Curve-X work. It is not my absolute favorite set of choices on a technical level but it is certainly a result I can and do endorse. The question now is whether CABForum should try to speed up that transition process or not. The main argument against would be if there was the possibility of yet another alternative appearing and I really don’t see that happening. Just as the AES competition killed most development of new symmetric algorithms for a decade and the SHA-3 competition has likely done the same, I don’t see any real likelihood of a new Public Key algorithm being promoted as a standard for use in IETF, W3C or OASIS protocols for quite a while. I would expect that cryptographers looking to make their mark right now would be looking at QRC approaches and working to refine those. _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
