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>
diff --git a/sumdb/note/note.go b/sumdb/note/note.go
index ebfbe34..4a00501 100644
--- a/sumdb/note/note.go
+++ b/sumdb/note/note.go
@@ -16,9 +16,7 @@
//
// A Go module database server signs texts using public key cryptography.
// A given server may have multiple public keys, each
-// identified by the first 32 bits of the SHA-256 hash of
-// the concatenation of the server name, a newline, and
-// the encoded public key.
+// identified by a 32-bit hash of the public key.
//
// Verifying Notes
//
@@ -77,9 +75,7 @@
// A signature is a base64 encoding of 4+n bytes.
//
// The first four bytes in the signature are the uint32 key hash
-// stored in big-endian order, which is to say they are the first
-// four bytes of the truncated SHA-256 used to derive the key hash
-// in the first place.
+// stored in big-endian order.
//
// The remaining n bytes are the result of using the specified key
// to sign the note text (including the final newline but not the
