draft-ietf-acme-acme-13.txt   draft-ietf-acme-acme-14.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: January 18, 2019 EFF Expires: February 11, 2019 EFF
D. McCarney D. McCarney
Let's Encrypt Let's Encrypt
J. Kasten J. Kasten
University of Michigan University of Michigan
July 17, 2018 August 10, 2018
Automatic Certificate Management Environment (ACME) Automatic Certificate Management Environment (ACME)
draft-ietf-acme-acme-13 draft-ietf-acme-acme-14
Abstract Abstract
Certificates in PKI using X.509 (PKIX) are used for a number of Public Key Infrastructure X.509 (PKIX) certificates are used for a
purposes, the most significant of which is the authentication of number of purposes, the most significant of which is the
domain names. Thus, certificate authorities in the Web PKI are authentication of domain names. Thus, certification authorities
trusted to verify that an applicant for a certificate legitimately (CAs) in the Web PKI are trusted to verify that an applicant for a
represents the domain name(s) in the certificate. Today, this certificate legitimately represents the domain name(s) in the
verification is done through a collection of ad hoc mechanisms. This certificate. Today, this verification is done through a collection
document describes a protocol that a certification authority (CA) and of ad hoc mechanisms. This document describes a protocol that a CA
an applicant can use to automate the process of verification and and an applicant can use to automate the process of verification and
certificate issuance. The protocol also provides facilities for certificate issuance. The protocol also provides facilities for
other certificate management functions, such as certificate other certificate management functions, such as certificate
revocation. revocation.
RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for
this draft is maintained in GitHub. Suggested changes should be this draft is maintained in GitHub. Suggested changes should be
submitted as pull requests at https://github.com/ietf-wg-acme/acme submitted as pull requests at https://github.com/ietf-wg-acme/acme
[1]. Instructions are on that page as well. Editorial changes can [1]. Instructions are on that page as well. Editorial changes can
be managed in GitHub, but any substantive change should be discussed be managed in GitHub, but any substantive change should be discussed
on the ACME mailing list (acme@ietf.org). on the ACME mailing list (acme@ietf.org).
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 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 January 18, 2019. This Internet-Draft will expire on February 11, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 44 skipping to change at page 2, line 44
6.3. Request URL Integrity . . . . . . . . . . . . . . . . . . 12 6.3. Request URL Integrity . . . . . . . . . . . . . . . . . . 12
6.3.1. "url" (URL) JWS Header Parameter . . . . . . . . . . 13 6.3.1. "url" (URL) JWS Header Parameter . . . . . . . . . . 13
6.4. Replay protection . . . . . . . . . . . . . . . . . . . . 13 6.4. Replay protection . . . . . . . . . . . . . . . . . . . . 13
6.4.1. Replay-Nonce . . . . . . . . . . . . . . . . . . . . 14 6.4.1. Replay-Nonce . . . . . . . . . . . . . . . . . . . . 14
6.4.2. "nonce" (Nonce) JWS Header Parameter . . . . . . . . 14 6.4.2. "nonce" (Nonce) JWS Header Parameter . . . . . . . . 14
6.5. Rate Limits . . . . . . . . . . . . . . . . . . . . . . . 14 6.5. Rate Limits . . . . . . . . . . . . . . . . . . . . . . . 14
6.6. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.6. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.6.1. Subproblems . . . . . . . . . . . . . . . . . . . . . 17 6.6.1. Subproblems . . . . . . . . . . . . . . . . . . . . . 17
7. Certificate Management . . . . . . . . . . . . . . . . . . . 18 7. Certificate Management . . . . . . . . . . . . . . . . . . . 18
7.1. Resources . . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Resources . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1.1. Directory . . . . . . . . . . . . . . . . . . . . . . 20 7.1.1. Directory . . . . . . . . . . . . . . . . . . . . . . 21
7.1.2. Account Objects . . . . . . . . . . . . . . . . . . . 22 7.1.2. Account Objects . . . . . . . . . . . . . . . . . . . 23
7.1.3. Order Objects . . . . . . . . . . . . . . . . . . . . 23 7.1.3. Order Objects . . . . . . . . . . . . . . . . . . . . 24
7.1.4. Authorization Objects . . . . . . . . . . . . . . . . 26 7.1.4. Authorization Objects . . . . . . . . . . . . . . . . 27
7.1.5. Challenge Objects . . . . . . . . . . . . . . . . . . 28 7.1.5. Challenge Objects . . . . . . . . . . . . . . . . . . 29
7.1.6. Status Changes . . . . . . . . . . . . . . . . . . . 28 7.1.6. Status Changes . . . . . . . . . . . . . . . . . . . 29
7.2. Getting a Nonce . . . . . . . . . . . . . . . . . . . . . 30 7.2. Getting a Nonce . . . . . . . . . . . . . . . . . . . . . 31
7.3. Account Creation . . . . . . . . . . . . . . . . . . . . 31 7.3. Account Creation . . . . . . . . . . . . . . . . . . . . 32
7.3.1. Finding an Account URL Given a Key . . . . . . . . . 33 7.3.1. Finding an Account URL Given a Key . . . . . . . . . 34
7.3.2. Account Update . . . . . . . . . . . . . . . . . . . 34 7.3.2. Account Update . . . . . . . . . . . . . . . . . . . 35
7.3.3. Account Information . . . . . . . . . . . . . . . . . 34 7.3.3. Account Information . . . . . . . . . . . . . . . . . 35
7.3.4. Changes of Terms of Service . . . . . . . . . . . . . 35 7.3.4. Changes of Terms of Service . . . . . . . . . . . . . 36
7.3.5. External Account Binding . . . . . . . . . . . . . . 35 7.3.5. External Account Binding . . . . . . . . . . . . . . 36
7.3.6. Account Key Roll-over . . . . . . . . . . . . . . . . 37 7.3.6. Account Key Roll-over . . . . . . . . . . . . . . . . 38
7.3.7. Account Deactivation . . . . . . . . . . . . . . . . 40 7.3.7. Account Deactivation . . . . . . . . . . . . . . . . 41
7.4. Applying for Certificate Issuance . . . . . . . . . . . . 41 7.4. Applying for Certificate Issuance . . . . . . . . . . . . 42
7.4.1. Pre-Authorization . . . . . . . . . . . . . . . . . . 46 7.4.1. Pre-Authorization . . . . . . . . . . . . . . . . . . 47
7.4.2. Downloading the Certificate . . . . . . . . . . . . . 48 7.4.2. Downloading the Certificate . . . . . . . . . . . . . 49
7.5. Identifier Authorization . . . . . . . . . . . . . . . . 49 7.5. Identifier Authorization . . . . . . . . . . . . . . . . 50
7.5.1. Responding to Challenges . . . . . . . . . . . . . . 50 7.5.1. Responding to Challenges . . . . . . . . . . . . . . 51
7.5.2. Deactivating an Authorization . . . . . . . . . . . . 52 7.5.2. Deactivating an Authorization . . . . . . . . . . . . 53
7.6. Certificate Revocation . . . . . . . . . . . . . . . . . 53 7.6. Certificate Revocation . . . . . . . . . . . . . . . . . 54
8. Identifier Validation Challenges . . . . . . . . . . . . . . 55 8. Identifier Validation Challenges . . . . . . . . . . . . . . 56
8.1. Key Authorizations . . . . . . . . . . . . . . . . . . . 57 8.1. Key Authorizations . . . . . . . . . . . . . . . . . . . 58
8.2. Retrying Challenges . . . . . . . . . . . . . . . . . . . 57 8.2. Retrying Challenges . . . . . . . . . . . . . . . . . . . 58
8.3. HTTP Challenge . . . . . . . . . . . . . . . . . . . . . 58 8.3. HTTP Challenge . . . . . . . . . . . . . . . . . . . . . 59
8.4. DNS Challenge . . . . . . . . . . . . . . . . . . . . . . 60 8.4. DNS Challenge . . . . . . . . . . . . . . . . . . . . . . 61
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63
9.1. MIME Type: application/pem-certificate-chain . . . . . . 62 9.1. MIME Type: application/pem-certificate-chain . . . . . . 63
9.2. Well-Known URI for the HTTP Challenge . . . . . . . . . . 63 9.2. Well-Known URI for the HTTP Challenge . . . . . . . . . . 64
9.3. Replay-Nonce HTTP Header . . . . . . . . . . . . . . . . 63 9.3. Replay-Nonce HTTP Header . . . . . . . . . . . . . . . . 64
9.4. "url" JWS Header Parameter . . . . . . . . . . . . . . . 63 9.4. "url" JWS Header Parameter . . . . . . . . . . . . . . . 64
9.5. "nonce" JWS Header Parameter . . . . . . . . . . . . . . 64 9.5. "nonce" JWS Header Parameter . . . . . . . . . . . . . . 65
9.6. URN Sub-namespace for ACME (urn:ietf:params:acme) . . . . 64 9.6. URN Sub-namespace for ACME (urn:ietf:params:acme) . . . . 65
9.7. New Registries . . . . . . . . . . . . . . . . . . . . . 64 9.7. New Registries . . . . . . . . . . . . . . . . . . . . . 65
9.7.1. Fields in Account Objects . . . . . . . . . . . . . . 65 9.7.1. Fields in Account Objects . . . . . . . . . . . . . . 66
9.7.2. Fields in Order Objects . . . . . . . . . . . . . . . 66 9.7.2. Fields in Order Objects . . . . . . . . . . . . . . . 67
9.7.3. Fields in Authorization Objects . . . . . . . . . . . 67 9.7.3. Fields in Authorization Objects . . . . . . . . . . . 68
9.7.4. Error Types . . . . . . . . . . . . . . . . . . . . . 68 9.7.4. Error Types . . . . . . . . . . . . . . . . . . . . . 69
9.7.5. Resource Types . . . . . . . . . . . . . . . . . . . 68 9.7.5. Resource Types . . . . . . . . . . . . . . . . . . . 69
9.7.6. Fields in the "meta" Object within a Directory Object 69 9.7.6. Fields in the "meta" Object within a Directory Object 70
9.7.7. Identifier Types . . . . . . . . . . . . . . . . . . 70 9.7.7. Identifier Types . . . . . . . . . . . . . . . . . . 71
9.7.8. Validation Methods . . . . . . . . . . . . . . . . . 70 9.7.8. Validation Methods . . . . . . . . . . . . . . . . . 71
10. Security Considerations . . . . . . . . . . . . . . . . . . . 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 73
10.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 72 10.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 73
10.2. Integrity of Authorizations . . . . . . . . . . . . . . 73 10.2. Integrity of Authorizations . . . . . . . . . . . . . . 74
10.3. Denial-of-Service Considerations . . . . . . . . . . . . 77 10.3. Denial-of-Service Considerations . . . . . . . . . . . . 78
10.4. Server-Side Request Forgery . . . . . . . . . . . . . . 77 10.4. Server-Side Request Forgery . . . . . . . . . . . . . . 78
10.5. CA Policy Considerations . . . . . . . . . . . . . . . . 78 10.5. CA Policy Considerations . . . . . . . . . . . . . . . . 79
11. Operational Considerations . . . . . . . . . . . . . . . . . 79 11. Operational Considerations . . . . . . . . . . . . . . . . . 80
11.1. Key Selection . . . . . . . . . . . . . . . . . . . . . 79 11.1. Key Selection . . . . . . . . . . . . . . . . . . . . . 80
11.2. DNS security . . . . . . . . . . . . . . . . . . . . . . 80 11.2. DNS security . . . . . . . . . . . . . . . . . . . . . . 81
11.3. Token Entropy . . . . . . . . . . . . . . . . . . . . . 80 11.3. Token Entropy . . . . . . . . . . . . . . . . . . . . . 81
11.4. Malformed Certificate Chains . . . . . . . . . . . . . . 81 11.4. Malformed Certificate Chains . . . . . . . . . . . . . . 82
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 81 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 82
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 82 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 83
13.1. Normative References . . . . . . . . . . . . . . . . . . 82 13.1. Normative References . . . . . . . . . . . . . . . . . . 83
13.2. Informative References . . . . . . . . . . . . . . . . . 85 13.2. Informative References . . . . . . . . . . . . . . . . . 86
13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 86 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 87
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, certification authorities (CAs) in
PKI are trusted to verify that an applicant for a certificate the Web 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
Validation" (DV) certificates are by far the most common type. The Validation" (DV) certificates are by far the most common type. The
only validation the CA is required to perform in the DV issuance only validation the CA is required to perform in the DV issuance
process is to verify that the requester has effective control of the process is to verify that the requester has effective control of the
domain. The CA is not required to attempt to verify the requester's domain. The CA is not required to attempt to verify the requester's
real-world identity. (This is as opposed to "Organization real-world identity. (This is as opposed to "Organization
Validation" (OV) and "Extended Validation" (EV) certificates, where Validation" (OV) and "Extended Validation" (EV) certificates, where
the process is intended to also verify the real-world identity of the the process is intended to also verify the real-world identity of the
requester.) requester.)
Existing Web PKI certificate authorities tend to use a set of ad hoc Existing Web PKI certificate authorities tend to use a set of ad hoc
protocols for certificate issuance and identity verification. In the protocols for certificate issuance and identity verification. In the
case of DV certificates, a typical user experience is something like: case of DV certificates, a typical user experience is something like:
o Generate a PKCS#10 [RFC2986] Certificate Signing Request (CSR). o Generate a PKCS#10 [RFC2986] Certificate Signing Request (CSR).
o Cut-and-paste the CSR into a CA web page. o Cut-and-paste the CSR into a CA's web page.
o Prove ownership of the domain by one of the following methods: o Prove ownership of the domain by one of the following methods:
* Put a CA-provided challenge at a specific place on the web * Put a CA-provided challenge at a specific place on the web
server. server.
* Put a CA-provided challenge in a DNS record corresponding to * Put a CA-provided challenge in a DNS record corresponding to
the target domain. the target domain.
* Receive a CA-provided challenge at a (hopefully) administrator- * Receive a CA-provided challenge at a (hopefully) administrator-
skipping to change at page 5, line 7 skipping to change at page 5, line 7
respond to it on the CA's web page. respond to it on the CA's web page.
o Download the issued certificate and install it on their Web o Download the issued certificate and install it on their Web
Server. Server.
With the exception of the CSR itself and the certificates that are With the exception of the CSR itself and the certificates that are
issued, these are all completely ad hoc procedures and are issued, these are all completely ad hoc procedures and are
accomplished by getting the human user to follow interactive natural- accomplished by getting the human user to follow interactive natural-
language instructions from the CA rather than by machine-implemented language instructions from the CA rather than by machine-implemented
published protocols. In many cases, the instructions are difficult published protocols. In many cases, the instructions are difficult
to follow and cause significant confusion. Informal usability tests to follow and cause significant frustration and confusion. Informal
by the authors indicate that webmasters often need 1-3 hours to usability tests by the authors indicate that webmasters often need
obtain and install a certificate for a domain. Even in the best 1-3 hours to obtain and install a certificate for a domain. Even in
case, the lack of published, standardized mechanisms presents an the best case, the lack of published, standardized mechanisms
obstacle to the wide deployment of HTTPS and other PKIX-dependent presents an obstacle to the wide deployment of HTTPS and other PKIX-
systems because it inhibits mechanization of tasks related to dependent systems because it inhibits mechanization of tasks related
certificate issuance, deployment, and revocation. to 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 infrastructure 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-based authentication
other protocols based on Transport Layer Security (TLS) [RFC5246]. for other protocols based on Transport Layer Security (TLS)
[RFC5246].
It should be noted that while the focus of this document is on It should be noted that while the focus of this document is on
validating domain names for purposes of issuing certificates in the validating domain names for purposes of issuing certificates in the
Web PKI, ACME supports extensions for uses with other identifiers in Web PKI, ACME supports extensions for uses with other identifiers in
other PKI contexts. For example, as of this writing, there is other PKI contexts. For example, as of this writing, there is
ongoing work to use ACME for issuance of WebPKI certificates ongoing work to use ACME for issuance of Web PKI certificates
attesting to IP addresses [I-D.ietf-acme-ip] and STIR certificates attesting to IP addresses [I-D.ietf-acme-ip] and STIR certificates
attesting to telephone numbers [I-D.ietf-acme-telephone]. attesting to telephone numbers [I-D.ietf-acme-telephone].
ACME can also be used to automate some aspects of certificate ACME can also be used to automate some aspects of certificate
management even where non-automated processes are still needed. For management even where non-automated processes are still needed. For
example, the external account binding feature (see Section 7.3.5) can example, the external account binding feature (see Section 7.3.5) can
allow an ACME account to use authorizations that have been granted to allow an ACME account to use authorizations that have been granted to
an external, non-ACME account. This allows ACME to address issuance an external, non-ACME account. This allows ACME to address issuance
scenarios that cannot yet be fully automated, such as the issuance of scenarios that cannot yet be fully automated, such as the issuance of
Extended Validation certificates. Extended Validation certificates.
skipping to change at page 7, line 17 skipping to change at page 7, line 17
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 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
server, mail server, or some other server system which requires valid server, mail server, or some other server system which requires valid
TLS certificates. Or, it may run on a separate server that does not X.509 certificates. Or, it may run on a separate server that does
consume the certificate, but is authorized to respond to a CA- not consume the certificate, but is authorized to respond to a CA-
provided challenge. The ACME server runs at a certification provided challenge. The ACME server runs at a certification
authority, and responds to client requests, performing the requested authority, and responds to client requests, performing the requested
actions if the client is authorized. actions if the client is authorized.
An ACME client authenticates to the server by means of an "account An ACME client authenticates to the server by means of an "account
key pair". The client uses the private key of this key pair to sign key pair". The client uses the private key of this key pair to sign
all messages sent to the server. The server uses the public key to all messages sent to the server. The server uses the public key to
verify the authenticity and integrity of messages from the client. verify the authenticity and integrity of messages from the client.
4. Protocol Overview 4. Protocol Overview
ACME allows a client to request certificate management actions using ACME allows a client to request certificate management actions using
a set of JavaScript Object Notation (JSON) messages carried over a set of JavaScript Object Notation (JSON) messages carried over
HTTPS. Issuance using ACME resembles a traditional CA's issuance HTTPS. Issuance using ACME resembles a traditional CA's issuance
process, in which a user creates an account, requests a certificate, process, in which a user creates an account, requests a certificate,
and proves control of the domain(s) in that certificate in order for and proves control of the domain(s) in that certificate in order for
the CA to sign the requested certificate. the CA to issue the requested certificate.
The first phase of ACME is for the client to request an account with The first phase of ACME is for the client to request an account with
the ACME server. The client generates an asymmetric key pair and the ACME server. The client generates an asymmetric key pair and
requests a new account, optionally providing contact information, requests a new account, optionally providing contact information,
agreeing to terms of service, and/or associating the account with an agreeing to terms of service, and/or associating the account with an
existing account in another system. The creation request is signed existing account in another system. The creation request is signed
with the generated private key to prove that the client controls it. with the generated private key to prove that the client controls it.
Client Server Client Server
skipping to change at page 12, line 6 skipping to change at page 12, line 6
below below
An ACME server MUST implement the "ES256" signature algorithm An ACME server MUST implement the "ES256" signature algorithm
[RFC7518] and SHOULD implement the "EdDSA" signature algorithm using [RFC7518] and SHOULD implement the "EdDSA" signature algorithm using
the "Ed25519" variant (indicated by "crv") [RFC8037]. the "Ed25519" variant (indicated by "crv") [RFC8037].
The "jwk" and "kid" fields are mutually exclusive. Servers MUST The "jwk" and "kid" fields are mutually exclusive. Servers MUST
reject requests that contain both. reject requests that contain both.
For newAccount requests, and for revokeCert requests authenticated by For newAccount requests, and for revokeCert requests authenticated by
certificate key, there MUST be a "jwk" field. This field MUST a certificate key, there MUST be a "jwk" field. This field MUST
contain the public key corresponding to the private key used to sign contain the public key corresponding to the private key used to sign
the JWS. the JWS.
For all other requests, the request is signed using an existing For all other requests, the request is signed using an existing
account and there MUST be a "kid" field. This field MUST contain the account and there MUST be a "kid" field. This field MUST contain the
account URL received by POSTing to the newAccount resource. account URL received by POSTing to the newAccount resource.
Note that authentication via signed JWS request bodies implies that Note that authentication via signed JWS request bodies implies that
GET requests are not authenticated. Servers MUST NOT respond to GET GET requests are not authenticated. Servers MUST NOT respond to GET
requests for resources that might be considered sensitive. Account requests for resources that might be considered sensitive. Account
resources are the only sensitive resources defined in this resources are the only sensitive resources defined in this
specification. specification.
If the client sends a JWS signed with an algorithm that the server If the client sends a JWS signed with an algorithm that the server
does not support, then the server MUST return an error with status does not support, then the server MUST return an error with status
code 400 (Bad Request) and type code 400 (Bad Request) and type
"urn:ietf:params:acme:error:badSignatureAlgorithm" (see Section 6.6). "urn:ietf:params:acme:error:badSignatureAlgorithm". The problem
The problem document returned with the error MUST include an document returned with the error MUST include an "algorithms" field
"algorithms" field with an array of supported "alg" values. with an array of supported "alg" values. See Section 6.6 for more
details on the structure of error responses.
Because client requests in ACME carry JWS objects in the Flattened Because client requests in ACME carry JWS objects in the Flattened
JSON Serialization, they must have the "Content-Type" header field JSON Serialization, they must have the "Content-Type" header field
set to "application/jose+json". If a request does not meet this set to "application/jose+json". If a request does not meet this
requirement, then the server MUST return a response with status code requirement, then the server MUST return a response with status code
415 (Unsupported Media Type). 415 (Unsupported Media Type).
6.3. Request URL Integrity 6.3. Request URL Integrity
It is common in deployment for the entity terminating TLS for HTTPS It is common in deployment for the entity terminating TLS for HTTPS
skipping to change at page 13, line 19 skipping to change at page 13, line 21
re-encoding on the URL). The server SHOULD perform the corresponding re-encoding on the URL). The server SHOULD perform the corresponding
string equality check, configuring each resource with the URL string string equality check, configuring each resource with the URL string
provided to clients and having the resource check that requests have provided to clients and having the resource check that requests have
the same string in their "url" header parameter. the same string in their "url" header parameter.
6.3.1. "url" (URL) JWS Header Parameter 6.3.1. "url" (URL) JWS Header Parameter
The "url" header parameter specifies the URL [RFC3986] to which this The "url" header parameter specifies the URL [RFC3986] to which this
JWS object is directed. The "url" header parameter MUST be carried JWS object is directed. The "url" header parameter MUST be carried
in the protected header of the JWS. The value of the "url" header in the protected header of the JWS. The value of the "url" header
parameter MUST be a string representing the URL. parameter MUST be a string representing the target URL.
6.4. Replay protection 6.4. Replay protection
In order to protect ACME resources from any possible replay attacks, In order to protect ACME resources from any possible replay attacks,
ACME requests have a mandatory anti-replay mechanism. This mechanism ACME requests have a mandatory anti-replay mechanism. This mechanism
is based on the server maintaining a list of nonces that it has is based on the server maintaining a list of nonces that it has
issued to clients, and requiring any signed request from the client issued to clients, and requiring any signed request from the client
to carry such a nonce. to carry such a nonce.
An ACME server provides nonces to clients using the Replay-Nonce An ACME server provides nonces to clients using the HTTP Replay-Nonce
header field, as specified in Section 6.4.1 below. The server MUST header field, as specified in Section 6.4.1 below. The server MUST
include a Replay-Nonce header field in every successful response to a include a Replay-Nonce header field in every successful response to a
POST request and SHOULD provide it in error responses as well. POST request and SHOULD provide it in error responses as well.
Every JWS sent by an ACME client MUST include, in its protected Every JWS sent by an ACME client MUST include, in its protected
header, the "nonce" header parameter, with contents as defined in header, the "nonce" header parameter, with contents as defined in
Section 6.4.2 below. As part of JWS verification, the ACME server Section 6.4.2 below. As part of JWS verification, the ACME server
MUST verify that the value of the "nonce" header is a value that the MUST verify that the value of the "nonce" header is a value that the
server previously provided in a Replay-Nonce header field. Once a server previously provided in a Replay-Nonce header field. Once a
nonce value has appeared in an ACME request, the server MUST consider nonce value has appeared in an ACME request, the server MUST consider
skipping to change at page 14, line 18 skipping to change at page 14, line 21
The "Replay-Nonce" header field includes a server-generated value The "Replay-Nonce" header field includes a server-generated value
that the server can use to detect unauthorized replay in future that the server can use to detect unauthorized replay in future
client requests. The server MUST generate the value provided in client requests. The server MUST generate the value provided in
Replay-Nonce in such a way that they are unique to each message, with Replay-Nonce in such a way that they are unique to each message, with
high probability. For instance, it is acceptable to generate Replay- high probability. For instance, it is acceptable to generate Replay-
Nonces randomly. Nonces randomly.
The value of the Replay-Nonce field MUST be an octet string encoded The value of the Replay-Nonce field MUST be an octet string encoded
according to the base64url encoding described in Section 2 of according to the base64url encoding described in Section 2 of
[RFC7515]. Clients MUST ignore invalid Replay-Nonce values. [RFC7515]. Clients MUST ignore invalid Replay-Nonce values. The
ABNF [RFC5234] for the Replay-Nonce header field follows:
base64url = [A-Z] / [a-z] / [0-9] / "-" / "_" base64url = [A-Z] / [a-z] / [0-9] / "-" / "_"
Replay-Nonce = *base64url Replay-Nonce = *base64url
The Replay-Nonce header field SHOULD NOT be included in HTTP request The Replay-Nonce header field SHOULD NOT be included in HTTP request
messages. messages.
6.4.2. "nonce" (Nonce) JWS Header Parameter 6.4.2. "nonce" (Nonce) JWS Header Parameter
skipping to change at page 14, line 45 skipping to change at page 14, line 49
[RFC7515]. If the value of a "nonce" header parameter is not valid [RFC7515]. If the value of a "nonce" header parameter is not valid
according to this encoding, then the verifier MUST reject the JWS as according to this encoding, then the verifier MUST reject the JWS as
malformed. malformed.
6.5. Rate Limits 6.5. Rate Limits
Creation of resources can be rate limited by ACME servers to ensure Creation of resources can be rate limited by ACME servers to ensure
fair usage and prevent abuse. Once the rate limit is exceeded, the fair usage and prevent abuse. Once the rate limit is exceeded, the
server MUST respond with an error with the type server MUST 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 [RFC7231] indicating when the
request may succeed again. If multiple rate limits are in place, current request may succeed again. If multiple rate limits are in
that is the time where all rate limits allow access again for the place, that is the time where all rate limits allow access again for
current request with exactly the same parameters. the 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 link relations in the response, the server MAY send one or multiple link relations in the
"Link" header pointing to documentation about the specific rate limit "Link" header [RFC8288] pointing to documentation about the specific
that was hit, using the "help" link relation type. rate limit that was hit, using the "help" link relation type.
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
in this document, then the server MAY return status code 405 (Method in this document, then the server MAY return status code 405 (Method
Not Allowed). Not Allowed).
When the server responds with an error status, it SHOULD provide When the server responds with an error status, it SHOULD provide
additional information using a problem document [RFC7807]. To additional information using a problem document [RFC7807]. To
facilitate automatic response to errors, this document defines the facilitate automatic response to errors, this document defines the
following standard tokens for use in the "type" field (within the following standard tokens for use in the "type" field (within the
"urn:ietf:params:acme:error:" namespace): ACME URN namespace "urn:ietf:params:acme:error:"):
+-------------------------+-----------------------------------------+ +-------------------------+-----------------------------------------+
| Type | Description | | Type | Description |
+-------------------------+-----------------------------------------+ +-------------------------+-----------------------------------------+
| accountDoesNotExist | The request specified an account that | | accountDoesNotExist | The request specified an account that |
| | does not exist | | | does not exist |
| | | | | |
| alreadyRevoked | The request specified a certificate to |
| | be revoked that has already been |
| | revoked |
| | |
| badCSR | The CSR is unacceptable (e.g., due to a | | badCSR | The CSR is unacceptable (e.g., due to a |
| | short key) | | | short key) |
| | | | | |
| badNonce | The client sent an unacceptable anti- | | badNonce | The client sent an unacceptable anti- |
| | replay nonce | | | replay nonce |
| | | | | |
| badRevocationReason | The revocation reason provided is not | | badRevocationReason | The revocation reason provided is not |
| | allowed by the server | | | allowed by the server |
| | | | | |
| badSignatureAlgorithm | The JWS was signed with an algorithm | | badSignatureAlgorithm | The JWS was signed with an algorithm |
skipping to change at page 15, line 51 skipping to change at page 16, line 9
| | (CAA) records forbid the CA from | | | (CAA) records forbid the CA from |
| | issuing | | | issuing |
| | | | | |
| compound | Specific error conditions are indicated | | compound | Specific error conditions are indicated |
| | in the "subproblems" array. | | | in the "subproblems" array. |
| | | | | |
| connection | The server could not connect to | | connection | The server could not connect to |
| | validation target | | | validation target |
| | | | | |
| dns | There was a problem with a DNS query | | dns | There was a problem with a DNS query |
| | during identifier validation |
| | | | | |
| externalAccountRequired | The request must include a value for | | externalAccountRequired | The request must include a value for |
| | the "externalAccountBinding" field | | | the "externalAccountBinding" field |
| | | | | |
| incorrectResponse | Response received didn't match the | | incorrectResponse | Response received didn't match the |
| | challenge's requirements | | | challenge's requirements |
| | | | | |
| invalidContact | A contact URL for an account was | | invalidContact | A contact URL for an account was |
| | invalid | | | invalid |
| | | | | |
skipping to change at page 16, line 41 skipping to change at page 16, line 48
| | | | | |
| unsupportedIdentifier | Identifier is not supported, but may be | | unsupportedIdentifier | Identifier is not supported, but may be |
| | in future | | | in future |
| | | | | |
| userActionRequired | Visit the "instance" URL and take | | userActionRequired | Visit the "instance" URL and take |
| | actions specified there | | | actions specified there |
+-------------------------+-----------------------------------------+ +-------------------------+-----------------------------------------+
This list is not exhaustive. The server MAY return errors whose This list is not exhaustive. The server MAY return errors whose
"type" field is set to a URI other than those defined above. Servers "type" field is set to a URI other than those defined above. Servers
MUST NOT use the ACME URN [RFC3553] namespace for errors other than MUST NOT use the ACME URN namespace Section 9.6 for errors other than
the standard types. Clients SHOULD display the "detail" field of all the standard types. Clients SHOULD display the "detail" field of all
errors. errors.
In the remainder of this document, we use the tokens in the table In the remainder of this document, we use the tokens in the table
above to refer to error types, rather than the full URNs. For above to refer to error types, rather than the full URNs. For
example, an "error of type 'badCSR'" refers to an error document with example, an "error of type 'badCSR'" refers to an error document with
"type" value "urn:ietf:params:acme:error:badCSR". "type" value "urn:ietf:params:acme:error:badCSR".
6.6.1. Subproblems 6.6.1. Subproblems
skipping to change at page 18, line 21 skipping to change at page 18, line 48
o Ordering a Certificate o Ordering a Certificate
o Identifier Authorization o Identifier Authorization
o Certificate Issuance o Certificate Issuance
o Certificate Revocation o Certificate Revocation
7.1. Resources 7.1. Resources
ACME is structured as a REST application with the following types of ACME is structured as a REST [REST] application with the following
resources: types of resources:
o Account resources, representing information about an account o Account resources, representing information about an account
(Section 7.1.2, Section 7.3) (Section 7.1.2, Section 7.3)
o Order resources, representing an account's requests to issue o Order resources, representing an account's requests to issue
certificates (Section 7.1.3) certificates (Section 7.1.3)
o Authorization resources, representing an account's authorization o Authorization resources, representing an account's authorization
to act for an identifier (Section 7.1.4) to act for an identifier (Section 7.1.4)
skipping to change at page 21, line 18 skipping to change at page 22, line 18
| newNonce | New nonce | | newNonce | New nonce |
| | | | | |
| newAccount | New account | | newAccount | New account |
| | | | | |
| newOrder | New order | | newOrder | New order |
| | | | | |
| newAuthz | New authorization | | newAuthz | New authorization |
| | | | | |
| revokeCert | Revoke certificate | | revokeCert | Revoke certificate |
| | | | | |
| keyChange | Key change | | keyChange | Key Change |
+------------+--------------------+ +------------+--------------------+
There is no constraint on the URL of the directory except that it There is no constraint on the URL of the directory except that it
should be different from the other ACME server resources' URLs, and should be different from the other ACME server resources' URLs, and
that it should not clash with other services. For instance: that it should not clash with other services. For instance:
o a host which functions as both an ACME and a Web server may want o a host which functions as both an ACME and a Web server may want
to keep the root path "/" for an HTML "front page", and place the to keep the root path "/" for an HTML "front page", and place the
ACME directory under the path "/acme". ACME directory under the path "/acme".
skipping to change at page 26, line 15 skipping to change at page 27, line 15
the referenced authorizations may already be valid: the referenced authorizations may already be valid:
o The client completed the authorization as part of a previous order o The client completed the authorization as part of a previous order
o The client previously pre-authorized the identifier (see o The client previously pre-authorized the identifier (see
Section 7.4.1) Section 7.4.1)
o The server granted the client authorization based on an external o The server granted the client authorization based on an external
account account
Clients should check the "status" field of an order to determine Clients SHOULD check the "status" field of an order to determine
whether they need to take any action. whether they need to take any action.
7.1.4. Authorization Objects 7.1.4. Authorization Objects
An ACME authorization object represents a server's authorization for An ACME authorization object represents a server's authorization for
an account to represent an identifier. In addition to the an account to represent an identifier. In addition to the
identifier, an authorization includes several metadata fields, such identifier, an authorization includes several metadata fields, such
as the status of the authorization (e.g., "pending", "valid", or as the status of the authorization (e.g., "pending", "valid", or
"revoked") and which challenges were used to validate possession of "revoked") and which challenges were used to validate possession of
the identifier. the identifier.
skipping to change at page 49, line 9 skipping to change at page 50, line 9
If the client wishes to obtain a renewed certificate, the client If the client wishes to obtain a renewed certificate, the client
initiates a new order process to request one. initiates a new order process to request one.
Because certificate resources are immutable once issuance is Because certificate resources are immutable once issuance is
complete, the server MAY enable the caching of the resource by adding complete, the server MAY enable the caching of the resource by adding
Expires and Cache-Control headers specifying a point in time in the Expires and Cache-Control headers specifying a point in time in the
distant future. These headers have no relation to the certificate's distant future. These headers have no relation to the certificate's
period of validity. period of validity.
The ACME client MAY request other formats by including an Accept The ACME client MAY request other formats by including an Accept
header in its request. For example, the client could use the media header [RFC7231] in its request. For example, the client could use
type "application/pkix-cert" [RFC2585] to request the end-entity the media type "application/pkix-cert" [RFC2585] or "applicaiton/
certificate in DER format. Server support for alternate formats is pkcs7-mime" [RFC5751] to request the end-entity certificate in DER
OPTIONAL. For formats that can only express a single certificate, format. Server support for alternate formats is OPTIONAL. For
the server SHOULD provide one or more "Link: rel="up"" headers formats that can only express a single certificate, the server SHOULD
pointing to an issuer or issuers so that ACME clients can build a provide one or more "Link: rel="up"" headers pointing to an issuer or
certificate chain as defined in TLS. issuers so that ACME clients can build a certificate chain as defined
in TLS.
7.5. Identifier Authorization 7.5. Identifier Authorization
The identifier authorization process establishes the authorization of The identifier authorization process establishes the authorization of
an account to manage certificates for a given identifier. This an account to manage certificates for a given identifier. This
process assures the server of two things: process assures the server of two things:
1. That the client controls the private key of the account key pair, 1. That the client controls the private key of the account key pair,
and and
skipping to change at page 55, line 15 skipping to change at page 56, line 15
o the account that issued the certificate. o the account that issued the certificate.
o an account that holds authorizations for all of the identifiers in o an account that holds authorizations for all of the identifiers in
the certificate. the certificate.
The server MUST also consider a revocation request valid if it is The server MUST also consider a revocation request valid if it is
signed with the private key corresponding to the public key in the signed with the private key corresponding to the public key in the
certificate. certificate.
If the revocation succeeds, the server responds with status code 200 If the revocation succeeds, the server responds with status code 200
(OK). If the revocation fails, the server returns an error. (OK). If the revocation fails, the server returns an error. For
example, if the certificate has already been revoked the server
returns an error response with status code 400 (Bad Request) and type
"urn:ietf:params:acme:error:alreadyRevoked".
HTTP/1.1 200 OK HTTP/1.1 200 OK
Replay-Nonce: IXVHDyxIRGcTE0VSblhPzw Replay-Nonce: IXVHDyxIRGcTE0VSblhPzw
Content-Length: 0 Content-Length: 0
--- or --- --- or ---
HTTP/1.1 403 Forbidden HTTP/1.1 403 Forbidden
Replay-Nonce: IXVHDyxIRGcTE0VSblhPzw Replay-Nonce: IXVHDyxIRGcTE0VSblhPzw
Content-Type: application/problem+json Content-Type: application/problem+json
skipping to change at page 58, line 45 skipping to change at page 59, line 45
and AAAA records, at its discretion. Because many web servers and AAAA records, at its discretion. Because many web servers
allocate a default HTTPS virtual host to a particular low-privilege allocate a default HTTPS virtual host to a particular low-privilege
tenant user in a subtle and non-intuitive manner, the challenge must tenant user in a subtle and non-intuitive manner, the challenge must
be completed over HTTP, not HTTPS. be completed over HTTP, not HTTPS.
type (required, string): The string "http-01" type (required, string): The string "http-01"
token (required, string): A random value that uniquely identifies token (required, string): A random value that uniquely identifies
the challenge. This value MUST have at least 128 bits of entropy. the challenge. This value MUST have at least 128 bits of entropy.
It MUST NOT contain any characters outside the base64url alphabet, It MUST NOT contain any characters outside the base64url alphabet,
and MUST NOT include base64 padding characters ("="). and MUST NOT include base64 padding characters ("="). See
[RFC4086] for additional information on randomness requirements.
GET /acme/authz/1234/0 HTTP/1.1 GET /acme/authz/1234/0 HTTP/1.1
Host: example.com Host: example.com
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/json Content-Type: application/json
{ {
"type": "http-01", "type": "http-01",
"url": "https://example.com/acme/authz/0", "url": "https://example.com/acme/authz/0",
skipping to change at page 63, line 32 skipping to change at page 64, line 32
Specification document(s): This document, Section Section 8.3 Specification document(s): This document, Section Section 8.3
Related information: N/A Related information: N/A
9.3. Replay-Nonce HTTP Header 9.3. Replay-Nonce HTTP Header
The "Message Headers" registry should be updated with the following The "Message Headers" registry should be updated with the following
additional value: additional value:
+-------------------+----------+----------+---------------+ +------------------+----------+----------+--------------------------+
| Header Field Name | Protocol | Status | Reference | | Header Field | Protocol | Status | Reference |
+-------------------+----------+----------+---------------+ | Name | | | |
| Replay-Nonce | http | standard | Section 6.4.1 | +------------------+----------+----------+--------------------------+
+-------------------+----------+----------+---------------+ | Replay-Nonce | http | standard | [[this-RFC, Section |
| | | | 6.4.1] |
+------------------+----------+----------+--------------------------+
9.4. "url" JWS Header Parameter 9.4. "url" JWS Header Parameter
The "JSON Web Signature and Encryption Header Parameters" registry The "JSON Web Signature and Encryption Header Parameters" registry
should be updated with the following additional value: should be updated with the following additional value:
o Header Parameter Name: "url" o Header Parameter Name: "url"
o Header Parameter Description: URL o Header Parameter Description: URL
skipping to change at page 74, line 4 skipping to change at page 75, line 4
ACME allows anyone to request challenges for an identifier by ACME allows anyone to request challenges for an identifier by
registering an account key and sending a new-order request using that registering an account key and sending a new-order request using that
account key. The integrity of the authorization process thus depends account key. The integrity of the authorization process thus depends
on the identifier validation challenges to ensure that the challenge on the identifier validation challenges to ensure that the challenge
can only be completed by someone who both (1) holds the private key can only be completed by someone who both (1) holds the private key
of the account key pair, and (2) controls the identifier in question. of the account key pair, and (2) controls the identifier in question.
Validation responses need to be bound to an account key pair in order Validation responses need to be bound to an account key pair in order
to avoid situations where a MitM on ACME HTTPS requests can switch to avoid situations where a MitM on ACME HTTPS requests can switch
out a legitimate domain holder's account key for one of his choosing, out a legitimate domain holder's account key for one of his choosing.
e.g.: Such MitMs can arise, for example, if a CA uses a CDN or third-party
reverse proxy in front of its ACME interface. An attack by such an
MitM could have the following form:
o Legitimate domain holder registers account key pair A o Legitimate domain holder registers account key pair A
o MitM registers account key pair B o MitM registers account key pair B
o Legitimate domain holder sends a new-order request signed using o Legitimate domain holder sends a new-order request signed using
account key A account key A
o MitM suppresses the legitimate request but sends the same request o MitM suppresses the legitimate request but sends the same request
signed using account key B signed using account key B
skipping to change at page 75, line 37 skipping to change at page 76, line 37
| validation response | | | validation response | |
|-------------------------------------------->| |-------------------------------------------->|
| | | | | |
| | | Considers challenge | | | Considers challenge
| | | fulfilled by B. | | | fulfilled by B.
| | | | | |
Man-in-the-Middle Attack Exploiting a Validation Method without Man-in-the-Middle Attack Exploiting a Validation Method without
Account Key Binding Account Key Binding
All of the challenges above have a binding between the account All of the challenges defined in this document have a binding between
private key and the validation query made by the server, via the key the account private key and the validation query made by the server,
authorization. The key authorization reflects the account public via the key authorization. The key authorization reflects the
key, is provided to the server in the validation response over the account public key, is provided to the server in the validation
validation channel and signed afterwards by the corresponding private response over the validation channel and signed afterwards by the
key in the challenge response over the ACME channel. 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 DNS: Provision DNS resource records for the domain o DNS: Provision DNS resource records for the domain
skipping to change at page 82, line 19 skipping to change at page 83, line 19
[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>.
[JSS15] Somorovsky, J., "On the Security of TLS 1.3 and QUIC [JSS15] Somorovsky, J., "On the Security of TLS 1.3 and QUIC
Against Weaknesses in PKCS#1 v1.5 Encryption", n.d., Against Weaknesses in PKCS#1 v1.5 Encryption", n.d.,
<https://dl.acm.org/citation.cfm?id=2813657>. <https://dl.acm.org/citation.cfm?id=2813657>.
[REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", 2000,
<http://www.ics.uci.edu/~fielding/pubs/dissertation/
top.htm>.
[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>.
[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,
<https://www.rfc-editor.org/info/rfc2585>. <https://www.rfc-editor.org/info/rfc2585>.
skipping to change at page 83, line 14 skipping to change at page 84, line 19
[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, <https://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,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[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,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[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-editor.org/info/rfc5246>. <https://www.rfc-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,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, DOI 10.17487/RFC5751, January
2010, <https://www.rfc-editor.org/info/rfc5751>.
[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,
<https://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-editor.org/info/rfc5988>. <https://www.rfc-editor.org/info/rfc5988>.
[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
skipping to change at page 85, line 5 skipping to change at page 86, line 23
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>.
13.2. Informative References 13.2. Informative References
[I-D.ietf-acme-caa] [I-D.ietf-acme-caa]
Landau, H., "CAA Record Extensions for Account URI and Landau, H., "CAA Record Extensions for Account URI and
ACME Method Binding", draft-ietf-acme-caa-05 (work in ACME Method Binding", draft-ietf-acme-caa-05 (work in
progress), June 2018. progress), June 2018.
[I-D.ietf-acme-ip] [I-D.ietf-acme-ip]
Shoemaker, R., "ACME IP Identifier Validation Extension", Shoemaker, R., "ACME IP Identifier Validation Extension",
draft-ietf-acme-ip-02 (work in progress), May 2018. draft-ietf-acme-ip-04 (work in progress), July 2018.
[I-D.ietf-acme-telephone] [I-D.ietf-acme-telephone]
Peterson, J. and R. Barnes, "ACME Identifiers and Peterson, J. and R. Barnes, "ACME Identifiers and
Challenges for Telephone Numbers", draft-ietf-acme- Challenges for Telephone Numbers", draft-ietf-acme-
telephone-01 (work in progress), October 2017. telephone-01 (work in progress), October 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.
 End of changes. 40 change blocks. 
131 lines changed or deleted 173 lines changed or added

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