Thomas Fossati <[email protected]> wrote: >> > 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 https://github.com/liuchunchi/draft-liu-acme-rats/issues/22 >> > 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.) I think that the Verifier's freshness requirements are something that's part of the trustworthy evaluation of it. >> > > 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. This seems like a general problem. >> 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. okay. -- 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]
