]> Crypto4A Inc.

1550A Laperriere Ave Ottawa, Ontario K1Z 7T2 Canada jp@crypto4a.com

Entrust Limited

2500 Solandt Road - Suite 100 Ottawa, Ontario K2K 3G5 Canada mike.ounsworth@entrust.com

University of Applied Sciences Bonn-Rhein-Sieg

Germany Hannes.Tschofenig@gmx.net

USA montywiseman32@gmail.com

Internet-Draft As described in RFC5280, key usages are specified in X.509 certificates using the certificate extensions "Key Usage" and "Extended Key Usage". This document defines an Extended Key Usage (EKU) relating to keys that are dedicated to the purpose of signing attestation evidence as introduced in RFC9334.

Introduction Attesters, as defined in Remote Attestation Procedures (RATS) in , can use cryptographic private keys to identify the origin of the evidence and protect its integrity. Those private keys are referred to as Attestation Keys. Attestation Keys can be endorsed by a Certification Authority (CA) by issuing X.509 certificates (see ). Those certificates SHOULD include an extended key usage to indicate that the associated key is dedicated to the purpose of attesting evidence. This allows recipients of signed evidence to trust that the associated key is controlled according to the constraints specified in this document.

Terminology Much of the terms used in this specification are borrowed from RATS (). Readers of this specification should review the RATS architecture and its terminology to put in context the text presented in this specification. Attestation Key : A key under the control of the Attester and reserved for the purpose of signing evidence.

Extended Key Usage for Attestation Key This specification defines the KeyPurposeId id-kp-attestationKey. This KeyPurposeId is reserved for Attestation Keys. The term "signing evidence" refers to performing a digital signature using an Attestation Key over content that includes claims and measurements about the target environment (see ). An Attestation Key must be associated with the "digital signing" key usage, as any other keys used to performed digital signature. No other key usage should be assigned to an Attestation Key. Furthermore, an Attestation Key MUST adhere to the following constraints:

• An Attestation Key SHOULD be used by an Attester only to digitally sign evidence that the Attester can observe in the target environment. The Attester SHOULD NOT use the Attestation Key for any other purpose (dedication).
• An Attestation Key MUST NOT be controlled by any entity other than the associated Attester. This constraint is to ensure that other entity can not impersonate the Attester (non-repudiation).

Including the EKU for Attestation Key in Certificates When the EKU id-kp-attestationKey is included in a X.509, other considerations should be taken:

• The X.509 extension "key usage" MUST be set to "digital signature". In other words, the value of the associated field includes the bit "digitalSignature" set. Other key usages MUST NOT be set.
• The X.509 extension "extended key usage" SHOULD NOT include usage other than the one defined in this document (id-kp-attestationKey). If other extended key usages are provided, they MUST be compatible with constraints outlined in this specification.

When the extended key usage id-kp-attestationKey is added to the X.509 EKU extension, it is not necessary to mark this extension as critical. This is to foster interoperability between systems that are not aware of this extended key usage. Systems that consume the evidence signed by an attestation key, such as a Verifier, can enforce the presence of this extended key usage through policy.

Implication for a Certificate Authority When a Certificate Authority issues a X.509 certificate that includes the extended key usage defined in this specification, certain additional considerations MUST be taken to ensure that the constraints defined in this document are respected. Issuing a X.509 certificate with the extended key usage id-kp-attestationKey equates to providing an endorsement of the attester as defined in the RATS architecture. Therefore, the procedures and practices employed by a Certificate Authority MUST be augmented to take into account the security considerations relating to the Attestation Key as outlined in the RATS architecture. In particular, it is not sufficient for a CA to verify that the subject of the certificate, the Attester, has possession of the subject key. It MUST also ensure that the Attester is the only entity that controls the key. This can be accomplished (but not restricted to) by using a key confined to specialized hardware under the control of the Attester.

Implication for the RATS Verifier In , the Verifier is the role that consumes the evidence produced by an Attester. As part of the verification process, the Verifier assesses endorsements, among other things. A X.509 certificate containing the EKU id-kp-attestationKey is an endorsement of the Attester by the issuing authorities.

Implication for Cryptographic Modules Attestation Keys are instantiated and operated on by cryptographic modules. These modules MUST provide the services required to restrict the use of an Attestation Key to its associated Attester. The mechanisms used to perform those restrictions are out of scope for this specification.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Security Considerations For attestation evidence to be valuable, coordination between the various roles is required:

• The cryptographic module MUST restrict the use of the Attestation Key to the associated Attester.
• The CA MUST ensure that the Attester is the only entity that controls the Attestation Key which is subject to the issuance of a certificate.
• A Verifier must perform the assessment of the presented evidence using all the procedures required to ascertain as to the origin and validity of the attester.

The risks associated with a failure of this coordination reduces the quality of the trustworthiness of the evidence. The implications are outlines in the Security Considerations section in RATS ().

IANA Considerations For the ASN.1 module found in Appendix A, IANA is requested to assign an object identifier for the module identifier (TBD0) with a description of "id-mod-attestation-eku-2025". This should be allocated in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0). For the ASN.1 module found in Appendix A, IANA is requested to assign an object identifier for the extended key usage value (XX) with a description of "id-kp-attestationKey". This should be allocated in the "SMI Security for PKIX Extended Key Purpose" registry (1.3.6.1.5.5.7.3).

Normative References In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

Appendix A. ASN.1 Module The following module adheres to ASN.1 specifications [X.680] and [X.690]. It defines the OID used for Attestation Key Extended Key Usage.

Acknowledgments TODO acknowledge.