Skip to content
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

Document/blog post demystifying the SET for Rekor entries #74

Open
lkatalin opened this issue Feb 16, 2023 · 6 comments
Open

Document/blog post demystifying the SET for Rekor entries #74

lkatalin opened this issue Feb 16, 2023 · 6 comments
Labels
enhancement New feature or request

Comments

@lkatalin
Copy link
Contributor

Including:

  • Use cases
  • Payload (as described here)
  • How to correlate SET with <--> UUID of entry

Basically a post walking someone through this for a Rekor entry.

Slack convo ref

@lkatalin lkatalin added the enhancement New feature or request label Feb 16, 2023
@haydentherapper
Copy link
Contributor

We should also document what the SET is not, a proof of an entry being in the log. This has come up a few times that the SET is sufficient for offline verification, because certificate transparency has the same structure (an SCT). Trusting an SET without ever querying the log requires trust in the log, which is antithetical to the design of transparency logs being auditable.

@EstherPhebe
Copy link
Contributor

EstherPhebe commented Apr 5, 2023

Hello @lkatalin @haydentherapper @ltagliaferri I would like to work on this. I did a bit of research and looked into the code, this is the information I currently know. Please could you let me know if I'm on the right path, so I can get started writing a walkthrough. I would also love more information on the correlation between UUID's and SET's other than for verification. Thanks.

The SignedEntryTimestamp (SET) can be thought of as a receipt, that is gotten back from Rekor when an entry has been included into the log. It is a signed inclusion promise provided by the transparency log and can act as a trusted guarantee by the log that the entry has been added to it.

For verification, Cosign queries Rekor to compare the public key attached to the generated certificate (from Fulcio) and checks the Timestamp on the signature against the entry in the transparency log. The signature is valid if its timestamp falls within the small window of time that the key pair and certificate issued by the certificate authority were valid

RekorBundle holds metadata about recording a Signature's ephemeral key to a Rekor transparency log.
type RekorBundle struct { SignedEntryTimestamp [ ]byte Payload RekorPayload }
The Payload consists of all fields required to verify the SignedEntryTimestamp (SET): The body of the Rekor Log Entry, the integratedTime, the logIndex and the logID.

@EstherPhebe
Copy link
Contributor

Hello @haydentherapper @lkatalin @ltagliaferri Could I please get some guidance on this. Thank you.

@lkatalin
Copy link
Contributor Author

Hi @EstherPhebe , thanks for working on this. I will have to dig into this a bit more before I can be helpful, so thanks for your patience.

@EstherPhebe
Copy link
Contributor

Alrighty @lkatalin. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants