draft-ietf-acme-star-delegation-06.txt   draft-ietf-acme-star-delegation-07.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: 8 September 2021 A. Pastor Perales Expires: 27 September 2021 A. Pastor Perales
Telefonica I+D Telefonica I+D
T. Fossati T. Fossati
ARM ARM
7 March 2021 26 March 2021
An ACME Profile for Generating Delegated STAR Certificates An ACME Profile for Generating Delegated Certificates
draft-ietf-acme-star-delegation-06 draft-ietf-acme-star-delegation-07
Abstract Abstract
This memo proposes a profile of the ACME protocol that allows the This memo defines a profile of the Automatic Certificate Management
owner of an identifier (e.g., a domain name) to delegate to a third Environment (ACME) protocol by which the owner of an identifier
party access to a certificate associated with said identifier. A (e.g., a domain name) can allow a third party to obtain an X.509
primary use case is that of a CDN (the third party) terminating TLS certificate such that the certificate subject is the delegated
identifier while the certified public key corresponds to a private
key controlled by the third party. A primary use case is that of a
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 owner of a domain
name). The presented mechanism allows the owner of the identifier to name). The presented mechanism allows the owner of the identifier to
retain control over the delegation and revoke it at any time by retain control over the delegation and revoke it at any time. A key
cancelling the associated STAR certificate renewal with the ACME CA. property of this mechanism is it does not require any modification to
Another key property of this mechanism is it does not require any the deployed TLS ecosystem.
modification to the deployed TLS ecosystem.
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 8 September 2021. This Internet-Draft will expire on 27 September 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
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Conventions used in this document . . . . . . . . . . . . 4 1.2. Conventions used in this document . . . . . . . . . . . . 5
2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Delegated Identity Profile . . . . . . . . . . . . . . . 7 2.3. Delegated Identity Profile . . . . . . . . . . . . . . . 8
2.3.1. Delegation Configuration . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . 10 Server (STAR) . . . . . . . . . . . . . . . . . . . . 10
2.3.3. Capability Discovery . . . . . . . . . . . . . . . . 13 2.3.3. Order Object Transmitted from NDC to IdO and to ACME
2.3.4. On Cancellation . . . . . . . . . . . . . . . . . . . 14 Server (non-STAR) . . . . . . . . . . . . . . . . . . 13
2.4. Delegation of Non-STAR Certificates . . . . . . . . . . . 14 2.3.4. Capability Discovery . . . . . . . . . . . . . . . . 16
2.5. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 15 2.3.5. Terminating the Delegation . . . . . . . . . . . . . 16
3. CSR Template . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 17
3.1. Template Syntax . . . . . . . . . . . . . . . . . . . . . 16 3. CSR Template . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1. Template Syntax . . . . . . . . . . . . . . . . . . . . . 19
4. Further Use Cases . . . . . . . . . . . . . . . . . . . . . . 18 3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1. CDNI . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4. Further Use Cases . . . . . . . . . . . . . . . . . . . . . . 21
4.1.1. Multiple Parallel Delegates . . . . . . . . . . . . . 19 4.1. CDN Interconnection (CDNI) . . . . . . . . . . . . . . . 21
4.1.2. Chained Delegation . . . . . . . . . . . . . . . . . 19 4.1.1. Multiple Parallel Delegates . . . . . . . . . . . . . 22
4.2. STIR . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.1.2. Chained Delegation . . . . . . . . . . . . . . . . . 22
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 4.2. Secure Telephone Identity Revisited (STIR) . . . . . . . 25
5.1. New ACME Identifier Object Fields . . . . . . . . . . . . 23 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
5.1. New ACME Identifier Object Fields . . . . . . . . . . . . 26
5.2. New Fields in the "meta" Object within a Directory 5.2. New Fields in the "meta" Object within a Directory
Object . . . . . . . . . . . . . . . . . . . . . . . . . 24 Object . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3. New Fields in the Order Object . . . . . . . . . . . . . 24 5.3. New Fields in the Order Object . . . . . . . . . . . . . 27
5.4. New Fields in the Account Object . . . . . . . . . . . . 25 5.4. New Fields in the Account Object . . . . . . . . . . . . 28
5.5. New Error Types . . . . . . . . . . . . . . . . . . . . . 25 5.5. New Error Types . . . . . . . . . . . . . . . . . . . . . 28
5.6. CSR Template Extensions . . . . . . . . . . . . . . . . . 25 5.6. CSR Template Extensions . . . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 26 6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 29
6.2. Delegation Security Goal . . . . . . . . . . . . . . . . 26 6.2. Delegation Security Goal . . . . . . . . . . . . . . . . 29
6.3. New ACME Channels . . . . . . . . . . . . . . . . . . . . 27 6.3. New ACME Channels . . . . . . . . . . . . . . . . . . . . 30
6.4. Restricting CDNs to the Delegation Mechanism . . . . . . 28 6.4. Restricting CDNs to the Delegation Mechanism . . . . . . 31
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1. Normative References . . . . . . . . . . . . . . . . . . 29 8.1. Normative References . . . . . . . . . . . . . . . . . . 32
8.2. Informative References . . . . . . . . . . . . . . . . . 30 8.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. Document History . . . . . . . . . . . . . . . . . . 32 Appendix A. Document History . . . . . . . . . . . . . . . . . . 35
A.1. draft-ietf-acme-star-delegation-06 . . . . . . . . . . . 32 A.1. draft-ietf-acme-star-delegation-07 . . . . . . . . . . . 35
A.2. draft-ietf-acme-star-delegation-05 . . . . . . . . . . . 32 A.2. draft-ietf-acme-star-delegation-06 . . . . . . . . . . . 35
A.3. draft-ietf-acme-star-delegation-04 . . . . . . . . . . . 32 A.3. draft-ietf-acme-star-delegation-05 . . . . . . . . . . . 35
A.4. draft-ietf-acme-star-delegation-03 . . . . . . . . . . . 32 A.4. draft-ietf-acme-star-delegation-04 . . . . . . . . . . . 35
A.5. draft-ietf-acme-star-delegation-02 . . . . . . . . . . . 32 A.5. draft-ietf-acme-star-delegation-03 . . . . . . . . . . . 36
A.6. draft-ietf-acme-star-delegation-01 . . . . . . . . . . . 33 A.6. draft-ietf-acme-star-delegation-02 . . . . . . . . . . . 36
A.7. draft-ietf-acme-star-delegation-00 . . . . . . . . . . . 33 A.7. draft-ietf-acme-star-delegation-01 . . . . . . . . . . . 36
A.8. draft-sheffer-acme-star-delegation-01 . . . . . . . . . . 33 A.8. draft-ietf-acme-star-delegation-00 . . . . . . . . . . . 36
A.9. draft-sheffer-acme-star-delegation-00 . . . . . . . . . . 33 A.9. draft-sheffer-acme-star-delegation-01 . . . . . . . . . . 36
Appendix B. CSR Template: CDDL . . . . . . . . . . . . . . . . . 33 A.10. draft-sheffer-acme-star-delegation-00 . . . . . . . . . . 36
Appendix C. CSR Template: JSON Schema . . . . . . . . . . . . . 35 Appendix B. CSR Template: CDDL . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Appendix C. CSR Template: JSON Schema . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
This document is a companion document to [RFC8739]. To avoid This document is a companion document to [RFC8739]. 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 and further use cases, please
refer to the introductory sections of [RFC8739]. refer to the 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 authority 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 4.
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 STAR certificate for described in [RFC8739]) to request issuance of a Short-Term,
the same delegated identity. The generated short-term certificate is Automatically Renewed (STAR) certificate for the same delegated
automatically renewed by the ACME Certification Authority (CA), identity. The generated short-term certificate is automatically
periodically fetched by the NDC and used to terminate HTTPS renewed by the ACME Certification Authority (CA), periodically
connections in lieu of the IdO. The IdO can end the delegation at fetched by the NDC and used to terminate HTTPS connections in lieu of
any time by simply instructing the CA to stop the automatic renewal the IdO. The IdO can end the delegation at any time by simply
and letting the certificate expire shortly thereafter. instructing the CA to stop the automatic renewal and letting the
certificate expire shortly thereafter.
While the primary use case we address is delegation of STAR
certificates, the mechanism proposed here accommodates also long-
lived certificates managed with the ACME protocol. The most
noticeable difference between long-lived and STAR certificates is the
way the termination of the delegation is managed. In the case of
long-lived certificates, the IdO uses the revokeCert URL exposed by
the ACME CA and waits for the explicit revocation based on CRL and
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.
While the primary use case we address is delegation of STAR
certificates, the mechanism proposed here accommodates any
certificate managed with the ACME protocol. See Section 2.4 for
details.
We note that other ongoing efforts address the problem of certificate We note that other ongoing efforts address the problem of certificate
delegation for TLS connections, specifically [I-D.ietf-tls-subcerts] delegation for TLS connections, specifically [I-D.ietf-tls-subcerts]
and [I-D.mglt-lurk-tls13]. Compared to these other solutions, the and [I-D.mglt-lurk-tls13]. Compared to these other solutions, the
current draft does not introduce additional latency to the TLS current document does not introduce additional latency to the TLS
connection, nor does it require changes to the TLS network stack of connection, nor does it require changes to the TLS network stack of
either the client or the server. either the client or the server.
1.1. Terminology 1.1. Terminology
IdO Identifier Owner, the owner of an identifier (e.g., a domain IdO Identifier Owner, the owner of an identifier (e.g., a domain
name) that needs to be delegated. name) that needs to be delegated.
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 symmetry of the two acronyms).
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 The IETF Automated Certificate Management Environment, a
certificate management protocol. ACME Automated Certificate Management Environment, a certificate
CA A Certificate Authority that implements the ACME protocol. management protocol [RFC8555].
Synonymous with "ACME server".
CA A Certification Authority that implements the ACME protocol. In
this document, the term is synonymous with "ACME server".
CSR A PKCS#10 [RFC2986] Certificate Signing Request, as supported by
ACME.
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 draft as well as the include the ACME profile proposed in this document as well as the
extended ACME protocol described in [RFC8739]. extended ACME 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., "somesite.example.com"), requested
algorithms and key length, key usage, extensions (e.g., algorithms and key length, key usage, extensions (e.g.,
TNAuthList). The NDC is required to use this template for every TNAuthList). The NDC is required to 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 Certificate Authority * IdO has registered an ACME account with the Certification
(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 ACME server.
2.2. Overview 2.2. Overview
For clarity, the protocol overview presented here covers the main use
case of this protocol, namely delegation of STAR certificates.
Protocol behavior for non-STAR certificates is similar, and the
detailed differences are listed in the following sections.
The interaction between the NDC and the IdO is governed by the The interaction between the NDC and the IdO is governed by the
profiled ACME workflow detailed in Section 2.3. The interaction profiled ACME workflow detailed in Section 2.3. The interaction
between the IdO and the CA is ruled by ACME STAR [RFC8739] as well as between the IdO and the CA is ruled by ACME [RFC8555], ACME STAR
any other ACME extension that applies (e.g., [RFC8739] as well as any other ACME extension that applies (e.g.,
[I-D.ietf-acme-authority-token-tnauthlist] for STIR). [I-D.ietf-acme-authority-token-tnauthlist] for STIR).
The outline of the combined protocol is as follow (Figure 1): The outline of the combined protocol for STAR certificates is as
follow (Figure 1):
* NDC sends an order Order1 for the delegated identifier to IdO; * NDC sends an order Order1 for the delegated identifier to IdO;
* IdO creates an Order1 resource in state "ready" with a "finalize" * IdO creates an Order1 resource in state "ready" with a "finalize"
URL; URL;
* NDC immediately sends a finalize request (which includes the CSR) * NDC immediately sends a finalize request (which includes the CSR)
to the IdO; to the IdO;
* IdO verifies the CSR according to the agreed upon CSR template; * IdO verifies the CSR according to the agreed upon CSR template;
* If the CSR verification fails, Order1 is moved to an "invalid" * If the CSR verification fails, Order1 is moved to an "invalid"
state and everything stops; state and everything stops;
* If the CSR verification is successful, IdO moves Order1 to state * If the CSR verification is successful, IdO moves Order1 to state
skipping to change at page 7, line 30 skipping to change at page 8, line 16
Figure 1: End to end STAR delegation flow Figure 1: End to end STAR delegation flow
2.3. Delegated Identity Profile 2.3. Delegated Identity Profile
This section defines a profile of the ACME protocol, to be used This section defines a profile of the ACME protocol, to be used
between the NDC and IdO. between the NDC and IdO.
2.3.1. Delegation Configuration 2.3.1. Delegation Configuration
The IdO must be preconfigured to recognize one or more NDCs, and
present them with details about certificate delegations that apply to
each one.
2.3.1.1. Account Object Extensions 2.3.1.1. Account Object Extensions
An NDC identifies itself to the IdO as an ACME account. The IdO can An NDC identifies itself to the IdO as an ACME account. The IdO can
delegate multiple names to a NDC, and these configurations are delegate multiple names to 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:
skipping to change at page 9, line 9 skipping to change at page 9, line 24
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 is shown in Figure 3.
{ {
"csr-template": { "csr-template": {
"keyTypes": [ "keyTypes": [
{ {
"PublicKeyType": "ecPublicKey", "PublicKeyType": "id-ecPublicKey",
"Curve": "secp521r1", "namedCurve": "secp256r1",
"SignatureType": "ecdsa-with-SHA256" "SignatureType": "ecdsa-with-SHA256"
} }
], ],
"subject": { "subject": {
"country": "CA", "country": "CA",
"stateOrProvince": "**", "stateOrProvince": "**",
"locality": "**", "locality": "**",
"commonName": "**" "commonName": "**"
}, },
"extensions": { "extensions": {
skipping to change at page 9, line 38 skipping to change at page 10, line 4
], ],
"extendedKeyUsage": [ "extendedKeyUsage": [
"serverAuth" "serverAuth"
] ]
} }
}, },
"cname-map": { "cname-map": {
"abc.ndc.ido.example.": "abc.ndc.example." "abc.ndc.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 identifier in the Order object on the NDC-IdO side (see Figure 4).
Section 2.3.2). The value of this attribute is the URL pointing to The value of this attribute is the URL pointing to the delegation
the delegation configuration object that is to be used for this configuration object that is to be used for this certificate request.
certificate request. If the "delegation" attribute in the Order If the "delegation" attribute in the Order object contains a URL that
object contains a URL that does not correspond to a configuration does not correspond to a configuration available to the requesting
available to the requesting NDC, the IdO MUST return an error NDC, the IdO MUST return an error response with status code 403
response with status code 403 (Forbidden) and type (Forbidden) and type "urn:ietf:params:acme:error:unknownDelegation".
"urn:ietf:params:acme:error:unknownDelegation".
2.3.2. Order Object Transmitted from NDC to IdO and to ACME Server 2.3.2. Order Object Transmitted from NDC to IdO and to ACME Server
(STAR)
The Order object created by the NDC: If the delegation is for a STAR certificate, the Order object created
by the NDC:
* MUST have the delegated name as the identifier value with a * MUST have the delegated name as the identifier value with a
"delegation" attribute indicating the configuration used for the "delegation" attribute indicating the configuration used for the
identifier. identifier.
Besides, when delegation is for a STAR certificate, the Order:
* 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].
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({
skipping to change at page 10, line 48 skipping to change at page 11, line 34
], ],
"auto-renewal": { "auto-renewal": {
"end-date": "2020-04-20T00:00:00Z", "end-date": "2020-04-20T00:00:00Z",
"lifetime": 345600, // 4 days "lifetime": 345600, // 4 days
"allow-certificate-get": true "allow-certificate-get": true
} }
}), }),
"signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g" "signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g"
} }
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" configurations.
Besides, when delegation is for a STAR certificate, the Order:
* 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": "2019-05-01T00:00:00Z",
"identifiers": [ "identifiers": [
{ {
"type": "dns", "type": "dns",
"value": "abc.ndc.ido.example.", "value": "abc.ndc.ido.example.",
skipping to change at page 11, line 33 skipping to change at page 12, line 29
"end-date": "2020-04-20T00:00:00Z", "end-date": "2020-04-20T00:00:00Z",
"lifetime": 345600, "lifetime": 345600,
"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/TO8rfgo/finalize"
} }
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 that applies to each delegated identifier, as described
in Section 3.1. If the CSR fails validation for any of the in Section 3.1. If the CSR fails validation for any of the
identifiers, the IdO MUST return an error response with status code identifiers, the IdO MUST return an error response with status code
403 (Forbidden) and an appropriate type, e.g., "rejectedIdentifier" 403 (Forbidden) and an appropriate type, e.g., "rejectedIdentifier"
or "badCSR". The error response SHOULD contain subproblems or "badCSR". The error response SHOULD contain subproblems
(Section 6.7.1 of [RFC8555]) for each failed identifier. If the CSR (Section 6.7.1 of [RFC8555]) for each failed identifier. If the CSR
is successfully validated, the Order object status moves to 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 Order object created by the IdO:
* MUST copy the identifiers sent by the NDC and strip the * MUST copy the identifiers sent by the NDC and strip the
"delegation" attribute; "delegation" attribute;
Besides, when delegation is for a STAR certificate, the Order:
* 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 and
augment it with an "allow-certificate-get" attribute set to true. augment it with an "allow-certificate-get" attribute set to true.
Instead, when the delegation is for a non-STAR certificate, the
Order:
* MUST include the "allow-certificate-get" attribute set to true.
When the validation of the identifiers has been successfully When the validation of the identifiers has been successfully
completed and the certificate has been issued by the CA, the IdO: completed 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".
Besides, when delegation is for a STAR certificate, the IdO:
* MUST copy the "star-certificate" field from the STAR Order. The * MUST copy the "star-certificate" field from the STAR Order. The
latter indirectly includes (via the NotBefore and NotAfter HTTP latter indirectly includes (via the NotBefore and NotAfter HTTP
headers) the renewal timers needed by the NDC to inform its headers) the renewal timers needed by the NDC to inform its
certificate reload logic. certificate reload logic.
Instead, when the delegation is for a non-STAR certificate, the IdO:
* MUST copy the "certificate" field from the Order, as well as
"notBefore" and "notAfter" if these fields exist.
{ {
"status": "valid", "status": "valid",
"expires": "2019-05-01T00:00:00Z", "expires": "2019-05-01T00:00:00Z",
"identifiers": [ "identifiers": [
{ {
"type": "dns", "type": "dns",
"value": "abc.ndc.ido.example.", "value": "abc.ndc.ido.example.",
"delegation": "delegation":
"https://acme.ido.example/acme/delegations/adFqoz/2" "https://acme.ido.example/acme/delegations/adFqoz/2"
skipping to change at page 13, line 31 skipping to change at page 13, line 37
"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/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
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 corresponding CNAME records to its zone, e.g.:
abc.ndc.ido.example. CNAME abc.ndc.example. abc.ndc.ido.example. CNAME abc.ndc.example.
2.3.3. Capability Discovery 2.3.3. Order Object Transmitted from NDC to IdO and to ACME Server
(non-STAR)
If the delegation is for a non-STAR certificate, the Order object
created by the NDC:
* MUST have the delegated name as the identifier value with a
"delegation" attribute indicating the configuration used for the
identifier.
POST /acme/new-order HTTP/1.1
Host: acme.ido.example
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "ES256",
"kid": "https://acme.ido.example/acme/acct/evOfKhNU60wg",
"nonce": "IYBkoQfaCS80UcCn9qH8Gt",
"url": "https://acme.ido.example/acme/new-order"
}),
"payload": base64url({
"identifiers": [
{
"type": "dns",
"value": "abc.ndc.ido.example.",
"delegation":
"https://acme.ido.example/acme/delegations/adFqoz/2"
}
]
}),
"signature": "H6ZyWqg8aaKEkYca...dudoz4igiMvUBJ9j"
}
Figure 7: New Non-STAR Order from NDC
The Order object that is created on the IdO:
* MUST start in the "ready" state;
* MUST contain an "authorizations" array with zero elements;
* MUST contain the indicated "delegation" configurations.
{
"status": "ready",
"expires": "2019-05-01T00:00:00Z",
"identifiers": [
{
"type": "dns",
"value": "abc.ndc.ido.example.",
"delegation":
"https://acme.ido.example/acme/delegations/adFqoz/2"
}
],
"authorizations": [],
"finalize": "https://acme.ido.example/acme/order/to8RFGO/finalize"
}
Figure 8: Non-STAR Order Resource Created on IdO
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 is successfully validated, the Order object status moves to
"processing" and the twin ACME protocol instance is initiated on the
IdO-CA side.
The Order object created by the IdO:
* MUST copy the identifiers sent by the NDC and strip the
"delegation" attribute;
* MUST include the "allow-certificate-get" attribute set to true.
When the validation of the identifiers has been successfully
completed and the certificate has been issued by the CA, the IdO:
* MUST move its Order resource status to "valid".
* MUST copy the "certificate" field from the Order, as well as
"notBefore" and "notAfter" if these fields exist.
{
"status": "valid",
"expires": "2019-05-01T00:00:00Z",
"identifiers": [
{
"type": "dns",
"value": "abc.ndc.ido.example.",
"delegation":
"https://acme.ido.example/acme/delegations/adFqoz/2"
}
],
"allow-certificate-get": true,
"authorizations": [],
"finalize": "https://acme.ido.example/acme/order/to8RFGO/finalize",
"certificate": "https://acme.ca.example/acme/order/YtR23SsdG9"
}
Figure 9: Non-STAR Order Resource Updated on IdO
At this point of the protocol flow, the same considerations as in
Section 2.3.2.1 apply.
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 MUST contain the following
attribute in the "meta" field: attribute in the "meta" field:
* delegation-enabled: boolean flag indicating support for the * delegation-enabled: boolean flag indicating support for the
profile specified in this memo. An ACME server that supports this profile specified in this memo. An ACME server that supports this
delegation profile MUST include this key, and MUST set it to true. delegation profile MUST include this key, and MUST set it to true.
The "delegation-enabled" flag may be specified regardless of the The "delegation-enabled" flag may be specified regardless of the
existence or setting of the "auto-renewal" flag. existence or setting of the "auto-renewal" flag.
2.3.4. On Cancellation 2.3.5. Terminating the Delegation
It is worth noting that cancellation of the ACME STAR certificate is Identity delegation is terminated differently, depending on whether
a prerogative of the IdO. The NDC does not own the relevant account this is a STAR certificate or not.
key on the ACME server, therefore it can't issue a cancellation
request for the STAR cert. Potentially, since it holds the STAR
certificate's private key, it could request the revocation of a
single STAR certificate. However, STAR explicitly disables the
revokeCert interface.
2.4. Delegation of Non-STAR Certificates 2.3.5.1. By Cancellation (STAR)
The mechanism defined here can be used to delegate regular ACME The IdO can terminate the delegation of a STAR certificate by
certificates whose expiry is not "short term". requesting its cancellation (see Section 3.1.2 of [RFC8739]).
To allow delegation of non-STAR certificates, this document allows Cancellation of the ACME STAR certificate is a prerogative of the
use of "allow-certificate-get" directly in the Order object and IdO. The NDC does not own the relevant account key on the ACME
independently of the "auto-renewal" object, so that the NDC can fetch server, therefore it can't issue a cancellation request for the STAR
the certificate without having to authenticate into the ACME server. certificate. Potentially, since it holds the STAR certificate's
private key, it could request the revocation of a single STAR
certificate. However, STAR explicitly disables the revokeCert
interface.
The following differences exist between STAR and non-STAR certificate Shortly after the automatic renewal process is stopped by the IdO,
delegation: the last issued STAR certificate expires and the delegation
terminates.
* With STAR certificates, the "star-certificate" field is copied by 2.3.5.2. By Revocation (non-STAR)
the IdO; with non-STAR certificates, the "certificate" field is
copied.
* The "auto-renewal" object is not used (either in the request or
response) for non-STAR certificates. The field "allow-
certificate-get" MUST be included in the order object, and its
value MUST be "true".
* The "notBefore" and "notAfter" order fields are omitted only in
STAR certificates.
When delegating a non-STAR certificate, standard certificate The IdO can terminate the delegation of a non-STAR certificate by
revocation still applies. The ACME certificate revocation endpoint requesting it to be revoked using the revokeCert URL exposed by the
is explicitly unavailable for STAR certificates but it is available ACME server.
for all other certificates. We note that according to Sec. 7.6 of
[RFC8555], the revocation endpoint can be used with either the
account keypair, or the certificate keypair. In other words, the NDC
would be able to revoke the certificate. However, given the trust
relationship between NDC and IdO expected by the delegation trust
model (Section 6.1) as well as the lack of incentives for the NDC -
which, doing so, would create a self-inflicted DoS - this does not
represent a security risk.
2.5. Proxy Behavior According to Section 7.6 of [RFC8555], the revocation endpoint can be
used with either the account keypair, or the certificate keypair. In
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
revoke the certificate using the associated private key. However,
given the trust relationship between NDC and IdO expected by the
delegation trust model (Section 6.1), as well as the lack of
incentives for the NDC to prematurely terminate the delegation, this
does not represent a security risk.
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 4.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 ACME server for the identity
skipping to change at page 15, line 38 skipping to change at page 18, line 22
- 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. - And similarly, any "Link" relations.
* 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 MUST be copied as-is. - Similarly, the "star-certificate" URL (or the "certificate" URL
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.
skipping to change at page 16, line 42 skipping to change at page 19, line 29
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 An alternative, non-normative JSON Schema syntax is given in
Appendix C. Appendix C.
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], Sec. 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 5.6.
The "subjectAltName" field is currently defined for the following
identifiers: DNS names, email addresses, and URIs. New identifier
types may be added in the future by documents that extend this
specification. Each new identifier type SHALL have an associated
identifier validation challenge that the ACME CA can use to obtain
proof 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 CSR is received by the IdO, it MUST verify that the CSR is When the IdO receives the CSR, it MUST verify that the CSR is
consistent with the template that the IdO sent earlier. The IdO MAY consistent with the template contained in the "delegation" object
enforce additional constraints, e.g. by restricting field lengths. referenced in the Order. The IdO MAY enforce additional constraints,
In this regard, note that a "subjectAltName" of type "DNS" can be e.g. by restricting field lengths. In this regard, note that a
specified using the wildcard notation, meaning that the NDC can be "subjectAltName" of type "DNS" can be specified using the wildcard
required ("**") or offered the possibility ("*") to define the notation, meaning that the NDC can be required ("**") or offered the
delegated domain name by itself. If this is the case, the IdO needs possibility ("*") to define the delegated domain name by itself. If
to have a further layer of checks on top of the control rules already this is the case, the IdO needs to have a further layer of checks on
provided by the CSR template to fully validate the CSR input. top of the control rules already provided by the CSR template to
fully validate the CSR input.
3.2. Example 3.2. Example
The CSR template in Figure 4 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,
"SignatureType": "sha256WithRSAEncryption" "SignatureType": "sha256WithRSAEncryption"
}, },
skipping to change at page 18, line 40 skipping to change at page 21, line 40
"keyUsage": [ "keyUsage": [
"digitalSignature" "digitalSignature"
], ],
"extendedKeyUsage": [ "extendedKeyUsage": [
"serverAuth", "serverAuth",
"clientAuth" "clientAuth"
] ]
} }
} }
Figure 4: Example CSR template Figure 10: Example CSR template
4. Further Use Cases 4. 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. CDNI 4.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 4.1.1. Multiple Parallel Delegates
skipping to change at page 19, line 50 skipping to change at page 22, line 50
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 4.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 5. Figure 11.
.------------. .------------.
video.cp.example ? | .-----. | video.cp.example ? | .-----. |
.---------------------------------->| | | .---------------------------------->| | |
| (a) | | DNS | CP | | (a) | | DNS | CP |
| .-------------------------------+ | | | .-------------------------------+ | |
| | CNAME video.ucdn.example | '-----' | | | CNAME video.ucdn.example | '-----' |
| | '------------' | | '------------'
| | | |
| | | |
skipping to change at page 20, line 35 skipping to change at page 23, line 35
| | '------------------------------>| | | | | '------------------------------>| | |
| | (c) | | DNS | | | | (c) | | DNS | |
| '-----------------------------------+ | | | '-----------------------------------+ | |
| A 192.0.2.1 | +-----+ dCDN | | A 192.0.2.1 | +-----+ dCDN |
| | | | | | | | | |
'--------------------------------------->| TLS | | '--------------------------------------->| TLS | |
SNI: video.cp.example | | | | SNI: video.cp.example | | | |
| '-----' | | '-----' |
'------------' '------------'
Figure 5: 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 an SNI equal
to the "host" in the original URI - in the example, to the "host" in the original URI - in the example,
"video.cp.example". So, in order to successfully complete the "video.cp.example". So, in order to successfully complete the
handshake, the landing dCDN node has to be configured with a handshake, the landing dCDN node has to be configured with a
certificate whose subjectAltName matches "video.cp.example", i.e., a certificate whose subjectAltName matches "video.cp.example", i.e., a
Content Provider's name. Content Provider's name.
Figure 6 illustrates the cascaded delegation flow that allows dCDN to Figure 12 illustrates the cascaded delegation flow that allows dCDN
obtain a STAR certificate that bears a name belonging to the Content to obtain a STAR certificate that bears a name belonging to the
Provider with a private key that is only known to the dCDN. Content Provider with a private key that is only known to the dCDN.
.--------------------. .--------------------.
| .------.------. | | .------.------. |
| | STAR | ACME |<-------------. | | STAR | ACME |<-------------.
.------->| CP | dele | STAR | | | .------->| CP | dele | STAR | | |
| | | srv | cli +-----. | | | | srv | cli +-----. |
| | '---+--'------' | | 6 | | '---+--'------' | | 6
| '---------|------^---' 5 | | '---------|------^---' 5 |
| | | | .--|-------. | | | | .--|-------.
| | | | | .-+----. | | | | | | .-+----. |
skipping to change at page 21, line 39 skipping to change at page 24, line 39
1 | | 3 | | 1 | | 3 | |
| | | | 9 | | | | | 9 |
.-------|--v---v--|---------. | | .-------|--v---v--|---------. | |
| .-+----.----+-.------. | | | | .-+----.----+-.------. | | |
| | | STAR | +------------' | | | | STAR | +------------' |
| dCDN | CDNI | dele | HTTP | | | | dCDN | CDNI | dele | HTTP | | |
| | | cli | |<--------------' | | | cli | |<--------------'
| '------'------'------' | | '------'------'------' |
'---------------------------' '---------------------------'
Figure 6: Two levels delegation in CDNI Figure 12: Two levels delegation in CDNI
uCDN is configured to delegate to dCDN, and CP is configured to uCDN is configured to delegate to dCDN, and CP is configured to
delegate to uCDN, both as defined in Section 2.3.1. delegate to uCDN, both as defined in Section 2.3.1.
1. dCDN requests CDNI path metadata to uCDN; 1. dCDN requests CDNI path metadata to uCDN;
2. uCDN replies with, among other CDNI metadata, the STAR 2. uCDN replies with, among other CDNI metadata, the STAR
delegation configuration, which includes the delegated Content delegation configuration, which includes the delegated Content
Provider's name; Provider's name;
3. dCDN creates a key-pair and the CSR with the delegated name. It 3. dCDN creates a key-pair and the CSR with the delegated name. It
then places an order for the delegated name to uCDN; then places an order for the delegated name to uCDN;
skipping to change at page 22, line 21 skipping to change at page 25, line 21
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 ACME server;
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. STIR 4.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
[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
order to do that, SP2 needs a STIR certificate, and private key, that order to do that, SP2 needs a STIR certificate, and private key, that
includes TN=+123 in the TNAuthList [RFC8226] certificate extension. includes TN=+123 in the TNAuthList [RFC8226] certificate extension.
In details (Figure 7): 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;
4. Subsequently, after the required TNAuthList authorizations are 4. Subsequently, after the required TNAuthList authorizations are
skipping to change at page 23, line 28 skipping to change at page 26, line 31
| 2 | | | '---+--' | | 2 | | | '---+--' |
| | | | '----|-----' | | | | '----|-----'
| .------|--v---------. 6 | | .------|--v---------. 6 |
| | .-+----.------. | | 7 | | .-+----.------. | | 7
| | | STAR | +-----' | | | | STAR | +-----' |
'-->| SP2 | dele | HTTP | | | '-->| SP2 | dele | HTTP | | |
| | cli | |<--------------' | | cli | |<--------------'
| '----+-'-+----' | | '----+-'-+----' |
'-------------------' '-------------------'
Figure 7: 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 5. IANA Considerations
[[RFC Editor: please replace XXXX below by the RFC number.]] [[RFC Editor: please replace XXXX below by the RFC number.]]
skipping to change at page 26, line 10 skipping to change at page 29, line 10
Each extension registered must specify: Each extension registered must specify:
* An extension name. * An extension name.
* An extension syntax, as a reference to a JSON Schema 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 JSON Schema document in Appendix C. 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 |
+==================+===========+===============================+ +==================+===========+===============================+
| keyUsage | See | [RFC5280], Sec. 4.2.1.3 | | keyUsage | See | [RFC5280], Section 4.2.1.3 |
| | Appendix | | | | Appendix | |
| | C | | | | B | |
+------------------+-----------+-------------------------------+ +------------------+-----------+-------------------------------+
| extendedKeyUsage | See | [RFC5280], Sec. 4.2.1.12 | | extendedKeyUsage | See | [RFC5280], Section 4.2.1.12 |
| | Appendix | | | | Appendix | |
| | C | | | | B | |
+------------------+-----------+-------------------------------+ +------------------+-----------+-------------------------------+
| subjectAltName | See | [RFC5280], Sec. 4.2.1.6 (note | | subjectAltName | See | [RFC5280], Section 4.2.1.6 |
| | Appendix | that only specific name | | | Appendix | (note that only specific name |
| | C | formats are allowed: URI, DNS | | | B | formats are allowed: URI, DNS |
| | | name, email address) | | | | name, email address) |
+------------------+-----------+-------------------------------+ +------------------+-----------+-------------------------------+
Table 6 Table 6
6. Security Considerations 6. Security Considerations
6.1. Trust Model 6.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
skipping to change at page 27, line 52 skipping to change at page 30, line 52
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]).
6.3. New ACME Channels 6.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 8. in Figure 14.
ACME Channel ACME Channel
.------------>------------. .------------>------------.
.-----. ACME Channel .--+--. .--+----------. .-----. ACME Channel .--+--. .--+----------.
| NDC +------------->| IdO | | ACME server | | NDC +------------->| IdO | | ACME server |
'--+--' '--+--' '--+-+--------' '--+--' '--+--' '--+-+--------'
| '-----------<-------------' | | '-----------<-------------' |
| Validation Channel | | 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 8: 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 ACME server leg. The same can be said for the ACME channel on the
NDC/IdO leg. A slightly different set of considerations apply to the NDC/IdO leg. A slightly different set of considerations apply to the
ACME Channel between NDC and ACME server, which consists of a subset ACME Channel between NDC and ACME server, which consists of a subset
of the ACME interface comprising two API endpoints: the of the ACME interface comprising two API endpoints: the
unauthenticated certificate retrieval and, potentially, non-STAR unauthenticated certificate retrieval and, potentially, non-STAR
revocation via certificate private key. No specific security revocation via certificate private key. No specific security
considerations apply to the former, but the privacy considerations in considerations apply to the former, but the privacy considerations in
skipping to change at page 29, line 34 skipping to change at page 32, line 34
it, and MUST require "dns-01" as the sole validation method. 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 CAs.
7. Acknowledgments 7. 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, Sanjay Mishra, Jon proposals: Roman Danyliw, Frédéric Fieau, Russ Housley, Sanjay
Peterson, Ryan Sleevi, Emile Stephan. Mishra, Jon Peterson, Ryan Sleevi, Emile Stephan.
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 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000,
<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 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
skipping to change at page 31, line 9 skipping to change at page 34, line 11
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 8.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-06, 9 March 2020, <http://www.ietf.org/ tnauthlist-07, 22 February 2021,
internet-drafts/draft-ietf-acme-authority-token- <https://www.ietf.org/archive/id/draft-ietf-acme-
tnauthlist-06.txt>. authority-token-tnauthlist-07.txt>.
[I-D.ietf-cdni-interfaces-https-delegation] [I-D.ietf-cdni-interfaces-https-delegation]
Fieau, F., Emile, S., and S. Mishra, "CDNI extensions for Fieau, F., Stephan, E., and S. Mishra, "CDNI extensions
HTTPS delegation", Work in Progress, Internet-Draft, for HTTPS delegation", Work in Progress, Internet-Draft,
draft-ietf-cdni-interfaces-https-delegation-04, 9 draft-ietf-cdni-interfaces-https-delegation-05, 12 March
September 2020, <http://www.ietf.org/internet-drafts/ 2021, <https://www.ietf.org/archive/id/draft-ietf-cdni-
draft-ietf-cdni-interfaces-https-delegation-04.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
Progress, Internet-Draft, draft-ietf-stir-cert-delegation- Progress, Internet-Draft, draft-ietf-stir-cert-delegation-
03, 13 July 2020, <http://www.ietf.org/internet-drafts/ 04, 22 February 2021, <https://www.ietf.org/archive/id/
draft-ietf-stir-cert-delegation-03.txt>. draft-ietf-stir-cert-delegation-04.txt>.
[I-D.ietf-tls-subcerts] [I-D.ietf-tls-subcerts]
Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla,
"Delegated Credentials for TLS", Work in Progress, "Delegated Credentials for TLS", Work in Progress,
Internet-Draft, draft-ietf-tls-subcerts-10, 24 January Internet-Draft, draft-ietf-tls-subcerts-10, 24 January
2021, <http://www.ietf.org/internet-drafts/draft-ietf-tls- 2021, <https://www.ietf.org/archive/id/draft-ietf-tls-
subcerts-10.txt>. subcerts-10.txt>.
[I-D.mglt-lurk-tls13] [I-D.mglt-lurk-tls13]
Migault, D., "LURK Extension version 1 for (D)TLS 1.3 Migault, D., "LURK Extension version 1 for (D)TLS 1.3
Authentication", Work in Progress, Internet-Draft, draft- Authentication", Work in Progress, Internet-Draft, draft-
mglt-lurk-tls13-04, 25 January 2021, <http://www.ietf.org/ mglt-lurk-tls13-04, 25 January 2021,
internet-drafts/draft-mglt-lurk-tls13-04.txt>. <https://www.ietf.org/archive/id/draft-mglt-lurk-
tls13-04.txt>.
[json-schema-07] [json-schema-07]
Wright, A., Andrews, H., and G. Luff, "JSON Schema Wright, A., Andrews, H., and G. Luff, "JSON Schema
Validation: A Vocabulary for Structural Validation of Validation: A Vocabulary for Structural Validation of
JSON", 2018, <https://datatracker.ietf.org/doc/html/draft- JSON", 2018, <https://datatracker.ietf.org/doc/html/draft-
handrews-json-schema-validation-01>. handrews-json-schema-validation-01>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
skipping to change at page 32, line 23 skipping to change at page 35, line 30
[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>.
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-06 A.1. draft-ietf-acme-star-delegation-07
* SecDir comments by Russ Housley.
* In particular, reorganized some parts of the document to clarify
handling of non-STAR certificates.
* And changed the document's title accordingly.
A.2. draft-ietf-acme-star-delegation-06
* CDDL schema to address Roman's remaining comments. * CDDL schema to address Roman's remaining comments.
A.2. draft-ietf-acme-star-delegation-05 A.3. 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.3. draft-ietf-acme-star-delegation-04 A.4. 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.4. draft-ietf-acme-star-delegation-03 A.5. 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.5. draft-ietf-acme-star-delegation-02 A.6. 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.6. draft-ietf-acme-star-delegation-01 A.7. 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.7. draft-ietf-acme-star-delegation-00 A.8. draft-ietf-acme-star-delegation-00
* Republished as a working group draft. * Republished as a working group draft.
A.8. draft-sheffer-acme-star-delegation-01 A.9. 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.9. draft-sheffer-acme-star-delegation-00 A.10. 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 An additional constraint that is not expressed in CDDL but MUST be
validated by the recipient is that all objects (e.g. validated by the recipient is that all objects (e.g.
"distinguishedName") MUST NOT be empty when they are included, even "distinguishedName") MUST NOT be empty when they are included, even
when each separate property is optional. when each separate property is optional.
csr-template-schema = { csr-template-schema = {
keyTypes: [ 1* $keyType ] keyTypes: [ 1* $keyType ]
? subject: distinguishedName ? subject: distinguishedName
extensions: extensions extensions: extensions
} }
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
distinguishedName = { regtext-or-wildcard = regtext / wildcard
? country: regtext-or-wildcard
? stateOrProvince: regtext-or-wildcard
? locality: regtext-or-wildcard
? organization: regtext-or-wildcard
? organizationalUnit: regtext-or-wildcard
? emailAddress: regtext-or-wildcard
? commonName: regtext-or-wildcard
}
$keyType /= rsaKeyType distinguishedName = {
$keyType /= ecdsaKeyType ? country: regtext-or-wildcard
? stateOrProvince: regtext-or-wildcard
? locality: regtext-or-wildcard
? organization: regtext-or-wildcard
? organizationalUnit: regtext-or-wildcard
? emailAddress: regtext-or-wildcard
? commonName: regtext-or-wildcard
}
rsaKeyType = { $keyType /= rsaKeyType
PublicKeyType: "rsaEncryption" ; OID: 1.2.840.113549.1.1.1 $keyType /= ecdsaKeyType
PublicKeyLength: rsaKeySize
SignatureType: $rsaSignatureType
}
rsaKeySize = int .ge 2048 rsaKeyType = {
PublicKeyType: "rsaEncryption" ; OID: 1.2.840.113549.1.1.1
PublicKeyLength: rsaKeySize
SignatureType: $rsaSignatureType
}
; RSASSA-PKCS1-v1_5 with SHA-256 rsaKeySize = int .ge 2048
$rsaSignatureType /= "sha256WithRSAEncryption"
; RSASSA-PCKS1-v1_5 with SHA-384
$rsaSignatureType /= "sha384WithRSAEncryption"
; RSASSA-PCKS1-v1_5 with SHA-512
$rsaSignatureType /= "sha512WithRSAEncryption"
; RSASSA-PSS with SHA-256, MGF-1 with SHA-256, and a salt length of 32 bytes
$rsaSignatureType /= "sha256WithRSAandMGF1"
; RSASSA-PSS with SHA-384, MGF-1 with SHA-384, and a salt length of 48 bytes
$rsaSignatureType /= "sha384WithRSAandMGF1"
; RSASSA-PSS with SHA-512, MGF-1 with SHA-512, and a salt length of 64 bytes
$rsaSignatureType /= "sha512WithRSAandMGF1"
ecdsaKeyType = { ; RSASSA-PKCS1-v1_5 with SHA-256
PublicKeyType: "id-ecPublicKey" ; OID: 1.2.840.10045.2.1 $rsaSignatureType /= "sha256WithRSAEncryption"
namedCurve: $ecdsaCurve ; RSASSA-PCKS1-v1_5 with SHA-384
SignatureType: $ecdsaSignatureType $rsaSignatureType /= "sha384WithRSAEncryption"
} ; RSASSA-PCKS1-v1_5 with SHA-512
$rsaSignatureType /= "sha512WithRSAEncryption"
; RSASSA-PSS with SHA-256, MGF-1 with SHA-256, and a 32 byte salt
$rsaSignatureType /= "sha256WithRSAandMGF1"
; RSASSA-PSS with SHA-384, MGF-1 with SHA-384, and a 48 byte salt
$rsaSignatureType /= "sha384WithRSAandMGF1"
; RSASSA-PSS with SHA-512, MGF-1 with SHA-512, and a 64 byte salt
$rsaSignatureType /= "sha512WithRSAandMGF1"
$ecdsaCurve /= "secp256r1" ; OID: 1.2.840.10045.3.1.7 ecdsaKeyType = {
$ecdsaCurve /= "secp384r1" ; OID: 1.3.132.0.34 PublicKeyType: "id-ecPublicKey" ; OID: 1.2.840.10045.2.1
$ecdsaCurve /= "secp521r1" ; OID: 1.3.132.0.3 namedCurve: $ecdsaCurve
SignatureType: $ecdsaSignatureType
}
$ecdsaSignatureType /= "ecdsa-with-SHA256" ; paired with secp256r1 $ecdsaCurve /= "secp256r1" ; OID: 1.2.840.10045.3.1.7
$ecdsaSignatureType /= "ecdsa-with-SHA384" ; paired with secp384r1 $ecdsaCurve /= "secp384r1" ; OID: 1.3.132.0.34
$ecdsaSignatureType /= "ecdsa-with-SHA512" ; paired with secp521r1 $ecdsaCurve /= "secp521r1" ; OID: 1.3.132.0.3
subjectaltname = { $ecdsaSignatureType /= "ecdsa-with-SHA256" ; paired with secp256r1
? DNS: [ 1* regtext-or-wildcard ] $ecdsaSignatureType /= "ecdsa-with-SHA384" ; paired with secp384r1
? Email: [ 1* regtext ] $ecdsaSignatureType /= "ecdsa-with-SHA512" ; paired with secp521r1
? URI: [ 1* regtext ]
* $$subjectaltname-extension
}
extensions = { subjectaltname = {
? keyUsage: [ 1* keyUsageType ] ? DNS: [ 1* regtext-or-wildcard ]
? extendedKeyUsage: [ 1* extendedKeyUsageType ] ? Email: [ 1* regtext ]
subjectAltName: subjectaltname ? URI: [ 1* regtext ]
} * $$subjectaltname-extension
}
keyUsageType /= "digitalSignature" extensions = {
keyUsageType /= "nonRepudiation" ? keyUsage: [ 1* keyUsageType ]
keyUsageType /= "keyEncipherment" ? extendedKeyUsage: [ 1* extendedKeyUsageType ]
keyUsageType /= "dataEncipherment" subjectAltName: subjectaltname
keyUsageType /= "keyAgreement" }
keyUsageType /= "keyCertSign"
keyUsageType /= "cRLSign"
keyUsageType /= "encipherOnly"
keyUsageType /= "decipherOnly"
extendedKeyUsageType /= "serverAuth" keyUsageType /= "digitalSignature"
extendedKeyUsageType /= "clientAuth" keyUsageType /= "nonRepudiation"
extendedKeyUsageType /= "codeSigning" keyUsageType /= "keyEncipherment"
extendedKeyUsageType /= "emailProtection" keyUsageType /= "dataEncipherment"
extendedKeyUsageType /= "timeStamping" keyUsageType /= "keyAgreement"
extendedKeyUsageType /= "OCSPSigning" keyUsageType /= "keyCertSign"
keyUsageType /= "cRLSign"
keyUsageType /= "encipherOnly"
keyUsageType /= "decipherOnly"
extendedKeyUsageType /= "serverAuth"
extendedKeyUsageType /= "clientAuth"
extendedKeyUsageType /= "codeSigning"
extendedKeyUsageType /= "emailProtection"
extendedKeyUsageType /= "timeStamping"
extendedKeyUsageType /= "OCSPSigning"
extendedKeyUsageType /= oid
oid = text .regexp "[0-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
skipping to change at page 38, line 50 skipping to change at page 42, line 21
"cRLSign", "cRLSign",
"encipherOnly", "encipherOnly",
"decipherOnly" "decipherOnly"
] ]
} }
}, },
"extendedKeyUsage": { "extendedKeyUsage": {
"type": "array", "type": "array",
"minItems": 1, "minItems": 1,
"items": { "items": {
"type": "string", "oneOf": [
"enum": [ {
"serverAuth", "type": "string",
"clientAuth", "enum": [
"codeSigning", "serverAuth",
"emailProtection", "clientAuth",
"timeStamping", "codeSigning",
"OCSPSigning" "emailProtection",
"timeStamping",
"OCSPSigning"
]
},
{
"type": "string",
"pattern": "^[0-9]+(\\.[0-9]+)*$",
"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,
 End of changes. 104 change blocks. 
299 lines changed or deleted 455 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/