Use of Short-Term, Automatically-Renewed (STAR) Certificates to address the LURK problem
draft-sheffer-acme-star-lurk-00

Document Type Active Internet-Draft (individual)
Last updated 2016-10-25
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
ACME Working Group                                            Y. Sheffer
Internet-Draft                                                    Intuit
Intended status: Standards Track                                D. Lopez
Expires: April 28, 2017                              O. Gonzalez de Dios
                                                          Telefonica I+D
                                                              T. Fossati
                                                                   Nokia
                                                        October 25, 2016

Use of Short-Term, Automatically-Renewed (STAR) Certificates to address
                            the LURK problem
                    draft-sheffer-acme-star-lurk-00

Abstract

   This memo proposes two mechanisms that work in concert to address the
   LURK problem statement, allowing a third party (e.g., a content
   delivery network) to terminate TLS sessions on behalf of a domain
   name owner (e.g., a content provider).

   The proposed mechanisms are:

   1.  An extension to the ACME protocol to enable the issuance of
       short-term and automatically renewed certificates, and
   2.  A protocol that allows a domain name owner to delegate to a third
       party control over a certificate that bears its own name.

   It should be noted that these are in fact independent building blocks
   that could be used separately to solve completely different problems.

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 http://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 April 28, 2017.

Sheffer, et al.          Expires April 28, 2017                 [Page 1]
Internet-Draft               ACME STAR LURK                 October 2016

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://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.  A Solution for the HTTPS CDN Use Case . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   3
   3.  Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Preconditions . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Bootstrap . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.3.  Refresh . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.4.  Termination . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
     4.1.  Restricting CDNs to the Delegation Mechanism  . . . . . .   8
   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   9
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  A Solution for the HTTPS CDN Use Case

   A content provider, and Domain Name Owner (DNO), has agreements in
   place with one or more Content Delivery Networks (CDN) 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, CDN providers would
   rather not have to handle other parties' long-term secrets.  This
   problem has been discussed at the IETF under the LURK (limited use of
Show full document text