Lesson 8.3 · 12 min read
Pinning versus signing, and reference-value governance
Trade-offs between approving exact hashes and trusting a signer, and the approval record an officer keeps.
Two ways to express "approved code"
| Approach | Example | Strength | Weakness |
|---|---|---|---|
| Pin exact measurements | KMS condition on PCR0; Confidential Space policy on image digest | Precise: only this exact build | Every release requires a policy change |
| Trust a signing identity | KMS condition on PCR8 (EIF signing certificate); signed container images | Releases do not require policy changes | Anyone holding the signing key can produce an approved image, so the key becomes the crown jewel |
The reference-value record
For every approved measurement, keep a record containing: the measurement values, source commit, build provenance, who approved it and when, the policies it was added to, and the date it was or will be removed. This record is what an auditor will ask to see.
Key takeaways
- Pinning is precise but requires policy changes per release; signing shifts trust to the signing key.
- Protect signing keys in a KMS or HSM and log their use.
- Keep an approval record per measurement, including removal date.
References: AWS Nitro Enclaves: cryptographic attestation, Confidential Space overview, RFC 9334 (reference values).
End of module 8
Take the module 8 quiz to check your understanding.