[Acme] Re: [Rats] Re: Re: Questions about draft-liu-acme-rats-02

[Carl Wallace <[e-mail]>]

Inline…

 

From: Mike Ounsworth <[e-mail]>
Date: Monday, December 15, 2025 at 12:24 PM
To: Henk Birkholz <[e-mail]>
Cc: Thomas Fossati <[e-mail]>, Michael Richardson <[e-mail]>, "[e-mail]" <[e-mail]>, RATS <[e-mail]>
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 <[e-mail]> 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 -- [e-mail] To unsubscribe send an email to [e-mail]