Yeah, but then you'd run your own closed instance that wouldn’t be trusted by others and you’re back to square one of identifying which key is trusted. The system works best if everyone trusts Google, Microsoft and Github. I guess you can run your own instance in a closed corporate setting (like a custom CA) but it wouldn’t give any benefits for the wider ecosystem.

That’s how I see it, happy to be corrected by someone more intimately associated with sigstore.

The biggest advantage *and* disadvantage is documented right there on their site: https://docs.sigstore.dev/cosign/signing/overview/#logging-in-to-identity-issuers

If you’re okay with the requirement to use OIDC and accepting Google, Microsoft or Github as the ultimate overlords for all signing then it’s all good and the flow is seamless.

Some folks are not comfortable with that but then they have to manage the signing keys themselves (as well as the trust chains) which looks like this: https://github.com/c-ares/c-ares/issues/829 (a random example I found).

Do they?

RSA 4k has slightly more “bits of security” than ed25519 (of course for any practical purpose ed25519 is more than enough). RSA has also more broad support if you need to interoperate with older software.

Fun fact: the ed25519 construction that’s supported by PGP implementations is actually called a “legacy” variant in the new RFC (https://www.rfc-editor.org/rfc/rfc9580.html#name-algorithm-specific-part-for-ed) due to the spec being in limbo for years.