> *ONE* of the challenges. > But more than one challenge needs to be done.
I don't understand why this is true. Maybe this is because I don't fully understand how RATS attestations work. My understanding is that the server has some set of things that it wants the client to prove, e.g. that the client's OS is up to date, and it is in FIPS mode, and that the key lives in a TPM. My reading of RFC 9334 suggests that a Remote Attestation Result can contain any number of claims. If that is true, then all the claims the server wants to see can be satisfied by a single challenge. If that is not true, then what is stopping the server from creating multiple Authorization objects, each with one claim that the client needs to prove? In either case, each Authorization will be fulfilled by exactly one challenge. No need for multiple challenges to be completed. Aaron On Wed, Jul 23, 2025, 06:34 Michael Richardson <[email protected]> wrote: > > Having been through the entire thread. > It seems that my *very* *initial* view that we should do this via the > account, > and the Extended Accounting Binding might actually be reasonable? > > Aaron Gable <[email protected]> wrote: > > I *believe* that the reason the design team has gone in this > direction is > > because the rats identifier does not appear in the final issued > > certificate. Is that correct? > > Yes. > > > If yes, *why* does no corresponding identifier appear in the cert? > > What would it say? While there are some small number of use cases where > putting Attestation Results into a certificate makes sense, in most cases > it's just a privacy violation waiting to happen... and as MikeO said, it > might not even be valid for the lifetime of the certificate. (Not that the > device is bad at that point!) > > > If the CA is enforcing that certain policies be met, then can't that > be > > represented by a Certificate Policies extension? > > Yes, the CA can put a policy OID in to say that it's done this check. > Or, even that, the CA has followed it's CSP. > > As you write in another email, the identity challenge can be loopholed > because we didn't precisely say what identity is. It just feels totally > wrong to widen that loophole. > > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- *I*LIKE*TRAINS* > > > >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
