On Mon, 8 Dec 2025 at 20:06, Michael Richardson <[email protected]> wrote:
> Thomas Fossati <[email protected]> wrote:
> > I read -02, and have the following questions:
>
> Thank you!
>
> > 1. Why and how the CA/RA come to trust a verifier controlled by the
> > attester is unclear to me. What prevents the attester and verifier
> > from colluding?
>
> I'm unclear how you come to conclude that the Attester and Verifier
> are controlled by the "same" entity. What did we write that said
> that? (It's wrong)
I think I have picked the wrong word "controlled". What I mean is that,
in passport, it's the attester who chooses the verifier from which the
AR is obtained. But as the final consumer of the AR is the CA/RA, this
needs some coordination (via discovery or OOB pre-arrangement),
otherwise you'd end up with a very inefficient process :-)
> [One might however say that a goal of Remote Attestation is to make
> sure that the Target Environment *is* under control of a known
> entity... and for Enterprises, that could be the Enterprise. And not
> the script-kiddies]
>
> In Enterprise cases, if the Enterprise operates the Verifier, and the
> ACME Server/CA is outsourced, then there would need to be some trust
> relationship established. For Passport Model, this means a trust
> anchor.
>
> For Background Check, then the relationship involves some protocol
> between ACME Server and Verifier... I don't have anything concrete to
> point to. It would be nice to point to something. It would involve:
> * a trust anchor (and chain) to sign Attestation Results
> * a DNS name to connect to (if TLS based), or HTTPS resource (if httpapi),
> along with expected trust anchor (if not RFC9525)
> * some IP addresses, port numbers and/or client certificates that identifies
> the ACME Server to the Verifier (or the Verifier's firewalls and/or WAP)
Yeah, that's a problem with the lack of standardised verifier APIs.
> {This is why I think Background Check is more complicated}
>
> In *some* situations, one can imagine that the the relationship is
> "public". As in, Vendor X runs a Verifier that can create ARs for
> product X. (For X in Apple, Dell/{Ubuntu,VMware}, Lenovo/RHEL,
> MS-Surface/Windows...)
>
> > 2. Freshness appears to depend on the inclusion of the
> > CA/RA-presented nonce in the AR. However, it is unclear what would
> > stop a malicious attester from presenting old evidence to the
> > verifier while still requesting that the CA/RA nonce be used in the
> > AR.
>
> If one can posit that there is a malicious *Attesting Environment*,
> doesn't that cancel all the assumptions of 9334?
Hmm, I don't think so. Isn't the whole point of the 9334 game to work
out whether an attesting endpoint is trustworthy? :-)
> Assuming a passport model, the freshness flow would be:
>
> 1. CA/RA-nonce -> system -> Attesting Environment.
> 2. system contacts Verifier, who sends Evidence freshness
nonce -> Attesting Environment
> 3. Attesting Environment sends
> Evidence_ek(CA-RA-nonce,Verifier-nonce) -> Verifier
This step seems problematic. Whether or not both nonces can be included
in the same Evidence payload depends critically on the Attesting
Environment API/ABI. Typically, there is one small, fixed-size slot
(usually 64 bytes, sometimes 32 or 48) available for the nonce/handle
data, and optionally another one for free-form "user data". Even in the
best case scenario of two separate parameters, one still needs to define
how the split CA-RA-nonce and Verifier-nonce are handled. In the worst
case scenario (where there is only one nonce/handle parameter), it seems
like a necessary step to explicitly define the mixing function and pass
the inputs to the verification API for "reconstruction".
To me, broadcasting the same nonce to both the attester and the verifier
seems much simpler. However, this depends on the verifier API allowing
a caller-supplied nonce. (Implementer's note: our verifier allows
that.)
> 4. Verifier checks verifier-nonce, creates
> AR_verifier(CA-RA-nonce,+results)
> 5. system passes AR back to CA/ACME-Server,who as RP, checks that
> nonce.
>
> Step 4 should clarified, I think to say more.
> https://github.com/liuchunchi/draft-liu-acme-rats/issues/19
>
> For background check, it's potentially more complicated.
Architecturally, I see bg-check as a much less convoluted arrangement:
1. V -> CA: nonce
2. CA -> A: nonce
3. A -> CA: E(nonce)
4. CA -> V: E(nonce)
5. V -> CA: AR
6. CA -> A: cert or error
The only caveat is to avoid a potential mismatch in the nonce size
between the attester and the verifier (steps 1 and 2).
> I think that perhaps that we need an additional details in 4.1. The
> token provided in the Challenge Object probably should be created by
> the Verifier, communicated to the RP(ACME Server), to be relayed.
> https://github.com/liuchunchi/draft-liu-acme-rats/issues/20
>
> Or, it could be created by the RP, and when it talks to the Verifier,
> it could provide that nonce to it (the Evidence being potentially
> encrypted)
> https://github.com/liuchunchi/draft-liu-acme-rats/issues/21
cheers, t
_______________________________________________
Acme mailing list -- [email protected]
To unsubscribe send an email to [email protected]
