Hacker News Reader

Comment by di | Hacker News Reader

Anyone can generate a hash. Signing with a private key means that only the owner of that private key was able to generate a given signature. Singing with a private key which was bound to a known identity via a signing certificate proves that only that identity was in possession of the signing key, during a very short window.

In this specific case, we can say that the artifacts in question were verifiably signed by owner of the <release-manager>@python.org identity.

View on HN

But the key pair is not known, you have to put the public key in the trusted registry. Every time you sign, because you get a new key pair.

Why not put a hash in that trusted registry instead?

That's the point of the certificate authority and transparency log: it makes the public key known by publicly binding it to a verifiable identity.

A hash verifies integrity, but has no way to demonstrate any relationship to a signing identity. Signing is not just about integrity, but also being able to say _who_ generated the signature.

I have no idea what you are saying concretely.

The way it seems to me that it works:

* You generate a keypair and use it to sign your Python installer (SP)

* Authority creates a signature of your public key (SA) and puts the whole thing in transparency logs (SP + SA)

* End users can check SA because they trust authority, can check SA is in transparency logs, therefore can trust your signature SP, therefore can trust your software

Why not just use a hash instead:

* You generate a hash of your Python installer (HP)

* Authority creates a signature of your hash (SA) and puts it in transparency logs (H + SA)

* End users can check SA because they trust authority, can check SA is in transparency logs, therefore can trust your hash, therefore can trust your software

What matters is that ultimately the contents of your software are signed by the Authority and a commitment of that is in logs. Why add this level of keys, that can't possibly be trusted since they are ephemeral?

This proposed scheme lacks individual publishing identities, which are desirable. The goal here isn't just to churn out random signatures; it's to be able to associate specific identities (such as a person, GitHub repository, or specific CI workflow) with the production of an artifact.

It also requires the user to trust the signer to do proper secret generation, which is weakens the scheme. With Sigstore, the entire CA and CT infrastructure can fail or be compromised, but the certificates (and the ephemeral keys that they bind to) remain sound. That too is desirable, which is why the TLS PKI ecosystem is the way it is.

Edit: To be clear, the PGP equivalent for your scheme would be "trust Joe Public to sign for everyone on PyPI, he's reliable." If you can see why that doesn't work, you should also be able to see why your alternative to Sigstore won't work.

The certificates remain sound? What does that mean? Those certificates are never to be reused (ephemeral). Do you mean the signature remains valid and secure?

And whether the CA signs "identity information + public key" or "identity information + software hash", I don't see the different in "identities", no matter what that means to you.

Please, give a concrete example of information that is available/verifiable in one scheme and not the other. You both keep saying vague things like "it lacks identities" or "there's a binding" etc and I really don't see it.

Reply on news.ycombinator.com