Finally get around to looking at sigstore, since several people have mentioned it recently ( @soatok most recently). It confuses me, so will take some time to figure it out fully, so take these comments with a grain of salt.
Something on this design page must be wrong, because these statements combined seem to lead to badness:
“If an OIDC identity or OIDC provider is compromised, Fulcio might issue unauthorized certificates. However, these certificates are useless unless they are published to the certificate transparency log, so such compromise can be detected.”
“To mitigate against OIDC compromise, Fulcio appends certificates to an immutable, append-only cryptographically verifiable transparency log.”
(So Fulcio may issue bad certs, and Fulcio automatically publishes those certs to the log, so they’ll be trusted?)
“Note: Fulcio itself does not monitor the certificate transparency log; users are responsible for monitoring the log for unauthorized certificates issued to their identities.”
The fuck kind of UX is this?
Generally this reinforces my conviction that logs are a poor replacement for working revocation mechanisms.
@neilmadden @soatok CT logs are fairly standard for TLS.
@falken Indeed. I could say a lot about that, but for now I’ll just say that the WebPKI should mostly be seen as a cautionary tale not a source of inspiration. It is adapted to a very specific set of design constraints.
@neilmadden sigstore sounds poor too!
They "handwave" then add a hash of your object to a blockchain they control.
Not sure why this is good.
@falken I don’t think it’s all bad. The OIDC-based issuing of short-lived certs looks like a smart idea. The blockchain stuff is indeed a bit iffy.