Integrity of revocation lists in Remote Attestation

[Rafal_W_]

In the below text, I assume "client" is an attesting SGX enclave and SP is a Service Provider. Let's assume that client's platform is on an EPID revocation list. RA is performed as follows: 1) Client sends msg1 to SP, msg1 contains client EPID group ID. 2) SP gets revocation list for client EPID from IAS. Question: how can the SP be sure that the revocation list received is genuine? Does it contain some signatures? I can assume that SP logic also runs in an SGX enclave. 3) SP generates msg2 from msg1. This message contains the revocation list. Now, as said above, to protect the SP from malware and/or untrusted personnel I run it in an enclave. msg2 is signed so it can't be tampered with but still the initial data from IAS comes from untrusted source. How can SP be sure that the received data is genuine (or anything is received at all)? 4) Client receives msg2 from SP and generates msg3. I assume sgx_ra_proc_msg2() checks the revocation list in msg2, but how can the client enclave be sure that SP got a genuine response from IAS (since network I/O is always untrusted, even if most SP logic runs in an enclave)? While verifying quote status with IAS the IAS response contains a cryptographic signature over the HTTP body so a SP enclave can verify that the response is genuine. Why is there no such signature in SigRL response?

[Rafal_W_]

After examining the EPID SDK and SGX SDK/PSW sources I think I understand most of the issues. I was wondering why even have the "Get SigRL" API -- IAS obviously has all the revocation lists so it can reject quotes from revoked members. The problem is, an EPID signature includes "non-revoked proofs" so the client Quoting Enclave needs to know the SigRL. Thus, in the scenario from my first post, if the SP sends an empty SigRL to the (revoked) client during RA, the client won't generate non-revoked EPID proofs needed and the IAS will reject the quote with the SIGRL_VERSION_MISMATCH status. Is that correct? So, if the SP logic runs in an SGX enclave that doesn't trust its network data from the "Get SigRL" IAS API and a quote fails IAS verification twice with the SIGRL_VERSION_MISMATCH (with potential "Get SigRL" call in between), then the SP enclave should assume that the IAS communication is being tampered with. Still, it would be nice to just have a cryptographic signature in ALL IAS responses...