Movatterモバイル変換

[0]ホーム
URL:

RFC 9115ACME DelegationSeptember 2021
Sheffer, et al.Standards Track[Page]
Stream:
Internet Engineering Task Force (IETF)
RFC:
9115
Category:
Standards Track
Published:
ISSN:
2070-1721
Authors:
Y. Sheffer
Intuit
D. López
Telefonica I+D
A. Pastor Perales
Telefonica I+D
T. Fossati
ARM

RFC 9115

An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates

Abstract

This document defines a profile of the Automatic Certificate Management Environment(ACME) protocol by which the holder of an identifier (e.g., a domain name) canallow a third party to obtain an X.509 certificate such that the certificatesubject is the delegated identifier while the certified public key correspondsto 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 holder of a domainname). The presented mechanism allows the holder of the identifier to retaincontrol over the delegation and revoke it at any time. Importantly, thismechanism does not require any modification to the deployed TLSclients and servers.

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9115.

Copyright Notice

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

▲

Table of Contents

1.Introduction

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 for this solution. Formore details, please refer to the introductory sectionsof[RFC8739].

An Identifier Owner (IdO) has agreementsin place with one or more Name Delegation Consumer (NDC) to use and attest itsidentity.

In the primary use case, the IdO is a content provider, and we consider a Content Delivery Network (CDN) provider contracted toserve the content over HTTPS. The CDN terminates the HTTPS connection atone of its edge cache servers and needs to present its clients (browsers,mobile apps, set-top boxes) a certificate whose name matches the domain name ofthe URL that is requested, i.e., that of the IdO. Understandably, some IdOs may balk at sharing their long-term private keys with another organization;equally, delegates would rather not have to handle other parties' long-termsecrets. Other relevant use cases are discussed inSection 5.

This document describes a profile of the ACME protocol[RFC8555] that allowsthe NDC to request from the IdO, acting as a profiled ACME server, a certificate fora delegated identity -- i.e., one belonging to the IdO. The IdO then uses theACME protocol (with the extensions described in[RFC8739]) to requestissuance of a Short-Term, Automatically Renewed (STAR) certificate for the same delegated identity. The generatedshort-term certificate is automatically renewed by the ACME CertificationAuthority (CA), is periodically fetched by the NDC, and is used to terminate HTTPSconnections in lieu of the IdO. The IdO can end the delegation at any time bysimply instructing the CA to stop the automatic renewal and letting thecertificate expire shortly thereafter.

While the primary use case we address is a delegation of STAR certificates, themechanism proposed here also accommodates long-lived certificates managed withthe ACME protocol. The most noticeable difference between long-lived and STARcertificates is the way the termination of the delegation is managed. In thecase of long-lived certificates, the IdO uses therevokeCert URL exposed by theCA and waits for the explicit revocation based on the Certificate RevocationList (CRL) and Online Certificate Status Protocol (OCSP) to propagate to therelying parties.

In case the delegated identity is a domain name, this document also provides away for the NDC to inform the IdO about the CNAME mappings that need to beinstalled in the IdO's DNS zone to enable the aliasing of the delegated name,thus allowing the complete name delegation workflow to be handled using asingle interface.

We note that other standardization efforts address the problem of certificate delegation for TLS connections, specifically[TLS-SUBCERTS] and[MGLT-LURK-TLS13]. The former extends the TLS certificate chain with a customer-owned signing certificate; the latter separates the server's private key into a 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

IdO

Identifier Owner, the holder (current owner) of an identifier (e.g., a domainname) that needs to be delegated. Depending on the context, the term IdO mayalso be used to designate the (profiled) ACME server deployed by the IdentifierOwner 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 isdelegated for a limited time. This is a CDN in the primary usecase (in fact, readers may note the similarity of the twoabbreviations). Depending on the context, the term NDC mayalso be used to designate the (profiled) ACME client used by the NameDelegation Consumer.

CDN

Content Delivery Network, a widely distributed network thatserves the domain's web content to a wide audience at highperformance.

STAR

Short-Term, Automatically Renewed, as applied to X.509 certificates.

ACME

Automated Certificate Management Environment, acertificate management protocol[RFC8555].

CA

Certification Authority, specifically one that implements the ACME protocol. In this document, the term is synonymous with "ACME server deployed by the Certification Authority".

CSR

Certificate Signing Request, specifically a PKCS#10[RFC2986] Certificate Signing Request, as supported by ACME.

FQDN

Fully Qualified Domain Name.

1.2.Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED","MAY", and "OPTIONAL" in this document are to be interpreted asdescribed in BCP 14[RFC2119][RFC8174] when, and only when, theyappear in all capitals, as shown here.

2.Protocol Flow

This section presents the protocol flow. For completeness, we include the ACMEprofile proposed in this document as well as the ACME STAR protocol describedin[RFC8739].

2.1.Preconditions

The protocol assumes the following preconditions are met:

  • The IdO exposes an ACME server interface to the NDC(s) comprising the accountmanagement interface.
  • The NDC has registered an ACME account with the IdO.
  • The NDC and IdO have agreed on a "CSR template" to use, including at a minimum:subject name (e.g.,abc.ido.example), requested algorithms and keylength, key usage, and extensions. The NDC will usethis template for every CSR created under the same delegation.
  • The IdO has registered an ACME account with the Certification Authority (CA).

Note that even if the IdO implements the ACME server role, it is not acting asa CA; in fact, from the point of view of the certificate issuance process, theIdO only works as a "policing" forwarder of the NDC's key pair and isresponsible for completing the identity verification process towards the CA.

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 profiled ACMEworkflow detailed inSection 2.3. The interaction between the IdO and theCA is ruled by ACME[RFC8555], ACME STAR[RFC8739], and any other ACME extension thatapplies (e.g.,[TOKEN-TNAUTHLIST] for Secure Telephone Identity Revisited (STIR)).

The outline of the combined protocol for STAR certificates is as follows (Figure 1):

  • NDC sends an Order1 for the delegated identifier to IdO.
  • IdO creates an Order1 resource in stateready with afinalize URL.
  • NDC immediately sends afinalize request (which includes the CSR) to the IdO.
  • IdO verifies the CSR according to the agreed upon CSR template.
  • If the CSR verification fails, Order1 is moved to aninvalid state andeverything stops.
  • If the CSR verification is successful, IdO moves Order1 to stateprocessing and sends a new Order2 (using its own account) for the delegatedidentifier to the CA.
  • If the ACME STAR protocol fails, Order2 moves toinvalid, and the same stateis reflected in Order1 (i.e., the NDC Order).
  • If the ACME STAR run is successful (i.e., Order2 isvalid), IdO copies thestar-certificate URL from Order2 to Order1 and updates the Order1 state tovalid.

The NDC can now download, install, and use the short-term certificate bearing the name delegated by the IdO. The STAR certificate can be used until it expires, at which time the NDC is guaranteed to find a new certificate it can download, install, and use. This continues with subsequent certificates until either Order1 expires or the IdO decides to cancel the automatic renewal process with the CA.

Note that the interactive identifier authorization phase described inSection 7.5 of [RFC8555] is suppressed on the NDC-IdO side because the delegatedidentity contained in the CSR presented to the IdO is validated against theconfigured CSR template (Section 4.1). Therefore, the NDCsends thefinalize request, including the CSR, to the IdO immediately afterOrder1 has been acknowledged. The IdOSHALL buffer a (valid) CSR until theValidation phase completes successfully.

Also note that the successful negotiation of the unauthenticated GET (Section 3.4 of [RFC8739]) is required in order to allow the NDC to access thestar-certificate URL on the CA.

etannICreSa~~erriroitutSeT)tNleoiettteutlidAeaAwRcennuedGn~G(]hf(ut]osgETiAtcc[y[rca>nznAiirneanEisksetecraqrsnDiSgoi#T]tCe.Raa~aSatazuiidog<(teCeSfiiweRfmVTSg~asattehSaSCauaSAnivetiaCsicciade1utaeru~eNaitntuhCnanRi>-<TtRdrr<inrAtSieunrEn~~ct[tgielisrOtnAicciodti~lisufula~~cetaieSrreeenr#eirRerielC.TnOSanaeat2meihoteotdc)en[ku~vtoerniAOtdd~tGcevtuww)irvott.dCanuitf1iMctsaiiC2n~Rgertn#pguetdAeeeah~d>c]Eecf
Figure 1:End-to-End STAR Delegation Flow

2.3.Delegated Identity Profile

This section defines a profile of the ACME protocol to be used between the NDCand IdO.

2.3.1.Delegation Configuration

The IdO must be preconfigured to recognize one or more NDCs and present them withdetails about certificate delegations that apply to each one.

2.3.1.1.Account Object Extensions

An NDC identifies itself to the IdO as an ACME account. The IdO can delegatemultiple names to an NDC, and these configurations are described throughdelegation objects associated with the NDC's account object on the IdO.

As shown inFigure 2, the ACME account resource on the IdO isextended with a newdelegations attribute:

delegations (required, string):
A URL from which a list of delegationsconfigured for this account (Section 2.3.1.3) can be fetched via aPOST-as-GET request.
{  "status": "valid",  "contact": [    "mailto:delegation-admin@ido.example"  ],  "termsOfServiceAgreed": true,  "orders": "https://example.com/acme/orders/saHpfB",  "delegations": "https://acme.ido.example/acme/delegations/adFqoz"}
Figure 2:Example Account Object with Delegations
2.3.1.2.Delegation Lists

Each account object includes adelegations URL from which a list ofdelegation configurations created by the IdO can be fetched via a POST-as-GETrequest. The result of the requestMUST be a JSON object whosedelegationsfield is an array of URLs, each identifying a delegation configuration madeavailable to the NDC account (Section 2.3.1.3). The serverMAYreturn an incomplete list, along with aLink header field with anext linkrelation indicating where further entries can be acquired.

HTTP/1.1 200 OKContent-Type: application/jsonLink: <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"  ]}

Note that in the figure above, https://acme.ido.example/acme/delegations/adFqoz?cursor=2 includes a line breakfor the sake of presentation.

2.3.1.3.Delegation Objects

This profile extends the ACME resource model with a new read-onlydelegationobject that represents a delegation configuration that applies to a given NDC.

Adelegation object contains the CSR template (seeSection 4) thatapplies to that delegation and, optionally, any related CNAME mapping for thedelegated identifiers. Its structure is as follows:

csr-template (required, object):
CSR template, as defined inSection 4.
cname-map (optional, object):
A map of FQDN pairs. In each pair, the name isthe delegated identifier; the value is the corresponding NDC name that isaliased in the IdO's zone file to redirect the resolvers to the delegatedentity. Both names and valuesMUST be FQDNs with a terminating '.'.This field is only meaningful for identifiers of typedns.

An exampledelegation object in JSON format is shown inFigure 3.

{  "csr-template": {    "keyTypes": [      {        "PublicKeyType": "id-ecPublicKey",        "namedCurve": "secp256r1",        "SignatureType": "ecdsa-with-SHA256"      }    ],    "subject": {      "country": "CA",      "stateOrProvince": "**",      "locality": "**"    },    "extensions": {      "subjectAltName": {        "DNS": [          "abc.ido.example"        ]      },      "keyUsage": [        "digitalSignature"      ],      "extendedKeyUsage": [        "serverAuth"      ]    }  },  "cname-map": {    "abc.ido.example.": "abc.ndc.example."  }}
Figure 3:Example Delegation Configuration Object

In order to indicate which specific delegation applies to the requestedcertificate, a newdelegation attribute is added to theorder object on the NDC-IdO side (see Figures4and7). Thevalue of this attribute is the URL pointing to the delegation configurationobject that is to be used for this certificate request. If thedelegationattribute in the order object contains a URL that does not correspond to aconfiguration available to the requesting ACME account, the IdOMUST return an errorresponse with status code 403 (Forbidden), providing a problem document[RFC7807] with typeurn:ietf:params:acme:error:unknownDelegation.

2.3.2.Order Object Transmitted from NDC to IdO and to ACME Server (STAR)

If the delegation is for a STAR certificate, the request object created by theNDC:

  • MUST have adelegation attribute indicating the preconfigured delegationthat applies to this Order;
  • MUST have entries in theidentifiers field for each delegated namepresent in the configuration;
  • MUST NOT contain thenotBefore andnotAfter fields; and
  • MUST contain anauto-renewal object and, inside it, the fieldslisted inSection 3.1.1 of [RFC8739]. In particular, theallow-certificate-get attributeMUST be present and set to true.
POST /acme/new-order HTTP/1.1Host: acme.ido.exampleContent-Type: application/jose+json{  "protected": base64url({    "alg": "ES256",    "kid": "https://acme.ido.example/acme/acct/evOfKhNU60wg",    "nonce": "Alc00Ap6Rt7GMkEl3L1JX5",    "url": "https://acme.ido.example/acme/new-order"  }),  "payload": base64url({    "identifiers": [      {        "type": "dns",        "value": "abc.ido.example"      }    ],    "auto-renewal": {      "end-date": "2021-04-20T00:00:00Z",      "lifetime": 345600,          // 4 days      "allow-certificate-get": true    },    "delegation":      "https://acme.ido.example/acme/delegation/gm0wfLYHBen"  }),  "signature": "g454e3hdBlkT4AEw...nKePnUyZTjGtXZ6H"}
Figure 4:New STAR Order from NDC

The order object that is created on the IdO:

  • MUST start in theready state;
  • MUST contain anauthorizations array with zero elements;
  • MUST contain the indicateddelegation configuration;
  • MUST contain the indicatedauto-renewal settings; and
  • MUST NOT contain thenotBefore andnotAfter fields.
{  "status": "ready",  "expires": "2021-05-01T00:00:00Z",  "identifiers": [   {     "type": "dns",     "value": "abc.ido.example"   }  ],  "auto-renewal": {    "end-date": "2021-04-20T00:00:00Z",    "lifetime": 345600,    "allow-certificate-get": true  },  "delegation":    "https://acme.ido.example/acme/delegation/gm0wfLYHBen",  "authorizations": [],  "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 thedelegated identifiers. The IdO checks the provided CSR against the templatecontained in thedelegation object that applies to this request, as described inSection 4.1. If the CSR fails validation for any of theidentifiers, the IdOMUST return an error response with status code 403(Forbidden) and an appropriate type, e.g.,rejectedIdentifier orbadCSR.The error responseSHOULD contain subproblems (Section 6.7.1 of [RFC8555])for each failed identifier. If the CSR is successfully validated, the orderobject status moves toprocessing and the twin ACME protocol instance isinitiated on the IdO-CA side.

The request object created by the IdO:

  • MUST copy the identifiers sent by the NDC;
  • MUST strip thedelegation attribute; and
  • MUST carry a copy of theauto-renewal object sent by the NDC.

When the identifiers' authorization has been successfully completed and thecertificate has been issued by the CA, the IdO:

  • MUST move its Order resource status tovalid and
  • MUST copy thestar-certificate field from the STAR Order returned by the CAinto its Order resource. When dereferenced, thestar-certificate URLincludes (via theCert-Not-Before andCert-Not-After HTTP header fields) the renewal timersneeded by the NDC to inform its certificate reload logic.
{  "status": "valid",  "expires": "2021-05-01T00:00:00Z",  "identifiers": [   {     "type": "dns",     "value": "abc.ido.example"   }  ],  "auto-renewal": {    "end-date": "2021-04-20T00:00:00Z",    "lifetime": 345600,    "allow-certificate-get": true  },  "delegation":    "https://acme.ido.example/acme/delegation/gm0wfLYHBen",  "authorizations": [],  "finalize": "https://acme.ido.example/acme/order/TO8rfgo/finalize",  "star-certificate": "https://acme.ca.example/acme/order/yTr23sSDg9"}
Figure 6:STAR Order Resource Updated on IdO

This delegation protocol is predicated on the NDC being able to fetchcertificates periodically using an unauthenticated HTTP GET, since, in general,the NDC does not possess an account on the CA; as a consequence, it cannot issue thestandard POST-as-GET ACME request. Therefore, before forwarding the Orderrequest to the CA, the IdOSHOULD ensure that the selected CA supportsunauthenticated GET by inspecting the relevant settings in the CA'sdirectory object, as perSection 3.4 of [RFC8739]. If the CA does notsupport unauthenticated GET of STAR certificates, the IdOMUST NOT forwardthe Order request. Instead, itMUST move the Order status toinvalid and settheallow-certificate-get in theauto-renewal object tofalse. The sameoccurs in case the Order request is forwarded and the CA does not reflect theallow-certificate-get setting in its Order resource. The combination ofinvalid status and deniedallow-certificate-get in the Order resource atthe IdO provides an unambiguous (asynchronous) signal to the NDC about thefailure reason.

2.3.2.1.CNAME Installation

If one of the objects in theidentifiers list is of typedns, the IdO can add theCNAME records specified in thedelegation object to its zone, for example:

   abc.ido.example. CNAME abc.ndc.example.

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 request object created bythe NDC:

  • MUST have adelegation attribute indicating the preconfigured delegationthat applies to this Order;
  • MUST have entries in theidentifiers field for each delegated namepresent in the configuration; and
  • MUST have theallow-certificate-get attribute set to true.
POST /acme/new-order HTTP/1.1Host: acme.ido.exampleContent-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.ido.example"      }    ],    "delegation":      "https://acme.ido.example/acme/delegation/gm0wfLYHBen",    "allow-certificate-get": true  }),  "signature": "j9JBUvMigi4zodud...acYkEKaa8gqWyZ6H"}
Figure 7:New Non-STAR Order from NDC

The order object that is created on the IdO:

  • MUST start in theready state;
  • MUST contain anauthorizations array with zero elements;
  • MUST contain the indicateddelegation configuration; and
  • MUST contain the indicatedallow-certificate-get setting.
{  "status": "ready",  "expires": "2021-05-01T00:00:00Z",  "identifiers": [   {     "type": "dns",     "value": "abc.ido.example"   }  ],  "delegation":    "https://acme.ido.example/acme/delegation/gm0wfLYHBen",  "allow-certificate-get": true,  "authorizations": [],  "finalize": "https://acme.ido.example/acme/order/3ZDlhYy/finalize"}
Figure 8:Non-STAR Order Resource Created on IdO

The Order finalization by the NDC and the subsequent validation of the CSR bythe IdO proceed in the same way as for the STAR case. If the CSR issuccessfully validated, the order object status moves toprocessing and thetwin ACME protocol instance is initiated on the IdO-CA side.

The request object created by the IdO:

  • MUST copy the identifiers sent by the NDC;
  • MUST strip thedelegation attribute; and
  • MUST copy theallow-certificate-get attribute.

When the identifiers' authorization has been successfully completed and thecertificate has been issued by the CA, the IdO:

  • MUST move its Order resource status tovalid and
  • MUST copy thecertificate field from the Order returned by the CA into itsOrder resource, as well asnotBefore andnotAfter if these fields exist.
{  "status": "valid",  "expires": "2021-05-01T00:00:00Z",  "identifiers": [   {     "type": "dns",     "value": "abc.ido.example"   }  ],  "delegation":    "https://acme.ido.example/acme/delegation/gm0wfLYHBen",  "allow-certificate-get": true,  "authorizations": [],  "finalize": "https://acme.ido.example/acme/order/3ZDlhYy/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 inSection 2.3.2.1 apply.

Before forwarding the Order request to the CA, the IdOSHOULD ensure that theselected CA supports unauthenticated GET by inspecting the relevant settingsin the CA's directory object, as perSection 2.3.5. If the CAdoes not support unauthenticated GET of certificate resources, the IdOMUST NOT forward the Order request. Instead, itMUST move the Order status toinvalid and set theallow-certificate-get attribute tofalse. The sameoccurs in case the Order request is forwarded and the CA does not reflect theallow-certificate-get setting in its Order resource. The combination ofinvalid status and deniedallow-certificate-get in the Order resource atthe IdO provides an unambiguous (asynchronous) signal to the NDC about thefailure reason.

2.3.4.Capability Discovery

In order to help a client discover support for this profile, the directoryobject of an ACME server (typically, one deployed by the IdO) contains thefollowing attribute in themeta field:

delegation-enabled (optional, boolean):
Boolean flag indicating support forthe profile specified in this memo. An ACME server that supports thisdelegation profileMUST include this key andMUST set it to true.

The IdOMUST declare its support for delegation usingdelegation-enabledregardless of whether it supports delegation of STAR certificates, non-STARcertificates, or both.

In order to help a client discover support for certificate fetching usingunauthenticated HTTP GET, the directory object of an ACME server (typically,one deployed by the CA) contains the following attribute in themeta field:

allow-certificate-get (optional, boolean):
SeeSection 2.3.5.

2.3.5.Negotiating an Unauthenticated GET

In order to enable the name delegation of non-STAR certificates, this documentdefines a mechanism that allows a server to advertise support for accessingcertificate resources via unauthenticated GET (in addition toPOST-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 sectionhave the same names and semantics as those introduced inSection 3.4 of [RFC8739] for the STAR use case (except, of course, they apply to thecertificate resource rather than the star-certificate resource). However, theydiffer in terms of their position in the directory meta and order objects;rather than being wrapped in anauto-renewal subobject, they are located at thetop level.

A server states its availability to grant unauthenticated access to a client'sOrder certificate by setting theallow-certificate-get attribute totrue in themeta field inside the directory object:

allow-certificate-get (optional, boolean):
If this field is present and settotrue, the server allows GET (and HEAD) requests to certificate URLs.

A client states its desire to access the issued certificate via unauthenticatedGET by adding anallow-certificate-get attribute to the payload of itsnewOrder request and setting it totrue.

allow-certificate-get (optional, boolean):
If this field is present and settotrue, the client requests the server to allow unauthenticated GET (andHEAD) to the certificate associated with this Order.

If the server accepts the request, itMUST reflect the attribute setting in theresulting order object.

Note that even when the use of unauthenticated GET has been agreed upon, theserverMUST also allow POST-as-GET requests to the certificate resource.

2.3.6.Terminating the Delegation

Identity delegation is terminated differently depending on whether or not this is a STAR certificate.

2.3.6.1.By Cancellation (STAR)

The IdO can terminate the delegation of a STAR certificate by requesting itscancellation (seeSection 3.1.2 of [RFC8739]).

Cancellation of the ACME STAR certificate is aprerogative of the IdO. The NDC does not own the relevant account key on theCA; therefore, it can't issue a cancellation request for the STAR certificate.Potentially, since it holds the STAR certificate's private key, it could request therevocation of a single STAR certificate. However, STAR explicitly disables therevokeCert interface.

Shortly after the automatic renewal process is stopped by the IdO, the lastissued STAR certificate expires and the delegation terminates.

2.3.6.2.By Revocation (Non-STAR)

The IdO can terminate the delegation of a non-STAR certificate by requesting itto be revoked using therevokeCert URL exposed by the CA.

According toSection 7.6 of [RFC8555], the revocation endpoint can be usedwith either the account key pair or the certificate key pair. In other words, anNDC that learns therevokeCert URL of the CA (which is publicly available viathe CA's directory object) would be able to revoke the certificate using theassociated private key. However, given the trust relationship between the NDC andIdO expected by the delegation trust model (Section 7.1), as well asthe lack of incentives for the NDC to prematurely terminate the delegation,this does not represent a significant security risk.

2.4.Proxy Behavior

There are cases where the ACME Delegation flow should be proxied, such as theuse case described inSection 5.1.2. This section describes the behavior ofsuch proxies.

An entity implementing the IdO server role -- an "ACME Delegation server" --may behave, on a per-identity case, either as a proxy into another ACME Delegationserver or as an IdO and obtain a certificate directly.The determining factor is whether it can successfully be authorized bythe next-hop ACME server for the identity associated with the certificate request.

The identities supported by each server and the disposition for each of themare preconfigured.

Following is the proxy's behavior for each of the messages exchanged in theACME Delegation process:

New-order request:
  • The completeidentifiers attributeMUST be copied as is.
  • Similarly, theauto-renewal objectMUST be copied as is.
New-order response:
  • Thestatus,expires,authorizations,identifiers, andauto-renewalattributes/objectsMUST be copied as is.
  • Thefinalize URL is rewritten so that thefinalize request will bemade to the proxy.
  • Similarly, theLocation headerMUST be rewritten to point to an order object on the proxy.
  • AnyLink relationsMUST be rewritten to point to the proxy.
Get Order response:
  • Thestatus,expires,authorizations,identifiers, andauto-renewalattributes/objectsMUST be copied as is.
  • Similarly, thestar-certificate URL (or thecertificate URL in case ofnon-STAR requests)MUST be copied as is.
  • Thefinalize URL is rewritten so that thefinalize request will bemade to the proxy.
  • TheLocation headerMUST be rewritten to point to an order object on the proxy.
  • AnyLink relationsMUST be rewritten to point to the proxy.
finalize request:
  • The CSRMUST be copied as is.
finalize response:
  • TheLocation header,Link relations, and thefinalize URLs are rewritten as for Get Order.

We note that all the above messages are authenticated; therefore, each proxymust be able to authenticate any subordinate server.

3.CA Behavior

Although most of this document, and in particularSection 2, is focused on the protocol between the NDC and IdO, the protocol does affect the ACME server running in the CA. A CA that wishes to support certificate delegationMUST also support unauthenticated certificate fetching, which it declares usingallow-certificate-get (Section 2.3.5, Paragraph 3).

4.CSR Template

The CSR template is used to express and constrain the shape of the CSR that theNDC uses to request the certificate. The CSR is used for every certificatecreated under the same delegation. Its validation by the IdO is a criticalelement in the security of the whole delegation mechanism.

Instead of defining every possible CSR attribute, this document takes aminimalist approach by declaring only the minimum attribute set and deferringthe registration of further, more-specific attributes to future documents.

4.1.Template Syntax

The template is a JSON document. Each field (with the exception ofkeyTypes, see below) denotes one of the following:

  • A mandatory field where the template specifies the literal value of thatfield. This is denoted by a literal string, such asabc.ido.example.
  • A mandatory field where the content of the field is defined by the client.This is denoted by**.
  • An optional field where the client decides whether the field is included inthe CSR and, if so, what its value is. This is denoted by*.

The NDCMUST NOT include any fields in the CSR, including any extensions, unless they are specified in thetemplate.

The structure of the template object is defined by the Concise Data Definition Language (CDDL)[RFC8610] document inAppendix A.An alternative, nonnormative JSON Schema syntax is given inAppendix B.While the CSR template must follow the syntax defined here, neither the IdO northe NDC are expected to validate it at runtime.

Thesubject field and its subfields are mapped into thesubject field of the CSR, as perSection 4.1.2.6 of [RFC5280]. Other extension fields of the CSR template are mapped into the CSR according to the table inSection 6.5.

ThesubjectAltName field is currently defined for the following identifiers:DNS names, email addresses, and URIs. New identifier types may be added in thefuture by documents that extend this specification. Each new identifier typeSHALL have an associated identifier validation challenge that the CA canuse to obtain proof of the requester's control over it.

ThekeyTypes property is not copied into the CSR. Instead, this property constrains theSubjectPublicKeyInfo field of the CSR, whichMUST have the type/size defined by one of the array members of thekeyTypes property.

When the IdO receives the CSR, itMUST verify that the CSR is consistentwith the template contained in thedelegation object referenced in the Order. The IdOMAY enforce additionalconstraints, e.g., by restricting field lengths. In this regard, note that asubjectAltName of typeDNS can be specified using the wildcard notation,meaning that the NDC can be required (**) or offered the possibility (*) todefine the delegated domain name by itself. If this is the case, the IdOMUSTapply application-specific checks on top of the control rules already providedby the CSR template to ensure the requested domain name is legitimate accordingto its local policy.

4.2.Example

The CSR template inFigure 10 represents one possible CSR templategoverning the delegation exchanges provided in the rest of this document.

{  "keyTypes": [    {      "PublicKeyType": "rsaEncryption",      "PublicKeyLength": 2048,      "SignatureType": "sha256WithRSAEncryption"    },    {      "PublicKeyType": "id-ecPublicKey",      "namedCurve": "secp256r1",      "SignatureType": "ecdsa-with-SHA256"    }  ],  "subject": {    "country": "CA",    "stateOrProvince": "**",    "locality": "**"  },  "extensions": {    "subjectAltName": {      "DNS": [        "abc.ido.example"      ]    },    "keyUsage": [      "digitalSignature"    ],    "extendedKeyUsage": [      "serverAuth",      "clientAuth"    ]  }}
Figure 10:Example CSR Template

5.Further Use Cases

This nonnormative section describes additional use cases implementing the STAR certificatedelegation in nontrivial ways.

5.1.CDN Interconnection (CDNI)

[HTTPS-DELEGATION] discusses several solutionsaddressing different delegation requirements for the CDN Interconnection (CDNI)environment. This section discusses two of the stated requirements in thecontext of the STAR delegation workflow.

This section uses specific CDNI terminology, e.g., Upstream CDN (uCDN) and Downstream (dCDN), as defined in[RFC7336].

5.1.1.Multiple Parallel Delegates

In some cases, the content owner (IdO) would like to delegate authority over awebsite to multiple NDCs (CDNs). This could happen if the IdO has agreementsin place with different regional CDNs for different geographical regions or ifa "backup" CDN is used to handle overflow traffic by temporarily altering someof the CNAME mappings in place. The STAR delegation flow enables this use casenaturally, since each CDN can authenticate separately to the IdO (via its ownseparate account) specifying its CSR, and the IdO is free to allow or deny eachcertificate request according to its own policy.

5.1.2.Chained Delegation

In other cases, a content owner (IdO) delegates some domains to a large CDN(uCDN), which in turn delegates to a smaller regional CDN (dCDN). The IdO has acontractual relationship with uCDN, and uCDN has a similar relationship withdCDN. However, IdO may not even know about dCDN.

If needed, the STAR protocol can be chained to support this use case: uCDNcould forward requests from dCDN to IdO and forward responses back to dCDN.Whether such proxying is allowed is governed by policy and contracts betweenthe parties.

A mechanism is necessary at the interface between uCDN and dCDN, by which theuCDN can advertise:

  • the names that the dCDN is allowed to use and
  • the policy for creating the key material (allowed algorithms, minimum keylengths, key usage, etc.) that the dCDN needs to satisfy.

Note that such mechanism is provided by the CSR template.

5.1.2.1.Two-Level Delegation in CDNI

A User Agent (UA), e.g., a browser or set-top box, wants to fetch the video resource atthe following URI:https://video.cp.example/movie. Redirection between the content provider (CP) and upstream and downstream CDNs is arranged as aCNAME-based aliasing chain, as illustrated inFigure 11.

.Mea.eipe(NeUN.pCSipAn(.?dNemumSDln.cllAoaiMecxNa.vACvo0avppp(DS:eDcTodndie.DaxmeNdmvcxS..cv2ePdDNANLdeccl)diTee.SSpe2peNe..a.adEvSo9Cd?ubCdemildDomu1xne)?1Ioldd)CLNE.x.x
Figure 11:DNS Redirection

Unlike HTTP-based redirection, where the original URL is supplanted by the onefound in theLocation header of the 302 response, DNS redirection is completelytransparent to the User Agent. As a result, the TLS connection to the dCDNedge is done with a Server Name Indication (SNI) equal to thehost in theoriginal URI -- in the example,video.cp.example. So, in order tosuccessfully complete the handshake, the landing dCDN node has to be configuredwith a certificate whosesubjectAltName field matchesvideo.cp.example, i.e., acontent provider's name.

Figure 12 illustrates the cascaded delegation flow that allows dCDN toobtain a STAR certificate that bears a name belonging to the content providerwith a private key that is only known to the dCDN.

vidAC1CeeSRDlSuwTM8NeEPlTArE0CIDCecRHCSTIfeCMlTT21dRdARNTPlTAAR73CADdTPNlSs54TSCDcNdHeA6A9i
Figure 12:Two-Level Delegation in CDNI

uCDN is configured to delegate to dCDN, and CP is configured to delegate to uCDN, both as defined inSection 2.3.1.

  1. dCDN requests CDNI path metadata to uCDN.
  2. uCDN replies with, among other CDNI metadata, the STAR delegationconfiguration, which includes the delegated content provider's name.
  3. dCDN creates a key pair and the CSR with the delegated name. It then placesan order for the delegated name to uCDN.
  4. uCDN forwards the received order to the content provider (CP).
  5. CP creates an order for a STAR certificate and sends it to the CA. Theorder also requests unauthenticated access to the certificate resource.
  6. After all authorizations complete successfully, the STAR certificate isissued.
  7. CP notifies uCDN that the STAR certificate is available at the order'sstar-certificate URL.
  8. uCDN forwards the information to dCDN. At this point, the ACME signaling iscomplete.
  9. dCDN requests the STAR certificate using unauthenticated GET from the CA.
  10. The CA returns the certificate. Now dCDN is fully configured to handleHTTPS traffic in lieu of the content provider.

Note that 9 and 10 repeat until the delegation expires or is terminated.

5.2.Secure Telephone Identity Revisited (STIR)

As a second use case, we consider the delegation of credentials in the STIRecosystem[RFC9060].

This section uses STIR terminology. The term Personal Assertion Token (PASSporT) is defined in[RFC8225], and "TNAuthList" is defined in[RFC8226].

In the STIR delegated mode, a service provider SP2 -- the NDC -- needs to signPASSporTs[RFC8225] for telephone numbers (e.g., TN=+123) belonging toanother service provider, SP1 -- the IdO. In order to do that, SP2 needs a STIRcertificate and a private key that includes TN=+123 in the TNAuthList[RFC8226] certificate extension.

In detail (Figure 13):

  1. SP1 and SP2 agree on the configuration of the delegation -- in particular,the CSR template that applies.
  2. SP2 generates a private/public key pair and sends a CSR to SP1, requestingcreation of a certificate with an SP1 name, an SP2 public key, and a TNAuthListextension with the list of TNs that SP1 delegates to SP2. (Note that theCSR sent by SP2 to SP1 needs to be validated against the CSR templateagreed upon in step 1.).
  3. SP1 sends an order for the CSR to the CA. The order also requestsunauthenticated access to the certificate resource.
  4. Subsequently, after the required TNAuthList authorizations are successfullycompleted, the CA moves the order to a "valid" state; at the sametime, the star-certificate endpoint is populated.
  5. The contents of the order are forwarded from SP1 to SP2 by means of the paired"delegation" order.
  6. SP2 dereferences thestar-certificate URL in the order to fetch the rollingSTAR certificate bearing the delegated identifiers.
  7. The STAR certificate is returned to SP2.
1HSlPeTTPPilSRlc3TceiRS7eAA26T1slEAARSCTTSdvCAHdre5MdeR4PeTAlST2
Figure 13:Delegation in STIR

As shown, the STAR delegation profile described in this document appliesstraightforwardly; the only extra requirement being the ability to instruct theNDC about the allowed TNAuthList values. This can be achieved by a simpleextension to the CSR template.

6.IANA Considerations

6.1.New Fields in the "meta" Object within a Directory Object

This document adds the following entries to the "ACME Directory Metadata Fields" registry:

Table 1
Field NameField TypeReference
delegation-enabledbooleanRFC 9115
allow-certificate-getbooleanRFC 9115

6.2.New Fields in the Order Object

This document adds the following entries to the "ACME Order Object Fields" registry:

Table 2
Field NameField TypeConfigurableReference
allow-certificate-getbooleantrueRFC 9115
delegationstringtrueRFC 9115

6.3.New Fields in the Account Object

This document adds the following entries to the "ACME Account Object Fields" registry:

Table 3
Field NameField TypeRequestsReference
delegationsstringnoneRFC 9115

Note that thedelegations field is only reported by ACME servers that havedelegation-enabled set to true in their meta Object.

6.4.New Error Types

This document adds the following entries to the "ACME Error Types" registry:

Table 4
TypeDescriptionReference
unknownDelegationAn unknown configuration is listed in thedelegation attribute of the order requestRFC 9115

6.5.CSR Template Extensions

IANA has established the "STAR Delegation CSR TemplateExtensions" registry, with "Specification Required" as its registration procedure.

Each extension registered must specify:

  • an extension name,
  • an extension syntax, as a reference to a CDDL document that defines this extension, and
  • the extension's mapping into an X.509 certificate extension.

The initial contents of this registry are the extensions defined by the CDDLinAppendix A.

Table 5
Extension NameExtension SyntaxMapping to X.509 Certificate Extension
keyUsageSeeAppendix A[RFC5280],Section 4.2.1.3
extendedKeyUsageSeeAppendix A[RFC5280],Section 4.2.1.12
subjectAltNameSeeAppendix A[RFC5280],Section 4.2.1.6 (note that only specific name formats are allowed: URI, DNS name, email address)

When evaluating a request for an assignment in this registry, the designated expert should follow this guidance:

  • 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 relationshipbetween NDC and IdO. Note that once this trust link is established, itpotentially becomes recursive. Therefore, there has to be a trust relationshipbetween each of the nodes in the delegation chain; for example, in case ofcascading CDNs, this is contractually defined. Note that when using standard[RFC6125] identity verification, there are no mechanisms available to the IdOto restrict the use of the delegated name once the name has been handed over tothe first NDC. It is, therefore, expected that contractual measures are in placeto get some assurance that redelegation is not being performed.

7.2.Delegation Security Goal

Delegation introduces a new security goal: only an NDC that has been authorizedby the IdO, either directly or transitively, can obtain a certificate with anIdO identity.

From a security point of view, the delegation process has five separate parts:

  1. enabling a specific third party (the intended NDC) to submit requests fordelegated certificates
  2. making sure that any request for a delegated certificate matches theintended "shape" in terms of delegated identities as well as any othercertificate metadata, e.g., key length, x.509 extensions, etc.
  3. serving the certificate back to the NDC
  4. handling revocation of the delegation
  5. handling revocation of the certificate itself

The first part is covered by the NDC's ACME account that is administered by theIdO, whose security relies on the correct handling of the associated key pair.When a compromise of the private key is detected, the delegateMUST use theaccount deactivation procedures defined inSection 7.3.6 of [RFC8555].

The second part is covered by the act of checking an NDC's certificate requestagainst the intended CSR template. The steps of shaping the CSR templatecorrectly, selecting the right CSR template to check against the presented CSR,and making sure that the presented CSR matches the selected CSR template areall security relevant.

The third part builds on the trust relationship between NDC and IdO that isresponsible for correctly forwarding the certificate URL from the Orderreturned by the CA.

The fourth part is associated with the ability of the IdO to unilaterallyremove thedelegation object associated with the revoked identity, therefore,disabling any further NDC requests for such identity. Note that, in moreextreme circumstances, the IdO might decide to disable the NDC account,thus entirely blocking any further interaction.

The fifth is covered by two different mechanisms, depending on the nature ofthe certificate. For STAR, the IdO shall use the cancellation interfacedefined inSection 2.3 of [RFC8739]. For non-STAR, the certificate revocationinterface defined inSection 7.6 of [RFC8555]) is used.

The ACME account associated with the delegation plays a crucial role in theoverall security of the presented protocol. This, in turn, means that (indelegation scenarios) the security requirements and verification associated withan ACME account may be more stringent than in base ACME deployments, since theout-of-band configuration of delegations that an account is authorized to use(combined with account authentication) takes the place of the normal ACMEauthorization challenge procedures. Therefore, the IdOMUST ensure thateach account is associated with the exact policies (via their matchingdelegation objects)that define which domain names can be delegated to the account and how.The IdO is expected to use out-of-band means to preregister each NDC tothe corresponding account.

7.3.New ACME Channels

Using the model established inSection 10.1 of [RFC8555], we can decomposethe interactions of the basic delegation workflow, as shown inFigure 14.

dieahldiOrtOeActcvCIVifeADennfhcfaoIehvnio]-dhteEtedee1UunoeeMhM.CtancEA[efSaMConsatnRnCtachnseAtun1Nl)noerabniatleClciActCanTnsdtaane]ilnl(raii[tCCcrrCE
Figure 14:Delegation Channels Topology

The considerations regarding the security of the ACME Channel and ValidationChannel discussed in[RFC8555] apply verbatim to the IdO-CA leg.The same can be said for the ACME Channel on the NDC-IdO leg. A slightlydifferent set of considerations apply to the ACME Channel between the NDC and CA,which consists of a subset of the ACME interface comprising two APIendpoints: the unauthenticated certificate retrieval and, potentially, non-STARrevocation via certificate private key. No specific security considerationsapply to the former, but the privacy considerations inSection 6.3 of [RFC8739] do. With regard to the latter, it should be noted that there iscurrently no means for an IdO to disable authorizing revocation based oncertificate private keys. So, in theory, an NDC could use the revocation APIdirectly with the CA, therefore, bypassing the IdO. The NDCSHOULD NOTdirectly use the revocation interface exposed by the CA unless failingto do so would compromise the overall security, for example, if the certificateprivate key is compromised and the IdO is not currently reachable.

All other security considerations from[RFC8555] and[RFC8739] applyas is to the delegation topology.

7.4.Restricting CDNs to the Delegation Mechanism

When a website is delegated to a CDN, the CDN can in principle modify the website at will, e.g., create and remove pages. This means that a malicious or breachedCDN can pass the ACME (as well as common non-ACME) HTTPS-based validationchallenges and generate a certificate for the site. This is true regardless ofwhether or not the CNAME mechanisms defined in the current document is used.

In some cases, this is the desired behavior; the domain holder trusts the CDN tohave full control of the cryptographic credentials for the site. However, thisdocument assumes a scenario where the domain holder only wants to delegaterestricted control and wishes to retain the capability to cancel the CDN'scredentials at a short notice.

The following is a possible mitigation when the IdO wishes to ensure that arogue CDN cannot issue unauthorized certificates:

  • The domain holder makes sure that the CDN cannot modify the DNS records forthe domain. The domain holder should ensure it is the only entity authorizedto modify the DNS zone. Typically, it establishes a CNAME resource recordfrom a subdomain into a CDN-managed domain.
  • The domain holder uses a Certification Authority Authorization (CAA) record[RFC8659] to restrict certificateissuance for the domain to specific CAs that comply with ACME and are knownto implement[RFC8657].
  • The domain holder uses the ACME-specific CAA mechanism[RFC8657] torestrict issuance to a specific CA account that is controlled by it andMUST require "dns-01" as the sole validation method.

We note that the above solution may need to be tweaked depending on the exactcapabilities and authorization flows supported by the selected CA.In addition, this mitigation may be bypassed if a malicious or misconfigured CAdoes not comply with CAA restrictions.

8.References

8.1.Normative References

[RFC2119]
Bradner, S.,"Key words for use in RFCs to Indicate Requirement Levels",BCP 14,RFC 2119,DOI 10.17487/RFC2119,,<https://www.rfc-editor.org/info/rfc2119>.
[RFC2986]
Nystrom, M. andB. Kaliski,"PKCS #10: Certification Request Syntax Specification Version 1.7",RFC 2986,DOI 10.17487/RFC2986,,<https://www.rfc-editor.org/info/rfc2986>.
[RFC5280]
Cooper, D.,Santesson, S.,Farrell, S.,Boeyen, S.,Housley, R., andW. Polk,"Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile",RFC 5280,DOI 10.17487/RFC5280,,<https://www.rfc-editor.org/info/rfc5280>.
[RFC7807]
Nottingham, M. andE. Wilde,"Problem Details for HTTP APIs",RFC 7807,DOI 10.17487/RFC7807,,<https://www.rfc-editor.org/info/rfc7807>.
[RFC8174]
Leiba, B.,"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words",BCP 14,RFC 8174,DOI 10.17487/RFC8174,,<https://www.rfc-editor.org/info/rfc8174>.
[RFC8555]
Barnes, R.,Hoffman-Andrews, J.,McCarney, D., andJ. Kasten,"Automatic Certificate Management Environment (ACME)",RFC 8555,DOI 10.17487/RFC8555,,<https://www.rfc-editor.org/info/rfc8555>.
[RFC8610]
Birkholz, H.,Vigano, C., andC. Bormann,"Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures",RFC 8610,DOI 10.17487/RFC8610,,<https://www.rfc-editor.org/info/rfc8610>.
[RFC8739]
Sheffer, Y.,Lopez, D.,Gonzalez de Dios, O.,Pastor Perales, A., andT. Fossati,"Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME)",RFC 8739,DOI 10.17487/RFC8739,,<https://www.rfc-editor.org/info/rfc8739>.

8.2.Informative References

[HTTPS-DELEGATION]
Fieau, F.,Stephan, E., andS. Mishra,"CDNI extensions for HTTPS delegation",Work in Progress,Internet-Draft, draft-ietf-cdni-interfaces-https-delegation-06,,<https://datatracker.ietf.org/doc/html/draft-ietf-cdni-interfaces-https-delegation-06>.
[json-schema-07]
Wright, A.,Andrews, H., andB. Hutton,"JSON Schema Validation: A Vocabulary for Structural Validation of JSON",Work in Progress,Internet-Draft, draft-handrews-json-schema-validation-02,,<https://datatracker.ietf.org/doc/html/draft-handrews-json-schema-validation-02>.
[MGLT-LURK-TLS13]
Migault, D.,"LURK Extension version 1 for (D)TLS 1.3 Authentication",Work in Progress,Internet-Draft, draft-mglt-lurk-tls13-05,,<https://datatracker.ietf.org/doc/html/draft-mglt-lurk-tls13-05>.
[RFC6125]
Saint-Andre, P. andJ. Hodges,"Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)",RFC 6125,DOI 10.17487/RFC6125,,<https://www.rfc-editor.org/info/rfc6125>.
[RFC7336]
Peterson, L.,Davie, B., andR. van Brandenburg, Ed.,"Framework for Content Distribution Network Interconnection (CDNI)",RFC 7336,DOI 10.17487/RFC7336,,<https://www.rfc-editor.org/info/rfc7336>.
[RFC8225]
Wendt, C. andJ. Peterson,"PASSporT: Personal Assertion Token",RFC 8225,DOI 10.17487/RFC8225,,<https://www.rfc-editor.org/info/rfc8225>.
[RFC8226]
Peterson, J. andS. Turner,"Secure Telephone Identity Credentials: Certificates",RFC 8226,DOI 10.17487/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,,<https://www.rfc-editor.org/info/rfc8657>.
[RFC8659]
Hallam-Baker, P.,Stradling, R., andJ. Hoffman-Andrews,"DNS Certification Authority Authorization (CAA) Resource Record",RFC 8659,DOI 10.17487/RFC8659,,<https://www.rfc-editor.org/info/rfc8659>.
[RFC9060]
Peterson, J.,"Secure Telephone Identity Revisited (STIR) Certificate Delegation",RFC 9060,DOI 10.17487/RFC9060,,<https://www.rfc-editor.org/info/rfc9060>.
[TLS-SUBCERTS]
Barnes, R.,Iyengar, S.,Sullivan, N., andE. Rescorla,"Delegated Credentials for TLS",Work in Progress,Internet-Draft, draft-ietf-tls-subcerts-10,,<https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-10>.
[TOKEN-TNAUTHLIST]
Wendt, C.,Hancock, D.,Barnes, M., andJ. Peterson,"TNAuthList profile of ACME Authority Token",Work in Progress,Internet-Draft, draft-ietf-acme-authority-token-tnauthlist-08,,<https://datatracker.ietf.org/doc/html/draft-ietf-acme-authority-token-tnauthlist-08>.

Appendix A.CSR Template: CDDL

Following is the normative definition of the CSR template using CDDL[RFC8610]. The CSR templateMUST be a valid JSON document that is compliant with the syntax defined here.

There are additional constraints not expressed in CDDL thatMUST be validatedby the recipient, including:

csr-template-schema = {  keyTypes: [ + $keyType ]  ? subject: non-empty<distinguishedName>  extensions: extensions}non-empty<M> = (M) .and ({ + any => any })mandatory-wildcard = "**"optional-wildcard = "*"wildcard = mandatory-wildcard / optional-wildcard; regtext matches all text strings but "*" and "**"regtext = text .regexp "([^\*].*)|([\*][^\*].*)|([\*][\*].+)"regtext-or-wildcard = regtext / wildcarddistinguishedName = {  ? 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$keyType /= ecdsaKeyTypersaKeyType = {  PublicKeyType: "rsaEncryption" ; OID: 1.2.840.113549.1.1.1  PublicKeyLength: rsaKeySize  SignatureType: $rsaSignatureType}rsaKeySize = uint; RSASSA-PKCS1-v1_5 with SHA-256$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 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"ecdsaKeyType = {  PublicKeyType: "id-ecPublicKey" ; OID: 1.2.840.10045.2.1  namedCurve: $ecdsaCurve  SignatureType: $ecdsaSignatureType}$ecdsaCurve /= "secp256r1" ; OID: 1.2.840.10045.3.1.7$ecdsaCurve /= "secp384r1" ; OID: 1.3.132.0.34$ecdsaCurve /= "secp521r1" ; OID: 1.3.132.0.3$ecdsaSignatureType /= "ecdsa-with-SHA256" ; paired with secp256r1$ecdsaSignatureType /= "ecdsa-with-SHA384" ; paired with secp384r1$ecdsaSignatureType /= "ecdsa-with-SHA512" ; paired with secp521r1subjectaltname = {  ? DNS: [ + regtext-or-wildcard ]  ? Email: [ + regtext ]  ? URI: [ + regtext ]  * $$subjectaltname-extension}extensions = {  ? keyUsage: [ + keyUsageType ]  ? extendedKeyUsage: [ + extendedKeyUsageType ]  subjectAltName: non-empty<subjectaltname>}keyUsageType /= "digitalSignature"keyUsageType /= "nonRepudiation"keyUsageType /= "keyEncipherment"keyUsageType /= "dataEncipherment"keyUsageType /= "keyAgreement"keyUsageType /= "keyCertSign"keyUsageType /= "cRLSign"keyUsageType /= "encipherOnly"keyUsageType /= "decipherOnly"extendedKeyUsageType /= "serverAuth"extendedKeyUsageType /= "clientAuth"extendedKeyUsageType /= "codeSigning"extendedKeyUsageType /= "emailProtection"extendedKeyUsageType /= "timeStamping"extendedKeyUsageType /= "OCSPSigning"extendedKeyUsageType /= oidoid = text .regexp "([0-2])((\.0)|(\.[1-9][0-9]*))*"

Appendix B.CSR Template: JSON Schema

This appendix includes an alternative, nonnormative JSON Schema 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 later versions of this (now-expired) draft describe later versions of 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 draft version, which is currently best supported by tool implementations.

The same considerations about additional constraints checking discussed inAppendix A apply here as well.

{  "title": "JSON Schema for the STAR Delegation CSR template",  "$schema": "http://json-schema.org/draft-07/schema#",  "$id": "http://ietf.org/acme/drafts/star-delegation/csr-template",  "$defs": {    "distinguished-name": {      "$id": "#distinguished-name",      "type": "object",      "minProperties": 1,      "properties": {        "country": {          "type": "string"        },        "stateOrProvince": {          "type": "string"        },        "locality": {          "type": "string"        },        "organization": {          "type": "string"        },        "organizationalUnit": {          "type": "string"        },        "emailAddress": {          "type": "string"        },        "commonName": {          "type": "string"        }      },      "additionalProperties": false    },    "rsaKeyType": {      "$id": "#rsaKeyType",      "type": "object",      "properties": {        "PublicKeyType": {          "type": "string",          "const": "rsaEncryption"        },        "PublicKeyLength": {          "type": "integer"        },        "SignatureType": {          "type": "string",          "enum": [            "sha256WithRSAEncryption",            "sha384WithRSAEncryption",            "sha512WithRSAEncryption",            "sha256WithRSAandMGF1",            "sha384WithRSAandMGF1",            "sha512WithRSAandMGF1"          ]        }      },      "required": [        "PublicKeyType",        "PublicKeyLength",        "SignatureType"      ],      "additionalProperties": false    },    "ecdsaKeyType": {      "$id": "#ecdsaKeyType",      "type": "object",      "properties": {        "PublicKeyType": {          "type": "string",          "const": "id-ecPublicKey"        },        "namedCurve": {          "type": "string",          "enum": [            "secp256r1",            "secp384r1",            "secp521r1"          ]        },        "SignatureType": {          "type": "string",          "enum": [            "ecdsa-with-SHA256",            "ecdsa-with-SHA384",            "ecdsa-with-SHA512"          ]        }      },      "required": [        "PublicKeyType",        "namedCurve",        "SignatureType"      ],      "additionalProperties": false    }  },  "type": "object",  "properties": {    "keyTypes": {      "type": "array",      "minItems": 1,      "items": {        "anyOf": [          {            "$ref": "#rsaKeyType"          },          {            "$ref": "#ecdsaKeyType"          }        ]      }    },    "subject": {      "$ref": "#distinguished-name"    },    "extensions": {      "type": "object",      "properties": {        "keyUsage": {          "type": "array",          "minItems": 1,          "items": {            "type": "string",            "enum": [              "digitalSignature",              "nonRepudiation",              "keyEncipherment",              "dataEncipherment",              "keyAgreement",              "keyCertSign",              "cRLSign",              "encipherOnly",              "decipherOnly"            ]          }        },        "extendedKeyUsage": {          "type": "array",          "minItems": 1,          "items": {            "anyOf": [              {                "type": "string",                "enum": [                  "serverAuth",                  "clientAuth",                  "codeSigning",                  "emailProtection",                  "timeStamping",                  "OCSPSigning"                ]              },              {                "type": "string",                "pattern": "^([0-2])((\\.0)|(\\.[1-9][0-9]*))*$",                "description": "Used for OID values"              }            ]          }        },        "subjectAltName": {          "type": "object",          "minProperties": 1,          "properties": {            "DNS": {              "type": "array",              "minItems": 1,              "items": {                "anyOf": [                  {                    "type": "string",                    "enum": [                      "*",                      "**"                    ]                  },                  {                    "type": "string",                    "format": "hostname"                  }                ]              }            },            "Email": {              "type": "array",              "minItems": 1,              "items": {                "type": "string",                "format": "email"              }            },            "URI": {              "type": "array",              "minItems": 1,              "items": {                "type": "string",                "format": "uri"              }            }          },          "additionalProperties": false        }      },      "required": [        "subjectAltName"      ],      "additionalProperties": false    }  },  "required": [    "extensions",    "keyTypes"  ],  "additionalProperties": false}

Acknowledgements

We would like to thank the following people who contributed significantly to this document with their review comments and design proposals:Richard Barnes,Carsten Bormann,Roman Danyliw,Lars Eggert,Frédéric Fieau,Russ Housley,Ben Kaduk,Eric Kline,Sanjay Mishra,Francesca Palombini,Jon Peterson,Ryan Sleevi,Emile Stephan, andÉric Vyncke.

This work is partially supported by the European Commission under Horizon 2020grant agreement no. 688421 Measurement and Architecture for a MiddleboxedInternet (MAMI). This support does not imply endorsement.

Authors' Addresses

Yaron Sheffer
Intuit
Email:yaronf.ietf@gmail.com
Diego López
Telefonica I+D
Email:diego.r.lopez@telefonica.com
Antonio Agustín Pastor Perales
Telefonica I+D
Email:antonio.pastorperales@telefonica.com
Thomas Fossati
ARM
Email:thomas.fossati@arm.com
[8]ページ先頭
©2009-2025 Movatter.jp