Limited Additional Mechanisms for PKIX and SMIME J.-P. Fiset Internet-Draft Crypto4A Intended status: Informational M. Ounsworth Expires: 21 September 2025 Entrust H. Tschofenig H-BRS M. Wiseman Beyond Identity 20 March 2025 Extended Key Usage (EKU) for X.509 Certificates associated with Attestation Keys draft-jpfiset-lamps-attestationkey-eku-latest Abstract 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]. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-jpfiset-lamps-attestationkey- eku/. Discussion of this document takes place on the Limited Additional Mechanisms for PKIX and SMIME mailing list (mailto:spasm@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/spasm/. Subscribe at https://www.ietf.org/mailman/listinfo/spasm/. Source for this draft and an issue tracker can be found at https://github.com/jpfiset/draft-jpfiset-attestationkey-eku. 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 2. Terminology 3. Extended Key Usage for Attestation Key 3.1. Including the EKU for Attestation Key in Certificates 3.2. Implication for a Certificate Authority 3.3. Implication for the RATS Verifier 3.4. Implication for Cryptographic Modules 4. Conventions and Definitions 5. Security Considerations 6. IANA Considerations 7. Normative References Appendix A. ASN.1 Module Acknowledgments Authors' Addresses 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). 3.1. 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. * The X.509 extension "extended key usage" SHOULD not include usage other than the one defined in this document (id-kp- attestationKey). 3.2. Implication for a Certificate Authority When a Certificate Authority issues a X.509 certificate that includes the extended key usage defined in this document, 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. 3.3. Implication for the RATS Verifier In [RFC9334], 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. While assessing an endorsement provided this way, a Verifier must follow all practices to validate the veracity of the certificate. 3.4. 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 document. 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, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . 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 Jean-Pierre Fiset Crypto4A Inc. 1550A Laperriere Ave Ottawa, Ontario K1Z 7T2 Canada Email: jp@crypto4a.com Mike Ounsworth Entrust Limited 2500 Solandt Road - Suite 100 Ottawa, Ontario K2K 3G5 Canada Email: mike.ounsworth@entrust.com Hannes Tschofenig University of Applied Sciences Bonn-Rhein-Sieg Germany Email: Hannes.Tschofenig@gmx.net Monty Wiseman Beyond Identity United States of America Email: monty.wiseman@beyondidentity.com