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
signature.asc
Description: PGP signature
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
