Endorsement freshness techniques and best practices

[gkostal]

Endorsement freshness is a complex topic with many variations "in the wild".

The general problem is that the author of a measured component that will be attested is expected to keep verifiers up to date on the trust characteristics of the measured component over time. According to the RATS architecture model, this is communicated via an endorsement. Not covered (as far as I've seen) is a description of techniques along with pros/cons for keeping the verifier up to date with the current endorsement value as it changes over time (e.g., a security vulnerability is found, so the measured component transitions from "trustworthy" to "untrustworthy").

Given that:

• Verifiers typically cache endorsements (reliability, minimize load on endorsement publisher)
• CoRIM is the emerging standard for communicating endorsements
• CoRIM has at least two ways to force verifiers to refresh their endorsement cache (rim_validity field, revocation of cert in signing chain)
• Historically, vendors have not been consistent (e.g., Intel uses ~1 month expiry times for TCB baselines, NVIDIA uses ~1 day CRL check responses for certs)

A community discussion in this space that resulted in:

• a clear understanding and description of the scenario requirements
• a clear understanding of patterns and anti-patterns when leveraging legacy or CoRIM as endorsement vehicles
• "best practices" guidance for various specific use cases

would be wonderful. The more common the designs are, the more successful we can authoring shared tooling. Additionally, the less likely the confidential compute environments have issues (e.g., adoption friction, security issues) if a broader set eyeballs discusses and arrives on a few common patterns.