Key Attestation Extension for Certificate Management Protocols

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 11 February 2023.¶

Copyright Notice

Copyright (c) 2022 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

Many different certificate management protocols exist, including:¶

• PKCS #10 [RFC2986]¶
• Simple Certificate Enrolment Protocol (SCEP) [RFC8894]¶
• Certificate Management over CMS (CMC) [RFC5272]¶
• Certificate Management Protocol (CMP) [RFC4210]¶
• Certificate Request Management Format (CRMF) [RFC4211]¶
• Enrollment over Secure Transport (EST) [RFC7030]¶
• Automatic Certificate Management Environment (ACME) [RFC8555]¶

Each of these specifications defines extensibility mechanisms to customize requests sent to a Certification Authority (CA), Registration Authority (RA), or certificate management server. This document addresses the first six specifications in the above list, as all can be customized using attributes or extensions. [RFC8555] is somewhat different and is addressed by [I-D.draft-bweeks-acme-device-attest].¶

Many operating system and device vendors offer functionality enabling a device to generate a cryptographic attestation that can be used to establish the provenance of a key:¶

• Android Key Attestation¶
• Trusted Platform Module¶
• Apple Key Attestation¶
• Yubico PIV Attestation¶

[WebAuthn] defines an "API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users." In support of this goal, it defines a model and corresponding formats to support attestation functionality. Section 6.5 of [WebAuthn] describes the general attestation structure and section 8 defines some specific attestation formats. Similar to [I-D.draft-bweeks-acme-device-attest], this specification uses the attestation object definition from [WebAuthn] as a means of supporting a variety of attestation formats, which are defined in the IANA registry that was established by [RFC8809]; see [WebAuthnReg].¶

This document defines a structure, KeyAttestation, that can be used to convey a [WebAuthn] attestation statement as an attribute or extension when using the protocols listed above.¶

2. 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.¶

3. Key Attestation Attribute or Extension

A key attestation attribute or extension MAY be included in certificate request messages to convey an attestation statement for the private key corresponding to the public key contained in the request. The attribute definition and the certificate extension definition are exactly the same, and they are identified by the same object identifier.¶

ext-keyAttestation EXTENSION ::= {
  SYNTAX KeyAttestation IDENTIFIED BY id-pe-keyAttestation }

attr-keyAttestation ATTRIBUTE ::= {
  SYNTAX KeyAttestation IDENTIFIED BY id-pe-keyAttestation }

id-pe-keyAttestation OBJECT IDENTIFIER ::=  { id-pe TBD }

KeyAttestation ::= OCTET STRING

The KeyAttestation conveys an attestation statement as defined in [WebAuthn] encoded as an OCTET STRING.¶

While the format of an attestation statement varies, all attestation statement formats conveyed via a keyAttestation extension MUST include the public key that is the subject of the corresponding certificate management request. Certificate request messages that contain a key attestation that does not include a public key or that contain a public key that does not match the public key in the certificate request SHOULD be rejected with no certificate issued, however, a CA MAY elect to issue a certificate as if the request did not contain a key attestation per local policy.¶

Some attestation statement formats support the use of challenge password or nonce values. While the means of conveying challenge password value or a nonce value to certificate request clients is outside the scope of this document, each of SCEP [RFC8894], CMC [RFC5272], CMP [RFC4210] and EST [RFC7030] define means for conveying nonce values to certificate request clients. In some cases, challenge password or nonce values may be conveyed outside of a certificate management protocol. For example, SCEP payloads in Apple's Over-the-Air Profile Delivery and Configuration specification [OTA] deliver challenge passwords in an XML-formatted set of instructions.¶

Similarly, use and verification of a nonce value relative to an attestation statement is outside the scope of this document. Verification procedures for currently defined attestation statement formats can be found in Section 8 of [WebAuthn]. Certificate request messages that contain a key attestation that cannot be validated, including processing any nonce or challenge password values, SHOULD be rejected with no certificate issued, however, a CA MAY elect to issue a certificate as if the request did not contain a key attestation per local policy.¶

4. Security Considerations

See Section 13 of [WebAuthn] for additional security considerations related to attestation statement formats, including certificate revocation.¶

CAs, RAs and certificate management servers will need a set of trust anchors to validate attestation statements that may originate from any number of sources. Where possible, a dedicated trust anchor and issuing CA should be used when verifying a given type of attestation statement. Where a trust anchor or issuing CA are shared for mulitple sources of attestation statements, including constraints in attestation signer certificates or attestation certificates is recommended. [COTS] and [fido-metadata] define structures for conveying trust anchors that may be used for verifying attestations such that constraints are implied or are explicitly stated. Expression and validation of constraints imposed on trust anchors, CAs or attestation signers is beyond the scope of this specification.¶

Key attestation statements may include a variety of information in addition to the public key being attested. While not described in this document, CAs, RAs and certificate management servers are free to use any policy when evaluating this information. This evaluation can result in rejection of a certificate request that features a verifiable key attestation for the public key contained in the request. For example, an attestation statement may indicate use of an unacceptable firmware version.¶

5. IANA Considerations

6. ASN.1 Module

The following ASN.1 module makes use of the conventions from [RFC5912].¶

KeyAttestationExtn-2022
  { iso(1) identified-organization(3) dod(6)
    internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
    id-mod-keyAttestation(TBD2) }

DEFINITIONS IMPLICIT TAGS ::=
BEGIN

IMPORTS

  id-pe
  FROM PKIX1Explicit-2009 -- from [RFC5912]
    { iso(1) identified-organization(3) dod(6) internet(1) security(5)
      mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) }

  EXTENSION, ATTRIBUTE
  FROM PKIX-CommonTypes-2009 -- from [RFC5912]
    { iso(1) identified-organization(3) dod(6) internet(1) security(5)
      mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) }
  ;

-- EXPORT ALL --

ext-keyAttestation EXTENSION ::= {
  SYNTAX KeyAttestation IDENTIFIED BY id-pe-keyAttestation }

attr-keyAttestation ATTRIBUTE ::= {
  TYPE KeyAttestation IDENTIFIED BY id-pe-keyAttestation }

id-pe-keyAttestation OBJECT IDENTIFIER ::=  { id-pe TBD }

KeyAttestation ::= OCTET STRING

END

Acknowledgments

TODO acknowledge.¶

Authors' Addresses