On Tue, 9 Dec 2025 at 20:58, Michael Richardson wrote:
> Thomas Fossati <[email protected]> wrote:
> > On Mon, 8 Dec 2025 at 20:06, Michael Richardson 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.

WFM

> > 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**?

I am not talking about collusion here; I ma assuming an honest
verifier.  I was just trying to understand the freshness story of
attestation-result-01 in the event of a compromised target environment.
According to ยง3.1, the challenge token from the CA/RA is included in the
attestation result.  There is no mention of its inclusion in evidence.
So I was aksing for clarification about the interlocking strategy.
(I suspect this branch of the discussion is OBE now.)

> > > 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.

Or, on the return path, alow the endpoint to inform the CA of the amount
of truncation/padding that was required.

> > 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?

yes

> >> 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*

Yeah, the thing deos have a few interesting trade-offs :-)

> Shouldn't the CA also send nonce2 at 4.5, so that 5 is fresh?

I'm not sure it's relevant to the security of the whole process. The
submission of evidence and the retrieval of the corresponding
attestation results are done within the same appraisal session initiated
by the verifier using "nonce" (1), and then checking that the evidence
contains/signs "nonce" (between 4 and 5).  I think that's what matters.

cheers, t

_______________________________________________
Acme mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to