Thanks for the response, some great points there! > I noticed recently that Chrome doesn't honor a name constraint on a trust root[1]. So the name constraint y

Thanks for the response, some great points there! > I noticed recently that Chrome doesn't honor a name constraint on a trust root[1]. So the name constraint you mention on the intermediary certificate should be honored, but any name constraints on the Cages root CA may not be (I'm not sure if there is one). Our customers are currently using our clients that attest the connection and honour the name constraint. We'll document what wider support looks like before we release the product fully - we're still in beta atm. Thanks for the tip re BetterTLS! > This reminds me of the AWS Metadata API. If an attacker can trick the user process to read and leak data from that API, they can privilege escalate[2]. AWS hardened that API, which may be a good approach to follow [3]. The attack surface is much smaller than the metadata api due to it only being accessible on the enclave. When the crypto API sends the request to E3 it checks the token and attestation doc to ensure the request came from the right enclave (based on PCRs in the attestation doc), and also the expected IP. That being said I think adding an expected header in the API to mitigate SSRF makes a lot of sense and also blocking requests that have an X-Forwarded-For header.