draft-ietf-acme-acme-17.txt   draft-ietf-acme-acme-18.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: June 20, 2019 EFF Expires: June 23, 2019 EFF
D. McCarney D. McCarney
Let's Encrypt Let's Encrypt
J. Kasten J. Kasten
University of Michigan University of Michigan
December 17, 2018 December 20, 2018
Automatic Certificate Management Environment (ACME) Automatic Certificate Management Environment (ACME)
draft-ietf-acme-acme-17 draft-ietf-acme-acme-18
Abstract Abstract
Public Key Infrastructure X.509 (PKIX) certificates are used for a Public Key Infrastructure X.509 (PKIX) certificates are used for a
number of purposes, the most significant of which is the number of purposes, the most significant of which is the
authentication of domain names. Thus, certification authorities authentication of domain names. Thus, certification authorities
(CAs) in the Web PKI are trusted to verify that an applicant for a (CAs) in 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. Today, this verification is done through a collection certificate. Today, this verification is done through a collection
of ad hoc mechanisms. This document describes a protocol that a CA of ad hoc mechanisms. This document describes a protocol that a CA
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 June 20, 2019. This Internet-Draft will expire on June 23, 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 84, line 50 skipping to change at page 84, line 50
4. Changing the account key pair for the account, locking out the 4. Changing the account key pair for the account, locking out the
legitimate account holder legitimate account holder
For this reason, it is RECOMMENDED that each account key pair be used For this reason, it is RECOMMENDED that each account key pair be used
only for authentication of a single ACME account. For example, the only for authentication of a single ACME account. For example, the
public key of an account key pair MUST NOT be included in a public key of an account key pair MUST NOT be included in a
certificate. If an ACME client receives a request from a user for certificate. If an ACME client receives a request from a user for
account creation or key roll-over using an account key that the account creation or key roll-over using an account key that the
client knows to be used elsewhere, then the client MUST return an client knows to be used elsewhere, then the client MUST return an
error. Clients that manage account keys on behalf of users SHOULD error. Clients MUST generate a fresh account key for every account
generate a fresh account key for every account creation or roll-over creation or roll-over operation. Note that given the requirements of
operation. Note that given the requirements of Section 7.3.1, Section 7.3.1, servers will not create accounts with reused keys
servers will not create accounts with reused keys anyway. anyway.
ACME clients and servers MUST verify that a CSR submitted in a ACME clients and servers MUST verify that a CSR submitted in a
finalize request does not contain a public key for any known account finalize request does not contain a public key for any known account
key pair. In particular, when a server receives a finalize request, key pair. In particular, when a server receives a finalize request,
it MUST verify that the public key in a CSR is not the same as the it MUST verify that the public key in a CSR is not the same as the
public key of the account key pair used to authenticate that request. public key of the account key pair used to authenticate that request.
This assures that vulnerabilities in the protocols with which the This assures that vulnerabilities in the protocols with which the
certificate is used (e.g., signing oracles in TLS [JSS15]) do not certificate is used (e.g., signing oracles in TLS [JSS15]) do not
result in compromise of the ACME account. Because ACME accounts are result in compromise of the ACME account. Because ACME accounts are
uniquely identified by their account key pair (see Section 7.3.1) the uniquely identified by their account key pair (see Section 7.3.1) the
 End of changes. 5 change blocks. 
8 lines changed or deleted 8 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/