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

Add option to unify signed and log timestamps #51

Merged
merged 6 commits into from
Jan 3, 2024

Conversation

haydentherapper
Copy link
Contributor

@haydentherapper haydentherapper commented Dec 18, 2023

Summary

This adds the WithObserverTimestamps option to verify that a threshold is
met using both RFC3161 signed timestamps and log integrated timestamps.

This also adds WithIntegratedTimestamps to verify a threshold for log integrated
timestamps.

This updates the verification API for the log to only verify log
inclusion proofs or SETs, so that log and timestamp verification are not
conflated.

This also fixes a bug where the integrated time is used with an
inclusion proof. This is not safe to do, since the integrated time is
not authenticated metadata without a SignedEntryTimestamp signature.

Fixes #44

Release Note

Documentation

@haydentherapper haydentherapper marked this pull request as draft December 18, 2023 23:52
@haydentherapper
Copy link
Contributor Author

haydentherapper commented Dec 19, 2023

@steiza @kommendorkapten @phillmv PTAL (at commit 1a0fa2b, PR will be rebased once the other PR is merged)

The summary of the various options is in #44 (comment)

This is a WIP, looking for early comments. Remaining TODOs:

  • Fix validation logic for what combo of options are allowed
  • Add tests for WithObserverTimestamp
  • Clean up TODOs I left in code (documentation)
  • Separate PR: Add configuration to not count SETs towards log threshold (Default: false for v0.2 bundles, true for v0.1)

Also, this fixes a bug during log entry verification. When an inclusion proof is verified, the integrated timestamp was marked as verified. This is unsafe, because the integrated timestamp is unauthenticated metadata. It can only be trusted when signed over in the case of an SET. Given this library is not widely used, I don't think this needs a CVE (unless you think otherwise), but we should at least ping those who we know use this to upgrade.

@haydentherapper haydentherapper marked this pull request as ready for review December 19, 2023 23:54
@haydentherapper haydentherapper changed the title WIP: Add option to unify signed and log timestamps Add option to unify signed and log timestamps Dec 19, 2023
Copy link
Member

@kommendorkapten kommendorkapten left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good 🚀

@haydentherapper
Copy link
Contributor Author

Thank you @kommendorkapten for the discussions and reviews!

@steiza any comments?

Like sigstore#45, as long as the threshold of expected timestamps is met, then
verification should succeed. Otherwise, entries without trust root
material should be skipped.

One benefit of having the log key ID be used to look up the correct
trust root material is that we can still error out if the signature is invalid.

Ref: sigstore#43

Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>
Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>
This adds the WithObserverTimestamp option to verify that a threshold is
met using both RFC3161 signed timestamps and log integrated timestamps.

This updates the verification API for the log to only verify log
inclusion proofs or SETs, so that log and timestamp verification are not
conflated.

This also fixes a bug where the integrated time is used with an
inclusion proof. This is not safe to do, since the integrated time is
not authenticated metadata without a SignedEntryTimestamp signature.

Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>
Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>
Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>
Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>
@haydentherapper
Copy link
Contributor Author

haydentherapper commented Jan 3, 2024

Copy link
Member

@steiza steiza left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this change gives us the flexibility to cover almost any use case.

I do worry about the complexity of the interface, but I think for many (most?) users, they should just use WithObserverTimestamps() and not need to dive into WithIntegratedTimestamps() vs WithSignedTimestamps().

One minor comment, but I don't feel strongly that the current implementation need to change.

@@ -237,7 +237,7 @@ func main() {

// Check bundle and trusted root for Tlog information
if len(tr.TlogAuthorities()) > 0 && b.HasInclusionPromise() {
verifierConfig = append(verifierConfig, verify.WithTransparencyLog(1))
verifierConfig = append(verifierConfig, verify.WithTransparencyLog(1), verify.WithObserverTimestamps(1))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor: In trying to make sure I understand this pull request, I'm wondering if this should be verify.WithIntegratedTimestamps(1) instead.

Generally, I think we want people to use WithObserverTimestamps() and not have to reason about the specifics of WithIntegratedTimestamps() or WithSignedTimestamps().

But I thought what we were saying on #42 is that the conformance test will infer the verification policy from the trust root, and if the trust root has tlogs entries, we should rely on them both for inclusion and for establishing a timestamp?

I guess when inferring the policy from the trust root, there isn't a way to differentiate today. This isn't a problem really, but it does highlight the complexity of the problem space generally!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, this should be WithIntegratedTimestamps since this is inferring a policy based on if a promise is present. I'll update in a follow up.

In order to infer WithObserverTimestamps, which would be more permissive, it would probably look something like a check for either bundled timestamps or SETs. We could do that here, but we can be more precise with WithSignedTimestamps and WithIntegratedTimestamps.

@haydentherapper
Copy link
Contributor Author

Thanks for the review @steiza! Agreed that the goal is that most if not all users would leverage WithObserverTimestamps. The other options would be for those who have specific requirements, eg only trusting a timestamp authority. At some point in the future, we might be able to deprecate WithIntegratedTimestamps if the log requires timestamps on entry inclusion.

@haydentherapper haydentherapper merged commit 44c7c85 into sigstore:main Jan 3, 2024
8 checks passed
@haydentherapper haydentherapper deleted the refactor-rekor-ts branch January 3, 2024 20:42
haydentherapper added a commit to haydentherapper/sigstore-go that referenced this pull request Jan 3, 2024
Follow up from sigstore#51

Fixes sigstore#62

Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>
haydentherapper added a commit to haydentherapper/sigstore-go that referenced this pull request Jan 4, 2024
Follow up from sigstore#51

Fixes sigstore#62

Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>
haydentherapper added a commit that referenced this pull request Jan 5, 2024
Follow up from #51

Fixes #62

Signed-off-by: Hayden Blauzvern <hblauzvern@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Unifying timestamp verification across SETs and TSA signed timestamps
3 participants