Update acme divergences documentation (letsencrypt#5101)

aarongable · web-flow · commit cbef9ac43b15 · 2020-09-23T13:37:57.000-07:00
This change reorganizes the document to have all changes
noted under their respective section headings, updates estimated
resolution dates on long-standing divergences, and updates all URLs
to reference the final RFC 8555 instead of various drafts.

In addition, it adds a note that we do not accept the (optional)
`notBefore` and `notAfter` fields of a `newOrder` request.
diff --git a/docs/acme-divergences.md b/docs/acme-divergences.md
@@ -2,24 +2,41 @@
 
 While Boulder attempts to implement the ACME specification ([RFC 8555]) as strictly as possible there are places at which we will diverge from the letter of the specification for various reasons. This document describes the difference between RFC 8555 and Boulder's implementation of ACME, informally called ACMEv2 and available at https://acme-v02.api.letsencrypt.org/directory. Boulder's implementation of ACMEv1 differs substantially from the final RFC. Documentation for Boulder's ACMEv1 support is available in [acme-divergences-v1.md](acme-divergences-v1.md).
 
-Presently the following protocol features are not implemented:
+Presently, Boulder diverges from the RFC 8555 ACME spec in the following ways:
 
-- Pre-authorization. This is an optional feature and we have no plans to implement it. V2 clients should use order based issuance without pre-authorization.
-- The `orders` field on account objects. We intend to support this non-essential feature in the future. Please follow Boulder Issue [#3335](https://github.com/letsencrypt/boulder/issues/3335).
+## [Section 6.3](https://tools.ietf.org/html/rfc8555#section-6.3)
 
-POST-as-GET: We support POST-as-GET but do not yet mandate it. We [plan to mandate](https://community.letsencrypt.org/t/acme-v2-scheduled-deprecation-of-unauthenticated-resource-gets/74380) POST-as-GET for all ACMEv2 requests in late 2019.
+We support POST-as-GET but do not yet mandate it. We
+[plan to mandate](https://community.letsencrypt.org/t/acme-v2-scheduled-deprecation-of-unauthenticated-resource-gets/74380)
+POST-as-GET for all ACMEv2 requests in November 2020.
 
 ## [Section 6.6](https://tools.ietf.org/html/rfc8555#section-6.6)
 
 Boulder does not provide a `Retry-After` header when a user hits a rate-limit, nor does it provide `Link` headers to further documentation on rate-limiting.
 
 ## [Section 6.7](https://tools.ietf.org/html/rfc8555#section-6.7)
 
-Boulder uses `invalidEmail` in place of the error `invalidContact` defined in [draft-ietf-acme-01 Section 5.4](https://tools.ietf.org/html/draft-ietf-acme-acme-01#section-5.4).
+Boulder uses `invalidEmail` in place of the error `invalidContact`.
 
 Boulder does not implement the `unsupportedContact` and `dnssec` errors.
 
-## [Section 7.4.2](https://tools.ietf.org/html/draft-ietf-acme-acme-07#section-7.4.2)
+## [Section 7.1.2](https://tools.ietf.org/html/rfc8555#section-7.1.2)
+
+Boulder does not supply the `orders` field on account objects. We intend to
+support this non-essential feature in the future. Please follow Boulder Issue
+[#3335](https://github.com/letsencrypt/boulder/issues/3335).
+
+## [Section 7.4](https://tools.ietf.org/html/rfc8555#section-7.4)
+
+Boulder does not accept the optional `notBefore` and `notAfter` fields of a
+`newOrder` request paylod.
+
+## [Section 7.4.1](https://tools.ietf.org/html/rfc8555#section-7.4.1)
+
+Pre-authorization is an optional feature and we have no plans to implement it.
+V2 clients should use order based issuance without pre-authorization.
+
+## [Section 7.4.2](https://tools.ietf.org/html/rfc8555#section-7.4.2)
 
 Boulder does not process `Accept` headers for `Content-Type` negotiation when retrieving certificates.
 
