Automated Certificate Management Environment (ACME) Extension for Public Key Challenges
draft-geng-acme-public-key-00

Automated Certificate Management Environment Working Group       F. Geng
Internet-Draft                                                     P. Wu
Intended status: Standards Track                                  L. Xia
Expires: 12 April 2025                               Huawei Technologies
                                                          9 October 2024

Automated Certificate Management Environment (ACME) Extension for Public
                             Key Challenges
                     draft-geng-acme-public-key-00

Abstract

   This document specifies an extension to the ACME protocol [RFC8555]
   that enables ACME servers to use the public key authentication
   protocol to verify that the client has control of the private key
   corresponding to the public key.  This document also defines several
   application methods for binding identity information to public keys.

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 12 April 2025.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Geng, et al.              Expires 12 April 2025                 [Page 1]
Internet-Draft              ACME PK Challenge               October 2024

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   3
   3.  ACME pk Identifier Type . . . . . . . . . . . . . . . . . . .   5
   4.  ACME pk-01 Challenge Type . . . . . . . . . . . . . . . . . .   6
   5.  Public Key Authentication & Order Fulfillment . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  8.1 ACME Identifier Types . . . . . . . . . . . . . . . .   9
     7.2.  8.2 ACME Validation Method  . . . . . . . . . . . . . . .   9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   More and more applications use end-to-end encryption to protect the
   communication process, in which X.509 certificates play an important
   role.  ACME helps to promote and popularize the certificate.  In the
   automatic application process for certificates, the public key of the
   submitted certificate signing request (CSR) is not checked in the
   finalized order request to see if it belongs to the applying user.
   The public key replacement attack may exist for this.

   Normally a user has a client for automated applications.  And in some
   specific application scenarios, some users who expect to obtain
   certificates and allow continuous updates cannot integrate such a
   client.  Such a user might use a proxy as a unified entry point for
   automated certificate requests.  This proxy might be a system or an
   administrator.

   In environments where proxies are used, which are usually relatively
   safe, there are also risks with very low probability.  Based on the
   standard ACME automated certificate request process, the ACME server
   can communicate with the user and prove the validity of the user's
   identity through the use of proxies.  However, in this scenario, on
   the one hand, users may inevitably need to grant their own identity

Geng, et al.              Expires 12 April 2025                 [Page 2]
Internet-Draft              ACME PK Challenge               October 2024

   proofing privileges to intermediate proxies, e.g., they need proxies
   to complete DNS records; on the other hand, at the final submission
   of the CSR, the proxy may substitute the final CSR and apply for a
   mismatched certificate.

   Similarly, in other non-proxy scenarios it is possible for an
   applicant to obtain the CSR of another users, thus obtaining the
   corresponding certificate of the others, resulting in a security
   risk.

   This specification introduces a new ACME challenge type to allow the
   identity of a user to be verified by means of public key (PK)
   authentication.  In this process it can be ensured that the public
   key of the application request is consistent with the public key in
   the final submitted CSR, eliminating the security risk of public key
   replacement in the certificate application.

   The protocol interaction process is based on the ACME standardized
   process.  The client only needs to know how to initiate the public
   key authentication protocol by opening a given URL, and then
   recognize when that interaction has ended.  Once finished, the ACME
   client can query the status of the challenge to the ACME server to
   determine if the challenge was successful and, if so, to complete the
   standard ACME awarding process.  The entire process of applying for a
   certificate conforms to the ACME standardized process.

   Note that this specification requires an Identity Provider (IDP) that
   records public keys.  The IDP is the trust center for the automated
   certificate request process, which stores the trusted user's public
   key and possibly the identity information corresponding to the public
   key.  Specific identity information can be selected based on the
   actual operations.  Before the certificate request process, the
   user's public key should have been entered into the IDP in some way,
   such as self-registration by the user or LDAP-based import.

2.  Protocol Overview

   The general process of the PK challenge is illustrated by the
   standard ACME certificate issuance sequence.  First the client needs
   to submit a certificate request, which carries the public key
   information at the start.  The server responds to the client that it
   must satisfy authentication.  The client can select one of its
   supported authentication methods from a variety of authentication
   methods and inform the server.  The server returns what needs to be
   accomplished for this authentication method.  This content will
   contain the “start URL”. This authentication method is similar to
   that of single sign-on (SSO) [draft-biggs-acme-sso-01], except that
   the IDP here must contain the user's public key and no longer

Geng, et al.              Expires 12 April 2025                 [Page 3]
Internet-Draft              ACME PK Challenge               October 2024

   requires a passphrase or key information.

   The client performs a request for one of the authentication methods
   and the server responds to it.  Among these may be one or more
   challenge of type pk-01, which can be used to start the process of
   authentication based on the web through different start URL.  The
   request redirects the client to the applicant object and the IDP,
   which conducts a public key authentication protocol with the
   applicant.  After successfully providing validation to the IDP, the
   ACME server logs the associated challenge as validated (or not).

   In the process of authentication, the process of this specification
   is quite different from the way of SSO.  The authentication process
   is primarily authenticated through public key authentication
   protocols (e.g. aPAKE/Opaque [I-D.irtf-cfrg-opaque]).  The IDP here
   also needs to support the appropriate public key authentication
   protocols.

   Then the redirection to the client indicates that the authentication
   process has been completed, at which point it can be demonstrated
   that the client has the private key corresponding to the public key
   in the application order.  The user's private key information is
   always private in this process and does not need to be provided to
   the agent, only part of the computation is done.  After completing
   the authentication, it redirects the client to the certificate
   request process.

   Figure 1 depicts the overview of the public key challenge flow:

Geng, et al.              Expires 12 April 2025                 [Page 4]
Internet-Draft              ACME PK Challenge               October 2024

Client                                                    ACME Server

~~~~~~~~~~~~~~~~~~~~ ACME client ~~~~~~~~~~~~~~~~~~~~~

request new order              -------->
                              <--------           required authorizations
request authorization           -------->
                              <--------        PK challenge with start URL

~~~~~~~~~~~~~~~~~~~~ Browser ~~~~~~~~~~~~~~~~~~~~~~~~

request on PK start URL         --------->
                             <---------         ACME redirect to provider
                                            authentication request

             provider authenticates client (not shown here)

provider redirect to ACME       --------->
identity assertion
                                          validate provider assertion
                                            record challenge as valid
                             <---------               redirect to client

~~~~~~~~~~~~~~~~~~~~ ACME client ~~~~~~~~~~~~~~~~~~~~~~

request challenge             -------->
                           <---------                          valid
request finalize (CSR)         --------->
                           <---------                    finalize URL
finalize                      -------->
                           <---------                     certificate

             Figure 1: Overview of the PK Challenge Flow

   After completing authentication the client eventually submits the
   CSR.  This specification requires that the public key contained in
   the CSR must match the public key in the starting order.  In this
   way, tampering with public key information can be avoided.  Other
   processes are consistent with the standard process.

3.  ACME pk Identifier Type

   This document defines the pk-01 challenge type that ensures strong
   consistency between the final certificate and the identity of the
   application order even in scenarios where proxies are present.  And
   public key authentication protocol is utilized to provide strong
   security for the authentication process.

Geng, et al.              Expires 12 April 2025                 [Page 5]
Internet-Draft              ACME PK Challenge               October 2024

   The pk-01 challenge type can be applied to a variety of identity
   types that contain public key information. the public key can be used
   directly with no specific identity information.  The identifier pk
   can be used in case of user-bound devices; Csr and selfsign-cert can
   be used in cases where specific identity information needs to be
   bound.  Implementations MUST NOT use the challenge of type pk-01 as
   options to validate a type identifier other than the following:

"identifier": { "type": "pk", "value":"MIGfMA0GC***GbQIDAQAB"}
"identifier": { "type": "selfsign-cert", "value":"MIIHSDCC***AU1GH3xQ="}
"identifier": { "type": "csr", "value":"MIICljCCA***RL64+taHbP"}

4.  ACME pk-01 Challenge Type

   The pk-01 challenge type requires the client to access the specified
   pk-url to start the PK challenge and complete the verification of the
   corresponding private key control of the declared public key.  A
   challenge of this type MUST include all required fields described in
   section 8 of [RFC8555].  In addition, the following fields are
   defined for this specific type of challenge:

   pk_url (required, string): The URL to start the pk challenge type
   process.  The server must include enough information in the URL to
   allow the request to be associated with a specific challenge and to
   be able to point to a specific PK provider or public key server.

   pk_provider (optional, string): The domain of the PK provider relied
   upon for this challenge.  An ACME server MAY rely upon any number of
   PK providers and public key servers, however each MUST be represented
   as a different entry in the challenge array.  The applicant can use
   this field to differentiate the list of providers and select the most
   appropriate one.  If this field does not exist, the ACME server's
   default identity provider is used.  The server MUST NOT present more
   than one pk-01 challenge with the same pk_provider value in a single
   authorization, including values for unprovided fields.

   The server MUST sets the status of the challenge to processing after
   receiving a response from the client within the validity period.  If
   the client completes the proof of ownership of the private key
   corresponding to public key and the generated identity assertion
   validates the declared identifier, then the status of the challenge
   is set to valid.  If the server fails to validate the public key
   against the private key control or fails to validate the declared
   identifier, the status of the challenge will be set to invalid.

Geng, et al.              Expires 12 April 2025                 [Page 6]
Internet-Draft              ACME PK Challenge               October 2024

   {
     “type”: “pk-01”,
     “url”: https://example.org/acme/chall/abc123_defg456,
     “status”: “pending”,
     “pk_url”: “https://example.org/acme/start-pk”,
     “pk_provider”: “https://pk-identity-provider.org/”
   }

5.  Public Key Authentication & Order Fulfillment

   Public key authentication is essentially authenticating the control
   of the corresponding private key of a public key and pk_url allows
   the client to initiate the public key authentication process.  The
   server must accept GET requests for PK URL.  Upon receiving such a
   request:

   1.  The ACME server receives the request and redirects it to the IDP
       server.  IDP instance holds the public key, e.g.  IDP instances
       supporting the aPAKE/Opaque protocols.

   2.  The IDP server requires the requesting party to perform
       authentication to verify that it holds the private key
       corresponding to the public key.  The IDP will include supported
       public key verification protocols in the verification request,
       protocols that include, but are not limited to (1) challenge
       public key signature and verify signature, (2) Opaque/AKE and (3)
       non-interactive zero-knowledge (NIZK) discrete logarithm equality
       (DLEQ) proof, etc.  The client selects one of the protocols to
       perform the authentication process.

   3.  After successfully authenticating the identity, the IDP returns
       the user's information and the logged-in device public key
       information to the ACME server.  When the ACME server receives
       the request, it checks whether the device public key is
       consistent with the public key in the order.  When the ACME
       server receives the request, it MUST check whether the device
       public key is consistent with the public key in the order.  For
       identifiers of type csr and selfsign-cert, identity consistency
       checks are also required.  The challenge is successful if the
       check passes.

Geng, et al.              Expires 12 April 2025                 [Page 7]
Internet-Draft              ACME PK Challenge               October 2024

ACME Server                                Applicant                                       IDP

~~~~~~~~~~~~~~~~~~~~~~~~~provider authenticates client ~~~~~~~~~~~~~~~~~~~~~~~~~~
ACME redirect to provider        ------------------------------------------------->

                                    <-------------      list of supported
                                                        public key authentication protocols
select authentication protocol   ------------->

verification        <-------------------------------------------------    redirect to ACME Server

       Figure 2: Overview of the Public Key Authentication Flow

   When the ACME server receives a response from IDP, it must validate
   it and update the appropriate challenge status.  The server updates
   the challenge status to valid if the provider validation is
   successful, or to invalid if it is unsuccessful.

   In the case of public key verification, the IDP acts as the asserting
   party and conducts a public key authentication agreement with the
   user to obtain public key information and identity information about
   the subject (user).  The ACME server acts as a relying party that
   receives identity information from the IDP.  The ACME server verifies
   the consistency of the public key and the order public key after
   receiving the public key and identity information.  For the
   identifiers of type csr and selfsign-cert, the identity consistency
   needs to be further checked on the basis again.

   As defined in section 7.4 of [RFC8555] once the client has been
   authorized in all respects, it can proceed with the completion of the
   order.  The client SHOULD use the public key declared in the order as
   the public key in the CSR.  If the order identifier type is csr or
   selfsign-cert, the commonName, subjectAltName, etc. fields should be
   filled in the CSR.  Then the CSR, encapsulated as specified, is
   submitted to the ACME server.

   The server needs to validate the order against the identifier after
   receiving a request from the customer to complete the order.  For
   identifiers of pk type, it is necessary to check whether the public
   key recorded in the identifier matches the public key in the CSR.
   For csr or selfsign-cert type identifiers, in addition to this, the
   identity in the order has to be verified against the identity in the
   CSR.  The client's request for order fulfillment can only be
   continued under the condition that all checks have been passed.

Geng, et al.              Expires 12 April 2025                 [Page 8]
Internet-Draft              ACME PK Challenge               October 2024

6.  Security Considerations

   This document is an extension to ACME to provide an additional
   validation method for verifing that the client has control of the
   public key corresponding to the private key.  For general security
   considerations related to the ACME certificate issuance process, see
   [RFC8555].

   As with ACME validation methods, the security of PK validation
   depends on the risk of the validation process being compromised and
   the strength of the binding between the validation process and the
   ACME transaction.

   The binding of the validation process to the ACME transaction is
   managed through a built-in public key validation protocol, where the
   IDP and the requesting party negotiate an validation protocol to
   return identity information to the ACME server.

   As for the security based on PK-based authentication itself, it is
   carried out based on the public key authentication protocol, and
   corresponding risk mitigation measures can be applied.  In PK-based
   certificate issuance, the PK provided is trustworthy enough to assert
   whether a given user has a given identity and public key information.
   A malicious PK provider may falsify these assertions, resulting in
   the issuance of the wrong certificate.  CA's selection of a trusted
   PK provider is one of the initiatives to mitigate this risk.

7.  IANA Considerations

7.1.  8.1 ACME Identifier Types

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

   +----------------+------------------+
   | Label          | Reference        |
   +----------------+------------------+
   | pk             | RFC XXXX         |
   +----------------+------------------+
   | csr            | RFC XXXX         |
   +----------------+------------------+
   | selfsign-cert  | RFC XXXX         |
   +----------------+------------------+

7.2.  8.2 ACME Validation Method

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

Geng, et al.              Expires 12 April 2025                 [Page 9]
Internet-Draft              ACME PK Challenge               October 2024

   +------------+-------------------------+---------+------------+
   | Label      | Identifier Type         | ACME    | Reference  |
   +------------+-------------------------+---------+------------+
   | pk-01      | pk/csr/selfsign-cert    | Y       | RFC XXXX   |
   +------------+-------------------------+---------+------------+

8.  References

8.1.  Normative References

   [RFC8555]  Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
              Kasten, "Automatic Certificate Management Environment
              (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
              <https://www.rfc-editor.org/info/rfc8555>.

8.2.  Informative References

   [I-D.irtf-cfrg-opaque]
              Bourdrez, D., Krawczyk, H., Lewi, K., and C. A. Wood, "The
              OPAQUE Augmented PAKE Protocol", Work in Progress,
              Internet-Draft, draft-irtf-cfrg-opaque-17, 27 September
              2024, <https://datatracker.ietf.org/doc/html/draft-irtf-
              cfrg-opaque-17>.

Authors' Addresses

   Feng Geng
   Huawei Technologies
   Email: gengfeng@huawei.com

   Panyu Wu
   Huawei Technologies
   Email: wupanyu3@huawei.com

   Liang Xia
   Huawei Technologies
   Email: frank.xialiang@huawei.com

Geng, et al.              Expires 12 April 2025                [Page 10]