There is some interesting discussion from Filippo on why you might not want to use ML-DSA in things like sigstore.
----
> We designed protocols for 30 years on the assumption that signatures and public keys are marginally ~free. Suddenly replacing them with multi-KB blobs is sub-optimal, but we have the time to do better, especially in the context of synchronous protocols like TLS! (Stuff like firmware signing with timelines in the decades is different, granted, but this CA/BF ballot is about server authentication, proving that the moment we implement this it will be used for TLS.)
----
> Sigstore is a great example, actually. Right now Sigstore works like this:
> Generate a short-lived private key.
Log in to Sigstore with OIDC to obtain a certificate for the key that includes the OIDC metadata.
Use the private key to sign an attestation.
Send the signed artifact and certificate back to Sigstore to get a signed inclusion proof in the transparency log.
Every transparency log entry contains at least one public key and two signatures (one on the cert, one on the artifact). That was fine when they were free, but they are not with ML-DSA!
> Instead, here's a small change to Sigstore that leads to a much better post-quantum system:
> Log in to Sigstore with OIDC and provide the artifact, get back a signed inclusion proof in the transparency log.
>This is completely equivalent in security, but removes both public key and signatures from transparency log leaves. You can then move to ML-DSA for signing the transparency log tree heads (a smaller transition, because it doesn't affect as many parts of the stack).
>ML-DSA support in Go is not the blocker for the bulk of this work.
tjade273•1w ago
----
> We designed protocols for 30 years on the assumption that signatures and public keys are marginally ~free. Suddenly replacing them with multi-KB blobs is sub-optimal, but we have the time to do better, especially in the context of synchronous protocols like TLS! (Stuff like firmware signing with timelines in the decades is different, granted, but this CA/BF ballot is about server authentication, proving that the moment we implement this it will be used for TLS.)
----
> Sigstore is a great example, actually. Right now Sigstore works like this:
> Generate a short-lived private key. Log in to Sigstore with OIDC to obtain a certificate for the key that includes the OIDC metadata. Use the private key to sign an attestation. Send the signed artifact and certificate back to Sigstore to get a signed inclusion proof in the transparency log. Every transparency log entry contains at least one public key and two signatures (one on the cert, one on the artifact). That was fine when they were free, but they are not with ML-DSA!
> Instead, here's a small change to Sigstore that leads to a much better post-quantum system:
> Log in to Sigstore with OIDC and provide the artifact, get back a signed inclusion proof in the transparency log.
>This is completely equivalent in security, but removes both public key and signatures from transparency log leaves. You can then move to ML-DSA for signing the transparency log tree heads (a smaller transition, because it doesn't affect as many parts of the stack).
>ML-DSA support in Go is not the blocker for the bulk of this work.
https://github.com/golang/go/issues/64537#issuecomment-34516...