[Poll] When should we verify the timestamp signature?

[priteshbandi]

Context
NotaryProject is considering adding support for timestamp signatures. This would enable users to verify the authenticity of images even after the signing certificate has expired. During the meeting hend on May 13th, the following options were discussed for handling timestamp signatures:

Option 1: Only Verify Timestamp Signatures if the Signing Certificate Has Expired
The verification operation will evaluate timestamp signatures only when the signing certificate has expired. Essentially, if the signing certificate is still valid, the verification operation wont evaluate timestamp signature. However, once the signing certificate expires, the verification operation will start validating of the timestamp signature.

Pros:

1. Faster signature verification when signing certificate are valid (not expired) as timestamp signature validation is avoided.
2. Owing to the absence of timestamp signature validation, there is reduced latency, enhanced availability (elimination of OCSP/CRL calls for timestamp certificate revocation checks), and decreased computational overhead.

Cons:

1. Introduces a modal behavior where the system's workload for signature verification fluctuates based on the verification timing. This modal behavior can lead to unexpected failures in various scenarios, some of which are outlined below:
   Scenario 1: Invalid/incorrect TSA trust store configuration by the verifier.
   Scenario 2: Corruption of the timestamp signature during signature generation or transmission.
   Scenario 3: Failure to configure network policies to allow OCSP/CRL calls for timestamp signature verification.
   Scenario 4: Increased verification workload (network call, computational cycles, latency) after the signing certificate expires, potentially resulting in unforeseen failures.
   In abovescenarios, signature verification succeeds until Day T but unexpectedly begins to fail on Day T+1. Furthermore, there is no straightforward method for the verifier to proactively detect these failures.

Option 2: Always Validate Timestamp Signatures (if Present)
The verification operation will always validate timestamp signature if it was added during signing, regardless of the signing certificate's expiry.

Pros:

1. Since the signature verification process always evaluates timestamp signatures, a consistent workload is maintained irrespective of the verification timing. This consistency aids in early issue detection and mitigates surprise failures due to scenarios such as invalid/incorrect TSA trust store configuration, corrupted timestamp signatures, and missed network policies.

Cons:

1. If signing certificates are not expired, the verification process will incur additional overhead in verifying timestamp signatures, yielding no security benefits.

To summarize , both options offer equivalent security measures, with the trade-off being additional workload that mitigates fragility/brittleness against some potential availability tradeoff.

Please provide feedback by Thursday, May 16th, to assist in deciding which option to implement.
cc: @shizhMSFT, @NiazFK, @toddysm, @vaninrao10, @yizha1, @gokarnm, @yizha1

Related Slack conversation: https://cloud-native.slack.com/archives/CQUH8U287/p1715294129223819
Related Meeting Notes: https://hackmd.io/_vrqBGAOSUC_VWvFzWruZw?view#May-13-2024

[shizhMSFT]

I vote for option 1.

[yizha1]

I vote for option 1

[toddysm]

Bearing in mind that the industry is driving to short lived certificates, I like the predictability of Option 2. My vote is Option 2.

[Two-Hearts]

I'm voting as Notation subproject maintainer. My vote goes to option 1.

[gokarnm]

I'm voting for option 2. I'd prefer failing fast with option 2 as the default behavior. When we discuss how trust policy interacts with timestamp signatures, we can discuss options for verifiers to set their preferences for timestamp signature verification.

[FeynmanZhou]

Thanks @priteshbandi for starting this poll.

Per Monday's meeting discussion, I would like to clarify more backgrounds to this poll.

This poll is not intended to decide to choose only one option and drop another one. It is intended to determine a reasonable default behavior of timestamp signature verification in Notary Project.

It would be flexible if we make the timestamp signature verification configurable by providing a configuration alwaysVerifyTimestamp=< true | false > to users in the trust policy.

We could determine an appropriate default value (verification behavior) of the timestamp signature verification configuration via this poll.

• If we make the Option 1 as the default behavior, i.e. alwaysVerifyTimestamp=false, it looks much reasonable to me since timestamping is an additional trust source not the primary trust source. Not every signer creates timestamp signature. It would be much more efficient to verify timestamp signatures if the signing certificate expired.

• If we make Option 2 as the default behavior, i.e. alwaysVerifyTimestamp=true, it is too strict in some scenarios which may encounter these two potential issues:

  • Performance bottleneck in a large-scale verification scenario. For example, when a verifier (e.g. Ratify or Kyverno) received 1000 verification requests at once in a multi-cluster environment, the constant timestamp signature verification might be pending or even timeout in an admission control scenario.
  • Unexpected verification failure in an air-gapped environment: When the revocation check endpoints are unreachable, it may cause unexpected timestamp signature verification failure. Thereby the images become untrusted.

I vote for making option 1 as the default behavior.

/cc @notaryproject/notaryproject-notation-maintainers

[gokarnm]

If we plan to introduce additional trust policy switches (I'm in favor of that) they need to be compatible with existing behavior. For example, if I set verification level to strict - Signature verification is performed at strict level, which enforces all validations., option 1 as default is not appropriate.

[priteshbandi]

I vote for option 2.

@FeynmanZhou thanks for adding more context. The issues you have outlined for option2 are also applicable for option1, its just that they wont popup until signing cert expirty.

[rgnote]

I vote for option#2

I like the predictability and simplicity of that option. Also, it is consistent with how AuthenticTimestamps are evaluated for notary.x509.signingAuthority signing scheme.

[JeyJeyGao]

Personally, option 1 has a performance advantage, while option 2 offers predictability. I am wondering if we can maintain the performance of option 1 while also leveraging the consistency benefit.

For signing certificates that are not expired, the trust source is the signing root certificate. Actually, we don't care whether timestamping works or not, because we have enough trust to ensure that the signature was signed while the certificate was valid. To ensure an authentic timestamp, we don't need a timestamp token. (This sentence is important) Then, to maintain the consistent benefit, we can also check the timestamp token but without checking the revocation of the timestamp certificate. Let me explain the reason: by checking the timestamp certificate, we can ensure that the user's trust policy and trust store are correct. If they are not correct, we should output a warning to encourage the user to update their configuration rather than failing the verification. We do not check for revocation because, currently, the trust source is the signing root certificate.

When the signing certificate has expired, we should shift the trust source to the timestamp certificate to maintain the authentic timestamp requirement.

As a result, I maintain my vote for option 1 and consider consistency as a potential improvement.

[vaninrao10]

I'm voting for option 2. I'd prefer failing fast with option 2 as the default behavior.

[yizha1]

@priteshbandi as a follow-up from last meeting, would you mind adding the four cases you shared during the meeting, so that we can continue the discussion under this issue, especially for case 2.

[priteshbandi]

Here are four scenarios involving trust policies and timestamp signatures. For each scenario, we must specify the behavior for parameter “verifyTimestamp” : “afterCertExpiry” | “always”:

1. TrustPolicy contains TSA trust-store | Signature contains timestamp
   • TBD ???
2. TrustPolicy contains TSA trust-store | Signature doesn't contain timestamp
   • TBD ???
3. TrustPolicy doesn't contains TSA trust-store | Signature contains timestamp
   • Don't verify timestamp irrespective of value of verifyTimestamp parameter because user doesnt trust any TSA
4. TrustPolicy doesn't contains TSA trust-store | Signature doesn't contain timestamp
   • Don't verify timestamp irrespective of value of verifyTimestamp parameter because user doesnt trust any TSA

[Two-Hearts]

@priteshbandi you might want to take a look at this flow chart: https://github.com/notaryproject/specifications/blob/8f0be6a5228e16b5079c09266f944977051526cb/specs/trust-store-trust-policy.md#timestamp-countersignature-verification-details

1. TrustPolicy contains TSA trust-store | Signature contains timestamp

• If verifyTimestamp is always, perform timestamp verification.

• If verifyTimestamp is afterCertExpiry, and signing cert has expired, perform timestamp verification. Otherwise, do not perform the timestamp verification, continue to next step.

  There's no failure in this case.

2. TrustPolicy contains TSA trust-store | Signature doesn't contain timestamp

• If verifyTimestamp is always, fail timestamp verification. This makes verification result more stable: an invalid timestamp countersignature would fail the verification, removing it would fail as well.
• If verifyTimestamp is afterCertExpiry, and signing cert has expired, fail timestamp verification (same reason as above). Otherwise, do not perform the timestamp verification, continue to next step.