Hi Peter, On Mon, 8 Dec 2025 at 09:01, Liuchunchi(Peter) <[email protected]> wrote: > The CA/RA should have some prior trust relationship established with > the verifier. In the passport model, a CA would have a list of an > acceptable verifier and corresponding public keys.
In an enterprise environment, this should be quite easy to achieve: 1. The verifier owner is the enterprise itself. 2. Similarly, the RP owner (i.e. the CA/RA administrator) is also tightly coupled with the enterprise (in most cases, I would expect this to be a complete overlap). However, in a more general setting, it looks like the trust relationship establishment may be more complex to bootstrap, which may require some kind of discovery interface. (On a side note: in the background check model where evidence is encrypted, there also has to be a discovery mechanism, maybe via the usual ACME directory, for the attester to discover the verifier’s encryption key. So, yes, discovery tout-court is a feature that probably warrants some further exploration.) > Regarding freshness issue, in my case, there would be a EDR client > software that is responsible for collecting evidences from host > endpoint attester, but I think this is general problem that could be > improved. Any suggestions? If the attestation result format (and the verification API) allow it, requiring the AR to include the same nonce signed by the verifier could achieve binding. It would clearly destroy the cacheability properties of the AR, but that may actually be a good thing in this case :-) > You're welcomed to propose issues and texts at > https://github.com/liuchunchi/draft-liu-acme-rats! ok! cheers, t _______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
