draft-ietf-acme-star-delegation-00.txt   draft-ietf-acme-star-delegation-01.txt 
ACME Y. Sheffer ACME Y. Sheffer
Internet-Draft Intuit Internet-Draft Intuit
Intended status: Standards Track D. Lopez Intended status: Standards Track D. Lopez
Expires: June 16, 2019 A. Pastor Perales Expires: February 27, 2020 A. Pastor Perales
Telefonica I+D Telefonica I+D
T. Fossati T. Fossati
Nokia Nokia
December 13, 2018 August 26, 2019
An ACME Profile for Generating Delegated STAR Certificates An ACME Profile for Generating Delegated STAR Certificates
draft-ietf-acme-star-delegation-00 draft-ietf-acme-star-delegation-01
Abstract Abstract
This memo proposes a profile of the ACME protocol that allows the This memo proposes a profile of the ACME protocol that allows the
owner of an identifier (e.g., a domain name) to delegate to a third owner of an identifier (e.g., a domain name) to delegate to a third
party access to a certificate associated with said identifier. A party access to a certificate associated with said identifier. A
primary use case is that of a CDN (the third party) terminating TLS primary use case is that of a CDN (the third party) terminating TLS
sessions on behalf of a content provider (the owner of a domain sessions on behalf of a content provider (the owner of a domain
name). The presented mechanism allows the owner of the identifier to name). The presented mechanism allows the owner of the identifier to
retain control over the delegation and revoke it at any time by retain control over the delegation and revoke it at any time by
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 June 16, 2019. This Internet-Draft will expire on February 27, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Conventions used in this document . . . . . . . . . . . . 4 1.2. Conventions used in this document . . . . . . . . . . . . 4
2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Delegated Identity Profile . . . . . . . . . . . . . . . 6 2.3. Delegated Identity Profile . . . . . . . . . . . . . . . 6
2.3.1. Order Object on the NDC-IdO side . . . . . . . . . . 6 2.3.1. Order Object on the NDC-IdO side . . . . . . . . . . 6
2.3.2. Order Object on the IdO-CA side . . . . . . . . . . . 9 2.3.2. Order Object on the IdO-CA side . . . . . . . . . . . 9
2.3.3. Capability Discovery . . . . . . . . . . . . . . . . 9 2.3.3. Capability Discovery . . . . . . . . . . . . . . . . 9
2.3.4. On Cancelation . . . . . . . . . . . . . . . . . . . 9 2.3.4. On Cancelation . . . . . . . . . . . . . . . . . . . 9
3. CDNI Use Cases . . . . . . . . . . . . . . . . . . . . . . . 9 3. CSR Template . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Multiple Parallel Delegates . . . . . . . . . . . . . . . 9 3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Chained Delegation . . . . . . . . . . . . . . . . . . . 10 3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4. Further Use Cases . . . . . . . . . . . . . . . . . . . . . . 11
4.1. New fields in the "meta" Object within a Directory Object 10 4.1. CDNI . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4.1.1. Multiple Parallel Delegates . . . . . . . . . . . . . 12
5.1. Restricting CDNs to the Delegation Mechanism . . . . . . 10 4.1.2. Chained Delegation . . . . . . . . . . . . . . . . . 12
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. STIR . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 11 5.1. New fields in the "meta" Object within a Directory Object 13
7.2. Informative References . . . . . . . . . . . . . . . . . 12 5.2. CSR Template Registry . . . . . . . . . . . . . . . . . . 13
Appendix A. Document History . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
A.1. draft-ietf-acme-star-delegation-00 . . . . . . . . . . . 13 6.1. Restricting CDNs to the Delegation Mechanism . . . . . . 13
A.2. draft-sheffer-acme-star-delegation-01 . . . . . . . . . . 13 6.2. TBC . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
A.3. draft-sheffer-acme-star-delegation-00 . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Document History . . . . . . . . . . . . . . . . . . 16
A.1. draft-ietf-acme-star-delegation-01 . . . . . . . . . . . 16
A.2. draft-ietf-acme-star-delegation-00 . . . . . . . . . . . 16
A.3. draft-sheffer-acme-star-delegation-01 . . . . . . . . . . 16
A.4. draft-sheffer-acme-star-delegation-00 . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This document is a companion document to [I-D.ietf-acme-star]. To This document is a companion document to [I-D.ietf-acme-star]. To
avoid duplication, we give here a bare-bones description of the avoid duplication, we give here a bare-bones description of the
motivation for this solution. For more details and further use motivation for this solution. For more details and further use
cases, please refer to the introductory sections of cases, please refer to the introductory sections of
[I-D.ietf-acme-star]. [I-D.ietf-acme-star].
An Identifier Owner (IdO), that we can associate in the primary use An Identifier Owner (IdO), that we can associate in the primary use
skipping to change at page 3, line 18 skipping to change at page 3, line 26
Consumer) to use and attest its identity. In the primary use case, Consumer) to use and attest its identity. In the primary use case,
we consider a CDN provider contracted to serve the IdO content over we consider a CDN provider contracted to serve the IdO content over
HTTPS. The CDN terminates the HTTPS connection at one of its edge HTTPS. The CDN terminates the HTTPS connection at one of its edge
cache servers and needs to present its clients (browsers, mobile cache servers and needs to present its clients (browsers, mobile
apps, set-top-boxes) a certificate whose name matches the authority apps, set-top-boxes) a certificate whose name matches the authority
of the URL that is requested, i.e., that of the IdO. Understandably, of the URL that is requested, i.e., that of the IdO. Understandably,
most IdOs balk at sharing their long-term private keys with another most IdOs balk at sharing their long-term private keys with another
organization and, equally, delegates would rather not have to handle organization and, equally, delegates would rather not have to handle
other parties' long-term secrets. other parties' long-term secrets.
Other relevant use cases are discussed in Section 4.
This document describes a profile of the ACME protocol This document describes a profile of the ACME protocol
[I-D.ietf-acme-acme] that allows the NDC to request the IdO, acting [I-D.ietf-acme-acme] that allows the NDC to request the IdO, acting
as a profiled ACME server, a certificate for a delegated identity - as a profiled ACME server, a certificate for a delegated identity -
i.e., one belonging to the IdO. The IdO then uses the ACME protocol i.e., one belonging to the IdO. The IdO then uses the ACME protocol
(with the extensions described in [I-D.ietf-acme-star]) to request (with the extensions described in [I-D.ietf-acme-star]) to request
issuance of a STAR certificate for the same delegated identity. The issuance of a STAR certificate for the same delegated identity. The
generated short-term certificate is automatically renewed by the ACME generated short-term certificate is automatically renewed by the ACME
Certification Authority (CA), periodically fetched by the NDC and Certification Authority (CA), periodically fetched by the NDC and
used to terminate HTTPS connections in lieu of the IdO. The IdO can used to terminate HTTPS connections in lieu of the IdO. The IdO can
end the delegation at any time by simply instructing the CA to stop end the delegation at any time by simply instructing the CA to stop
skipping to change at page 4, line 28 skipping to change at page 4, line 39
2.1. Preconditions 2.1. Preconditions
The protocol assumes the following preconditions are met: The protocol assumes the following preconditions are met:
o The IdO exposes an ACME server interface to the NDC(s) comprising o The IdO exposes an ACME server interface to the NDC(s) comprising
the account management interface; the account management interface;
o The NDC has registered an ACME account with the IdO; o The NDC has registered an ACME account with the IdO;
o NDC and IdO have agreed on a "CSR template" to use, including at a o NDC and IdO have agreed on a "CSR template" to use, including at a
minimum: subject name (e.g., "somesite.example.com"), requested minimum: subject name (e.g., "somesite.example.com"), requested
algorithms, key length, key usage. The NDC is required to use algorithms and key length, key usage, extensions (e.g.,
this template for every CSR created under the same delegation; TNAuthList). The NDC is required to use this template for every
CSR created under the same delegation;
o IdO has registered an ACME account with the Certificate Authority o IdO has registered an ACME account with the Certificate Authority
(CA) (CA)
Note that even if the IdO implements the ACME server role, it is not Note that even if the IdO implements the ACME server role, it is not
acting as a CA: in fact, from the point of view of the certificate acting as a CA: in fact, from the point of view of the certificate
issuance process, the IdO only works as a "policing" forwarder of the issuance process, the IdO only works as a "policing" forwarder of the
NDC's key-pair and is responsible for completing the identity NDC's key-pair and is responsible for completing the identity
verification process towards the ACME CA. verification process towards the ACME CA.
2.2. Overview 2.2. Overview
The interaction between the NDC and the IdO is governed by the The interaction between the NDC and the IdO is governed by the
profiled ACME workflow detailed in Section 2.3. The interaction profiled ACME workflow detailed in Section 2.3. The interaction
between the IdO and the CA is ruled by ACME STAR between the IdO and the CA is ruled by ACME STAR [I-D.ietf-acme-star]
[I-D.ietf-acme-star]. as well as any other ACME extension that applies (e.g.,
[I-D.ietf-acme-authority-token-tnauthlist] for STIR).
The outline of the combined protocol is as follow (Figure 1): The outline of the combined protocol is as follow (Figure 1):
o NDC sends an Order for the delegated identifier to IdO; o NDC sends an Order for the delegated identifier to IdO;
o IdO creates an Order resource in state "ready" with a "finalize" o IdO creates an Order resource in state "ready" with a "finalize"
URL; URL;
o NDC immediately sends a finalize request (which includes the CSR) o NDC immediately sends a finalize request (which includes the CSR)
to the IdO; to the IdO;
o IdO verifies the CSR according to the agreed CSR template; o IdO verifies the CSR according to the agreed CSR template;
o If the CSR verification fails, the Order is moved to an "invalid" o If the CSR verification fails, the Order is moved to an "invalid"
state and everything stops; state and everything stops;
o If the CSR verification is successful, IdO moves the Order to o If the CSR verification is successful, IdO moves the Order to
state "processing", and sends an Order' (using its own account) state "processing", and sends an Order' (using its own account)
for the delegated identifier to the ACME STAR CA; for the delegated identifier to the ACME STAR CA;
o If the ACME STAR protocol fails, Order' moves to "invalid" and the o If the ACME STAR protocol fails, Order' moves to "invalid" and the
same state is reflected in the NDC Order; same state is reflected in the NDC Order;
o If the ACME STAR run is successful (i.e., Order' is "valid"), IdO o If the ACME STAR run is successful (i.e., Order' is "valid"), IdO
copies the "star-certificate" URL from Order' to Order and moves copies the "star-certificate" URL from Order' to Order and moves
skipping to change at page 9, line 33 skipping to change at page 9, line 33
2.3.4. On Cancelation 2.3.4. On Cancelation
It is worth noting that cancelation of the ACME STAR certificate is a It is worth noting that cancelation of the ACME STAR certificate is a
prerogative of the IdO. The NDC does not own the relevant account prerogative of the IdO. The NDC does not own the relevant account
key on the ACME CA, therefore it can't issue a cancelation request key on the ACME CA, therefore it can't issue a cancelation request
for the STAR cert. Potentially, since it holds the STAR cert private for the STAR cert. Potentially, since it holds the STAR cert private
key, it could request the revocation of a single STAR certificate. key, it could request the revocation of a single STAR certificate.
However, STAR explicitly disables the revokeCert interface. However, STAR explicitly disables the revokeCert interface.
3. CDNI Use Cases 3. CSR Template
Members of the IETF CDNI (Content Delivery Network Interconnection) The CSR template is used to express and constrain the shape of the
working group are interested in delegating authority over web content CSR that the NDC uses to request the certificate. The CSR is used
to CDNs. Their requirements are described in a draft for every CSR created under the same delegation. Its validation is a
[I-D.fieau-cdni-https-delegation] that considers several solutions critical element in the security of the whole delegation mechanism.
addressing different delegation requirements. This section discusses
two of these particular requirements in the context of the STAR
delegation workflow.
3.1. Multiple Parallel Delegates The CSR template is defined using JSON Schema
[I-D.handrews-json-schema], a mature, widely used format, which is a
natural fit for the JSON-centric ACME.
Instead of defining every possible CSR attribute, this document takes
a minimalist approach by declaring only the minimum attribute set and
deferring the registration of further, more specific, attributes to
future documents. Critically, this document establishes the
necessary IANA registry and registration rules (see Section 5.2).
3.1. Rules
TODO
3.2. Example
The CSR template in Figure 2 represents one possible CSR template
governing the delegation exchanges provided in the rest of this
document.
{
"type": "object",
"properties": {
"san": {
"type": "string",
"pattern": "*.ndc.dno.example."
},
"requested-algorithms": {
"type": "object",
"properties": {
"sigAlgo": {
"type": "string",
"enum": [
"ecdsa-with-sha256"
]
},
},
"required": [
"sigAlgo"
]
},
"key-usage": {
"type": "string",
"enum": [
"digitalSignature"
]
}
},
"required": [
"san",
"requested-algorithms",
"key-length",
"key-usage"
],
"title": "csr-template",
"description": "Example CSR Template for IETF ACME STAR Delegation"
}
Figure 2: Example CSR template
4. Further Use Cases
4.1. CDNI
[I-D.ietf-cdni-interfaces-https-delegation] discusses several
solutions addressing different delegation requirements for the CDNI
(CDN Interconnection) environment. This section discusses two of the
stated requirements in the context of the STAR delegation workflow.
4.1.1. Multiple Parallel Delegates
In some cases the content owner (IdO) would like to delegate In some cases the content owner (IdO) would like to delegate
authority over a web site to multiple NDCs (CDNs). This could happen authority over a web site to multiple NDCs (CDNs). This could happen
if the IdO has agreements in place with different regional CDNs for if the IdO has agreements in place with different regional CDNs for
different geographical regions, or if a "backup" CDN is used to different geographical regions, or if a "backup" CDN is used to
handle overflow traffic by temporarily altering some of the CNAME handle overflow traffic by temporarily altering some of the CNAME
mappings in place. The STAR delegation flow enables this use case mappings in place. The STAR delegation flow enables this use case
naturally, since each CDN can authenticate separately to the IdO (via naturally, since each CDN can authenticate separately to the IdO (via
its own separate account) specifying its CSR, and the IdO is free to its own separate account) specifying its CSR, and the IdO is free to
allow or deny each certificate request according to its own policy. allow or deny each certificate request according to its own policy.
3.2. Chained Delegation 4.1.2. Chained Delegation
In other cases, a content owner (IdO) delegates some domains to a In other cases, a content owner (IdO) delegates some domains to a
large CDN (uCDN), which in turn delegates to a smaller regional CDN, large CDN (uCDN), which in turn delegates to a smaller regional CDN,
dCDN. The DNO has a contractual relationship with uCDN, and uCDN has dCDN. The DNO has a contractual relationship with uCDN, and uCDN has
a similar relationship with dCDN. However IdO may not even know a similar relationship with dCDN. However IdO may not even know
about dCDN. about dCDN.
The STAR protocol does not prevent this use case, although there is The STAR protocol can be chained to support this use case: uCDN could
no special support for it: uCDN could forward requests from dCDN to forward requests from dCDN to DNO, and forward responses back to
DNO, and forward responses back to dCDN. Whether such proxying is dCDN. Whether such proxying is allowed is governed by policy and
allowed is governed by policy and contracts between the parties. contracts between the parties.
One thing that might be necessary at the interface between uCDN and A mechanism is necessary at the interface between uCDN and dCDN by
dCDN is a mechanism by which the uCDN can advertise: which the uCDN can advertise:
o The namespace that is made available to the dCDN to mint its o The namespace that is made available to the dCDN to mint its
delegated names; delegated names;
o The policy for creating the key material (allowed algorithms, o The policy for creating the key material (allowed algorithms,
minimum key lengths, key usage, etc.) that the dCDN needs to minimum key lengths, key usage, etc.) that the dCDN needs to
satisfy. satisfy.
4. IANA Considerations Note that such mechanism is provided by the CSR template.
4.2. STIR
As a second use case, we consider the delegation of credentials in
the STIR ecosystem [I-D.ietf-stir-cert-delegation].
In the STIR "delegated" model, a service provider, the NDC, needs to
sign PASSPorT's [RFC8225] for telephone numbers (e.g., TN=+123)
belonging to another service provider, the IdO. In order to do that,
it needs a STIR certificate, and private key, that includes TN=+123
in the TNAuthList [RFC8226] cert extension.
The STAR delegation profile described in this document applies
straightforwardly, the only extra requirement being the ability to
instruct the NDC about the allowed TNAuthList values. This can be
achieved by a simple extension of the CSR template.
5. IANA Considerations
[[RFC Editor: please replace XXXX below by the RFC number.]] [[RFC Editor: please replace XXXX below by the RFC number.]]
4.1. New fields in the "meta" Object within a Directory Object 5.1. New fields in the "meta" Object within a Directory Object
This document adds the following entries to the ACME Directory This document adds the following entries to the ACME Directory
Metadata Fields: Metadata Fields:
+-------------------------+------------+-----------+ +-------------------------+------------+-----------+
| Field Name | Field Type | Reference | | Field Name | Field Type | Reference |
+-------------------------+------------+-----------+ +-------------------------+------------+-----------+
| star-delegation-enabled | boolean | RFC XXXX | | star-delegation-enabled | boolean | RFC XXXX |
+-------------------------+------------+-----------+ +-------------------------+------------+-----------+
5. Security Considerations 5.2. CSR Template Registry
5.1. Restricting CDNs to the Delegation Mechanism TODO
6. Security Considerations
6.1. Restricting CDNs to the Delegation Mechanism
When a web site is delegated to a CDN, the CDN can in principle When a web site is delegated to a CDN, the CDN can in principle
modify the web site at will, create and remove pages. This means modify the web site at will, create and remove pages. This means
that a malicious or breached CDN can pass the ACME (as well as common that a malicious or breached CDN can pass the ACME (as well as common
non-ACME) HTTPS-based validation challenges and generate a non-ACME) HTTPS-based validation challenges and generate a
certificate for the site. This is true regardless of whether the certificate for the site. This is true regardless of whether the
CNAME mechanisms defined in the current document is used or not. CNAME mechanisms defined in the current document is used or not.
In some cases, this is the desired behavior: the domain owner trusts In some cases, this is the desired behavior: the domain owner trusts
the CDN to have full control of the cryptographic credentials for the the CDN to have full control of the cryptographic credentials for the
skipping to change at page 11, line 20 skipping to change at page 14, line 4
only wants to delegate restricted control, and wishes to retain the only wants to delegate restricted control, and wishes to retain the
capability to cancel the CDN's credentials at a short notice. capability to cancel the CDN's credentials at a short notice.
To restrict certificate delegation only to the protocol defined here: To restrict certificate delegation only to the protocol defined here:
o The domain owner MUST make sure that the CDN cannot modify the DNS o The domain owner MUST make sure that the CDN cannot modify the DNS
records for the domain. The domain owner should ensure it is the records for the domain. The domain owner should ensure it is the
only entity authorized to modify the DNS zone. Typically, it only entity authorized to modify the DNS zone. Typically, it
establishes a CNAME resource record from a subdomain into a CDN- establishes a CNAME resource record from a subdomain into a CDN-
managed domain. managed domain.
o The domain owner MUST use a CAA record [RFC6844] to restrict o The domain owner MUST use a CAA record [RFC6844] to restrict
certificate issuance for the domain to specific CAs that comply certificate issuance for the domain to specific CAs that comply
with ACME. with ACME.
o The domain owner MUST use the ACME-specific CAA mechanism o The domain owner MUST use the ACME-specific CAA mechanism
[I-D.ietf-acme-caa] to restrict issuance to a specific account key [I-D.ietf-acme-caa] to restrict issuance to a specific account key
which is controlled by it, and MUST require "dns-01" as the sole which is controlled by it, and MUST require "dns-01" as the sole
validation method. validation method.
6. Acknowledgments 6.2. TBC
o CSR validation
o CNAME mappings
o Composition with ACME STAR
o Composition with other ACME extensions
o Channel security
7. 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 8. References
7.1. Normative References 8.1. Normative References
[I-D.handrews-json-schema]
Wright, A. and H. Andrews, "JSON Schema: A Media Type for
Describing JSON Documents", draft-handrews-json-schema-01
(work in progress), March 2018.
[I-D.ietf-acme-acme] [I-D.ietf-acme-acme]
Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment Kasten, "Automatic Certificate Management Environment
(ACME)", draft-ietf-acme-acme-16 (work in progress), (ACME)", draft-ietf-acme-acme-18 (work in progress),
October 2018. December 2018.
[I-D.ietf-acme-caa] [I-D.ietf-acme-caa]
Landau, H., "CAA Record Extensions for Account URI and Landau, H., "CAA Record Extensions for Account URI and
ACME Method Binding", draft-ietf-acme-caa-05 (work in ACME Method Binding", draft-ietf-acme-caa-10 (work in
progress), June 2018. progress), June 2019.
[I-D.ietf-acme-star] [I-D.ietf-acme-star]
Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T.
Fossati, "Support for Short-Term, Automatically-Renewed Fossati, "Support for Short-Term, Automatically-Renewed
(STAR) Certificates in Automated Certificate Management (STAR) Certificates in Automated Certificate Management
Environment (ACME)", draft-ietf-acme-star-04 (work in Environment (ACME)", draft-ietf-acme-star-07 (work in
progress), October 2018. progress), August 2019.
[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-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification [RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification
Authority Authorization (CAA) Resource Record", RFC 6844, Authority Authorization (CAA) Resource Record", RFC 6844,
DOI 10.17487/RFC6844, January 2013, DOI 10.17487/RFC6844, January 2013,
<https://www.rfc-editor.org/info/rfc6844>. <https://www.rfc-editor.org/info/rfc6844>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References 8.2. Informative References
[I-D.fieau-cdni-https-delegation] [I-D.ietf-acme-authority-token-tnauthlist]
Fieau, F., Emile, S., and S. Mishra, "HTTPS delegation in Wendt, C., Hancock, D., Barnes, M., and J. Peterson,
CDNI", draft-fieau-cdni-https-delegation-02 (work in "TNAuthList profile of ACME Authority Token", draft-ietf-
progress), July 2017. acme-authority-token-tnauthlist-03 (work in progress),
March 2019.
[I-D.ietf-cdni-interfaces-https-delegation]
Fieau, F., Emile, S., and S. Mishra, "CDNI extensions for
HTTPS delegation", draft-ietf-cdni-interfaces-https-
delegation-01 (work in progress), May 2019.
[I-D.ietf-stir-cert-delegation]
Peterson, J., "STIR Certificate Delegation", draft-ietf-
stir-cert-delegation-00 (work in progress), July 2019.
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
<https://www.rfc-editor.org/info/rfc8225>.
[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", RFC 8226,
DOI 10.17487/RFC8226, February 2018,
<https://www.rfc-editor.org/info/rfc8226>.
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-delegation-00 A.1. draft-ietf-acme-star-delegation-01
o Addition of the STIR use case.
o Refinement of the CDNI use case.
o Addition of the CSR template (partial, more work required).
o Further security considerations (work in progress).
A.2. draft-ietf-acme-star-delegation-00
o Republished as a working group draft. o Republished as a working group draft.
A.2. draft-sheffer-acme-star-delegation-01 A.3. draft-sheffer-acme-star-delegation-01
o Added security considerations about disallowing CDNs from issuing o Added security considerations about disallowing CDNs from issuing
certificates for a delegated domain. certificates for a delegated domain.
A.3. draft-sheffer-acme-star-delegation-00 A.4. draft-sheffer-acme-star-delegation-00
o Initial version, some text extracted from draft-sheffer-acme-star- o Initial version, some text extracted from draft-sheffer-acme-star-
requests-02 requests-02
Authors' Addresses Authors' Addresses
Yaron Sheffer Yaron Sheffer
Intuit Intuit
EMail: yaronf.ietf@gmail.com EMail: yaronf.ietf@gmail.com
 End of changes. 34 change blocks. 
65 lines changed or deleted 204 lines changed or added

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