draft-ietf-acme-acme-07.txt   draft-ietf-acme-acme-08.txt 
ACME Working Group R. Barnes ACME Working Group R. Barnes
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track J. Hoffman-Andrews Intended status: Standards Track J. Hoffman-Andrews
Expires: December 23, 2017 EFF Expires: May 3, 2018 EFF
J. Kasten J. Kasten
University of Michigan University of Michigan
June 21, 2017 October 30, 2017
Automatic Certificate Management Environment (ACME) Automatic Certificate Management Environment (ACME)
draft-ietf-acme-acme-07 draft-ietf-acme-acme-08
Abstract Abstract
Certificates in PKI using X.509 (PKIX) are used for a number of Certificates in PKI using X.509 (PKIX) are used for a number of
purposes, the most significant of which is the authentication of purposes, the most significant of which is the authentication of
domain names. Thus, certificate authorities in the Web PKI are domain names. Thus, certificate authorities in the Web PKI are
trusted to verify that an applicant for a certificate legitimately trusted to verify that an applicant for a certificate legitimately
represents the domain name(s) in the certificate. Today, this represents the domain name(s) in the certificate. Today, this
verification is done through a collection of ad hoc mechanisms. This verification is done through a collection of ad hoc mechanisms. This
document describes a protocol that a certification authority (CA) and document describes a protocol that a certification authority (CA) and
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 23, 2017. This Internet-Draft will expire on May 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 29 skipping to change at page 2, line 29
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Deployment Model and Operator Experience . . . . . . . . . . 5 2. Deployment Model and Operator Experience . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
5. Character Encoding . . . . . . . . . . . . . . . . . . . . . 8 5. Character Encoding . . . . . . . . . . . . . . . . . . . . . 8
6. Message Transport . . . . . . . . . . . . . . . . . . . . . . 8 6. Message Transport . . . . . . . . . . . . . . . . . . . . . . 9
6.1. HTTPS Requests . . . . . . . . . . . . . . . . . . . . . 9 6.1. HTTPS Requests . . . . . . . . . . . . . . . . . . . . . 9
6.2. Request Authentication . . . . . . . . . . . . . . . . . 9 6.2. Request Authentication . . . . . . . . . . . . . . . . . 10
6.3. Request URL Integrity . . . . . . . . . . . . . . . . . . 10 6.3. Request URL Integrity . . . . . . . . . . . . . . . . . . 11
6.3.1. "url" (URL) JWS header parameter . . . . . . . . . . 11 6.3.1. "url" (URL) JWS header parameter . . . . . . . . . . 11
6.4. Replay protection . . . . . . . . . . . . . . . . . . . . 11 6.4. Replay protection . . . . . . . . . . . . . . . . . . . . 12
6.4.1. Replay-Nonce . . . . . . . . . . . . . . . . . . . . 12 6.4.1. Replay-Nonce . . . . . . . . . . . . . . . . . . . . 12
6.4.2. "nonce" (Nonce) JWS header parameter . . . . . . . . 12 6.4.2. "nonce" (Nonce) JWS header parameter . . . . . . . . 13
6.5. Rate limits . . . . . . . . . . . . . . . . . . . . . . . 13 6.5. Rate limits . . . . . . . . . . . . . . . . . . . . . . . 13
6.6. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.6. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Certificate Management . . . . . . . . . . . . . . . . . . . 15 7. Certificate Management . . . . . . . . . . . . . . . . . . . 15
7.1. Resources . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. Resources . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1.1. Directory . . . . . . . . . . . . . . . . . . . . . . 17 7.1.1. Directory . . . . . . . . . . . . . . . . . . . . . . 18
7.1.2. Account Objects . . . . . . . . . . . . . . . . . . . 19 7.1.2. Account Objects . . . . . . . . . . . . . . . . . . . 19
7.1.3. Order Objects . . . . . . . . . . . . . . . . . . . . 20 7.1.3. Order Objects . . . . . . . . . . . . . . . . . . . . 20
7.1.4. Authorization Objects . . . . . . . . . . . . . . . . 21 7.1.4. Authorization Objects . . . . . . . . . . . . . . . . 22
7.2. Getting a Nonce . . . . . . . . . . . . . . . . . . . . . 23 7.2. Getting a Nonce . . . . . . . . . . . . . . . . . . . . . 23
7.3. Account Creation . . . . . . . . . . . . . . . . . . . . 24 7.3. Account Creation . . . . . . . . . . . . . . . . . . . . 24
7.3.1. Finding an Account URL Given a Key . . . . . . . . . 26 7.3.1. Finding an Account URL Given a Key . . . . . . . . . 26
7.3.2. Account Update . . . . . . . . . . . . . . . . . . . 26 7.3.2. Account Update . . . . . . . . . . . . . . . . . . . 27
7.3.3. Account Information . . . . . . . . . . . . . . . . . 27 7.3.3. Account Information . . . . . . . . . . . . . . . . . 27
7.3.4. Changes of Terms of Service . . . . . . . . . . . . . 27 7.3.4. Changes of Terms of Service . . . . . . . . . . . . . 27
7.3.5. External Account Binding . . . . . . . . . . . . . . 27 7.3.5. External Account Binding . . . . . . . . . . . . . . 28
7.3.6. Account Key Roll-over . . . . . . . . . . . . . . . . 30 7.3.6. Account Key Roll-over . . . . . . . . . . . . . . . . 30
7.3.7. Account Deactivation . . . . . . . . . . . . . . . . 32 7.3.7. Account Deactivation . . . . . . . . . . . . . . . . 32
7.4. Applying for Certificate Issuance . . . . . . . . . . . . 33 7.4. Applying for Certificate Issuance . . . . . . . . . . . . 33
7.4.1. Pre-Authorization . . . . . . . . . . . . . . . . . . 36 7.4.1. Pre-Authorization . . . . . . . . . . . . . . . . . . 36
7.4.2. Downloading the Certificate . . . . . . . . . . . . . 38 7.4.2. Downloading the Certificate . . . . . . . . . . . . . 38
7.5. Identifier Authorization . . . . . . . . . . . . . . . . 39 7.5. Identifier Authorization . . . . . . . . . . . . . . . . 39
7.5.1. Responding to Challenges . . . . . . . . . . . . . . 40 7.5.1. Responding to Challenges . . . . . . . . . . . . . . 40
7.5.2. Deactivating an Authorization . . . . . . . . . . . . 42 7.5.2. Deactivating an Authorization . . . . . . . . . . . . 42
7.6. Certificate Revocation . . . . . . . . . . . . . . . . . 43 7.6. Certificate Revocation . . . . . . . . . . . . . . . . . 43
8. Identifier Validation Challenges . . . . . . . . . . . . . . 45 8. Identifier Validation Challenges . . . . . . . . . . . . . . 45
skipping to change at page 3, line 35 skipping to change at page 3, line 35
9.3. Replay-Nonce HTTP Header . . . . . . . . . . . . . . . . 56 9.3. Replay-Nonce HTTP Header . . . . . . . . . . . . . . . . 56
9.4. "url" JWS Header Parameter . . . . . . . . . . . . . . . 56 9.4. "url" JWS Header Parameter . . . . . . . . . . . . . . . 56
9.5. "nonce" JWS Header Parameter . . . . . . . . . . . . . . 57 9.5. "nonce" JWS Header Parameter . . . . . . . . . . . . . . 57
9.6. URN Sub-namespace for ACME (urn:ietf:params:acme) . . . . 57 9.6. URN Sub-namespace for ACME (urn:ietf:params:acme) . . . . 57
9.7. New Registries . . . . . . . . . . . . . . . . . . . . . 57 9.7. New Registries . . . . . . . . . . . . . . . . . . . . . 57
9.7.1. Fields in Account Objects . . . . . . . . . . . . . . 58 9.7.1. Fields in Account Objects . . . . . . . . . . . . . . 58
9.7.2. Fields in Order Objects . . . . . . . . . . . . . . . 59 9.7.2. Fields in Order Objects . . . . . . . . . . . . . . . 59
9.7.3. Error Types . . . . . . . . . . . . . . . . . . . . . 60 9.7.3. Error Types . . . . . . . . . . . . . . . . . . . . . 60
9.7.4. Resource Types . . . . . . . . . . . . . . . . . . . 60 9.7.4. Resource Types . . . . . . . . . . . . . . . . . . . 60
9.7.5. Identifier Types . . . . . . . . . . . . . . . . . . 61 9.7.5. Identifier Types . . . . . . . . . . . . . . . . . . 61
9.7.6. Challenge Types . . . . . . . . . . . . . . . . . . . 61 9.7.6. Validation Methods . . . . . . . . . . . . . . . . . 61
10. Security Considerations . . . . . . . . . . . . . . . . . . . 62 10. Security Considerations . . . . . . . . . . . . . . . . . . . 63
10.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 63 10.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 63
10.2. Integrity of Authorizations . . . . . . . . . . . . . . 64 10.2. Integrity of Authorizations . . . . . . . . . . . . . . 64
10.3. Denial-of-Service Considerations . . . . . . . . . . . . 66 10.3. Denial-of-Service Considerations . . . . . . . . . . . . 66
10.4. Server-Side Request Forgery . . . . . . . . . . . . . . 67 10.4. Server-Side Request Forgery . . . . . . . . . . . . . . 67
10.5. CA Policy Considerations . . . . . . . . . . . . . . . . 67 10.5. CA Policy Considerations . . . . . . . . . . . . . . . . 68
11. Operational Considerations . . . . . . . . . . . . . . . . . 68 11. Operational Considerations . . . . . . . . . . . . . . . . . 68
11.1. DNS security . . . . . . . . . . . . . . . . . . . . . . 68 11.1. DNS security . . . . . . . . . . . . . . . . . . . . . . 69
11.2. Default Virtual Hosts . . . . . . . . . . . . . . . . . 69 11.2. Default Virtual Hosts . . . . . . . . . . . . . . . . . 69
11.3. Token Entropy . . . . . . . . . . . . . . . . . . . . . 69 11.3. Token Entropy . . . . . . . . . . . . . . . . . . . . . 70
11.4. Malformed Certificate Chains . . . . . . . . . . . . . . 70 11.4. Malformed Certificate Chains . . . . . . . . . . . . . . 70
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 70 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 71
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 71 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 71
13.1. Normative References . . . . . . . . . . . . . . . . . . 71 13.1. Normative References . . . . . . . . . . . . . . . . . . 71
13.2. Informative References . . . . . . . . . . . . . . . . . 73 13.2. Informative References . . . . . . . . . . . . . . . . . 74
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 75
1. Introduction 1. Introduction
Certificates [RFC5280] in the Web PKI are most commonly used to Certificates [RFC5280] in the Web PKI are most commonly used to
authenticate domain names. Thus, certificate authorities in the Web authenticate domain names. Thus, certificate authorities in the Web
PKI are trusted to verify that an applicant for a certificate PKI are trusted to verify that an applicant for a certificate
legitimately represents the domain name(s) in the certificate. legitimately represents the domain name(s) in the certificate.
Different types of certificates reflect different kinds of CA Different types of certificates reflect different kinds of CA
verification of information about the certificate subject. "Domain verification of information about the certificate subject. "Domain
skipping to change at page 5, line 17 skipping to change at page 5, line 17
systems because it inhibits mechanization of tasks related to systems because it inhibits mechanization of tasks related to
certificate issuance, deployment, and revocation. certificate issuance, deployment, and revocation.
This document describes an extensible framework for automating the This document describes an extensible framework for automating the
issuance and domain validation procedure, thereby allowing servers issuance and domain validation procedure, thereby allowing servers
and infrastructural software to obtain certificates without user and infrastructural software to obtain certificates without user
interaction. Use of this protocol should radically simplify the interaction. Use of this protocol should radically simplify the
deployment of HTTPS and the practicality of PKIX authentication for deployment of HTTPS and the practicality of PKIX authentication for
other protocols based on Transport Layer Security (TLS) [RFC5246]. other protocols based on Transport Layer Security (TLS) [RFC5246].
It should be noted that while the focus of this document is on
validating domain names for purposes of issuing certificates in the
Web PKI, ACME supports extensions for uses with other identifiers in
other PKI contexts. For example, as of this writing, there is
ongoing work to use ACME for issuance of WebPKI certificates
attesting to IP addresses [I-D.ietf-acme-ip] and STIR certificates
attesting to telephone numbers [I-D.ietf-acme-telephone].
2. Deployment Model and Operator Experience 2. Deployment Model and Operator Experience
The guiding use case for ACME is obtaining certificates for websites The guiding use case for ACME is obtaining certificates for websites
(HTTPS [RFC2818]). In this case, the user's web server is intended (HTTPS [RFC2818]). In this case, the user's web server is intended
to speak for one or more domains, and the process of certificate to speak for one or more domains, and the process of certificate
issuance is intended to verify that this web server actually speaks issuance is intended to verify that this web server actually speaks
for the domain(s). for the domain(s).
DV certificate validation commonly checks claims about properties DV certificate validation commonly checks claims about properties
related to control of a domain name - properties that can be observed related to control of a domain name - properties that can be observed
skipping to change at page 6, line 21 skipping to change at page 6, line 28
o The ACME client periodically contacts the CA to get updated o The ACME client periodically contacts the CA to get updated
certificates, stapled OCSP responses, or whatever else would be certificates, stapled OCSP responses, or whatever else would be
required to keep the web server functional and its credentials up- required to keep the web server functional and its credentials up-
to-date. to-date.
In this way, it would be nearly as easy to deploy with a CA-issued In this way, it would be nearly as easy to deploy with a CA-issued
certificate as with a self-signed certificate. Furthermore, the certificate as with a self-signed certificate. Furthermore, the
maintenance of that CA-issued certificate would require minimal maintenance of that CA-issued certificate would require minimal
manual intervention. Such close integration of ACME with HTTPS manual intervention. Such close integration of ACME with HTTPS
servers would allow the immediate and automated deployment of servers allows the immediate and automated deployment of certificates
certificates as they are issued, sparing the human administrator from as they are issued, sparing the human administrator from much of the
much of the time-consuming work described in the previous section. time-consuming work described in the previous section.
3. Terminology 3. 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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
The two main roles in ACME are "client" and "server". The ACME The two main roles in ACME are "client" and "server". The ACME
client uses the protocol to request certificate management actions, client uses the protocol to request certificate management actions,
such as issuance or revocation. An ACME client may run on a web such as issuance or revocation. An ACME client may run on a web
skipping to change at page 9, line 17 skipping to change at page 9, line 27
Each ACME function is accomplished by the client sending a sequence Each ACME function is accomplished by the client sending a sequence
of HTTPS requests to the server, carrying JSON messages of HTTPS requests to the server, carrying JSON messages
[RFC2818][RFC7159]. Use of HTTPS is REQUIRED. Each subsection of [RFC2818][RFC7159]. Use of HTTPS is REQUIRED. Each subsection of
Section 7 below describes the message formats used by the function Section 7 below describes the message formats used by the function
and the order in which messages are sent. and the order in which messages are sent.
In most HTTPS transactions used by ACME, the ACME client is the HTTPS In most HTTPS transactions used by ACME, the ACME client is the HTTPS
client and the ACME server is the HTTPS server. The ACME server acts client and the ACME server is the HTTPS server. The ACME server acts
as an HTTP and HTTPS client when validating challenges via HTTP. as an HTTP and HTTPS client when validating challenges via HTTP.
ACME servers SHOULD follow the recommendations of [RFC7525] when
configuring their TLS implementations. ACME servers that support TLS
1.3 MAY allow clients to send early data (0xRTT). This is safe
because the ACME protocol itself includes anti-replay protections.
ACME clients SHOULD send a User-Agent header in accordance with ACME clients SHOULD send a User-Agent header in accordance with
[RFC7231], including the name and version of the ACME software in [RFC7231], including the name and version of the ACME software in
addition to the name and version of the underlying HTTP client addition to the name and version of the underlying HTTP client
software. software.
ACME clients SHOULD send an Accept-Language header in accordance with ACME clients SHOULD send an Accept-Language header in accordance with
[RFC7231] to enable localization of error messages. [RFC7231] to enable localization of error messages.
ACME servers that are intended to be generally accessible need to use ACME servers that are intended to be generally accessible need to use
Cross-Origin Resource Sharing (CORS) in order to be accessible from Cross-Origin Resource Sharing (CORS) in order to be accessible from
skipping to change at page 13, line 16 skipping to change at page 13, line 35
Creation of resources can be rate limited to ensure fair usage and Creation of resources can be rate limited to ensure fair usage and
prevent abuse. Once the rate limit is exceeded, the server MUST prevent abuse. Once the rate limit is exceeded, the server MUST
respond with an error with the type respond with an error with the type
"urn:ietf:params:acme:error:rateLimited". Additionally, the server "urn:ietf:params:acme:error:rateLimited". Additionally, the server
SHOULD send a "Retry-After" header indicating when the current SHOULD send a "Retry-After" header indicating when the current
request may succeed again. If multiple rate limits are in place, request may succeed again. If multiple rate limits are in place,
that is the time where all rate limits allow access again for the that is the time where all rate limits allow access again for the
current request with exactly the same parameters. current request with exactly the same parameters.
In addition to the human readable "detail" field of the error In addition to the human-readable "detail" field of the error
response, the server MAY send one or multiple tokens in the "Link" response, the server MAY send one or multiple tokens in the "Link"
header pointing to documentation about the specific hit rate limits header pointing to documentation about the specific hit rate limits
using the "urn:ietf:params:acme:documentation" relation. using the "urn:ietf:params:acme:documentation" relation.
6.6. Errors 6.6. Errors
Errors can be reported in ACME both at the HTTP layer and within Errors can be reported in ACME both at the HTTP layer and within
challenge objects as defined in Section 8. ACME servers can return challenge objects as defined in Section 8. ACME servers can return
responses with an HTTP error response code (4XX or 5XX). For responses with an HTTP error response code (4XX or 5XX). For
example: If the client submits a request using a method not allowed example: If the client submits a request using a method not allowed
skipping to change at page 22, line 30 skipping to change at page 23, line 7
the CA MUST consider this authorization valid for all orders until the CA MUST consider this authorization valid for all orders until
the authorization expires. the authorization expires.
challenges (required, array of objects): For pending authorizations, challenges (required, array of objects): For pending authorizations,
the challenges that the client can fulfill in order to prove the challenges that the client can fulfill in order to prove
possession of the identifier. For final authorizations, the possession of the identifier. For final authorizations, the
challenges that were used. Each array entry is an object with challenges that were used. Each array entry is an object with
parameters required to validate the challenge. A client should parameters required to validate the challenge. A client should
attempt to fulfill one of these challenges, and a server should attempt to fulfill one of these challenges, and a server should
consider any one of the challenges sufficient to make the consider any one of the challenges sufficient to make the
authorization valid. For final authorizations it contains the authorization valid. For final authorizations, it contains the
challenges that were successfully completed. challenges that were successfully completed.
The only type of identifier defined by this specification is a fully- The only type of identifier defined by this specification is a fully-
qualified domain name (type: "dns"). If a domain name contains non- qualified domain name (type: "dns"). If a domain name contains non-
ASCII Unicode characters it MUST be encoded using the rules defined ASCII Unicode characters it MUST be encoded using the rules defined
in [RFC3492]. Servers MUST verify any identifier values that begin in [RFC3492]. Servers MUST verify any identifier values that begin
with the ASCII Compatible Encoding prefix "xn-" as defined in with the ASCII Compatible Encoding prefix "xn-" as defined in
[RFC5890] are properly encoded. Wildcard domain names (with "*" as [RFC5890] are properly encoded. Wildcard domain names (with "*" as
the first label) MUST NOT be included in authorization objects. the first label) MUST NOT be included in authorization objects.
skipping to change at page 25, line 12 skipping to change at page 25, line 39
the specification of those fields MUST describe whether they can be the specification of those fields MUST describe whether they can be
provided by the client. provided by the client.
In general, the server MUST ignore any fields in the request object In general, the server MUST ignore any fields in the request object
that it does not recognize. In particular, it MUST NOT reflect that it does not recognize. In particular, it MUST NOT reflect
unrecognized fields in the resulting account object. This allows unrecognized fields in the resulting account object. This allows
clients to detect when servers do not support an extension field. clients to detect when servers do not support an extension field.
The server SHOULD validate that the contact URLs in the "contact" The server SHOULD validate that the contact URLs in the "contact"
field are valid and supported by the server. If the server validates field are valid and supported by the server. If the server validates
contact URLs it MUST support the "mailto" scheme. If the server contact URLs it MUST support the "mailto" scheme. Clients MUST NOT
rejects a contact URL for using an unsupported scheme it MUST return provide a "mailto" URL in the "contact" field that contains "hfields"
an error of type "unsupportedContact", with a description describing [RFC6068], or more than one "addr-spec" in the "to" component. If a
the error and what types of contact URLs the server considers server encounters a "mailto" contact URL that does not meet these
acceptable. If the server rejects a contact URL for using a criteria, then it SHOULD reject it as invalid.
supported scheme but an invalid value then the server MUST return an
error of type "invalidContact". If the server rejects a contact URL for using an unsupported scheme
it MUST return an error of type "unsupportedContact", with a
description describing the error and what types of contact URLs the
server considers acceptable. If the server rejects a contact URL for
using a supported scheme but an invalid value then the server MUST
return an error of type "invalidContact".
If the server wishes to present the client with terms under which the If the server wishes to present the client with terms under which the
ACME service is to be used, it MUST indicate the URL where such terms ACME service is to be used, it MUST indicate the URL where such terms
can be accessed in the "terms-of-service" subfield of the "meta" can be accessed in the "terms-of-service" subfield of the "meta"
field in the directory object, and the server MUST reject new-account field in the directory object, and the server MUST reject new-account
requests that do not have the "terms-of-service-agreed" set to requests that do not have the "terms-of-service-agreed" set to
"true". Clients SHOULD NOT automatically agree to terms by default. "true". Clients SHOULD NOT automatically agree to terms by default.
Rather, they SHOULD require some user interaction for agreement to Rather, they SHOULD require some user interaction for agreement to
terms. terms.
skipping to change at page 32, line 19 skipping to change at page 32, line 19
verifies the inner JWS. verifies the inner JWS.
9. Check that no account exists whose account key is the same as the 9. Check that no account exists whose account key is the same as the
key in the "newKey" field. key in the "newKey" field.
If all of these checks pass, then the server updates the If all of these checks pass, then the server updates the
corresponding account by replacing the old account key with the new corresponding account by replacing the old account key with the new
public key and returns status code 200 (OK). Otherwise, the server public key and returns status code 200 (OK). Otherwise, the server
responds with an error status code and a problem document describing responds with an error status code and a problem document describing
the error. If there is an existing account with the new key the error. If there is an existing account with the new key
provided, then the server SHOULD use status code 409 (Conflict). provided, then the server SHOULD use status code 409 (Conflict) and
provide the URL of that account in the Location header field.
Note that changing the account key for an account SHOULD NOT have any Note that changing the account key for an account SHOULD NOT have any
other impact on the account. For example, the server MUST NOT other impact on the account. For example, the server MUST NOT
invalidate pending orders or authorization transactions based on a invalidate pending orders or authorization transactions based on a
change of account key. change of account key.
7.3.7. Account Deactivation 7.3.7. Account Deactivation
A client can deactivate an account by posting a signed update to the A client can deactivate an account by posting a signed update to the
server with a status field of "deactivated." Clients may wish to do server with a status field of "deactivated." Clients may wish to do
skipping to change at page 41, line 20 skipping to change at page 41, line 20
Content-Type: application/jose+json Content-Type: application/jose+json
{ {
"protected": base64url({ "protected": base64url({
"alg": "ES256", "alg": "ES256",
"kid": "https://example.com/acme/acct/1", "kid": "https://example.com/acme/acct/1",
"nonce": "Q_s3MWoqT05TrdkM2MTDcw", "nonce": "Q_s3MWoqT05TrdkM2MTDcw",
"url": "https://example.com/acme/authz/1234/0" "url": "https://example.com/acme/authz/1234/0"
}), }),
"payload": base64url({ "payload": base64url({
"type": "http-01",
"keyAuthorization": "IlirfxKKXA...vb29HhjjLPSggwiE" "keyAuthorization": "IlirfxKKXA...vb29HhjjLPSggwiE"
}), }),
"signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ" "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ"
} }
The server updates the authorization document by updating its The server updates the authorization document by updating its
representation of the challenge with the response fields provided by representation of the challenge with the response fields provided by
the client. The server MUST ignore any fields in the response object the client. The server MUST ignore any fields in the response object
that are not specified as response fields for this type of challenge. that are not specified as response fields for this type of challenge.
The server provides a 200 (OK) response with the updated challenge The server provides a 200 (OK) response with the updated challenge
skipping to change at page 47, line 51 skipping to change at page 47, line 51
client via the "errors" field in the challenge and the Retry-After client via the "errors" field in the challenge and the Retry-After
HTTP header field in response to requests to the challenge resource. HTTP header field in response to requests to the challenge resource.
The server MUST add an entry to the "errors" field in the challenge The server MUST add an entry to the "errors" field in the challenge
after each failed validation query. The server SHOULD set the Retry- after each failed validation query. The server SHOULD set the Retry-
After header field to a time after the server's next validation After header field to a time after the server's next validation
query, since the status of the challenge will not change until that query, since the status of the challenge will not change until that
time. time.
Clients can explicitly request a retry by re-sending their response Clients can explicitly request a retry by re-sending their response
to a challenge in a new POST request (with a new nonce, etc.). This to a challenge in a new POST request (with a new nonce, etc.). This
allows clients to request a retry when state has changed (e.g., after allows clients to request a retry when the state has changed (e.g.,
firewall rules have been updated). Servers SHOULD retry a request after firewall rules have been updated). Servers SHOULD retry a
immediately on receiving such a POST request. In order to avoid request immediately on receiving such a POST request. In order to
denial-of-service attacks via client-initiated retries, servers avoid denial-of-service attacks via client-initiated retries, servers
SHOULD rate-limit such requests. SHOULD rate-limit such requests.
8.3. HTTP Challenge 8.3. HTTP Challenge
With HTTP validation, the client in an ACME transaction proves its With HTTP validation, the client in an ACME transaction proves its
control over a domain name by proving that for that domain name it control over a domain name by proving that for that domain name it
can provision resources to be returned by an HTTP server. The ACME can provision resources to be returned by an HTTP server. The ACME
server challenges the client to provision a file at a specific path, server challenges the client to provision a file at a specific path,
with a specific string as its content. with a specific string as its content.
skipping to change at page 48, line 48 skipping to change at page 48, line 48
"token": "LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0" "token": "LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0"
} }
A client responds to this challenge by constructing a key A client responds to this challenge by constructing a key
authorization from the "token" value provided in the challenge and authorization from the "token" value provided in the challenge and
the client's account key. The client then provisions the key the client's account key. The client then provisions the key
authorization as a resource on the HTTP server for the domain in authorization as a resource on the HTTP server for the domain in
question. question.
The path at which the resource is provisioned is comprised of the The path at which the resource is provisioned is comprised of the
fixed prefix ".well-known/acme-challenge/", followed by the "token" fixed prefix "/.well-known/acme-challenge/", followed by the "token"
value in the challenge. The value of the resource MUST be the ASCII value in the challenge. The value of the resource MUST be the ASCII
representation of the key authorization. representation of the key authorization.
GET .well-known/acme-challenge/LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0 GET /.well-known/acme-challenge/LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0
Host: example.org Host: example.org
HTTP/1.1 200 OK HTTP/1.1 200 OK
LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0.9jg46WB3rR_AHD-EBXdN7cBkH1WOu0tA3M9fm21mqTI LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0.9jg46WB3rR_AHD-EBXdN7cBkH1WOu0tA3M9fm21mqTI
The client's response to this challenge indicates its agreement to The client's response to this challenge indicates its agreement to
this challenge by sending the server the key authorization covering this challenge by sending the server the key authorization covering
the challenge's token and the client's account key. the challenge's token and the client's account key.
keyAuthorization (required, string): The key authorization for this keyAuthorization (required, string): The key authorization for this
skipping to change at page 54, line 9 skipping to change at page 54, line 9
challenge and the client's account key. If they do not match, then challenge and the client's account key. If they do not match, then
the server MUST return an HTTP error in response to the POST request the server MUST return an HTTP error in response to the POST request
in which the client sent the challenge. in which the client sent the challenge.
To validate a DNS challenge, the server performs the following steps: To validate a DNS challenge, the server performs the following steps:
1. Compute the SHA-256 digest [FIPS180-4] of the key authorization 1. Compute the SHA-256 digest [FIPS180-4] of the key authorization
2. Query for TXT records for the validation domain name 2. Query for TXT records for the validation domain name
3. Verify that the contents of one of the TXT records matches the 3. Verify that the contents of one of the TXT records match the
digest value digest value
If all of the above verifications succeed, then the validation is If all of the above verifications succeed, then the validation is
successful. If no DNS record is found, or DNS record and response successful. If no DNS record is found, or DNS record and response
payload do not pass these checks, then the validation fails. payload do not pass these checks, then the validation fails.
8.6. Out-of-Band Challenge 8.6. Out-of-Band Challenge
There may be cases where a server cannot perform automated validation There may be cases where a server cannot perform automated validation
of an identifier, for example, if validation requires some manual of an identifier, for example, if validation requires some manual
skipping to change at page 56, line 4 skipping to change at page 56, line 4
Encoding considerations: None Encoding considerations: None
Security considerations: Carries a cryptographic certificate and its Security considerations: Carries a cryptographic certificate and its
associated certificate chain associated certificate chain
Interoperability considerations: None Interoperability considerations: None
Published specification: draft-ietf-acme-acme [[ RFC EDITOR: Please Published specification: draft-ietf-acme-acme [[ RFC EDITOR: Please
replace draft-ietf-acme-acme above with the RFC number assigned to replace draft-ietf-acme-acme above with the RFC number assigned to
this ]] this ]]
Applications which use this media type: Any MIME-complaint transport Applications which use this media type: Any MIME-compliant transport
Additional information: Additional information:
File should contain one or more certificates encoded as PEM according File should contain one or more certificates encoded as PEM according
to RFC 7468 [RFC7468]. In order to provide easy interoperation with to RFC 7468 [RFC7468]. In order to provide easy interoperation with
TLS, the first certificate MUST be an end-entity certificate. Each TLS, the first certificate MUST be an end-entity certificate. Each
following certificate SHOULD directly certify one preceding it. following certificate SHOULD directly certify one preceding it.
Because certificate validation requires that trust anchors be Because certificate validation requires that trust anchors be
distributed independently, a certificate that specifies a trust distributed independently, a certificate that specifies a trust
anchor MAY be omitted from the chain, provided that supported peers anchor MAY be omitted from the chain, provided that supported peers
skipping to change at page 58, line 12 skipping to change at page 58, line 12
1. ACME Account Object Fields (Section 9.7.1) 1. ACME Account Object Fields (Section 9.7.1)
2. ACME Order Object Fields (Section 9.7.2) 2. ACME Order Object Fields (Section 9.7.2)
3. ACME Error Types (Section 9.7.3) 3. ACME Error Types (Section 9.7.3)
4. ACME Resource Types (Section 9.7.4) 4. ACME Resource Types (Section 9.7.4)
5. ACME Identifier Types (Section 9.7.5) 5. ACME Identifier Types (Section 9.7.5)
6. ACME Challenge Types (Section 9.7.6) 6. ACME Validation Methods (Section 9.7.6)
All of these registries are under a heading of "Automated Certificate All of these registries are under a heading of "Automated Certificate
Management Environment (ACME) Protocol" and are administered under a Management Environment (ACME) Protocol" and are administered under a
Specification Required policy [RFC5226]. Specification Required policy [RFC8126].
9.7.1. Fields in Account Objects 9.7.1. Fields in Account Objects
This registry lists field names that are defined for use in ACME This registry lists field names that are defined for use in ACME
account objects. Fields marked as "configurable" may be included in account objects. Fields marked as "configurable" may be included in
a new-account request. a new-account request.
Template: Template:
o Field name: The string to be used as a field name in the JSON o Field name: The string to be used as a field name in the JSON
skipping to change at page 61, line 46 skipping to change at page 61, line 46
+-------+-----------+ +-------+-----------+
| Label | Reference | | Label | Reference |
+-------+-----------+ +-------+-----------+
| dns | RFC XXXX | | dns | RFC XXXX |
+-------+-----------+ +-------+-----------+
[[ RFC EDITOR: Please replace XXXX above with the RFC number assigned [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned
to this document ]] to this document ]]
9.7.6. Challenge Types 9.7.6. Validation Methods
This registry lists the ways that ACME servers can offer to validate This registry lists identifiers for the ways that CAs can validate
control of an identifier. The "Identifier Type" field in the control of identifiers. Each method's entry must specify whether it
template must be contained in the Label column of the ACME Identifier corresponds to an ACME challenge type. The "Identifier Type" field
Types registry. must be contained in the Label column of the ACME Identifier Types
registry.
Template: Template:
o Label: The value to be put in the "type" field of challenge o Label: The identifier for this validation method
objects using this validation mechanism
o Identifier Type: The type of identifier that this mechanism o Identifier Type: The type of identifier that this method applies
applies to to
o Reference: Where the challenge type is defined o ACME: "Y" if the validation method corresponds to an ACME
challenge type; "N" otherwise.
o Reference: Where the validation method is defined
Initial Contents Initial Contents
+------------+-----------------+-----------+ +------------+-----------------+------+-----------+
| Label | Identifier Type | Reference | | Label | Identifier Type | ACME | Reference |
+------------+-----------------+-----------+ +------------+-----------------+------+-----------+
| http-01 | dns | RFC XXXX | | http-01 | dns | Y | RFC XXXX |
| | | | | | | | |
| tls-sni-02 | dns | RFC XXXX | | tls-sni-02 | dns | Y | RFC XXXX |
| | | | | | | | |
| dns-01 | dns | RFC XXXX | | dns-01 | dns | Y | RFC XXXX |
| | | | | | | | |
| oob-01 | dns | RFC XXXX | | oob-01 | dns | Y | RFC XXXX |
+------------+-----------------+-----------+ +------------+-----------------+------+-----------+
When evaluating a request for an assignment in this registry, the
designated expert should ensure that the method being registered has
a clear, interoperable definition and does not overlap with existing
validation methods. That is, it should not be possible for a client
and server to follow take the same set of actions to fulfill two
different validation mechanisms.
Validation methods do not have to be compatible with ACME in order to
be registered. For example, a CA might wish to register a validation
method in order to support its use with the ACME extensions to CAA
[I-D.ietf-acme-caa].
[[ RFC EDITOR: Please replace XXXX above with the RFC number assigned [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned
to this document ]] to this document ]]
10. Security Considerations 10. Security Considerations
ACME is a protocol for managing certificates that attest to ACME is a protocol for managing certificates that attest to
identifier/key bindings. Thus the foremost security goal of ACME is identifier/key bindings. Thus the foremost security goal of ACME is
to ensure the integrity of this process, i.e., to ensure that the to ensure the integrity of this process, i.e., to ensure that the
bindings attested by certificates are correct and that only bindings attested by certificates are correct and that only
skipping to change at page 64, line 43 skipping to change at page 65, line 14
o ACME server performs validation query and sees the response o ACME server performs validation query and sees the response
provisioned by the legitimate domain holder provisioned by the legitimate domain holder
o Because the challenges were issued in response to a message signed o Because the challenges were issued in response to a message signed
account key B, the ACME server grants authorization to account key account key B, the ACME server grants authorization to account key
B (the MitM) instead of account key A (the legitimate domain B (the MitM) instead of account key A (the legitimate domain
holder) holder)
All of the challenges above have a binding between the account All of the challenges above have a binding between the account
private key and the validation query made by the server, via the key private key and the validation query made by the server, via the key
authorization. The key authorization is signed by the account authorization. The key authorization reflects the account public
private key, reflects the corresponding public key, and is provided key, is provided to the server in the validation response over the
to the server in the validation response. validation channel and signed afterwards by the corresponding private
key in the challenge response over the ACME channel.
The association of challenges to identifiers is typically done by The association of challenges to identifiers is typically done by
requiring the client to perform some action that only someone who requiring the client to perform some action that only someone who
effectively controls the identifier can perform. For the challenges effectively controls the identifier can perform. For the challenges
in this document, the actions are: in this document, the actions are:
o HTTP: Provision files under .well-known on a web server for the o HTTP: Provision files under .well-known on a web server for the
domain domain
o TLS SNI: Configure a TLS server for the domain o TLS SNI: Configure a TLS server for the domain
o DNS: Provision DNS resource records for the domain o DNS: Provision DNS resource records for the domain
There are several ways that these assumptions can be violated, both There are several ways that these assumptions can be violated, both
by misconfiguration and by attacks. For example, on a web server by misconfiguration and by attacks. For example, on a web server
that allows non-administrative users to write to .well-known, any that allows non-administrative users to write to .well-known, any
user can claim to own the web server's hostname by responding to an user can claim to own the web server's hostname by responding to an
HTTP challenge, and likewise for TLS configuration and TLS SNI. HTTP challenge, and likewise for TLS configuration and TLS SNI.
Similarly, if a server that can be used for ACME validation is
compromised by a malicious actor, then that malicious actor can use
that access to obtain certificates via ACME.
The use of hosting providers is a particular risk for ACME The use of hosting providers is a particular risk for ACME
validation. If the owner of the domain has outsourced operation of validation. If the owner of the domain has outsourced operation of
DNS or web services to a hosting provider, there is nothing that can DNS or web services to a hosting provider, there is nothing that can
be done against tampering by the hosting provider. As far as the be done against tampering by the hosting provider. As far as the
outside world is concerned, the zone or website provided by the outside world is concerned, the zone or website provided by the
hosting provider is the real thing. hosting provider is the real thing.
More limited forms of delegation can also lead to an unintended party More limited forms of delegation can also lead to an unintended party
gaining the ability to successfully complete a validation gaining the ability to successfully complete a validation
skipping to change at page 68, line 4 skipping to change at page 68, line 26
o Is the claimed identifier syntactically valid? o Is the claimed identifier syntactically valid?
o For domain names: o For domain names:
* If the leftmost label is a '*', then have the appropriate * If the leftmost label is a '*', then have the appropriate
checks been applied? checks been applied?
* Is the name on the Public Suffix List? * Is the name on the Public Suffix List?
* Is the name a high-value name? * Is the name a high-value name?
* Is the name a known phishing domain? * Is the name a known phishing domain?
o Is the key in the CSR sufficiently strong? o Is the key in the CSR sufficiently strong?
o Is the CSR signed with an acceptable algorithm? o Is the CSR signed with an acceptable algorithm?
o Has issuance been authorized or forbidden by a Certficate o Has issuance been authorized or forbidden by a Certificate
Authority Authorization (CAA) record? [RFC6844] Authority Authorization (CAA) record? [RFC6844]
CAs that use ACME to automate issuance will need to ensure that their CAs that use ACME to automate issuance will need to ensure that their
servers perform all necessary checks before issuing. servers perform all necessary checks before issuing.
CAs using ACME to allow clients to agree to terms of service should CAs using ACME to allow clients to agree to terms of service should
keep in mind that ACME clients can automate this agreement, possibly keep in mind that ACME clients can automate this agreement, possibly
not involving a human user. If a CA wishes to have stronger evidence not involving a human user. If a CA wishes to have stronger evidence
of user consent, it may present an out-of-band requirement or of user consent, it may present an out-of-band requirement or
challenge to require human involvement. challenge to require human involvement.
skipping to change at page 70, line 7 skipping to change at page 70, line 31
The http-01, tls-sni-02 and dns-01 validation methods mandate the The http-01, tls-sni-02 and dns-01 validation methods mandate the
usage of a random token value to uniquely identify the challenge. usage of a random token value to uniquely identify the challenge.
The value of the token is required to contain at least 128 bits of The value of the token is required to contain at least 128 bits of
entropy for the following security properties. First, the ACME entropy for the following security properties. First, the ACME
client should not be able to influence the ACME server's choice of client should not be able to influence the ACME server's choice of
token as this may allow an attacker to reuse a domain owner's token as this may allow an attacker to reuse a domain owner's
previous challenge responses for a new validation request. Secondly, previous challenge responses for a new validation request. Secondly,
the entropy requirement prevents ACME clients from implementing a the entropy requirement prevents ACME clients from implementing a
"naive" validation server that automatically replies to challenges "naive" validation server that automatically replies to challenges
without participating in the creation of the intial authorization without participating in the creation of the initial authorization
request. request.
11.4. Malformed Certificate Chains 11.4. Malformed Certificate Chains
ACME provides certificate chains in the widely-used format known ACME provides certificate chains in the widely-used format known
colloquially as PEM (though it may diverge from the actual Privacy colloquially as PEM (though it may diverge from the actual Privacy
Enhanced Mail specifications [RFC1421], as noted in [RFC7468]). Some Enhanced Mail specifications [RFC1421], as noted in [RFC7468]). Some
current software will allow the configuration of a private key and a current software will allow the configuration of a private key and a
certificate in one PEM file, by concatenating the textual encodings certificate in one PEM file, by concatenating the textual encodings
of the two objects. In the context of ACME, such software might be of the two objects. In the context of ACME, such software might be
skipping to change at page 71, line 17 skipping to change at page 71, line 39
13.1. Normative References 13.1. Normative References
[FIPS180-4] [FIPS180-4]
Department of Commerce, National., "NIST FIPS 180-4, Department of Commerce, National., "NIST FIPS 180-4,
Secure Hash Standard", March 2012, Secure Hash Standard", March 2012,
<http://csrc.nist.gov/publications/fips/fips180-4/ <http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>. fips-180-4.pdf>.
[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-
<http://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP", Infrastructure Operational Protocols: FTP and HTTP",
RFC 2585, DOI 10.17487/RFC2585, May 1999, RFC 2585, DOI 10.17487/RFC2585, May 1999,
<http://www.rfc-editor.org/info/rfc2585>. <https://www.rfc-editor.org/info/rfc2585>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2818>. editor.org/info/rfc2818>.
[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
Classes and Attribute Types Version 2.0", RFC 2985, Classes and Attribute Types Version 2.0", RFC 2985,
DOI 10.17487/RFC2985, November 2000, DOI 10.17487/RFC2985, November 2000, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2985>. editor.org/info/rfc2985>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986, Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000, DOI 10.17487/RFC2986, November 2000, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2986>. editor.org/info/rfc2986>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<http://www.rfc-editor.org/info/rfc3339>. <https://www.rfc-editor.org/info/rfc3339>.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications for Internationalized Domain Names in Applications
(IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
<http://www.rfc-editor.org/info/rfc3492>. <https://www.rfc-editor.org/info/rfc3492>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5246>. editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010, RFC 5890, DOI 10.17487/RFC5890, August 2010,
<http://www.rfc-editor.org/info/rfc5890>. <https://www.rfc-editor.org/info/rfc5890>.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, [RFC5988] Nottingham, M., "Web Linking", RFC 5988,
DOI 10.17487/RFC5988, October 2010, DOI 10.17487/RFC5988, October 2010, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5988>. editor.org/info/rfc5988>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6066>. editor.org/info/rfc6066>.
[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,
<https://www.rfc-editor.org/info/rfc6068>.
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
and D. Orchard, "URI Template", RFC 6570, and D. Orchard, "URI Template", RFC 6570,
DOI 10.17487/RFC6570, March 2012, DOI 10.17487/RFC6570, March 2012, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6570>. editor.org/info/rfc6570>.
[RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification [RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification
Authority Authorization (CAA) Resource Record", RFC 6844, Authority Authorization (CAA) Resource Record", RFC 6844,
DOI 10.17487/RFC6844, January 2013, DOI 10.17487/RFC6844, January 2013, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6844>. editor.org/info/rfc6844>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <http://www.rfc-editor.org/info/rfc7159>. 2014, <https://www.rfc-editor.org/info/rfc7159>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7231>. editor.org/info/rfc7231>.
[RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX,
PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468,
April 2015, <http://www.rfc-editor.org/info/rfc7468>. April 2015, <https://www.rfc-editor.org/info/rfc7468>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <http://www.rfc-editor.org/info/rfc7515>. 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015, DOI 10.17487/RFC7518, May 2015, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7518>. editor.org/info/rfc7518>.
[RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK)
Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September
2015, <http://www.rfc-editor.org/info/rfc7638>. 2015, <https://www.rfc-editor.org/info/rfc7638>.
[RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP [RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP
APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016, APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016,
<http://www.rfc-editor.org/info/rfc7807>. <https://www.rfc-editor.org/info/rfc7807>.
[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, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
13.2. Informative References 13.2. Informative References
[I-D.ietf-acme-caa]
Landau, H., "CAA Record Extensions for Account URI and
ACME Method Binding", draft-ietf-acme-caa-03 (work in
progress), August 2017.
[I-D.ietf-acme-ip]
Shoemaker, R., "ACME IP Identifier Validation Extension",
draft-ietf-acme-ip-01 (work in progress), September 2017.
[I-D.ietf-acme-telephone]
Peterson, J. and R. Barnes, "ACME Identifiers and
Challenges for Telephone Numbers", draft-ietf-acme-
telephone-00 (work in progress), July 2017.
[I-D.vixie-dnsext-dns0x20] [I-D.vixie-dnsext-dns0x20]
Vixie, P. and D. Dagon, "Use of Bit 0x20 in DNS Labels to Vixie, P. and D. Dagon, "Use of Bit 0x20 in DNS Labels to
Improve Transaction Identity", draft-vixie-dnsext- Improve Transaction Identity", draft-vixie-dnsext-
dns0x20-00 (work in progress), March 2008. dns0x20-00 (work in progress), March 2008.
[RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic
Mail: Part I: Message Encryption and Authentication Mail: Part I: Message Encryption and Authentication
Procedures", RFC 1421, DOI 10.17487/RFC1421, February Procedures", RFC 1421, DOI 10.17487/RFC1421, February
1993, <http://www.rfc-editor.org/info/rfc1421>. 1993, <https://www.rfc-editor.org/info/rfc1421>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc3552>. editor.org/info/rfc3552>.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June
2003, <http://www.rfc-editor.org/info/rfc3553>. 2003, <https://www.rfc-editor.org/info/rfc3553>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785, Uniform Resource Identifiers (URIs)", RFC 5785,
DOI 10.17487/RFC5785, April 2010, DOI 10.17487/RFC5785, April 2010, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5785>. editor.org/info/rfc5785>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[W3C.CR-cors-20130129] [W3C.CR-cors-20130129]
Kesteren, A., "Cross-Origin Resource Sharing", World Wide Kesteren, A., "Cross-Origin Resource Sharing", World Wide
Web Consortium CR CR-cors-20130129, January 2013, Web Consortium CR CR-cors-20130129, January 2013,
<http://www.w3.org/TR/2013/CR-cors-20130129>. <http://www.w3.org/TR/2013/CR-cors-20130129>.
Authors' Addresses Authors' Addresses
Richard Barnes Richard Barnes
Cisco Cisco
 End of changes. 74 change blocks. 
118 lines changed or deleted 180 lines changed or added

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