VERDICT: Strong verification, fragile availability.

VERIFICATION

Binding the inner-TLS peer SPKI to a client nonce and a pinned Nitro PCR0 is a robust identity mechanism. It gives you fresh, replay-resistant proof of exactly which enclave image booted, and it removes dependency on external WebPKI. The client knows it is speaking to the intended code.

Caveat: PCR0 attests only to boot-time image measurement, not to runtime integrity, side-channel resistance, or absence of implementation bugs in the enclave code itself.

AVAILABILITY

Encapsulating a stateful inner TLS byte stream inside HTTPS GET messages creates a category error. GET is idempotent, cacheable, and routinely logged by proxies, load balancers, and web servers. If TLS handshake or record material appears in URLs, query strings, or even GET bodies, secrets are exposed to persistent logs and history. HTTP infrastructure may also replay, buffer, reorder, or drop GETs, which breaks TLS sequencing assumptions and can deadlock or desynchronize the inner state machine. Verification tells you the peer is genuine; it does not prevent HTTP-aware middleboxes from blocking or mangling the channel.

SUMMARY

• Verification = "Is the peer the right Nitro enclave?" Answered well by nonce + PCR0 + SPKI pinning.
• Availability = "Can a reliable, non-logged byte stream reach that peer?" Answered poorly by GET encapsulation.

RECOMMENDATION: Retain the attestation binding; move the inner TLS to a non-idempotent, non-logged bidirectional transport such as a CONNECT tunnel or WebSocket.