Thomas Fossati <[email protected]> wrote: TF> I read -02, and have the following questions:
Thank you!
TF> 1. Why and how the CA/RA come to trust a verifier controlled by the
TF> attester is unclear to me. What prevents the attester and verifier
TF> 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)
[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)
{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...)
TF> 2. Freshness appears to depend on the inclusion of the
TF> CA/RA-presented nonce in the AR. However, it is unclear what would
TF> stop a malicious attester from presenting old evidence to the
TF> verifier while still requesting that the CA/RA nonce be used in the
TF> AR.
If one can posit that there is a malicious *Attesting Environment*, doesn't
that cancel all the assumptions of 9334?
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
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.
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
--
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]
