Thomas Fossati <[email protected]> wrote: > 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 :-)
Yes, you are right: it could be a problem.
If the Attester picks a Verifier for Passport mode that the ACME Server does
not trust, then it's a fail. I don't think it's a question of discovery, but
rather would require an agreement protocol. Maybe even a zero-knowlege
process in order to avoid each end showing all their cards.
What I would propose for now is that we call out this specific situation, and
that we look for a specific error reply that indicate that this has occured.
That doesn't solve the problem, but at least it clearly communicates what the
problem was.
> 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? :-)
Yes, it's to determine if the target attesting endpoint is trustworthy.
But, how does a *malicious* attacker who controls the **Target Environment**,
collude with the Verifier without also controlling the **Attesting
Environment**?
>> 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".
Fair enough comment: so we might not be able to use every single API, and/or
we might have to extend such a thing.
> 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".
Yes, that's what I was thinking too.
> 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.)
Yes. Good to know ... "our" --- Veraison?
>> 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
Yes, I agree that this could be simpler... for *freshness*
Shouldn't the CA also send nonce2 at 4.5, so that 5 is fresh?
--
] 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]
