Is integrated_time required if inclusion_promiseis present?

[ramonpetgrave64]

Description

Is integrated_time required if inclusion_promise is present?

• https://github.com/sigstore/protobuf-specs/blob/ef40dfbbd35e6efd3c6151e7d24da73f6382e579/protos/sigstore_rekor.proto#L103-L106

To extend a bit more:

Regardless of whether an rf3163 timestamp is present or not, if inclusion_promise is present, then must I check that the integrated_time exists and is within the validity period of the signing certificate?

Related:

• Client spec: Timestamp verification should be best effort, not hard fail #16
• Verifying Signature time when no inclusion promise or integrated time sigstore-python#1380
• Verify artifact signing time against all timestamps sigstore-python#1381

[ramonpetgrave64]

cc: @haydentherapper @loosebazooka

[haydentherapper]

Most clients assume that if an inclusion_promise is present, then they use integrated_time in addition to any other timestamps. If a promise is present, then the integrated timestamp should be present since it's a required field and set by Rekor v1. I would use all available verified timestamps to verify the short-lived certificate.

For a little more info, this should technically be a client policy decision, but only sigstore-go has implemented a policy layer. A clients should be able to decide what set of timestamp authorities, either RFC3161 or log timestamps, are trusted. In sigstore-go, we implemented separate policies for trusting just RFC3161 signed timestamps, just integrated timestamps, or both. This complexity of coupling timestamping to tlog proofs during verification is the motivation for why we removed timestamping from Rekor v2, since timestamping is not independently verifiable unlike inclusion proofs.

[haydentherapper]

Related to #16: How many timestamps are needed to verify a short-lived certificate should also be a policy decision. Right now, most clients (besides sigstore-go) have an implicit policy of 1 valid timestamp - try them all, as long as one verifies, that's sufficient. With both Rekor v1 and Rekor v2, most bundles have only one timestamp, either from the integrated timestamp (for v1) or from the timestamp authority (for bundles with Rekor v2 proofs). There are bundles with both, like the GitHub Artifact Attestation bundles - I would suggest best effort. In the future, we can standardize a policy layer that lets the client state how many timestamps are needed to verify a certificate.

[ramonpetgrave64]

@haydentherapper Can I summarize your opinion like this?

"If inclusion_promise is present, then SHOULD I check that the integrated_time exists and is within the validity period of the signing certificate. If I cannot verify an integrated_time, then I MUST verify a that the a rfc3161 timestamp is within the validity period. ANY one of either the integrated_time or one of the rfc3161 timestamps MUST be verified to be within the validity period. They need not all be verified."

cc: @jku sigstore/sigstore-python#1381 (review)

[haydentherapper]

Yes, that's correct. There must be at least one verified timestamp that falls in the validity window of the certificate.

One additional detail is that some clients also allow the current time to be used as a fallback. This is only relevant for private PKI, which may issue long-lived code signing certificates. For the public instance, this fallback would only help if an artifact was verified within the very brief 10 minute validity window after it was signed. For sigstore-go, we gated this behind a policy since it shouldn't be the default behavior.

Longer term, we'd like to see clients implement https://github.com/sigstore/protobuf-specs/blob/main/protos/sigstore_verification.proto. sigstore-go's verification policy is roughly an implementation of this.