(registered 2024-12-23, last updated 2024-12-23)

Media type name: application

Media subtype name: toc+cbor

Required parameters: N/A

Optional parameters: N/A

Encoding considerations: binary

Security considerations: Evidence appraisal is at the core of any attestation protocol flow that delivers Evidence to a Verifier. The Attester may be required to provide Evidence as a condition for gaining access to resources, networks, or services. Attester Evidence therefore needs to be authentic, and integrity protected so that Verifiers can perform appraisals that accurately represent the security posture of the Attester. Any mistake in the appraisal process could have security implications. For instance, it could lead to the subversion of an access control function, which creates a chance for privilege escalation.

Therefore, the Attester’s code and configuration, especially those that collect and protect Evidence, are primary security assets that must be built and maintained as securely as possible.

The protection of the Attester system should be considered throughout its entire lifecycle, from design to operation. This includes the following aspects:

• Minimizing implementation complexity (see also Section 6.1 of [I-D.ietf-rats-endorsements]);

• Using memory-safe programming languages;

• Using secure defaults;

• Minimizing the attack surface by avoiding unnecessary features that could be exploited by attackers;

• Applying the principle of least privilege to the system's users;

• Minimizing the potential impact of security breaches by implementing separation of duties in both the software and operational architecture;

• Conducting regular, automated audits and reviews of the system, such as ensuring that users' privileges are correctly configured and that any new code has been audited and approved by independent parties;

• Failing securely in the event of errors to avoid compromising the security of the system.
The integrity of public and private key material and the secrecy of private key material must always be ensured. This includes key material carried in attestation Evidence and key material used to verify the authority of Evidence (such as public keys that identify trusted Verifiers). For more detailed information on protecting Trust Anchors, refer to Section 12.4 of [RFC9334].

The Attester should use cryptographically protected, mutually authenticated secure channels when supplying Evidence to Verifiers to avoid man-in-the-middle attacks. Also consider minimizing the use of intermediaries: each intermediary becomes another party that needs to be trusted and therefore factored in the Attesters TCBs. Refer to Section 12.2 of [RFC9334] for information on Conceptual Messages protection.

This content is CBOR encoded requiring CBOR parsers that convert the data to a representation consumable by an application. The content is not encrypted or signed, but its anticipated applications require the content to be protected by a secure channel (e.g., TLS, SPDM, CXL) or by a secure token or certificate (e.g., CWT, X.509). The content could contain privacy sensitive values. The use of secure channels that protect confidentiality are recommended by RFC9334. The content may contain hyperlinks or other references to other information. These links and their expected use are defined by a DDL, typically CDDL. This content has already been registered with the CBOR Tags registry (i.e., tag # 570).

Interoperability considerations: Interoperability is achieved through CBOR encoding.

Published specification: https://trustedcomputinggroup.org/wp-content/uploads/TCG-DICE-Concise-Evidence-Binding-for-SPDM-Version-1.0-Revision-54_pub.pdf

See section 6.3.1.

Applications which use this media: RFC9334 defines Attester and Verifier roles. The Attester formats content for conveyance via a secure channel such as SPDM or TLS, the Verfier decodes the content for processing according to draft-ietf-rats-corim or similar verifier.

Fragment identifier considerations: N/A

Restrictions on usage: N/A

Additional information:

1. Deprecated alias names for this type: N/A
2. Magic number(s): N/A
3. File extension(s): N/A
4. Macintosh file type code: N/A
5. Object Identifiers: N/A

Person to contact for further information:

1. Name: Ned M. Smith
2. Email: ned.smith&intel.com

Intended usage: COMMON

Author/Change controller: Trusted Computing Group (TCG) DICE Architecture Working Group