On Tue, 9 Dec 2025 at 16:28, Mike Ounsworth wrote: > [...] > Good point about requiring some kind of coordination between ACME and > RATS layers. One example, is that I've been pushing that this draft > include some sort of hint whereby the ACME Server can specify what > property it needs attested -- ex.: some cert profiles might require > proof that the private key is in a FIPS 140-3 module, while others > might require attestation of the serial number of the device, while > others might require proof that you are running the corporate > anti-virus and which Windows domain user is currently logged-in. To > your point: any mechanisms that accomplishes this will involve some > bleed-through -- ie the ACME Server and Client will need at least some > "RATS-awareness".
Yes, that would likely simplify the appraisal policy for attestation results, albeit at the cost of a more "coupled" Verifier. Perhaps, before we start minting new ad hoc claims though, I suggest we should try to see what can be achieved within the boundaries of the AR4SI information model -- also adding specific new categories where appropriate (e.g., "key protection" seems like a useful new AR4SI bucket). _______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
