Skip to content
This repository was archived by the owner on Apr 24, 2020. It is now read-only.

Commit b7047e4

Browse files
bifurcationbifurcation
authored
Nits from EKR's RFC approval (#504)
* Final nits from EKR * XML reconciliation * Complete reconciliation to RFC XML
1 parent eebe98f commit b7047e4

File tree

4 files changed

+1013
-976
lines changed

4 files changed

+1013
-976
lines changed

‎draft-ietf-acme-acme.md‎

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -191,7 +191,7 @@ deploying an HTTPS server using ACME, the experience would be something like thi
191191
automatically downloads and installs it, potentially notifying the operator
192192
via email, SMS, etc.
193193
* The ACME client periodically contacts the CA to get updated certificates,
194-
stapled Online Certificate Status Protocol (OCSP) responses, or whatever else would be required to keep the web server functional and its credentials up to date.
194+
stapled Online Certificate Status Protocol (OCSP) responses {{?RFC6960}}, or whatever else would be required to keep the web server functional and its credentials up to date.
195195

196196
In this way, it would be nearly as easy to deploy with a CA-issued certificate
197197
as with a self-signed certificate. Furthermore, the maintenance of that
@@ -226,7 +226,7 @@ from the client.
226226
# Protocol Overview
227227

228228
ACME allows a client to request certificate management actions using a set of
229-
JavaScript Object Notation (JSON) messages carried over HTTPS {{!RFC8259}} {{!RFC2818}}.
229+
JavaScript Object Notation (JSON) messages {{!RFC8259}} carried over HTTPS {{!RFC2818}}.
230230
Issuance using ACME resembles a traditional CA's issuance process, in which a user creates an account,
231231
requests a certificate, and proves control of the domain(s) in that certificate in
232232
order for the CA to issue the requested certificate.
@@ -354,7 +354,7 @@ integrity for the HTTPS request URL.
354354
## HTTPS Requests
355355

356356
Each ACME function is accomplished by the client sending a sequence of HTTPS
357-
requests to the server, carrying JSON messages {{!RFC2818}}{{!RFC8259}}. Use of
357+
requests to the server {{!RFC2818}}, carrying JSON messages {{!RFC8259}}. Use of
358358
HTTPS is REQUIRED. Each subsection of
359359
{{certificate-management}} below describes the message formats used by the
360360
function and the order in which messages are sent.
@@ -2513,7 +2513,7 @@ server SHOULD set the Retry-After header field to a time after the server's
25132513
next validation query, since the status of the challenge will not change until
25142514
that time.
25152515

2516-
Clients can explicitly request a retry by resending their response to a
2516+
Clients can explicitly request a retry by re-sending their response to a
25172517
challenge in a new POST request (with a new nonce, etc.). This allows clients
25182518
to request a retry when the state has changed (e.g., after firewall rules have been
25192519
updated). Servers SHOULD retry a request immediately on receiving such a POST

‎rfced/draft-ietf-acme-acme.clean.xml‎

Lines changed: 22 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -176,7 +176,7 @@ under http://example.com.</t>
176176
automatically downloads and installs it, potentially notifying the operator
177177
via email, SMS, etc.</t>
178178
<t>The ACME client periodically contacts the CA to get updated certificates,
179-
stapled Online Certificate Status Protocol (OCSP) responses, or whatever else would be required to keep the web server functional and its credentials up to date.</t>
179+
stapled Online Certificate Status Protocol (OCSP) responses <xref target="RFC6960"/>, or whatever else would be required to keep the web server functional and its credentials up to date.</t>
180180
</list></t>
181181

182182
<t>In this way, it would be nearly as easy to deploy with a CA-issued certificate
@@ -213,7 +213,7 @@ from the client.</t>
213213
<section anchor="protocol-overview" title="Protocol Overview">
214214

215215
<t>ACME allows a client to request certificate management actions using a set of
216-
JavaScript Object Notation (JSON) messages carried over HTTPS <xref target="RFC8259"/> <xref target="RFC2818"/>.
216+
JavaScript Object Notation (JSON) messages <xref target="RFC8259"/> carried over HTTPS <xref target="RFC2818"/>.
217217
Issuance using ACME resembles a traditional CA's issuance process, in which a user creates an account,
218218
requests a certificate, and proves control of the domain(s) in that certificate in
219219
order for the CA to issue the requested certificate.</t>
@@ -341,7 +341,7 @@ integrity for the HTTPS request URL.</t>
341341
<section anchor="https-requests" title="HTTPS Requests">
342342

343343
<t>Each ACME function is accomplished by the client sending a sequence of HTTPS
344-
requests to the server, carrying JSON messages <xref target="RFC2818"/><xref target="RFC8259"/>. Use of
344+
requests to the server <xref target="RFC2818"/>, carrying JSON messages <xref target="RFC8259"/>. Use of
345345
HTTPS is REQUIRED. Each subsection of
346346
<xref target="certificate-management"/> below describes the message formats used by the
347347
function and the order in which messages are sent.</t>
@@ -2618,7 +2618,7 @@ server SHOULD set the Retry-After header field to a time after the server's
26182618
next validation query, since the status of the challenge will not change until
26192619
that time.</t>
26202620

2621-
<t>Clients can explicitly request a retry by resending their response to a
2621+
<t>Clients can explicitly request a retry by re-sending their response to a
26222622
challenge in a new POST request (with a new nonce, etc.). This allows clients
26232623
to request a retry when the state has changed (e.g., after firewall rules have been
26242624
updated). Servers SHOULD retry a request immediately on receiving such a POST
@@ -4374,6 +4374,24 @@ in the use of HTTP.</t>
43744374

43754375

43764376

4377+
<reference anchor="RFC6960" target='https://www.rfc-editor.org/info/rfc6960'>
4378+
<front>
4379+
<title>X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP</title>
4380+
<author initials='S.' surname='Santesson' fullname='S. Santesson'><organization/></author>
4381+
<author initials='M.' surname='Myers' fullname='M. Myers'><organization/></author>
4382+
<author initials='R.' surname='Ankney' fullname='R. Ankney'><organization/></author>
4383+
<author initials='A.' surname='Malpani' fullname='A. Malpani'><organization/></author>
4384+
<author initials='S.' surname='Galperin' fullname='S. Galperin'><organization/></author>
4385+
<author initials='C.' surname='Adams' fullname='C. Adams'><organization/></author>
4386+
<date year='2013' month='June'/>
4387+
<abstract><t>This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912.</t></abstract>
4388+
</front>
4389+
<seriesInfo name='RFC' value='6960'/>
4390+
<seriesInfo name='DOI' value='10.17487/RFC6960'/>
4391+
</reference>
4392+
4393+
4394+
43774395
<reference anchor="RFC7525" target='https://www.rfc-editor.org/info/rfc7525'>
43784396
<front>
43794397
<title>Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>

0 commit comments

Comments
 (0)