Thomas, Good points. I agree with all. I'm gonna + the RATS WG on this because there is RATS philosophy below.
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". Passport Model -- I am curious about what is the right philosophy here. This has also come up in the discussion around draft-ietf-lamps-csr-attest; there are really two types of Passport model. Type 1: the device has a hard-coded Verifier to contact -- say, it's manufacturer -- in this type, the AR is sorta filling the role of Evidence; ie from the RA/CA's perspective, it doesn't really matter whether it is presented Evidence signed by an onboard key on the device, or an AR signed by a Verifier run by the device's manufacturer; either way the relevant Trust Anchor is probably the same; the device's manufacturer. Type 2: the RA/CA redirects the device to a Verifier chosen by the RA/CA to obtain a passport and come back. This is necessarily more complex in both wire negotiation, trust anchor management, etc. I suspect for for cert enrollment, where we need to consider Passport Model, it's sufficient to only accommodate Type 1 -- ie the device shows up with Evidence and/or Endorsements and/or ARs and the RA/CA either accepts them or it doesn't, but you don't need any in-protocol negotiation of which Verifier the device is supposed to contact. On Tue, 9 Dec 2025 at 04:29, Thomas Fossati <[email protected]> wrote: > 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]
