[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 draft-ietf-acme-star-delegation

ACME                                                          Y. Sheffer
Internet-Draft                                                    Intuit
Intended status: Standards Track                                D. Lopez
Expires: May 17, 2019                                  A. Pastor Perales
                                                          Telefonica I+D
                                                              T. Fossati
                                                       November 13, 2018

       An ACME Profile for Generating Delegated STAR Certificates


   This memo proposes a profile of the ACME protocol that allows the
   owner of an identifier (e.g., a domain name) to delegate to a third
   party access to a certificate associated with said identifier.  A
   primary use case is that of a CDN (the third party) terminating TLS
   sessions on behalf of a content provider (the owner of a domain
   name).  The presented mechanism allows the owner of the identifier to
   retain control over the delegation and revoke it at any time by
   cancelling the associated STAR certificate renewal with the ACME CA.
   Another key property of this mechanism is it does not require any
   modification to the deployed TLS ecosystem.

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 May 17, 2019.

Copyright Notice

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

Sheffer, et al.           Expires May 17, 2019                  [Page 1]

Internet-Draft            ACME STAR Delegation             November 2018

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Conventions used in this document . . . . . . . . . . . .   4
   2.  Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Preconditions . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Delegated Identity Profile  . . . . . . . . . . . . . . .   6
       2.3.1.  Order Object on the NDC-IdO side  . . . . . . . . . .   6
       2.3.2.  Order Object on the IdO-CA side . . . . . . . . . . .   9
       2.3.3.  Capability Discovery  . . . . . . . . . . . . . . . .   9
       2.3.4.  On Cancelation  . . . . . . . . . . . . . . . . . . .   9
   3.  CDNI Use Cases  . . . . . . . . . . . . . . . . . . . . . . .   9
     3.1.  Multiple Parallel Delegates . . . . . . . . . . . . . . .   9
     3.2.  Chained Delegation  . . . . . . . . . . . . . . . . . . .  10
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     4.1.  New fields in the "meta" Object within a Directory Object  10
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
     5.1.  Restricting CDNs to the Delegation Mechanism  . . . . . .  10
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  11
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Appendix A.  Document History . . . . . . . . . . . . . . . . . .  13
     A.1.  draft-sheffer-acme-star-delegation-01 . . . . . . . . . .  13
     A.2.  draft-sheffer-acme-star-delegation-00 . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   This document is a companion document to [I-D.ietf-acme-star].  To
   avoid duplication, we give here a bare-bones description of the
   motivation for this solution.  For more details and further use
   cases, please refer to the introductory sections of

Sheffer, et al.           Expires May 17, 2019                  [Page 2]

Internet-Draft            ACME STAR Delegation             November 2018

   An Identifier Owner (IdO), that we can associate in the primary use
   case to a content provider (also referred to as Domain Name Owner,
   DNO), has agreements in place with one or more NDC (Name Delegation
   Consumer) to use and attest its identity.  In the primary use case,
   we consider a CDN provider contracted to serve the IdO content over
   HTTPS.  The CDN terminates the HTTPS connection at one of its edge
   cache servers and needs to present its clients (browsers, mobile
   apps, set-top-boxes) a certificate whose name matches the authority
   of the URL that is requested, i.e., that of the IdO.  Understandably,
   most IdOs balk at sharing their long-term private keys with another
   organization and, equally, delegates would rather not have to handle
   other parties' long-term secrets.

   This document describes a profile of the ACME protocol
   [I-D.ietf-acme-acme] that allows the NDC to request the IdO, acting
   as a profiled ACME server, a certificate for a delegated identity -
   i.e., one belonging to the IdO.  The IdO then uses the ACME protocol
   (with the extensions described in [I-D.ietf-acme-star]) to request
   issuance of a STAR certificate for the same delegated identity.  The
   generated short-term certificate is automatically renewed by the ACME
   Certification Authority (CA), periodically fetched by the NDC and
   used to terminate HTTPS connections in lieu of the IdO.  The IdO can
   end the delegation at any time by simply instructing the CA to stop
   the automatic renewal and letting the certificate expire shortly

   In case the delegated identity is a domain name, this document also
   provides a way for the NDC to inform the IdO about the CNAME mappings
   that need to be installed in the IdO's DNS zone to enable the
   aliasing of the delegated name, thus allowing the complete name
   delegation workflow to be handled using a single interface.

1.1.  Terminology

   IdO  Identifier Owner, the owner of an identifier (e.g., a domain
      name) that needs to be delegated.
   DNO  Domain Name Owner, a specific kind of IdO whose identifier is a
      domain name
   NDC  Name Delegation Consumer, the entity to which the domain name is
      delegated for a limited time.  This is a CDN in the primary use
      case (in fact, readers may note the symmetry of the two acronyms).
   CDN  Content Delivery Network, a widely distributed network that
      serves the domain's web content to a wide audience at high
   STAR  Short-Term, Automatically Renewed X.509 certificates.
   ACME  The IETF Automated Certificate Management Environment, a
      certificate management protocol.
   CA A Certificate Authority that implements the ACME protocol.

Sheffer, et al.           Expires May 17, 2019                  [Page 3]

Internet-Draft            ACME STAR Delegation             November 2018

1.2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Protocol Flow

   This section presents the protocol flow.  For completeness, we
   include the ACME profile proposed in this draft as well as the
   extended ACME protocol described in [I-D.ietf-acme-star].

2.1.  Preconditions

   The protocol assumes the following preconditions are met:

   o  The IdO exposes an ACME server interface to the NDC(s) comprising
      the account management interface;
   o  The NDC has registered an ACME account with the IdO;
   o  NDC and IdO have agreed on a "CSR template" to use, including at a
      minimum: subject name (e.g., "somesite.example.com"), requested
      algorithms, key length, key usage.  The NDC is required to use
      this template for every CSR created under the same delegation;
   o  IdO has registered an ACME account with the Certificate Authority

   Note that even if the IdO implements the ACME server role, it is not
   acting as a CA: in fact, from the point of view of the certificate
   issuance process, the IdO only works as a "policing" forwarder of the
   NDC's key-pair and is responsible for completing the identity
   verification process towards the ACME CA.

2.2.  Overview

   The interaction between the NDC and the IdO is governed by the
   profiled ACME workflow detailed in Section 2.3.  The interaction
   between the IdO and the CA is ruled by ACME STAR

   The outline of the combined protocol is as follow (Figure 1):

   o  NDC sends an Order for the delegated identifier to IdO;
   o  IdO creates an Order resource in state "ready" with a "finalize"
   o  NDC immediately sends a finalize request (which includes the CSR)
      to the IdO;

Sheffer, et al.           Expires May 17, 2019                  [Page 4]

Internet-Draft            ACME STAR Delegation             November 2018

   o  IdO verifies the CSR according to the agreed CSR template;
   o  If the CSR verification fails, the Order is moved to an "invalid"
      state and everything stops;
   o  If the CSR verification is successful, IdO moves the Order to
      state "processing", and sends an Order' (using its own account)
      for the delegated identifier to the ACME STAR CA;
   o  If the ACME STAR protocol fails, Order' moves to "invalid" and the
      same state is reflected in the NDC Order;
   o  If the ACME STAR run is successful (i.e., Order' is "valid"), IdO
      copies the "star-certificate" URL from Order' to Order and moves
      its state "valid".

   The NDC can now download, install and use the certificate bearing the
   name delegated by the IdO.

   Note that, because the identity validation is suppressed, the NDC
   sends the finalize request, including the CSR, to the IdO immediately
   after the Order has been acknowledged.  The IdO must buffer a (valid)
   CSR until the Validation phase completes successfully.

Sheffer, et al.           Expires May 17, 2019                  [Page 5]

Internet-Draft            ACME STAR Delegation             November 2018

        NDC                      IdO                   CA
        Client              Server  Client             Server

        Signature ------->

        [ No identity validation ]

        Signature ------->

                                    Signature ------->
                                              <------- Required

                                    Signature ------->


                                    Signature ------->

       <~~~~~~Await issuance~~~~~~> <~~~~~~Await issuance~~~~~~>

                 <------------------------------------ Certificate

                         Figure 1: End to end flow

2.3.  Delegated Identity Profile

2.3.1.  Order Object on the NDC-IdO side

   The Order object created by the NDC:

   o  MUST contain identifiers with the new "delegated" field set to
   o  MUST NOT contain the notBefore and notAfter fields;
   o  MAY contain any of the "recurrent-*" fields listed in
      Section 3.1.1 of [I-D.ietf-acme-star];
   o  In case the identifier type is "dns", it MAY contain a "cname"
      field with the alias of the identifier in the NDC domain.  This
      field is used by the IdO to create the DNS aliasing needed to
      redirect the resolvers to the delegated entity.

Sheffer, et al.           Expires May 17, 2019                  [Page 6]

Internet-Draft            ACME STAR Delegation             November 2018

      POST /acme/new-order HTTP/1.1
      Host: acme.dno.example
      Content-Type: application/jose+json

        "protected": base64url({
          "alg": "ES256",
          "kid": "https://acme.dno.example/acme/acct/evOfKhNU60wg",
          "nonce": "5XJ1L3lEkMG7tR6pA00clA",
          "url": "https://acme.dno.example/acme/new-order"
        "payload": base64url({
          "identifiers": [
              "type": "dns",
              "value": "abc.ndc.dno.example.",
              "delegated": true,
              "cname": "abc.ndc.example."
        "signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g"

   The Order object that is created on the IdO:

   o  MUST start in the "ready" state;
   o  MUST contain an "authorizations" array with zero elements;
   o  MUST NOT contain the "notBefore" and "notAfter" fields.

      "status": "ready",
      "expires": "2016-01-01T00:00:00Z",

      "identifiers": [
         "type": "dns",
         "value": "abc.ndc.dno.example.",
         "delegated": true,
         "cname": "abc.ndc.example."

      "authorizations": [],

      "finalize": "https://acme.dno.example/acme/order/TO8rfgo/finalize"

Sheffer, et al.           Expires May 17, 2019                  [Page 7]

Internet-Draft            ACME STAR Delegation             November 2018

   The IdO SHOULD copy any "recurrent-*" field from the NDC request into
   the related STAR request to the ACME CA.

   When the validation of the identifiers has been successfully
   completed and the certificate has been issued by the CA, the IdO:

   o  MUST move its Order resource status to "valid";
   o  MUST copy the "star-certificate" field from the STAR Order;

   The latter indirectly includes (via the NotBefore and NotAfter HTTP
   headers) the renewal timers needed by the NDC to inform its
   certificate reload logic.

     "status": "valid",
     "expires": "2016-01-01T00:00:00Z",

     "identifiers": [
        "type": "dns",
        "value": "abc.ndc.dno.example.",
        "delegated": true,
        "cname": "abc.ndc.example."

     "authorizations": [],

     "finalize": "https://acme.dno.example/acme/order/TO8rfgo/finalize",

     "star-certificate": "https://acme.ca.example/acme/order/yTr23sSDg9"

   If an "identifier" object of type "dns" was included, the IdO MUST
   validate the specified CNAME at this point in the flow.  The NDC and
   IdO may have a pre-established list of valid CNAME values.  At the
   minimum, the IdO MUST verify that both DNS names are syntactically

   Following this validation, the IdO can add the CNAME records to its

      abc.ndc.dno.example. CNAME abc.ndc.example.

Sheffer, et al.           Expires May 17, 2019                  [Page 8]

Internet-Draft            ACME STAR Delegation             November 2018

2.3.2.  Order Object on the IdO-CA side

   When sending the Order to the ACME CA, the IdO SHOULD strip the
   "delegated" and "cname" attributes sent by the NDC (Section 2.3.1).
   The IdO MUST add the necessary STAR extensions to the Order.  In
   addition, to allow the NDC to download the certificate using
   unauthenticated GET, the IdO MUST add the recurrent-certificate-get
   attribute and set it to true.

2.3.3.  Capability Discovery

   In order to help a client to discover support for this profile, the
   directory object of an ACME server MUST contain the following
   attribute inside the "meta" field:

   o  star-delegation-enabled: boolean flag indicating support for the
      profile specified in this memo.  An ACME server that supports this
      delegation profile MUST include this key, and MUST set it to true.

2.3.4.  On Cancelation

   It is worth noting that cancelation of the ACME STAR certificate is a
   prerogative of the IdO.  The NDC does not own the relevant account
   key on the ACME CA, therefore it can't issue a cancelation request
   for the STAR cert.  Potentially, since it holds the STAR cert private
   key, it could request the revocation of a single STAR certificate.
   However, STAR explicitly disables the revokeCert interface.

3.  CDNI Use Cases

   Members of the IETF CDNI (Content Delivery Network Interconnection)
   working group are interested in delegating authority over web content
   to CDNs.  Their requirements are described in a draft
   [I-D.fieau-cdni-https-delegation] that considers several solutions
   addressing different delegation requirements.  This section discusses
   two of these particular requirements in the context of the STAR
   delegation workflow.

3.1.  Multiple Parallel Delegates

   In some cases the content owner (IdO) would like to delegate
   authority over a web site to multiple NDCs (CDNs).  This could happen
   if the IdO has agreements in place with different regional CDNs for
   different geographical regions, or if a "backup" CDN is used to
   handle overflow traffic by temporarily altering some of the CNAME
   mappings in place.  The STAR delegation flow enables this use case
   naturally, since each CDN can authenticate separately to the IdO (via

Sheffer, et al.           Expires May 17, 2019                  [Page 9]

Internet-Draft            ACME STAR Delegation             November 2018

   its own separate account) specifying its CSR, and the IdO is free to
   allow or deny each certificate request according to its own policy.

3.2.  Chained Delegation

   In other cases, a content owner (IdO) delegates some domains to a
   large CDN (uCDN), which in turn delegates to a smaller regional CDN,
   dCDN.  The DNO has a contractual relationship with uCDN, and uCDN has
   a similar relationship with dCDN.  However IdO may not even know
   about dCDN.

   The STAR protocol does not prevent this use case, although there is
   no special support for it: uCDN could forward requests from dCDN to
   DNO, and forward responses back to dCDN.  Whether such proxying is
   allowed is governed by policy and contracts between the parties.

   One thing that might be necessary at the interface between uCDN and
   dCDN is a mechanism by which the uCDN can advertise:

   o  The namespace that is made available to the dCDN to mint its
      delegated names;
   o  The policy for creating the key material (allowed algorithms,
      minimum key lengths, key usage, etc.) that the dCDN needs to

4.  IANA Considerations

   [[RFC Editor: please replace XXXX below by the RFC number.]]

4.1.  New fields in the "meta" Object within a Directory Object

   This document adds the following entries to the ACME Directory
   Metadata Fields:

           | Field Name              | Field Type | Reference |
           | star-delegation-enabled | boolean    | RFC XXXX  |

5.  Security Considerations

5.1.  Restricting CDNs to the Delegation Mechanism

   When a web site is delegated to a CDN, the CDN can in principle
   modify the web site at will, create and remove pages.  This means
   that a malicious or breached CDN can pass the ACME (as well as common
   non-ACME) HTTPS-based validation challenges and generate a

Sheffer, et al.           Expires May 17, 2019                 [Page 10]

Internet-Draft            ACME STAR Delegation             November 2018

   certificate for the site.  This is true regardless of whether the
   CNAME mechanisms defined in the current document is used or not.

   In some cases, this is the desired behavior: the domain owner trusts
   the CDN to have full control of the cryptographic credentials for the
   site.  The current document however assumes that the domain owner
   only wants to delegate restricted control, and wishes to retain the
   capability to cancel the CDN's credentials at a short notice.

   To restrict certificate delegation only to the protocol defined here:

   o  The domain owner MUST make sure that the CDN cannot modify the DNS
      records for the domain.  The domain owner should ensure it is the
      only entity authorized to modify the DNS zone.  Typically, it
      establishes a CNAME resource record from a subdomain into a CDN-
      managed domain.
   o  The domain owner MUST use a CAA record [RFC6844] to restrict
      certificate issuance for the domain to specific CAs that comply
      with ACME.
   o  The domain owner MUST use the ACME-specific CAA mechanism
      [I-D.ietf-acme-caa] to restrict issuance to a specific account key
      which is controlled by it, and MUST require "dns-01" as the sole
      validation method.

6.  Acknowledgments

   This work is partially supported by the European Commission under
   Horizon 2020 grant agreement no. 688421 Measurement and Architecture
   for a Middleboxed Internet (MAMI).  This support does not imply

7.  References

7.1.  Normative References

              Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
              Kasten, "Automatic Certificate Management Environment
              (ACME)", draft-ietf-acme-acme-16 (work in progress),
              October 2018.

              Landau, H., "CAA Record Extensions for Account URI and
              ACME Method Binding", draft-ietf-acme-caa-05 (work in
              progress), June 2018.

Sheffer, et al.           Expires May 17, 2019                 [Page 11]

Internet-Draft            ACME STAR Delegation             November 2018

              Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T.
              Fossati, "Support for Short-Term, Automatically-Renewed
              (STAR) Certificates in Automated Certificate Management
              Environment (ACME)", draft-ietf-acme-star-04 (work in
              progress), October 2018.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC6844]  Hallam-Baker, P. and R. Stradling, "DNS Certification
              Authority Authorization (CAA) Resource Record", RFC 6844,
              DOI 10.17487/RFC6844, January 2013,

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

7.2.  Informative References

              Fieau, F., Emile, S., and S. Mishra, "HTTPS delegation in
              CDNI", draft-fieau-cdni-https-delegation-02 (work in
              progress), July 2017.

Sheffer, et al.           Expires May 17, 2019                 [Page 12]

Internet-Draft            ACME STAR Delegation             November 2018

Appendix A.  Document History

   [[Note to RFC Editor: please remove before publication.]]

A.1.  draft-sheffer-acme-star-delegation-01

   o  Added security considerations about disallowing CDNs from issuing
      certificates for a delegated domain.

A.2.  draft-sheffer-acme-star-delegation-00

   o  Initial version, some text extracted from draft-sheffer-acme-star-

Authors' Addresses

   Yaron Sheffer

   EMail: yaronf.ietf@gmail.com

   Diego Lopez
   Telefonica I+D

   EMail: diego.r.lopez@telefonica.com

   Antonio Agustin Pastor Perales
   Telefonica I+D

   EMail: antonio.pastorperales@telefonica.com

   Thomas Fossati

   EMail: thomas.fossati@nokia.com

Sheffer, et al.           Expires May 17, 2019                 [Page 13]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/