tree 43e491fb69ea477b470cf0e1b6b70431cdac6b80
parent a410e2daa716f879ede62862a0351cad3606d11b
author Filippo Valsorda <hi@filippo.io> 1637185080 -0500
committer Gopher Robot <gobot@golang.org> 1648673612 +0000

sumdb/note: relax prescriptiveness of key hash format

The key hash is too short to serve a cryptographic purpose: it is
trivial for example to generate two names that given the same private
key end up with the same key hash. That means the only thing the key
hash does is help pull up the right Verifier, similarly to the X.509
Subject Key ID/Authority Key ID. That's ok.

It's also the case that the Open and Verifier APIs don't enforce a key
hash scheme, so each Signer/Verifier implementation is free to implement
its own. There is already in the ecosystem an ECDSA based implementation
that uses the hash of the SPKI for the key hash (which notably does not
include the name).

We could either try to enforce that every implementation use an
equivalent or specified key hash algorithm, or relax the prescriptiveness.
I think that the latter is the right choice given that as mentioned
above we don't need (or can get) extra properties out of it.

Change-Id: I9730cef862604aa8608d68f7f204f5dddfb4a39b
Reviewed-on: https://go-review.googlesource.com/c/mod/+/364856
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>