-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What payload should we send to the TSA in Sigstore? #116
Comments
I'm currently sending the signature e.g. (sig.Payload()) as the payload to use in the TSA. Happy to hear better suggestions because that would help me with my current development. |
@hectorj2f For attestations, |
@cdris I think when users supply their own timestamp to Rekor its on the client to figure out the correct logic. It's hard to figure out the canoniclization. When Sigstore has it's own TSA I believe it can use the canonicalized Rekor body as the timestamp payload, since it always contains the sig. |
@asraa Agreed, the logic for client-provided timestamps should be on the side of the client. Eventually when Rekor is using the TSA itself, we had discussed Rekor requesting timestamps over the leaf identity hash. |
@asraa For blobs, What would you suggest to use as payload if you decided to use the TSA server, as a replacement of Rekor ? |
|
+1 to @asraa's comment about using the signature. This is in line with other code-signing mechanisms like Authenticode, that describe timestamping as a countersignature (a signature over a signature). This is a great point, let's add this to the README. |
Why base64? I'm also generally confused about the divergence from Rekor. One of the nice things about having (even unauthenticated) extra metadata in the log entry is that it's somewhat less malleable: I can't take a binary with metadata that says it's "cowsay" and then serve it to you later and call it "openssl". (Though, counterpoint: I can currently take someone's Rekor entry and resubmit it with the unauthenticated metadata changed around while the cert is valid.) I do think that signing only the signature is a reasonable decision overall, but I'd like to spell out the motivations. Maybe with a move towards timestamps over naked signatures instead of signatures + metadata, we should start recommending that in most cases signatures should be over attestations about an artifact, and move some of the metadata inside the signed payload. This feels prudent anyway; I think that directly signing a binary is semantically confusing in general. |
No real reason except that's the only thing offered by the interface. You could decode it but it's one more step (which I think the interface should have just given the isgnature bytes) |
This is also super related to: sigstore/protobuf-specs#9 Basically, if the payload sent to the TSA is too complicated, it puts an unncessary burden on clients to reproduce that payload. In the Rekor case the "payload" was the canonicalized entry. |
Agree on sending the signature, this is also how I envisioned it for the Sigstore bundle: https://github.com/sigstore/protobuf-specs/blob/main/protos/sigstore_bundle.proto#L35 |
ACK. IMO we should decode it rather than propagate an accidental decision of one particular library in one particular language, or even better try to get it fixed upstream (this method comes from go-containerregistry IIUC). |
@znewman01 Can you provide an example of this? |
I think binaries/blobs and attestations are both relatively easy, and in fact attestation signatures can be detached to look basically like a blob signature. The complicated parts is actually the other types of signatures: JARs, PKCS7 objects, etc. |
Trying to combine what has been discussed so far, I would think of this like this:
To re-state what @haydentherapper said, this is compatible with Authenticode. Also, as this is decoupled from any of the preparation of a signature creation, it will be easy to adopt regardless on what data the signature is made over, we are only interested in the signature, which is a finite octet-stream. If we want to tie this with Rekor, we can create a counter signature over the SET, without caring how Rekor canonicalizes the entry, all that logic is only related to verifying the SET. I think this provides a nice separation of concerns for the different signatures, and what needs to be verified where. |
I would say it should always be over the artifact signature, not over the SET, because we're timestamping the creation of the artifact, not the SET's creation. For Rekor, it would look something like:
For verification, you must look up both the artifact in Rekor and the 3161 record. Obviously the user experience here isn't ideal because you have to upload two records rather than one, but this is something that @cdris is working on improving by adding support for uploading signed timestamps when uploading an artifact. |
Yeah, the signature over the SET was just a crazy idea I got when I was about to publish the comment. The signature over the artifact's signature is of course the most important one. |
If the client is using the bundle format, the signed timestamp can be added to that. It won't go on Rekor though, but I think this is a reasonable tradeoff. Another use-case is that the request to Rekor for adding an entity can take the signed timestamp as an optional parameter. We won't get the rfc3161 record though, but not sure if that's relevant? |
Correct, the idea would be we replace the |
This includes a security model and how to do timestamping with Sigstore. This includes more details on how to operate the TSA in production also. Fixes #17 Fixes #116 Signed-off-by: Hayden B <[email protected]>
* Update README with more details This includes a security model and how to do timestamping with Sigstore. This includes more details on how to operate the TSA in production also. Fixes #17 Fixes #116 Signed-off-by: Hayden B <[email protected]> * Update from comments Signed-off-by: Hayden B <[email protected]> * Fix link Signed-off-by: Hayden B <[email protected]> Signed-off-by: Hayden B <[email protected]>
Is it going to be the same thing we send to Rekor? Something simpler?
I think I've heard folks chatting about this and maybe there are docs around but would love a place to centralize discussion.
The text was updated successfully, but these errors were encountered: