# Remote attestation sync up 05/30/2024

## from last meeting

### a correction from the last meeting for authentication and attestation over TLS
* To do remote attestation, it must have mutual authentication
* Server sends the Certificate and must request mutual authentication via CertificateRequest message to the Client
* The evidence is then carried in Certificate message from the Client

---
### Mutual attestation over EDHOC


Discussion in LAKE mail list:
1. Michael: I don't expect two constrained devices to be able to perform remote attestation on each other.

I suppose Michael thinks that mutual attestation happens between the Attester and Verifier, and constrained devices are not able to act as Verifier. But for us, mutual attestation is between the attester and Relying Party.

But I don't understand the following conversation:

---
### New EDHOC Error type "Attestation failed"
* should we keep silence for the achieved remote attestation
* the scope of this error
1. only indicate the failures after the evidence is sent, for the others, define the criticalities of EADs
2. all the errors that cause the attestation fails (no evidence types selected, not able to generate the evidence, the attestation result is negative)(not prefer)

**An example:**

* should receiver know the details of error? (e.g., the error is case 1 or case 2)
* should I specify how the receiver handles the error message?

---
### Security considerations
**an example**


---
## from LAKE mailing list
* indicate the possible cases?
* current case: Initiator is the Attester, background-check model
* possible case: Responder is the Atester (reverse attestation)
* possible case: mutual attestation
* not covered: passport model
* because aTLS in passport model, it will be selecting trusted Verifiers (replace the evidence types), then transport the attestation result (replace the evidence). Then it loses the core process of remote attestation, which is the attestation evidence.
* new update 06/06/2024: passport model can work, since EDHOC can handle with non constrained device.
* make a reference to lake-authz?
---
## a shorter process (reduce the evidence type negotiation)

**Normal case:** Verifier selects based on what are provided by the Attester
**Reduced the negotiation between Relying Party and Verifier:** Verifier tells the Relying Party what evidence types it supports before remote attestation proposal