IETF K. Moriarty
Internet-Draft Dell EMC
Intended status: Standards Track May 30, 2019
Expires: December 1, 2019

ACME End User Client and Code Signing Certificates
draft-moriarty-acme-client-01

Abstract

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 end user client, device client, and code signing certificates.

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 December 1, 2019.

Copyright Notice

Copyright (c) 2019 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Introduction

ACME [RFC8555] 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 and Code SIgning may also benefit from automated management to ease the deployment and maintenance of these certificates type, thus the definition of this extension defining challenge types specific to that usage.

2. Identity Proofing for Client Certificates

As with the TLS certificates defined in the core ACME document, identity proofing for ACME issued end user client, device client, and code signing certificates was not covered in RFC8555.

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 follows from NIST SP 800-63 r3:

"IAL1: There is no requirement to link the applicant to a specific real-life identity. Any attributes provided in conjunction with the authentication process are self-asserted or should be treated as such (including attributes a Credential Service Provider, or CSP, asserts to an RP).

IAL2: Evidence supports the real-world existence of the claimed identity and verifies that the applicant is appropriately associated with this real-world identity. IAL2 introduces the need for either remote or physically-present identity proofing. Attributes can be asserted by CSPs to RPs in support of pseudonymous identity with verified attributes.

IAL3: Physical presence is required for identity proofing. Identifying attributes must be verified by an authorized and trained representative of the CSP. As with IAL2, attributes can be asserted by CSPs to RPs in support of pseudonymous identity with verified attributes."

The certificate issuing CA may make this choice by certificate type issued. 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 has the following recommendations for authentication or in the context of ACME, management of issuance for subsequent client, device, or code-signing certificates:

"For services in which return visits are applicable, a successful authentication provides reasonable risk-based assurances that the subscriber accessing the service today is the same as that which accessed the service previously. The robustness of this confidence is described by an AAL categorization. NIST SP 800-63 B addresses how an individual can securely authenticate to a CSP to access a digital service or set of digital services. SP 800-63B contains both normative and informative material.

The three AALs define the subsets of options agencies can select based on their risk profile and the potential harm caused by an attacker taking control of an authenticator and accessing agencies? systems. The AALs are as follows:

AAL1: AAL1 provides some assurance that the claimant controls an authenticator bound to the subscriber's account. AAL1 requires either single-factor or multi-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove possession and control of the authenticator through a secure authentication protocol.

AAL2: AAL2 provides high confidence that the claimant controls authenticator(s) bound to the subscriber's account. Proof of possession and control of two distinct authentication factors is required through secure authentication protocol(s). Approved cryptographic techniques are required at AAL2 and above.

AAL3: AAL3 provides very high confidence that the claimant controls authenticator(s) bound to the subscriber's account. Authentication at AAL3 is based on proof of possession of a key through a cryptographic protocol. AAL3 authentication SHALL use a hardware-based authenticator and an authenticator that provides verifier impersonation resistance; the same device MAY fulfill both these requirements. In order to authenticate at AAL3, claimants SHALL prove possession and control of two distinct authentication factors through secure authentication protocol(s). Approved cryptographic techniques are required."

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

3. Device Certificates

A device certificate is a client certificate issued to a device identified through device credentials such as an IP address, hostname, or MAC address. This process is separate from an end user client certificate that may be stored on a device, but identifies a person using the device described in the next subsection. While there are automated processes in place today for device certificate renewal, most are specific to the CA and not open standards. The general workflow is similar to that described in RFC8555 with the differences being in the CSR, requesting a client certificate. [IP addresses may be necessary for some devices and it may be best to extend [I-D.ietf-acme-ip] to cover varying CSR types that include client certificates for devices explicitly.]

A typical process to obtain a device certificate may be similar to the following workflow described in the introduction of RFC8555 with the exception of certificate type and usage.

[There is some work happening in possibly 2 different drafts on device certificates, so no further definition is provided here at this time.]

[Is an additional type definition helpful to distinguish that this is for a client certificate?]

4. End User Client Certificates

A client certificate used to authenticate an end user may be used for mutual authentication in TLS, EAP-TLS, or messaging. The client certificate in this case may be stored in a browser, PKCS-#11 container, KMIP, or another key container. To obtain an end user client certificate, there are several possibilities to automate authentication of an identity credential presumably tied to an end user.

[We need to determine if it is important in ACME to define an automated method that tests the identity or the user or to just have consistent credentials for the authentication challenges. The credentials may be distributed through an out-of-band method that involves identity proofing.]

[Several authentication options with identity proofing are intentionally provided for review and discussion by the ACME working group.]

A trusted federated service that ties the user to an email address with a reputation of the user attached to the email may be possible. One such example might be the use of a JWT signed OAuth token.

Risk based authentication used for identity proofing with red herring questions is a third option that could utilize public information on individuals to authenticate. This would be similar to the signup process used in some financial applications.

Existing credentials - for instance, FIDO. FIDO uses a public key pair and does not perform identity proofing. FIDO authentication provides a different key pair to each service using FIDO for authentication, which are generated at the client and registered by the server. This may require using the FIDO credentials from a specific service for authentication to gain ACME issued crededentials (not advised based on how FIDO credentials are supposed to be used). Are there instances where the same provider would issue both sets of credentials? You wouldn't want to expose your FIDO credentials to a different party, that's why each service has their own. Would you set up a mechanism to get FIDO credentials to then obtain a certificate? (What use cases would this be necessary? When do you need a certificate where you already have a specific public/private key pair?) This can be defined as an auth type, but should it be?

One-time password (OTP) authentication is a secure option. 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.

One consideration is to understand if the use case could just use FIDO and not create anything new (ACME client certificates). FIDO provides 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 it's 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. However, is automated identity proofing important for any user certificate or should it remain decoupled where it could be automated by a service offering or is there a need for a standardized mechanism to support it for user certificates?

Three methods for ACME client authentication, not identity proofing, are proposed in the Challenge Type Section.

5. CodeSigning Certificates

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 similar 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.

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 typically requires 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 for 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 accessible replaced with ACME authenticated client access with extra challenges for authentication may be an option to automate the functionality.

[For standard certificates, is it worth defining SMS and email for the challenge? Obviously, EV needs more, so a few choices are suggested in this revision.]

To improve the vetting process, ACME's optional use of CAA [RFC6844] with the Directory "meta" data "caaIdentities" ([RFC8555] 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.

CAA helps as anyone verifying a certificate used for code signing can verify that the CA used has been authorized to issue certificates for that organization. CSR requests for code signing certificates typically contain a Common Name (CN) using a domain name that is replaced with the organization name to have the expected details displayed in the resulting certificate. Since this work flow already occurs, there is a path to automation and validation via an existing ACME type, "dns".

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, [RFC8555] Section 7.1.5 is RECOMMENDED for use for Pre-authorization ([RFC8555] 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-Authoriziation.

Questions for reviewers:

[Is there interest to set a specific or default challenge object for CodeSigning Certificates? Or should this be left to individual CAs to decide and differentiate? The current challenge types defined in RFC8555 include HTTPS (provisioning HTTP resources) and DNS (provisioning a TXT resource record). Use of DNS may be possible, but the HTTP resource doesn't necessarily make sense. Since the process to retrieve an EV CodeSigning certificate usually requires proof of the organization and validation from one of 2 named administrators, some other challenge type like public/private key pairs or OTP may be needed as defined challenge types. An organization may want to tie this contact to a role rather than a person and that consideration should be made in the design as well as implementation by organizations.]

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. 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. Additional types may be added if agreed upon by the working group.

Since DNS is used to identify the organization in the request, the identifier "type" ([RFC8555]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 or two, but automation could allow for shorter expiry times becoming feasible.

Automation of storage to an HSM, which typically requires authentication is intentionally left out-of-scope.

6. Pre-authorization

Additional challenge types are defined here for the verification of administrors at an organization requesting CodeSigning certificates. SMS and email are both defined 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.

7. Challenge Types

The challenge types are defined in the following subsections are for use 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 challenges with certificate types such as the Code Signing Certificate. 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.

7.1. One Time Password (OTP)

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 accomodate 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 reponse to be provided in the URL, the token can supply the challenge.

   {
     "type": "otp-01",
     "url": "https://example.com/acme/chall/WrV_H87EyD3",
     "status": "pending",
     "token": "challenge"
   }
    

7.2. Certificate

Certificates may be pre-issued and stored according to assurance level requirements for the purpose of identiying 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 posisble for identity proofing to occur in person using identifiers acceptable for the specified process and then 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": "cert-01",
     "url": "https://example.com/acme/chall/WrV_H87EyD3",
     "status": "pending",
     "token": "Some challenge to digitally sign"
   }
    

7.3. FIDO or Public/Private Key Pairs

FIDO uses public/private key pairs that are issued specific to a service. If FIDO 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 FIDO 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 FIDO regisration of credentials. As with normal FIDO and puiblic/private key pairs, the token or challenge is digitally signed to prove possession of the private key.

   {
     "type": "ppkp-01",
     "url": "https://example.com/acme/chall/WrV_H87EyD3",
     "status": "pending",
     "token": "Some challenge to sign"
   }
    

8. Security Considerations

This will likely be full of considerations and is TBD for this revision until challenge types are settled.

9. IANA Considerations

This memo includes no request to IANA, yet.

10. Contributors

11. References

11.1. 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.
[RFC7030] Pritikin, M., Yee, P. and D. Harkins, "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D. and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019.

11.2. Informative References

[I-D.ietf-acme-ip] Shoemaker, R., "ACME IP Identifier Validation Extension", Internet-Draft draft-ietf-acme-ip-06, May 2019.

11.3. URL References

[NIST800-63A] US National Institute of Standards and Technology, "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63a.pdf"
[NIST800-63B] US National Institute of Standards and Technology, "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf"
[NIST800-63C] US National Institute of Standards and Technology, "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63c.pdf"
[NIST800-63r3] US National Institute of Standards and Technology, "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-3.pdf"

Appendix A. Change Log

Note to RFC Editor: if this document does not obsolete an existing RFC, please remove this appendix before publication as an RFC.

Appendix B. Open Issues

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

Author's Address

Kathleen M. Moriarty Dell EMC 176 South Street Hopkinton, US EMail: Kathleen.Moriarty@dell.com