Hi Thomas, [Author hat]
First, I think we want to be a little bit careful here about boiling the ocean. Like, you are asking good questions, but I think there's a broader question here about whether ACME (server / client) is an active participant in RATS, or merely a passive transport for it. How does a CA/RA come to trust a given Verifier / RATS trust anchor? Maybe it's a public CA and they have a formal Partner Program. Or maybe it's a corporate CA and they know that they only issue Dell hardware to their employees. Or maybe it's a CA part of a Cloud backend and they know what RATS data they're expecting their kubernetes stack to produce. I think this question is really for the CA to sort out privately, and is out-of-scope for the ACME wire transport protocol being standardized here. Freshness -- I think the scope of this draft-acme-rats is simply to provide a way for the ACME Server to supply the ACME Client with a RATS nonce, and that anything that smells like Appraisal Policy should be outside the scope of this draft. I agree with the point that encrypted Evidence might require a new ACME Directory entry so that the ACME Client can discover the public key that it should encrypt the Evidence for, but I think we should be careful here too about scope creep and try to keep this as a passive transport mechanism (ie as simple as we can get away with). On Mon, 8 Dec 2025 at 13:57, Michael Richardson <[email protected]> wrote: > > Thomas Fossati <[email protected]> wrote: > > 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. > > It's not clear to me that you can even reasonably do this. > There is a business relationship first, and not a *LetsEncrypt* > free-for-all.. > What would you discover? > > > (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.) > > We put that into section 4.1, as: "verifierEncryptionCredential" > It could be that the RP (ACME Server) needs to know more about the client > before it can pick the right Verifier, and therefore the right key. > Remember that the client already logged in with an account, and that has > probably been bound to via externalAccount to the business relationship. > (Again, this is among the reasons I think background check is much more > complicated) > > >> 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. > > Yes. One nonce or two? > Who picked it? RP or Verifier? > > > It would clearly destroy the cacheability properties of the AR, but > > that may actually be a good thing in this case :-) > > Yes, it's a good thing. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | IoT > architect [ > ] [email protected] http://www.sandelman.ca/ | ruby on > rails [ > > > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > _______________________________________________ > Acme 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]
