]> Google

bweeks@google.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 if 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

Using ACME and device attestation to issue client certificates for enterprise PKI is anticipated to be the most 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.

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. The name of this identifier type was chosen to align with , it does not prescribe the lifetime of the identifier, which is at the discretion of the Assigner Authority. The identity along with the assigning organization can be included in the Subject Alternate Name Extension using the PermanentIdentifier form described in . The server MAY allow the client to include this identifier in the certificate signing request (CSR). Alternatively if the server wishes to only 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 cryptoprocessor, if any, that generated the certificate key. (TODO describe the certificate representation) If the server includes HardwareModule in the subjectAltName extension the CA MUST verify that the certificate key was generated on the secure cryptoprocessor with the asserted identity and type. The key MUST NOT be able to be exported from the cryptoprocessor. If the server wishes to issue privacy-preserving certificates, it MAY omit HardwareModule from 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. This value MUST have at least 128 bits of entropy. It MUST NOT contain any characters outside the base64url alphabet, including padding characters ("="). See for additional information on randomness requirements.

A client fulfills this challenge by constructing a key authorization ( Section 8.1) from the "token" value provided in the challenge and the client's account key. The client then generates an 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 with these modification:

• 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 "token" value and the current client account key. To validate a device attestation challenge, the server performs the following steps:

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

Security Considerations TODO Security

IANA Considerations

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

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	Reference
device-attest-01	permanent-identifier	RFC XXXX

Normative References 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. 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. Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

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 .

Acknowledgments TODO acknowledge.