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

<!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 ipr="trust200902" docName="draft-sheffer-lurk-cert-delegation-00" category="std">

  <front>
    <title abbrev="TLS Certificate Delegation">Delegating TLS Certificates to a CDN</title>

    <author initials="Y." surname="Sheffer" fullname="Yaron Sheffer">
      <organization>Intuit</organization>
      <address>
        <email>yaronf.ietf@gmail.com</email>
      </address>
    </author>

    <date year="2016" month="May" day="12"/>

    <area>General</area>
    
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>An organization that owns web content often prefers to delegate hosting of this content
to a Content Delivery Network (CDN). To serve HTTP content securely, it needs to be
protected with TLS. This document proposes a way for the CDN
to request constrained certificates so that it can serve web content on behalf
of the content owner, without having the owner’s
long term certificate.</t>



    </abstract>


  </front>

  <middle>


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

<t>Content owners frequently prefer a Content Delivery Network (CDN)
to host their content. CDNs typically have very large networks, and are designed
to serve content to a global audience with a high aggregate bandwidth.</t>

<t>To protect this traffic, the CDN uses HTTPS and presents a certificate that
usually bears the content owner’s name. However, many content owners
balk at sharing their long-term private keys with another organization.</t>

<t>This document proposes a way for the CDN to obtain
short-term credentials (an end-entity certificate along with the associated private key),
allowing the content owner to revoke this authority at short
notice.</t>

<t>We note that there are other solutions to this problem:</t>

<t><list style="symbols">
  <t>The CDN
could contact the content owner on each TLS handshake and have the content
owner take part in completing the TLS handshake. Such a solution is described in
e.g. <xref target="I-D.cairns-tls-session-key-interface"/>.</t>
  <t>We could extend ACME <xref target="I-D.ietf-acme-acme"/> by allowing the content owner to share an authorization
“ticket” with the CDN, the CDN then using it to obtain short-term
certificates directly from the ACME server. This alternative is possibly easier
to deploy than the one described in this document, but
it would require a non-trivial change to the ACME protocol.</t>
  <t>The current proposal has the content owner generate the certificate’s private key,
although the best practice would have the CDN generate it and create a Certificate
Signing Request (CSR). Note however that it would be difficult for the content owner to validate the
correctness of a CSR,
potentially allowing a malicious CDN to obtain fraudulent certificates.</t>
</list></t>

<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”, “MAY”, and “OPTIONAL” in this document are to be
interpreted as described in <xref target="RFC2119" />.</t>

</section>
</section>
<section anchor="overview" title="Overview">

<t>We define the interaction between the CDN and the content owner, where the CDN
requests a short-term certificate periodically, and the content owner obtains it
on the CDN’s behalf and returns it to the CDN.</t>

<t>We expect the content owner to use the ACME protocol to obtain a short-term certificate,
but this is not strictly required by the protocol.</t>

<section anchor="advantages" title="Advantages">

<t><list style="symbols">
  <t>Compared with solutions that require the CDN to have the content owner sign each
handshake, this solution does not require the content owner to set up its own
scalable infrastructure.</t>
  <t>Moreover, the need to scale the content owner’s web service could result in the content
owner ending up by sharing the private keys with the CDN and abdicating its responsibility
for its own security.</t>
</list></t>

</section>
</section>
<section anchor="lurk-operations" title="LURK Operations">

<t>This section lists the REST APIs that the content owner needs to provide to the CDN.</t>

<section anchor="request-a-certificate" title="Request a Certificate">

<figure><artwork><![CDATA[
POST /.well-known/lurk/certificate/1234 HTTP/1.1
Content-Type: application/json

{
    "password":"fb2831d6607124286a7b439f2f09793a"
}
]]></artwork></figure>

<t>There is no negotiation of key type (RSA or ECDSA), key length or validity dates,
and the client and server
must coordinate these details in advance.
Similarly, the server MUST be able to determine the FQDN to be included in the certificate
based on the authenticated client’s identity.</t>

<t>The URI contains a request ID, which MAY be sequential or generated randomly
by the client.</t>

<t>The given password MUST be randomly generated and SHOULD
have at least 128-bits of entropy.</t>

<t>The server responds with one of:</t>

<t><list style="symbols">
  <t>A “200 OK” status code, and response body containing a PKCS #12 <xref target="RFC7292"/> structure
(private key and certificate), with the content type:
<spanx style="verb">application/x-pkcs12</spanx>.
The structure is protected by the given password.</t>
  <t>A “201 Accepted” status code if the certificate is not yet ready. The CDN should poll
the content owner periodically (see below), but not more often than once every 5 seconds.</t>
  <t>Other responses if the request is not acceptable or not allowed.</t>
</list></t>

</section>
<section anchor="poll-for-a-certificate" title="Poll for a Certificate">

<figure><artwork><![CDATA[
GET /.well-known/lurk/certificate/1234 HTTP/1.1
]]></artwork></figure>

<t>The server responds with one of:</t>

<t><list style="symbols">
  <t>A “200 OK” status code, and response body containing the PKCS #12 response, with the content type:
<spanx style="verb">application/x-pkcs12</spanx>.</t>
  <t>A “204 No Content” status code if the certificate is not yet ready.</t>
  <t>Other responses if the request is not acceptable or not allowed.</t>
</list></t>

<t>Access to these resources MUST be protected by TLS.</t>

<t>Both requests MUST be authenticated, using one of the following methods:</t>

<t><list style="symbols">
  <t>Mutual TLS authentication with a client certificate. This is the RECOMMENDED option.</t>
  <t>TLS with preshared secret authentication or TLS-SRP.</t>
  <t>TLS with HTTP-Basic or Digest authentication.</t>
</list></t>

<t>The client cannot assume that the sever will cache the certificate beyond a few seconds
after it is first fetched.</t>

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

<t>This section presents additional considerations beyond those strictly required by the protocol.</t>

<section anchor="certificate-details" title="Certificate Details">

<t><list style="symbols">
  <t>It is RECOMMENDED to restrict the certificate’s scope as much as possible.
Specifically, the certificate request SHOULD specify restrictive Key Usage.</t>
  <t>The certificate SHOULD NOT be for a wildcard DN.</t>
  <t>The RECOMMENDED validity period for certificates provisioned using this
mechanism is 3 days, and the certificate SHOULD be valid immediately when it is fetched.</t>
</list></t>

</section>
<section anchor="revocation" title="Revocation">

<t>When the content owner decides it no longer trusts the CDN, the content owner MUST:</t>

<t><list style="symbols">
  <t>Revoke any extant short-term certificates already handed to the CDN. This implies
that all such certificates MUST be logged.</t>
  <t>Immediately block the certificate issuance operations described above.</t>
</list></t>

</section>
<section anchor="restricting-cdns-to-the-delegation-mechanism" title="Restricting CDNs to the Delegation Mechanism">

<t>Currently there are no standard methods for the content owner to ensure that
the CDN cannot issue a certificate through mechanisms other than the one described here,
for the URLs under the CDN’s control.
The best solution currently being worked on would consist of several related
configuration steps:</t>

<t><list style="symbols">
  <t>Make sure that the CDN cannot modify the DNS records for the domain.
 Typically this would mean that the content owner establishes a CNAME resource record
 from a subdomain into a CDN-managed domain.</t>
  <t>Restrict certificate issuance for the domain to specific CAs that comply
 with ACME. This assumes
 universal deployment of CAA <xref target="RFC6844"/> by CAs, which is not the case yet.</t>
  <t>Deploy ACME-specific methods to restrict issuance to a specific authorization
 key which is controlled by the content owner <xref target="I-D.landau-acme-caa"/>.</t>
</list></t>

<t>This solution is recommended in general, even if an alternative to the
mechanism described here (e.g. <xref target="I-D.cairns-tls-session-key-interface"/>) is used.</t>

</section>
</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor='RFC2119' target='http://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='RFC7292' target='http://www.rfc-editor.org/info/rfc7292'>
<front>
<title>PKCS #12: Personal Information Exchange Syntax v1.1</title>
<author initials='K.' surname='Moriarty' fullname='K. Moriarty' role='editor'><organization /></author>
<author initials='M.' surname='Nystrom' fullname='M. Nystrom'><organization /></author>
<author initials='S.' surname='Parkinson' fullname='S. Parkinson'><organization /></author>
<author initials='A.' surname='Rusch' fullname='A. Rusch'><organization /></author>
<author initials='M.' surname='Scott' fullname='M. Scott'><organization /></author>
<date year='2014' month='July' />
<abstract><t>PKCS #12 v1.1 describes a transfer syntax for personal identity information, including private keys, certificates, miscellaneous secrets, and extensions.  Machines, applications, browsers, Internet kiosks, and so on, that support this standard will allow a user to import, export, and exercise a single set of personal identity information.  This standard supports direct transfer of personal information under several privacy and integrity modes.</t><t>This document represents a republication of PKCS #12 v1.1 from RSA Laboratories' Public Key Cryptography Standard (PKCS) series.  By publishing this RFC, change control is transferred to the IETF.</t></abstract>
</front>
<seriesInfo name='RFC' value='7292'/>
<seriesInfo name='DOI' value='10.17487/RFC7292'/>
</reference>




    </references>

    <references title='Informative References'>





<reference  anchor='RFC6844' target='http://www.rfc-editor.org/info/rfc6844'>
<front>
<title>DNS Certification Authority Authorization (CAA) Resource Record</title>
<author initials='P.' surname='Hallam-Baker' fullname='P. Hallam-Baker'><organization /></author>
<author initials='R.' surname='Stradling' fullname='R. Stradling'><organization /></author>
<date year='2013' month='January' />
<abstract><t>The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain. CAA Resource Records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue.  This document defines the syntax of the CAA record and rules for processing CAA records by certificate issuers. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6844'/>
<seriesInfo name='DOI' value='10.17487/RFC6844'/>
</reference>



<reference anchor='I-D.landau-acme-caa'>
<front>
<title>ACME Account Key Binding via CAA Records</title>

<author initials='H' surname='Landau' fullname='Hugo Landau'>
    <organization />
</author>

<date month='April' day='21' year='2016' />

<abstract><t>The ACME protocol provides a means for hosts to automatically request and obtain X.509 certificates from certificate authorities. Certification authorities which implement ACME may also choose to implement the CAA DNS record, which allows a domain to communicate issuance policy to CAs.  The CAA specification alone allows a domain to define policy with CA-level granularity.  However, the CAA specification also provides facilities for extension to admit more granular, CA-specific policy.  This specification defines such a parameter.</t></abstract>

</front>

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



<reference anchor='I-D.cairns-tls-session-key-interface'>
<front>
<title>Session Key Interface (SKI) for TLS and DTLS</title>

<author initials='K' surname='Cairns' fullname='Kelsey Cairns'>
    <organization />
</author>

<author initials='J' surname='Mattsson' fullname='John Mattsson'>
    <organization />
</author>

<author initials='R' surname='Skog' fullname='Robert Skog'>
    <organization />
</author>

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

<date month='October' day='19' year='2015' />

<abstract><t>This document describes a session key interface that can be used for TLS and DTLS.  The Heartbleed attack has clearly illustrated the security problems with storing private keys in the memory of the TLS server.  Hardware Security Modules (HSM) offer better protection but are inflexible, especially as more (D)TLS servers are running on virtualized servers in data centers.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-cairns-tls-session-key-interface-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-cairns-tls-session-key-interface-01.txt' />
</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='J' surname='Kasten' fullname='James Kasten'>
    <organization />
</author>

<date month='March' day='21' year='2016' />

<abstract><t>Certificates in the Web's X.509 PKI (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 certificate 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.</t></abstract>

</front>

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




    </references>


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

<section anchor="draft-sheffer-lurk-cert-delegation-00" title="draft-sheffer-lurk-cert-delegation-00">

<t>Initial version.</t>

</section>
</section>


  </back>
</rfc>

