Hi Mike, On Mon, 8 Dec 2025 at 23:38, Mike Ounsworth <[email protected]> wrote: > > 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.
Don't get me wrong; I'm also against scope creep. Who isn't? ;-) And I believe that "as passive as possible transport" should be one of the guiding principles of this work. My point is that, unfortunately, there will necessarily be some impedance mismatch between the RATS and the ACME layer/APIs, which will require some kind of coordination, and can be achieved through OOB mechanisms, discovery, negotiation, or (more likely) a mix of the three. > 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. Yes, but in passport mode, there's also an attester who may need to be told which verifier to use when interacting with a given CA. > 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. Yes, but (see also my reply to MCR), the nonce goes through different APIs, and the overall protocol should ensure end-to-end functionality. > 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). Agree! KISSes, t :-) > > 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]
