]>

me@brandonweeks.com

ganesh.mallaya@appviewx.com

sven.rajala@keyfactor.com

corey.bonnell@digicert.com

Security ACME Working Group Internet-Draft This document specifies new identifiers and a challenge for the Automated Certificate Management Environment (ACME) protocol which allows validating the identity of a device using attestation.

Introduction The Automatic Certificate Management Environment (ACME) standard specifies methods for validating control over identifiers, such as domain names. It is also useful to be able to validate properties of the device requesting the certificate, such as the identity of the device and whether the certificate key is protected by a secure cryptoprocessor. Many operating systems and device vendors offer functionality enabling a device to generate a cryptographic attestation of their identity, such as:

• Android Key Attestation
• Chrome OS Verified Access
• Trusted Platform Module
• Managed Device Attestation for Apple Devices

Using ACME and device attestation to issue client certificates for enterprise PKI is to be a common use case. The following variances to the ACME specification are described in this document:

• Addition of permanent-identifier and hardware-module identifier types.
• Addition of the device-attest-01 challenge type to prove control of the permanent-identifier and hardware-module identifier types.
• The challenge response payload contains a serialized WebAuthn attestation statement format instead of an empty JSON object ({}).
• Accounts and external account binding being used as a mechanism to pre-authenticate requests to an enterprise CA.

This document does not specify the attestation verification procedures. Section 13 of gives some guidance, however verification procedures are complex and may require changes to address future security issues. Efforts are underway within the Remote ATtestation ProcedureS (RATS) working group to define a set of standard formats and protocols for attestation. An explicit aim of this document is to support vendor specific formats and protocols that are widely deployed at publication time of 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.

Permanent Identifier A new identifier type, "permanent-identifier" is introduced to represent the identity of a device assigned by the manufacturer, typically a serial number. Additionally, the assigner of the identifier MAY also be specified. The name of this identifier type was chosen to align with . This specification does not prescribe the lifetime of the identifier, which is at the discretion of the Assigner Authority. Although permits any valid UTF-8 string to be used as the identifier, this specification mandates that identifiers MUST NOT contain the forward-slash "/" (UTF-8: U+002F) character. This restriction is required to make the ABNF production rule for the permanent-identifier-value unambiguous.

Representation in Order resources The identifier's value field contains a UTF-8 string representation of the identity of the device. In addition to the value being a valid UTF-8 string, the value MUST match the permanent-identifier-value production rule as defined in this ABNF syntax: ``` assigner-value = ("0" / "1" / "2") 1("." 1DIGIT) device-identifier-value = 1*(%x00-2E / %x30-FF) permanent-identifier-value = device-identifier-value ["/" assigner-value] ``` A valid permanent-identifier-value value is a UTF-8 string that contains an identity consisting of one or more characters without any forward-slash "/" (UTF-8: U+002F) characters. Optionally, a forward-slash "/" character and "dotted-decimal" object identifier identifying the assigner may follow the identity. Example identifier without an assigner: { "type": "permanent-identifier", "value": "ABCDEF123456" } Example identifier with an assigner: { "type": "permanent-identifier", "value": "ABCDEF123456/1.2.3.4" }

Representation in Certificate Signing Requests and X.509 Certificates The identity is included in the Subject Alternative Name Extension using the identifierValue field of the PermanentIdentifier form described in . Although permits the requester to include the identifierValue in a serialNumber subject attribute, this specification mandates that the identifierValue field of the PermanentIdentifier MUST be present and MUST contain the identifier. The value of the identifierValue field of the PermanentIdentifier MUST be an octet-for-octet match of the device-identifier-value value as encoded in the Order resource. If the assigner-value value is included in the identifier as encoded in the Order resource, then the assigner field of the PermanentIdentifier MUST be the encoding of the "dotted-decimal" object identifier encoded as the assigner-value value. To ensure that the identifier as presented in the Order resource and CSR match, the Server MUST perform the logical equivalent of extracting the device-identifier-value and assigner-value values from the CSR and reconstructing the UTF-8 representation of the identifier. The Server MUST then ensure that the UTF-8 representation and the identifier presented in the Order resource are an octet-for-octet match and reject the Order otherwise. section 7.4 mandates that "The CSR MUST indicate the exact same set of requested identifiers as the initial newOrder request". However, there are some environments where the Server requires validation of the identifier but does not include the identifier in certificates due to privacy concerns. To support privacy-preserving certificates, Clients MAY omit this identifier in the certificate signing request (CSR). Similarly, if the Server wishes to issue privacy-preserving certificates, it MAY reject CSRs containing a PermanentIdentifier in the subjectAltName extension.

Hardware Module A new identifier type, "hardware-module" is introduced to represent the identity of the secure crypto-processor that generated the certificate key. The identity is modeled after the HardwareModuleName form described in . It consists of two components: an OBJECT IDENTIFIER to represent the type of hardware module, and a serial number that identifies the specific hardware module. Although specifies that serial numbers can be represented as any sequence of bytes, this specification requires that serial numbers MUST be representable as valid UTF-8 strings consisting of at least one code point and MUST NOT contain a forward-slash "/" (UTF-8: U+002F) character. These restriction ensures that serial numbers can be included in hardware-module identifier string values and that the ABNF production rule for the value is unambiguous.

Representation in Order resources The identifier's value field contains a UTF-8 string representation of the identity of the hardware module. In addition to the value being a valid UTF-8 string, the value MUST match the hardware-module-value production rule as defined in this ABNF syntax: ``` hw-type-value = ("0" / "1" / "2") 1("." 1DIGIT) hw-serial-num-value = 1*(%x00-2E / %x30-FF) hardware-module-value = hw-serial-num-value ["/" hw-type-value] ``` A valid hardware-module-value value is a UTF-8 string that contains a serial number consisting of one or more characters without any forward-slash "/" (UTF-8: U+002F) characters. Optionally, a forward-slash "/" character and "dotted-decimal" object identifier identifying the hardware type may follow the serial number. Example identifier with the type of the hardware module represented using the OBJECT IDENTIFIER "1.2.3.4" and a serial number of "ABCD": { "type": "hardware-module", "value": "ABCD/1.2.3.4" } Example identifier with no type specified and a serial number of "ABCD": { "type": "hardware-module", "value": "ABCD" }

Representation in Certificate Signing Requests and X.509 Certificates The hardware module identity is included in the Subject Alternate Name Extension using the HardwareModuleName form described in . The HardwareModuleName is encoded as an otherName with the OID id-on-hardwareModuleName (1.3.6.1.5.5.7.8.4) and consists of:

• hwType: An OBJECT IDENTIFIER that identifies the type of hardware module
• hwSerialNum: An OCTET STRING containing the hardware module serial number

The value of the hwSerialNum field of the HardwareModuleName MUST be an octet-for-octet match of the hw-serial-num-value value as encoded in the Order resource. If the hw-type-value value is included in the identifier as encoded in the Order resource, then the hwType field of the HardwareModuleName MUST be the encoding of the "dotted-decimal" object identifier encoded as the hw-type-value value. To ensure that the identifier as presented in the Order resource and CSR match, the Server MUST perform the logical equivalent of extracting the hw-serial-num-value and hw-type-value values from the CSR and reconstructing the UTF-8 representation of the identifier. The Server MUST then ensure that the UTF-8 representation and the identifier presented in the Order resource are an octet-for-octet match and reject the Order otherwise. section 7.4 mandates that "The CSR MUST indicate the exact same set of requested identifiers as the initial newOrder request". However, there are some environments where the Server requires validation of the identifier but does not include the identifier in certificates due to privacy concerns. To support privacy-preserving certificates, Clients MAY omit this identifier in the certificate signing request (CSR). Similarly, if the Server wishes to issue privacy-preserving certificates, it MAY reject CSRs containing a HardwareModuleName in the subjectAltName extension.

Device Attestation Challenge The Client can prove control over a permanent identifier of a device by providing an attestation statement containing the identifier of the device. The device-attest-01 ACME challenge object has the following format:

type (required, string):

The string "device-attest-01".

token (required, string):

A random value that uniquely identifies the challenge.

A Client fulfills this challenge by constructing a key authorization () from the "token" value provided in the challenge and the Client's account key. The Client then generates a WebAuthn attestation object using the key authorization as the challenge. This specification borrows the WebAuthn attestation object representation as described in Section 6.5.4 of for encapsulating attestation formats, but with these modifications:

• The key authorization is used to form attToBeSigned. This replaces the concatenation of authenticatorData and clientDataHash. attToBeSigned is hashed using an algorithm specified by the attestation format.
• The authData field is unused and SHOULD be omitted.

A Client responds with the response object containing the WebAuthn attestation object in the "attObj" field to acknowledge that the challenge can be validated by the Server. On receiving a response, the Server constructs and stores the key authorization from the challenge's "token" value and the current Client account key. To validate a device attestation challenge, the Server performs the following steps:

1. Perform the verification procedures described in Section 6 of .
2. Verify that key authorization conveyed by attToBeSigned matches the key authorization stored by the Server.

The webauthn payload MAY contain any identifiers registered in "WebAuthn Attestation Statement Format Identifiers" and any extensions registered in "WebAuthn Extension Identifiers" , .

Operational Considerations Although this document focuses guidance on implementing new type and challenge for certificate issuance using ACME, it does not define a New Protocol, a Protocol Extension, or an architecture.

Enterprise PKI ACME was originally envisioned for issuing certificates in the Web PKI, however this extension will primarily be useful in enterprise PKI. The subsection below covers some operational considerations for an ACME-based enterprise CA.

External Account Binding An enterprise CA likely only wants to receive requests from authorized devices. It is RECOMMENDED that the Server require a value for the "externalAccountBinding" field to be present in "newAccount" requests. If an enterprise CA desires to limit the number of certificates that can be requested with a given account, including limiting an account to a single certificate. After the desired number of certificates have been issued to an account, the Server MAY revoke the account as described in Section 7.1.2 of .

Security Considerations Please reference for other security considerations. See Section 13 of for additional security considerations related to attestation statement formats, including certificate revocation. Key attestation statements may include a variety of information in addition to the public key being attested. While not described in this document, the Server MAY 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. The "token" value MUST have at least 128 bits of entropy. It MUST NOT contain any characters outside the base64url alphabet, including padding characters ("="). See , Appendix C.1 for additional information on randomness requirements.

IANA Considerations

ACME Identifier Types The "ACME Identifier Types" registry is to be updated to include the following entries:

Label	Reference
permanent-identifier	RFC XXXX
hardware-module	RFC XXXX

ACME Validation Method The "ACME Validation Methods" registry is to be updated to include the following entry:

Label	Identifier Type	ACME	Reference
device-attest-01	permanent-identifier	Y	RFC XXXX

New Error Types This document adds the following entries to the ACME Error Type registry:

Type	Description	Reference
badAttestationStatement	The attestation statement is unacceptable (e.g. not signed by an attestation authority trusted by the CA)	RFC XXXX

References Normative References This document describes the use of the Cryptographic Message Syntax (CMS) to protect firmware packages, which provide object code for one or more hardware module components. CMS is specified in RFC 3852. A digital signature is used to protect the firmware package from undetected modification and to provide data origin authentication. Encryption is optionally used to protect the firmware package from disclosure, and compression is optionally used to reduce the size of the protected firmware package. A firmware package loading receipt can optionally be generated to acknowledge the successful loading of a firmware package. Similarly, a firmware package load error report can optionally be generated to convey the failure to load a firmware package. [STANDARDS-TRACK] This document defines a new form of name, called permanent identifier, that may be included in the subjectAltName extension of a public key certificate issued to an entity. The permanent identifier is an optional feature that may be used by a CA to indicate that two or more certificates relate to the same entity, even if they contain different subject name (DNs) or different names in the subjectAltName extension, or if the name or the affiliation of that entity stored in the subject or another name form in the subjectAltName extension has changed. The subject name, carried in the subject field, is only unique for each subject entity certified by the one CA as defined by the issuer name field. However, the new name form can carry a name that is unique for each subject entity certified by a CA. [STANDARDS-TRACK] Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. This specification defines IANA registries for W3C Web Authentication (WebAuthn) attestation statement format identifiers and extension identifiers. Independent This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies new requirements for TLS 1.2 implementations. Google Mozilla Microsoft Microsoft Yubico 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. Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] Informative References n.d.

Acknowledgments We thank the participants on the ACME Working Group mailing list for their insightful feedback and comments. In particular, the authors extend sincere appreciation to Mike Ounsworth, Deb Cooley, Aaron Gable, Richard Barnes, and Herman Slatman for their reviews and suggestions, which greatly improved the quality of this document.