Naming scheme of media-types

[henkbirkholz]

Let's collect candidates and document the decision process in this issue.

[thomas-fossati]

We need to encode two things:

• the TPM 2.0 operation (e.g., quote), and
• the serialisation format (e.g., CBOR, TLV, etc.)

Some proposals:

TPM operation in the media type, serialisation in the suffix

• "application/tpm2_" ${TPM 2.0 op} "+" ${serialisation format}
  • e.g.:
    • application/tpm2_quote+cbor
    • application/tpm2_quote+json
    • Not sure how TLV would be expressed, maybe just as application/tpm2_quote with no suffix?

TPM operation in the media type, serialisation in a parameter

• "application/tpm2_" ${TPM 2.0 op} "; encoding=" ${serialisation format}
  • e.g.:
    • application/tpm2_quote; encoding=cbor
    • application/tpm2_quote; encoding=json
    • application/tpm2_quote; encoding=tlv
      • this format makes things more regular compared to the previous one: TLV is not "special" anymore

Single TPM 2.0 media type with extensible set of ops and serialisation carried in parameters

• "application/tpm2; op=" <TMP 2.0 op> "; encoding=" ${serialisation format}
  • e.g.:
    • application/tpm2; op=quote; encoding=cbor
    • application/tpm2; op=quote; encoding=json
    • application/tpm2; op=quote; encoding=tlv

TPM operation in the media type, serialisation in the suffix

• "application/tpm2+" ${serialisation format} "; op=" ${TPM 2.0 op}
  • e.g.:
    • application/tpm2+cbor; op=quote
    • As above, this makes TLV somewhat special, e.g.: application/tpm2; op=quote

[thomas-fossati]

ACTION @thomas-fossati: send an email to media-types@ietf.org to ask for advice.

[thomas-fossati]

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?

[thomas-fossati]

@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.

[thomas-fossati]

@henkbirkholz put forwards the following list:

• PCRDIGEST
• TPM_KEY_HANDLE
• TPM_NONCE
• TPM2B_{DIGEST,DATA,NAME}
• TPML_{PCR_SELECTION,DIGEST}
• TPMS_CLOCK_INFO

ACTION(@henkbirkholz): talk to Monty and make sure this is all we need.

[thomas-fossati]

Actions list and related timings

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)

[THS-on]

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:

• raw bytes: TCG TSS 2.0 Marshaling/Unmarshaling API Specification (basically size || buffer[size] ): https://trustedcomputinggroup.org/wp-content/uploads/TCG_TSS_Marshaling_Unmarshaling_API_v1p0_r07_pub.pdf
• JSON: TCG TSS 2.0 JSON Data Types and Policy Language Specification Section 2. https://trustedcomputinggroup.org/wp-content/uploads/TSS_JSON_Policy_v0p7_r08_pub.pdf

The 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.

[THS-on]

I can see three approaches:

• register only for the high level structs such as TPMS_ATTEST (still be probably around 10-20)
  • example: application/tcg.tpm2.tpms_attest
• register one type and use a parameter to specify which struct it is (probably does not play nice with things like CoAP)
  • example application/tcg.tpm2; type=tpms-attest
• register one type and define a simple wrapper strucutre that encodes the struct type
  • example: 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.