Open henkbirkholz opened 2 years ago
We need to encode two things:
Some proposals:
"application/tpm2_"
${TPM 2.0 op} "+"
${serialisation format}
application/tpm2_quote+cbor
application/tpm2_quote+json
application/tpm2_quote
with no suffix?"application/tpm2_"
${TPM 2.0 op} "; encoding="
${serialisation format}
application/tpm2_quote; encoding=cbor
application/tpm2_quote; encoding=json
application/tpm2_quote; encoding=tlv
"application/tpm2; op="
<TMP 2.0 op> "; encoding="
${serialisation format}
application/tpm2; op=quote; encoding=cbor
application/tpm2; op=quote; encoding=json
application/tpm2; op=quote; encoding=tlv
"application/tpm2+"
${serialisation format} "; op="
${TPM 2.0 op}
application/tpm2+cbor; op=quote
application/tpm2; op=quote
ACTION @thomas-fossati: send an email to media-types@ietf.org to ask for advice.
Section 4.11.2 of TCG Trusted Attestation Protocol (TAP) Information Model has the following table:
TPM Family | Subtype | Value |
---|---|---|
1.2 | Explicit Attestation using TPM_Quote | 0x00 |
1.2 | Explicit Attestation using TPM_Quote2 | 0x01 |
2.0 | Explicit Attestation using Audit Session and Nonce | 0x02 |
2.0 | Explicit Attestation using Audit Session and Clock | 0x03 |
2.0 | Explicit Attestation using TPM2_Quote | 0x04 |
@henkbirkholz believes this is the list of types that need registering, alongside Canonical Event Log.
Another dimension to consider is the serialisation formats that can be used. I.e., is there JSON or CBOR equivalent to the TLV format?
NOTE: can we avoid supporting 1.2?
@ths-on proposes to make use of the C-structure names.
ACTION(@ths-on): to provide TPMS_ATTEST data structure examples with media-type-friendly typographic conventions.
@henkbirkholz put forwards the following list:
ACTION(@henkbirkholz): talk to Monty and make sure this is all we need.
Description | Holder | Deadline |
---|---|---|
Come up with a consolidated list of TCG representations | @ths-on | 2 Nov 2024 (before IETF 121) |
Go to Monty and do a sanity check | @henkbirkholz | 2-8 Nov 2024 (IETF week) |
Come up with a really consolidated list of TCG representations | @thomas-fossati @henkbirkholz | 2-8 Nov 2024 (IETF week) |
Go with Monty to Murray (or another IANA expert) to search for direction | @thomas-fossati @henkbirkholz | 2-8 Nov 2024 (IETF week) |
I would lobby for only taking the TCG TPM data structures as bytes (i.e. base64 encoded), as this simplifies the usage later on. As far as encoding goes there are the following:
size || buffer[size]
): https://trustedcomputinggroup.org/wp-content/uploads/TCG_TSS_Marshaling_Unmarshaling_API_v1p0_r07_pub.pdfThe two really necessary data structures for attestation are TPMS_ATTEST
and TPMT_SIGNATURE
. Even when looking at only at TPMS_ATTEST
it has 28 different types nested. I think this makes not really feasible to get a media type for each and everyone.
As the raw data are mostly fixed size C structs, I would suggest to use a delta transfer algorithm if only partial information should be transferred.
I can see three approaches:
TPMS_ATTEST
(still be probably around 10-20)
application/tcg.tpm2.tpms_attest
application/tcg.tpm2; type=tpms-attest
application/tcg.tpm2+json
content {"tpms-attest": "base64 data"}
For partial types we could implement a selector application/tcg.tpm2.tpms_attest;select=clockInfo
though again in the IoT use case parameters in media types might not play nice.
Let's collect candidates and document the decision process in this issue.