Internet-Draft | ACME STAR Delegation | August 2020 |
Sheffer, et al. | Expires 26 February 2021 | [Page] |
This memo proposes a profile of the ACME protocol that allows the owner of an identifier (e.g., a domain name) to delegate to a third party access to a certificate associated with said identifier. A primary use case is that of a 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 by cancelling the associated STAR certificate renewal with the ACME CA. Another key property of this mechanism is it does not require any modification to the deployed TLS ecosystem.¶
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 26 February 2021.¶
Copyright (c) 2020 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.¶
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), that we can associate in the primary use case to a content provider (also referred to as Domain Name Owner, DNO), has agreements in place with one or more NDC (Name Delegation Consumer) to use and attest its identity. In the primary use case, we consider a CDN provider contracted to serve the IdO 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 authority of the URL that is requested, i.e., that of the IdO. Understandably, most IdOs 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 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 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.¶
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.¶
While the primary use case we address is delegation of STAR certificates, the mechanism proposed here accommodates any certificate managed with the ACME protocol. See Section 2.4 for details.¶
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.¶
This section presents the protocol flow. For completeness, we include the ACME profile proposed in this draft as well as the extended ACME protocol described in [RFC8739].¶
The protocol assumes the following preconditions are met:¶
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;¶
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 CA.¶
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 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 is as follow (Figure 1):¶
ready
with a finalize
URL;¶
invalid
state and
everything stops;¶
processing
, and sends a new Order2 (using its own account) for the delegated
identifier to the ACME STAR CA;¶
invalid
and the same state
is reflected in the NDC Order;¶
valid
), IdO copies the
star-certificate
URL from Order2 to Order1 and moves its 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 ACME STAR CA.¶
Note that, because the identity validation is suppressed, the NDC sends the finalize request, including the CSR, to the IdO immediately after Order1 has been acknowledged. The IdO must buffer a (valid) CSR until the Validation phase completes successfully.¶
This section defines a profile of the ACME protocol, to be used between the NDC and IdO.¶
An NDC identifies itself to the IdO as an ACME account. The IdO can delegate
multiple names through each NDC, and these configurations are described through
delegation
objects associated with the NDC's Account object on the IdO. A
delegation configuration object contains the CSR template (see
Section 3) that applies to that delegation. Its structure is as
follows:¶
An example delegation object is shown in Figure 2.¶
{ "csr-template": { "keyTypes": [ { "PublicKeyType": "ecPublicKey", "Curve": "secp521r1", "SignatureType": "ecdsa-with-SHA256" } ], "subject": { "country": "CA", "stateOrProvince": "**", "locality": "**", "commonName": "**" }, "extensions": { "subjectAltName": { "DNS": [ "abc.ndc.dno.example" ] }, "keyUsage": [ "digitalSignature" ], "extendedKeyUsage": [ "serverAuth" ] } } }
In order to list all the delegation configuration objects that are associated
with the NDC account, a new (read-only) delegations
attribute is added to the
Account object. The value of this attribute is an array of URLs each pointing
to a delegation configuration object as shown in Figure 3.¶
{ "status": "valid", "contact": [ "mailto:delegation-admin@ido.example" ], "termsOfServiceAgreed": true, "orders": "https://example.com/acme/orders/rzGoeA", "delegations": [ "https://acme.dno.example/acme/acct/ndc/delegations/1", "https://acme.dno.example/acme/acct/ndc/delegations/2" ] }
In order to indicate which specific delegation applies to the requested
certificate a new delegation
attribute is added to the Order object on the
NDC-IdO side (see Section 2.3.2). The value of this attribute is
the URL pointing to the delegation configuration object that is to be used for
this certificate request.¶
The Order object created by the NDC:¶
delegation
attribute indicating the configuration used for
this request;¶
delegated
field set to true;¶
notBefore
and notAfter
fields;¶
auto-renewal
object and inside it, the fields
listed in Section 3.1.1 of [RFC8739];¶
dns
, it MAY contain a cname
field with the
alias of the identifier in the NDC domain. This field is used by the IdO to
create the DNS aliasing needed to redirect the resolvers to the delegated
entity.¶
POST /acme/new-order HTTP/1.1 Host: acme.dno.example Content-Type: application/jose+json { "protected": base64url({ "alg": "ES256", "kid": "https://acme.dno.example/acme/acct/evOfKhNU60wg", "nonce": "5XJ1L3lEkMG7tR6pA00clA", "url": "https://acme.dno.example/acme/new-order" }), "payload": base64url({ "identifiers": [ { "type": "dns", "value": "abc.ndc.dno.example.", "delegated": true, "cname": "abc.ndc.example." } ], "auto-renewal": { "end-date": "2020-04-20T00:00:00Z", "lifetime": 345600, // 4 days "allow-certificate-get": true }, "delegation": "https://acme.dno.example/acme/acct/ndc/delegations/2" }), "signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g" }¶
The Order object that is created on the IdO:¶
ready
state;¶
authorizations
array with zero elements;¶
notBefore
and notAfter
fields;¶
delegation
configuration.¶
{ "status": "ready", "expires": "2019-05-01T00:00:00Z", "identifiers": [ { "type": "dns", "value": "abc.ndc.dno.example.", "delegated": true, "cname": "abc.ndc.example." } ], "auto-renewal": { "end-date": "2020-04-20T00:00:00Z", "lifetime": 345600, "allow-certificate-get": true }, "delegation": "https://acme.dno.example/acme/acct/ndc/delegations/2", "authorizations": [], "finalize": "https://acme.dno.example/acme/order/TO8rfgo/finalize" }¶
The IdO MUST copy the auto-renewal
object from the NDC request into the
related STAR request to the ACME CA.¶
When the validation of the identifiers has been successfully completed and the certificate has been issued by the CA, the IdO:¶
valid
;¶
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.dno.example.", "delegated": true, "cname": "abc.ndc.example." } ], "auto-renewal": { "end-date": "2020-04-20T00:00:00Z", "lifetime": 345600, "allow-certificate-get": true }, "delegation": "https://acme.dno.example/acme/acct/ndc/delegations/2", "authorizations": [], "finalize": "https://acme.dno.example/acme/order/TO8rfgo/finalize", "star-certificate": "https://acme.ca.example/acme/order/yTr23sSDg9" }¶
If an identifier
attribute of type dns
was included, the IdO MUST validate
the specified CNAME at this point in the flow. At the minimum, the IdO MUST
verify that both DNS names are syntactically valid, to prevent a malicious NDC
from injecting arbitrary data into a DNS zone file.¶
Following this validation, the IdO can add the CNAME records to its zone:¶
abc.ndc.dno.example. CNAME abc.ndc.example.¶
When sending the Order to the ACME CA, the IdO SHOULD strip the delegated
and
cname
attributes sent by the NDC (Section 2.3.2). The IdO MUST
add the necessary STAR extensions to the Order. In addition, to allow the NDC
to download the certificate using unauthenticated GET, the IdO MUST add the
auto-renewal
object and inside it, include the allow-certificate-get
attribute and set it to true.¶
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:¶
The delegation-enabled
flag may be specified regardless of the existence or
setting of the auto-renewal
flag.¶
It is worth noting that cancellation of the ACME STAR certificate is a prerogative of the IdO. The NDC does not own the relevant account key on the ACME CA, therefore it can't issue a cancellation request for the STAR cert. Potentially, since it holds the STAR certificate's private key, it could request the revocation of a single STAR certificate. However, STAR explicitly disables the revokeCert interface.¶
The mechanism defined here can be used to delegate regular ACME certificates whose expiry is not "short term".¶
To allow delegation of non-STAR certificates, this document allows use of
allow-certificate-get
directly in the Order object and independently of the
auto-renewal
object, so that the NDC can fetch the certificate without having
to authenticate into the ACME server.¶
The following differences exist between STAR and non-STAR certificate delegation:¶
star-certificate
field is copied by the IdO;
with non-STAR certificates, the certificate
field is copied.¶
auto-renewal
object is not used (either in the request or response) for
non-STAR certificates. The field allow-certificate-get
MUST be included in
the order object, and its value MUST be true
.¶
notBefore
and notAfter
order fields are omitted only in STAR
certificates.¶
When delegating a non-STAR certificate, standard certificate revocation still applies. The ACME certificate revocation endpoint is explicitly unavailable for STAR certificates but it is available for all other certificates. We note that according to Sec. 7.6 of [RFC8555], the revocation endpoint can be used with either the account keypair, or the certificate keypair. In other words, the NDC would be able to revoke the certificate. The authors believe that this is a very minor security risk.¶
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 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 the server 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:¶
New-order response:¶
Get Order response:¶
Finalize request:¶
Finalize response:¶
Location
header and the finalize
URLs are rewritten.¶
We note that all the above messages are authenticated, and therefore each proxy must be able to authenticate any subordinate server.¶
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.¶
The template is a JSON document. Each field denotes one of:¶
client1.ndc.dno.example.com
.¶
\*\*
.¶
\*
.¶
The NDC MUST NOT include in the CSR any fields that are not specified in the template, and in particular MUST NOT add any extensions unless those were previously negotiated out of band with the IdO.¶
The mapping between X.509 CSR fields and the template will be defined in a future revision of this document.¶
When the CSR is received by the IdO, it MUST verify that the CSR is consistent with the template that the IdO sent earlier. The IdO MAY enforce additional constraints, e.g. by restricting field lengths.¶
The CSR template in Figure 4 represents one possible CSR template governing the delegation exchanges provided in the rest of this document.¶
{ "keyTypes": [ { "PublicKeyType": "RSA", "PublicKeyLength": 4096, "SignatureType": "sha256WithRSAEncryption" } ], "subject": { "country": "CA", "stateOrProvince": "**", "locality": "**", "commonName": "**" }, "extensions": { "subjectAltName": { "DNS": [ "client1.ndc.dno.example" ], "IP": [ "1.2.3.4", "13::17" ] }, "keyUsage": [ "digitalSignature" ], "extendedKeyUsage": [ "serverAuth", "timeStamping" ] } }
The template syntax is defined in Appendix B.¶
[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.¶
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.¶
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 DNO 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 DNO, 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:¶
Note that such mechanism is provided by the CSR template.¶
A User Agent (browser or set-top-box) wants to fetch the video resource at
the following URI: https://video.cp.example/movie
. Redirection between
Content Provider, upstream, and downstream CDNs is arranged as a
CNAME-based aliasing chain as illustrated in Figure 5.¶
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
SAN matches video.cp.example
, i.e., a Content Provider's name.¶
Figure 6 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.¶
TBD bootstrap, see https://github.com/yaronf/I-D/issues/47¶
Note that 9. and 10. repeat until the delegation expires or is terminated.¶
As a second use case, we consider the delegation of credentials in the STIR ecosystem [I-D.ietf-stir-cert-delegation].¶
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] cert extension.¶
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.¶
[[RFC Editor: please replace XXXX below by the RFC number.]]¶
This document adds the following entries to the ACME Directory Metadata Fields:¶
Field Name | Field Type | Reference |
---|---|---|
delegation-enabled | boolean | RFC XXXX |
This document adds the following entries to the ACME Order Object Fields:¶
Field Name | Field Type | Configurable | Reference |
---|---|---|---|
allow-certificate-get | boolean | true | RFC XXXX |
delegation | string | true | RFC XXXX |
Note that the delegation field is only meaningful in interactions with ACME
servers that have delegation-enabled
set to true in their meta Object.¶
This document adds the following entries to the ACME Account Object Fields:¶
Field Name | Field Type | Requests | Reference |
---|---|---|---|
delegations | array of strings | 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.¶
This document adds the following entries to each element of the ACME
identifiers
array of objects:¶
Field Name | Field Type |
---|---|
delegated | boolean |
cname | string |
We note that [RFC8555] does not define a registry for these objects.¶
IANA is requested to establish a registry "STAR Delegation CSR Template Extensions", with "Expert Review" as its registration procedure.¶
Each extension registered must specify:¶
The initial contents of this registry are the extensions defined by the JSON Schema document in Appendix B.¶
Extension Name | Type | Mapping to X.509 |
---|---|---|
keyUsage | See Appendix B | [RFC5280], Sec. 4.2.1.3 |
extendedKeyUsage | See Appendix B | [RFC5280], Sec. 4.2.1.12 |
subjectAltName | See Appendix B | [RFC5280], Sec. 4.2.1.6 (only for the supported name formats) |
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.¶
Delegation introduces a new security goal: only an NDC that has been authorised by the IdO, either directly or transitively, can obtain a cert with an IdO identity.¶
From a security point of view, the delegation process has two separate parts:¶
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.¶
Using the model established in Section 10.1 of [RFC8555], we can decompose the interactions of the basic delegation workflow as shown in Figure 8.¶
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.¶
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.¶
Following is the proposed solution where the IdO wishes to ensure that a rogue CDN cannot issue unauthorized certificates:¶
We note that the above solution may need to be tweaked depending on the exact capabilities and authorisation flows supported by the selected CAs.¶
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.¶
[[Note to RFC Editor: please remove before publication.]]¶
Following is a JSON Schema definition of the CSR template. The syntax used is that of draft 7 of JSON Schema, which may not be the latest version of the corresponding Internet Draft [I-D.handrews-json-schema] at the time of publication.¶
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", "$def": { "distinguished-name": { "$id": "#distinguished-name", "type": "object", "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": "RSA" }, "PublicKeyLength": { "type": "integer" }, "SignatureType": { "type": "string", "enum": [ "sha256WithRSAEncryption" ] } }, "additionalProperties": false }, "ecKeyTYpe": { "$id": "#ecKeyType", "type": "object", "properties": { "PublicKeyType": { "type": "string", "const": "ecPublicKey" }, "Curve": { "type": "string", "enum": [ "secp521r1" ] }, "SignatureType": { "type": "string", "enum": [ "ecdsa-with-SHA256" ] } }, "additionalProperties": false } }, "type": "object", "properties": { "keyTypes": { "type": "array", "items": { "oneOf": [ { "$ref": "#rsaKeyType" }, { "$ref": "#ecKeyType" } ] } }, "subject": { "$ref": "#distinguished-name" }, "extensions": { "type": "object", "properties": { "keyUsage": { "type": "array", "items": { "type": "string", "enum": [ "digitalSignature", "nonRepudiation", "keyEncipherment", "dataEncipherment", "keyAgreement", "keyCertSign", "cRLSign", "encipherOnly", "decipherOnly" ] } }, "extendedKeyUsage": { "type": "array", "items": { "type": "string", "enum": [ "serverAuth", "clientAuth", "codeSigning", "emailProtection", "timeStamping", "OCSPSigning" ] } }, "subjectAltName": { "type": "object", "properties": { "DNS": { "type": "array", "items": { "type": "string", "format": "hostname" } }, "IP": { "type": "array", "items": { "oneOf": [ { "type": "string", "format": "ipv4" }, { "type": "string", "format": "ipv6" } ] } }, "Email": { "type": "array", "items": { "type": "string", "format": "email" } } }, "additionalProperties": false } }, "additionalProperties": false } }, "additionalProperties": false }¶