Inline…
From: Mike Ounsworth <[email protected]> Date: Monday, December 15, 2025 at 12:24 PM To: Henk Birkholz <[email protected]> Cc: Thomas Fossati <[email protected]>, Michael Richardson <[email protected]>, "[email protected]" <[email protected]>, RATS <[email protected]> Subject: [Rats] Re: [Acme] Re: Questions about draft-liu-acme-rats-02 Hi Henk. I am going to make a maybe bold statement here. I have seen Evidence -- I've played with TPM attestation, I've seen PSA Tokens, I'm designing the PKIX-Key-Attest format. But I have never seen an AR. [CW] You have in the form of an API call that processes an attestation in your relying party with an integrated verifier. I've never actually held one in my hand. I find these discussions about what features should and should not be supported for ARs to be rather too abstract. [CW] +1 For example, would an AR satisfying the question "Prove that the device's secure boot chain is intact" be syntactically and semantically interoperable with one satisfying the question "Prove that the device is joined to the Corp Domain and that the currently logged-in user matches the CN in the cert request". Given that I have never actually seen an AR, I don't even know how to start thinking about this question. On Thu, 11 Dec 2025 at 03:19, Henk Birkholz <[email protected]> wrote: On 10.12.25 17:07, Thomas Fossati wrote: > 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). I'd like to put some emphasis on the importance of the topic that Thomas brought up here. Minimizing the number of AR Claims and designing them for re-use is crucial for RATS interoperability (and thereby simpler and also re-usable appraisal policies for ARs across systems and platforms). I really understand the appeal of "adding your claims to the list and be done", but if everybody does this it will ultimately lead to distinct appraisal procedures where every application will come (up) with its dedicated Claims sets that will be very hard to be re-used and interoped with, long term. AR4SI's approach is to design a Claims set layout that allows for semantic interoperability across applications and platforms. Requiring only simple policy, it already allows to be interpreted as a simple bool - even if multiple Claims with detailed values are expressed: as long as all of them are in the "affirming bucket" the whole AR can be appraised as "OK". If you require more detail appraisal for AR, the values in the trust vectors can be subject to more complex policy. This is very much in support of the Relying Party empathy that Mark is looking for. _______________________________________________ RATS mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
