Internet-Draft ACME Delegation March 2021
Sheffer, et al. Expires 27 September 2021 [Page]
Workgroup:
ACME
Internet-Draft:
draft-ietf-acme-star-delegation-07
Published:
Intended Status:
Standards Track
Expires:
Authors:
Y. Sheffer
Intuit
D. López
Telefonica I+D
A. Pastor Perales
Telefonica I+D
T. Fossati
ARM

An ACME Profile for Generating Delegated Certificates

Abstract

This memo defines a profile of the Automatic Certificate Management Environment (ACME) protocol by which the owner of an identifier (e.g., a domain name) can allow a third party to obtain an X.509 certificate such that the certificate subject is the delegated 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 name). The presented mechanism allows the owner of the identifier to retain control over the delegation and revoke it at any time. A key property of this mechanism is it does not require any modification to the deployed TLS ecosystem.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 27 September 2021.

▲

Table of Contents

1. Introduction

This document is a companion document to [RFC8739]. To avoid duplication, we give here a bare-bones description of the motivation for this solution. For more details and further use cases, please refer to the introductory sections of [RFC8739].

An Identifier Owner (IdO) has agreements in place with one or more NDC (Name Delegation Consumer) to use and attest its identity.

In the primary use case the IdO is a content provider, and we consider a Content Delivery Network (CDN) provider contracted to serve the content over HTTPS. The CDN terminates the HTTPS connection at one 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 of the 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 and, equally, delegates would rather not have to handle other parties' long-term secrets. Other relevant use cases are discussed in Section 4.

This document describes a profile of the ACME protocol [RFC8555] that allows the NDC to request from the IdO, acting as a profiled ACME server, a certificate for a delegated identity - i.e., one belonging to the IdO. The IdO then uses the ACME protocol (with the extensions described in [RFC8739]) to request issuance of a Short-Term, Automatically Renewed (STAR) certificate for the same delegated identity. The generated short-term certificate is automatically renewed by the ACME Certification Authority (CA), periodically fetched by the NDC and used to terminate HTTPS connections in lieu of the IdO. The IdO can end the delegation at any time by simply 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 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 aliasing of the delegated name, thus allowing the complete name delegation workflow to be handled using a single interface.

We note that other ongoing efforts address the problem of certificate delegation for TLS connections, specifically [I-D.ietf-tls-subcerts] and [I-D.mglt-lurk-tls13]. Compared to these other solutions, the current document does not introduce additional latency to the TLS connection, nor does it require changes to the TLS network stack of either the client or the server.

1.1. Terminology

IdO

Identifier Owner, the owner of an identifier (e.g., a domain name) that needs to be delegated.

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 case (in fact, readers may note the symmetry of the two acronyms).

CDN

Content Delivery Network, a widely distributed network that serves the domain's web content to a wide audience at high performance.

STAR

Short-Term, Automatically Renewed X.509 certificates.

ACME

Automated Certificate Management Environment, a certificate management protocol [RFC8555].

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

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 as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Protocol Flow

This section presents the protocol flow. For completeness, we include the ACME profile proposed in this document as well as the extended ACME protocol described in [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 account management interface;
  • The NDC has registered an ACME account with the IdO;
  • NDC and IdO have agreed on a "CSR template" to use, including at a minimum: subject name (e.g., somesite.example.com), requested algorithms and key length, key usage, extensions (e.g., TNAuthList). The NDC is required to use this template for every CSR created under the same delegation;
  • 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 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 NDC's key-pair and is responsible for completing the identity verification process towards the ACME server.

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 ACME workflow detailed in Section 2.3. The interaction between the IdO and the CA is ruled by ACME [RFC8555], ACME STAR [RFC8739] as well as any other ACME extension that applies (e.g., [I-D.ietf-acme-authority-token-tnauthlist] for STIR).

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;
  • IdO creates an Order1 resource in state ready with a finalize URL;
  • NDC immediately sends a finalize 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 an invalid state and everything stops;
  • If the CSR verification is successful, IdO moves Order1 to state processing, and sends a new Order2 (using its own account) for the delegated identifier to the CA;
  • If the ACME STAR protocol fails, Order2 moves to invalid and the same state is reflected in Order1 (i.e., the NDC Order);
  • If the ACME STAR run is successful (i.e., Order2 is valid), IdO copies the star-certificate URL from Order2 to Order1 and updates the Order1 state to valid.

The NDC can now download, install and use the short-term certificate bearing the name delegated by the IdO. This can continue until the STAR certificate expires or the IdO decides to cancel the automatic renewal process with the CA.

Note that the interactive identifier authorization phase described in Section 7.5 of [RFC8555] is suppressed on the NDC-IdO side because the delegated identity contained in the CSR presented to the IdO is validated against the configured CSR template (Section 2.3.1). Therefore, the NDC sends the finalize request, including the CSR, to the IdO immediately after Order1 has been acknowledged. The IdO SHALL buffer a (valid) CSR until the Validation phase completes successfully.

e t a n n I C r e S a ~ ~ e r r i r o i t u t S e T ) t N l e o i e t t t e u t l i d A e a A w R c e n n u e d G n ~ G ( ] h f ( u t ] o s g E T i A t c c [ y [ r c a > n z n A i i r n e a n E i s k s e t e c r a q r s n D i S g o i # T ] t C e . R a a ~ a S a t a z u i i d o g < ( t e C e S f i i w e R f m V T S g ~ a s a t t e h S a S C a u a S A n i v e t i a C s i c c i a d e 1 u t a e r u ~ e N a i t n t u h C n a n R i > - < T t R d r r < i n r A t S i e u n r E n ~ ~ c t [ t g i e l i s r O t n A i c c i o d t i ~ l i s u f u l a ~ ~ c e t a i e S r r e e e n r # e i r R e r i e l C . T n O S a n a e a t 2 m e i h o t e o t d c ) e n [ k u ~ v t o e r n i A O t d d ~ t G c e v t u w w ) i r v o t t . d C a n u i t f 1 i M c t s a i i C 2 n ~ R g e r t n # p g u e t d A e e e a h ~ d > c ] E e c f
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 NDC and IdO.

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

An NDC identifies itself to the IdO as an ACME account. The IdO can delegate multiple names to a NDC, and these configurations are described through delegation objects associated with the NDC's Account object on the IdO.

As shown in Figure 2, the ACME account resource on the IdO is extended with a new delegations attribute:

  • delegations (required, string): A URL from which a list of delegations configured for this account can be fetched via a POST-as-GET request. 
{
  "status": "valid",
  "contact": [
    "mailto:delegation-admin@ido.example"
  ],
  "termsOfServiceAgreed": true,
  "orders": "https://example.com/acme/orders/rzGoeA",
  "delegations": "https://acme.ido.example/acme/delegations/adFqoz"
}
Figure 2: Example Account object with delegations
2.3.1.2. Delegation Objects

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

A delegation object contains the CSR template (see Section 3) that applies to that delegation, and optionally any related CNAME mapping for the delegated identifiers. Its structure is as follows:

  • csr-template (required, object): CSR template as defined in Section 3.
  • cname-map (optional, object): a map of FQDN pairs. In each pair, the name is the delegated identifier, the value is the corresponding IdO name that is aliased in the IdO's zone file to redirect the resolvers to the delegated entity. Both names and values MUST be FQDNs with a terminating '.'. This field is only meaningful for identifiers of type dns.

An example delegation object is shown in Figure 3.

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

In order to indicate which specific delegation applies to the requested certificate a new delegation attribute is added to the identifier in the Order object on the NDC-IdO side (see Figure 4). The value of this attribute is the URL pointing to the delegation configuration object that is to be used for this certificate request. If the delegation attribute in the Order object contains a URL that does not correspond to a configuration available to the requesting NDC, the IdO MUST return an error response with status code 403 (Forbidden) and type urn: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 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.
  • MUST NOT contain the notBefore and notAfter fields;
  • MUST contain an auto-renewal object and inside it, the fields listed in Section 3.1.1 of [RFC8739]. 
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": "5XJ1L3lEkMG7tR6pA00clA",
    "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"
      }
    ],
    "auto-renewal": {
      "end-date": "2020-04-20T00:00:00Z",
      "lifetime": 345600,          // 4 days
      "allow-certificate-get": true
    }
  }),
  "signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g"
}
Figure 4: New 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.
  • MUST NOT contain the notBefore and notAfter fields. 
{
  "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"
   }
  ],

  "auto-renewal": {
    "end-date": "2020-04-20T00:00:00Z",
    "lifetime": 345600,
    "allow-certificate-get": true
  },

  "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 the delegated identifiers. The IdO checks the provided CSR against the template that applies to each delegated identifier, as described in Section 3.1. If the CSR fails validation for any of the identifiers, the IdO MUST return an error response with status code 403 (Forbidden) and an appropriate type, e.g., rejectedIdentifier or badCSR. The error response SHOULD contain subproblems (Section 6.7.1 of [RFC8555]) for each failed identifier. 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 carry a copy of the auto-renewal object sent by the NDC and augment it with an 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 star-certificate field from the STAR Order. The latter indirectly includes (via the NotBefore and NotAfter HTTP headers) the renewal timers needed by the NDC to inform its certificate reload logic. 
{
  "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"
   }
  ],

  "auto-renewal": {
    "end-date": "2020-04-20T00:00:00Z",
    "lifetime": 345600,
    "allow-certificate-get": true
  },

  "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
2.3.2.1. CNAME Installation

If an identifier object of type dns was included, the IdO can add the corresponding CNAME records to its zone, e.g.:

   abc.ndc.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 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 directory object of an ACME server MUST contain the following attribute in the meta field:

  • delegation-enabled: boolean flag indicating support for the profile specified in this memo. An ACME server that supports this delegation profile MUST include this key, and MUST set it to true.

The delegation-enabled flag may be specified regardless of the existence or setting of the auto-renewal flag.

2.3.5. Terminating the Delegation

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

2.3.5.1. By Cancellation (STAR)

The IdO can terminate the delegation of a STAR certificate by requesting its cancellation (see Section 3.1.2 of [RFC8739]).

Cancellation of the ACME STAR certificate is a prerogative of the IdO. The NDC does not own the relevant account key on the ACME server, 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 the revocation of a single STAR certificate. However, STAR explicitly disables the revokeCert interface.

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

2.3.5.2. By Revocation (non-STAR)

The IdO can terminate the delegation of a non-STAR certificate by requesting it to be revoked using the revokeCert URL exposed by the ACME server.

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, such as the use case described in Section 4.1.2. This section describes the behavior of such proxies.

An entity implementing the IdO server role - an "ACME Delegation 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 obtain a certificate directly. The determining factor is whether it can successfully be authorized by the ACME server for the identity associated with the certificate request.

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

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

  • New-order request:

    • The complete identifiers object MUST be copied as-is.
    • Similarly, the auto-renewal object MUST be copied as-is.

  • New-order response:

    • The status, expires, authorizations, identifiers and auto-renewal attributes/objects MUST be copied as-is.
    • The finalize URL is rewritten, so that the finalize request will be made to the proxy.
    • Similarly, the Location header MUST be rewritten to point to an Order object on the proxy.
    • And similarly, any Link relations.

  • Get Order response:

    • The status, expires, authorizations, identifiers and auto-renewal attributes/objects 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 will be made to the proxy.
    • The Location header MUST be rewritten to point to an Order object on the proxy.
    • Any Link relations MUST be rewritten to point to the proxy.

  • Finalize request:

    • The CSR MUST be copied as-is.

  • Finalize response:

    • The Location header, Link relations and the finalize URLs are rewritten as for Get Order.

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

3. CSR Template

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

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

3.1. Template Syntax

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

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

The NDC MUST NOT include in the CSR any fields, including any extensions, unless they are specified in the template.

The structure of the template object is defined by the CDDL [RFC8610] document in Appendix B.

An alternative, non-normative JSON Schema syntax is given in Appendix C.

The subject field and its subfields are mapped into the subject field of the CSR, as per [RFC5280], Section 4.1.2.6. Other extension fields of the CSR template are mapped into the CSR according to the 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 property constrains the SubjectPublicKeyInfo field of the CSR, which MUST have the type/size defined by one of the array members of the keyTypes property.

When the IdO receives the CSR, it MUST verify that the CSR is consistent with the template contained in the delegation object referenced in the Order. The IdO MAY enforce additional constraints, e.g. by restricting field lengths. In this regard, note that a subjectAltName of type DNS can be specified using the wildcard notation, meaning that the NDC can be required (**) or offered the possibility (*) to define the delegated domain name by itself. If this is the case, the IdO needs to have a further layer of checks on top of the control rules already provided by the CSR template to fully validate the CSR input.

3.2. Example

The CSR template in Figure 10 represents one possible CSR template governing 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": "**",
    "commonName": "**"
  },
  "extensions": {
    "subjectAltName": {
      "DNS": [
        "client1.ndc.ido.example"
      ]
    },
    "keyUsage": [
      "digitalSignature"
    ],
    "extendedKeyUsage": [
      "serverAuth",
      "clientAuth"
    ]
  }
}
Figure 10: Example CSR template

4. Further Use Cases

This non-normative section describes additional use cases that use STAR certificate delegation in non-trivial ways.

4.1. CDN Interconnection (CDNI)

[I-D.ietf-cdni-interfaces-https-delegation] discusses several solutions addressing different delegation requirements for the CDNI (CDN Interconnection) environment. This section discusses two of the stated requirements in the context of the STAR delegation workflow.

This section uses specifically CDNI terminology, e.g. "uCDN" and "dCDN", as defined in [RFC7336].

4.1.1. Multiple Parallel Delegates

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

4.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 a contractual relationship with uCDN, and uCDN has a similar relationship with dCDN. However IdO may not even know about dCDN.

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

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

  • The namespace that is made available to the dCDN to mint its delegated names;
  • The policy for creating the key material (allowed algorithms, minimum key lengths, key usage, etc.) that the dCDN needs to satisfy.

Note that such mechanism is provided by the CSR template.

4.1.2.1. Two-Level Delegation in CDNI

A User Agent (UA), browser or set-top-box, wants to fetch the video resource at the following URI: https://video.cp.example/movie. Redirection between Content Provider (CP), upstream, and downstream CDNs is arranged as a CNAME-based aliasing chain as illustrated in Figure 11.

. M e a . e i p e ( N e U N . p C S i p A n ( . ? d N e m u m S D l n . c l l A o a i M e c x N a . v A C v o 0 a v p p p ( D S : e D c T o d n d i e . D a x m e N d m v c x S . . c v 2 e P d D N A N L d e c c l ) d i T e e . S S p e 2 p e N e . . a . a d E v S o 9 C d ? u b C d e m i l d D o m u 1 x n e ) ? 1 I o l d d ) C L N E . x . x
Figure 11: DNS Redirection

Unlike HTTP based redirection, where the original URL is supplanted by the one found in the Location header of the 302 response, DNS redirection is completely transparent to the User Agent. As a result, the TLS connection to the dCDN edge is done with an SNI equal to the host in the original URI - in the example, video.cp.example. So, in order to successfully complete the handshake, the landing dCDN node has to be configured with a certificate whose subjectAltName matches video.cp.example, i.e., a Content Provider's name.

Figure 12 illustrates the cascaded delegation flow that allows dCDN to obtain a STAR certificate that bears a name belonging to the Content Provider with a private key that is only known to the dCDN.

i T 1 N e l 8 A c 4 d 9 A c 0 D N A D l M P v M C T T R s 3 T e l d C e C 0 H P S P 5 l T T u C 2 N d H S i R e e S r 6 C A A E e I l D A R C w 1 N T T T f S 7 S d R d C A R I C D A E
Figure 12: Two levels delegation in CDNI

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

  1. dCDN requests CDNI path metadata to uCDN;
  2. uCDN replies with, among other CDNI metadata, the STAR delegation configuration, which includes the delegated Content Provider's name;
  3. dCDN creates a key-pair and the CSR with the delegated name. It then places an order for the delegated name to uCDN;
  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. The order also requests unauthenticated access to the certificate resource;
  6. After all authorizations complete successfully, the STAR certificate is issued;
  7. CP notifies uCDN that the STAR certificate is available at the order's star-certificate URL;
  8. uCDN forwards the information to dCDN. At this point the ACME signalling is complete;
  9. dCDN requests the STAR certificate using unauthenticated GET from the ACME server;
  10. the CA returns the certificate. Now dCDN is fully configured to handle HTTPS traffic in-lieu of the Content Provider.

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

4.2. Secure Telephone Identity Revisited (STIR)

As a second use case, we consider the delegation of credentials in 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 - needs to sign PASSPorT's [RFC8225] for telephone numbers (e.g., TN=+123) belonging to another service provider, SP1 - the IdO. In order to do that, SP2 needs a STIR certificate, and private key, that includes TN=+123 in the TNAuthList [RFC8226] certificate extension.

In details (Figure 13):

  1. SP1 and SP2 agree on the configuration of the delegation - in particular, the CSR template that applies;
  2. SP2 generates a private/public key-pair and sends a CSR to SP1 requesting creation of a certificate with: SP1 name, SP2 public key, and a TNAuthList extension with the list of TNs that SP1 delegates to SP2. (Note that the CSR sent by SP2 to SP1 needs to be validated against the CSR template agreed upon in step 1.);
  3. SP1 sends an Order for the CSR to the CA;
  4. Subsequently, after the required TNAuthList authorizations are successfully completed, the CA moves the Order to a "valid" state; at the same time the star-certificate endpoint is populated.
  5. The Order contents are forwarded from SP1 to SP2 by means of the paired "delegation" Order.
  6. SP2 dereferences the star-certificate URL in the Order to fetch the rolling STAR certificate bearing the delegated identifiers.
1 H S l P e T T P P i l S R l c 3 T c e i R S 7 e A A 2 6 T 1 s l E A A R S C T T S d v C A H d r e 5 M d e R 4 P e T A l S T 2
Figure 13: Delegation in STIR

As shown, the STAR delegation profile described in this document applies straightforwardly, the only extra requirement being the ability to instruct the NDC about the allowed TNAuthList values. This can be achieved by a simple extension to the CSR template.

5. IANA Considerations

[[RFC Editor: please replace XXXX below by the RFC number.]]

5.1. New ACME Identifier Object Fields

This document requests that IANA create the following new registry under the Automated Certificate Management Environment (ACME) Protocol:

  • ACME Identifier Object Fields

This registry is administered under a Specification Required policy [RFC8126].

The "ACME Identifier Object Fields" registry lists field names that are defined for use in the ACME identifier object.

Template:

  • Field name: The string to be used as a field name in the JSON object
  • Field type: The type of value to be provided, e.g., string, boolean, array of string
  • Reference: Where this field is defined
Table 1
Field Name Field Type Reference
type string Section 7.1.3 of RFC 8555
value string Section 7.1.3 of RFC 8555
delegation string RFC XXXX

Note: this registry was not created at the time [RFC8555] was standardized likely because it was not anticipated that the identifier object would be extended. It is retrospectively introduced to record the status quo and allow controlled extensibility of the identifier object.

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

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

Table 2
Field Name Field Type Reference
delegation-enabled boolean RFC XXXX

5.3. New Fields in the Order Object

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

Table 3
Field Name Field Type Configurable Reference
allow-certificate-get boolean true RFC XXXX

5.4. New Fields in the Account Object

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

Table 4
Field Name Field Type Requests Reference
delegations string none RFC XXXX

Note that the delegations field is only reported by ACME servers that have delegation-enabled set to true in their meta Object.

5.5. New Error Types

This document adds the following entries to the ACME Error Type registry:

Table 5
Type Description Reference
unknownDelegation An unknown configuration is listed in the delegations attribute of the request Order RFC XXXX

5.6. CSR Template Extensions

IANA is requested to establish a registry "STAR Delegation CSR Template Extensions", with "Expert Review" as its registration procedure.

Each extension registered must specify:

  • An extension name.
  • An extension syntax, as a reference to a JSON Schema document that defines this extension.
  • The extension's mapping into an X.509 certificate extension.

The initial contents of this registry are the extensions defined by the CDDL in Appendix B.

Table 6
Extension Name Extension Syntax Mapping to X.509 Certificate Extension
keyUsage See Appendix B [RFC5280], Section 4.2.1.3
extendedKeyUsage See Appendix B [RFC5280], Section 4.2.1.12
subjectAltName See Appendix B [RFC5280], Section 4.2.1.6 (note that only specific name formats are allowed: URI, DNS name, email address)

6. Security Considerations

6.1. Trust Model

The ACME trust model needs to be extended to include the trust relationship between NDC and IdO. Note that once this trust link is established, it potentially becomes recursive. Therefore, there has to be a trust relationship between each of the nodes in the delegation chain; for example, in case of cascading CDNs this is contractually defined. Note that using standard [RFC6125] identity verification there are no mechanisms available to the IdO to restrict the use of the delegated name once the name has been handed over to the first NDC.

6.2. Delegation Security Goal

Delegation introduces a new security goal: only an NDC that has been authorised by the IdO, either directly or transitively, can obtain a certificate with an IdO 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 for delegated certificates;
  2. Making sure that any request for a delegated certificate matches the intended "shape" in terms of delegated identities as well as any other certificate metadata, e.g., key length, x.509 extensions, etc.;
  3. Serving the certificate back to the NDC;
  4. A process for handling revocation of the delegation;
  5. A process for handling revocation of the certificate itself.

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

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

The third part builds on the trust relationship between NDC and IdO that is responsible for correctly forwarding the certificate URL from the Order returned by the ACME server.

The fourth part is associated with the ability of the IdO to unilaterally remove the delegation object associated with the revoked identity, therefore disabling any further NDC requests for such identity. Note that, in more extreme 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 of the certificate. For STAR, the IdO shall use the cancellation interface defined in Section 2.3 of [RFC8739]. For non-STAR, the certificate revocation interface defined in Section 7.6 of [RFC8555]).

6.3. New ACME Channels

Using the model established in Section 10.1 of [RFC8555], we can decompose the interactions of the basic delegation workflow as shown in Figure 14.

M t i r ] t i n M t ] D d [ i t i n r t o e o A A R a 1 t e e n s i l h l C c . d n h h a t C C e n c n c n a a e t S o C u n t C h c M l v l t A C r T A e r e h V U n E a [ c N d e s c i c r E a 1 n E C s a t A a C b o e f h I ) f E o v u a a n l d O n n a f a i C i f n M - e e n ( e e e e
Figure 14: Delegation Channels Topology

The considerations regarding the security of the ACME Channel and Validation Channel discussed in [RFC8555] apply verbatim to the IdO/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 ACME Channel between NDC and ACME server, which consists of a subset of the ACME interface comprising two API endpoints: the unauthenticated certificate retrieval and, potentially, non-STAR revocation via certificate private key. No specific security considerations apply to the former, but the privacy considerations in Section 6.3 of [RFC8739] do. With regards to the latter, it should be noted that there is currently no means for an IdO to disable authorising revocation based on certificate private keys. So, in theory, an NDC could use the revocation API directly with the ACME server, therefore bypassing the IdO. The NDC SHOULD NOT directly use the revocation interface exposed by the ACME server unless failing to do so would compromise the overall security, for example if the certificate private key is compromised and the IdO is not currently reachable.

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

6.4. Restricting CDNs to the Delegation Mechanism

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

In some cases, this is the desired behavior: the domain owner trusts the CDN to have full control of the cryptographic credentials for the site. The current document however assumes that the domain owner only wants to delegate restricted control, and wishes to retain the capability to cancel the CDN's credentials at a short notice.

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

  • The domain owner makes sure that the CDN cannot modify the DNS records for the domain. The domain owner should ensure it is the only entity authorized to modify the DNS zone. Typically, it establishes a CNAME resource record from a subdomain into a CDN-managed domain.
  • The domain owner uses a CAA record [RFC8659] to restrict certificate issuance for the domain to specific CAs that comply with ACME and are known to implement [RFC8657].
  • The domain owner uses the ACME-specific CAA mechanism [RFC8657] to restrict issuance to a specific account key which is controlled by it, and MUST require "dns-01" as the sole validation method.

We note that the above solution may need to be tweaked depending on the exact capabilities and authorisation flows supported by the selected CAs.

7. Acknowledgments

We would like to thank the following people who contributed significantly to this document with their review comments and design proposals: Roman Danyliw, Frédéric Fieau, Russ Housley, Sanjay Mishra, Jon Peterson, Ryan Sleevi, Emile Stephan.

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

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. and B. 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., and W. 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>.
[RFC8126]
Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/info/rfc8126>.
[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., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, , <https://www.rfc-editor.org/info/rfc8555>.
[RFC8610]
Birkholz, H., Vigano, C., and C. 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>.
[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., and J. Hoffman-Andrews, "DNS Certification Authority Authorization (CAA) Resource Record", RFC 8659, DOI 10.17487/RFC8659, , <https://www.rfc-editor.org/info/rfc8659>.
[RFC8739]
Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor Perales, A., and T. 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

[I-D.ietf-acme-authority-token-tnauthlist]
Wendt, C., Hancock, D., Barnes, M., and J. Peterson, "TNAuthList profile of ACME Authority Token", Work in Progress, Internet-Draft, draft-ietf-acme-authority-token-tnauthlist-07, , <https://www.ietf.org/archive/id/draft-ietf-acme-authority-token-tnauthlist-07.txt>.
[I-D.ietf-cdni-interfaces-https-delegation]
Fieau, F., Stephan, E., and S. Mishra, "CDNI extensions for HTTPS delegation", Work in Progress, Internet-Draft, draft-ietf-cdni-interfaces-https-delegation-05, , <https://www.ietf.org/archive/id/draft-ietf-cdni-interfaces-https-delegation-05.txt>.
[I-D.ietf-stir-cert-delegation]
Peterson, J., "STIR Certificate Delegation", Work in Progress, Internet-Draft, draft-ietf-stir-cert-delegation-04, , <https://www.ietf.org/archive/id/draft-ietf-stir-cert-delegation-04.txt>.
[I-D.ietf-tls-subcerts]
Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, "Delegated Credentials for TLS", Work in Progress, Internet-Draft, draft-ietf-tls-subcerts-10, , <https://www.ietf.org/archive/id/draft-ietf-tls-subcerts-10.txt>.
[I-D.mglt-lurk-tls13]
Migault, D., "LURK Extension version 1 for (D)TLS 1.3 Authentication", Work in Progress, Internet-Draft, draft-mglt-lurk-tls13-04, , <https://www.ietf.org/archive/id/draft-mglt-lurk-tls13-04.txt>.
[json-schema-07]
Wright, A., Andrews, H., and G. Luff, "JSON Schema Validation: A Vocabulary for Structural Validation of JSON", , <https://datatracker.ietf.org/doc/html/draft-handrews-json-schema-validation-01>.
[RFC6125]
Saint-Andre, P. and J. 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., and R. 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. and J. Peterson, "PASSporT: Personal Assertion Token", RFC 8225, DOI 10.17487/RFC8225, , <https://www.rfc-editor.org/info/rfc8225>.
[RFC8226]
Peterson, J. and S. Turner, "Secure Telephone Identity Credentials: Certificates", RFC 8226, DOI 10.17487/RFC8226, , <https://www.rfc-editor.org/info/rfc8226>.

Appendix A. Document History

[[Note to RFC Editor: please remove before publication.]]

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.

A.3. draft-ietf-acme-star-delegation-05

  • Detailed AD review by Roman Danyliw.
  • Some comments that were left unaddressed in Ryan Sleevi's review.
  • Numerous other edits for clarity and consistency.

A.4. draft-ietf-acme-star-delegation-04

  • Delegation of non-STAR certificates.
  • More IANA clarity, specifically on certificate extensions.
  • Add delegation configuration object and extend account and order objects accordingly.
  • A lot more depth on Security Considerations.

A.5. draft-ietf-acme-star-delegation-03

  • Consistency with the latest changes in the base ACME STAR document, e.g. star-delegation-enabled capability renamed and moved.
  • Proxy use cases (recursive delegation) and the definition of proxy behavior.
  • More detailed analysis of the CDNI and STIR use cases, including sequence diagrams.

A.6. draft-ietf-acme-star-delegation-02

  • Security considerations: review by Ryan Sleevi.
  • CSR template simplified: instead of being a JSON Schema document itself, it is now a simple JSON document which validates to a JSON Schema.

A.7. draft-ietf-acme-star-delegation-01

  • Refinement of the CDNI use case.
  • Addition of the CSR template (partial, more work required).
  • Further security considerations (work in progress).

A.8. draft-ietf-acme-star-delegation-00

  • Republished as a working group draft.

A.9. draft-sheffer-acme-star-delegation-01

  • Added security considerations about disallowing CDNs from issuing certificates for a delegated domain.

A.10. draft-sheffer-acme-star-delegation-00

  • Initial version, some text extracted from draft-sheffer-acme-star-requests-02

Appendix B. CSR Template: CDDL

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

An additional constraint that is not expressed in CDDL but MUST be validated by the recipient is that all objects (e.g. distinguishedName) MUST NOT be empty when they are included, even when each separate property is optional.

csr-template-schema = {
  keyTypes: [ 1* $keyType ]
  ? subject: distinguishedName
  extensions: extensions
}

mandatory-wildcard = "**"
optional-wildcard = "*"
wildcard = mandatory-wildcard / optional-wildcard

; regtext matches all text strings but "*" and "**"
regtext = text .regexp "([^\*].*)|([\*][^\*].*)|([\*][\*].+)"

regtext-or-wildcard = regtext / wildcard

distinguishedName = {
  ? 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 /= ecdsaKeyType

rsaKeyType = {
  PublicKeyType: "rsaEncryption" ; OID: 1.2.840.113549.1.1.1
  PublicKeyLength: rsaKeySize
  SignatureType: $rsaSignatureType
}

rsaKeySize = int .ge 2048

; 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 secp521r1

subjectaltname = {
  ? DNS: [ 1* regtext-or-wildcard ]
  ? Email: [ 1* regtext ]
  ? URI: [ 1* regtext ]
  * $$subjectaltname-extension
}

extensions = {
  ? keyUsage: [ 1* keyUsageType ]
  ? extendedKeyUsage: [ 1* extendedKeyUsageType ]
  subjectAltName: 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 /= oid

oid = text .regexp "[0-9]+(\\.[0-9]+)*"

Appendix C. CSR Template: JSON Schema

This appendix includes an alternative, non-normative, 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.

While the CSR template must follow the syntax defined here, neither the IdO nor the NDC are expected to validate it at run-time.

{
  "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",
          "minimum": 2048,
          "multipleOf": 8
        },
        "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",
      "items": {
        "oneOf": [
          {
            "$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": {
            "oneOf": [
              {
                "type": "string",
                "enum": [
                  "serverAuth",
                  "clientAuth",
                  "codeSigning",
                  "emailProtection",
                  "timeStamping",
                  "OCSPSigning"
                ]
              },
              {
                "type": "string",
                "pattern": "^[0-9]+(\\.[0-9]+)*$",
                "description": "Used for OID values"
              }
            ]
          }
        },
        "subjectAltName": {
          "type": "object",
          "minProperties": 1,
          "properties": {
            "DNS": {
              "type": "array",
              "minItems": 1,
              "items": {
                "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
}

Authors' Addresses

Yaron Sheffer
Intuit
Diego López
Telefonica I+D
Antonio Agustín Pastor Perales
Telefonica I+D
Thomas Fossati
ARM