draft-ietf-acme-star-delegation-07.txt   draft-ietf-acme-star-delegation-08.txt 
ACME Y. Sheffer ACME Y. Sheffer
Internet-Draft Intuit Internet-Draft Intuit
Intended status: Standards Track D. López Intended status: Standards Track D. López
Expires: 27 September 2021 A. Pastor Perales Expires: 11 November 2021 A. Pastor Perales
Telefonica I+D Telefonica I+D
T. Fossati T. Fossati
ARM ARM
26 March 2021 10 May 2021
An ACME Profile for Generating Delegated Certificates An ACME Profile for Generating Delegated Certificates
draft-ietf-acme-star-delegation-07 draft-ietf-acme-star-delegation-08
Abstract Abstract
This memo defines a profile of the Automatic Certificate Management This document defines a profile of the Automatic Certificate
Environment (ACME) protocol by which the owner of an identifier Management Environment (ACME) protocol by which the holder of an
(e.g., a domain name) can allow a third party to obtain an X.509 identifier (e.g., a domain name) can allow a third party to obtain an
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 owner of a domain sessions on behalf of a content provider (the holder of a domain
name). The presented mechanism allows the owner of the identifier to name). The presented mechanism allows the holder of the identifier
retain control over the delegation and revoke it at any time. A key to retain control over the delegation and revoke it at any time.
property of this mechanism is it does not require any modification to Importantly, this mechanism does not require any modification to the
the deployed TLS ecosystem. deployed TLS clients and servers.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 27 September 2021. This Internet-Draft will expire on 11 November 2021.
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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 30 skipping to change at page 2, line 30
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Conventions used in this document . . . . . . . . . . . . 5 1.2. Conventions used in this document . . . . . . . . . . . . 5
2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Delegated Identity Profile . . . . . . . . . . . . . . . 8 2.3. Delegated Identity Profile . . . . . . . . . . . . . . . 8
2.3.1. Delegation Configuration . . . . . . . . . . . . . . 8 2.3.1. Delegation Configuration . . . . . . . . . . . . . . 8
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) . . . . . . . . . . . . . . . . . . . . 10 Server (STAR) . . . . . . . . . . . . . . . . . . . . 11
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) . . . . . . . . . . . . . . . . . . 13 Server (non-STAR) . . . . . . . . . . . . . . . . . . 15
2.3.4. Capability Discovery . . . . . . . . . . . . . . . . 16 2.3.4. Capability Discovery . . . . . . . . . . . . . . . . 18
2.3.5. Terminating the Delegation . . . . . . . . . . . . . 16 2.3.5. Negotiating an Unauthenticated GET . . . . . . . . . 19
2.4. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 17 2.3.6. Terminating the Delegation . . . . . . . . . . . . . 20
3. CSR Template . . . . . . . . . . . . . . . . . . . . . . . . 18 2.4. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 21
3.1. Template Syntax . . . . . . . . . . . . . . . . . . . . . 19 3. CA Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 20 4. CSR Template . . . . . . . . . . . . . . . . . . . . . . . . 22
4. Further Use Cases . . . . . . . . . . . . . . . . . . . . . . 21 4.1. Template Syntax . . . . . . . . . . . . . . . . . . . . . 22
4.1. CDN Interconnection (CDNI) . . . . . . . . . . . . . . . 21 4.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.1. Multiple Parallel Delegates . . . . . . . . . . . . . 22 5. Further Use Cases . . . . . . . . . . . . . . . . . . . . . . 24
4.1.2. Chained Delegation . . . . . . . . . . . . . . . . . 22 5.1. CDN Interconnection (CDNI) . . . . . . . . . . . . . . . 24
4.2. Secure Telephone Identity Revisited (STIR) . . . . . . . 25 5.1.1. Multiple Parallel Delegates . . . . . . . . . . . . . 25
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 5.1.2. Chained Delegation . . . . . . . . . . . . . . . . . 25
5.1. New ACME Identifier Object Fields . . . . . . . . . . . . 26 5.2. Secure Telephone Identity Revisited (STIR) . . . . . . . 28
5.2. New Fields in the "meta" Object within a Directory 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
Object . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.1. New Fields in the "meta" Object within a Directory
5.3. New Fields in the Order Object . . . . . . . . . . . . . 27 Object . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4. New Fields in the Account Object . . . . . . . . . . . . 28 6.2. New Fields in the Order Object . . . . . . . . . . . . . 30
5.5. New Error Types . . . . . . . . . . . . . . . . . . . . . 28 6.3. New Fields in the Account Object . . . . . . . . . . . . 30
5.6. CSR Template Extensions . . . . . . . . . . . . . . . . . 28 6.4. New Error Types . . . . . . . . . . . . . . . . . . . . . 30
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 6.5. CSR Template Extensions . . . . . . . . . . . . . . . . . 31
6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 29
6.2. Delegation Security Goal . . . . . . . . . . . . . . . . 29 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
6.3. New ACME Channels . . . . . . . . . . . . . . . . . . . . 30 7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 32
6.4. Restricting CDNs to the Delegation Mechanism . . . . . . 31 7.2. Delegation Security Goal . . . . . . . . . . . . . . . . 32
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 7.3. New ACME Channels . . . . . . . . . . . . . . . . . . . . 33
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.4. Restricting CDNs to the Delegation Mechanism . . . . . . 35
8.1. Normative References . . . . . . . . . . . . . . . . . . 32 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
8.2. Informative References . . . . . . . . . . . . . . . . . 34 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
Appendix A. Document History . . . . . . . . . . . . . . . . . . 35 9.1. Normative References . . . . . . . . . . . . . . . . . . 36
A.1. draft-ietf-acme-star-delegation-07 . . . . . . . . . . . 35 9.2. Informative References . . . . . . . . . . . . . . . . . 37
A.2. draft-ietf-acme-star-delegation-06 . . . . . . . . . . . 35 Appendix A. Document History . . . . . . . . . . . . . . . . . . 39
A.3. draft-ietf-acme-star-delegation-05 . . . . . . . . . . . 35 A.1. draft-ietf-acme-star-delegation-08 . . . . . . . . . . . 39
A.4. draft-ietf-acme-star-delegation-04 . . . . . . . . . . . 35 A.2. draft-ietf-acme-star-delegation-07 . . . . . . . . . . . 39
A.5. draft-ietf-acme-star-delegation-03 . . . . . . . . . . . 36 A.3. draft-ietf-acme-star-delegation-06 . . . . . . . . . . . 39
A.6. draft-ietf-acme-star-delegation-02 . . . . . . . . . . . 36 A.4. draft-ietf-acme-star-delegation-05 . . . . . . . . . . . 39
A.7. draft-ietf-acme-star-delegation-01 . . . . . . . . . . . 36 A.5. draft-ietf-acme-star-delegation-04 . . . . . . . . . . . 39
A.8. draft-ietf-acme-star-delegation-00 . . . . . . . . . . . 36 A.6. draft-ietf-acme-star-delegation-03 . . . . . . . . . . . 40
A.9. draft-sheffer-acme-star-delegation-01 . . . . . . . . . . 36 A.7. draft-ietf-acme-star-delegation-02 . . . . . . . . . . . 40
A.10. draft-sheffer-acme-star-delegation-00 . . . . . . . . . . 36 A.8. draft-ietf-acme-star-delegation-01 . . . . . . . . . . . 40
Appendix B. CSR Template: CDDL . . . . . . . . . . . . . . . . . 36 A.9. draft-ietf-acme-star-delegation-00 . . . . . . . . . . . 40
Appendix C. CSR Template: JSON Schema . . . . . . . . . . . . . 39 A.10. draft-sheffer-acme-star-delegation-01 . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 A.11. draft-sheffer-acme-star-delegation-00 . . . . . . . . . . 40
Appendix B. CSR Template: CDDL . . . . . . . . . . . . . . . . . 40
Appendix C. CSR Template: JSON Schema . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
This document is a companion document to [RFC8739]. To avoid This document is related to [RFC8739], in that some important use
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 and further use cases, please for this solution. For more details, please refer to the
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. NDC (Name Delegation Consumer) 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 and, equally,
delegates would rather not have to handle other parties' long-term delegates would rather not have to handle other parties' long-term
secrets. Other relevant use cases are discussed in Section 4. secrets. 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), periodically
fetched by the NDC and used to terminate HTTPS connections in lieu of fetched by the NDC and used to terminate HTTPS connections in lieu of
the IdO. The IdO can end the delegation at any time by simply the IdO. The IdO can end the delegation at any time by simply
instructing the CA to stop the automatic renewal and letting the instructing the CA to stop the automatic renewal and letting the
certificate expire shortly thereafter. certificate expire shortly thereafter.
While the primary use case we address is delegation of STAR While the primary use case we address is delegation of STAR
certificates, the mechanism proposed here accommodates also long- certificates, the mechanism proposed here accommodates also 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 ACME CA and waits for the explicit revocation based on CRL and the CA and waits for the explicit revocation based on Certificate
OCSP to propagate to the relying parties. Revocation List (CRL) and Online Certificate Status Protocol (OCSP)
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 ongoing efforts address the problem of certificate We note that other standardization efforts address the problem of
delegation for TLS connections, specifically [I-D.ietf-tls-subcerts] certificate delegation for TLS connections, specifically
and [I-D.mglt-lurk-tls13]. Compared to these other solutions, the [I-D.ietf-tls-subcerts] and [I-D.mglt-lurk-tls13]. The former
current document does not introduce additional latency to the TLS extends the TLS certificate chain with a customer-owned signing
connection, nor does it require changes to the TLS network stack of certificate; the latter separates the server's private key into a
either the client or the server. dedicated, more secure component. Compared to these other
approaches, the current document does not require changes to the TLS
network stack of the client or the server, nor does it introduce
additional latency to the TLS connection.
1.1. Terminology 1.1. Terminology
IdO Identifier Owner, the owner of an identifier (e.g., a domain IdO Identifier Owner, the holder (current owner) of an identifier
name) that needs to be delegated. (e.g., a domain name) that needs to be delegated. Depending on
the context, the term IdO may also be used to designate the
(profiled) ACME server deployed by the Identifier Owner 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 is
delegated for a limited time. This is a CDN in the primary use delegated for a limited time. This is a CDN in the primary use
case (in fact, readers may note the symmetry of the two acronyms). case (in fact, readers may note the similarity of the two
acronyms). Depending on the context, the term NDC may also be
used to designate the (profiled) ACME client 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 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 A Certification Authority that implements the ACME protocol. In
this document, the term is synonymous with "ACME server". this document, the term is synonymous with "ACME server deployed
by the Certification Authority".
CSR A PKCS#10 [RFC2986] Certificate Signing Request, as supported by CSR A PKCS#10 [RFC2986] Certificate Signing Request, as supported by
ACME. 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
extended ACME 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; * The NDC has registered an ACME account with the IdO;
* NDC and IdO have agreed on a "CSR template" to use, including at a * NDC and IdO have agreed on a "CSR template" to use, including at a
minimum: subject name (e.g., "somesite.example.com"), requested minimum: subject name (e.g., "abc.ido.example"), requested
algorithms and key length, key usage, extensions (e.g., algorithms and key length, key usage, extensions. The NDC will
TNAuthList). The NDC is required to use this template for every use this template for every CSR created under the same delegation;
CSR created under the same delegation;
* IdO has registered an ACME account with the Certification * IdO has registered an ACME account with the Certification
Authority (CA) 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 ACME server. 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
skipping to change at page 6, line 46 skipping to change at page 7, line 13
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. This can continue until the
STAR certificate expires or the IdO decides to cancel the automatic STAR certificate expires or the IdO decides to cancel the automatic
renewal process with the CA. 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 2.3.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, to
the IdO immediately after Order1 has been acknowledged. The IdO 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
GET" (Section 3.4 of [RFC8793]) is required in order to allow the NDC
to 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 31 skipping to change at page 8, line 49
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 a 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 can be fetched via a POST- delegations configured for this account (Section 2.3.1.3) can be
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/rzGoeA", "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 Objects 2.3.1.2. Delegation Lists
Each account object includes a "delegations" URL from which a list of
delegation configurations created by the IdO can be fetched via 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
delegation configuration made available to the NDC account
(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
further entries can be acquired.
HTTP/1.1 200 OK
Content-Type: application/json
Link: <https://acme.ido.example/acme/directory>;rel="index"
Link: <https://acme.ido.example/acme/delegations/adFqoz?cursor=2>;rel="next"
{
"delegations": [
"https://acme.ido.example/acme/delegation/ogfr8EcolOT",
"https://acme.ido.example/acme/delegation/wSi5Lbb61E4",
/* more URLs not shown for example brevity */
"https://acme.ido.example/acme/delegation/gm0wfLYHBen"
]
}
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 3) 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 3. Section 4.
* cname-map (optional, object): a map of FQDN pairs. In each pair, * cname-map (optional, object): a map of FQDN pairs. In each pair,
the name is the delegated identifier, the value is the the name is the delegated identifier, the value is the
corresponding IdO 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 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"
} }
], ],
"subject": { "subject": {
"country": "CA", "country": "CA",
"stateOrProvince": "**", "stateOrProvince": "**",
"locality": "**", "locality": "**"
"commonName": "**"
}, },
"extensions": { "extensions": {
"subjectAltName": { "subjectAltName": {
"DNS": [ "DNS": [
"abc.ndc.ido.example" "abc.ido.example"
] ]
}, },
"keyUsage": [ "keyUsage": [
"digitalSignature" "digitalSignature"
], ],
"extendedKeyUsage": [ "extendedKeyUsage": [
"serverAuth" "serverAuth"
] ]
} }
}, },
"cname-map": { "cname-map": {
"abc.ndc.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
identifier in the Order object on the NDC-IdO side (see Figure 4). Order object on the NDC-IdO side (see Figure 4). The value of this
The value of this attribute is the URL pointing to the delegation attribute is the URL pointing to the delegation configuration object
configuration object that is to be used for this certificate request. that is to be used for this certificate request. If the "delegation"
If the "delegation" attribute in the Order object contains a URL that attribute in the Order object contains a URL that does not correspond
does not correspond to a configuration available to the requesting to a configuration available to the requesting ACME account, the IdO
NDC, the IdO MUST return an error response with status code 403 MUST return an error response with status code 403 (Forbidden),
(Forbidden) and type "urn:ietf:params:acme:error:unknownDelegation". providing a problem document [RFC7807] with type
"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 Order object created If the delegation is for a STAR certificate, the request object
by the NDC: created by the NDC:
* MUST have the delegated name as the identifier value with a * MUST have a "delegation" attribute indicating the preconfigured
"delegation" attribute indicating the configuration used for the delegation that applies to this Order;
identifier. * MUST have entries in the "identifiers" field for each delegated
name present in the configuration;
* MUST NOT contain the "notBefore" and "notAfter" fields; * MUST NOT contain the "notBefore" and "notAfter" fields;
* MUST contain an "auto-renewal" object and inside it, the fields * MUST contain an "auto-renewal" object and inside it, the fields
listed in Section 3.1.1 of [RFC8739]. listed in Section 3.1.1 of [RFC8739]. In particular, the "allow-
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",
"kid": "https://acme.ido.example/acme/acct/evOfKhNU60wg", "kid": "https://acme.ido.example/acme/acct/evOfKhNU60wg",
"nonce": "5XJ1L3lEkMG7tR6pA00clA", "nonce": "Alc00Ap6Rt7GMkEl3L1JX5",
"url": "https://acme.ido.example/acme/new-order" "url": "https://acme.ido.example/acme/new-order"
}), }),
"payload": base64url({ "payload": base64url({
"identifiers": [ "identifiers": [
{ {
"type": "dns", "type": "dns",
"value": "abc.ndc.ido.example.", "value": "abc.ido.example"
"delegation":
"https://acme.ido.example/acme/delegations/adFqoz/2"
} }
], ],
"auto-renewal": { "auto-renewal": {
"end-date": "2020-04-20T00:00:00Z", "end-date": "2021-04-20T00:00:00Z",
"lifetime": 345600, // 4 days "lifetime": 345600, // 4 days
"allow-certificate-get": true "allow-certificate-get": true
} },
"delegation":
"https://acme.ido.example/acme/delegations/adFqoz/2"
}), }),
"signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g" "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" configurations. * MUST contain the indicated "delegation" configuration;
* MUST contain the indicated "auto-renewal" settings;
* MUST NOT contain the "notBefore" and "notAfter" fields. * MUST NOT contain the "notBefore" and "notAfter" fields.
{ {
"status": "ready", "status": "ready",
"expires": "2019-05-01T00:00:00Z", "expires": "2021-05-01T00:00:00Z",
"identifiers": [ "identifiers": [
{ {
"type": "dns", "type": "dns",
"value": "abc.ndc.ido.example.", "value": "abc.ido.example"
"delegation":
"https://acme.ido.example/acme/delegations/adFqoz/2"
} }
], ],
"auto-renewal": { "auto-renewal": {
"end-date": "2020-04-20T00:00:00Z", "end-date": "2021-04-20T00:00:00Z",
"lifetime": 345600, "lifetime": 345600,
"allow-certificate-get": true "allow-certificate-get": true
}, },
"delegation":
"https://acme.ido.example/acme/delegations/adFqoz/2",
"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 that applies to each delegated identifier, as described the template contained in the delegation object that applies to this
in Section 3.1. If the CSR fails validation for any of the request, as described in Section 4.1. If the CSR fails validation
identifiers, the IdO MUST return an error response with status code for any of the identifiers, the IdO MUST return an error response
403 (Forbidden) and an appropriate type, e.g., "rejectedIdentifier" with status code 403 (Forbidden) and an appropriate type, e.g.,
or "badCSR". The error response SHOULD contain subproblems "rejectedIdentifier" or "badCSR". The error response SHOULD contain
(Section 6.7.1 of [RFC8555]) for each failed identifier. If the CSR subproblems (Section 6.7.1 of [RFC8555]) for each failed identifier.
is successfully validated, the Order object status moves to If the CSR is successfully validated, the Order object status moves
"processing" and the twin ACME protocol instance is initiated on the to "processing" and the twin ACME protocol instance is initiated on
IdO-CA side. the IdO-CA side.
The Order object created by the IdO: The request object created by the IdO:
* MUST copy the identifiers sent by the NDC and strip the * MUST copy the identifiers sent by the NDC;
"delegation" attribute; * MUST strip the "delegation" attribute;
* MUST carry a copy of the "auto-renewal" object sent by the NDC and * MUST carry a copy of the "auto-renewal" object sent by the NDC.
augment it with an "allow-certificate-get" attribute set to true.
When the validation of the identifiers has been successfully When the identifiers' authorization has been successfully completed
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";
* MUST copy the "star-certificate" field from the STAR Order. The * MUST copy the "star-certificate" field from the STAR Order
latter indirectly includes (via the NotBefore and NotAfter HTTP returned by the CA into its Order resource. When dereferenced,
headers) the renewal timers needed by the NDC to inform its the "star-certificate" URL includes (via the Cert-Not-Before and
certificate reload logic. Cert-Not-After HTTP header fields) the renewal timers needed by
the NDC to inform its certificate reload logic.
{ {
"status": "valid", "status": "valid",
"expires": "2019-05-01T00:00:00Z", "expires": "2021-05-01T00:00:00Z",
"identifiers": [ "identifiers": [
{ {
"type": "dns", "type": "dns",
"value": "abc.ndc.ido.example.", "value": "abc.ido.example"
"delegation":
"https://acme.ido.example/acme/delegations/adFqoz/2"
} }
], ],
"auto-renewal": { "auto-renewal": {
"end-date": "2020-04-20T00:00:00Z", "end-date": "2021-04-20T00:00:00Z",
"lifetime": 345600, "lifetime": 345600,
"allow-certificate-get": true "allow-certificate-get": true
}, },
"delegation":
"https://acme.ido.example/acme/delegations/adFqoz/2",
"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
certificates periodically using an unauthenticated HTTP GET, since in
general the NDC does not possess an account on the CA and therefore
cannot issue the standard POST-as-GET ACME request. Therefore,
before forwarding the Order request to the CA, the IdO SHOULD ensure
that the selected CA supports "unauthenticated GET" by inspecting the
relevant settings in the CA's "directory" object, as per Section 3.4
of [RFC8739]. If the CA does not support "unauthenticated GET" of
STAR certificates, the IdO MUST NOT forward the Order request.
Instead, it MUST move the Order status to "invalid" and set 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
not reflect the "allow-certificate-get" setting in its Order
resource. The combination of "invalid" status and denied "allow-
certificate-get" in the Order resource at the IdO provides an
unambiguous (asynchronous) signal to the NDC about the failure
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 an identifier object of type "dns" was included, the IdO can add
the corresponding CNAME records to its zone, e.g.: the CNAME records specified in the delegation object to its zone,
e.g.:
abc.ndc.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 Order object If the delegation is for a non-STAR certificate, the request object
created by the NDC: created by the NDC:
* MUST have the delegated name as the identifier value with a * MUST have a "delegation" attribute indicating the preconfigured
"delegation" attribute indicating the configuration used for the delegation that applies to this Order;
identifier. * MUST have entries in the "identifiers" field for each delegated
name present in the configuration;
* 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",
"nonce": "IYBkoQfaCS80UcCn9qH8Gt", "nonce": "IYBkoQfaCS80UcCn9qH8Gt",
"url": "https://acme.ido.example/acme/new-order" "url": "https://acme.ido.example/acme/new-order"
}), }),
"payload": base64url({ "payload": base64url({
"identifiers": [ "identifiers": [
{ {
"type": "dns", "type": "dns",
"value": "abc.ndc.ido.example.", "value": "abc.ido.example"
"delegation":
"https://acme.ido.example/acme/delegations/adFqoz/2"
} }
] ],
"delegation":
"https://acme.ido.example/acme/delegations/adFqoz/2",
"allow-certificate-get": true
}), }),
"signature": "H6ZyWqg8aaKEkYca...dudoz4igiMvUBJ9j" "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" configurations. * MUST contain the indicated "delegation" configuration;
* MUST contain the indicated "allow-certificate-get" setting.
{ {
"status": "ready", "status": "ready",
"expires": "2019-05-01T00:00:00Z", "expires": "2021-05-01T00:00:00Z",
"identifiers": [ "identifiers": [
{ {
"type": "dns", "type": "dns",
"value": "abc.ndc.ido.example.", "value": "abc.ido.example"
"delegation":
"https://acme.ido.example/acme/delegations/adFqoz/2"
} }
], ],
"delegation":
"https://acme.ido.example/acme/delegations/adFqoz/2",
"allow-certificate-get": true,
"authorizations": [], "authorizations": [],
"finalize": "https://acme.ido.example/acme/order/to8RFGO/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 Order object created by the IdO: The request object created by the IdO:
* MUST copy the identifiers sent by the NDC and strip the * MUST copy the identifiers sent by the NDC;
"delegation" attribute; * MUST strip the "delegation" attribute;
* MUST include the "allow-certificate-get" attribute set to true. * MUST copy the "allow-certificate-get" attribute.
When the validation of the identifiers has been successfully When the identifiers' authorization has been successfully completed
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";
* MUST copy the "certificate" field from the Order, as well as * MUST copy the "certificate" field from the Order returned by the
"notBefore" and "notAfter" if these fields exist. CA into its Order resource, as well as "notBefore" and "notAfter"
if these fields exist.
{ {
"status": "valid", "status": "valid",
"expires": "2019-05-01T00:00:00Z", "expires": "2021-05-01T00:00:00Z",
"identifiers": [ "identifiers": [
{ {
"type": "dns", "type": "dns",
"value": "abc.ndc.ido.example.", "value": "abc.ido.example"
"delegation":
"https://acme.ido.example/acme/delegations/adFqoz/2"
} }
], ],
"delegation":
"https://acme.ido.example/acme/delegations/adFqoz/2",
"allow-certificate-get": true, "allow-certificate-get": true,
"authorizations": [], "authorizations": [],
"finalize": "https://acme.ido.example/acme/order/to8RFGO/finalize", "finalize": "https://acme.ido.example/acme/order/3ZDlhYy/finalize",
"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
that the selected CA supports "unauthenticated GET" by inspecting the
relevant settings in the CA's "directory" object, as per
Section 2.3.5. If the CA does not support "unauthenticated GET" of
certificate resources, the IdO MUST NOT forward the Order request.
Instead, it MUST move the Order status to "invalid" and set the
"allow-certificate-get" attribute to "false". The same occurs in
case the Order request is forwarded and the CA does not reflect the
"allow-certificate-get" setting in its Order resource. The
combination of "invalid" status and denied "allow-certificate-get" in
the Order resource at the IdO provides an unambiguous (asynchronous)
signal to 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 to discover support for this profile, the
directory object of an ACME server MUST contain the following directory object of an ACME server (typically, one deployed by the
attribute in the "meta" field: IdO) contains the following attribute in the "meta" field:
* delegation-enabled: boolean flag indicating support for the * delegation-enabled (optional, boolean): Boolean flag indicating
profile specified in this memo. An ACME server that supports this support for the profile specified in this memo. An ACME server
delegation profile MUST include this key, and MUST set it to true. that supports this delegation profile MUST include this key, and
MUST set it to true.
The "delegation-enabled" flag may be specified regardless of the The IdO MUST declare its support for delegation using "delegation-
existence or setting of the "auto-renewal" flag. enabled" regardless of whether it supports delegation of STAR
certificates, non-STAR certificates or both.
2.3.5. Terminating the Delegation In order to help a client to discover support for certificate
fetching using unauthenticated HTTP GET, the directory object of an
ACME server (typically, one deployed by the CA) contains the
following attribute in the "meta" field:
Identity delegation is terminated differently, depending on whether * allow-certificate-get (optional, boolean): See Section 2.3.5.
2.3.5. Negotiating an Unauthenticated GET
In order to enable the name delegation of non-STAR certificates, this
document defines a mechanism that allows a server to advertise
support for accessing certificate resources via unauthenticated GET
(in addition to POST-as-GET), and a client to enable this service
with per-Order granularity.
It is worth pointing out that the protocol elements described in this
section have the same names and semantics as those introduced in
Section 3.4 of [RFC8739] for the STAR use case (except, of course,
they apply to the certificate resource rather than the star-
certificate resource). However, they differ in terms of their
position in the directory meta and order objects: rather than being
wrapped in an auto-renewal sub-object they are located at the top-
level.
A server states its availability to grant unauthenticated access to a
client's Order certificate by setting the "allow-certificate-get"
attribute to "true" in the "meta" field inside the directory object:
* allow-certificate-get (optional, boolean): If this field is
present and set to "true", the server allows GET (and HEAD)
requests to certificate URLs.
A client states its desire to access the issued certificate via
unauthenticated GET by adding an "allow-certificate-get" attribute to
the payload of its newOrder request and setting it to "true".
* allow-certificate-get (optional, boolean): If this field is
present and set to "true", the client requests the server to allow
unauthenticated GET (and HEAD) to the certificate associated with
this Order.
If the server accepts the request, it MUST reflect the attribute
setting in the resulting order object.
Note that even when the use of unauthenticated GET has been agreed
upon, the server MUST also allow POST-as-GET requests to the
certificate resource.
2.3.6. Terminating the Delegation
Identity delegation is terminated differently depending on whether
this is a STAR certificate or not. this is a STAR certificate or not.
2.3.5.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 ACME IdO. The NDC does not own the relevant account key on the CA,
server, 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.5.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
ACME server. 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 keypair, or the certificate keypair. In
other words, an NDC that learns the revokeCert URL of the CA (which other words, an NDC that learns the revokeCert URL of the CA (which
is publicly available via the CA's Directory object) would be able to is publicly available via the CA's Directory object) would be able to
revoke the certificate using the associated private key. However, revoke the certificate using the associated private key. However,
given the trust relationship between NDC and IdO expected by the given the trust relationship between NDC and IdO expected by the
delegation trust model (Section 6.1), as well as the lack of delegation trust model (Section 7.1), as well as the lack of
incentives for the NDC to prematurely terminate the delegation, this incentives for the NDC to prematurely terminate the delegation, this
does not represent a security risk. 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 4.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" - can decide, on a per-identity case, whether to act as a server" - can decide, on a per-identity case, whether to act as a
proxy into another ACME Delegation server, or to behave as an IdO and proxy into another ACME Delegation server, or to behave as an IdO and
obtain a certificate directly. The determining factor is whether it obtain a certificate directly. The determining factor is whether it
can successfully be authorized by the ACME server for the identity can successfully be authorized by the next-hop ACME server for the
associated with the certificate request. identity associated 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" object 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.
- And similarly, any "Link" relations. - 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" URLs
are rewritten as for Get Order. 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, and therefore
skipping to change at page 18, line 38 skipping to change at page 22, line 17
- 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" URLs
are rewritten as for Get Order. 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, and therefore
each proxy must be able to authenticate any subordinate server. each proxy must be able to authenticate any subordinate server.
3. CSR Template 3. CA Behavior
Although most of this document, and in particular Section 2 is
focused on the protocol between the NDC and to IdO, the protocol does
affect the ACME server running in the CA. A CA that wishes to
support certificate delegation MUST also support unauthenticated
certificate fetching, which it declares using "allow-certificate-get"
(Section 2.3.5, Paragraph 3).
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.
3.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:
* 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
"client1.ndc.ido.example.com". "abc.ido.example".
* A mandatory field, where the content of the field is defined by * A mandatory field, where the content of the field is defined by
the client. This is denoted by "**". the client. This is denoted by "**".
* An optional field, where the client decides whether the field is * 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 included in the CSR and if so, what its value is. This is denoted
by "*". by "*".
The NDC MUST NOT include in the CSR any fields, including any The NDC MUST NOT include in the CSR any fields, 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 CDDL [RFC8610]
document in Appendix B. document in Appendix B. An alternative, non-normative JSON Schema
syntax is given in Appendix C. While the CSR template must follow
An alternative, non-normative JSON Schema syntax is given in the syntax defined here, neither the IdO nor the NDC are expected to
Appendix C. validate it at run-time.
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 [RFC5280], Section 4.1.2.6. Other extension
fields of the CSR template are mapped into the CSR according to the fields of the CSR template are mapped into the CSR according to the
table in Section 5.6. 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 ACME CA can use to obtain identifier validation challenge that the CA can use to obtain proof
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,
which MUST have the type/size defined by one of the array members of which MUST have the type/size defined by one of the array members of
the "keyTypes" property. the "keyTypes" property.
When the IdO receives the CSR, it MUST verify that the CSR is When the IdO receives the CSR, it MUST verify that the CSR is
consistent with the template contained in the "delegation" object consistent with the template contained in the "delegation" object
referenced in the Order. The IdO MAY enforce additional constraints, referenced in the Order. The IdO MAY enforce additional constraints,
e.g. by restricting field lengths. In this regard, note that a e.g., by restricting field lengths. In this regard, note that a
"subjectAltName" of type "DNS" can be specified using the wildcard "subjectAltName" of type "DNS" can be specified using the wildcard
notation, meaning that the NDC can be required ("**") or offered the notation, meaning that the NDC can be required ("**") or offered the
possibility ("*") to define the delegated domain name by itself. If possibility ("*") to define the delegated domain name by itself. If
this is the case, the IdO needs to have a further layer of checks on this is the case, the IdO MUST apply application-specific checks on
top of the control rules already provided by the CSR template to top of the control rules already provided by the CSR template to
fully validate the CSR input. ensure the requested domain name is legitimate according to its local
policy.
3.2. Example 4.2. Example
The CSR template in Figure 10 represents one possible CSR template The CSR template in Figure 10 represents one possible CSR template
governing the delegation exchanges provided in the rest of this governing the delegation exchanges provided in the rest of this
document. document.
{ {
"keyTypes": [ "keyTypes": [
{ {
"PublicKeyType": "rsaEncryption", "PublicKeyType": "rsaEncryption",
"PublicKeyLength": 2048, "PublicKeyLength": 2048,
skipping to change at page 21, line 21 skipping to change at page 24, line 21
}, },
{ {
"PublicKeyType": "id-ecPublicKey", "PublicKeyType": "id-ecPublicKey",
"namedCurve": "secp256r1", "namedCurve": "secp256r1",
"SignatureType": "ecdsa-with-SHA256" "SignatureType": "ecdsa-with-SHA256"
} }
], ],
"subject": { "subject": {
"country": "CA", "country": "CA",
"stateOrProvince": "**", "stateOrProvince": "**",
"locality": "**", "locality": "**"
"commonName": "**"
}, },
"extensions": { "extensions": {
"subjectAltName": { "subjectAltName": {
"DNS": [ "DNS": [
"client1.ndc.ido.example" "abc.ido.example"
] ]
}, },
"keyUsage": [ "keyUsage": [
"digitalSignature" "digitalSignature"
], ],
"extendedKeyUsage": [ "extendedKeyUsage": [
"serverAuth", "serverAuth",
"clientAuth" "clientAuth"
] ]
} }
} }
Figure 10: Example CSR template Figure 10: Example CSR template
4. Further Use Cases 5. Further Use Cases
This non-normative section describes additional use cases that use This non-normative section describes additional use cases that use
STAR certificate delegation in non-trivial ways. STAR certificate delegation in non-trivial ways.
4.1. CDN Interconnection (CDNI) 5.1. CDN Interconnection (CDNI)
[I-D.ietf-cdni-interfaces-https-delegation] discusses several [I-D.ietf-cdni-interfaces-https-delegation] discusses several
solutions addressing different delegation requirements for the CDNI solutions addressing different delegation requirements for the CDNI
(CDN Interconnection) environment. This section discusses two of the (CDN Interconnection) environment. This section discusses two of the
stated requirements in the context of the STAR delegation workflow. stated requirements in the context of the STAR delegation workflow.
This section uses specifically CDNI terminology, e.g. "uCDN" and This section uses specifically CDNI terminology, e.g., "uCDN" and
"dCDN", as defined in [RFC7336]. "dCDN", as defined in [RFC7336].
4.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 web site to multiple NDCs (CDNs). This could happen
if the IdO has agreements in place with different regional CDNs for if the IdO has agreements in place with different regional CDNs for
different geographical regions, or if a "backup" CDN is used to different geographical regions, or if a "backup" CDN is used to
handle overflow traffic by temporarily altering some of the CNAME handle overflow traffic by temporarily altering some of the CNAME
mappings in place. The STAR delegation flow enables this use case mappings in place. The STAR delegation flow enables this use case
naturally, since each CDN can authenticate separately to the IdO (via naturally, since each CDN can authenticate separately to the IdO (via
its own separate account) specifying its CSR, and the IdO is free to its own separate account) specifying its CSR, and the IdO is free to
allow or deny each certificate request according to its own policy. allow or deny each certificate request according to its own policy.
4.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 has
a similar relationship with dCDN. However IdO may not even know a similar relationship with dCDN. However IdO may not even know
about dCDN. about dCDN.
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 namespace that is made available to the dCDN to mint its * The names that the dCDN is allowed to use;
delegated names;
* 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.
4.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), browser or set-top-box, wants to fetch the video
resource at the following URI: "https://video.cp.example/movie". resource at the following URI: "https://video.cp.example/movie".
Redirection between Content Provider (CP), upstream, and downstream Redirection between Content Provider (CP), upstream, and downstream
CDNs is arranged as a CNAME-based aliasing chain as illustrated in CDNs is arranged as a CNAME-based aliasing chain as illustrated in
Figure 11. Figure 11.
.------------. .------------.
video.cp.example ? | .-----. | video.cp.example ? | .-----. |
.---------------------------------->| | | .---------------------------------->| | |
skipping to change at page 23, line 37 skipping to change at page 26, line 37
| '-----------------------------------+ | | | '-----------------------------------+ | |
| 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 an SNI equal result, the TLS connection to the dCDN edge is done with a Server
to the "host" in the original URI - in the example, Name Indication (SNI) equal to the "host" in the original URI - in
"video.cp.example". So, in order to successfully complete the the example, "video.cp.example". So, in order to successfully
handshake, the landing dCDN node has to be configured with a complete the handshake, the landing dCDN node has to be configured
certificate whose subjectAltName matches "video.cp.example", i.e., a with a certificate whose subjectAltName matches "video.cp.example",
Content Provider's name. 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 |
| | | | .--|-------. | | | .--|-------.
| | | | | .-+----. | | | | | .-+----. |
| 7 | '---->| ACME | | 7 | '---->| ACME | |
| | | | | STAR | C | | | | | STAR | C |
0 | 4 | +------| A | | 4 | +------| A |
| | | | | HTTP | | | | | | HTTP | |
| | | | '----+-' | | | | '----+-' |
| | .-' '--^--|----' | .-' '--^--|----'
| .--------------v--|--. | | .--------------v--|--. | |
| | .------.----+-. | | 10 | .------.----+-. | | 10
| | | | STAR | | | | | | | STAR | | | |
'-->| uCDN | CDNI | dele | | | | | uCDN | CDNI | dele | | | |
| | | fwd | | | | | | | fwd | | | |
| '----+-'-+----' | | | | '----+-'-+----' | | |
'-------^--|---|--^--' | | '-------^--|---|--^--' | |
| | | | | | | | | | | |
| 2 8 | | | | 2 8 | | |
1 | | 3 | | 1 | | 3 | |
| | | | 9 | | | | | 9 |
.-------|--v---v--|---------. | | .-------|--v---v--|---------. | |
| .-+----.----+-.------. | | | | .-+----.----+-.------. | | |
| | | STAR | +------------' | | | | STAR | +------------' |
skipping to change at page 25, line 14 skipping to change at page 28, line 14
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 8. uCDN forwards the information to dCDN. At this point the ACME
signalling is complete; signalling is complete;
9. dCDN requests the STAR certificate using unauthenticated GET 9. dCDN requests the STAR certificate using unauthenticated GET
from the ACME server; from the CA;
10. the CA returns the certificate. Now dCDN is fully configured to 10. the CA returns the certificate. Now dCDN is fully configured to
handle HTTPS traffic in-lieu of the Content Provider. handle HTTPS traffic in-lieu of the Content Provider.
Note that 9. and 10. repeat until the delegation expires or is Note that 9. and 10. repeat until the delegation expires or is
terminated. terminated.
4.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 [I-D.ietf-stir-cert-delegation].
This section uses STIR terminology. The term PASSPorT is defined in This section uses STIR terminology. The term PASSPorT is defined in
[RFC8225], and "TNAuthList" in [RFC8226]. [RFC8225], and "TNAuthList" 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 PASSPorT's [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
skipping to change at page 25, line 44 skipping to change at page 28, line 44
In details (Figure 13): In details (Figure 13):
1. SP1 and SP2 agree on the configuration of the delegation - in 1. SP1 and SP2 agree on the configuration of the delegation - in
particular, the CSR template that applies; particular, the CSR template that applies;
2. SP2 generates a private/public key-pair and sends a CSR to SP1 2. SP2 generates a private/public key-pair and sends a CSR to SP1
requesting creation of a certificate with: SP1 name, SP2 public requesting creation of a certificate with: SP1 name, SP2 public
key, and a TNAuthList extension with the list of TNs that SP1 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 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.); be validated against the CSR template agreed upon in step 1.);
3. SP1 sends an Order for the CSR to the CA; 3. SP1 sends an order for the CSR to the CA. The order also
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 5. The order contents are forwarded from SP1 to SP2 by means of the
paired "delegation" Order. paired "delegation" order;
6. SP2 dereferences the star-certificate URL in the Order to fetch 6. SP2 dereferences the star-certificate URL in the order to fetch
the rolling STAR certificate bearing the delegated identifiers. the rolling STAR certificate bearing the delegated identifiers;
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 |
| | | | .----|-----. | | | | .----|-----.
| | 5 | | .---+--. | | | 5 | | .---+--. |
skipping to change at page 26, line 38 skipping to change at page 29, line 39
| '----+-'-+----' | | '----+-'-+----' |
'-------------------' '-------------------'
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.
5. IANA Considerations 6. IANA Considerations
[[RFC Editor: please replace XXXX below by the RFC number.]] [[RFC Editor: please replace XXXX below by the RFC number.]]
5.1. New ACME Identifier Object Fields 6.1. New Fields in the "meta" Object within a Directory Object
This document requests that IANA create the following new registry
under the Automated Certificate Management Environment (ACME)
Protocol:
* ACME Identifier Object Fields
This registry is administered under a Specification Required policy
[RFC8126].
The "ACME Identifier Object Fields" registry lists field names that
are defined for use in the ACME identifier object.
Template:
* Field name: The string to be used as a field name in the JSON
object
* Field type: The type of value to be provided, e.g., string,
boolean, array of string
* Reference: Where this field is defined
+============+============+===========================+
| Field Name | Field Type | Reference |
+============+============+===========================+
| type | string | Section 7.1.3 of RFC 8555 |
+------------+------------+---------------------------+
| value | string | Section 7.1.3 of RFC 8555 |
+------------+------------+---------------------------+
| delegation | string | RFC XXXX |
+------------+------------+---------------------------+
Table 1
Note: this registry was not created at the time [RFC8555] was
standardized likely because it was not anticipated that the
identifier object would be extended. It is retrospectively
introduced to record the status quo and allow controlled
extensibility of the identifier object.
5.2. 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 XXXX |
+--------------------+------------+-----------+ +-----------------------+------------+-----------+
| allow-certificate-get | boolean | RFC XXXX |
+-----------------------+------------+-----------+
Table 2 Table 1
5.3. 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 XXXX |
+-----------------------+------------+--------------+-----------+ +-----------------------+------------+--------------+-----------+
| delegation | string | true | RFC XXXX |
+-----------------------+------------+--------------+-----------+
Table 3 Table 2
5.4. 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 XXXX |
+-------------+------------+----------+-----------+ +-------------+------------+----------+-----------+
Table 4 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.
5.5. 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 Type
registry: registry:
+===================+================================+===========+ +===================+================================+===========+
| Type | Description | Reference | | Type | Description | Reference |
+===================+================================+===========+ +===================+================================+===========+
| unknownDelegation | An unknown configuration is | RFC XXXX | | unknownDelegation | An unknown configuration is | RFC XXXX |
| | listed in the "delegations" | | | | listed in the "delegations" | |
| | attribute of the request Order | | | | attribute of the request Order | |
+-------------------+--------------------------------+-----------+ +-------------------+--------------------------------+-----------+
Table 5 Table 4
5.6. 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 "Expert Review" as its registration Template Extensions", with "Specification Required" as its
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
* An extension syntax, as a reference to a JSON Schema document that
defines this extension. defines this extension.
* The extension's mapping into an X.509 certificate extension. * 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 B.
+==================+===========+===============================+ +==================+===========+===============================+
| Extension Name | Extension | Mapping to X.509 Certificate | | Extension Name | Extension | Mapping to X.509 Certificate |
| | Syntax | Extension | | | Syntax | Extension |
+==================+===========+===============================+ +==================+===========+===============================+
skipping to change at page 29, line 30 skipping to change at page 31, line 49
| extendedKeyUsage | See | [RFC5280], Section 4.2.1.12 | | extendedKeyUsage | See | [RFC5280], Section 4.2.1.12 |
| | Appendix | | | | Appendix | |
| | B | | | | B | |
+------------------+-----------+-------------------------------+ +------------------+-----------+-------------------------------+
| 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 | | | B | formats are allowed: URI, DNS |
| | | name, email address) | | | | name, email address) |
+------------------+-----------+-------------------------------+ +------------------+-----------+-------------------------------+
Table 6 Table 5
6. Security Considerations When evaluating a request for an assignment in this registry, the
designated expert should follow this guidance:
6.1. Trust Model * The definition must include a full CDDL definition, which the
expert will validate.
* The definition must include both positive and negative test cases.
* Additional requirements that are not captured by the CDDL
definition are allowed but must be explicitly specified.
7. Security Considerations
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 using standard [RFC6125] identity
verification there are no mechanisms available to the IdO to restrict verification there are no mechanisms available to the IdO to restrict
the use of the delegated name once the name has been handed over to the use of the delegated name once the name has been handed over to
the first NDC. the first NDC. It is therefore expected that contractual measures
are in place to get some assurance that re-delegation is not being
performed.
6.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 authorised 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;
skipping to change at page 30, line 33 skipping to change at page 33, line 14
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 ACME server. 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 revoked
identity, therefore disabling any further NDC requests for such identity, therefore disabling any further NDC requests for such
identity. Note that, in more extreme circumstances, the IdO might identity. Note that, in more extreme circumstances, the IdO might
decide to disable the NDC account thus entirely blocking any further decide to disable the NDC account thus entirely blocking any further
interaction. 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]). [RFC8555]) is used.
6.3. New ACME Channels The ACME account associated with the delegation plays a crucial role
in the overall security of the presented protocol. This, in turn,
means that in delegation scenarios the security requirements and
verification associated with an ACME account may be more stringent
than in traditional ACME, since the out-of-band configuration of
delegations that an account is authorized to use, combined with
account authentication, takes the place of the normal ACME
authorization challenge procedures. Therefore, the IdO MUST ensure
that each account is associated with the exact policy (via a
"delegation" object) that defines which domain names can be 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.
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 |
.-----. ACME Channel .--+--. .--+----------. '--+--' | server |
| NDC +------------->| IdO | | ACME server | | '--o-----'
'--+--' '--+--' '--+-+--------' | |
| '-----------<-------------' | | | ACME Channel
| Validation Channel | | | .------------>-------------.
'-------------------->---------------------------' | | | |
| .--o--+--. .--+---.
| | IdO | | CA |
| | client | '--+-+-'
| '-----+--' | |
| '-----------<--------------' |
| Validation Channel |
'-------------------->-------------------------------'
(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-
ACME server leg. The same can be said for the ACME channel on the CA leg. The same can be said for the ACME channel on the NDC-IdO
NDC/IdO leg. A slightly different set of considerations apply to the leg. A slightly different set of considerations apply to the ACME
ACME Channel between NDC and ACME server, which consists of a subset Channel between NDC and CA, which consists of a subset of the ACME
of the ACME interface comprising two API endpoints: the interface comprising two API endpoints: the unauthenticated
unauthenticated certificate retrieval and, potentially, non-STAR certificate retrieval and, potentially, non-STAR revocation via
revocation via certificate private key. No specific security certificate private key. No specific security considerations apply
considerations apply to the former, but the privacy considerations in to the former, but the privacy considerations in Section 6.3 of
Section 6.3 of [RFC8739] do. With regards to the latter, it should [RFC8739] do. With regards to the latter, it should be noted that
be noted that there is currently no means for an IdO to disable there is currently no means for an IdO to disable authorising
authorising revocation based on certificate private keys. So, in revocation based on certificate private keys. So, in theory, an NDC
theory, an NDC could use the revocation API directly with the ACME could use the revocation API directly with the CA, therefore
server, therefore bypassing the IdO. The NDC SHOULD NOT directly use bypassing the IdO. The NDC SHOULD NOT directly use the revocation
the revocation interface exposed by the ACME server unless failing to interface exposed by the CA unless failing to do so would compromise
do so would compromise the overall security, for example if the the overall security, for example if the certificate private key is
certificate private key is compromised and the IdO is not currently compromised and the IdO is not currently reachable.
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.
6.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 web site is delegated to a CDN, the CDN can in principle
modify the web site at will, create and remove pages. This means modify the web site at will, create and remove pages. This means
that a malicious or breached CDN can pass the ACME (as well as common that a malicious or breached CDN can pass the ACME (as well as common
non-ACME) HTTPS-based validation challenges and generate a non-ACME) HTTPS-based validation challenges and generate a
certificate for the site. This is true regardless of whether the certificate for the site. This is true regardless of whether the
CNAME mechanisms defined in the current document is used or not. CNAME mechanisms defined in the current document is used or not.
In some cases, this is the desired behavior: the domain owner trusts In some cases, this is the desired behavior: the domain 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 that the domain owner site. The current document however assumes a scenario where the
only wants to delegate restricted control, and wishes to retain the domain holder only wants to delegate restricted control, and wishes
capability to cancel the CDN's credentials at a short notice. to retain the capability to cancel the CDN's credentials at a short
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 owner 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 owner 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 owner uses a CAA record [RFC8659] to restrict * The domain holder uses a CAA record [RFC8659] to restrict
certificate issuance for the domain to specific CAs that comply certificate issuance for the domain to specific CAs that comply
with ACME and are known to implement [RFC8657]. with ACME and are known to implement [RFC8657].
* The domain owner uses the ACME-specific CAA mechanism [RFC8657] to * The domain holder uses the ACME-specific CAA mechanism [RFC8657]
restrict issuance to a specific account key which is controlled by to restrict issuance to a specific account key which is controlled
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 authorisation flows supported by the
selected CAs. selected CA. In addition, this mitigation may be bypassed if a
malicious or misconfigured CA does not comply with CAA restrictions.
7. Acknowledgments 8. Acknowledgments
We would like to thank the following people who contributed We would like to thank the following people who contributed
significantly to this document with their review comments and design significantly to this document with their review comments and design
proposals: Roman Danyliw, Frédéric Fieau, Russ Housley, Sanjay proposals: Richard Barnes, Carsten Bormann, Roman Danyliw, Lars
Mishra, Jon Peterson, Ryan Sleevi, Emile Stephan. 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 This work is partially supported by the European Commission under
Horizon 2020 grant agreement no. 688421 Measurement and Architecture Horizon 2020 grant agreement no. 688421 Measurement and Architecture
for a Middleboxed Internet (MAMI). This support does not imply for a Middleboxed Internet (MAMI). This support does not imply
endorsement. endorsement.
8. References 9. References
8.1. Normative References 9.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>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP
Writing an IANA Considerations Section in RFCs", BCP 26, APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016,
RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc7807>.
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>. <https://www.rfc-editor.org/info/rfc8555>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
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>.
[RFC8657] Landau, H., "Certification Authority Authorization (CAA)
Record Extensions for Account URI and Automatic
Certificate Management Environment (ACME) Method Binding",
RFC 8657, DOI 10.17487/RFC8657, November 2019,
<https://www.rfc-editor.org/info/rfc8657>.
[RFC8659] Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews,
"DNS Certification Authority Authorization (CAA) Resource
Record", RFC 8659, DOI 10.17487/RFC8659, November 2019,
<https://www.rfc-editor.org/info/rfc8659>.
[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>.
8.2. Informative References [RFC8793] Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran,
D., and C. Tschudin, "Information-Centric Networking
(ICN): Content-Centric Networking (CCNx) and Named Data
Networking (NDN) Terminology", RFC 8793,
DOI 10.17487/RFC8793, June 2020,
<https://www.rfc-editor.org/info/rfc8793>.
9.2. Informative References
[I-D.ietf-acme-authority-token-tnauthlist] [I-D.ietf-acme-authority-token-tnauthlist]
Wendt, C., Hancock, D., Barnes, M., and J. Peterson, Wendt, C., Hancock, D., Barnes, M., and J. Peterson,
"TNAuthList profile of ACME Authority Token", Work in "TNAuthList profile of ACME Authority Token", Work in
Progress, Internet-Draft, draft-ietf-acme-authority-token- Progress, Internet-Draft, draft-ietf-acme-authority-token-
tnauthlist-07, 22 February 2021, tnauthlist-08, 27 March 2021,
<https://www.ietf.org/archive/id/draft-ietf-acme- <https://www.ietf.org/archive/id/draft-ietf-acme-
authority-token-tnauthlist-07.txt>. authority-token-tnauthlist-08.txt>.
[I-D.ietf-cdni-interfaces-https-delegation] [I-D.ietf-cdni-interfaces-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://www.ietf.org/archive/id/draft-ietf-cdni-
interfaces-https-delegation-05.txt>. interfaces-https-delegation-05.txt>.
[I-D.ietf-stir-cert-delegation] [I-D.ietf-stir-cert-delegation]
Peterson, J., "STIR Certificate Delegation", Work in Peterson, J., "STIR Certificate Delegation", Work in
skipping to change at page 35, line 26 skipping to change at page 38, line 39
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
<https://www.rfc-editor.org/info/rfc8225>. <https://www.rfc-editor.org/info/rfc8225>.
[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", RFC 8226, Credentials: Certificates", RFC 8226,
DOI 10.17487/RFC8226, February 2018, DOI 10.17487/RFC8226, February 2018,
<https://www.rfc-editor.org/info/rfc8226>. <https://www.rfc-editor.org/info/rfc8226>.
[RFC8657] Landau, H., "Certification Authority Authorization (CAA)
Record Extensions for Account URI and Automatic
Certificate Management Environment (ACME) Method Binding",
RFC 8657, DOI 10.17487/RFC8657, November 2019,
<https://www.rfc-editor.org/info/rfc8657>.
[RFC8659] Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews,
"DNS Certification Authority Authorization (CAA) Resource
Record", RFC 8659, DOI 10.17487/RFC8659, November 2019,
<https://www.rfc-editor.org/info/rfc8659>.
Appendix A. Document History Appendix A. Document History
[[Note to RFC Editor: please remove before publication.]] [[Note to RFC Editor: please remove before publication.]]
A.1. draft-ietf-acme-star-delegation-07 A.1. 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.2. draft-ietf-acme-star-delegation-07
* SecDir comments by Russ Housley. * SecDir comments by Russ Housley.
* In particular, reorganized some parts of the document to clarify * In particular, reorganized some parts of the document to clarify
handling of non-STAR certificates. handling of non-STAR certificates.
* And changed the document's title accordingly. * And changed the document's title accordingly.
A.2. draft-ietf-acme-star-delegation-06 A.3. draft-ietf-acme-star-delegation-06
* CDDL schema to address Roman's remaining comments. * CDDL schema to address Roman's remaining comments.
A.3. draft-ietf-acme-star-delegation-05 A.4. draft-ietf-acme-star-delegation-05
* Detailed AD review by Roman Danyliw. * Detailed AD review by Roman Danyliw.
* Some comments that were left unaddressed in Ryan Sleevi's review. * Some comments that were left unaddressed in Ryan Sleevi's review.
* Numerous other edits for clarity and consistency. * Numerous other edits for clarity and consistency.
A.4. draft-ietf-acme-star-delegation-04 A.5. draft-ietf-acme-star-delegation-04
* Delegation of non-STAR certificates. * Delegation of non-STAR certificates.
* More IANA clarity, specifically on certificate extensions. * More IANA clarity, specifically on certificate extensions.
* Add delegation configuration object and extend account and order * Add delegation configuration object and extend account and order
objects accordingly. objects accordingly.
* A lot more depth on Security Considerations. * A lot more depth on Security Considerations.
A.5. draft-ietf-acme-star-delegation-03 A.6. draft-ietf-acme-star-delegation-03
* Consistency with the latest changes in the base ACME STAR * Consistency with the latest changes in the base ACME STAR
document, e.g. star-delegation-enabled capability renamed and document, e.g. star-delegation-enabled capability renamed and
moved. moved.
* Proxy use cases (recursive delegation) and the definition of proxy * Proxy use cases (recursive delegation) and the definition of proxy
behavior. behavior.
* More detailed analysis of the CDNI and STIR use cases, including * More detailed analysis of the CDNI and STIR use cases, including
sequence diagrams. sequence diagrams.
A.6. draft-ietf-acme-star-delegation-02 A.7. draft-ietf-acme-star-delegation-02
* Security considerations: review by Ryan Sleevi. * Security considerations: review by Ryan Sleevi.
* CSR template simplified: instead of being a JSON Schema document * CSR template simplified: instead of being a JSON Schema document
itself, it is now a simple JSON document which validates to a JSON itself, it is now a simple JSON document which validates to a JSON
Schema. Schema.
A.7. draft-ietf-acme-star-delegation-01 A.8. draft-ietf-acme-star-delegation-01
* Refinement of the CDNI use case. * Refinement of the CDNI use case.
* Addition of the CSR template (partial, more work required). * Addition of the CSR template (partial, more work required).
* Further security considerations (work in progress). * Further security considerations (work in progress).
A.8. draft-ietf-acme-star-delegation-00 A.9. draft-ietf-acme-star-delegation-00
* Republished as a working group draft. * Republished as a working group draft.
A.9. draft-sheffer-acme-star-delegation-01 A.10. draft-sheffer-acme-star-delegation-01
* Added security considerations about disallowing CDNs from issuing * Added security considerations about disallowing CDNs from issuing
certificates for a delegated domain. certificates for a delegated domain.
A.10. draft-sheffer-acme-star-delegation-00 A.11. draft-sheffer-acme-star-delegation-00
* Initial version, some text extracted from draft-sheffer-acme-star- * Initial version, some text extracted from draft-sheffer-acme-star-
requests-02 requests-02
Appendix B. CSR Template: CDDL Appendix B. 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, compliant
with the syntax defined here. with the syntax defined here.
An additional constraint that is not expressed in CDDL but MUST be There are additional constraints not expressed in CDDL that MUST be
validated by the recipient is that all objects (e.g. validated by the recipient, including:
"distinguishedName") MUST NOT be empty when they are included, even
when each separate property is optional. * The value of each "subjectAltName" entry is compatible with its
type;
* The parameters in each "keyTypes" entry form an acceptable
combination.
csr-template-schema = { csr-template-schema = {
keyTypes: [ 1* $keyType ] keyTypes: [ + $keyType ]
? subject: distinguishedName ? subject: non-empty<distinguishedName>
extensions: extensions extensions: extensions
} }
non-empty<M> = (M) .and ({ + any => any })
mandatory-wildcard = "**" mandatory-wildcard = "**"
optional-wildcard = "*" optional-wildcard = "*"
wildcard = mandatory-wildcard / optional-wildcard wildcard = mandatory-wildcard / optional-wildcard
; regtext matches all text strings but "*" and "**" ; regtext matches all text strings but "*" and "**"
regtext = text .regexp "([^\*].*)|([\*][^\*].*)|([\*][\*].+)" regtext = text .regexp "([^\*].*)|([\*][^\*].*)|([\*][\*].+)"
regtext-or-wildcard = regtext / wildcard regtext-or-wildcard = regtext / wildcard
distinguishedName = { distinguishedName = {
skipping to change at page 37, line 44 skipping to change at page 41, line 49
$keyType /= rsaKeyType $keyType /= rsaKeyType
$keyType /= ecdsaKeyType $keyType /= ecdsaKeyType
rsaKeyType = { rsaKeyType = {
PublicKeyType: "rsaEncryption" ; OID: 1.2.840.113549.1.1.1 PublicKeyType: "rsaEncryption" ; OID: 1.2.840.113549.1.1.1
PublicKeyLength: rsaKeySize PublicKeyLength: rsaKeySize
SignatureType: $rsaSignatureType SignatureType: $rsaSignatureType
} }
rsaKeySize = int .ge 2048 rsaKeySize = uint
; RSASSA-PKCS1-v1_5 with SHA-256 ; RSASSA-PKCS1-v1_5 with SHA-256
$rsaSignatureType /= "sha256WithRSAEncryption" $rsaSignatureType /= "sha256WithRSAEncryption"
; RSASSA-PCKS1-v1_5 with SHA-384 ; RSASSA-PCKS1-v1_5 with SHA-384
$rsaSignatureType /= "sha384WithRSAEncryption" $rsaSignatureType /= "sha384WithRSAEncryption"
; RSASSA-PCKS1-v1_5 with SHA-512 ; RSASSA-PCKS1-v1_5 with SHA-512
$rsaSignatureType /= "sha512WithRSAEncryption" $rsaSignatureType /= "sha512WithRSAEncryption"
; RSASSA-PSS with SHA-256, MGF-1 with SHA-256, and a 32 byte salt ; RSASSA-PSS with SHA-256, MGF-1 with SHA-256, and a 32 byte salt
$rsaSignatureType /= "sha256WithRSAandMGF1" $rsaSignatureType /= "sha256WithRSAandMGF1"
; RSASSA-PSS with SHA-384, MGF-1 with SHA-384, and a 48 byte salt ; RSASSA-PSS with SHA-384, MGF-1 with SHA-384, and a 48 byte salt
skipping to change at page 38, line 25 skipping to change at page 42, line 30
$ecdsaCurve /= "secp256r1" ; OID: 1.2.840.10045.3.1.7 $ecdsaCurve /= "secp256r1" ; OID: 1.2.840.10045.3.1.7
$ecdsaCurve /= "secp384r1" ; OID: 1.3.132.0.34 $ecdsaCurve /= "secp384r1" ; OID: 1.3.132.0.34
$ecdsaCurve /= "secp521r1" ; OID: 1.3.132.0.3 $ecdsaCurve /= "secp521r1" ; OID: 1.3.132.0.3
$ecdsaSignatureType /= "ecdsa-with-SHA256" ; paired with secp256r1 $ecdsaSignatureType /= "ecdsa-with-SHA256" ; paired with secp256r1
$ecdsaSignatureType /= "ecdsa-with-SHA384" ; paired with secp384r1 $ecdsaSignatureType /= "ecdsa-with-SHA384" ; paired with secp384r1
$ecdsaSignatureType /= "ecdsa-with-SHA512" ; paired with secp521r1 $ecdsaSignatureType /= "ecdsa-with-SHA512" ; paired with secp521r1
subjectaltname = { subjectaltname = {
? DNS: [ 1* regtext-or-wildcard ] ? DNS: [ + regtext-or-wildcard ]
? Email: [ 1* regtext ] ? Email: [ + regtext ]
? URI: [ 1* regtext ] ? URI: [ + regtext ]
* $$subjectaltname-extension * $$subjectaltname-extension
} }
extensions = { extensions = {
? keyUsage: [ 1* keyUsageType ] ? keyUsage: [ + keyUsageType ]
? extendedKeyUsage: [ 1* extendedKeyUsageType ] ? extendedKeyUsage: [ + extendedKeyUsageType ]
subjectAltName: subjectaltname subjectAltName: non-empty<subjectaltname>
} }
keyUsageType /= "digitalSignature" keyUsageType /= "digitalSignature"
keyUsageType /= "nonRepudiation" keyUsageType /= "nonRepudiation"
keyUsageType /= "keyEncipherment" keyUsageType /= "keyEncipherment"
keyUsageType /= "dataEncipherment" keyUsageType /= "dataEncipherment"
keyUsageType /= "keyAgreement" keyUsageType /= "keyAgreement"
keyUsageType /= "keyCertSign" keyUsageType /= "keyCertSign"
keyUsageType /= "cRLSign" keyUsageType /= "cRLSign"
keyUsageType /= "encipherOnly" keyUsageType /= "encipherOnly"
skipping to change at page 38, line 46 skipping to change at page 43, line 4
keyUsageType /= "digitalSignature" keyUsageType /= "digitalSignature"
keyUsageType /= "nonRepudiation" keyUsageType /= "nonRepudiation"
keyUsageType /= "keyEncipherment" keyUsageType /= "keyEncipherment"
keyUsageType /= "dataEncipherment" keyUsageType /= "dataEncipherment"
keyUsageType /= "keyAgreement" keyUsageType /= "keyAgreement"
keyUsageType /= "keyCertSign" keyUsageType /= "keyCertSign"
keyUsageType /= "cRLSign" keyUsageType /= "cRLSign"
keyUsageType /= "encipherOnly" keyUsageType /= "encipherOnly"
keyUsageType /= "decipherOnly" keyUsageType /= "decipherOnly"
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-9]+(\\.[0-9]+)*" oid = text .regexp "([0-2])((\.0)|(\.[1-9][0-9]*))*"
Appendix C. CSR Template: JSON Schema Appendix C. CSR Template: JSON Schema
This appendix includes an alternative, non-normative, JSON Schema This appendix includes an alternative, non-normative, 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.
While the CSR template must follow the syntax defined here, neither The same considerations about additional constraints checking
the IdO nor the NDC are expected to validate it at run-time. discussed in Appendix B 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 40, line 18 skipping to change at page 44, line 24
}, },
"rsaKeyType": { "rsaKeyType": {
"$id": "#rsaKeyType", "$id": "#rsaKeyType",
"type": "object", "type": "object",
"properties": { "properties": {
"PublicKeyType": { "PublicKeyType": {
"type": "string", "type": "string",
"const": "rsaEncryption" "const": "rsaEncryption"
}, },
"PublicKeyLength": { "PublicKeyLength": {
"type": "integer", "type": "integer"
"minimum": 2048,
"multipleOf": 8
}, },
"SignatureType": { "SignatureType": {
"type": "string", "type": "string",
"enum": [ "enum": [
"sha256WithRSAEncryption", "sha256WithRSAEncryption",
"sha384WithRSAEncryption", "sha384WithRSAEncryption",
"sha512WithRSAEncryption", "sha512WithRSAEncryption",
"sha256WithRSAandMGF1", "sha256WithRSAandMGF1",
"sha384WithRSAandMGF1", "sha384WithRSAandMGF1",
"sha512WithRSAandMGF1" "sha512WithRSAandMGF1"
skipping to change at page 41, line 30 skipping to change at page 45, line 33
"namedCurve", "namedCurve",
"SignatureType" "SignatureType"
], ],
"additionalProperties": false "additionalProperties": false
} }
}, },
"type": "object", "type": "object",
"properties": { "properties": {
"keyTypes": { "keyTypes": {
"type": "array", "type": "array",
"minItems": 1,
"items": { "items": {
"oneOf": [ "anyOf": [
{ {
"$ref": "#rsaKeyType" "$ref": "#rsaKeyType"
}, },
{ {
"$ref": "#ecdsaKeyType" "$ref": "#ecdsaKeyType"
} }
] ]
} }
}, },
"subject": { "subject": {
skipping to change at page 42, line 21 skipping to change at page 46, line 25
"cRLSign", "cRLSign",
"encipherOnly", "encipherOnly",
"decipherOnly" "decipherOnly"
] ]
} }
}, },
"extendedKeyUsage": { "extendedKeyUsage": {
"type": "array", "type": "array",
"minItems": 1, "minItems": 1,
"items": { "items": {
"oneOf": [ "anyOf": [
{ {
"type": "string", "type": "string",
"enum": [ "enum": [
"serverAuth", "serverAuth",
"clientAuth", "clientAuth",
"codeSigning", "codeSigning",
"emailProtection", "emailProtection",
"timeStamping", "timeStamping",
"OCSPSigning" "OCSPSigning"
] ]
}, },
{ {
"type": "string", "type": "string",
"pattern": "^[0-9]+(\\.[0-9]+)*$", "pattern": "^([0-2])((\\.0)|(\\.[1-9][0-9]*))*$",
"description": "Used for OID values" "description": "Used for OID values"
} }
] ]
} }
}, },
"subjectAltName": { "subjectAltName": {
"type": "object", "type": "object",
"minProperties": 1, "minProperties": 1,
"properties": { "properties": {
"DNS": { "DNS": {
"type": "array", "type": "array",
"minItems": 1, "minItems": 1,
"items": { "items": {
"type": "string", "anyOf": [
"format": "hostname" {
"type": "string",
"enum": [
"*",
"**"
]
},
{
"type": "string",
"format": "hostname"
}
]
} }
}, },
"Email": { "Email": {
"type": "array", "type": "array",
"minItems": 1, "minItems": 1,
"items": { "items": {
"type": "string", "type": "string",
"format": "email" "format": "email"
} }
}, },
"URI": { "URI": {
 End of changes. 189 change blocks. 
416 lines changed or deleted 606 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/