Extended Key Usage (EKU) for X.509 Certificates associated with Attestation Keys

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 21 September 2025.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Attesters, as defined in Remote Attestation Procedures (RATS) in [RFC9334], 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 [RFC5280]). 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.¶

2. Terminology

Much of the terms used in this specification are borrowed from RATS ([RFC9334]). 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 collected claims.¶

3. Extended Key Usage for Attestation Key

This specification defines the KeyPurposeId id-kp-attestationKey. This KeyPurposeId is reserved for Attestation Keys.¶

The term "signing attestation evidence" refers to performing a digital signature using an Attestation Key over content that includes claims about the target environment (see [RFC9334]).¶

An Attestation Key must be associated with the "digital signing" key usage, as any other keys used to performed digital signature. Furthermore, an Attestation Key MUST adhere to the following constraints:¶

• An Attestation Key SHOULD be used only by an Attester to digitally sign claims 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).¶

4. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

5. 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 ([RFC9334]).¶

6. IANA Considerations

IANA needs to assign an object identifier (OID) for this purpose.¶

7. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC5280]

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/rfc/rfc5280>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC9334]

Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/rfc/rfc9334>.

Appendix A. ASN.1 Module

The following ASN.1 module provides the complete definition of the Attestation Key KeyPurposeId.¶

  DEFINITIONS EXPLICIT TAGS ::=

  BEGIN

  -- EXPORTS ALL --

  -- IMPORTS NOTHING --

  -- OID Arc --

  id-kp  OBJECT IDENTIFIER  ::= {
    iso(1) identified-organization(3) dod(6) internet(1)
    security(5) mechanisms(5) pkix(7) kp(3) }

  -- Attestation Key Extended Key Usage --

  id-kp-attestationKey OBJECT IDENTIFIER ::= { id-kp XX }

  END

Acknowledgments

TODO acknowledge.¶

Authors' Addresses