rekor icon indicating copy to clipboard operation
rekor copied to clipboard

Design: Allow for storing "signature promises"

Open dlorenc opened this issue 4 years ago • 1 comments

cc @puiterwijk

This would look like an entry in Rekor that includes a digest of a file that will be signed, and the public key that will be used to sign that file.

The inclusion proof of that "promise entry" could then be included in the artifact that is signed, and then the final signature can be stored in rekor, which would include the "promise" as well.

dlorenc avatar Jan 12 '21 14:01 dlorenc

OK - I think I understand this now. In certain cases, we could allow users to verify that an entry is in Rekor without needing hit the Rekor API.

For the producer:

  • Create an artifact, call it A
  • Hash this artifact, call this H(A)
  • Create a rekor entry with the public key that will be used to sign the artifact, and the hash, H(A)
  • Publish this entry to the log, and get a SignedInclusionProof from Rekor. This is signed with Rekor's key P(R). Call this S(P).
  • Attach this proof S(P) to artifact A, creating the final bundle, B.
  • Sign the final bundle B.

For the user who receives Bundle B:

  • This assumes you already have Rekor's public key P(R), If not, you can fetch it without leaking any information on the binary you are trying to verify.
  • This assumes you already have the Publisher's public key P(P). If not, you have to get it somehow. PKI is currently out of scope.

Let's get started:

  • First, verify the signature of the bundle against the publisher's public key P(P).
  • Now, open up Bundle B into two parts: the artifact and the proof.
  • Examine the signed proof S(P). Verify the proof S(P) is correctly signed by Rekor's key `P(R)'.
  • Re-hash the artifact into H(A), making sure the signed proof also covers the correct hash.

We now know that the publisher signed the final bundle (non-repudiation). We also have evidence of this on the Rekor ledger in the form of the pre-signature rekord. Rekor signed this rekord, proving it is in the transparency log.

So, a privacy-concerned user or a user in an offline environment could have confidence that the entry is in the ledger without having to directly check the ledger.

Challenges:

The main challenge I see is being able to correctly separate the final bundle into the attached signature and artifact, in order to correctly calculate the digest of the artifact. This needs to be trivial to do repeatably, so users know which has the original digest was for.

For the RPM example:

  • We start with an unsigned RPM, and create a Rekord using this digest.
  • We then staple on the inclusion proof, sign this, and then attach the signature.

So to get the original digest, we need to reverse the process by removing the signature and inclusion proof.

dlorenc avatar Jan 16 '21 13:01 dlorenc

Closing since Rekor returns a promise (the bundle)

haydentherapper avatar Jan 03 '23 04:01 haydentherapper