| 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? |
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.