]> SecurityBiaS

Arlington US Kathleen.Moriarty.ietf@gmail.com

Security IETF ACME Certificate Client CodeSigning Automated Certificate Management Environment (ACME) core protocol addresses the use case of web server certificates for TLS. This document extends the ACME protocol to support service account authentication credentials, micro-service accounts credentials, device client, code signing, document signing certificates and keys.

ACME is a mechanism for automating certificate management on the Internet. It enables administrative entities to prove effective control over resources like domain names, and automates the process of generating and issuing certificates. The core ACME protocol defined challenge types specific to web server certificates with the possibility to create extensions, or additional challenge types for other use cases and certificate types. Client certificates, such as end user, digital signature, and service authentication also benefit from automated management to ease the deployment and maintenance of these certificate types, thus the definition of this extension defining challenge types for end users and service accounts (e.g. cloud native containers, microservices). Use cases for digital signatures are increasingly becoming foundational for integrity protection, origin authentication and data provenance including the following that may benefit from automating the certificate and key management for functions such as code signing, document signing (e.g. PDF), and format signing (e.g. JWT, SPDX, XML).

As with the TLS certificates defined in the core ACME document <xref target="RFC8555"/>, identity proofing for ACME issued end user client, device client, service accounts, code signing certificates, and document signing certificates is a separate process outside of the automation of ACME. Identity proofing may be an out-of-band process, if needed, and for this draft is likely tied to the credentials used for the defined challenge types. Identity proofing for these certificate types present some challenges for process automation. NIST SP 800-63 r3 serves as guidance for identity proofing further detailed in NIST SP 800-63A that may occur prior to the ability to automate certificate management via ACME or may obviate the need for it weighing end user privacy as a higher concern and allowing for credential issuance to be decoupled from identity proofing (IAL1). Using this guidance, a CA might select from the identity proofing levels to assert claims on the issued certificates as described in NIST SP 800-63 r3. The certificate issuing CA may make this choice by certificate type issued or by some other policy decision point. Once identity proofing has been performed, in cases where this is part of the process, and certificates have been issued, NIST SP 800-63 r3 includes recommendations for authentication or in the context of ACME, management of issuance for subsequent client, device, document, or code-signing certificates: If federations and assertions are used for authorizing certificate issuance, NIST SP 800-63 C may be referenced for guidance on levels of assurance. Existing PKI certification authorities (CAs) tend to use a set of ad hoc protocols for certificate issuance and identity verification, specific to the CA provider and aligned to requirements for the certificate type and level. For each certificate usage type, a basic process will be described to obtain an initial certificate and for the certificate renewal process. If higher assurance levels are desired, the guidance from NIST SP 800-63 r3 may be useful and out-of-band identity proofing options are possible options for pre-authorization challenges or notifications.

A client certificate used to authenticate an end user may be used for mutual authentication in TLS, EAP-TLS, or messaging. The client certificate and key in this case may be stored in a browser, PKCS-#11 container, Key Management Interoperability Protocol (KMIP), or another key store. To obtain an end user client or microservice or container certificate and associated key pair, there are several possibilities to automate authentication of an identity credential intended to be tied to an end user, device, service, application, or container. This draft adds challenge types to ACME for this purpose and includes: o Public Key Infrastructure, x.509, o FIDO Credentials/WebAuthn/Passkeys, and o One Time Passwords Existing credentials, for instance, FIDO or W3C WebAuthn may be used to automate the challenge required to obtain a certificate and key pair through ACME for use cases such as client certificates, code signing certificates, document signing certificates, and interactions between microservices in cloud native environments. User interaction may be required when these credentials are used to respond to a challenge and that requirement may be appropriate for the certificate type requested, yet still easing the certificate management burden. FIDO uses a public and private key pair and does not perform identity proofing, identity proofing is a separate function and its requirement depends on the application and policy. FIDO authentication provides a different key pair to each authenticating entity and service pair using FIDO for authentication, which are generated at the client and registered by the server. This may require using the FIDO or WebAuthn credentials from a specific service for authentication to gain ACME issued certificates and keys. The key pairs for FIDO, WebAuthn, or Passkeys may be stored in a system-based or hardware-based (e.g. FIDO approved hardware token, hardware security module) key store. One-time password (OTP) authentication is also an option providing multiple factors of authentication, designed with a human entering the OTP code manually. In cases where a higher assurance level is needed, OTP may be a good choice and many options exist today for OTP that could use an app on a phone for instance tied to an existing (or newly established) password. The OTP may be tied to an out-of-band process and may be associated with a username/password and other accounts. It is possible that the OTP response is automated, but that eliminates the second factor if two-factor authentication was desired. PKI may be fully automated to serve as the credential type in the challenge response for ACME. One consideration is to understand if the use case could use FIDO credentials, WebAuthn, or Passkeys directly and not require an additional or new set of PKI keys for the service or end user authentication, meaning ACME client certificates and keys. FIDO Credentials provide a mechanism to have unique public key pair based access for client authentication to web sites and they are working on non-web. Identity proofing is intentionally decoupled from authentication in this model as that is in line with NIST 800-63r3 recommendations for privacy protections of the user. The credential in this case is authenticated and would be consistent for its use, but the identity proofing for that credential is not performed. Obviously, identity proofing is more important for some services, like financial applications where tying the user to the identity for access to financial information is important. It is important to keep in mind that the challenge types defined may be used to have a human in the loop in order to establish PKI certificate and key pairs that may then be used for automated authentication. The issued certificate and key pairs can be stored in system based key stores or external hardware based key stores using PKCS 11. Three methods for ACME client authentication, not identity proofing, are proposed in the Challenge Type Section.

The process to retrieve a code signing certificate is similar to that of a web server certificate, with differences primarily in the CSR request and the resulting certificate properties. [The storage and access of a code signing certificate must be protected and is typically done through hardware, a hardware security module (HSM), which likely has a PKCS#11 interface. A code signing certificate may either be a standard one or an extended validation (EV) certificate.] For automation purposes, the process described in this document will follow the standard process and any out-of-band preprocessing can increase the level of the issued certificate if the CA offers such options and has additional identity proofing mechanisms (in-band or out-of-band). Strict vetting processes are necessary for many code signing certificates to provide a high assurance on the signer. In some cases, issuance of a standard CodeSigning certificate will be appropriate and no additional "challenges" [RFC8555 Section 8] will be necessary. In this case, the standard option could be automated very similarly to web server certificates with the only changes being in the CSR properties. However, this may not apply to all scenarios, such as those requiring EV certificates with the possibility for required out-of-band initial authentication and identity proofing. EV code signing certificates have a distinct set of requirements from EV web certificates. In particular, they don't have associated domain names, nor is CAA checking done. The code signing certificate links a public key to an organization, not a domain. CAs may choose different methods to enable the use of ACME for EV code signing certificates. The intent of this work is to provide additional authentication challenge types that may enable their automation process. Organization validation is required for standard code signing certificates from most issuers. The CSR is used to identify the organization from the included domain name in the request. The resulting certificate, however, instead contains the organization's name and for EV certificates, other identifying information for the organization. For EV certificates, this could require that the domain is registered with the Certificate Authority provider, listed in CAA [RFC6844], and administrators for the account are named with provided portal access for certificate issuance and management options. While ACME allows the client to directly establish an account with a CA, an initial out-of-band process for this step may assist with the additional requirements for EV certificates and assurance levels typically required for code signing certificates. For standard certificates, with a recommendation for additional vetting through extended challenge options to enable ACME to establish the account directly. In cases where code signing certificates are used heavily for an organization, having the portal access replaced with ACME authenticated client access with extra challenges for authentication may be an option to automate the functionality. To improve the vetting process, ACME's optional use of CAA [RFC6844] with the Directory "meta" data "caaIdentities" ( Section 9.7.6) assists with the validation that a CA may have issue certificates for any particular domain and is RECOMMENDED for use with code signing certificates for this additional level of validation checking on issued certificates. As noted in RFC8555, "the external account binding feature (see Section 7.3.4) can allow an ACME account to use authorizations that have been granted to an external, non-ACME account. This allows ACME to address issuance scenarios that cannot yet be fully automated, such as the issuance of "Extended Validation" certificates." The ACME challenge object, Section 7.1.5 is RECOMMENDED for use for Pre-authorization ( Section 7.4.1). Additional challenge types are added to provide higher levels of security for this issuance verification step. The use of OTP, FIDO credentials (public/private key pairs), or validation from a certificate issued at account setup time are defined in Section 8. Pre-Authorization. ACME provides an option for notification of the operator via email or SMS upon issuance/renewal of a certificate after the domain has been validated as owned by the requestor. This option is RECOMMENDED due to the security considerations of code signing certificates as a way to limit or reduce the possibility of a third-party gaining access to a code signing certificate inappropriately. The development of additional challenge types is included in this document to support this for pre-authorization, which would better match the security considerations for this certificate type. Since DNS is used to identify the organization in the request, the identifier "type" (Section 7.4) is set to dns, not requiring any additions to the ACME protocol for this type of certificate. The distinction lies in the CSR, where the values are set to request a CodeSigning certificate for a client certificate. [Question: Is it helpful to define an identifier for the administrator or for the developer to distinguish the certificate type in ACME and not just the CSR?] KeyUsage (DigitalSignature) and ExtendedKeyUsage (CodeSigning) in the CSR MUST be set to the correct values for the CA to see the request is for a Code Signing certificate. The Enhanced Key Usage SHOULD be set to show this is a client certificate, using OID "1.3.6.1.5.5.7.3.2". The CN MUST be set to the expected registered domain with the CA account. An advantage of ACME is the ability to automate rollover to allow for easy management of short expiry times on certificates. The lifetime of CodeSigning certificates is typically a year, and automation could allow for shorter expiry times becoming feasible. However, lifetimes are less of an issue for code signing certificates than other certificate types. However, there is a legitimate case for "one signature per certificate." Automation might be helpful in this case if patches or software updates were frequent or to minimize the knowledge needed for the organization using this method. Automation of storage to a hardware security module (HSM), which typically requires authentication is intentionally left out-of-scope since standards exist for key storage and this document is limited to adding new challenge types.

The challenge type may also be used to obtain a document signing certificate. The CSR must be configured with the correct information to obtain this certificate type. KeyUsage (DigitalSignature) and ExtendedKeyUsage (DocumentSigning) in the CSR MUST be set to the correct values for the CA to see the request is for a Document Signing certificate. The Enhanced Key Usage SHOULD be set to show this is a client certificate, using OID "1.3.6.1.5.5.7.3.36". The CN MUST be set to the expected registered domain with the CA account.

For service accounts, including microservices, it may be desirable to establish PKI based certificate and key pairs for use to perform the automated authentication functions necessary. As such, a challenge type paired with ACME can be supported to request the appropriate certificate type by defining the characteristics required in the CSR to be presented to the CA. The challenge type may be completely automated as in the TLS server use case or may require user interaction with the defined challenge types in this document. The challenge types could be used as the challenge to obtain certificates of a defined lifetime, with a certificate update process following the same requirements or presentation of a challenge type that can be fully automated. The CSR must be set to the appropriate values in order to obtain the desired certificate type and key pairs for use with the service, server, application, or microservice. ACME can be used for issuance of any of the possible certificate and key types by setting the CST values appropriately for the use case. KeyUsage (DigitalSignature) and ExtendedKeyUsage (serverAuth) in the CSR MUST be set to the correct values for the CA to see the request is for a server authentication certificate and associated key pair. The Enhanced Key Usage SHOULD be set to show this is a server certificate, using OID "1.3.6.1.5.5.7.3.1". The CN MUST be set to the expected registered domain with the CA account. If other properties are necessary for a particular use case, the challenge types defined in this document may be used in combination with the values asserted in the CSR to obtain the correct certificate type if supported by the certificate authority and its policies.

Additional challenge types are defined here for the verification of administrators at an organization requesting certificates with the extended key usage (EKU) for CodeSigning or Document Signing. Email is listed as possible in RFC8555 and may be used singularly or in combination as the ACME protocol allows for multiple pre-authorization challenges to be issued. Additional pre-authorization types are defined that provide a higher level of assurance to authorize a request.

The challenge types defined in the following subsections are to authenticate individuals or holders of specific pre-issued credentials (users acting in roles for an organization). The challenge types can be used to obtain end user certificate types or as a pre-authorization challenge with certificate types such as digital signature with the EKU set for code signing or document signing. Please note that the pre-authorization challenge is also coupled with the account certificate in ACME for verification. The process for obtaining EV Code Signing Certificates typically requires authorization from one or more individuals in a role for the organization. The use of pre-issued secure credentials, at an assurance level appropriate for the certificate type being issued, provides a way to automate the issuance and renewal process.

There are numerous one-time password technologies with slight variations between implementations. The response to the challenge is entered in the provided URL, offering flexibility to those using this challenge type to accommodate the specific requirements of their solution. Looking at 2 OTP solutions, the challenge response is provided via a tool or app without any user interaction of information required from the server to generate the challenge. The 2 solutions that operate in this manner include SecureID and Duo Security. If a challenge is required to generate the response to be provided in the URL, the token can supply the challenge. type (required, string): The string "otp-01". token (required, string): A random value that uniquely identifies the challenge. OTP types and input vary between technologies. The token value will match the type expected for the pre-issued OTP credential. The user will be able to supply a response in the provided URL from this challenge. It MUST NOT contain any characters outside the base64url alphabet and MUST NOT include base64 padding characters ("=").

HOTP() describes an algorithm for the generation of time-based password values. type (required, string): The string "hotp-01". token (required, string): The HOTP value. This SHOULD be the 6 digit representation.

TOTP() describes an algorithm for the generation of time-based password values, an extension from HOTP. type (required, string): The string "totp-01". token (required, string): The TOTP value. This SHOULD be the 6 digit representation.

There are numerous other one-time password technologies with slight variations between implementations. The response to the challenge is entered in the provided URL, offering flexibility to those using this challenge type to accommodate the specific requirements of their solution. Looking at 2 OTP solutions, the challenge response is provided via a tool or app without any user interaction of information required from the server to generate the challenge. The 2 solutions that operate in this manner include SecureID and Duo Security. If a challenge is required to generate the response to be provided in the URL, the token can supply the challenge. type (required, string): The string "otp-01". token (required, string): A random value that uniquely identifies the challenge. OTP types and input vary between technologies. The token value will match the type expected for the pre-issued OTP credential. The user will be able to supply a response in the provided URL from this challenge. It MUST NOT contain any characters outside the base64url alphabet and MUST NOT include base64 padding characters ("=").

Certificates may be pre-issued and stored according to assurance level requirements for the purpose of identifying a user's identity. If a higher assurance level is needed for a user serving in a specific role or for that individual, it is possible for identity proofing to occur in person using identifiers acceptable for the specified process and the private key stored appropriately for the required assurance level. PKCS#11 software or hardware tokens are both possible options. This model assumes that there may be multiple authorized users with different certificates that can be used for the authorization or pre-authentication challenge. As such, the user first provides the digital signature, so the account management can determine if one of the acceptable certificates was used to digitally sign the token. type (required, string): The string "cert-01". token (required, string): A random value that uniquely identifies the challenge. The token for a certificate authentication challenge includes a value for the recipient to digitally sign using their private key and post to the provided URL. The ACME server then uses the digitally signed content to verify that the challenge was signed using authorized credentials (certificate issued and authorized for this challenge type). It MUST NOT contain any characters outside the base64url alphabet and MUST NOT include base64 padding characters ("=").

W3C's WebAuthn/Passkeys use raw public/private key pairs that are issued specific to a service. If WebAuthn or public/private key pairs (PPKP) are selected as the challenge type, the account and credential issuance will have to occur prior to use of this challenge type. The WebAuthn or public/private key pair credentials would be specific to the certificate management account and would be created by the client, then registered with the service as occurs with normal WebAuthn registration of credentials. As with normal WebAuthn and public/private key pairs, the token or challenge is digitally signed to prove possession of the private key. Passkeys need to be pre-registered with the ACME service since they are origin bound. type (required, string): The string "ppkp-01". token (required, string): A random value that uniquely identifies the challenge. This challenge will operate much in the same way as the certificate challenge as the operations are largely the same. The user will be able to supply a response in the provided URL from this challenge. It MUST NOT contain any characters outside the base64url alphabet and MUST NOT include base64 padding characters ("=").

The additional challenge types may be used for any certificate type as ACME's design allows for that flexibility. Careful consideration is recommended when selecting the appropriate challenge types for certificate and key pairs. In the case of code signing certificate and key pairs, policy for an issuing organization may require processes involving challenges to more than one person in the organization with specific challenge types required. The challenge type may be tied back to specific authentication levels, for instance the authentication levels defined in NIST SP 800-63. The authentication process may also be tied to roles in the organization as opposed to individuals. Policy and application of policy are outside the scope of this document. Policy considerations for microservices accounts and other automated service accounts may include the required authentication level to be used for the initial challenge type. The policy should also consider what is acceptable for subsequent key renewal and if automation is possible with other PKI or WebAuthn keys for instance. The security levels of the service may dictate the appropriate and required authentication levels for both the initial challenge type and the subsequent challenge types for renewals in advance of certificate and key pair expiration dates.

This memo includes no request to IANA, yet.

Thank you to reviewers and contributors who helped to improve this document. Thank you to Thomas Peterson who added the one-time password types, HOTP and TOTP. Thank you to Tim Hollebeek for your early review and added text specific to EV certificate issuance and one time use code signing certificates. Thank you to Andrei Popov and Deb Cooley for your reviews and suggestions made in -04. Thank you to those who reviewed the CAA text removed in version -05 including: Carl Mehner, Roland Shoemaker, Ben Schwartz, and Ryan Sleevi. Posted WG version. -02 updates authors email address. Updates included in version 11 correspond to comments on list from Dean Saxe and Richard Wang.

US National Institute of Standards and Technology US National Institute of Standards and Technology US National Institute of Standards and Technology US National Institute of Standards and Technology

Note to RFC Editor: if this document does not obsolete an existing RFC, please remove this appendix before publication as an RFC. 02 draft added subsections contributed from Thomas Peterson on HOTP and TOTP.

Note to RFC Editor: please remove this appendix before publication as an RFC.