While Boulder attempts to implement the ACME specification as strictly as possible there are places at which we will diverge from the letter of the specification for various reasons.
This document details these differences, since ACME is not yet finalized it will be updated as numbered drafts are published.
Current draft: draft-ietf-acme-acme-05.
Boulder does not implement the general JWS syntax, but only accepts the flattened syntax.
Boulder enforces the presence of the jwk field in JWS objects, and does not support the kid field.
Boulder does not use the url field from the JWS protected resource. Instead Boulder will validate the resource field from the JWS payload matches the resource being requested. Boulder implements the resource types described in draft-ietf-acme-02 Section 6.1 plus the additional "KeyChange" resource. Boulder verifies the resource field contains the /directory URI for the requested resource.
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.
Boulder doesn't return errors under the urn:ietf:params:acme:error: namespace but instead uses the urn:acme:error: namespace from draft-ietf-acme-01 Section 5.4.
Boulder uses invalidEmail in place of the error invalidContact defined in draft-ietf-acme-01 Section 5.4.
Boulder does not implement the caa and dnssec errors.
Boulder does not implement the new-order resource. Instead of new-order Boulder implements the new-cert resource that is defined in draft-ietf-acme-02 Section 6.5.
Boulder also doesn't implement the new-nonce endpoint.
Boulder implements the new-account ressource only under the new-reg key.
Boulder implements Link: rel="next" headers from new-reg to new-authz, and new-authz to new-cert, as specified in draft-02, but these links are not provided in the latest draft, and clients should use URLs from the directory instead.
Boulder does not implement the meta field returned by the directory endpoint.
Boulder does not implement the terms-of-service-agreed or orders fields in the registration object (nor the endpoints the latter links to).
Boulder does not implement orders, instead it implements the new-cert flow from draft-ietf-acme-02 Section 6.5. Instead of authorizations in the order response, Boulder currently uses authorizations that are created using the new-authz flow from draft-ietf-acme-02 Section 6.4.
Boulder does not implement the scope field in authorization objects.
Boulder doesn't implement the new-nonce endpoint, instead it responds to HEAD requests with a valid Replay-Nonce header per draft-ietf-acme-03 Section 5.4.
Boulder only allows mailto URIs in the registrations contact list.
Boulder uses an HTTP status code 409 (Conflict) response for an already existing registration instead of 200 (OK). Boulder returns the URI of the already existing registration in a Location header field instead of a Content-Location header field.
Boulder does not return the status field.
Boulder implements draft-05 style key roll-over with a few divergences. Since Boulder doesn't currently use the registration URL to identify users we do not check for that field in the JWS protected headers but do check for it in the inner payload. Boulder also requires the outer JWS payload contains the "resource": "key-change" field.
Boulder does not implement orders, instead it implements the new-cert flow from draft-ietf-acme-02 Section 6.5. Instead of authorizations in the order response, Boulder currently uses authorizations that are created using the new-authz flow from draft-ietf-acme-02 Section 6.4. Certificates are not proactively issued, a user must request issuance via the new-cert endpoint instead of assuming a certificate will be created once all required authorizations are validated.
Boulder ignores the existing field in authorization request objects.
Boulder returns an uri instead of an url field in challenge objects.
Boulder uses an HTTP status code 202 (Accepted) response for correct challenge responses instead of 200 (OK) as defined in Section 6.1.
Boulder implements tls-sni-01 from draft-ietf-acme-01 Section 7.3 instead of the tls-sni-02 validation method.
Boulder does not implement the oob-01 validation method.
Boulder uses the urn:acme: namespace from draft-ietf-acme-01 Section 5.4 for errors instead of urn:ietf:params:acme:.