@jsha suggested I re-implement a PR against Pebble regarding Authorization
reuse into Boulder (see https://github.com/letsencrypt/pebble/pull/325).
This is an initial attempt. I opted to handle this by creating a new file for
"Implementation Details" that are RFC conformant and are known to have
confused client developers.
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.
We can remove some divergences since in the V2 API:
* We use the correct error namespace.
* We use the correct `Content-Type` for Certificate requests.
* We use the correct `url` field in Challenge objects.
* We use the correct HTTP status code for Challenge POST requests.
* Remove the challenge whitelist
* Reduce the signature for ChallengesFor and ChallengeTypeEnabled
* Some unit tests in the VA were changed from testing TLS-SNI to testing the same behavior
in TLS-ALPN, when that behavior wasn't already tested. For instance timeouts during connect
are now tested.
Fixes#4109
This is primarily based on @rolandshoemaker's `readme-updates` branch and the closed PR: #3195
The README is restructured to be user-driven. Information that is strictly contributor focused (e.g. dep upgrades) is moved to CONTRIBUTING.md. The review feedback from #3195 from @jsha was all about text that we removed entirely in 29cdd78155
The README now links to the production deployment guide in the wiki and describes our general position on using Boulder.
The CONTRIBUTING.md guide links to the various docs/ pages and was updated.
The docs/acme-divergences page is updated for draft-15.
The DESIGN.md document is moved from the root of the repo into docs/. It has been updated to cover ACMEv2 and precertificates/SCT embedding.
Resolves https://github.com/letsencrypt/boulder/issues/3850
A frequent point of confusion is which ACME draft Boulder implements. Often people imagine (sensibly!) that there is one draft they can reference to understand Boulder.
This commit updates the divergences doc to clarify that it should be used to compare Boulder to whatever the most current ACME draft is and that Boulder doesn't implement a specific draft. This commit also adds a reference to what ACME v1 is and a link to the ACME v2 blog post.
Small references are also added to the "applications" concept from prev. drafts. Otherwise folks that land on older ACME drafts may wonder why the divergences doc doesn't mention "applications", a concept that was renamed to "orders" in subsequent drafts. We do document divergences for "orders" and attention should be directed there.
The IETF working group has published a [draft-06](https://tools.ietf.org/html/draft-ietf-acme-acme-07) and [draft-07 revision of ACME](https://tools.ietf.org/html/draft-ietf-acme-acme-07). This PR updates the Boulder `docs/acme-divergences.md` documentation for both drafts. Primarily this meant updating section numbers and links.
Notable updates:
* Added "index" directory Link divergence
* Removed divergence for "existing" field of authorizations - this was removed from the spec so it isn't a divergence anymore \o/
* Added divergence for the Boulder certificates endpoint not respecting client `Accept` headers and using the `application/pkix-cert` content type in responses vs `application/pem-certificate-chain`
* Added divergence for `unsupportedContact` and `accountDoesNotExist` errors.
* Added divergence for the `only-return-existing` field.
* Added divergence for retrying challenges
* Removed "meta" directory divergence since Boulder supports this now
Resolves#2825
Issue #2365 reported two places where we had divergences from ACME-04 in Boulder's implementation that were not reflected in the divergences doc. This PR documents:
1. That Boulder checks the `resource` field from the protected JWS header instead of the `url` field as described in Section 5.4.1
2. That Boulder uses a response with HTTP status code 409 (Conflict) when returning a Location header for an existing reg while Section 6.3 describes using HTTP status code 200 for this purpose.
This resolves#2365.
The current ACME specification allows certificates to be revoked by a account key for an account that holds valid authorizations for every name in the certificate to be revoked. This PR adds a branch to the existing wfe.RevokeCertificate method which checks if the account key holds the required authorizations if it isn't the key for the issuing account or the certificate key.
Fixes#2318.
Fixes#503.
Functionality is gated by the feature flag `AllowKeyRollover`. Since this functionality is only specified in ACME draft-03 and we mostly implement the draft-02 style this takes some liberties in the implementation, which are described in the updated divergences doc. The `key-change` resource is used to side-step draft-03 `url` requirement.
This PR adds a divergence to the acme-divergence doc for Section 6.6 "Certificate Revocation". Boulder does not currently support authorizing a revocation request using an arbitrary account key that is authorized for the same domains as in the certificate.
Aaron Gable