<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.9 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc rfcedstyle="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc text-list-symbols="o-*+"?>
<?rfc compact="yes"?>
<?rfc subcompact="yes"?>

<rfc ipr="trust200902" docName="draft-sheffer-acme-star-request-02" category="std">

  <front>
    <title abbrev="ACME STAR Request">Generating Certificate Requests for Short-Term, Automatically-Renewed (STAR) Certificates</title>

    <author initials="Y." surname="Sheffer" fullname="Yaron Sheffer">
      <organization>Intuit</organization>
      <address>
        <email>yaronf.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="D." surname="Lopez" fullname="Diego Lopez">
      <organization>Telefonica I+D</organization>
      <address>
        <email>diego.r.lopez@telefonica.com</email>
      </address>
    </author>
    <author initials="O." surname="Gonzalez de Dios" fullname="Oscar Gonzalez de Dios">
      <organization>Telefonica I+D</organization>
      <address>
        <email>oscar.gonzalezdedios@telefonica.com</email>
      </address>
    </author>
    <author initials="A." surname="Pastor Perales" fullname="Antonio Agustin Pastor Perales">
      <organization>Telefonica I+D</organization>
      <address>
        <email>antonio.pastorperales@telefonica.com</email>
      </address>
    </author>
    <author initials="T." surname="Fossati" fullname="Thomas Fossati">
      <organization>Nokia</organization>
      <address>
        <email>thomas.fossati@nokia.com</email>
      </address>
    </author>

    <date year="2018" month="June" day="29"/>

    <area>Security</area>
    <workgroup>ACME</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This memo proposes a protocol that allows a domain name owner to delegate to a third
party (such as a CDN) control over a certificate that bears one or more names in that domain.
Specifically the third party creates a Certificate Signing Request
for the domain, which can then be used by the domain owner to request
a short term and automatically renewed (STAR) certificate.</t>

<t>This is a component in a solution where a third-party such as a CDN can terminate TLS
sessions on behalf of a domain name owner (e.g., a content provider),
and the domain owner can cancel this delegation at any time without
having to rely on certificate revocation mechanisms.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>This document is a companion document to <xref target="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 <xref target="I-D.ietf-acme-star"/>.</t>

<t>A content provider (referred to in this document as Domain Name Owner, DNO, or
more generally as Identity Owner, IdO) has agreements in
place with one or more Content Delivery Networks (CDNs) that are
contracted to serve its content over HTTPS. The CDN terminates the
HTTPS connection at one of its edge cache servers and needs to present
its clients (browsers, set-top-boxes) a certificate whose name matches
the authority of the URL that is requested, i.e. that of the DNO.
However, many DNOs balk at sharing their long-term private keys with
another organization and, equally, delegates (henceforth referred to
as NDC, Name Delegation Consumer) would rather not have
to handle other parties’ long-term secrets.</t>

<t>This document describes a protocol where the IdO and the NDC agree on
a CSR template and the NDC
generates a CSR for a private key that it holds. The IdO then uses the
ACME protocol (as extended in <xref target="I-D.ietf-acme-star"/>) to issue the
STAR certificate.</t>

<t>The generated short-term certificate is automatically renewed by an
ACME Certification Authority (CA) <xref target="I-D.ietf-acme-acme"/> and periodically
fetched into the NDC and used for HTTPS connections. 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 thereafter.</t>

<section anchor="terminology" title="Terminology">

<t><list style="hanging">
  <t hangText='IdO'>
  Identity Owner, the owner of an identity (e.g., a domain name) that needs to be delegated.</t>
  <t hangText='DNO'>
  Domain Name Owner, a specific kind of IdO whose identity is a domain name.</t>
  <t hangText='NDC'>
  Name Delegation Consumer, the entity to which the domain name is delegated for a limited
time. This is often a CDN (in fact, readers may note the similarity of the two acronyms).</t>
  <t hangText='CDN'>
  Content Delivery Network, a widely distributed network
that serves the domain’s web content to a wide audience at
high performance.</t>
  <t hangText='STAR'>
  Short-Term, Automatically Renewed X.509 certificates.</t>
  <t hangText='ACME'>
  The IETF Automated Certificate Management Environment, a certificate
management protocol.</t>
  <t hangText='CA'>
  A Certificate Authority that implements the ACME protocol.</t>
</list></t>

</section>
<section anchor="conventions-used-in-this-document" title="Conventions used in this document">

<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and
“OPTIONAL” in this document are to be interpreted as described in <xref target="RFC2119"/>.</t>

</section>
</section>
<section anchor="protocol-flow" title="Protocol Flow">

<t>This section presents the protocol flow. For completeness, we include
the STAR Interface proposed in this draft, as well as the extended
ACME protocol as described in <xref target="I-D.ietf-acme-star"/>.</t>

<section anchor="proto-preconditions" title="Preconditions">

<t>The protocol assumes the following preconditions are met:</t>

<t><list style="symbols">
  <t>A mutually authenticated channel between NDC and IdO pre-exists.
This is called “STAR channel” and all STAR protocol exchanges between
NDC and IdO are run over it.  It provides the guarantee that requests
and responses are authentic.</t>
  <t>NDC and IdO have agreed on a “CSR template” to use, including at a minimum:
  <list style="symbols">
      <t>Subject name (e.g., “somesite.example.com”),</t>
      <t>Requested algorithms,</t>
      <t>Key length,</t>
      <t>Key usage.</t>
    </list>
The NDC is required to use this template for every CSR created under the same delegation.</t>
  <t>IdO has registered through the ACME interface exposed by the
Certificate Authority (CA) using the usual ACME registration
procedure. In ACME terms, the IdO has an Account on the server
and is ready to issue Orders.</t>
</list></t>

</section>
<section anchor="proto-bootstrap" title="Bootstrap">

<t>The NDC (STAR Client) generates a key-pair, wraps it into a Certificate
Signing Request (CSR) according to the agreed upon CSR template, and sends
it to the IdO (STAR Proxy) over the pre-established STAR channel.  The
IdO uses the NDC identity provided on the STAR channel to look up the
CSR template that applies to the requesting NDC and decides whether or
not to accept the request. Assuming everything is in order,
it then “forwards” the NDC request to the ACME CA by means of the
usual ACME application procedure. Specifically, the IdO, in its role as an
ACME client, requests the CA to issue a STAR certificate, i.e., one that:</t>

<t><list style="symbols">
  <t>Has a short validity (e.g., 24 to 72 hours);</t>
  <t>Is automatically renewed by the CA for a certain period of time;</t>
  <t>Is downloadable from a (highly available) public link without requiring any special authorization.</t>
</list></t>

<t>Other than that, the ACME protocol flows as normal between IdO and CA,
in particular IdO is responsible for satisfying the requested ACME
challenges until the CA is willing to issue the requested certificate.
Per normal ACME processing, the IdO is given back an Order ID for the issued STAR
certificate to be used in subsequent interaction with the CA (e.g., if
the certificate needs to be terminated.)</t>

<t>Concurrently, a response is sent back to the NDC with an
endpoint to  poll for completion of the certificate generation process.</t>

<t>The bootstrap phase ends when the IdO obtains the OK from the ACME CA
and posts the certificate’s URL to the “completion endpoint” where the
NDC can retrieve it.</t>

<figure title="Bootstrap" anchor="figprotoboot"><artwork><![CDATA[
                     ...........................
STAR                 :  STAR Proxy /           :              ACME/STAR
Client               :           ACME Client   :               Server
  |                  :    |               |    :                  |
  |                  :    |               |   ACME registration   |
  +-------.          :    |               |<--------------------->|
  |       |          :    |               |   STAR capabilities   |
  |   generate CSR   :    |               |    :                  |
  |       |          :    |               |    :                  |
  |<------'          :    |               |    :                  |
  |                  :    |               |    :                  |
  |     Request new  :    |               |    :                  |
  +---------------------->|               |    :                  |
  |     cert for CSR :    |               |    :                  |
  |                  :    +-------.       |    :                  |
  |                  :    |       |       |    :                  |
  |                  :    |   Verify CSR  |    :                  |
  |                  :    |       |       |    :                  |
  |                  :    +<------'       |    :                  |
  |   Accepted, poll at   |               |    :                  |
  |<----------------------+               |    :                  |
  |    "completion URL"   |- - - - - - - >|    Application for    |
  |                  :    |               +---------------------->|
  |                  :    |               |    STAR certificate   |
  |                  :    |               |    :                  |
  |  GET "completion URL" |               |    :  Challenge       |
  |<--------------------->|               |<--------------------->|
  |   in progress    :    |               |    :  Response        |
  |                  :    |               |    :                  |
  |                  :    |               |  Finalize/Certificate |
  |                  :    |               |<----------------------+
  |  GET "completion URL" |< - - - - - - -|    : + Order Id       |
  +---------------------->|               |    :                  |
  |                  :    |               |    :                  |
  |  200, certificate URL |               |    :                  |
  |<----------------------+               |    :                  |
  |   and other metadata  |               |    :                  |
  |                  :    |               |    :                  |
                     `.........................'
]]></artwork></figure>

</section>
<section anchor="proto-auto-renewal" title="Refresh">

<t>The CA automatically re-issues the certificate (using the same CSR)
before it expires and publishes it to the URL that the NDC has come to
know at the end of the bootstrap phase.  The NDC downloads and
installs it. This process goes on until either:</t>

<t><list style="symbols">
  <t>IdO terminates the delegation, or</t>
  <t>Automatic renewal expires.</t>
</list></t>

<figure title="Auto renewal" anchor="figprotorefresh"><artwork><![CDATA[
        STAR                    ACME/STAR
        Client                  Server
          |     Retrieve cert     |                     [...]
          |<--------------------->|                      |
          |                       +------.              /
          |                       |      |             /
          |                       | Automatic renewal :
          |                       |      |             \
          |                       |<-----'              \
          |     Retrieve cert     |                      |
          |<--------------------->|                   72 hours
          |                       |                      |
          |                       +------.              /
          |                       |      |             /
          |                       | Automatic renewal :
          |                       |      |             \
          |                       |<-----'              \
          |     Retrieve cert     |                      |
          |<--------------------->|                   72 hours
          |                       |                      |
          |                       +------.              /
          |                       |      |             /
          |                       | Automatic renewal :
          |                       |      |             \
          |                       |<-----'              \
          |                       |                      |
          |         [...]         |                    [...]
]]></artwork></figure>

</section>
<section anchor="proto-termination" title="Termination">

<t>The IdO may request early termination of the STAR certificate by including
the Order ID in a certificate termination request to the ACME
interface, defined below.
After the CA receives and verifies the request, it shall:</t>

<t><list style="symbols">
  <t>Cancel the automatic renewal process for the STAR certificate;</t>
  <t>Change the certificate publication resource to return an error
indicating the termination of the delegation to external clients, including the NDC.</t>
</list></t>

<t>Note that it is not necessary to explicitly revoke the short-term certificate.</t>

<figure title="Termination" anchor="figprototerm"><artwork><![CDATA[
   STAR                    STAR                   ACME/STAR
   Client                  Proxy                  Server
     |                       |                       |
     |                       |  Terminate Order ID   |
     |                       +---------------------->|
     |                       |                       +-------.
     |                       |                       |       |
     |                       |                       |  End auto renewal
     |                       |                       |  Remove cert link
     |                       |                       |  etc.
     |                       |                       |       |
     |                       |         Done          |<------'
     |                       |<----------------------+
     |                       |                       |
     |                                               |
     |                 Retrieve cert                 |
     +---------------------------------------------->|
     |                 Error: terminated             |
     |<----------------------------------------------+
     |                                               |
]]></artwork></figure>

<t>No facility is provided for the NDC to directly initiate the termination
of a STAR certificate.</t>

</section>
</section>
<section anchor="protocol-details" title="Protocol Details">

<t>This section describes the STAR
API between the STAR Client and the STAR Proxy.</t>

<section anchor="star-api" title="STAR API">

<t>This API allows an IdO (STAR Proxy) to control the long-term delegation of one of its names to an authorized third-party (STAR Client).</t>

<section anchor="creating-a-delegation-request" title="Creating a Delegation Request">

<t>To create a new delegation request, the client wraps the following parameters in a POST to the ‘/star/delegation’ path:</t>

<t><list style="symbols">
  <t>csr (required, string):
A CSR encoding the parameters for the certificate being requested <xref target="RFC2986"/>.  The CSR is sent in the base64url-encoded version of the DER format.  (Note: Because this field uses base64url, and does not include headers, it is different from PEM.)</t>
  <t>duration (optional, integer):
How long the delegation should last (in seconds).  If not specified, a local default applies.</t>
  <t>certificate-lifetime (optional, integer):
How long each short-term certificate should last (in seconds).  If not specified, a local default applies.</t>
</list></t>

<t>Note that the STAR Proxy MAY treat both “duration” and “certificate-lifetime” as hints, and MAY update any of them due to local policy decisions or as a result of the interaction with the ACME server.</t>

<figure><artwork><![CDATA[
    POST /star/delegation
    Host: star-proxy.example.net
    Content-Type: application/json

    {
        "csr": "jcRf4uXra7FGYW5ZMewvV...rhlnznwy8YbpMGqwidEXfE",
        "duration": 31536000,
        "certificate-lifetime": 604800
    }
]]></artwork></figure>

<t>On success, the service returns a 201 Created status with the URL of the newly generated delegation order in the Location header field.  The current state of the delegation order is returned in the body of the response in JSON format:</t>

<figure><artwork><![CDATA[
    HTTP/1.1 201 Created
    Content-Type: application/json
    Location: http://example.net/star/delegation/567

    {
        "id": "567",
        "certificate-lifetime": 604800,
        "duration": 31536000,
        "status": "new"
    }
]]></artwork></figure>

<t>If an error occurs, an error response (4XX or 5XX) is generated with an appropriate problem detail <xref target="RFC7807"/> body, e.g.:</t>

<figure><artwork><![CDATA[
    HTTP/1.1 400 Bad Request
    Content-Type: application/problem+json

    {
       "type": "https://example.net/validation-error",
       "title": "Your request parameters didn't validate.",
       "invalid-params": [ {
                             "name": "csr",
                             "reason": "missing mandatory parameter"
                           } ]
    }
]]></artwork></figure>

</section>
<section anchor="polling-the-delegation-request" title="Polling the Delegation Request">

<t>The returned delegation order URL can be polled until the dialog between the STAR Proxy and the ACME server is complete (i.e., the “status” attribute changes from “new” or “pending” to one of “failed” or “success”):</t>

<figure><artwork><![CDATA[
    GET /star/delegation/567
    Host: star-proxy.example.net
]]></artwork></figure>

<t>In responding to poll requests while the validation is still in progress, the server MUST return a 200 (OK) response and MAY include a Retry-After header field to suggest a polling interval to the client.  The Retry-After value MUST be expressed in seconds.  If the Retry-After header is present, in order to avoid surprising interactions with heuristic expiration times, a max-age Cache-Control
SHOULD also be present and set to a value slightly smaller than the Retry-After value:</t>

<figure><artwork><![CDATA[
    HTTP/1.1 200 OK
    Content-Type: application/json
    Retry-After: 10
    Cache-Control: max-age=9

    {
        "id": "5",
        "certificate-lifetime": 604800,
        "creation-date": "2017-11-12T01:38:09Z",
        "duration": 31536000,
        "status": "pending"
    }
]]></artwork></figure>

<t>When the operation is successfully completed, the ACME Proxy returns:</t>

<figure><artwork><![CDATA[
    HTTP/1.1 200 OK

    {
        "status": "success", // or "failed"
        "lifetime": 365,     // lifetime of the registration in days,
                             // possibly less than requested
        "certificates": "https://ca.example.org/certificates/A51A3"
    }
]]></artwork></figure>

<t>The “certificates” attribute contains a URL of the certificate pull endpoint, received from the ACME Server.</t>

<t>If the registration fails for any reason, the server returns a “200 OK” response, with the status as “failed” and a “reason” attribute containing a human readable error message.</t>

</section>
</section>
<section anchor="transport-security-for-the-star-protocol" title="Transport Security for the STAR Protocol">

<t>Traffic between the STAR Client and the STAR Proxy MUST be protected with HTTPS.
For interoperability, all implementations
MUST support HTTP Basic Authentication <xref target="RFC7617"/>. However some deployments
MAY prefer mutually-authenticated HTTPS or two-legged OAUTH.</t>

</section>
</section>
<section anchor="cdni-use-cases" title="CDNI Use Cases">

<t>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 <xref target="I-D.fieau-cdni-https-delegation"/> that compares
several solutions. This section discusses two particular requirements
in the context of the STAR protocol.</t>

<section anchor="multiple-parallel-delegates" title="Multiple Parallel Delegates">

<t>In some cases the DNO would like to delegate authority over a web site
to multiple CDNs. This could happen if the DNO has agreements in place
with different regional CDNs for different geographical regions. STAR
enables this use case naturally, since each CDN can authenticate
separately to the DNO specifying its CSR, and the DNO is free to allow
or deny each certificate request according to its own policy.</t>

</section>
<section anchor="chained-delegation" title="Chained Delegation">

<t>In other cases, a content owner (DNO) delegates some domains to a
large CDN (CDN1), which in turn delegates to a smaller regional
CDN, CDN2. The DNO has a contractual relationship with CDN1, and CDN1
has a similar relationship with CDN2. However DNO may not even know
about CDN2.</t>

<t>The STAR protocol does not prevent this use case, although there is
no special support for it. CDN1 can forward requests from CDN2 to DNO,
and forward responses back to CDN2. Whether such proxying is allowed
is governed by policy and contracts between the parties.</t>

</section>
</section>
<section anchor="security-considerations" title="Security Considerations">

<section anchor="star-protocol-authentication" title="STAR Protocol Authentication">

<t>The STAR protocol allows its client to obtain certificates bearing the
IdO’s identity. Therefore strong client authentication is
mandatory.</t>

<t>When multiple NDCs may connect to the same IdO, the STAR protocol’s
authentication MUST allow the IdO to distinguish between different
NDCs, and the IdO MUST associate different Registration objects to
different clients. Among other benefits, this allows the IdO to cancel a STAR
registration for one of its clients instead of all of them.</t>

</section>
</section>
<section anchor="acknowledgments" title="Acknowledgments">

<t>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 endorsement.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference  anchor="RFC2986" target='https://www.rfc-editor.org/info/rfc2986'>
<front>
<title>PKCS #10: Certification Request Syntax Specification Version 1.7</title>
<author initials='M.' surname='Nystrom' fullname='M. Nystrom'><organization /></author>
<author initials='B.' surname='Kaliski' fullname='B. Kaliski'><organization /></author>
<date year='2000' month='November' />
<abstract><t>This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process.  The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='2986'/>
<seriesInfo name='DOI' value='10.17487/RFC2986'/>
</reference>



<reference  anchor="RFC7617" target='https://www.rfc-editor.org/info/rfc7617'>
<front>
<title>The 'Basic' HTTP Authentication Scheme</title>
<author initials='J.' surname='Reschke' fullname='J. Reschke'><organization /></author>
<date year='2015' month='September' />
<abstract><t>This document defines the &quot;Basic&quot; Hypertext Transfer Protocol (HTTP) authentication scheme, which transmits credentials as user-id/ password pairs, encoded using Base64.</t></abstract>
</front>
<seriesInfo name='RFC' value='7617'/>
<seriesInfo name='DOI' value='10.17487/RFC7617'/>
</reference>



<reference  anchor="RFC7807" target='https://www.rfc-editor.org/info/rfc7807'>
<front>
<title>Problem Details for HTTP APIs</title>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'><organization /></author>
<author initials='E.' surname='Wilde' fullname='E. Wilde'><organization /></author>
<date year='2016' month='March' />
<abstract><t>This document defines a &quot;problem detail&quot; as a way to carry machine- readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs.</t></abstract>
</front>
<seriesInfo name='RFC' value='7807'/>
<seriesInfo name='DOI' value='10.17487/RFC7807'/>
</reference>



<reference anchor="I-D.ietf-acme-acme">
<front>
<title>Automatic Certificate Management Environment (ACME)</title>

<author initials='R' surname='Barnes' fullname='Richard Barnes'>
    <organization />
</author>

<author initials='J' surname='Hoffman-Andrews' fullname='Jacob Hoffman-Andrews'>
    <organization />
</author>

<author initials='D' surname='McCarney' fullname='Daniel McCarney'>
    <organization />
</author>

<author initials='J' surname='Kasten' fullname='James Kasten'>
    <organization />
</author>

<date month='April' day='24' year='2018' />

<abstract><t>Certificates in PKI using X.509 (PKIX) are used for a number of purposes, the most significant of which is the authentication of domain names.  Thus, certificate authorities in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate.  Today, this verification is done through a collection of ad hoc mechanisms.  This document describes a protocol that a certification authority (CA) and an applicant can use to automate the process of verification and certificate issuance.  The protocol also provides facilities for other certificate management functions, such as certificate revocation.  RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for this draft is maintained in GitHub.  Suggested changes should be submitted as pull requests at https://github.com/ietf-wg-acme/acme [1].  Instructions are on that page as well.  Editorial changes can be managed in GitHub, but any substantive change should be discussed on the ACME mailing list (acme@ietf.org).</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-acme-acme-12' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-acme-acme-12.txt' />
</reference>



<reference anchor="I-D.ietf-acme-star">
<front>
<title>Support for Short-Term, Automatically-Renewed (STAR) Certificates in Automated Certificate Management Environment (ACME)</title>

<author initials='Y' surname='Sheffer' fullname='Yaron Sheffer'>
    <organization />
</author>

<author initials='D' surname='Lopez' fullname='Diego Lopez'>
    <organization />
</author>

<author initials='O' surname='Dios' fullname='Oscar de Dios'>
    <organization />
</author>

<author initials='A' surname='Pastor' fullname='Antonio Pastor'>
    <organization />
</author>

<author initials='T' surname='Fossati' fullname='Thomas Fossati'>
    <organization />
</author>

<date month='March' day='3' year='2018' />

<abstract><t>Public-key certificates need to be revoked when they are compromised, that is, when the associated private key is exposed to an attacker. However the revocation process is often unreliable.  An alternative to revocation is issuing a sequence of certificates, each with a short validity period, and terminating this sequence upon compromise. This memo proposes an ACME extension to enable the issuance of short- term and automatically renewed (STAR) certificates.  [RFC Editor: please remove before publication]  While the draft is being developed, the editor's version can be found at https://github.com/yaronf/I-D/tree/master/STAR.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-acme-star-03' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-acme-star-03.txt' />
</reference>




    </references>

    <references title='Informative References'>





<reference anchor="I-D.fieau-cdni-https-delegation">
<front>
<title>HTTPS delegation in CDNI</title>

<author initials='F' surname='Fieau' fullname='Frederic Fieau'>
    <organization />
</author>

<author initials='S' surname='Emile' fullname='Stephan Emile'>
    <organization />
</author>

<author initials='S' surname='Mishra' fullname='Sanjay Mishra'>
    <organization />
</author>

<date month='July' day='3' year='2017' />

<abstract><t>This document examines probable solutions for delegating encrypted content delivery within the context of CDN interconnection.  The HTTPS delegation also expects delivering content without compromising security, integrity and user privacy.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-fieau-cdni-https-delegation-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-fieau-cdni-https-delegation-02.txt' />
</reference>




    </references>


<section anchor="document-history" title="Document History">

<t>[[Note to RFC Editor: please remove before publication.]]</t>

<section anchor="draft-sheffer-acme-star-request-02" title="draft-sheffer-acme-star-request-02">

<t><list style="symbols">
  <t>Clarifications and minor changes based on implementation experience.</t>
  <t>More detail on error cases.</t>
</list></t>

</section>
<section anchor="draft-sheffer-acme-star-request-01" title="draft-sheffer-acme-star-request-01">

<t><list style="symbols">
  <t>Correct reference to WG draft.</t>
</list></t>

</section>
<section anchor="draft-sheffer-acme-star-request-00" title="draft-sheffer-acme-star-request-00">

<t><list style="symbols">
  <t>Initial version, the STAR API extracted from draft-sheffer-acme-star-02.</t>
</list></t>

</section>
</section>


  </back>

<!-- ##markdown-source:
H4sIABwhNlsAA+1c+3PbOJL+nX8FSvkh9kaUH5OnbvdqNLYz8U1s52zPTrJz
U3cQCUnYUKSWIO0oM7m//b5uACSoh+Nkp3brqtZXt6OQeDQa/fga6GYcx1Gl
q0wNxfcqV6WsdD4VR6qs9EQnslLiUv2tVqYyYlKU4mpWlFV8rcp5X4zqqpij
fSKzbBlfovetSsXO1fXocjccwURyPC7VzVCMjs5OBL33g0ZpkeRyjsnTUk6q
2MzUZKLKWCZzFZtKlnFpG8b7hxGNNS3K5VCYKo0ivSiHoiprUx3u77/Ae1kq
ORRXKqlLXS2j26J8Py2LemHnjd6rJR6lQ3GaV6rMVRUf05xRhHny9L9lVuSg
YwlyF3oYCVFOEpWaapm5p0JURRL81Hmq8so/MOBLqSam+fdy3vlnVeqkaZwU
8zn6Nm91num8nUZ9qOJMY9EYZFxkaFbEf3hk+y1kO4ypx50nkawr7A+Ij/GW
hkXXdwNsGnOVn1luv5NlkXeeF+VU5vojtrPImUW1rviFmkudYXzqMRloVU2+
ndKjAabuTHQ8EK+LhfoYTHOssWHB0+4k1ypTkyKHjIjTR8fhZCn1G5SDjHp+
WzXt1ua8GIjvi/yjzNRHkSrMV5hg+guTyHJzg/tSUtAQg6kbIlUpBriLoNFA
vJGmgqa8gS5lKiRnlFfoVIjRFDKr800N70uWtEMNFjzEwo5wF13XA/GyMAYD
BwRdz6C/pvOiS8B58V7LcN6Kewwmtse3Ob3nuaK8KMkW3ChSncuXR4cHBy/8
zxfPn7qfz54ePPM/n+/zz9P4mKXK6jz9z/pTsgRDaHw+CWehNhOtZB0naa7j
WVUtTJyCB1NLfhTFcSzkGLoHFYmi65k2Yq7mhViUxaIwyghJP6HLRYalyUrA
khW39DjFOrFFxCdR3MIuQuOFG1vRb4kOukyjhSyrpdgxdTITknoeHZ/vQlHz
qsSgxQ16SpEE5pTnGStZGgGDA4aLeVEqnslgr+x7O/0gulqohDvCwuKNspMK
O2kCe1fxIkJzfaWnOZlwb2HJalNPO2Rf3M40SE0kzaRyUCJqA7M9Xgat2iU7
8xtJYcjywzaVc0hfKmRo/NGsY/yD9Q4c3zXRSdYKi84rWiiGLLKadgo0KbDA
sTS2q+tw1NKLuXVOa7x+fRVh+wz6EhexiJnMJqKYbNy5HTWYDvo8PSw/Jsee
3+hUlbv9iJaytm6aDP+fKJIKEN7KlCAZycEqjdFvNdShrqKZvCGGM7fAC7QK
9xuOr0hs57lKZtAuMzcDK5tznaaZiqIHZHDLIq0Tauc4BtdYz5lXnnXoi1Ga
55jw11/XFeXTp4G4hoDeFDqN0nqRaTs9tl6JKXRHOG6P4TDjMfaDVmiSUi+Y
SnCRODIvoGeWbitCIMNv2CB66eU2VRUsg2GZmNQlepYkUOAfNqgvFpnCDzBh
YuUJ76HGbq3w5cIoXrOhabesJopGa1sndnjIEjKHUVltQpZBbo7tjp6THFzQ
tvbF8flFHwoXMeFTRjskvGh8Sq4coMG3PE0vdsWMpG9aKsW+GpNEi0wmdt87
unvkiDtWGdiLRZ2ritCHETuQXbPrbEupIrYLMEaWbKNK7IbG2H55bC9eXV+/
ucIeYhNI9BuxN8w9fksdcss5EkkmZsIjqXRKzE/QmYcv7dbkCliG5lyUymCm
iGfNNK9sZ1zC6qFpH32quCoWEIsPCoR3TdftDEbTahZUH1OYiCTFog7inhOd
Hy9f2yVjS5wBUWlf6IEa2OeuHfZjEL0qbtUN8XxOioVHBoKZvadlmZksWbNm
SpcC+Gwas/1ZlCSZSgDRGd4NqHHBkhe6L1p3X2B62uR+Y7yxXNi9BI4SwioC
KYqw3efHR30rMsetzmN7DcSq3BW3RZ2lAhiZ5sKUEJEbFYGrUGsosrBEkP3S
yjwMKIaUl6oyg1XVtno37noiaw2JQRBD4S0USLPSiN2GOT66uoRkzCGRYETQ
JrJy7fwCGpHyypBlbmtAfJGlxsoZTcTuoDZOzBiqNyTtgDdApQqQNyVt26yp
u6yLxtRMfcRAf9UVeMUjFWCXYhkUihnZu43eBT5K5pay1uPRDo0aCdw5Gu2u
UUf/8+kTcwlQSRepHTeaKBJiWpC1TJbHaMUekRi3qmwBu8hJKMv3aIuDAL1G
Y4uWhMEQqSSVk2ZxNGL9h6Zx/2a5dqkyYyoyVTUdQv6oDwsNAWHuWVgAIDAB
G8HgBw/ENduLIiumyygCpdFwzbzRiNbVkcvMhfbvG1cZeFFnvhoLMlaNLqWY
ERqLGTZYW/h3h17Ee8RKNBXxzRqRZka9grYwIknxcKsWWupdb5Bj8Uzgw9k+
tV7b7aQUmZ5r/CuiraFttKCkAONyBzJ20HsC69zHNsiUTOdcLknPrTZiL3Um
Q0MHKy9kgsBoOTe7oByDgPJt7oBYcouFY89STQHhuCbqcvs2Yi6zzTbBch7C
wqlx4yAYedIgUBFESbBjkLhopqczEm2Gx3gGUkj5QMvWeF34eP3t4Mn+i1C+
yEpxwDy0sn5y/dJ3RfMQap7JXE7ZO4qT/EaDD/S73/Ua0bxt5e0JsWqE8Ued
4VotthYKmuNcL7GjY5CspIPRNyQIBB9YZVdxgDU4ZPMo8jeid/bj1XWvb/8r
zi/49+XJf/54enlyTL+vXo1ev25+2BYR/nHx42v3nn61PY8uzs5Ozo9tZzwV
K4/ORu/wHyhz1Lt4c316cT563duAVkrlFEvT0QRcNHFamsY9OJvrwiqGRA/E
G2+cXyJmcY7FoSnv5S3nGis+QUOKA0tGkzAvEAFjGBfqPMnqVLE/Z7vNhyQT
gjsuWAq4S8cmfaLvVmUZ/Zc10rmHFc+xvootGO8BrUhBzlPNOxr9OhQPeJh4
ET7/ZDc1mIDMgqVhUlD8Rjaz04UZPFcVRYSQuXld1Rb41eTzKpa+VBA2zwH5
x9BHBZvgnQEZLQwXqw9QWiiHtxykRujWs27Odu7Z2Ahc4acNkeoDNZiCTDd6
FI5O5JV1btGfrgYIbRukaxc2rWWJmF+58NGBKsPhC7YaQRVHs6Vq1zTAWsNJ
CKpYAJFSiCJFL4QQPRJA6FDfSQLxkFwZQpRcz+s5xduxuKrHf4WEWRPrfEXP
FGA/LOtAfZAkVXQe0ENoRR0uPfoDT6ak27O5sW9+gFJmKp9Ws/bftYGhgCgI
NjxEvAOQ2uF8CixYBBvkQ6ZdsZGl1diIGP47pxCBbTZR2rpnYoplBg08xYYq
HnpWFvV01toZ3Ug/nG3RxsfRZnvFqKM23lnXBvJlB7KTlDx5hC1NVFqXcD+n
uX1P4Mf0G7DHIQdeJUlRUziQ20UwkOfNZobIdNkirYuSPJVVoO+KoqLZFoHy
jP0zpzjEVg7TxRHD/10RIkbYSsTfGl72Fl0MwURGR50zhmjljAHrv0LUL0F1
mbpQmAMDK231gtx3IGxsEbGqPDWIQ3xrWr8lDJbtw3LXqoM1YNA+GIpxpg3h
tVDjBiwshHMa7GolxwMMp0epZ2bYmabOiuI9SLS7G4JqG7QtED8r42l0ikdr
9LqVAuOQmgK1uxAkosiAeJYkalGF/QZiRNaKurPQQpbxU/O5T0H72Gd+EBDv
QbJvJZxWr1mSG8TTYnHwiCRzrqSNoGkRgfQx9Q4jB8IXnio1skeazxFkWSCS
YTm0ptxGif3G6AQA1kqgFKtI38Z6fY5LiY1seF/xYY49RrqRmU4DwHn4mIZ7
doiYpC7N7r+Rmt4RBTgKLK6jeQn3WWjPXADCc0OkgLlZIVPIDoxFWczRYYfg
Epn/Gwk8hxe7YlFDthJAxPy9P9ZxhocNIQA9Y1kC5lbpPzpzEl3wpmOR9uSu
v45V2O0a4iifkbYOxkd3RyNse27DxqQGwuQ3rOls2TXTjrXSmauZLL2ZaUJr
e78Bmc7IokIWYTt05rmkKUbOMqeXTXgWdO/EaG84tGVC/TISOmrLp62ZwpB0
kJQjUk/ek8FiIyROj4U/beRprKZGndPPojlxxJJNPTZEBR8IwhRKi174gMVR
7wRET6LVMCgMSJozknSwC2xZ5EmNqD6vSL5l4yEFIyRMxmQHMR9PCHmHRVoU
2sJssQCY4PU4sBScjYVkOOvZqJgxLs5tDK9YzOgMjMwdWYm8YWMxJsG1CnXx
gxXPQLPZ4MP7OJULJkVQwGcsdgW9gEC/gl57isBQg6JVwMpSKz5xAon/2/zx
Af/a32D7n43sV/+GQrTWW+x134R/tLw9lgzrgdbH6TQVTauVccSV9YtC/LZO
Prddff7bBmr4+ReOseba3RiPYvs3+NwYf4w3/f17SMdvnxtDOH4nciHHOtN0
5hSsxXt19rx/Bz/uQ8fWMdw6H/49Y6w//soxPFqBG/mKMR5t3DLs2RfTQYrM
hoV25nfjx6rs/T087fz3K8b4M1zxxELyfxodj1Zk73NjjBit0Tk1G35ZiS/c
l806HT/6kjHoR2jOYeV79C4W4f9ZmRsF4I6k6TP8WH2+VZ6/VOdWwd8X0vEZ
fnx/cr3OkW1jHHkIFI6xzdaujvEZm6zZvyOiMeaza7n0gKO7lt+DH/cd4yXg
UKY/qr0wYv2iMbbJ81378seOnMZuLY88PkyDtfx+9vRe/LhrjMP9/X5Hgglc
/TN0nwCfvUOaqwpBSyX/8b5yw9//bEWCD0MYSWcOEz3luIfAr+C8sj/1mlOJ
3ic+pbhUE2jRLDijoEAvdlcf7pgC0H81/Is5qFgDw2KnPXnh4x46jIjGdMFH
UNddl9hrUI7zzEzxwYaDz81tpY8G6BAGkk3BSvQ+L26Fe6fsJUa1ju0H7YmV
Dzh5vojufUC94VM9Pjh0MYKYFopTF2yopjTtOofJfBXXufINzq/4+jpuT/Kb
+yK3yM24fiNcFyEQ9082AnIRIO2OBGEnXUTBkGaTpNm/nyEqv4S972mTN4jl
libenAy6T/fu0fO3Ta/v13F9H4ZfO+F/3aejZdvD7tP1nvfdli5jv2BP/EHN
/Rd758xbuv5rS9ue/9rSTa//X2/p1inXHm/syjb17q7W7G7x0KX1wt5JE5M8
f8hPt5kE9u6iddZV+9T5anJZdFPuD6iVLCkvoW3n3eZaqDBetvdNfMDXHCRy
gmDn5DAYbsNJeNRc2VCqz0TndFKs6MIzGlFuhD9PLFWi9I2DAzcUp2rnZd2g
fYIGhgIJdsdHPg9QifUsDe/M/ann6vroEPqIL/7WQIs9cfbLMVC9RNkUwqou
KXdJqLKEs9d5ys0cwNnA1CD5BP3pGrYE9PfJXeGFngM4lGJR+AsOzVladGOR
K1qLLJd2GAoudcXA66Z47zIgNibsrIGObXhjy/MODNmGQOyp4vqQATD5QrXy
enVHt+sm47SRy892uyuu/goim2Odr1yj/+9Xdz9xyb5e6L96oEs1L7wDo4uW
rx5IVck/ihvHdIPVPvdHSp/pfkfk/DVE391t29/WbutQYkO3LVK87W+7dJ+Q
FRsGFzQbidzCsW1/n+HkdpZs8YVs0ZwjDJwe+cHzglLC6Hidc9Wa22Rv8inm
o9IARF9JxZl+utLSZYwF1jri5PS1lEjRyeQ5tsnUrbPFw9hlWH9aSfFpU0e9
54lGb06by8XGHTmD6lNE2ysamzLA/0ZHNzoN4Ysg8vUreazUlzbQYG2Ca+CE
sNAgH9nWNdBteN7cnXLGRZvp38lGYKoeiCPK5OC71zAH0Nc0RNeFy/XAezrO
D6Zv3Dh7XLt4m8uwkiEkS5BWUZYfY403F1fXHlA83KO0pL121IdoXs0YECSG
k89tUkqfC7vy6e4wGvFxt8qTovG1wRReXDrgR1HD9hrWJni9eP6UMvht+jdG
9HeW2u7pWBr19HFdZjFPpRjEmAAOHJ9wzi+ACgbZIUc/FN+pRDa5MwA8WWqT
JZrBbEZGSmcSBAVcNpiY2TTIvkMJqaZyMSKGryrfnJzRbWss0trdgu0UXEIg
sz7f505VCca8Km5ZUFbBCsAEZVNnkhJI6DKYM7bMLqU/TZgMlz9KbJYYIgGq
AbSTddbkZQx4R1qexpmeKM69vZsUJZPZtvTj34muFmJ11U6cjd6JioRXjItq
JnqeezZ3rLdpNT3KHphphnPUiIaoF6lN/fbZqFDCWtmMFqJoUQDALTk9xdXJ
lLacBmiTKHXisvHene83bdaRBXdsb1lDVjWD37wqTEVVmbKMF2xafCpYrmwR
oUuJja+XC4hjkJay91dDBS/U5tcmzOlBx3pD0ftrcjl5XL8t5bOX37/76clf
ztTtzZ8R05SzLP+Y3y6fvxsvzr7/261OT95OTnr9doCGp0PxzcGTb57u7+8H
bzeyeCie7j9+vr/PzT7xoqMLSlFIEk6S9IlYOlEOpBMzD/cPrK2idPZKVrVp
uUgHi47LsFHwDW3me2guGVk67X7tS4Ws5llddcbApTTwNGoD+HcDGUedT9ik
w8q0yVhuUyFy8R9XF+fOVAzbXaaU972DwUG4tPvsITXx5A8FFeMN9/YCOVgV
nL0nT5+tbbxOad/xpnff7br3ptvdoeGxGb1wl08nTbgligRsZi1zDxqG7Tx+
+5Z06Mnbt7ucANNspsseIZaUxaJk749f44xUkp23Ne1U8fjpE29HX1Bayyau
P97fF9/JtHF1d3PeTfNogxb1KrSm5XJd5MpecP4VDxHzMlt29xgGUb93iEmb
SDtwZalO84cuhYsgTNBX5/w05tbE65+Dzd341yN8QLORyvc/0xbCaHh7e3PN
GUlUMwQaqI6sIbB31yCfxC/hzhPSeFO43KiZ2gw1ZqrVqDV1Ix2n3Jqx4mtj
zj31uVepllkxXUdk1g14QBbYWs4qdpnZcD2cQscJPk52haxc1YDw6cTsiFmi
STZ7C5UT+uBsXgfCehMIoErte2fNeruB6NFN3kblZLm8y7Jb7cmdjvjMT74+
b5IFb2eYnVfRyhxjGnApCy9VWwsLRnB+vj8Kofs5sXPxw26rjN4JeqAiOapZ
xvaoJzSeXGdTT6ckxJJp45RL8nogyAM+ixOdoQ2HQhs4VSZnzMnARKpLXrO4
wMKCaqWfI4EjBk7F7zc5ngyGqTgTdJUwF6YhSLpSSDYoM1XjHZ028d2OO+CB
6SPrBMH/EMspECJV+sVHFpNHrjxBZoaz4tzULtvWFY/YFZlMT2cUr5g5XZk3
GYwbVr/ZN+yLix/u6xaCIYfiwHrYDuFDv54/vdjmEr7GIXCIQDaO7BSNApf2
LD44iA8Or/cPht88H+6/+Mv9YUPrQbyahbbkJ5/ZVyx8PiCJuVW4SU1XmF63
0yBL1BoDByjuYPUqW1pivE73xd4eK7lT+LZtwKNvnj7p80O0bbBygw2ChDZI
ayqX5jMmGaMsCkMZqpTNb4wVoyak2bhlJnRKiWwsSlFO98Jme6MnB6NvOjy+
5mzHcKjQJEKWOJ1Shsire+YKk+MzJPv+KDhdSby88rj3dANbJlzszInHOW0b
OaSO5WqhYc/uXK+xWv0WGjqoCDzemGcuHGl83Pq6bDA8q+fMYJfRbDHKnM5t
uXKCDu1LmWO+smq+hNI9nvaHDeBmKSdUnXf/I4PGENLhhEoa8GMrlrkonA0Z
qwDnJFL+Ldl5X8slbW0Pj2PqBdNJvYF5DEgZtRU5xG0Lm54ePKOI2BUKC6o3
gSNeZMWSq8MicgQLW2HuS3vibmmPLeMkLtwWMXzcFM8uRj9ev+JCqqPj81Px
oyFjaugrKmdqPiag4ySIC+C4zc62yj5bLdWWie7yx2dox/gDNFyYw4yxgT7p
lnO1+TQKyqdpeSvVflRAzkWnuvSlMLYmTnLxvausivgIgwuzXIXVHR/GAAbl
uJQ/KQCSIkN8hTP05f3G5So0R03aJLXh6orbIsxTDwmKXLTBtH+oOlc+3bK9
M4SfGvIg3kgqwFeZx13EfMAJ3mD+foAFZecXrvA60+9V5zscK6yTzDyqRaKa
7LmfxrOQ0RWNM4OXgrzrpgp9vdRfcKl/xNLdHnuQKaAzBR6S1ap9N1XAMXIx
o3QV1xCz8rmcyklZjT1+8R9HEDlMQGlLMAABqNSIDiX8xy5CAcYGEbytqHLU
ARYi2h5DcDkAnbQdXV32G52l93TWQ/Xi5Pbp1CsiehXMFk/U/UaFRfmdCh4a
s7jN3UGCq7icSb5Za4Ey75jNWXKffGi/s+E+vwFadoPye6u/XNxqDwYjiNLU
fuuAvpdwsOs/UkISRQiw7csIxkMWvxtUdtun7oe2OrvZUOE/t1DzlmTW+Mz0
wlotmstyjH5Ftosr8t3c/LC1QjSJqw6mWp5cUKZQJMdUOcItrbfqlgE2B2ww
Vzes4KFEkKmk0hNbiEYmw0R50VSeeHNJYkfpREQ0i4qrFGoxN/szIoL4RR+9
4EqCtpmvF/RlEHZlP7kCJv7wCoN9V5zEwkM2hrKWbhQHQuOlP2CioT2fTceX
uO8gsI1tfBGVcdMHPJwjaI6gmzPwrgvYxEV3Pt1+wYKjHa6l6NQx81d2XGhH
BWIPTVMVxoJS2hQx+HY6EnRDya4HwhY0MebAgbzGsJwfH9kScWf5vXJyFhqX
VK1ZwIcmWpmBXSEvqakL4fsErjKrtZk1PG1sDVV0mFbXqYsdxZgi4eOH1ixd
huil4PJNUqOobeEuigdiNCc+WF0eq1xNdMVRmRcBExLovo9jrzSiLkaic5T2
BsB/ZYRy4YBb+JMDgATu0JKlY5SQ9gAGTa0rsXcR7FkpgiI54hxApwJtEdhJ
TVhD0tcB5nwmwBl1EK/oFV004F+H+4f78MKSttYbeKjgQDx9/vzx4YE4A96q
rQtjho7KZKYJ2+BhZAvMzvgrPfRFlLT5dpzYORudne56R+lUsz1A568+AGoW
peGx3Qd/SONowce+9PuVpg94LaPo55/tgXFB38YSJ6mu6Nqs+XwOX526nMYg
dWDwyy+sQvf4eh6lItDXC/xHM2wGBH0pomxOE+g+gAslu3iNIlBV8tcGqID2
rP3uD7W1GJSN/+B+xBwwMUVJV2b2Cyz8IQOs/afvbe97DrTPCZN845b5e5BA
6egyC1DEfXCHreK2IfdhsP8PZc8/8QtRAAA=

-->

</rfc>

