9. Claims Encoding Formats

Figure 8 illustrates a relationship to which remote attestation is desired to be added:

   .-------------.               .------------. Evaluate
   |             +-------------->|            | request
   |  Attester   |  Access some  |   Relying  | against
   |             |    resource   |    Party   | security
   '-------------'               '------------' policy

                  Figure 8: Typical Resource Access

In this diagram, the protocol between the Attester and a Relying Party can be any new or existing protocol (e.g., HTTP(S), CoAP(S), Resource-Oriented Lightweight Information Exchange (ROLIE) [RFC8322], 802.1x, OPC UA [OPCUA], etc.) depending on the use case.

Typically, such protocols already have mechanisms for passing security information for authentication and authorization purposes. Common formats include JSON Web Tokens (JWTs) [RFC7519], CWTs [RFC8392], and X.509 certificates.

Retrofitting already-deployed protocols with remote attestation requires adding RATS conceptual messages to the existing data flows. This must be done in a way that does not degrade the security properties of the systems involved and should use extension mechanisms provided by the underlying protocol. For example, if a TLS handshake is to be extended with remote attestation capabilities, attestation Evidence may be embedded in an ad hoc X.509 certificate extension (e.g., [TCG-DICE]) or into a new TLS Certificate Type (e.g., [TLS-CWT]).

Especially for constrained nodes, there is a desire to minimize the amount of parsing code needed in a Relying Party in order to both minimize footprint and the attack surface. While it would be possible to embed a CWT inside a JWT, or a JWT inside an X.509 extension, etc., there is a desire to encode the information in a format that is already supported by the Relying Party.

This motivates having a common "information model" that describes the set of remote attestation related information in an encoding-agnostic way and allows multiple encoding formats (CWT, JWT, X.509, etc.) that encode the same information into the Claims format needed by the Relying Party.

Figure 9 illustrates that Evidence and Attestation Results might be expressed via multiple potential encoding formats so that they can be conveyed by various existing protocols. It also motivates why the Verifier might also be responsible for accepting Evidence that encodes Claims in one format while issuing Attestation Results that encode Claims in a different format.

                Evidence           Attestation Results
.--------------.   CWT                    CWT   .-------------------.
|  Attester-A  +-----------.        .---------->|  Relying Party V  |
'--------------'            |      |            `-------------------'
                            v      |
.--------------.   JWT   .---------+--.   JWT   .-------------------.
|  Attester-B  +-------->|            +-------->|  Relying Party W  |
'--------------'         |            |         `-------------------'
                         |            |
.--------------.  X.509  |            |  X.509  .-------------------.
|  Attester-C  +-------->|  Verifier  +-------->|  Relying Party X  |
'--------------'         |            |         `-------------------'
                         |            |
.--------------.   TPM   |            |   TPM   .-------------------.
|  Attester-D  +-------->|            +-------->|  Relying Party Y  |
'--------------'         '---------+--'         `-------------------'
                            ^      |
.--------------.  other     |      |     other  .-------------------.
|  Attester-E  +-----------'        '---------->|  Relying Party Z  |
'--------------'                                `-------------------'

   Figure 9: Multiple Attesters and Relying Parties with Different
                               Formats

9. Claims Encoding Formats​

9. Claims Encoding Formats