rekor
rekor copied to clipboard
sigstore
Planning for deprecation log
I am hearing more and more demand for this. folks want a way to mark nefarious / deprecated images and releases, so users can query to see if an image is considered safe to use. From a cursory look , we should be able to work with the current default x509 type, but some extra fields may be useful (for example CVE numbers, EOL dates).
This has come up a few times recently, and I just had a thought. What if instead of deprecation logs, we flip things around and add validity logs?
I outlined this here: https://dlorenc.medium.com/policy-and-attestations-89650fd6f4fa, but attestations around supply chains are best phrased as positive statements, rather than negative ones. A deprecation log is similar to a revocation log - they both fail open rather than closed.
What if artifacts could be explicitly "allowed" for a given time period from when they are published. Usage beyond then is permitted by explicit re-attesting to the artifact's validity. The usage of a transparency log turns this into a "global build horizon".
The validity period is explicitly controlled by the publisher, and there is a natural trade-off between how frequently artifacts must be re-attested with the complexity/work required by the publisher. Clients are free to make the same tradeoff - checking less frequently than is requested by the publisher, trading timeliness of effective revocation for operational simplicity.
This is basically TUF - but from a slightly different angle...
Interesting, I think there is still valid use for a dlog (I just made a word).
How do you see the re-attesting occur , would this be a case of publishers resign all supported releases again?
Yeah - instead of "this is now deprecated", the log switches to "this will deprecate on X date, unless you hear otherwise saying it's good for longer".