Skip to content

Make timestamp/established time policy enforcement clearerย #1488

@jku

Description

@jku

Currently our established time policy is a little weird and I'd like to to make it clear and correct:

  • we don't (yet) have a way to define more complex policies like requiring more than one timestamp : this is fine
  • The default policy is or should be "require at least one established time from a source listed in trusted_root.json" where established time is a TSA timestamp or alternatively a rekor v1 integrated time
  • Currently there are two issues:
    • If the bundle contains TSA timestamps, then one of the TSA timestamps is ALSO required to be valid (even if the entry is rekorv1 entry and has a valid integrated time). This means an invalid bundle can be made valid by just removing a timestamp from it
    • If a rekor v2 entry did somehow contain an integrated time, this would be a valid established time for the time policy code ... (maybe this is not technically possible but I'd like to see it in the code )

The first issue currently prevents the following scenario

  • sign bundle with --rekor-version 1 cli: Add --rekor-version to sign argumentsย #1471 This leads to a bundle with rekor v1 entry and a TSA timestamp
  • verify bundle with previous release 3.6.4 (currently fails with not enough timestamps validated to meet the validation threshold (0/1) maybe because the timestamp signing key type was not yet supported?)

I don't know how important this is but it feels like a source of future issues.

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingcomponent:verificationCore verification functionality

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions