CertificateVerify is not extensible

[yaronf]

We have a section Attestation Alongside X.509 Certificates. But in that section, we only talk about the Certificate message which is extensible to support multiple certs and cert types. However CertificateVerify is not extensible at all, and IMO we should provide proof of possession of both TIK and the regular cert's private key.

[ionut-arm]

I would've thought that if both key attestation and cert are used, they both have to identify the same key (i.e. TIK), would that not be a reasonable restriction?

[yaronf]

@ionut-arm This is sometimes a reasonable option. But IMO, not commonly, because (especially for server clusters) the private key is typically generated outside the protected domain and/or needs to be exported from it. So you cannot attest that it's under control of the TEE.

I'm honestly not clear about the security guarantees we're getting in such cases, even when using an independent TIK. Intuitively the independent option seems better to me, but it's worth some formal analysis.

[yaronf]

Per our discussion, the preferred option is to add a PoP for TIK in the Certificate message (using CMW wrapping?) and leave CertificateVerify to only use the X.509 key.

But we would need to formally verify that this is still secure even though TIK does not behave the same as the X.509 identity key.

[ionut-arm]

One thing still confuses me - do we assume that the attested key is never the key used for the signature in CertificateVerify? Or is it only when attestation and certs are used together that we assume they relate to different keys, and thus we need two PoP, one in CertificateVerify, one in Certificate?

If I understand correctly, there are 4 cases:

• vanilla TLS, only PKIX is used: x509 in Cert message, x509 key used for CertVerify
• attestation-only: att token in Cert message, attested key used for CertVerify
• key attestation + PKIX: x509 and att token + PoP of attested key in Cert message, x509 key used for CertVerify
• platform attestation + PKIX: x509 and att token in Cert message, x509 key used for CertVerify

Am I missing anything?

[thomas-fossati]

Per our discussion, the preferred option is to add a PoP for TIK in the Certificate message (using CMW wrapping?) and leave CertificateVerify to only use the X.509 key.

Copying here a comment I made on the chat: what is the purpose of this PoP if the key is not used in the TLS handshake? If a PoP is needed, it should be completely encapsulated within the remote attestation session (i.e., invisible to the TLS machinery)

[ionut-arm]

Even more specifically, what does key attestation achieve if you have a certificate and a PAT bound to the session? The KAT seems to exist mostly as a bridge between the PAT and the need to sign the TLS handshake with something.

[thomas-fossati]

Even more specifically, what does key attestation achieve if you have a certificate and a PAT bound to the session?

If the key attestation is about a key that is not involved in the TLS handshake in any way, it achieves nothing.

The KAT seems to exist mostly as a bridge between the PAT and the need to sign the TLS handshake with something.

yes

[thomas-fossati]

@artoniemi what is your take here?