draft-ietf-acme-integrations-04.txt   draft-ietf-acme-integrations-05.txt 
Network Working Group O. Friel Network Working Group O. Friel
Internet-Draft R. Barnes Internet-Draft R. Barnes
Intended status: Informational Cisco Intended status: Informational Cisco
Expires: December 25, 2021 R. Shekh-Yusef Expires: April 28, 2022 R. Shekh-Yusef
Auth0 Auth0
M. Richardson M. Richardson
Sandelman Software Works Sandelman Software Works
June 23, 2021 October 25, 2021
ACME Integrations ACME Integrations
draft-ietf-acme-integrations-04 draft-ietf-acme-integrations-05
Abstract Abstract
This document outlines multiple advanced use cases and integrations This document outlines multiple advanced use cases and integrations
that ACME facilitates without any modifications or enhancements that ACME facilitates without any modifications or enhancements
required to the base ACME specification. The use cases include ACME required to the base ACME specification. The use cases include ACME
integration with EST, BRSKI and TEAP. integration with EST, BRSKI and TEAP.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 25, 2021. This Internet-Draft will expire on April 28, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
7.2. CSR Attributes . . . . . . . . . . . . . . . . . . . . . 15 7.2. CSR Attributes . . . . . . . . . . . . . . . . . . . . . 15
7.3. Certificate Chains and Trust Anchors . . . . . . . . . . 15 7.3. Certificate Chains and Trust Anchors . . . . . . . . . . 15
7.3.1. EST /cacerts . . . . . . . . . . . . . . . . . . . . 15 7.3.1. EST /cacerts . . . . . . . . . . . . . . . . . . . . 15
7.3.2. TEAP PKCS#7 TLV . . . . . . . . . . . . . . . . . . . 16 7.3.2. TEAP PKCS#7 TLV . . . . . . . . . . . . . . . . . . . 16
7.4. id-kp-cmcRA . . . . . . . . . . . . . . . . . . . . . . . 16 7.4. id-kp-cmcRA . . . . . . . . . . . . . . . . . . . . . . . 16
7.5. Error Handling . . . . . . . . . . . . . . . . . . . . . 16 7.5. Error Handling . . . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9.1. Denial of Service against ACME infrastructure . . . . . . 18 9.1. Denial of Service against ACME infrastructure . . . . . . 18
10. Informative References . . . . . . . . . . . . . . . . . . . 19 10. Informative References . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
ACME [RFC8555] defines a protocol that a certificate authority (CA) ACME [RFC8555] defines a protocol that a certificate authority (CA)
and an applicant can use to automate the process of domain name and an applicant can use to automate the process of domain name
ownership validation and X.509 (PKIX) certificate issuance. The ownership validation and X.509 (PKIX) certificate issuance. The
protocol is rich and flexible and enables multiple use cases that are protocol is rich and flexible and enables multiple use cases that are
not immediately obvious from reading the specification. This not immediately obvious from reading the specification. This
document explicitly outlines multiple advanced ACME use cases document explicitly outlines multiple advanced ACME use cases
including: including:
skipping to change at page 3, line 23 skipping to change at page 3, line 23
requirement. requirement.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The following terms are defined in the CA/Browser Forum Baseline The following terms are defined in DNS Terminology [RFC8499] and are
Requirements [CAB] and are reproduced here: reproduced here:
o Authorization Domain Name (ADN): The Domain Name used to obtain
authorization for certificate issuance for a given FQDN. The CA
may use the FQDN returned from a DNS CNAME lookup as the FQDN for
the purposes of domain validation. If the FQDN contains a
wildcard character, then the CA MUST remove all wildcard labels
from the left most portion of requested FQDN. The CA may prune
zero or more labels from left to right until encountering a Base
Domain Name and may use any one of the intermediate values for the
purpose of domain validation
o Base Domain Name: The portion of an applied-for FQDN that is the
first domain name node left of a registry-controlled or public
suffix plus the registry-controlled or public suffix (e.g.
"example.co.uk" or "example.com"). For FQDNs where the right-most
domain name node is a gTLD having ICANN Specification 13 in its
registry agreement, the gTLD itself may be used as the Base Domain
Name.
o Certification Authority (CA): An organization that is responsible o Label: An ordered list of zero or more octets that makes up a
for the creation, issuance, revocation, and management of portion of a domain name. Using graph theory, a label identifies
Certificates. The term applies equally to both Roots CAs and one node in a portion of the graph of all possible domain names.
Subordinate CAs
o Domain Name: The label assigned to a node in the Domain Name o Domain Name: An ordered list of one or more labels.
System
o Domain Namespace: The set of all possible Domain Names that are o Subdomain: "A domain is a subdomain of another domain if it is
subordinate to a single node in the Domain Name System contained within that domain. This relationship can be tested by
seeing if the subdomain's name ends with the containing domain's
name." (Quoted from [RFC1034], Section 3.1) For example, in the
host name "nnn.mmm.example.com", both "mmm.example.com" and
"nnn.mmm.example.com" are subdomains of "example.com". Note that
the comparisons here are done on whole labels; that is,
"ooo.example.com" is not a subdomain of "oo.example.com".
o Fully-Qualified Domain Name (FQDN): A Domain Name that includes o Fully-Qualified Domain Name (FQDN): This is often just a clear way
the labels of all superior nodes in the Internet Domain Name of saying the same thing as "domain name of a node", as outlined
System. above. However, the term is ambiguous. Strictly speaking, a
fully-qualified domain name would include every label, including
the zero-length label of the root: such a name would be written
"www.example.net." (note the terminating dot). But, because every
name eventually shares the common root, names are often written
relative to the root (such as "www.example.net") and are still
called "fully qualified". This term first appeared in [RFC0819].
In this document, names are often written relative to the root.
The following terms are used in this document: The following terms are used in this document:
o BRSKI: Bootstrapping Remote Secure Key Infrastructures [RFC8995] o BRSKI: Bootstrapping Remote Secure Key Infrastructures [RFC8995]
o Certification Authority (CA): An organization that is responsible
for the creation, issuance, revocation, and management of
Certificates. The term applies equally to both Roots CAs and
Subordinate CAs
o CMC: Certificate Management over CMS o CMC: Certificate Management over CMS
o CSR: Certificate Signing Request o CSR: Certificate Signing Request
o EST: Enrollment over Secure Transport [RFC7030] o EST: Enrollment over Secure Transport [RFC7030]
o RA: PKI Registration Authority o RA: PKI Registration Authority
o TEAP: Tunneled Extensible Authentication Protocol [RFC7170] o TEAP: Tunneled Extensible Authentication Protocol [RFC7170]
skipping to change at page 5, line 9 skipping to change at page 5, line 6
This section outlines how ACME could be used for communication This section outlines how ACME could be used for communication
between the EST RA and the CA. The example call flow leverages between the EST RA and the CA. The example call flow leverages
[I-D.friel-acme-subdomains] and shows the RA proving ownership of a [I-D.friel-acme-subdomains] and shows the RA proving ownership of a
parent domain, with individual client certificates being subdomains parent domain, with individual client certificates being subdomains
under that parent domain. This is an optimization that reduces DNS under that parent domain. This is an optimization that reduces DNS
and ACME traffic overhead. The RA could of course prove ownership of and ACME traffic overhead. The RA could of course prove ownership of
every explicit client certificate identifier. every explicit client certificate identifier.
The call flow illustrates the client calling the EST /csrattrs API The call flow illustrates the client calling the EST /csrattrs API
before calling the EST /simpleenroll API. before calling the EST /simpleenroll API. This enables the server to
indicate what fields the client should include in the CSR that the
client sends in the /simpleenroll API. CSR Attributes handling are
discussed in Section 7.2.
The call flow illustrates the EST RA returning a 202 Retry-After The call flow illustrates the EST RA returning a 202 Retry-After
response to the client's simpleenroll request. This is an optional response to the client's simpleenroll request. This is an optional
step and may be necessary if the interactions between the RA and the step and may be necessary if the interactions between the RA and the
ACME server take some time to complete. The exact details of when ACME server take some time to complete. The exact details of when
the RA returns a 202 Retry-After are implementation specific. the RA returns a 202 Retry-After are implementation specific.
+--------+ +--------+ +------+ +-----+ +--------+ +--------+ +------+ +-----+
| Pledge | | EST RA | | ACME | | DNS | | Client | | EST RA | | ACME | | DNS |
+--------+ +--------+ +------+ +-----+ +--------+ +--------+ +------+ +-----+
| | | | | | | |
STEP 1: Pre-Authorization of parent domain STEP 1: Pre-Authorization of parent domain
| | | | | | | |
| | POST /newAuthz | | | | POST /newAuthz | |
| | "example.com" | | | | "example.com" | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 201 authorizations | | | | 201 authorizations | |
| |<---------------------| | | |<---------------------| |
skipping to change at page 5, line 45 skipping to change at page 5, line 45
| |--------------------->| | | |--------------------->| |
| | | Verify | | | | Verify |
| | |---------->| | | |---------->|
| | 200 status=valid | | | | 200 status=valid | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
| | Delete DNS TXT | | | | Delete DNS TXT | |
| | "example.com" | | | | "example.com" | |
| |--------------------------------->| | |--------------------------------->|
| | | | | | | |
STEP 2: Pledge enrolls against RA STEP 2: Client enrolls against RA
| | | | | | | |
| GET /csrattrs | | | | GET /csrattrs | | |
|--------------------->| | | |--------------------->| | |
| | | | | | | |
| 200 OK | | | | 200 OK | | |
| SEQUENCE {AttrOrOID} | | | | SEQUENCE {AttrOrOID} | | |
| SAN OID: | | | | SAN OID: | | |
| "pledge.example.com" | | | | "client.example.com" | | |
|<---------------------| | | |<---------------------| | |
| | | | | | | |
| POST /simpleenroll | | | | POST /simpleenroll | | |
| PCSK#10 CSR | | | | PCSK#10 CSR | | |
| "pledge.example.com" | | | | "client.example.com" | | |
|--------------------->| | | |--------------------->| | |
| | | | | | | |
| 202 Retry-After | | | | 202 Retry-After | | |
|<---------------------| | | |<---------------------| | |
| | | | | | | |
STEP 3: RA places ACME order STEP 3: RA places ACME order
| | | | | | | |
| | POST /newOrder | | | | POST /newOrder | |
| | "pledge.example.com" | | | | "client.example.com" | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 201 status=ready | | | | 201 status=ready | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
| | POST /finalize | | | | POST /finalize | |
| | PKCS#10 CSR | | | | PKCS#10 CSR | |
| | "pledge.example.com" | | | | "client.example.com" | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 200 OK status=valid | | | | 200 OK status=valid | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
| | POST /certificate | | | | POST /certificate | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 200 OK | | | | 200 OK | |
| | PKCS#7 | | | | PKCS#7 | |
| | "pledge.example.com" | | | | "client.example.com" | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
STEP 4: Pledge retries enroll STEP 4: Client retries enroll
| | | | | | | |
| POST /simpleenroll | | | | POST /simpleenroll | | |
| PCSK#10 CSR | | | | PCSK#10 CSR | | |
| "pledge.example.com" | | | | "client.example.com" | | |
|--------------------->| | | |--------------------->| | |
| | | | | | | |
| 200 OK | | | | 200 OK | | |
| PKCS#7 | | | | PKCS#7 | | |
| "pledge.example.com" | | | | "client.example.com" | | |
|<---------------------| | | |<---------------------| | |
4. ACME Integration with BRSKI 4. ACME Integration with BRSKI
BRSKI [RFC8995] is based upon EST [RFC7030] and defines how to BRSKI [RFC8995] is based upon EST [RFC7030] and defines how to
autonomically bootstrap PKI trust anchors into devices via means of autonomically bootstrap PKI trust anchors into devices via means of
signed vouchers. EST certificate enrollment may then optionally take signed vouchers. EST certificate enrollment may then optionally take
place after trust has been established. BRKSI voucher exchange and place after trust has been established. BRKSI voucher exchange and
trust establishment are based on EST extensions and the certificate trust establishment are based on EST extensions and the certificate
enrollment part of BRSKI is fully based on EST. Similar to EST, enrollment part of BRSKI is fully based on EST. Similar to EST,
skipping to change at page 7, line 30 skipping to change at page 7, line 30
that the EST RA has previously proven ownership of a parent domain that the EST RA has previously proven ownership of a parent domain
and that pledge certificate identifiers are a subdomain of that and that pledge certificate identifiers are a subdomain of that
parent domain. The domain ownership exchanges between the RA, ACME parent domain. The domain ownership exchanges between the RA, ACME
and DNS are not shown. Similarly, not all BRSKI interactions are and DNS are not shown. Similarly, not all BRSKI interactions are
shown and only the key protocol flows involving voucher exchange and shown and only the key protocol flows involving voucher exchange and
EST enrollment are shown. EST enrollment are shown.
Similar to the EST section above, the client calls EST /csrattrs API Similar to the EST section above, the client calls EST /csrattrs API
before calling the EST /simpleenroll API. This enables the server to before calling the EST /simpleenroll API. This enables the server to
indicate what fields the pledge should include in the CSR that the indicate what fields the pledge should include in the CSR that the
client sends in the /simpleenroll API. client sends in the /simpleenroll API. Refer to section {csr-
attributes} for more details.
The call flow illustrates the RA returning a 202 Retry-After response The call flow illustrates the RA returning a 202 Retry-After response
to the initial EST /simpleenroll API. This may be appropriate if to the initial EST /simpleenroll API. This may be appropriate if
processing of the /simpleenroll request and ACME interactions takes processing of the /simpleenroll request and ACME interactions takes
some timme to complete. some timme to complete.
+--------+ +--------+ +------+ +------+ +--------+ +--------+ +------+ +------+
| Pledge | | EST RA | | ACME | | MASA | | Pledge | | EST RA | | ACME | | MASA |
+--------+ +--------+ +------+ +------+ +--------+ +--------+ +------+ +------+
| | | | | | | |
skipping to change at page 9, line 30 skipping to change at page 9, line 32
a cloud registrar bootstrap flow. a cloud registrar bootstrap flow.
BRSKI cloud registrar is flexible and allows for multiple different BRSKI cloud registrar is flexible and allows for multiple different
local domain discovery and redirect scenarios. In the example local domain discovery and redirect scenarios. In the example
illustrated here, the extension to [RFC8366] Vouchers which is illustrated here, the extension to [RFC8366] Vouchers which is
defined in [I-D.ietf-anima-brski-cloud], and allows the specification defined in [I-D.ietf-anima-brski-cloud], and allows the specification
of a bootstrap EST domain, is leveraged. This extension allows the of a bootstrap EST domain, is leveraged. This extension allows the
cloud registrar to specify the local domain RA that the pledge should cloud registrar to specify the local domain RA that the pledge should
connect to for the purposes of EST enrollment. connect to for the purposes of EST enrollment.
Similar to the sectioms above, the client calls EST /csrattrs API Similar to the sections above, the client calls EST /csrattrs API
before calling the EST /simpleenroll API. before calling the EST /simpleenroll API.
+--------+ +--------+ +------+ +----------+ +--------+ +--------+ +------+ +----------+
| Pledge | | EST RA | | ACME | | Cloud RA | | Pledge | | EST RA | | ACME | | Cloud RA |
+--------+ +--------+ +------+ | / MASA | +--------+ +--------+ +------+ | / MASA |
| +----------+ | +----------+
| | | |
NOTE: Pre-Authorization of "example.com" is complete NOTE: Pre-Authorization of "example.com" is complete
| | | |
STEP 1: Pledge requests Voucher from Cloud Registrar STEP 1: Pledge requests Voucher from Cloud Registrar
skipping to change at page 11, line 30 skipping to change at page 11, line 31
This section outlines how ACME could be used for communication This section outlines how ACME could be used for communication
between the TEAP server and the CA. The example call flow leverages between the TEAP server and the CA. The example call flow leverages
[I-D.friel-acme-subdomains] and shows the TEAP server proving [I-D.friel-acme-subdomains] and shows the TEAP server proving
ownership of a parent domain, with individual client certificates ownership of a parent domain, with individual client certificates
being subdomains under that parent domain. being subdomains under that parent domain.
The example illustrates the TEAP server sending a Request-Action TLV The example illustrates the TEAP server sending a Request-Action TLV
including a CSR-Attributes TLV instructing the peer to send a CSR- including a CSR-Attributes TLV instructing the peer to send a CSR-
Attributes TLV to the server. This enables the server to indicate Attributes TLV to the server. This enables the server to indicate
what fields the peer should include in the CSR that the peer sends in what fields the peer should include in the CSR that the peer sends in
the PKCS#10 TLV. For example, the TEAP server could instruct the the PKCS#10 TLV.
peer what Subject or SAN entries to include in its CSR.
Althought not explicitly illustrated in this call flow, the Peer and Althought not explicitly illustrated in this call flow, the Peer and
TEAP Server could exchange BRSKI TLVs, and a BRSKI integration and TEAP Server could exchange BRSKI TLVs, and a BRSKI integration and
voucher exchange with a MASA server could take place over TEAP. voucher exchange with a MASA server could take place over TEAP.
Whether a BRSKI TLV exchange takes place or not does not impact the Whether a BRSKI TLV exchange takes place or not does not impact the
ACME specific message exchanges. ACME specific message exchanges.
+------+ +-------------+ +------+ +-----+ +------+ +-------------+ +------+ +-----+
| Peer | | TEAP-Server | | ACME | | DNS | | Peer | | TEAP-Server | | ACME | | DNS |
+------+ +-------------+ +------+ +-----+ +------+ +-------------+ +------+ +-----+
skipping to change at page 13, line 49 skipping to change at page 13, line 49
|------------------------>| | | |------------------------>| | |
| | | | | | | |
| EAP-Request/ | | | | EAP-Request/ | | |
| Type=TEAP, | | | | Type=TEAP, | | |
| {CSR-Attributes TLV} | | | | {CSR-Attributes TLV} | | |
|<------------------------| | | |<------------------------| | |
| | | | | | | |
| EAP-Response/ | | | | EAP-Response/ | | |
| Type=TEAP, | | | | Type=TEAP, | | |
| {PKCS#10 TLV: | | | | {PKCS#10 TLV: | | |
| "pledge.example.com"} | | | | "client.example.com"} | | |
|------------------------>| | | |------------------------>| | |
| | POST /newOrder | | | | POST /newOrder | |
| | "pledge.example.com" | | | | "client.example.com" | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 201 status=ready | | | | 201 status=ready | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
| | POST /finalize | | | | POST /finalize | |
| | PKCS#10 CSR | | | | PKCS#10 CSR | |
| | "pledge.example.com" | | | | "client.example.com" | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 200 OK status=valid | | | | 200 OK status=valid | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
| | POST /certificate | | | | POST /certificate | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | 200 OK | | | | 200 OK | |
| | PKCS#7 | | | | PKCS#7 | |
| | "pledge.example.com" | | | | "client.example.com" | |
| |<---------------------| | | |<---------------------| |
| | | | | | | |
| EAP-Request/ | | | | EAP-Request/ | | |
| Type=TEAP, | | | | Type=TEAP, | | |
| {PKCS#7 TLV, | | | | {PKCS#7 TLV, | | |
| Result TLV=Success} | | | | Result TLV=Success} | | |
|<------------------------| | | |<------------------------| | |
| | | | | | | |
| EAP-Response/ | | | | EAP-Response/ | | |
| Type=TEAP, | | | | Type=TEAP, | | |
skipping to change at page 15, line 10 skipping to change at page 15, line 10
is expected that the EST RA or TEAP servers that the client sends is expected that the EST RA or TEAP servers that the client sends
certificate enrollment requests to are operated by the organization certificate enrollment requests to are operated by the organization
that controls the domains. The ACME server is not necessarily that controls the domains. The ACME server is not necessarily
operated by the organization that controls the domain. operated by the organization that controls the domain.
7.2. CSR Attributes 7.2. CSR Attributes
In all integrations, the client MUST send a CSR Attributes request to In all integrations, the client MUST send a CSR Attributes request to
the EST or TEAP server prior to sending a certificate enrollment the EST or TEAP server prior to sending a certificate enrollment
request. This enables the server to indicate to the client what request. This enables the server to indicate to the client what
attributes it expects the client to include in the subsequent CSR attributes, and what attribute values, it expects the client to
request. include in the subsequent CSR request. For example, the server could
instruct the peer what Subject Alternative Name entries to include in
its CSR.
EST [RFC7030] is not clear on how the CSR Attributes response should
be structured, and in particular is not clear on how a server can
instruct a client to include specific attribute values in its CSR.
[I-D.richardson-lamps-rfc7030-csrattrs] clarifies how a server can
use CSR Attributes response to specify specific values for attributes
that the client should include in its CSR.
Servers MUST use this mechanism to tell the client what identifiers Servers MUST use this mechanism to tell the client what identifiers
to include in CSR request. ACME [RFC8555] allows the identifier to to include in CSR request. ACME [RFC8555] allows the identifier to
be included in either CSR Subject or Subject Alternative Name fields, be included in either CSR Subject or Subject Alternative Name fields,
however [I-D.ietf-uta-use-san] states that Subject Alternative Name however [I-D.ietf-uta-use-san] states that Subject Alternative Name
field MUST be used. This document aligns with [I-D.ietf-uta-use-san] field MUST be used. This document aligns with [I-D.ietf-uta-use-san]
and Subject Alternate Name field MUST be used. The identifier must and Subject Alternate Name field MUST be used. The identifier must
be a Domain Name in a Domain Namespace that the server has control be a Domain Name in a Domain Namespace that the server has control
over and can fulfill ACME challenges against. The leftmost part of over and can fulfill ACME challenges against. The leftmost part of
the identifier MAY be a field that the client presented to the server the identifier MAY be a field that the client presented to the server
skipping to change at page 19, line 14 skipping to change at page 19, line 14
10. Informative References 10. Informative References
[CAB] CA/Browser Forum, "Baseline Requirements for the Issuance [CAB] CA/Browser Forum, "Baseline Requirements for the Issuance
and Management of Publicly-Trusted Certificates", n.d., and Management of Publicly-Trusted Certificates", n.d.,
<https://cabforum.org/wp-content/uploads/CA-Browser-Forum- <https://cabforum.org/wp-content/uploads/CA-Browser-Forum-
BR-1.7.1.pdf>. BR-1.7.1.pdf>.
[I-D.friel-acme-subdomains] [I-D.friel-acme-subdomains]
Friel, O., Barnes, R., Hollebeek, T., and M. Richardson, Friel, O., Barnes, R., Hollebeek, T., and M. Richardson,
"ACME for Subdomains", draft-friel-acme-subdomains-04 "ACME for Subdomains", draft-friel-acme-subdomains-05
(work in progress), March 2021. (work in progress), June 2021.
[I-D.ietf-anima-brski-cloud] [I-D.ietf-anima-brski-cloud]
Friel, O., Shekh-Yusef, R., and M. Richardson, "BRSKI Friel, O., Shekh-Yusef, R., and M. Richardson, "BRSKI
Cloud Registrar", draft-ietf-anima-brski-cloud-00 (work in Cloud Registrar", draft-ietf-anima-brski-cloud-02 (work in
progress), April 2021. progress), October 2021.
[I-D.ietf-uta-use-san] [I-D.ietf-uta-use-san]
Salz, R., "Update to Verifying TLS Server Identities with Salz, R., "Update to Verifying TLS Server Identities with
X.509 Certificates", draft-ietf-uta-use-san-00 (work in X.509 Certificates", draft-ietf-uta-use-san-00 (work in
progress), April 2021. progress), April 2021.
[I-D.lear-eap-teap-brski] [I-D.lear-eap-teap-brski]
Lear, E., Friel, O., Cam-Winget, N., and D. Harkins, "TEAP Lear, E., Friel, O., Cam-Winget, N., and D. Harkins, "TEAP
Update and Extensions for Bootstrapping", draft-lear-eap- Update and Extensions for Bootstrapping", draft-lear-eap-
teap-brski-05 (work in progress), November 2019. teap-brski-06 (work in progress), August 2021.
[I-D.richardson-lamps-rfc7030-csrattrs]
Richardson, M., Harkins, D., Oheimb, D. D. V., and O.
Friel, "Clarification of RFC7030 CSR Attributes
definition", draft-richardson-lamps-rfc7030-csrattrs-00
(work in progress), October 2021.
[IDevID] IEEE, "IEEE Standard for Local and metropolitan area [IDevID] IEEE, "IEEE Standard for Local and metropolitan area
networks - Secure Device Identity", n.d., networks - Secure Device Identity", n.d.,
<https://1.ieee802.org/security/802-1ar>. <https://1.ieee802.org/security/802-1ar>.
[RFC0819] Su, Z. and J. Postel, "The Domain Naming Convention for
Internet User Applications", RFC 819,
DOI 10.17487/RFC0819, August 1982,
<https://www.rfc-editor.org/info/rfc819>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
<https://www.rfc-editor.org/info/rfc3007>. <https://www.rfc-editor.org/info/rfc3007>.
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
skipping to change at page 20, line 19 skipping to change at page 20, line 37
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
"A Voucher Artifact for Bootstrapping Protocols", "A Voucher Artifact for Bootstrapping Protocols",
RFC 8366, DOI 10.17487/RFC8366, May 2018, RFC 8366, DOI 10.17487/RFC8366, May 2018,
<https://www.rfc-editor.org/info/rfc8366>. <https://www.rfc-editor.org/info/rfc8366>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>. <https://www.rfc-editor.org/info/rfc8555>.
[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
May 2021, <https://www.rfc-editor.org/info/rfc8995>. May 2021, <https://www.rfc-editor.org/info/rfc8995>.
 End of changes. 35 change blocks. 
62 lines changed or deleted 91 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/