draft-ietf-acme-star-00.txt   draft-ietf-acme-star-01.txt 
ACME Working Group Y. Sheffer ACME Working Group Y. Sheffer
Internet-Draft Intuit Internet-Draft Intuit
Intended status: Standards Track D. Lopez Intended status: Standards Track D. Lopez
Expires: December 18, 2017 O. Gonzalez de Dios Expires: May 16, 2018 O. Gonzalez de Dios
A. Pastor Perales A. Pastor Perales
Telefonica I+D Telefonica I+D
T. Fossati T. Fossati
Nokia Nokia
June 16, 2017 November 12, 2017
Use of Short-Term, Automatically-Renewed (STAR) Certificates to Delegate Support for Short-Term, Automatically-Renewed (STAR) Certificates in
Authority over Web Sites Automated Certificate Management Environment (ACME)
draft-ietf-acme-star-00 draft-ietf-acme-star-01
Abstract Abstract
This memo proposes an ACME extension to enable the issuance of short- This memo proposes an ACME extension to enable the issuance of short-
term and automatically renewed certificates. This allows a domain term and automatically renewed certificates.
name owner to delegate the use of certificates to another party,
while retaining the capability to cancel this delegation at any time
with no need to rely on certificate revocation mechanisms.
[RFC Editor: please remove before publication] [RFC Editor: please remove before publication]
While the draft is being developed, the editor's version can be found While the draft is being developed, the editor's version can be found
at https://github.com/yaronf/I-D/tree/master/STAR. at https://github.com/yaronf/I-D/tree/master/STAR.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 45 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 18, 2017. This Internet-Draft will expire on May 16, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction: A Solution for the HTTPS CDN Use Case . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Cloud Use Case . . . . . . . . . . . . . . . . . . . . . 3 1.1. Name Delegation Use Case . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Conventions used in this document . . . . . . . . . . . . 4 1.3. Conventions used in this document . . . . . . . . . . . . 4
2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Refresh . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Refresh . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Termination . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Termination . . . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 7 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 7
3.1. ACME Extensions between Proxy and Server . . . . . . . . 7 3.1. ACME Extensions . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Extending the Order Resource . . . . . . . . . . . . 7 3.1.1. Extending the Order Resource . . . . . . . . . . . . 7
3.1.2. Canceling a Recurrent Order . . . . . . . . . . . . . 8 3.1.2. Canceling a Recurrent Order . . . . . . . . . . . . . 8
3.2. Indicating Support of Recurrent Orders . . . . . . . . . 8 3.2. Indicating Support of Recurrent Orders . . . . . . . . . 9
3.3. ACME Authorization . . . . . . . . . . . . . . . . . . . 8 3.3. Fetching the Certificates . . . . . . . . . . . . . . . . 9
3.4. Fetching the Certificates . . . . . . . . . . . . . . . . 9 4. Operational Considerations . . . . . . . . . . . . . . . . . 10
4. Operational Considerations . . . . . . . . . . . . . . . . . 9 4.1. Certificate Transparency (CT) Logs . . . . . . . . . . . 10
4.1. Certificate Transparency (CT) Logs . . . . . . . . . . . 9 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Restricting CDNs to the Delegation Mechanism . . . . . . 9 5.1.1. ACME Server with STAR extension . . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 5.1.2. Proxy STAR . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Level of Maturity . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 10 5.3. Coverage . . . . . . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 10 5.4. Version Compatibility . . . . . . . . . . . . . . . . . . 12
Appendix A. Document History . . . . . . . . . . . . . . . . . . 12 5.5. Licensing . . . . . . . . . . . . . . . . . . . . . . . . 12
A.1. draft-ietf-acme-star-00 . . . . . . . . . . . . . . . . . 12 5.6. Implementation experience . . . . . . . . . . . . . . . . 12
A.2. draft-sheffer-acme-star-02 . . . . . . . . . . . . . . . 12 5.7. Contact Information . . . . . . . . . . . . . . . . . . . 13
A.3. draft-sheffer-acme-star-01 . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
A.4. draft-sheffer-acme-star-00 . . . . . . . . . . . . . . . 12 6.1. New ACME Error Types . . . . . . . . . . . . . . . . . . 13
A.5. draft-sheffer-acme-star-lurk-00 . . . . . . . . . . . . . 12 6.2. New ACME Order Object Fields . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction: A Solution for the HTTPS CDN Use Case 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14
A content provider (referred to in this document as Domain Name 9.2. Informative References . . . . . . . . . . . . . . . . . 14
Owner, DNO) has agreements in place with one or more Content Delivery Appendix A. Document History . . . . . . . . . . . . . . . . . . 16
Networks (CDNs) that are contracted to serve its content over HTTPS. A.1. draft-ietf-acme-star-01 . . . . . . . . . . . . . . . . . 16
The CDN terminates the HTTPS connection at one of its edge cache A.2. draft-ietf-acme-star-00 . . . . . . . . . . . . . . . . . 16
servers and needs to present its clients (browsers, set-top-boxes) a A.3. draft-sheffer-acme-star-02 . . . . . . . . . . . . . . . 16
certificate whose name matches the authority of the URL that is A.4. draft-sheffer-acme-star-01 . . . . . . . . . . . . . . . 16
requested, i.e. that of the DNO. However, many DNOs balk at sharing A.5. draft-sheffer-acme-star-00 . . . . . . . . . . . . . . . 16
their long-term private keys with another organization and, equally, A.6. draft-sheffer-acme-star-lurk-00 . . . . . . . . . . . . . 16
CDN providers would rather not have to handle other parties' long- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
term secrets. This problem has been discussed at the IETF under the
LURK (limited use of remote keys) title.
This document proposes a solution to the above problem that involves 1. Introduction
the use of short-term certificates with a DNO's name on them, and a
scheme for handling the naming delegation from the DNO to the CDN.
The generated short-term credentials are automatically renewed by an
ACME Certification Authority (CA) [I-D.ietf-acme-acme] and routinely
rotated by the CDN on its edge cache servers. The DNO can end the
delegation at any time by simply instructing the CA to stop the
automatic renewal and let the certificate expire shortly thereafter.
Using short-term certificates makes revocation cheap and effective The ACME protocol [I-D.ietf-acme-acme] automates the process of
[Topalovic] [I-D.iab-web-pki-problems] in case of key compromise or issuing a certificate to a Domain Name Owner (DNO). However, if the
of termination of the delegation; seamless certificate issuance and DNO wishes to obtain a string of short-term certificates originating
renewal enable the level of workflow automation that is expected in from the same private key (see [Topalovic] for the rationale), she
today's cloud environments. Also, compared to other keyless-TLS must go through the whole ACME protocol each time a new short-term
solutions [I-D.cairns-tls-session-key-interface] certificate is needed - e.g., every 2-3 days. If done this way, the
[I-D.erb-lurk-rsalg], the proposed approach doesn't suffer from process would involve frequent interactions between the registration
scalability issues or increase in connection setup latency, while function of the ACME Certification Authority (CA) and the user's
requiring virtually no changes to existing COTS caching software used backing infrastructure (e.g.: DNS, web servers), therefore making the
by the CDN. issuance of short-term certificates exceedingly dependent on the
reliability of both.
This document describes the ACME extension. A companion document [I- This document presents an extension of the ACME protocol that
D.sheffer-acme-star-request] describes how the CDN can request the optimizes this process by making short-term certificates first class
DNO to initiate the protocol with the ACME server. objects in the ACME ecosystem. Once the order for a string of short-
term certificates is accepted, the CA is responsible for publishing
the next certificate at an agreed upon URL before the previous one
expires. The DNO can terminate the automatic renewal before the
natural deadline, if needed - e.g., on key compromise.
1.1. Cloud Use Case For a more generic treatment of STAR certificates, readers are
referred to [I-D.nir-saag-star].
A similar use case is that of cloud infrastructure components, such 1.1. Name Delegation Use Case
as load balancers and Web Application Firewalls (WAF). These
components are typically provisioned with the DNO's certificate, and
similarly to the CDN use case, many organizations would prefer to
manage the private key only on their own cloud-based or on-premise
hosts, often on Hardware Security Modules (HSMs).
Here again, the STAR solution allows the DNO to delegate authority The proposed mechanism can be used as a building block of an
over the domain to the cloud provider, with the ability to revoke efficient name-delegation protocol, for example one that exists
this authority at any time. between a CDN or a cloud provider and its users
[I-D.sheffer-acme-star-request], in a way that makes the delegator
(i.e., the DNO) in full control of the delegation by simply
instructing the CA to stop the automatic renewal and letting the
currently active certificate expire shortly thereafter.
1.2. Terminology 1.2. Terminology
DNO Domain Name Owner, the owner of a domain that needs to be DNO Domain Name Owner, the owner of a domain.
delegated.
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).
CDN Content Delivery Network, a widely distributed network that
serves the domain's web content to a wide audience at high
performance.
STAR Short-Term, Automatically Renewed X.509 certificates. STAR Short-Term, Automatically Renewed X.509 certificates.
ACME The IETF Automated Certificate Management Environment, a NDC Name Delegation Client, an entity to which the domain name owned
certificate management protocol. by the DNO is delegated for a limited time. This might be a CDN
CA A Certificate Authority that implements the ACME protocol. edge cache, a cloud provider's load balancer or Web Application
Firewall (WAF).
1.3. Conventions used in this document 1.3. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
2. Protocol Flow 2. Protocol Flow
For clarity, we describe how the proposed ACME extension can be used
in a system that consists of an NDC, an ACME Client (the DNO) and an
ACME Server. Only the latter part (ACME Client to ACME Server) is in
scope of this document.
The protocol flow can be split into two: a STAR interface, used by
NDC and DNO to agree on the name delegation, and the extended ACME
interface, used by DNO to obtain the short-term and automatically
renewed certificate from the CA, which is eventually consumed by the
NDC. The latter is also used to terminate the delegation, if so
needed.
Communication between the NDC and the DNO (the STAR interface) is out
of scope of this document. It may take the form described in [I-
D.sheffer-acme-star-request], some other online protocol, or may even
be through manual generation of the CSR.
The following subsections describe the three main phases of the The following subsections describe the three main phases of the
protocol: protocol:
o Bootstrap: the DNO asks an ACME CA to create a corresponding o Bootstrap: the DNO asks an ACME CA to create a short-term and
short-term and auto-renewed (STAR) certificate, possibly on a automatically-renewed (STAR) certificate (Section 2.1);
request from an NDC which is out of scope for this document;
o Auto-renewal: the ACME CA periodically re-issues the short-term o Auto-renewal: the ACME CA periodically re-issues the short-term
certificate and posts it to a public URL (Section 2.2); certificate and posts it to a public URL (Section 2.2);
o Termination: the DNO (indirectly) stops name delegation by o Termination: the DNO requests the ACME CA to discontinue the
explicitly requesting the ACME CA to discontinue the automatic automatic renewal of the certificate (Section 2.3).
renewal of the certificate (Section 2.3).
This diagram presents the entities involved in the protocol and their This diagram presents the entities that are (or may be) involved in
interactions during the different phases. the protocol and their interactions during the different phases.
+-----------------+ Refresh
| STAR Proxy | . . . . . . . . . . . . . . . . . . . .
| (DNO) | . ' ` v
Bootstrap +-----------------+ Bootstrap .-----. Bootstrap / Terminate .---------.
+---------->+ STAR | ACME +-----------+ | DNO |------------------------------------->| ACME CA |
| | Server | Client | Terminate | `-----' `---------'
| +--------+--------+ | ^ .- - -. ^
| v ` . . . . . . . . : NDC : . . . . . . . . . '
+--------+ +--------+ Request `- - -' Refresh
| STAR | Refresh | ACME | Delegation
| Client +------------------------------->| Server |
| (NDC) | | (CA) | Note that there might be a distinct NDC entity (e.g., a CDN edge
+--------+ +--------+ cache) that uses a separate channel to request the DNO to set up a
name delegation. The protocol described in
[I-D.sheffer-acme-star-request] might be used for this purpose.
2.1. Bootstrap 2.1. Bootstrap
The DNO, in its role as an ACME client, requests the CA to issue a The DNO, in its role as an ACME client, requests the CA to issue a
STAR certificate, i.e., one that: STAR certificate, i.e., one that:
o Has a short validity (e.g., 24 to 72 hours); o Has a short validity (e.g., 24 to 72 hours);
o Is automatically renewed by the CA for a certain period of time; o Is automatically renewed by the CA for a certain period of time;
o Is downloadable from a (highly available) public link without o Is downloadable from a (highly available) public link without
requiring any special authorization. requiring any special authorization.
Other than that, the ACME protocol flows as normal between DNO and Other than that, the ACME protocol flows as normal between DNO and
CA, in particular DNO is responsible for satisfying the requested CA. In particular, DNO is responsible for satisfying the requested
ACME challenges until the CA is willing to issue the requested ACME challenges until the CA is willing to issue the requested
certificate. Per normal ACME processing, the DNO is given back an certificate. Per normal ACME processing, the DNO is given back an
Order ID for the issued STAR certificate to be used in subsequent Order ID for the issued STAR certificate to be used in subsequent
interaction with the CA (e.g., if the certificate needs to be interaction with the CA (e.g., if the certificate needs to be
terminated.) terminated.)
The bootstrap phase ends when the DNO obtains the OK from the ACME The bootstrap phase ends when the DNO obtains the OK from the ACME
CA. CA.
2.2. Refresh 2.2. Refresh
The CA automatically re-issues the certificate (using the same CSR) 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 (and therefore the same name and public key) before it expires and
to know at the end of the bootstrap phase. The NDC downloads and publishes it to the URL that was returned to the DNO at the end of
installs it. This process goes on until either: the bootstrap phase. The certificate user, which could be either the
DNO itself or a delegated third party, as described in
[I-D.sheffer-acme-star-request], obtains the certificate and uses it.
The refresh process (Figure 1) goes on until either:
o DNO terminates the delegation, or o DNO terminates the delegation, or
o Automatic renewal expires. o Automatic renewal expires.
STAR ACME/STAR Certificate ACME/STAR
Client Server User Server
| Retrieve cert | [...] | Retrieve cert | [...]
|<--------------------->| | |---------------------->| |
| +------. / | +------. /
| | | / | | | /
| | Automatic renewal : | | Automatic renewal :
| | | \ | | | \
| |<-----' \ | |<-----' \
| Retrieve cert | | | Retrieve cert | |
|<--------------------->| 72 hours |---------------------->| 72 hours
| | | | | |
| +------. / | +------. /
| | | / | | | /
| | Automatic renewal : | | Automatic renewal :
| | | \ | | | \
| |<-----' \ | |<-----' \
| Retrieve cert | | | Retrieve cert | |
|<--------------------->| 72 hours |---------------------->| 72 hours
| | | | | |
| +------. / | +------. /
| | | / | | | /
| | Automatic renewal : | | Automatic renewal :
| | | \ | | | \
| |<-----' \ | |<-----' \
| | | | | |
| [...] | [...] | [...] | [...]
Figure 1: Auto renewal Figure 1: Auto renewal
2.3. Termination 2.3. Termination
The DNO may request early termination of the STAR certificate by The DNO may request early termination of the STAR certificate by
including the Order ID in a certificate termination request to the including the Order ID in a certificate termination request to the
ACME interface, defined below. After the CA receives and verifies ACME interface, defined below. After the CA receives and verifies
the request, it shall: the request, it shall:
o Cancel the automatic renewal process for the STAR certificate; o Cancel the automatic renewal process for the STAR certificate;
o Change the certificate publication resource to return an error o Change the certificate publication resource to return an error
indicating the termination of the delegation to external clients, indicating the termination of the delegation to any external
including the NDC. client.
Note that it is not necessary to explicitly revoke the short-term Note that it is not necessary to explicitly revoke the short-term
certificate. certificate.
STAR STAR ACME/STAR STAR STAR ACME/STAR
Client Proxy Server Client Proxy Server
| | | | | |
| | Terminate Order ID | | | Terminate Order ID |
| +---------------------->| | +---------------------->|
| | +-------. | | +-------.
skipping to change at page 7, line 36 skipping to change at page 7, line 30
| Retrieve cert | | Retrieve cert |
+---------------------------------------------->| +---------------------------------------------->|
| Error: terminated | | Error: terminated |
|<----------------------------------------------+ |<----------------------------------------------+
| | | |
Figure 2: Termination Figure 2: Termination
3. Protocol Details 3. Protocol Details
This section describes the protocol's details, namely the extensions This section describes the protocol details, namely the extensions to
to the ACME protocol required to issue STAR certificates. the ACME protocol required to issue STAR certificates.
3.1. ACME Extensions between Proxy and Server 3.1. ACME Extensions
This protocol extends the ACME protocol, to allow for recurrent This protocol extends the ACME protocol, to allow for recurrent
orders. orders.
3.1.1. Extending the Order Resource 3.1.1. Extending the Order Resource
The Order resource is extended with the following attributes: The Order resource is extended with the following attributes:
{ {
"recurrent": true, "recurrent": true,
"recurrent-total-lifetime": 365, // requested lifetime of the "recurrent-start-date": "2016-01-01T00:00:00Z",
// recurrent registration, in days "recurrent-end-date": "2017-01-01T00:00:00Z",
"recurrent-certificate-validity": 7 "recurrent-certificate-validity": 604800
// requested validity of each certificate, in days }
}
o recurrent: MUST be "true" for STAR certificates.
o recurrent-start-date: the earliest date of validity of the first
certificate issued, in [RFC3339] format. This attribute is
optional. When omitted, the start date is as soon as
authorization is complete.
o recurrent-end-date: the latest date of validity of the last
certificate issued, in [RFC3339] format.
o recurrent-certificate-validity: the maximum validity period of
each STAR certificate, an integer that denotes a number of
seconds.
These attributes are included in a POST message when creating the These attributes are included in a POST message when creating the
order, as part of the "payload" encoded object. They are returned order, as part of the "payload" encoded object. They are returned
when the order has been created, and the ACME server MAY adjust them when the order has been created, and the ACME server MAY adjust them
at will, according to its local policy. at will, according to its local policy.
ACME defines the following values for the Order resource's status:
"invalid", "pending", "processing", "valid". In the case of
recurrent orders, the status MUST be "valid" as long as STAR
certificates are being issued. We add a new status value,
"canceled", see below.
3.1.2. Canceling a Recurrent Order 3.1.2. Canceling a Recurrent Order
An important property of the recurrent Order is that it can be An important property of the recurrent Order is that it can be
cancelled by the domain name owner, with no need for certificate canceled by the DNO, with no need for certificate revocation. To
revocation. We use the DELETE message to cancel the Order: cancel the Order, the ACME client sends a POST:
DELETE /acme/order/1 HTTP/1.1 POST /acme/order/1 HTTP/1.1
Host: acme-server.example.org Host: acme-server.example.org
Content-Type: application/jose+json
Which returns: {
"protected": base64url({
HTTP/1.1 202 Deleted "alg": "ES256",
"kid": "https://example.com/acme/acct/1",
"nonce": "5XJ1L3lEkMG7tR6pA00clA",
"url": "https://example.com/acme/order/1"
}),
"payload": base64url({
"status": "canceled"
}),
"signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g"
}
The server MUST NOT issue any additional certificates for this Order, The server MUST NOT issue any additional certificates for this Order,
beyond the certificate that is available for collection at the time beyond the certificate that is available for collection at the time
of deletion. of deletion. Immediately after the Order is canceled, the server
SHOULD respond with 403 (Forbidden) to any requests to the
certificate endpoint. The response SHOULD provide additional
information using a problem document [RFC7807] with type
"urn:ietf:params:acme:error:recurrentOrderCanceled".
3.2. Indicating Support of Recurrent Orders 3.2. Indicating Support of Recurrent Orders
ACME supports sending arbitrary extensions when creating an Order, ACME supports sending arbitrary extensions when creating an Order,
and as a result, there is no need to explicitly indicate support of and as a result, there is no need to explicitly indicate support of
this extension. The Proxy MUST verify that the "recurrent" attribute this extension. The DNO MUST verify that the "recurrent" attribute
was understood, as indicated by the "recurrent" attribute included in was understood, as indicated by the "recurrent" attribute included by
the created Order. Since the standard ACME protocol does not allow the CA in the created Order. Since the standard ACME protocol does
to explicitly cancel a pending Order (the DELETE operation above is not allow to explicitly cancel a pending Order (the POST operation in
an extension), a Proxy that encounters an non-supporting server will Section 3.1.2 is an extension), a DNO that encounters an non-
probably let the Order expire instead of following through with the supporting server will probably let the Order expire instead of
authorization process. following through with the authorization process.
3.3. ACME Authorization 3.3. Fetching the Certificates
The DNO MUST restrict the authorizations it requests from the ACME The certificate is fetched from the certificate endpoint, as per
server to only those that cannot be spoofed by a malicious NDC. In [I-D.ietf-acme-acme], Section 7.4.2.
most cases the NDC will have strong control of HTTP content under the
delegated domain, and therefore HTTPS-based authorization MUST NOT be
used. See also Section 5.1.
3.4. Fetching the Certificates GET /acme/cert/asdf HTTP/1.1
Host: acme-server.example.org
Accept: application/pkix-cert
The certificate is fetched from the certificate endpoint, as per HTTP/1.1 200 OK
[I-D.ietf-acme-acme], Sec. 7.4.2 "Downloading the Certificate". The Content-Type: application/pem-certificate-chain
server MUST include an Expires header that indicates expiry of the Link: <https://example.com/acme/some-directory>;rel="index"
specific certificate. When the certificate expires, the client MAY Not-Before: Mon, 1 Feb 2016 00:00:00 GMT
assume that a newer certificate is already in place. Not-After: Mon, 8 Feb 2016 00:00:00 GMT
A certificate MUST be replaced by its successor at the latest halfway -----BEGIN CERTIFICATE-----
through its lifetime (the period between its notBefore and notAfter [End-entity certificate contents]
times). -----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[Issuer certificate contents]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[Other certificate contents]
-----END CERTIFICATE-----
The Server SHOULD include the "Not-Before" and "Not-After" headers.
When they exist, they MUST be equal to the respective fields inside
the certificate. Their format is "HTTP-date" as defined in
Section 7.1.1.2 of [RFC7231]. Their purpose is to enable client
implementations that do not parse the certificate.
To improve robustness, the next certificate MUST be made available by
the ACME CA at the latest halfway through the lifetime of the
currently active certificate. It is worth noting that this has an
implication in case of cancellation: in fact, from the time the next
certificate is made available, the cancellation is not completely
effective until the latter also expires.
The server MUST NOT issue any additional certificates for this Order
beyond its recurrent-end-date.
Immediately after the Order expires, the server SHOULD respond with
403 (Forbidden) to any requests to the certificate endpoint. The
response SHOULD provide additional information using a problem
document [RFC7807] with type
"urn:ietf:params:acme:error:recurrentOrderExpired".
4. Operational Considerations 4. Operational Considerations
4.1. Certificate Transparency (CT) Logs 4.1. Certificate Transparency (CT) Logs
TBD: larger logs and how to deal with them. TBD: larger logs and how to deal with them.
5. Security Considerations 5. Implementation Status
5.1. Restricting CDNs to the Delegation Mechanism Note to RFC Editor: please remove this section before publication,
including the reference to [RFC7942].
Currently there are no standard methods for the DNO to ensure that This section records the status of known implementations of the
the CDN cannot issue a certificate through mechanisms other than the protocol defined by this specification at the time of posting of this
one described here, for the URLs under the CDN's control. For Internet-Draft, and is based on a proposal described in [RFC7942].
example, regardless of the STAR solution, a rogue CDN employee can The description of implementations in this section is intended to
use the ACME protocol (or proprietary mechanisms used by various CAs) assist the IETF in its decision processes in progressing drafts to
to create a fake certificate for the DNO's content because ACME RFCs. Please note that the listing of any individual implementation
authorizes its requests using information that may be under the here does not imply endorsement by the IETF. Furthermore, no effort
adversary's control. has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
The best solution currently being worked on would consist of several According to [RFC7942], "this will allow reviewers and working groups
related configuration steps: to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
o Make sure that the CDN cannot modify the DNS records for the 5.1. Overview
domain. Typically this would mean that the content owner
establishes a CNAME resource record from a subdomain into a CDN-
managed domain.
o Restrict certificate issuance for the domain to specific CAs that
comply with ACME. This assumes universal deployment of CAA
[RFC6844] by CAs, which is not the case yet. We note that the CA/
Browser Forum has recently decided to require CAA checking
[CAB-CAA].
o Deploy ACME-specific methods to restrict issuance to a specific
authorization key which is controlled by the content owner
[I-D.ietf-acme-caa], and/or to specific ACME authorization The implementation is constructed around 3 elements: Client STAR for
methods. NDC, Proxy STAR for DNO and Server ACME for CA. The communication
between them is over an IP network and the HTTPS protocol.
This solution is recommended in general, even if an alternative to The software of the implementation is available at:
the mechanism described here is used. https://github.com/mami-project/lurk
6. Acknowledgments The following subsections offer a basic description, detailed
information is available in https://github.com/mami-
project/lurk/blob/master/proxySTAR_v1/README.md
5.1.1. ACME Server with STAR extension
This is a fork of the Let's Encrypt Boulder project that implements
an ACME compliant CA. It includes modifications to extend the ACME
protocol as it is specified in this draft, to support recurrent
orders and cancelling orders.
The implementation understands the new "recurrent" attributes as part
of the Certificate issuance in the POST request for a new resource.
An additional process "renewalManager.go" has been included in
parallel that reads the details of each recurrent request,
automatically produces a "cron" Linux based task that issues the
recurrent certificates, until the lifetime ends or the order is
canceled. This process is also in charge of maintaining a fixed URI
to enable the NDC to download certificates, unlike Boulder's regular
process of producing a unique URI per certificate.
5.1.2. Proxy STAR
The Proxy STAR, has a double role as ACME client and STAR Server.
The former is a fork of the EFF Certbot project that implements an
ACME compliant client with the STAR extension. The latter is a basic
HTTP REST API server.
The proxy STAR understands the basic API request with a server. The
current implementation of the API is defined in draft-sheffer-acme-
star-request-00. Registration or order cancellation triggers the
modified Certbot client that requests, or cancels, the recurrent
generation of certificates using the STAR extension over ACME
protocol. The URI with the location of the recurrent certificate is
delivered to the STAR client as a response.
5.2. Level of Maturity
This is a prototype.
5.3. Coverage
Client STAR is not included in this implementation, but done by
direct HTTP request with any open HTTP REST API tool. This is
expected to be covered as part of [I-D.sheffer-acme-star-request]
implementation.
This implementation completely covers Proxy STAR and Server ACME with
STAR extension
5.4. Version Compatibility
The implementation is compatible with version draft-ietf-acme-star-
00. The implementation is based on the Boulder and Certbot code
release from 7-Aug-2017.
5.5. Licensing
This implementation inherits the Boulder license (Mozilla Public
License 2.0) and Certbot license (Apache License Version 2.0 ).
5.6. Implementation experience
To prove the concept all the implementation has been done with a
self-signed CA, to avoid impact on real domains. To be able to do it
we use the FAKE_DNS property of Boulder and static /etc/hosts entries
with domains names. Nonetheless this implementation should run with
real domains.
Most of the implementation has been made to avoid deep changes inside
of Boulder or Certbot, for example, the recurrent certificates
issuance by the CA is based on an external process that auto-
configures the standard Linux "cron" daemon in the ACME CA server.
The reference setup recommended is one physical host with 3 virtual
machines, one for each of the 3 components (client, proxy and server)
and the connectivity based on host bridge.
No security is enabled (iptables default policies are "accept" and
all rules removed) in this implementation to simplify and test the
protocol.
5.7. Contact Information
See author details below.
6. IANA Considerations
[[RFC Editor: please replace XXXX below by the RFC number.]]
6.1. New ACME Error Types
This document adds the following entry to the ACME Error Type
registry:
+------------------------+------------------------------+-----------+
| Type | Description | Reference |
+------------------------+------------------------------+-----------+
| recurrentOrderCanceled | The short-term certificate | RFC XXXX |
| | is no longer available | |
| | because the recurrent order | |
| | has been explicitly canceled | |
| | by the DNO | |
| recurrentOrderExpired | The short-term certificate | RFC XXXX |
| | is no longer available | |
| | because the recurrent order | |
| | has expired | |
+------------------------+------------------------------+-----------+
6.2. New ACME Order Object Fields
This document adds the following entries to the ACME Order Object
Fields registry:
+-------------------------------+--------+--------------+-----------+
| Field Name | Field | Configurable | Reference |
| | Type | | |
+-------------------------------+--------+--------------+-----------+
| recurrent | string | true | RFC XXXX |
| recurrent-start-date | string | true | RFC XXXX |
| recurrent-end-date | string | true | RFC XXXX |
| recurrent-certificate- | string | true | RFC XXXX |
| validity | | | |
+-------------------------------+--------+--------------+-----------+
7. Security Considerations
TBD
8. Acknowledgments
This work is partially supported by the European Commission under This work is partially supported by the European Commission under
Horizon 2020 grant agreement no. 688421 Measurement and Architecture Horizon 2020 grant agreement no. 688421 Measurement and Architecture
for a Middleboxed Internet (MAMI). This support does not imply for a Middleboxed Internet (MAMI). This support does not imply
endorsement. endorsement.
7. References 9. References
7.1. Normative References 9.1. Normative References
[I-D.ietf-acme-acme] [I-D.ietf-acme-acme]
Barnes, R., Hoffman-Andrews, J., and J. Kasten, "Automatic Barnes, R., Hoffman-Andrews, J., and J. Kasten, "Automatic
Certificate Management Environment (ACME)", draft-ietf- Certificate Management Environment (ACME)", draft-ietf-
acme-acme-06 (work in progress), March 2017. acme-acme-08 (work in progress), October 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
7.2. Informative References [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[CAB-CAA] CA/Browser Forum, "Ballot 187 - Make CAA Checking [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Mandatory", March 2017, <https://cabforum.org/2017/03/08/ Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
ballot-187-make-caa-checking-mandatory/>. DOI 10.17487/RFC7231, June 2014, <https://www.rfc-
editor.org/info/rfc7231>.
[I-D.cairns-tls-session-key-interface] [RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP
Cairns, K., Mattsson, J., Skog, R., and D. Migault, APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016,
"Session Key Interface (SKI) for TLS and DTLS", draft- <https://www.rfc-editor.org/info/rfc7807>.
cairns-tls-session-key-interface-01 (work in progress),
October 2015.
[I-D.erb-lurk-rsalg] 9.2. Informative References
Erb, S. and R. Salz, "A PFS-preserving protocol for LURK",
draft-erb-lurk-rsalg-01 (work in progress), May 2016.
[I-D.iab-web-pki-problems] [I-D.nir-saag-star]
Housley, R. and K. O'Donoghue, "Improving the Public Key Nir, Y., Fossati, T., and Y. Sheffer, "Considerations For
Infrastructure (PKI) for the World Wide Web", draft-iab- Using Short Term Certificates", draft-nir-saag-star-00
web-pki-problems-05 (work in progress), October 2016. (work in progress), October 2017.
[I-D.ietf-acme-caa] [I-D.sheffer-acme-star-request]
Landau, H., "CAA Record Extensions for Account URI and Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T.
ACME Method Binding", draft-ietf-acme-caa-01 (work in Fossati, "Generating Certificate Requests for Short-Term,
progress), February 2017. Automatically-Renewed (STAR) Certificates", draft-sheffer-
acme-star-request-01 (work in progress), June 2017.
[RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Authority Authorization (CAA) Resource Record", RFC 6844, Code: The Implementation Status Section", BCP 205,
DOI 10.17487/RFC6844, January 2013, RFC 7942, DOI 10.17487/RFC7942, July 2016,
<http://www.rfc-editor.org/info/rfc6844>. <https://www.rfc-editor.org/info/rfc7942>.
[Topalovic] [Topalovic]
Topalovic, E., Saeta, B., Huang, L., Jackson, C., and D. Topalovic, E., Saeta, B., Huang, L., Jackson, C., and D.
Boneh, "Towards Short-Lived Certificates", 2012, Boneh, "Towards Short-Lived Certificates", 2012,
<http://www.w2spconf.com/2012/papers/w2sp12-final9.pdf>. <http://www.w2spconf.com/2012/papers/w2sp12-final9.pdf>.
Appendix A. Document History Appendix A. Document History
[[Note to RFC Editor: please remove before publication.]] [[Note to RFC Editor: please remove before publication.]]
A.1. draft-ietf-acme-star-00 A.1. draft-ietf-acme-star-01
o Generalized the introduction, separating out the specifics of
CDNs.
o Clean out LURK-specific text.
o Using a POST to ensure cancellation is authenticated.
o First and last date of recurrent cert, as absolute dates.
Validity of certs in seconds.
o Use RFC7807 "Problem Details" in error responses.
o Add IANA considerations.
o Changed the document's title.
A.2. draft-ietf-acme-star-00
o Initial working group version. o Initial working group version.
o Removed the STAR interface, the protocol between NDC and DNO. o Removed the STAR interface, the protocol between NDC and DNO.
What remains is only the extended ACME protocol. What remains is only the extended ACME protocol.
A.2. draft-sheffer-acme-star-02 A.3. draft-sheffer-acme-star-02
o Using a more generic term for the delegation client, NDC. o Using a more generic term for the delegation client, NDC.
o Added an additional use case: public cloud services. o Added an additional use case: public cloud services.
o More detail on ACME authorization. o More detail on ACME authorization.
A.3. draft-sheffer-acme-star-01 A.4. draft-sheffer-acme-star-01
o A terminology section. o A terminology section.
o Some cleanup. o Some cleanup.
A.4. draft-sheffer-acme-star-00 A.5. draft-sheffer-acme-star-00
o Renamed draft to prevent confusion with other work in this space. o Renamed draft to prevent confusion with other work in this space.
o Added an initial STAR protocol: a REST API. o Added an initial STAR protocol: a REST API.
o Discussion of CDNI use cases. o Discussion of CDNI use cases.
A.5. draft-sheffer-acme-star-lurk-00 A.6. draft-sheffer-acme-star-lurk-00
o Initial version. o Initial version.
Authors' Addresses Authors' Addresses
Yaron Sheffer Yaron Sheffer
Intuit Intuit
EMail: yaronf.ietf@gmail.com EMail: yaronf.ietf@gmail.com
Diego Lopez Diego Lopez
Telefonica I+D Telefonica I+D
EMail: diego.r.lopez@telefonica.com EMail: diego.r.lopez@telefonica.com
Oscar Gonzalez de Dios Oscar Gonzalez de Dios
Telefonica I+D Telefonica I+D
EMail: oscar.gonzalezdedios@telefonica.com EMail: oscar.gonzalezdedios@telefonica.com
Antonio Agustin Pastor Perales Antonio Agustin Pastor Perales
Telefonica I+D Telefonica I+D
EMail: antonio.pastorperales@telefonica.com EMail: antonio.pastorperales@telefonica.com
 End of changes. 70 change blocks. 
242 lines changed or deleted 414 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/