On 24/02/17 19:32, Adam Langley wrote:
On Fri, Feb 24, 2017 at 11:09 AM, Rob Stradling via Public wrote:
My current wishlist:
Various EdDSA algorithms. See RFC8032 and
https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/
<https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/>
BLAKE2. See RFC7693. (No signature algorithm OIDs exist yet, AFAICT).
I too have sympathies towards BLAKE2 since I wanted BLAKE to win.
However, given that the winner was Keccak, and its performance doesn't
matter in the context of certificate signatures (well, perhaps for
CRLs), I suspect that we should probably just stick with SHA-3 here.
It's certainly very different from SHA-2 and diversity is a goal.
Hi Adam. I agree that having more options just for the sake of having
more options isn't actually helpful. Enough options to achieve
sufficient diversity is enough.
How much do we care about NIST's blessing these days?
EdDSA/Curve25519/etc isn't a NIST product.
Is there a case for using BLAKE2 for certificate signatures _instead_ of
using SHA-3?
Performance does matter for other uses of hash algorithms, so why not
settle on using BLAKE2 for everything (and not implement SHA-3 at all)?
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
