rfc9115.original   rfc9115.txt 
ACME Y. Sheffer Internet Engineering Task Force (IETF) Y. Sheffer
Internet-Draft Intuit Request for Comments: 9115 Intuit
Intended status: Standards Track D. López Category: Standards Track D. López
Expires: 13 December 2021 A. Pastor Perales ISSN: 2070-1721 A. Pastor Perales
Telefonica I+D Telefonica I+D
T. Fossati T. Fossati
ARM ARM
11 June 2021 August 2021
An ACME Profile for Generating Delegated Certificates An Automatic Certificate Management Environment (ACME) Profile for
draft-ietf-acme-star-delegation-09 Generating Delegated Certificates
Abstract Abstract
This document defines a profile of the Automatic Certificate This document defines a profile of the Automatic Certificate
Management Environment (ACME) protocol by which the holder of an Management Environment (ACME) protocol by which the holder of an
identifier (e.g., a domain name) can allow a third party to obtain an identifier (e.g., a domain name) can allow a third party to obtain an
X.509 certificate such that the certificate subject is the delegated X.509 certificate such that the certificate subject is the delegated
identifier while the certified public key corresponds to a private identifier while the certified public key corresponds to a private
key controlled by the third party. A primary use case is that of a key controlled by the third party. A primary use case is that of a
Content Delivery Network (CDN, the third party) terminating TLS Content Delivery Network (CDN), the third party, terminating TLS
sessions on behalf of a content provider (the holder of a domain sessions on behalf of a content provider (the holder of a domain
name). The presented mechanism allows the holder of the identifier name). The presented mechanism allows the holder of the identifier
to retain control over the delegation and revoke it at any time. to retain control over the delegation and revoke it at any time.
Importantly, this mechanism does not require any modification to the Importantly, this mechanism does not require any modification to the
deployed TLS clients and servers. deployed TLS clients and servers.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 13 December 2021. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc9115.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Simplified BSD License text as described in Section 4.e of
provided without warranty as described in the Simplified BSD License. the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology
1.2. Conventions used in this document . . . . . . . . . . . . 5 1.2. Conventions Used in This Document
2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Protocol Flow
2.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Preconditions
2.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Overview
2.3. Delegated Identity Profile . . . . . . . . . . . . . . . 8 2.3. Delegated Identity Profile
2.3.1. Delegation Configuration . . . . . . . . . . . . . . 8 2.3.1. Delegation Configuration
2.3.2. Order Object Transmitted from NDC to IdO and to ACME 2.3.2. Order Object Transmitted from NDC to IdO and to ACME
Server (STAR) . . . . . . . . . . . . . . . . . . . . 11 Server (for STAR)
2.3.3. Order Object Transmitted from NDC to IdO and to ACME 2.3.3. Order Object Transmitted from NDC to IdO and to ACME
Server (non-STAR) . . . . . . . . . . . . . . . . . . 15 Server (for Non-STAR)
2.3.4. Capability Discovery . . . . . . . . . . . . . . . . 18 2.3.4. Capability Discovery
2.3.5. Negotiating an Unauthenticated GET . . . . . . . . . 19 2.3.5. Negotiating an Unauthenticated GET
2.3.6. Terminating the Delegation . . . . . . . . . . . . . 20 2.3.6. Terminating the Delegation
2.4. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 21 2.4. Proxy Behavior
3. CA Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 22 3. CA Behavior
4. CSR Template . . . . . . . . . . . . . . . . . . . . . . . . 22 4. CSR Template
4.1. Template Syntax . . . . . . . . . . . . . . . . . . . . . 22 4.1. Template Syntax
4.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.2. Example
5. Further Use Cases . . . . . . . . . . . . . . . . . . . . . . 24 5. Further Use Cases
5.1. CDN Interconnection (CDNI) . . . . . . . . . . . . . . . 24 5.1. CDN Interconnection (CDNI)
5.1.1. Multiple Parallel Delegates . . . . . . . . . . . . . 25 5.1.1. Multiple Parallel Delegates
5.1.2. Chained Delegation . . . . . . . . . . . . . . . . . 25 5.1.2. Chained Delegation
5.2. Secure Telephone Identity Revisited (STIR) . . . . . . . 28 5.2. Secure Telephone Identity Revisited (STIR)
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 6. IANA Considerations
6.1. New Fields in the "meta" Object within a Directory 6.1. New Fields in the "meta" Object within a Directory Object
Object . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.2. New Fields in the Order Object
6.2. New Fields in the Order Object . . . . . . . . . . . . . 30 6.3. New Fields in the Account Object
6.3. New Fields in the Account Object . . . . . . . . . . . . 30 6.4. New Error Types
6.4. New Error Types . . . . . . . . . . . . . . . . . . . . . 30 6.5. CSR Template Extensions
6.5. CSR Template Extensions . . . . . . . . . . . . . . . . . 31 7. Security Considerations
7.1. Trust Model
7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 7.2. Delegation Security Goal
7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 32 7.3. New ACME Channels
7.2. Delegation Security Goal . . . . . . . . . . . . . . . . 32 7.4. Restricting CDNs to the Delegation Mechanism
7.3. New ACME Channels . . . . . . . . . . . . . . . . . . . . 33 8. References
7.4. Restricting CDNs to the Delegation Mechanism . . . . . . 35 8.1. Normative References
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 8.2. Informative References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 Appendix A. CSR Template: CDDL
9.1. Normative References . . . . . . . . . . . . . . . . . . 36 Appendix B. CSR Template: JSON Schema
9.2. Informative References . . . . . . . . . . . . . . . . . 37 . Acknowledgements
Appendix A. Document History . . . . . . . . . . . . . . . . . . 38 Authors' Addresses
A.1. draft-ietf-acme-star-delegation-09 . . . . . . . . . . . 38
A.2. draft-ietf-acme-star-delegation-08 . . . . . . . . . . . 39
A.3. draft-ietf-acme-star-delegation-07 . . . . . . . . . . . 39
A.4. draft-ietf-acme-star-delegation-06 . . . . . . . . . . . 39
A.5. draft-ietf-acme-star-delegation-05 . . . . . . . . . . . 39
A.6. draft-ietf-acme-star-delegation-04 . . . . . . . . . . . 39
A.7. draft-ietf-acme-star-delegation-03 . . . . . . . . . . . 40
A.8. draft-ietf-acme-star-delegation-02 . . . . . . . . . . . 40
A.9. draft-ietf-acme-star-delegation-01 . . . . . . . . . . . 40
A.10. draft-ietf-acme-star-delegation-00 . . . . . . . . . . . 40
A.11. draft-sheffer-acme-star-delegation-01 . . . . . . . . . . 40
A.12. draft-sheffer-acme-star-delegation-00 . . . . . . . . . . 40
Appendix B. CSR Template: CDDL . . . . . . . . . . . . . . . . . 40
Appendix C. CSR Template: JSON Schema . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
This document is related to [RFC8739], in that some important use This document is related to [RFC8739], in that some important use
cases require both documents to be implemented. To avoid cases require both documents to be implemented. To avoid
duplication, we give here a bare-bones description of the motivation duplication, we give here a bare-bones description of the motivation
for this solution. For more details, please refer to the for this solution. For more details, please refer to the
introductory sections of [RFC8739]. introductory sections of [RFC8739].
An Identifier Owner (IdO) has agreements in place with one or more An Identifier Owner (IdO) has agreements in place with one or more
NDC (Name Delegation Consumer) to use and attest its identity. Name Delegation Consumer (NDC) to use and attest its identity.
In the primary use case the IdO is a content provider, and we In the primary use case, the IdO is a content provider, and we
consider a Content Delivery Network (CDN) provider contracted to consider a Content Delivery Network (CDN) provider contracted to
serve the content over HTTPS. The CDN terminates the HTTPS serve the content over HTTPS. The CDN terminates the HTTPS
connection at one of its edge cache servers and needs to present its connection at one of its edge cache servers and needs to present its
clients (browsers, mobile apps, set-top-boxes) a certificate whose clients (browsers, mobile apps, set-top boxes) a certificate whose
name matches the domain name of the URL that is requested, i.e., that name matches the domain name of the URL that is requested, i.e., that
of the IdO. Understandably, some IdOs may balk at sharing their of the IdO. Understandably, some IdOs may balk at sharing their
long-term private keys with another organization and, equally, long-term private keys with another organization; equally, delegates
delegates would rather not have to handle other parties' long-term would rather not have to handle other parties' long-term secrets.
secrets. Other relevant use cases are discussed in Section 5. Other relevant use cases are discussed in Section 5.
This document describes a profile of the ACME protocol [RFC8555] that This document describes a profile of the ACME protocol [RFC8555] that
allows the NDC to request from the IdO, acting as a profiled ACME allows the NDC to request from the IdO, acting as a profiled ACME
server, a certificate for a delegated identity - i.e., one belonging server, a certificate for a delegated identity -- i.e., one belonging
to the IdO. The IdO then uses the ACME protocol (with the extensions to the IdO. The IdO then uses the ACME protocol (with the extensions
described in [RFC8739]) to request issuance of a Short-Term, described in [RFC8739]) to request issuance of a Short-Term,
Automatically Renewed (STAR) certificate for the same delegated Automatically Renewed (STAR) certificate for the same delegated
identity. The generated short-term certificate is automatically identity. The generated short-term certificate is automatically
renewed by the ACME Certification Authority (CA), periodically renewed by the ACME Certification Authority (CA), is periodically
fetched by the NDC and used to terminate HTTPS connections in lieu of fetched by the NDC, and is used to terminate HTTPS connections in
the IdO. The IdO can end the delegation at any time by simply lieu of the IdO. The IdO can end the delegation at any time by
instructing the CA to stop the automatic renewal and letting the simply instructing the CA to stop the automatic renewal and letting
certificate expire shortly thereafter. the certificate expire shortly thereafter.
While the primary use case we address is delegation of STAR While the primary use case we address is a delegation of STAR
certificates, the mechanism proposed here accommodates also long- certificates, the mechanism proposed here also accommodates long-
lived certificates managed with the ACME protocol. The most lived certificates managed with the ACME protocol. The most
noticeable difference between long-lived and STAR certificates is the noticeable difference between long-lived and STAR certificates is the
way the termination of the delegation is managed. In the case of way the termination of the delegation is managed. In the case of
long-lived certificates, the IdO uses the revokeCert URL exposed by long-lived certificates, the IdO uses the "revokeCert" URL exposed by
the CA and waits for the explicit revocation based on Certificate the CA and waits for the explicit revocation based on the Certificate
Revocation List (CRL) and Online Certificate Status Protocol (OCSP) Revocation List (CRL) and Online Certificate Status Protocol (OCSP)
to propagate to the relying parties. to propagate to the relying parties.
In case the delegated identity is a domain name, this document also In case the delegated identity is a domain name, this document also
provides a way for the NDC to inform the IdO about the CNAME mappings provides a way for the NDC to inform the IdO about the CNAME mappings
that need to be installed in the IdO's DNS zone to enable the that need to be installed in the IdO's DNS zone to enable the
aliasing of the delegated name, thus allowing the complete name aliasing of the delegated name, thus allowing the complete name
delegation workflow to be handled using a single interface. delegation workflow to be handled using a single interface.
We note that other standardization efforts address the problem of We note that other standardization efforts address the problem of
certificate delegation for TLS connections, specifically certificate delegation for TLS connections, specifically
[I-D.ietf-tls-subcerts] and [I-D.mglt-lurk-tls13]. The former [TLS-SUBCERTS] and [MGLT-LURK-TLS13]. The former extends the TLS
extends the TLS certificate chain with a customer-owned signing certificate chain with a customer-owned signing certificate; the
certificate; the latter separates the server's private key into a latter separates the server's private key into a dedicated, more-
dedicated, more secure component. Compared to these other secure component. Compared to these other approaches, the current
approaches, the current document does not require changes to the TLS document does not require changes to the TLS network stack of the
network stack of the client or the server, nor does it introduce client or the server, nor does it introduce additional latency to the
additional latency to the TLS connection. TLS connection.
1.1. Terminology 1.1. Terminology
IdO Identifier Owner, the holder (current owner) of an identifier IdO Identifier Owner, the holder (current owner) of an identifier
(e.g., a domain name) that needs to be delegated. Depending on (e.g., a domain name) that needs to be delegated. Depending
the context, the term IdO may also be used to designate the on the context, the term IdO may also be used to designate
(profiled) ACME server deployed by the Identifier Owner or the the (profiled) ACME server deployed by the Identifier Owner
ACME client used by the Identifier Owner to interact with the CA. or the ACME client used by the Identifier Owner to interact
with the CA.
NDC Name Delegation Consumer, the entity to which the domain name is NDC Name Delegation Consumer, the entity to which the domain name
delegated for a limited time. This is a CDN in the primary use is delegated for a limited time. This is a CDN in the
case (in fact, readers may note the similarity of the two primary use case (in fact, readers may note the similarity of
acronyms). Depending on the context, the term NDC may also be the two abbreviations). Depending on the context, the term
used to designate the (profiled) ACME client used by the Name NDC may also be used to designate the (profiled) ACME client
Delegation Consumer. used by the Name Delegation Consumer.
CDN Content Delivery Network, a widely distributed network that CDN Content Delivery Network, a widely distributed network that
serves the domain's web content to a wide audience at high serves the domain's web content to a wide audience at high
performance. performance.
STAR Short-Term, Automatically Renewed X.509 certificates. STAR Short-Term, Automatically Renewed, as applied to X.509
certificates.
ACME Automated Certificate Management Environment, a certificate ACME Automated Certificate Management Environment, a certificate
management protocol [RFC8555]. management protocol [RFC8555].
CA A Certification Authority that implements the ACME protocol. In CA Certification Authority, specifically one that implements the
this document, the term is synonymous with "ACME server deployed ACME protocol. In this document, the term is synonymous with
by the Certification Authority". "ACME server deployed by the Certification Authority".
CSR A PKCS#10 [RFC2986] Certificate Signing Request, as supported by CSR Certificate Signing Request, specifically a PKCS#10 [RFC2986]
ACME. Certificate Signing Request, as supported by ACME.
FQDN Fully Qualified Domain Name. FQDN Fully Qualified Domain Name.
1.2. Conventions used in this document 1.2. 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
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Protocol Flow 2. Protocol Flow
This section presents the protocol flow. For completeness, we This section presents the protocol flow. For completeness, we
include the ACME profile proposed in this document as well as the include the ACME profile proposed in this document as well as the
ACME STAR protocol described in [RFC8739]. ACME STAR protocol described in [RFC8739].
2.1. Preconditions 2.1. Preconditions
The protocol assumes the following preconditions are met: The protocol assumes the following preconditions are met:
* The IdO exposes an ACME server interface to the NDC(s) comprising * The IdO exposes an ACME server interface to the NDC(s) comprising
the account management interface; the account management interface.
* The NDC has registered an ACME account with the IdO;
* NDC and IdO have agreed on a "CSR template" to use, including at a * The NDC has registered an ACME account with the IdO.
minimum: subject name (e.g., "abc.ido.example"), requested
algorithms and key length, key usage, extensions. The NDC will * The NDC and IdO have agreed on a "CSR template" to use, including
use this template for every CSR created under the same delegation; at a minimum: subject name (e.g., "abc.ido.example"), requested
* IdO has registered an ACME account with the Certification algorithms and key length, key usage, and extensions. The NDC
Authority (CA) will use this template for every CSR created under the same
delegation.
* The IdO has registered an ACME account with the Certification
Authority (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 CA. verification process towards the CA.
2.2. Overview 2.2. Overview
For clarity, the protocol overview presented here covers the main use For clarity, the protocol overview presented here covers the main use
case of this protocol, namely delegation of STAR certificates. case of this protocol, namely delegation of STAR certificates.
Protocol behavior for non-STAR certificates is similar, and the Protocol behavior for non-STAR certificates is similar, and the
detailed differences are listed in the following sections. detailed differences are listed in the following sections.
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 [RFC8555], ACME STAR between the IdO and the CA is ruled by ACME [RFC8555], ACME STAR
[RFC8739] as well as any other ACME extension that applies (e.g., [RFC8739], and any other ACME extension that applies (e.g.,
[I-D.ietf-acme-authority-token-tnauthlist] for STIR). [TOKEN-TNAUTHLIST] for Secure Telephone Identity Revisited (STIR)).
The outline of the combined protocol for STAR certificates is as The outline of the combined protocol for STAR certificates is as
follow (Figure 1): follows (Figure 1):
* NDC sends an Order1 for the delegated identifier to IdO.
* NDC sends an order Order1 for the delegated identifier to IdO;
* IdO creates an Order1 resource in state "ready" with a "finalize" * IdO creates an Order1 resource in state "ready" with a "finalize"
URL; URL.
* NDC immediately sends a finalize request (which includes the CSR)
to the IdO; * NDC immediately sends a "finalize" request (which includes the
* IdO verifies the CSR according to the agreed upon CSR template; CSR) to the IdO.
* IdO verifies the CSR according to the agreed upon CSR template.
* If the CSR verification fails, Order1 is moved to an "invalid" * If the CSR verification fails, Order1 is moved to an "invalid"
state and everything stops; state and everything stops.
* If the CSR verification is successful, IdO moves Order1 to state * If the CSR verification is successful, IdO moves Order1 to state
"processing", and sends a new Order2 (using its own account) for "processing" and sends a new Order2 (using its own account) for
the delegated identifier to the CA; the delegated identifier to the CA.
* If the ACME STAR protocol fails, Order2 moves to "invalid" and the
same state is reflected in Order1 (i.e., the NDC Order); * If the ACME STAR protocol fails, Order2 moves to "invalid", and
the same state is reflected in Order1 (i.e., the NDC Order).
* If the ACME STAR run is successful (i.e., Order2 is "valid"), IdO * If the ACME STAR run is successful (i.e., Order2 is "valid"), IdO
copies the "star-certificate" URL from Order2 to Order1 and copies the "star-certificate" URL from Order2 to Order1 and
updates the Order1 state to "valid". updates the Order1 state to "valid".
The NDC can now download, install and use the short-term certificate The NDC can now download, install, and use the short-term certificate
bearing the name delegated by the IdO. This can continue until the bearing the name delegated by the IdO. The STAR certificate can be
STAR certificate expires or the IdO decides to cancel the automatic used until it expires, at which time the NDC is guaranteed to find a
renewal process with the CA. new certificate it can download, install, and use. This continues
with subsequent certificates until either Order1 expires or the IdO
decides to cancel the automatic renewal process with the CA.
Note that the interactive identifier authorization phase described in Note that the interactive identifier authorization phase described in
Section 7.5 of [RFC8555] is suppressed on the NDC-IdO side because Section 7.5 of [RFC8555] is suppressed on the NDC-IdO side because
the delegated identity contained in the CSR presented to the IdO is the delegated identity contained in the CSR presented to the IdO is
validated against the configured CSR template (Section 4.1). validated against the configured CSR template (Section 4.1).
Therefore, the NDC sends the finalize request, including the CSR, to Therefore, the NDC sends the "finalize" request, including the CSR,
the IdO immediately after Order1 has been acknowledged. The IdO to the IdO immediately after Order1 has been acknowledged. The IdO
SHALL buffer a (valid) CSR until the Validation phase completes SHALL buffer a (valid) CSR until the Validation phase completes
successfully. successfully.
Also note that the successful negotiation of the "unauthenticated Also note that the successful negotiation of the unauthenticated GET
GET" (Section 3.4 of [RFC8739]) is required in order to allow the NDC (Section 3.4 of [RFC8739]) is required in order to allow the NDC to
to access the "star-certificate" URL on the CA. access the "star-certificate" URL on the CA.
.------. .---------------. .------. .------. .---------------. .------.
| NDC | | IdO | | ACME | | NDC | | IdO | | ACME |
+--------+ +--------+--------+ +--------+ +--------+ +--------+--------+ +--------+
| Client | | Server | Client | | Server | | Client | | Server | Client | | Server |
'---+----' '----+---+---+----' '----+---' '---+----' '----+---+---+----' '----+---'
| | | | | | | |
| Order1 | | | | Order1 | | |
| Signature | | | | Signature | | |
o------------------->| | | o------------------->| | |
skipping to change at page 8, line 25 skipping to change at line 349
| (unauthenticated) GET STAR certificate | | (unauthenticated) GET STAR certificate |
o------------------------------------------------>| o------------------------------------------------>|
| Certificate #2 | | Certificate #2 |
|<------------------------------------------------o |<------------------------------------------------o
| [...] | | [...] |
| (unauthenticated) GET STAR certificate | | (unauthenticated) GET STAR certificate |
o------------------------------------------------>| o------------------------------------------------>|
| Certificate #n | | Certificate #n |
|<------------------------------------------------o |<------------------------------------------------o
Figure 1: End to end STAR delegation flow Figure 1: End-to-End STAR Delegation Flow
2.3. Delegated Identity Profile 2.3. Delegated Identity Profile
This section defines a profile of the ACME protocol, to be used This section defines a profile of the ACME protocol to be used
between the NDC and IdO. between the NDC and IdO.
2.3.1. Delegation Configuration 2.3.1. Delegation Configuration
The IdO must be preconfigured to recognize one or more NDCs, and The IdO must be preconfigured to recognize one or more NDCs and
present them with details about certificate delegations that apply to present them with details about certificate delegations that apply to
each one. each one.
2.3.1.1. Account Object Extensions 2.3.1.1. Account Object Extensions
An NDC identifies itself to the IdO as an ACME account. The IdO can An NDC identifies itself to the IdO as an ACME account. The IdO can
delegate multiple names to a NDC, and these configurations are delegate multiple names to an NDC, and these configurations are
described through "delegation" objects associated with the NDC's described through "delegation" objects associated with the NDC's
Account object on the IdO. account object on the IdO.
As shown in Figure 2, the ACME account resource on the IdO is As shown in Figure 2, the ACME account resource on the IdO is
extended with a new "delegations" attribute: extended with a new "delegations" attribute:
* delegations (required, string): A URL from which a list of delegations (required, string): A URL from which a list of
delegations configured for this account (Section 2.3.1.3) can be delegations configured for this account (Section 2.3.1.3) can be
fetched via a POST-as-GET request. fetched via a POST-as-GET request.
{ {
"status": "valid", "status": "valid",
"contact": [ "contact": [
"mailto:delegation-admin@ido.example" "mailto:delegation-admin@ido.example"
], ],
"termsOfServiceAgreed": true, "termsOfServiceAgreed": true,
"orders": "https://example.com/acme/orders/saHpfB", "orders": "https://example.com/acme/orders/saHpfB",
"delegations": "https://acme.ido.example/acme/delegations/adFqoz" "delegations": "https://acme.ido.example/acme/delegations/adFqoz"
} }
Figure 2: Example Account object with delegations Figure 2: Example Account Object with Delegations
2.3.1.2. Delegation Lists 2.3.1.2. Delegation Lists
Each account object includes a "delegations" URL from which a list of Each account object includes a "delegations" URL from which a list of
delegation configurations created by the IdO can be fetched via POST- delegation configurations created by the IdO can be fetched via a
as-GET request. The result of the request MUST be a JSON object POST-as-GET request. The result of the request MUST be a JSON object
whose "delegations" field is an array of URLs, each identifying a whose "delegations" field is an array of URLs, each identifying a
delegation configuration made available to the NDC account delegation configuration made available to the NDC account
(Section 2.3.1.3). The server MAY return an incomplete list, along (Section 2.3.1.3). The server MAY return an incomplete list, along
with a Link header field with a "next" link relation indicating where with a "Link" header field with a "next" link relation indicating
further entries can be acquired. where further entries can be acquired.
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/json Content-Type: application/json
Link: <https://acme.ido.example/acme/directory>;rel="index" Link: <https://acme.ido.example/acme/directory>;rel="index"
Link: <https://acme.ido.example/acme/delegations/adFqoz?cursor=2>;rel="next" Link: <https://acme.ido.example/acme/delegations/adFqoz?/
cursor=2>;rel="next"
{ {
"delegations": [ "delegations": [
"https://acme.ido.example/acme/delegation/ogfr8EcolOT", "https://acme.ido.example/acme/delegation/ogfr8EcolOT",
"https://acme.ido.example/acme/delegation/wSi5Lbb61E4", "https://acme.ido.example/acme/delegation/wSi5Lbb61E4",
/* more URLs not shown for example brevity */ /* more URLs not shown for example brevity */
"https://acme.ido.example/acme/delegation/gm0wfLYHBen" "https://acme.ido.example/acme/delegation/gm0wfLYHBen"
] ]
} }
Note that in the figure above,
https://acme.ido.example/acme/delegations/adFqoz?cursor=2 includes a
line break for the sake of presentation.
2.3.1.3. Delegation Objects 2.3.1.3. Delegation Objects
This profile extends the ACME resource model with a new read-only This profile extends the ACME resource model with a new read-only
delegation object that represents a delegation configuration that "delegation" object that represents a delegation configuration that
applies to a given NDC. applies to a given NDC.
A delegation object contains the CSR template (see Section 4) that A "delegation" object contains the CSR template (see Section 4) that
applies to that delegation, and optionally any related CNAME mapping applies to that delegation and, optionally, any related CNAME mapping
for the delegated identifiers. Its structure is as follows: for the delegated identifiers. Its structure is as follows:
* csr-template (required, object): CSR template as defined in csr-template (required, object): CSR template, as defined in
Section 4. Section 4.
* cname-map (optional, object): a map of FQDN pairs. In each pair,
the name is the delegated identifier, the value is the cname-map (optional, object): A map of FQDN pairs. In each pair,
the name is the delegated identifier; the value is the
corresponding NDC name that is aliased in the IdO's zone file to corresponding NDC name that is aliased in the IdO's zone file to
redirect the resolvers to the delegated entity. Both names and redirect the resolvers to the delegated entity. Both names and
values MUST be FQDNs with a terminating '.'. This field is only values MUST be FQDNs with a terminating '.'. This field is only
meaningful for identifiers of type "dns". meaningful for identifiers of type "dns".
An example delegation object in JSON format is shown in Figure 3. An example "delegation" object in JSON format is shown in Figure 3.
{ {
"csr-template": { "csr-template": {
"keyTypes": [ "keyTypes": [
{ {
"PublicKeyType": "id-ecPublicKey", "PublicKeyType": "id-ecPublicKey",
"namedCurve": "secp256r1", "namedCurve": "secp256r1",
"SignatureType": "ecdsa-with-SHA256" "SignatureType": "ecdsa-with-SHA256"
} }
], ],
skipping to change at page 10, line 49 skipping to change at line 473
"extendedKeyUsage": [ "extendedKeyUsage": [
"serverAuth" "serverAuth"
] ]
} }
}, },
"cname-map": { "cname-map": {
"abc.ido.example.": "abc.ndc.example." "abc.ido.example.": "abc.ndc.example."
} }
} }
Figure 3: Example Delegation Configuration object Figure 3: Example Delegation Configuration Object
In order to indicate which specific delegation applies to the In order to indicate which specific delegation applies to the
requested certificate a new "delegation" attribute is added to the requested certificate, a new "delegation" attribute is added to the
request object on the NDC-IdO side (see Figure 4 and Figure 7). The order object on the NDC-IdO side (see Figures 4 and 7). The value of
value of this attribute is the URL pointing to the delegation this attribute is the URL pointing to the delegation configuration
configuration object that is to be used for this certificate request. object that is to be used for this certificate request. If the
If the "delegation" attribute in the Order object contains a URL that "delegation" attribute in the order object contains a URL that does
does not correspond to a configuration available to the requesting not correspond to a configuration available to the requesting ACME
ACME account, the IdO MUST return an error response with status code account, the IdO MUST return an error response with status code 403
403 (Forbidden), providing a problem document [RFC7807] with type (Forbidden), providing a problem document [RFC7807] with type
"urn:ietf:params:acme:error:unknownDelegation". "urn:ietf:params:acme:error:unknownDelegation".
2.3.2. Order Object Transmitted from NDC to IdO and to ACME Server 2.3.2. Order Object Transmitted from NDC to IdO and to ACME Server
(STAR) (STAR)
If the delegation is for a STAR certificate, the request object If the delegation is for a STAR certificate, the request object
created by the NDC: created by the NDC:
* MUST have a "delegation" attribute indicating the preconfigured * MUST have a "delegation" attribute indicating the preconfigured
delegation that applies to this Order; delegation that applies to this Order;
skipping to change at page 11, line 24 skipping to change at line 494
"urn:ietf:params:acme:error:unknownDelegation". "urn:ietf:params:acme:error:unknownDelegation".
2.3.2. Order Object Transmitted from NDC to IdO and to ACME Server 2.3.2. Order Object Transmitted from NDC to IdO and to ACME Server
(STAR) (STAR)
If the delegation is for a STAR certificate, the request object If the delegation is for a STAR certificate, the request object
created by the NDC: created by the NDC:
* MUST have a "delegation" attribute indicating the preconfigured * MUST have a "delegation" attribute indicating the preconfigured
delegation that applies to this Order; delegation that applies to this Order;
* MUST have entries in the "identifiers" field for each delegated * MUST have entries in the "identifiers" field for each delegated
name present in the configuration; name present in the configuration;
* MUST NOT contain the "notBefore" and "notAfter" fields;
* MUST contain an "auto-renewal" object and inside it, the fields * MUST NOT contain the "notBefore" and "notAfter" fields; and
* MUST contain an "auto-renewal" object and, inside it, the fields
listed in Section 3.1.1 of [RFC8739]. In particular, the "allow- listed in Section 3.1.1 of [RFC8739]. In particular, the "allow-
certificate-get" attribute MUST be present and set to true. certificate-get" attribute MUST be present and set to true.
POST /acme/new-order HTTP/1.1 POST /acme/new-order HTTP/1.1
Host: acme.ido.example Host: acme.ido.example
Content-Type: application/jose+json Content-Type: application/jose+json
{ {
"protected": base64url({ "protected": base64url({
"alg": "ES256", "alg": "ES256",
skipping to change at page 12, line 36 skipping to change at line 535
"allow-certificate-get": true "allow-certificate-get": true
}, },
"delegation": "delegation":
"https://acme.ido.example/acme/delegation/gm0wfLYHBen" "https://acme.ido.example/acme/delegation/gm0wfLYHBen"
}), }),
"signature": "g454e3hdBlkT4AEw...nKePnUyZTjGtXZ6H" "signature": "g454e3hdBlkT4AEw...nKePnUyZTjGtXZ6H"
} }
Figure 4: New STAR Order from NDC Figure 4: New STAR Order from NDC
The Order object that is created on the IdO: The order object that is created on the IdO:
* MUST start in the "ready" state; * MUST start in the "ready" state;
* MUST contain an "authorizations" array with zero elements; * MUST contain an "authorizations" array with zero elements;
* MUST contain the indicated "delegation" configuration; * MUST contain the indicated "delegation" configuration;
* MUST contain the indicated "auto-renewal" settings;
* MUST contain the indicated "auto-renewal" settings; and
* MUST NOT contain the "notBefore" and "notAfter" fields. * MUST NOT contain the "notBefore" and "notAfter" fields.
{ {
"status": "ready", "status": "ready",
"expires": "2021-05-01T00:00:00Z", "expires": "2021-05-01T00:00:00Z",
"identifiers": [ "identifiers": [
{ {
"type": "dns", "type": "dns",
"value": "abc.ido.example" "value": "abc.ido.example"
skipping to change at page 13, line 34 skipping to change at line 576
"authorizations": [], "authorizations": [],
"finalize": "https://acme.ido.example/acme/order/TO8rfgo/finalize" "finalize": "https://acme.ido.example/acme/order/TO8rfgo/finalize"
} }
Figure 5: STAR Order Resource Created on IdO Figure 5: STAR Order Resource Created on IdO
The Order is then finalized by the NDC supplying the CSR containing The Order is then finalized by the NDC supplying the CSR containing
the delegated identifiers. The IdO checks the provided CSR against the delegated identifiers. The IdO checks the provided CSR against
the template contained in the delegation object that applies to this the template contained in the "delegation" object that applies to
request, as described in Section 4.1. If the CSR fails validation this request, as described in Section 4.1. If the CSR fails
for any of the identifiers, the IdO MUST return an error response validation for any of the identifiers, the IdO MUST return an error
with status code 403 (Forbidden) and an appropriate type, e.g., response with status code 403 (Forbidden) and an appropriate type,
"rejectedIdentifier" or "badCSR". The error response SHOULD contain e.g., "rejectedIdentifier" or "badCSR". The error response SHOULD
subproblems (Section 6.7.1 of [RFC8555]) for each failed identifier. contain subproblems (Section 6.7.1 of [RFC8555]) for each failed
If the CSR is successfully validated, the Order object status moves identifier. If the CSR is successfully validated, the order object
to "processing" and the twin ACME protocol instance is initiated on status moves to "processing" and the twin ACME protocol instance is
the IdO-CA side. initiated on the IdO-CA side.
The request object created by the IdO: The request object created by the IdO:
* MUST copy the identifiers sent by the NDC; * MUST copy the identifiers sent by the NDC;
* MUST strip the "delegation" attribute;
* MUST strip the "delegation" attribute; and
* MUST carry a copy of the "auto-renewal" object sent by the NDC. * MUST carry a copy of the "auto-renewal" object sent by the NDC.
When the identifiers' authorization has been successfully completed When the identifiers' authorization has been successfully completed
and the certificate has been issued by the CA, the IdO: and the certificate has been issued by the CA, the IdO:
* MUST move its Order resource status to "valid"; * MUST move its Order resource status to "valid" and
* MUST copy the "star-certificate" field from the STAR Order * MUST copy the "star-certificate" field from the STAR Order
returned by the CA into its Order resource. When dereferenced, returned by the CA into its Order resource. When dereferenced,
the "star-certificate" URL includes (via the Cert-Not-Before and the "star-certificate" URL includes (via the "Cert-Not-Before" and
Cert-Not-After HTTP header fields) the renewal timers needed by "Cert-Not-After" HTTP header fields) the renewal timers needed by
the NDC to inform its certificate reload logic. the NDC to inform its certificate reload logic.
{ {
"status": "valid", "status": "valid",
"expires": "2021-05-01T00:00:00Z", "expires": "2021-05-01T00:00:00Z",
"identifiers": [ "identifiers": [
{ {
"type": "dns", "type": "dns",
"value": "abc.ido.example" "value": "abc.ido.example"
skipping to change at page 14, line 42 skipping to change at line 635
"authorizations": [], "authorizations": [],
"finalize": "https://acme.ido.example/acme/order/TO8rfgo/finalize", "finalize": "https://acme.ido.example/acme/order/TO8rfgo/finalize",
"star-certificate": "https://acme.ca.example/acme/order/yTr23sSDg9" "star-certificate": "https://acme.ca.example/acme/order/yTr23sSDg9"
} }
Figure 6: STAR Order Resource Updated on IdO Figure 6: STAR Order Resource Updated on IdO
This delegation protocol is predicated on the NDC being able to fetch This delegation protocol is predicated on the NDC being able to fetch
certificates periodically using an unauthenticated HTTP GET, since in certificates periodically using an unauthenticated HTTP GET, since,
general the NDC does not possess an account on the CA and therefore in general, the NDC does not possess an account on the CA; as a
cannot issue the standard POST-as-GET ACME request. Therefore, consequence, it cannot issue the standard POST-as-GET ACME request.
before forwarding the Order request to the CA, the IdO SHOULD ensure Therefore, before forwarding the Order request to the CA, the IdO
that the selected CA supports "unauthenticated GET" by inspecting the SHOULD ensure that the selected CA supports unauthenticated GET by
relevant settings in the CA's "directory" object, as per Section 3.4 inspecting the relevant settings in the CA's directory object, as per
of [RFC8739]. If the CA does not support "unauthenticated GET" of Section 3.4 of [RFC8739]. If the CA does not support unauthenticated
STAR certificates, the IdO MUST NOT forward the Order request. GET of STAR certificates, the IdO MUST NOT forward the Order request.
Instead, it MUST move the Order status to "invalid" and set the Instead, it MUST move the Order status to "invalid" and set the
"allow-certificate-get" in the "auto-renewal" object to "false". The "allow-certificate-get" in the "auto-renewal" object to "false". The
same occurs in case the Order request is forwarded and the CA does same occurs in case the Order request is forwarded and the CA does
not reflect the "allow-certificate-get" setting in its Order not reflect the "allow-certificate-get" setting in its Order
resource. The combination of "invalid" status and denied "allow- resource. The combination of "invalid" status and denied "allow-
certificate-get" in the Order resource at the IdO provides an certificate-get" in the Order resource at the IdO provides an
unambiguous (asynchronous) signal to the NDC about the failure unambiguous (asynchronous) signal to the NDC about the failure
reason. reason.
2.3.2.1. CNAME Installation 2.3.2.1. CNAME Installation
If an identifier object of type "dns" was included, the IdO can add If one of the objects in the "identifiers" list is of type "dns", the
the CNAME records specified in the delegation object to its zone, IdO can add the CNAME records specified in the "delegation" object to
e.g.: its zone, for example:
abc.ido.example. CNAME abc.ndc.example. abc.ido.example. CNAME abc.ndc.example.
2.3.3. Order Object Transmitted from NDC to IdO and to ACME Server 2.3.3. Order Object Transmitted from NDC to IdO and to ACME Server
(non-STAR) (Non-STAR)
If the delegation is for a non-STAR certificate, the request object If the delegation is for a non-STAR certificate, the request object
created by the NDC: created by the NDC:
* MUST have a "delegation" attribute indicating the preconfigured * MUST have a "delegation" attribute indicating the preconfigured
delegation that applies to this Order; delegation that applies to this Order;
* MUST have entries in the "identifiers" field for each delegated * MUST have entries in the "identifiers" field for each delegated
name present in the configuration; name present in the configuration; and
* MUST have the "allow-certificate-get" attribute set to true. * MUST have the "allow-certificate-get" attribute set to true.
POST /acme/new-order HTTP/1.1 POST /acme/new-order HTTP/1.1
Host: acme.ido.example Host: acme.ido.example
Content-Type: application/jose+json Content-Type: application/jose+json
{ {
"protected": base64url({ "protected": base64url({
"alg": "ES256", "alg": "ES256",
"kid": "https://acme.ido.example/acme/acct/evOfKhNU60wg", "kid": "https://acme.ido.example/acme/acct/evOfKhNU60wg",
skipping to change at page 16, line 32 skipping to change at line 701
], ],
"delegation": "delegation":
"https://acme.ido.example/acme/delegation/gm0wfLYHBen", "https://acme.ido.example/acme/delegation/gm0wfLYHBen",
"allow-certificate-get": true "allow-certificate-get": true
}), }),
"signature": "j9JBUvMigi4zodud...acYkEKaa8gqWyZ6H" "signature": "j9JBUvMigi4zodud...acYkEKaa8gqWyZ6H"
} }
Figure 7: New Non-STAR Order from NDC Figure 7: New Non-STAR Order from NDC
The Order object that is created on the IdO: The order object that is created on the IdO:
* MUST start in the "ready" state; * MUST start in the "ready" state;
* MUST contain an "authorizations" array with zero elements; * MUST contain an "authorizations" array with zero elements;
* MUST contain the indicated "delegation" configuration;
* MUST contain the indicated "delegation" configuration; and
* MUST contain the indicated "allow-certificate-get" setting. * MUST contain the indicated "allow-certificate-get" setting.
{ {
"status": "ready", "status": "ready",
"expires": "2021-05-01T00:00:00Z", "expires": "2021-05-01T00:00:00Z",
"identifiers": [ "identifiers": [
{ {
"type": "dns", "type": "dns",
"value": "abc.ido.example" "value": "abc.ido.example"
skipping to change at page 17, line 30 skipping to change at line 736
"authorizations": [], "authorizations": [],
"finalize": "https://acme.ido.example/acme/order/3ZDlhYy/finalize" "finalize": "https://acme.ido.example/acme/order/3ZDlhYy/finalize"
} }
Figure 8: Non-STAR Order Resource Created on IdO Figure 8: Non-STAR Order Resource Created on IdO
The Order finalization by the NDC and the subsequent validation of The Order finalization by the NDC and the subsequent validation of
the CSR by the IdO proceed in the same way as for the STAR case. If the CSR by the IdO proceed in the same way as for the STAR case. If
the CSR is successfully validated, the Order object status moves to the CSR is successfully validated, the order object status moves to
"processing" and the twin ACME protocol instance is initiated on the "processing" and the twin ACME protocol instance is initiated on the
IdO-CA side. IdO-CA side.
The request object created by the IdO: The request object created by the IdO:
* MUST copy the identifiers sent by the NDC; * MUST copy the identifiers sent by the NDC;
* MUST strip the "delegation" attribute;
* MUST strip the "delegation" attribute; and
* MUST copy the "allow-certificate-get" attribute. * MUST copy the "allow-certificate-get" attribute.
When the identifiers' authorization has been successfully completed When the identifiers' authorization has been successfully completed
and the certificate has been issued by the CA, the IdO: and the certificate has been issued by the CA, the IdO:
* MUST move its Order resource status to "valid"; * MUST move its Order resource status to "valid" and
* MUST copy the "certificate" field from the Order returned by the * MUST copy the "certificate" field from the Order returned by the
CA into its Order resource, as well as "notBefore" and "notAfter" CA into its Order resource, as well as "notBefore" and "notAfter"
if these fields exist. if these fields exist.
{ {
"status": "valid", "status": "valid",
"expires": "2021-05-01T00:00:00Z", "expires": "2021-05-01T00:00:00Z",
"identifiers": [ "identifiers": [
{ {
skipping to change at page 18, line 34 skipping to change at line 786
"certificate": "https://acme.ca.example/acme/order/YtR23SsdG9" "certificate": "https://acme.ca.example/acme/order/YtR23SsdG9"
} }
Figure 9: Non-STAR Order Resource Updated on IdO Figure 9: Non-STAR Order Resource Updated on IdO
At this point of the protocol flow, the same considerations as in At this point of the protocol flow, the same considerations as in
Section 2.3.2.1 apply. Section 2.3.2.1 apply.
Before forwarding the Order request to the CA, the IdO SHOULD ensure Before forwarding the Order request to the CA, the IdO SHOULD ensure
that the selected CA supports "unauthenticated GET" by inspecting the that the selected CA supports unauthenticated GET by inspecting the
relevant settings in the CA's "directory" object, as per relevant settings in the CA's directory object, as per Section 2.3.5.
Section 2.3.5. If the CA does not support "unauthenticated GET" of If the CA does not support unauthenticated GET of certificate
certificate resources, the IdO MUST NOT forward the Order request. resources, the IdO MUST NOT forward the Order request. Instead, it
Instead, it MUST move the Order status to "invalid" and set the MUST move the Order status to "invalid" and set the "allow-
"allow-certificate-get" attribute to "false". The same occurs in certificate-get" attribute to "false". The same occurs in case the
case the Order request is forwarded and the CA does not reflect the Order request is forwarded and the CA does not reflect the "allow-
"allow-certificate-get" setting in its Order resource. The certificate-get" setting in its Order resource. The combination of
combination of "invalid" status and denied "allow-certificate-get" in "invalid" status and denied "allow-certificate-get" in the Order
the Order resource at the IdO provides an unambiguous (asynchronous) resource at the IdO provides an unambiguous (asynchronous) signal to
signal to the NDC about the failure reason. the NDC about the failure reason.
2.3.4. Capability Discovery 2.3.4. Capability Discovery
In order to help a client to discover support for this profile, the In order to help a client discover support for this profile, the
directory object of an ACME server (typically, one deployed by the directory object of an ACME server (typically, one deployed by the
IdO) contains the following attribute in the "meta" field: IdO) contains the following attribute in the "meta" field:
* delegation-enabled (optional, boolean): Boolean flag indicating delegation-enabled (optional, boolean): Boolean flag indicating
support for the profile specified in this memo. An ACME server support for the profile specified in this memo. An ACME server
that supports this delegation profile MUST include this key, and that supports this delegation profile MUST include this key and
MUST set it to true. MUST set it to true.
The IdO MUST declare its support for delegation using "delegation- The IdO MUST declare its support for delegation using "delegation-
enabled" regardless of whether it supports delegation of STAR enabled" regardless of whether it supports delegation of STAR
certificates, non-STAR certificates or both. certificates, non-STAR certificates, or both.
In order to help a client to discover support for certificate In order to help a client discover support for certificate fetching
fetching using unauthenticated HTTP GET, the directory object of an using unauthenticated HTTP GET, the directory object of an ACME
ACME server (typically, one deployed by the CA) contains the server (typically, one deployed by the CA) contains the following
following attribute in the "meta" field: attribute in the "meta" field:
* allow-certificate-get (optional, boolean): See Section 2.3.5. allow-certificate-get (optional, boolean): See Section 2.3.5.
2.3.5. Negotiating an Unauthenticated GET 2.3.5. Negotiating an Unauthenticated GET
In order to enable the name delegation of non-STAR certificates, this In order to enable the name delegation of non-STAR certificates, this
document defines a mechanism that allows a server to advertise document defines a mechanism that allows a server to advertise
support for accessing certificate resources via unauthenticated GET support for accessing certificate resources via unauthenticated GET
(in addition to POST-as-GET), and a client to enable this service (in addition to POST-as-GET) and a client to enable this service with
with per-Order granularity. per-Order granularity.
It is worth pointing out that the protocol elements described in this It is worth pointing out that the protocol elements described in this
section have the same names and semantics as those introduced in section have the same names and semantics as those introduced in
Section 3.4 of [RFC8739] for the STAR use case (except, of course, Section 3.4 of [RFC8739] for the STAR use case (except, of course,
they apply to the certificate resource rather than the star- they apply to the certificate resource rather than the star-
certificate resource). However, they differ in terms of their certificate resource). However, they differ in terms of their
position in the directory meta and order objects: rather than being position in the directory meta and order objects; rather than being
wrapped in an auto-renewal sub-object they are located at the top- wrapped in an "auto-renewal" subobject, they are located at the top
level. level.
A server states its availability to grant unauthenticated access to a A server states its availability to grant unauthenticated access to a
client's Order certificate by setting the "allow-certificate-get" client's Order certificate by setting the "allow-certificate-get"
attribute to "true" in the "meta" field inside the directory object: attribute to "true" in the "meta" field inside the directory object:
* allow-certificate-get (optional, boolean): If this field is allow-certificate-get (optional, boolean): If this field is present
present and set to "true", the server allows GET (and HEAD) and set to "true", the server allows GET (and HEAD) requests to
requests to certificate URLs. certificate URLs.
A client states its desire to access the issued certificate via A client states its desire to access the issued certificate via
unauthenticated GET by adding an "allow-certificate-get" attribute to unauthenticated GET by adding an "allow-certificate-get" attribute to
the payload of its newOrder request and setting it to "true". the payload of its newOrder request and setting it to "true".
* allow-certificate-get (optional, boolean): If this field is allow-certificate-get (optional, boolean): If this field is present
present and set to "true", the client requests the server to allow and set to "true", the client requests the server to allow
unauthenticated GET (and HEAD) to the certificate associated with unauthenticated GET (and HEAD) to the certificate associated with
this Order. this Order.
If the server accepts the request, it MUST reflect the attribute If the server accepts the request, it MUST reflect the attribute
setting in the resulting order object. setting in the resulting order object.
Note that even when the use of unauthenticated GET has been agreed Note that even when the use of unauthenticated GET has been agreed
upon, the server MUST also allow POST-as-GET requests to the upon, the server MUST also allow POST-as-GET requests to the
certificate resource. certificate resource.
2.3.6. Terminating the Delegation 2.3.6. Terminating the Delegation
Identity delegation is terminated differently depending on whether Identity delegation is terminated differently depending on whether or
this is a STAR certificate or not. not this is a STAR certificate.
2.3.6.1. By Cancellation (STAR) 2.3.6.1. By Cancellation (STAR)
The IdO can terminate the delegation of a STAR certificate by The IdO can terminate the delegation of a STAR certificate by
requesting its cancellation (see Section 3.1.2 of [RFC8739]). requesting its cancellation (see Section 3.1.2 of [RFC8739]).
Cancellation of the ACME STAR certificate is a prerogative of the Cancellation of the ACME STAR certificate is a prerogative of the
IdO. The NDC does not own the relevant account key on the CA, IdO. The NDC does not own the relevant account key on the CA;
therefore it can't issue a cancellation request for the STAR therefore, it can't issue a cancellation request for the STAR
certificate. Potentially, since it holds the STAR certificate's certificate. Potentially, since it holds the STAR certificate's
private key, it could request the revocation of a single STAR private key, it could request the revocation of a single STAR
certificate. However, STAR explicitly disables the revokeCert certificate. However, STAR explicitly disables the revokeCert
interface. interface.
Shortly after the automatic renewal process is stopped by the IdO, Shortly after the automatic renewal process is stopped by the IdO,
the last issued STAR certificate expires and the delegation the last issued STAR certificate expires and the delegation
terminates. terminates.
2.3.6.2. By Revocation (non-STAR) 2.3.6.2. By Revocation (Non-STAR)
The IdO can terminate the delegation of a non-STAR certificate by The IdO can terminate the delegation of a non-STAR certificate by
requesting it to be revoked using the revokeCert URL exposed by the requesting it to be revoked using the "revokeCert" URL exposed by the
CA. CA.
According to Section 7.6 of [RFC8555], the revocation endpoint can be According to Section 7.6 of [RFC8555], the revocation endpoint can be
used with either the account keypair, or the certificate keypair. In used with either the account key pair or the certificate key pair.
other words, an NDC that learns the revokeCert URL of the CA (which In other words, an NDC that learns the "revokeCert" URL of the CA
is publicly available via the CA's Directory object) would be able to (which is publicly available via the CA's directory object) would be
revoke the certificate using the associated private key. However, able to revoke the certificate using the associated private key.
given the trust relationship between NDC and IdO expected by the However, given the trust relationship between the NDC and IdO
delegation trust model (Section 7.1), as well as the lack of expected by the delegation trust model (Section 7.1), as well as the
incentives for the NDC to prematurely terminate the delegation, this lack of incentives for the NDC to prematurely terminate the
does not represent a significant security risk. delegation, this does not represent a significant security risk.
2.4. Proxy Behavior 2.4. Proxy Behavior
There are cases where the ACME Delegation flow should be proxied, There are cases where the ACME Delegation flow should be proxied,
such as the use case described in Section 5.1.2. This section such as the use case described in Section 5.1.2. This section
describes the behavior of such proxies. describes the behavior of such proxies.
An entity implementing the IdO server role - an "ACME Delegation An entity implementing the IdO server role -- an "ACME Delegation
server" - may behave, on a per-identity case, either as a proxy into server" -- may behave, on a per-identity case, either as a proxy into
another ACME Delegation server, or it may behave as an IdO and obtain another ACME Delegation server or as an IdO and obtain a certificate
a certificate directly. The determining factor is whether it can directly. The determining factor is whether it can successfully be
successfully be authorized by the next-hop ACME server for the authorized by the next-hop ACME server for the identity associated
identity associated with the certificate request. with the certificate request.
The identities supported by each server and the disposition for each The identities supported by each server and the disposition for each
of them are preconfigured. of them are preconfigured.
Following is the proxy's behavior for each of the messages exchanged Following is the proxy's behavior for each of the messages exchanged
in the ACME Delegation process: in the ACME Delegation process:
* New-order request: New-order request:
- The complete "identifiers" object MUST be copied as-is. * The complete "identifiers" attribute MUST be copied as is.
- Similarly, the "auto-renewal" object MUST be copied as-is. * Similarly, the "auto-renewal" object MUST be copied as is.
* New-order response: New-order response:
- The "status", "expires", "authorizations", "identifiers" and * The "status", "expires", "authorizations", "identifiers", and
"auto-renewal" attributes/objects MUST be copied as-is. "auto-renewal" attributes/objects MUST be copied as is.
- The "finalize" URL is rewritten, so that the "finalize" request * The "finalize" URL is rewritten so that the "finalize" request
will be made to the proxy. will be made to the proxy.
- Similarly, the "Location" header MUST be rewritten to point to * Similarly, the "Location" header MUST be rewritten to point to
an Order object on the proxy. an order object on the proxy.
- Any "Link" relations MUST be rewritten to point to the proxy. * Any "Link" relations MUST be rewritten to point to the proxy.
* Get Order response: Get Order response:
- The "status", "expires", "authorizations", "identifiers" and * The "status", "expires", "authorizations", "identifiers", and
"auto-renewal" attributes/objects MUST be copied as-is. "auto-renewal" attributes/objects MUST be copied as is.
- Similarly, the "star-certificate" URL (or the "certificate" URL * Similarly, the "star-certificate" URL (or the "certificate" URL
in case of non-STAR requests) MUST be copied as-is. in case of non-STAR requests) MUST be copied as is.
- The "finalize" URL is rewritten, so that the "finalize" request * The "finalize" URL is rewritten so that the "finalize" request
will be made to the proxy. will be made to the proxy.
* The "Location" header MUST be rewritten to point to an order
- The "Location" header MUST be rewritten to point to an Order
object on the proxy. object on the proxy.
- Any "Link" relations MUST be rewritten to point to the proxy. * Any "Link" relations MUST be rewritten to point to the proxy.
* Finalize request: "finalize" request:
- The CSR MUST be copied as-is. * The CSR MUST be copied as is.
* Finalize response: "finalize" response:
- The "Location" header, "Link" relations and the "finalize" URLs * The "Location" header, "Link" relations, and the "finalize"
are rewritten as for Get Order. URLs are rewritten as for Get Order.
We note that all the above messages are authenticated, and therefore We note that all the above messages are authenticated; therefore,
each proxy must be able to authenticate any subordinate server. each proxy must be able to authenticate any subordinate server.
3. CA Behavior 3. CA Behavior
Although most of this document, and in particular Section 2 is Although most of this document, and in particular Section 2, is
focused on the protocol between the NDC and to IdO, the protocol does focused on the protocol between the NDC and IdO, the protocol does
affect the ACME server running in the CA. A CA that wishes to affect the ACME server running in the CA. A CA that wishes to
support certificate delegation MUST also support unauthenticated support certificate delegation MUST also support unauthenticated
certificate fetching, which it declares using "allow-certificate-get" certificate fetching, which it declares using "allow-certificate-get"
(Section 2.3.5, Paragraph 3). (Section 2.3.5, Paragraph 3).
4. CSR Template 4. CSR Template
The CSR template is used to express and constrain the shape of the The CSR template is used to express and constrain the shape of the
CSR that the NDC uses to request the certificate. The CSR is used CSR that the NDC uses to request the certificate. The CSR is used
for every certificate created under the same delegation. Its for every certificate created under the same delegation. Its
validation by the IdO is a critical element in the security of the validation by the IdO is a critical element in the security of the
whole delegation mechanism. whole delegation mechanism.
Instead of defining every possible CSR attribute, this document takes Instead of defining every possible CSR attribute, this document takes
a minimalist approach by declaring only the minimum attribute set and a minimalist approach by declaring only the minimum attribute set and
deferring the registration of further, more specific, attributes to deferring the registration of further, more-specific attributes to
future documents. future documents.
4.1. Template Syntax 4.1. Template Syntax
The template is a JSON document. Each field (with the exception of The template is a JSON document. Each field (with the exception of
"keyTypes", see below) denotes one of: "keyTypes", see below) denotes one of the following:
* A mandatory field, where the template specifies the literal value * A mandatory field where the template specifies the literal value
of that field. This is denoted by a literal string, such as of that field. This is denoted by a literal string, such as
"abc.ido.example". "abc.ido.example".
* A mandatory field, where the content of the field is defined by
the client. This is denoted by "**".
* An optional field, where the client decides whether the field is
included in the CSR and if so, what its value is. This is denoted
by "*".
The NDC MUST NOT include in the CSR any fields, including any * A mandatory field where the content of the field is defined by the
client. This is denoted by "**".
* An optional field where the client decides whether the field is
included in the CSR and, if so, what its value is. This is
denoted by "*".
The NDC MUST NOT include any fields in the CSR, including any
extensions, unless they are specified in the template. extensions, unless they are specified in the template.
The structure of the template object is defined by the CDDL [RFC8610] The structure of the template object is defined by the Concise Data
document in Appendix B. An alternative, non-normative JSON Schema Definition Language (CDDL) [RFC8610] document in Appendix A. An
syntax is given in Appendix C. While the CSR template must follow alternative, nonnormative JSON Schema syntax is given in Appendix B.
the syntax defined here, neither the IdO nor the NDC are expected to While the CSR template must follow the syntax defined here, neither
validate it at run-time. the IdO nor the NDC are expected to validate it at runtime.
The "subject" field and its subfields are mapped into the "subject" The "subject" field and its subfields are mapped into the "subject"
field of the CSR, as per [RFC5280], Section 4.1.2.6. Other extension field of the CSR, as per Section 4.1.2.6 of [RFC5280]. Other
fields of the CSR template are mapped into the CSR according to the extension fields of the CSR template are mapped into the CSR
table in Section 6.5. according to the table in Section 6.5.
The "subjectAltName" field is currently defined for the following The "subjectAltName" field is currently defined for the following
identifiers: DNS names, email addresses, and URIs. New identifier identifiers: DNS names, email addresses, and URIs. New identifier
types may be added in the future by documents that extend this types may be added in the future by documents that extend this
specification. Each new identifier type SHALL have an associated specification. Each new identifier type SHALL have an associated
identifier validation challenge that the CA can use to obtain proof identifier validation challenge that the CA can use to obtain proof
of the requester's control over it. of the requester's control over it.
The "keyTypes" property is not copied into the CSR. Instead, this The "keyTypes" property is not copied into the CSR. Instead, this
property constrains the "SubjectPublicKeyInfo" field of the CSR, property constrains the "SubjectPublicKeyInfo" field of the CSR,
skipping to change at page 24, line 39 skipping to change at line 1064
"keyUsage": [ "keyUsage": [
"digitalSignature" "digitalSignature"
], ],
"extendedKeyUsage": [ "extendedKeyUsage": [
"serverAuth", "serverAuth",
"clientAuth" "clientAuth"
] ]
} }
} }
Figure 10: Example CSR template Figure 10: Example CSR Template
5. Further Use Cases 5. Further Use Cases
This non-normative section describes additional use cases that use This nonnormative section describes additional use cases implementing
STAR certificate delegation in non-trivial ways. the STAR certificate delegation in nontrivial ways.
5.1. CDN Interconnection (CDNI) 5.1. CDN Interconnection (CDNI)
[I-D.ietf-cdni-interfaces-https-delegation] discusses several [HTTPS-DELEGATION] discusses several solutions addressing different
solutions addressing different delegation requirements for the CDNI delegation requirements for the CDN Interconnection (CDNI)
(CDN Interconnection) environment. This section discusses two of the environment. This section discusses two of the stated requirements
stated requirements in the context of the STAR delegation workflow. in the context of the STAR delegation workflow.
This section uses specifically CDNI terminology, e.g., "uCDN" and This section uses specific CDNI terminology, e.g., Upstream CDN
"dCDN", as defined in [RFC7336]. (uCDN) and Downstream (dCDN), as defined in [RFC7336].
5.1.1. Multiple Parallel Delegates 5.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 website 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
handle overflow traffic by temporarily altering some of the CNAME overflow traffic by temporarily altering some of the CNAME mappings
mappings in place. The STAR delegation flow enables this use case in place. The STAR delegation flow enables this use case naturally,
naturally, since each CDN can authenticate separately to the IdO (via since each CDN can authenticate separately to the IdO (via its own
its own separate account) specifying its CSR, and the IdO is free to separate account) specifying its CSR, and the IdO is free to allow or
allow or deny each certificate request according to its own policy. deny each certificate request according to its own policy.
5.1.2. Chained Delegation 5.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 IdO has a contractual relationship with uCDN, and uCDN has (dCDN). The IdO has a contractual relationship with uCDN, and uCDN
a similar relationship with dCDN. However IdO may not even know has a similar relationship with dCDN. However, IdO may not even know
about dCDN. about dCDN.
If needed, the STAR protocol can be chained to support this use case: If needed, the STAR protocol can be chained to support this use case:
uCDN could forward requests from dCDN to IdO, and forward responses uCDN could forward requests from dCDN to IdO and forward responses
back to dCDN. Whether such proxying is allowed is governed by policy back to dCDN. Whether such proxying is allowed is governed by policy
and contracts between the parties. and contracts between the parties.
A mechanism is necessary at the interface between uCDN and dCDN by A mechanism is necessary at the interface between uCDN and dCDN, by
which the uCDN can advertise: which the uCDN can advertise:
* The names that the dCDN is allowed to use; * the names that the dCDN is allowed to use and
* The policy for creating the key material (allowed algorithms,
* 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.
Note that such mechanism is provided by the CSR template. Note that such mechanism is provided by the CSR template.
5.1.2.1. Two-Level Delegation in CDNI 5.1.2.1. Two-Level Delegation in CDNI
A User Agent (UA), browser or set-top-box, wants to fetch the video A User Agent (UA), e.g., a browser or set-top box, wants to fetch the
resource at the following URI: "https://video.cp.example/movie". video resource at the following URI: "https://video.cp.example/
Redirection between Content Provider (CP), upstream, and downstream movie". Redirection between the content provider (CP) and upstream
CDNs is arranged as a CNAME-based aliasing chain as illustrated in and downstream CDNs is arranged as a CNAME-based aliasing chain, as
Figure 11. illustrated in Figure 11.
.------------. .------------.
video.cp.example ? | .-----. | video.cp.example ? | .-----. |
.---------------------------------->| | | .---------------------------------->| | |
| (a) | | DNS | CP | | (a) | | DNS | CP |
| .-------------------------------+ | | | .-------------------------------+ | |
| | CNAME video.ucdn.example | '-----' | | | CNAME video.ucdn.example | '-----' |
| | '------------' | | '------------'
| | | |
| | | |
skipping to change at page 26, line 38 skipping to change at line 1158
| A 192.0.2.1 | +-----+ dCDN | | A 192.0.2.1 | +-----+ dCDN |
| | | | | | | | | |
'--------------------------------------->| TLS | | '--------------------------------------->| TLS | |
SNI: video.cp.example | | | | SNI: video.cp.example | | | |
| '-----' | | '-----' |
'------------' '------------'
Figure 11: DNS Redirection Figure 11: DNS Redirection
Unlike HTTP-based redirection, where the original URL is supplanted Unlike HTTP-based redirection, where the original URL is supplanted
by the one found in the Location header of the 302 response, DNS by the one found in the "Location" header of the 302 response, DNS
redirection is completely transparent to the User Agent. As a redirection is completely transparent to the User Agent. As a
result, the TLS connection to the dCDN edge is done with a Server result, the TLS connection to the dCDN edge is done with a Server
Name Indication (SNI) equal to the "host" in the original URI - in Name Indication (SNI) equal to the "host" in the original URI -- in
the example, "video.cp.example". So, in order to successfully the example, "video.cp.example". So, in order to successfully
complete the handshake, the landing dCDN node has to be configured complete the handshake, the landing dCDN node has to be configured
with a certificate whose subjectAltName matches "video.cp.example", with a certificate whose "subjectAltName" field matches
i.e., a Content Provider's name. "video.cp.example", i.e., a content provider's name.
Figure 12 illustrates the cascaded delegation flow that allows dCDN Figure 12 illustrates the cascaded delegation flow that allows dCDN
to obtain a STAR certificate that bears a name belonging to the to obtain a STAR certificate that bears a name belonging to the
Content Provider with a private key that is only known to the dCDN. content provider with a private key that is only known to the dCDN.
.--------------------. .--------------------.
| .------.------. | | .------.------. |
| | STAR | ACME |<-------------. | | STAR | ACME |<-------------.
| CP | dele | STAR | | | | CP | dele | STAR | | |
| | srv | cli +-----. | | | srv | cli +-----. |
| '---+--'------' | | 6 | '---+--'------' | | 6
'---------|------^---' 5 | '---------|------^---' 5 |
| | | .--|-------. | | | .--|-------.
| | | | .-+----. | | | | | .-+----. |
skipping to change at page 27, line 39 skipping to change at line 1205
1 | | 3 | | 1 | | 3 | |
| | | | 9 | | | | | 9 |
.-------|--v---v--|---------. | | .-------|--v---v--|---------. | |
| .-+----.----+-.------. | | | | .-+----.----+-.------. | | |
| | | STAR | +------------' | | | | STAR | +------------' |
| dCDN | CDNI | dele | HTTP | | | | dCDN | CDNI | dele | HTTP | | |
| | | cli | |<--------------' | | | cli | |<--------------'
| '------'------'------' | | '------'------'------' |
'---------------------------' '---------------------------'
Figure 12: Two levels delegation in CDNI Figure 12: Two-Level Delegation in CDNI
uCDN is configured to delegate to dCDN, and CP is configured to uCDN is configured to delegate to dCDN, and CP is configured to
delegate to uCDN, both as defined in Section 2.3.1. delegate to uCDN, both as defined in Section 2.3.1.
1. dCDN requests CDNI path metadata to uCDN; 1. dCDN requests CDNI path metadata to uCDN.
2. uCDN replies with, among other CDNI metadata, the STAR 2. uCDN replies with, among other CDNI metadata, the STAR
delegation configuration, which includes the delegated Content delegation configuration, which includes the delegated content
Provider's name; provider's name.
3. dCDN creates a key-pair and the CSR with the delegated name. It
then places an order for the delegated name to uCDN; 3. dCDN creates a key pair and the CSR with the delegated name. It
4. uCDN forwards the received order to the Content Provider (CP); then places an order for the delegated name to uCDN.
4. uCDN forwards the received order to the content provider (CP).
5. CP creates an order for a STAR certificate and sends it to the 5. CP creates an order for a STAR certificate and sends it to the
CA. The order also requests unauthenticated access to the CA. The order also requests unauthenticated access to the
certificate resource; certificate resource.
6. After all authorizations complete successfully, the STAR 6. After all authorizations complete successfully, the STAR
certificate is issued; certificate is issued.
7. CP notifies uCDN that the STAR certificate is available at the 7. CP notifies uCDN that the STAR certificate is available at the
order's star-certificate URL; order's "star-certificate" URL.
8. uCDN forwards the information to dCDN. At this point the ACME
signalling is complete; 8. uCDN forwards the information to dCDN. At this point, the ACME
signaling is complete.
9. dCDN requests the STAR certificate using unauthenticated GET 9. dCDN requests the STAR certificate using unauthenticated GET
from the CA; from the CA.
10. the CA returns the certificate. Now dCDN is fully configured to
handle HTTPS traffic in-lieu of the Content Provider.
Note that 9. and 10. repeat until the delegation expires or is 10. The CA returns the certificate. Now dCDN is fully configured to
handle HTTPS traffic in lieu of the content provider.
Note that 9 and 10 repeat until the delegation expires or is
terminated. terminated.
5.2. Secure Telephone Identity Revisited (STIR) 5.2. Secure Telephone Identity Revisited (STIR)
As a second use case, we consider the delegation of credentials in As a second use case, we consider the delegation of credentials in
the STIR ecosystem [I-D.ietf-stir-cert-delegation]. the STIR ecosystem [RFC9060].
This section uses STIR terminology. The term PASSPorT is defined in This section uses STIR terminology. The term Personal Assertion
[RFC8225], and "TNAuthList" in [RFC8226]. Token (PASSporT) is defined in [RFC8225], and "TNAuthList" is defined
in [RFC8226].
In the STIR "delegated" mode, a service provider SP2 - the NDC - In the STIR delegated mode, a service provider SP2 -- the NDC --
needs to sign PASSPorT's [RFC8225] for telephone numbers (e.g., needs to sign PASSporTs [RFC8225] for telephone numbers (e.g.,
TN=+123) belonging to another service provider, SP1 - the IdO. In TN=+123) belonging to another service provider, SP1 -- the IdO. In
order to do that, SP2 needs a STIR certificate, and private key, that order to do that, SP2 needs a STIR certificate and a private key that
includes TN=+123 in the TNAuthList [RFC8226] certificate extension. includes TN=+123 in the TNAuthList [RFC8226] certificate extension.
In details (Figure 13): In detail (Figure 13):
1. SP1 and SP2 agree on the configuration of the delegation -- in
particular, the CSR template that applies.
2. SP2 generates a private/public key pair and sends a CSR to SP1,
requesting creation of a certificate with an SP1 name, an SP2
public key, and a TNAuthList extension with the list of TNs that
SP1 delegates to SP2. (Note that the CSR sent by SP2 to SP1
needs to be validated against the CSR template agreed upon in
step 1.).
1. SP1 and SP2 agree on the configuration of the delegation - in
particular, the CSR template that applies;
2. SP2 generates a private/public key-pair and sends a CSR to SP1
requesting creation of a certificate with: SP1 name, SP2 public
key, and a TNAuthList extension with the list of TNs that SP1
delegates to SP2. (Note that the CSR sent by SP2 to SP1 needs to
be validated against the CSR template agreed upon in step 1.);
3. SP1 sends an order for the CSR to the CA. The order also 3. SP1 sends an order for the CSR to the CA. The order also
requests unauthenticated access to the certificate resource; requests unauthenticated access to the certificate resource.
4. Subsequently, after the required TNAuthList authorizations are 4. Subsequently, after the required TNAuthList authorizations are
successfully completed, the CA moves the order to a "valid" successfully completed, the CA moves the order to a "valid"
state; at the same time the star-certificate endpoint is state; at the same time, the star-certificate endpoint is
populated; populated.
5. The order contents are forwarded from SP1 to SP2 by means of the
paired "delegation" order; 5. The contents of the order are forwarded from SP1 to SP2 by means
of the paired "delegation" order.
6. SP2 dereferences the "star-certificate" URL in the order to fetch
the rolling STAR certificate bearing the delegated identifiers.
6. SP2 dereferences the star-certificate URL in the order to fetch
the rolling STAR certificate bearing the delegated identifiers;
7. The STAR certificate is returned to SP2. 7. The STAR certificate is returned to SP2.
.-------------------. .-------------------.
| .------.------. | | .------.------. |
| | STAR | STAR |<--------------. | | STAR | STAR |<--------------.
.-->| SP1 | dele | dele | | | .-->| SP1 | dele | dele | | |
| | | srv | cli +-----. | | | | srv | cli +-----. |
| | '----+-'------' | | 4 | | '----+-'------' | | 4
| '------^--|---------' 3 | | '------^--|---------' 3 |
| | | | .----|-----. | | | | .----|-----.
skipping to change at page 29, line 35 skipping to change at line 1312
| | .-+----.------. | | 7 | | .-+----.------. | | 7
| | | STAR | +-----' | | | | STAR | +-----' |
'-->| SP2 | dele | HTTP | | | '-->| SP2 | dele | HTTP | | |
| | cli | |<--------------' | | cli | |<--------------'
| '----+-'-+----' | | '----+-'-+----' |
'-------------------' '-------------------'
Figure 13: Delegation in STIR Figure 13: Delegation in STIR
As shown, the STAR delegation profile described in this document As shown, the STAR delegation profile described in this document
applies straightforwardly, the only extra requirement being the applies straightforwardly; the only extra requirement being the
ability to instruct the NDC about the allowed TNAuthList values. ability to instruct the NDC about the allowed TNAuthList values.
This can be achieved by a simple extension to the CSR template. This can be achieved by a simple extension to the CSR template.
6. IANA Considerations 6. IANA Considerations
[[RFC Editor: please replace XXXX below by the RFC number.]]
6.1. New Fields in the "meta" Object within a Directory Object 6.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 registry: Metadata Fields" registry:
+=======================+============+===========+ +=======================+============+===========+
| Field Name | Field Type | Reference | | Field Name | Field Type | Reference |
+=======================+============+===========+ +=======================+============+===========+
| delegation-enabled | boolean | RFC XXXX | | delegation-enabled | boolean | RFC 9115 |
+-----------------------+------------+-----------+ +-----------------------+------------+-----------+
| allow-certificate-get | boolean | RFC XXXX | | allow-certificate-get | boolean | RFC 9115 |
+-----------------------+------------+-----------+ +-----------------------+------------+-----------+
Table 1 Table 1
6.2. New Fields in the Order Object 6.2. New Fields in the Order Object
This document adds the following entries to the ACME Order Object This document adds the following entries to the "ACME Order Object
Fields registry: Fields" registry:
+=======================+============+==============+===========+ +=======================+============+==============+===========+
| Field Name | Field Type | Configurable | Reference | | Field Name | Field Type | Configurable | Reference |
+=======================+============+==============+===========+ +=======================+============+==============+===========+
| allow-certificate-get | boolean | true | RFC XXXX | | allow-certificate-get | boolean | true | RFC 9115 |
+-----------------------+------------+--------------+-----------+ +-----------------------+------------+--------------+-----------+
| delegation | string | true | RFC XXXX | | delegation | string | true | RFC 9115 |
+-----------------------+------------+--------------+-----------+ +-----------------------+------------+--------------+-----------+
Table 2 Table 2
6.3. New Fields in the Account Object 6.3. New Fields in the Account Object
This document adds the following entries to the ACME Account Object This document adds the following entries to the "ACME Account Object
Fields registry: Fields" registry:
+=============+============+==========+===========+ +=============+============+==========+===========+
| Field Name | Field Type | Requests | Reference | | Field Name | Field Type | Requests | Reference |
+=============+============+==========+===========+ +=============+============+==========+===========+
| delegations | string | none | RFC XXXX | | delegations | string | none | RFC 9115 |
+-------------+------------+----------+-----------+ +-------------+------------+----------+-----------+
Table 3 Table 3
Note that the "delegations" field is only reported by ACME servers Note that the "delegations" field is only reported by ACME servers
that have "delegation-enabled" set to true in their meta Object. that have "delegation-enabled" set to true in their meta Object.
6.4. New Error Types 6.4. New Error Types
This document adds the following entries to the ACME Error Type This document adds the following entries to the "ACME Error Types"
registry: registry:
+===================+================================+===========+ +===================+================================+===========+
| Type | Description | Reference | | Type | Description | Reference |
+===================+================================+===========+ +===================+================================+===========+
| unknownDelegation | An unknown configuration is | RFC XXXX | | unknownDelegation | An unknown configuration is | RFC 9115 |
| | listed in the "delegations" | | | | listed in the "delegation" | |
| | attribute of the request Order | | | | attribute of the order request | |
+-------------------+--------------------------------+-----------+ +-------------------+--------------------------------+-----------+
Table 4 Table 4
6.5. CSR Template Extensions 6.5. CSR Template Extensions
IANA is requested to establish a registry "STAR Delegation CSR IANA is requested to establish a registry, "STAR Delegation CSR
Template Extensions", with "Specification Required" as its Template Extensions", with "Specification Required" as its
registration procedure. registration procedure.
Each extension registered must specify: Each extension registered must specify:
* An extension name. * an extension name,
* An extension syntax, as a reference to a CDDL document that
defines this extension. * an extension syntax, as a reference to a CDDL document that
* The extension's mapping into an X.509 certificate extension. defines this extension, and
* the extension's mapping into an X.509 certificate extension.
The initial contents of this registry are the extensions defined by The initial contents of this registry are the extensions defined by
the CDDL in Appendix B. the CDDL in Appendix A.
+==================+===========+===============================+ +==================+===========+===============================+
| Extension Name | Extension | Mapping to X.509 Certificate | | Extension Name | Extension | Mapping to X.509 Certificate |
| | Syntax | Extension | | | Syntax | Extension |
+==================+===========+===============================+ +==================+===========+===============================+
| keyUsage | See | [RFC5280], Section 4.2.1.3 | | keyUsage | See | [RFC5280], Section 4.2.1.3 |
| | Appendix | | | | Appendix | |
| | B | | | | A | |
+------------------+-----------+-------------------------------+ +------------------+-----------+-------------------------------+
| extendedKeyUsage | See | [RFC5280], Section 4.2.1.12 | | extendedKeyUsage | See | [RFC5280], Section 4.2.1.12 |
| | Appendix | | | | Appendix | |
| | B | | | | A | |
+------------------+-----------+-------------------------------+ +------------------+-----------+-------------------------------+
| subjectAltName | See | [RFC5280], Section 4.2.1.6 | | subjectAltName | See | [RFC5280], Section 4.2.1.6 |
| | Appendix | (note that only specific name | | | Appendix | (note that only specific name |
| | B | formats are allowed: URI, DNS | | | A | formats are allowed: URI, DNS |
| | | name, email address) | | | | name, email address) |
+------------------+-----------+-------------------------------+ +------------------+-----------+-------------------------------+
Table 5 Table 5
When evaluating a request for an assignment in this registry, the When evaluating a request for an assignment in this registry, the
designated expert should follow this guidance: designated expert should follow this guidance:
* The definition must include a full CDDL definition, which the * The definition must include a full CDDL definition, which the
expert will validate. expert will validate.
skipping to change at page 32, line 19 skipping to change at line 1436
definition are allowed but must be explicitly specified. definition are allowed but must be explicitly specified.
7. Security Considerations 7. Security Considerations
7.1. Trust Model 7.1. Trust Model
The ACME trust model needs to be extended to include the trust The ACME trust model needs to be extended to include the trust
relationship between NDC and IdO. Note that once this trust link is relationship between NDC and IdO. Note that once this trust link is
established, it potentially becomes recursive. Therefore, there has established, it potentially becomes recursive. Therefore, there has
to be a trust relationship between each of the nodes in the to be a trust relationship between each of the nodes in the
delegation chain; for example, in case of cascading CDNs this is delegation chain; for example, in case of cascading CDNs, this is
contractually defined. Note that using standard [RFC6125] identity contractually defined. Note that when using standard [RFC6125]
verification there are no mechanisms available to the IdO to restrict identity verification, there are no mechanisms available to the IdO
the use of the delegated name once the name has been handed over to to restrict the use of the delegated name once the name has been
the first NDC. It is therefore expected that contractual measures handed over to the first NDC. It is, therefore, expected that
are in place to get some assurance that re-delegation is not being contractual measures are in place to get some assurance that
performed. redelegation is not being performed.
7.2. Delegation Security Goal 7.2. Delegation Security Goal
Delegation introduces a new security goal: only an NDC that has been Delegation introduces a new security goal: only an NDC that has been
authorised by the IdO, either directly or transitively, can obtain a authorized by the IdO, either directly or transitively, can obtain a
certificate with an IdO identity. certificate with an IdO identity.
From a security point of view, the delegation process has five From a security point of view, the delegation process has five
separate parts: separate parts:
1. Enabling a specific third party (the intended NDC) to submit 1. enabling a specific third party (the intended NDC) to submit
requests for delegated certificates; requests for delegated certificates
2. Making sure that any request for a delegated certificate matches
2. making sure that any request for a delegated certificate matches
the intended "shape" in terms of delegated identities as well as the intended "shape" in terms of delegated identities as well as
any other certificate metadata, e.g., key length, x.509 any other certificate metadata, e.g., key length, x.509
extensions, etc.; extensions, etc.
3. Serving the certificate back to the NDC;
4. A process for handling revocation of the delegation; 3. serving the certificate back to the NDC
5. A process for handling revocation of the certificate itself.
4. handling revocation of the delegation
5. handling revocation of the certificate itself
The first part is covered by the NDC's ACME account that is The first part is covered by the NDC's ACME account that is
administered by the IdO, whose security relies on the correct administered by the IdO, whose security relies on the correct
handling of the associated key pair. When a compromise of the handling of the associated key pair. When a compromise of the
private key is detected, the delegate MUST use the account private key is detected, the delegate MUST use the account
deactivation procedures defined in Section 7.3.6 of [RFC8555]. deactivation procedures defined in Section 7.3.6 of [RFC8555].
The second part is covered by the act of checking an NDC's The second part is covered by the act of checking an NDC's
certificate request against the intended CSR template. The steps of certificate request against the intended CSR template. The steps of
shaping the CSR template correctly, selecting the right CSR template shaping the CSR template correctly, selecting the right CSR template
to check against the presented CSR, and making sure that the to check against the presented CSR, and making sure that the
presented CSR matches the selected CSR template are all security presented CSR matches the selected CSR template are all security
relevant. relevant.
The third part builds on the trust relationship between NDC and IdO The third part builds on the trust relationship between NDC and IdO
that is responsible for correctly forwarding the certificate URL from that is responsible for correctly forwarding the certificate URL from
the Order returned by the CA. the Order returned by the CA.
The fourth part is associated with the ability of the IdO to The fourth part is associated with the ability of the IdO to
unilaterally remove the delegation object associated with the revoked unilaterally remove the "delegation" object associated with the
identity, therefore disabling any further NDC requests for such revoked identity, therefore, disabling any further NDC requests for
identity. Note that, in more extreme circumstances, the IdO might such identity. Note that, in more extreme circumstances, the IdO
decide to disable the NDC account thus entirely blocking any further might decide to disable the NDC account, thus entirely blocking any
interaction. further interaction.
The fifth is covered by two different mechanisms, depending on the The fifth is covered by two different mechanisms, depending on the
nature of the certificate. For STAR, the IdO shall use the nature of the certificate. For STAR, the IdO shall use the
cancellation interface defined in Section 2.3 of [RFC8739]. For non- cancellation interface defined in Section 2.3 of [RFC8739]. For non-
STAR, the certificate revocation interface defined in Section 7.6 of STAR, the certificate revocation interface defined in Section 7.6 of
[RFC8555]) is used. [RFC8555]) is used.
The ACME account associated with the delegation plays a crucial role The ACME account associated with the delegation plays a crucial role
in the overall security of the presented protocol. This, in turn, in the overall security of the presented protocol. This, in turn,
means that in delegation scenarios the security requirements and means that (in delegation scenarios) the security requirements and
verification associated with an ACME account may be more stringent verification associated with an ACME account may be more stringent
than in traditional ACME, since the out-of-band configuration of than in base ACME deployments, since the out-of-band configuration of
delegations that an account is authorized to use, combined with delegations that an account is authorized to use (combined with
account authentication, takes the place of the normal ACME account authentication) takes the place of the normal ACME
authorization challenge procedures. Therefore, the IdO MUST ensure authorization challenge procedures. Therefore, the IdO MUST ensure
that each account is associated with the exact policies (via their that each account is associated with the exact policies (via their
matching "delegation" objects) that define which domain names can be matching "delegation" objects) that define which domain names can be
delegated to the account and how. The IdO is expected to use out of delegated to the account and how. The IdO is expected to use out-of-
band means to pre-register each NDC to the corresponding account. band means to preregister each NDC to the corresponding account.
7.3. New ACME Channels 7.3. New ACME Channels
Using the model established in Section 10.1 of [RFC8555], we can Using the model established in Section 10.1 of [RFC8555], we can
decompose the interactions of the basic delegation workflow as shown decompose the interactions of the basic delegation workflow, as shown
in Figure 14. in Figure 14.
.-----. ACME Channel .--------. .-----. ACME Channel .--------.
| NDC +------------->| IdO | | NDC +------------->| IdO |
'--+--' | server | '--+--' | server |
| '--o-----' | '--o-----'
| | | |
| | ACME Channel | | ACME Channel
| | .------------>-------------. | | .------------>-------------.
| | | | | | | |
skipping to change at page 34, line 29 skipping to change at line 1540
'-------------------->-------------------------------' '-------------------->-------------------------------'
(subset of) ACME Channel [1] (subset of) ACME Channel [1]
[1] Unauthenticated certificate fetch and non-STAR certificate [1] Unauthenticated certificate fetch and non-STAR certificate
revocation. revocation.
Figure 14: Delegation Channels Topology Figure 14: Delegation Channels Topology
The considerations regarding the security of the ACME Channel and The considerations regarding the security of the ACME Channel and
Validation Channel discussed in [RFC8555] apply verbatim to the IdO- Validation Channel discussed in [RFC8555] apply verbatim to the IdO-
CA leg. The same can be said for the ACME channel on the NDC-IdO CA leg. The same can be said for the ACME Channel on the NDC-IdO
leg. A slightly different set of considerations apply to the ACME leg. A slightly different set of considerations apply to the ACME
Channel between NDC and CA, which consists of a subset of the ACME Channel between the NDC and CA, which consists of a subset of the
interface comprising two API endpoints: the unauthenticated ACME interface comprising two API endpoints: the unauthenticated
certificate retrieval and, potentially, non-STAR revocation via certificate retrieval and, potentially, non-STAR revocation via
certificate private key. No specific security considerations apply certificate private key. No specific security considerations apply
to the former, but the privacy considerations in Section 6.3 of to the former, but the privacy considerations in Section 6.3 of
[RFC8739] do. With regards to the latter, it should be noted that [RFC8739] do. With regard to the latter, it should be noted that
there is currently no means for an IdO to disable authorising there is currently no means for an IdO to disable authorizing
revocation based on certificate private keys. So, in theory, an NDC revocation based on certificate private keys. So, in theory, an NDC
could use the revocation API directly with the CA, therefore could use the revocation API directly with the CA, therefore,
bypassing the IdO. The NDC SHOULD NOT directly use the revocation bypassing the IdO. The NDC SHOULD NOT directly use the revocation
interface exposed by the CA unless failing to do so would compromise interface exposed by the CA unless failing to do so would compromise
the overall security, for example if the certificate private key is the overall security, for example, if the certificate private key is
compromised and the IdO is not currently reachable. compromised and the IdO is not currently reachable.
All other security considerations from [RFC8555] and [RFC8739] apply All other security considerations from [RFC8555] and [RFC8739] apply
as-is to the delegation topology. as is to the delegation topology.
7.4. Restricting CDNs to the Delegation Mechanism 7.4. Restricting CDNs to the Delegation Mechanism
When a web site is delegated to a CDN, the CDN can in principle When a website is delegated to a CDN, the CDN can in principle modify
modify the web site at will, create and remove pages. This means the website at will, e.g., create and remove pages. This means that
that a malicious or breached CDN can pass the ACME (as well as common a malicious or breached CDN can pass the ACME (as well as common non-
non-ACME) HTTPS-based validation challenges and generate a ACME) HTTPS-based validation challenges and generate a certificate
certificate for the site. This is true regardless of whether the for the site. This is true regardless of whether or not the CNAME
CNAME mechanisms defined in the current document is used or not. mechanisms defined in the current document is used.
In some cases, this is the desired behavior: the domain holder trusts In some cases, this is the desired behavior; the domain holder 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
site. The current document however assumes a scenario where the site. However, this document assumes a scenario where the domain
domain holder only wants to delegate restricted control, and wishes holder only wants to delegate restricted control and wishes to retain
to retain the capability to cancel the CDN's credentials at a short the capability to cancel the CDN's credentials at a short notice.
notice.
The following is a possible mitigation when the IdO wishes to ensure The following is a possible mitigation when the IdO wishes to ensure
that a rogue CDN cannot issue unauthorized certificates: that a rogue CDN cannot issue unauthorized certificates:
* The domain holder makes sure that the CDN cannot modify the DNS * The domain holder makes sure that the CDN cannot modify the DNS
records for the domain. The domain holder should ensure it is the records for the domain. The domain holder 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.
* The domain holder uses a CAA record [RFC8659] to restrict
certificate issuance for the domain to specific CAs that comply * The domain holder uses a Certification Authority Authorization
with ACME and are known to implement [RFC8657]. (CAA) record [RFC8659] to restrict certificate issuance for the
domain to specific CAs that comply with ACME and are known to
implement [RFC8657].
* The domain holder uses the ACME-specific CAA mechanism [RFC8657] * The domain holder uses the ACME-specific CAA mechanism [RFC8657]
to restrict issuance to a specific account key which is controlled to restrict issuance to a specific CA account that is controlled
by it, and MUST require "dns-01" as the sole validation method. by it and MUST require "dns-01" as the sole validation method.
We note that the above solution may need to be tweaked depending on We note that the above solution may need to be tweaked depending on
the exact capabilities and authorisation flows supported by the the exact capabilities and authorization flows supported by the
selected CA. In addition, this mitigation may be bypassed if a selected CA. In addition, this mitigation may be bypassed if a
malicious or misconfigured CA does not comply with CAA restrictions. malicious or misconfigured CA does not comply with CAA restrictions.
8. Acknowledgments 8. References
We would like to thank the following people who contributed
significantly to this document with their review comments and design
proposals: Richard Barnes, Carsten Bormann, Roman Danyliw, Lars
Eggert, Frédéric Fieau, Russ Housley, Ben Kaduk, Eric Kline, Sanjay
Mishra, Francesca Palombini, Jon Peterson, Ryan Sleevi, Emile
Stephan, Éric Vyncke.
This work is partially supported by the European Commission under
Horizon 2020 grant agreement no. 688421 Measurement and Architecture
for a Middleboxed Internet (MAMI). This support does not imply
endorsement.
9. References
9.1. Normative References 8.1. Normative References
[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>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986, Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000, DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/info/rfc2986>. <https://www.rfc-editor.org/info/rfc2986>.
skipping to change at page 37, line 12 skipping to change at line 1643
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8739] Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor [RFC8739] Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor
Perales, A., and T. Fossati, "Support for Short-Term, Perales, A., and T. Fossati, "Support for Short-Term,
Automatically Renewed (STAR) Certificates in the Automated Automatically Renewed (STAR) Certificates in the Automated
Certificate Management Environment (ACME)", RFC 8739, Certificate Management Environment (ACME)", RFC 8739,
DOI 10.17487/RFC8739, March 2020, DOI 10.17487/RFC8739, March 2020,
<https://www.rfc-editor.org/info/rfc8739>. <https://www.rfc-editor.org/info/rfc8739>.
9.2. Informative References 8.2. Informative References
[I-D.ietf-acme-authority-token-tnauthlist]
Wendt, C., Hancock, D., Barnes, M., and J. Peterson,
"TNAuthList profile of ACME Authority Token", Work in
Progress, Internet-Draft, draft-ietf-acme-authority-token-
tnauthlist-08, 27 March 2021,
<https://www.ietf.org/archive/id/draft-ietf-acme-
authority-token-tnauthlist-08.txt>.
[I-D.ietf-cdni-interfaces-https-delegation] [HTTPS-DELEGATION]
Fieau, F., Stephan, E., and S. Mishra, "CDNI extensions Fieau, F., Stephan, E., and S. Mishra, "CDNI extensions
for HTTPS delegation", Work in Progress, Internet-Draft, for HTTPS delegation", Work in Progress, Internet-Draft,
draft-ietf-cdni-interfaces-https-delegation-05, 12 March draft-ietf-cdni-interfaces-https-delegation-05, 12 March
2021, <https://www.ietf.org/archive/id/draft-ietf-cdni- 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-
interfaces-https-delegation-05.txt>. cdni-interfaces-https-delegation-05>.
[I-D.ietf-stir-cert-delegation]
Peterson, J., "STIR Certificate Delegation", Work in
Progress, Internet-Draft, draft-ietf-stir-cert-delegation-
04, 22 February 2021, <https://www.ietf.org/archive/id/
draft-ietf-stir-cert-delegation-04.txt>.
[I-D.ietf-tls-subcerts] [json-schema-07]
Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, Wright, A., Andrews, H., and B. Hutton, "JSON Schema
"Delegated Credentials for TLS", Work in Progress, Validation: A Vocabulary for Structural Validation of
Internet-Draft, draft-ietf-tls-subcerts-10, 24 January JSON", Work in Progress, Internet-Draft, draft-handrews-
2021, <https://www.ietf.org/archive/id/draft-ietf-tls- json-schema-validation-02, 17 September 2019,
subcerts-10.txt>. <https://datatracker.ietf.org/doc/html/draft-handrews-
json-schema-validation-02>.
[I-D.mglt-lurk-tls13] [MGLT-LURK-TLS13]
Migault, D., "LURK Extension version 1 for (D)TLS 1.3 Migault, D., "LURK Extension version 1 for (D)TLS 1.3
Authentication", Work in Progress, Internet-Draft, draft- Authentication", Work in Progress, Internet-Draft, draft-
mglt-lurk-tls13-04, 25 January 2021, mglt-lurk-tls13-05, 26 July 2021,
<https://www.ietf.org/archive/id/draft-mglt-lurk- <https://datatracker.ietf.org/doc/html/draft-mglt-lurk-
tls13-04.txt>. tls13-05>.
[json-schema-07]
Wright, A., Andrews, H., and G. Luff, "JSON Schema
Validation: A Vocabulary for Structural Validation of
JSON", 2018, <https://datatracker.ietf.org/doc/html/draft-
handrews-json-schema-validation-01>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>. 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
"Framework for Content Distribution Network "Framework for Content Distribution Network
skipping to change at page 38, line 43 skipping to change at line 1699
Record Extensions for Account URI and Automatic Record Extensions for Account URI and Automatic
Certificate Management Environment (ACME) Method Binding", Certificate Management Environment (ACME) Method Binding",
RFC 8657, DOI 10.17487/RFC8657, November 2019, RFC 8657, DOI 10.17487/RFC8657, November 2019,
<https://www.rfc-editor.org/info/rfc8657>. <https://www.rfc-editor.org/info/rfc8657>.
[RFC8659] Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews, [RFC8659] Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews,
"DNS Certification Authority Authorization (CAA) Resource "DNS Certification Authority Authorization (CAA) Resource
Record", RFC 8659, DOI 10.17487/RFC8659, November 2019, Record", RFC 8659, DOI 10.17487/RFC8659, November 2019,
<https://www.rfc-editor.org/info/rfc8659>. <https://www.rfc-editor.org/info/rfc8659>.
Appendix A. Document History [RFC9060] Peterson, J., "Secure Telephone Identity Revisited (STIR)
Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060,
[[Note to RFC Editor: please remove before publication.]] August 2021, <https://www.rfc-editor.org/info/rfc9060>.
A.1. draft-ietf-acme-star-delegation-09
* A few remaining comments by Ben Kaduk.
A.2. draft-ietf-acme-star-delegation-08
Extensive reviews by multiple IETF contributors and IESG members
(many thanks to all involved, your names are in the Acknowledgments).
Specifically:
* More clarity in the Terminology, and correct distinction between
CA and ACME server.
* Explicit description of "delegations list", the object returned by
the "delegations" URL.
* The "delegation" is no longer part of the identifier, rather it is
a property of the order.
* Clarified the negotiation of unauthenticated GET for fetching
certificates. This includes some normative changes.
* Explicit description of the changes required on the CA: support
for unauthenticated GET.
* Some changes to IANA registrations and a change to the
registration policy of a new registry.
* More detail about security considerations related to pre-
registration of the NDC as an ACME account on IdO.
* Minor changes to the CSR Template schemas.
* Many editorial changes.
A.3. draft-ietf-acme-star-delegation-07
* SecDir comments by Russ Housley.
* In particular, reorganized some parts of the document to clarify
handling of non-STAR certificates.
* And changed the document's title accordingly.
A.4. draft-ietf-acme-star-delegation-06
* CDDL schema to address Roman's remaining comments.
A.5. draft-ietf-acme-star-delegation-05
* Detailed AD review by Roman Danyliw.
* Some comments that were left unaddressed in Ryan Sleevi's review.
* Numerous other edits for clarity and consistency.
A.6. draft-ietf-acme-star-delegation-04
* Delegation of non-STAR certificates.
* More IANA clarity, specifically on certificate extensions.
* Add delegation configuration object and extend account and order
objects accordingly.
* A lot more depth on Security Considerations.
A.7. draft-ietf-acme-star-delegation-03
* Consistency with the latest changes in the base ACME STAR
document, e.g. star-delegation-enabled capability renamed and
moved.
* Proxy use cases (recursive delegation) and the definition of proxy
behavior.
* More detailed analysis of the CDNI and STIR use cases, including
sequence diagrams.
A.8. draft-ietf-acme-star-delegation-02
* Security considerations: review by Ryan Sleevi.
* CSR template simplified: instead of being a JSON Schema document
itself, it is now a simple JSON document which validates to a JSON
Schema.
A.9. draft-ietf-acme-star-delegation-01
* Refinement of the CDNI use case.
* Addition of the CSR template (partial, more work required).
* Further security considerations (work in progress).
A.10. draft-ietf-acme-star-delegation-00
* Republished as a working group draft.
A.11. draft-sheffer-acme-star-delegation-01
* Added security considerations about disallowing CDNs from issuing
certificates for a delegated domain.
A.12. draft-sheffer-acme-star-delegation-00 [TLS-SUBCERTS]
Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla,
"Delegated Credentials for TLS", Work in Progress,
Internet-Draft, draft-ietf-tls-subcerts-10, 24 January
2021, <https://datatracker.ietf.org/doc/html/draft-ietf-
tls-subcerts-10>.
* Initial version, some text extracted from draft-sheffer-acme-star- [TOKEN-TNAUTHLIST]
requests-02 Wendt, C., Hancock, D., Barnes, M., and J. Peterson,
"TNAuthList profile of ACME Authority Token", Work in
Progress, Internet-Draft, draft-ietf-acme-authority-token-
tnauthlist-08, 27 March 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-acme-
authority-token-tnauthlist-08>.
Appendix B. CSR Template: CDDL Appendix A. CSR Template: CDDL
Following is the normative definition of the CSR template, using CDDL Following is the normative definition of the CSR template using CDDL
[RFC8610]. The CSR template MUST be a valid JSON document, compliant [RFC8610]. The CSR template MUST be a valid JSON document that is
with the syntax defined here. compliant with the syntax defined here.
There are additional constraints not expressed in CDDL that MUST be There are additional constraints not expressed in CDDL that MUST be
validated by the recipient, including: validated by the recipient, including:
* The value of each "subjectAltName" entry is compatible with its * the value of each "subjectAltName" entry is compatible with its
type; type and
* The parameters in each "keyTypes" entry form an acceptable * the parameters in each "keyTypes" entry form an acceptable
combination. combination.
csr-template-schema = { csr-template-schema = {
keyTypes: [ + $keyType ] keyTypes: [ + $keyType ]
? subject: non-empty<distinguishedName> ? subject: non-empty<distinguishedName>
extensions: extensions extensions: extensions
} }
non-empty<M> = (M) .and ({ + any => any }) non-empty<M> = (M) .and ({ + any => any })
skipping to change at page 43, line 9 skipping to change at line 1831
extendedKeyUsageType /= "serverAuth" extendedKeyUsageType /= "serverAuth"
extendedKeyUsageType /= "clientAuth" extendedKeyUsageType /= "clientAuth"
extendedKeyUsageType /= "codeSigning" extendedKeyUsageType /= "codeSigning"
extendedKeyUsageType /= "emailProtection" extendedKeyUsageType /= "emailProtection"
extendedKeyUsageType /= "timeStamping" extendedKeyUsageType /= "timeStamping"
extendedKeyUsageType /= "OCSPSigning" extendedKeyUsageType /= "OCSPSigning"
extendedKeyUsageType /= oid extendedKeyUsageType /= oid
oid = text .regexp "([0-2])((\.0)|(\.[1-9][0-9]*))*" oid = text .regexp "([0-2])((\.0)|(\.[1-9][0-9]*))*"
Appendix C. CSR Template: JSON Schema Appendix B. CSR Template: JSON Schema
This appendix includes an alternative, non-normative, JSON Schema This appendix includes an alternative, nonnormative JSON Schema
definition of the CSR template. The syntax used is that of draft 7 definition of the CSR template. The syntax used is that of draft 7
of JSON Schema, which is documented in [json-schema-07]. Note that of JSON Schema, which is documented in [json-schema-07]. Note that
later versions of this (now expired) draft describe later versions of later versions of this (now-expired) draft describe later versions of
the JSON Schema syntax. At the time of writing, a stable reference the JSON Schema syntax. At the time of writing, a stable reference
for this syntax is not yet available, and we have chosen to use the for this syntax is not yet available, and we have chosen to use the
draft version which is currently best supported by tool draft version, which is currently best supported by tool
implementations. implementations.
The same considerations about additional constraints checking The same considerations about additional constraints checking
discussed in Appendix B apply here as well. discussed in Appendix A apply here as well.
{ {
"title": "JSON Schema for the STAR Delegation CSR template", "title": "JSON Schema for the STAR Delegation CSR template",
"$schema": "http://json-schema.org/draft-07/schema#", "$schema": "http://json-schema.org/draft-07/schema#",
"$id": "http://ietf.org/acme/drafts/star-delegation/csr-template", "$id": "http://ietf.org/acme/drafts/star-delegation/csr-template",
"$defs": { "$defs": {
"distinguished-name": { "distinguished-name": {
"$id": "#distinguished-name", "$id": "#distinguished-name",
"type": "object", "type": "object",
"minProperties": 1, "minProperties": 1,
skipping to change at page 47, line 48 skipping to change at line 2062
"additionalProperties": false "additionalProperties": false
} }
}, },
"required": [ "required": [
"extensions", "extensions",
"keyTypes" "keyTypes"
], ],
"additionalProperties": false "additionalProperties": false
} }
Acknowledgements
We would like to thank the following people who contributed
significantly to this document with their review comments and design
proposals: Richard Barnes, Carsten Bormann, Roman Danyliw, Lars
Eggert, Frédéric Fieau, Russ Housley, Ben Kaduk, Eric Kline, Sanjay
Mishra, Francesca Palombini, Jon Peterson, Ryan Sleevi, Emile
Stephan, and Éric Vyncke.
This work is partially supported by the European Commission under
Horizon 2020 grant agreement no. 688421 Measurement and Architecture
for a Middleboxed Internet (MAMI). This support does not imply
endorsement.
Authors' Addresses Authors' Addresses
Yaron Sheffer Yaron Sheffer
Intuit Intuit
Email: yaronf.ietf@gmail.com Email: yaronf.ietf@gmail.com
Diego López Diego López
Telefonica I+D Telefonica I+D
Email: diego.r.lopez@telefonica.com Email: diego.r.lopez@telefonica.com
 End of changes. 202 change blocks. 
632 lines changed or deleted 586 lines changed or added

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