Automated Certificate Management Environment (ACME) Challenges Using an Authority Token
Extracted elements (22)
An Authority Token may attest all resources a client is eligible for, not just those in the current certificate request. This pre-authorization allows the client to avoid returning to the Token Authority for subsequent narrower-scope certificates within the token's expiry period.
Binding an Authority Token to an ACME account fingerprint (rather than a per-challenge nonce) allows the token to be reused across multiple challenges within its lifetime. This is intentional for short-lived certificate workflows where challenges are issued more frequently than tokens should be refreshed.
To use the 'tkauth-01' validation method with an ACME Identifier Type other than 'TNAuthList', that identifier type must be listed in a new registration in the ACME Validation Methods registry; the current registration is scoped only to 'TNAuthList'.
Definitions of a tkauth-type MUST specify how they manage the freshness of authority assignments, because the assignment of resources can change over time.
For the 'atc' tkauth-type, the JWT MUST contain a 'jti' element and an 'exp' claim; the 'exp' claim manages token freshness and the 'jti' supports replay prevention and tracking of token reuse across multiple challenges.
Implementations compliant with this specification MUST support an HTTPS interface for Authority Token acquisition; other interfaces MAY be supported as well.
It is RECOMMENDED that the ACME account fingerprint be used as the binding in an Authority Token to correlate tokens with a specific ACME client and prevent replay or cut-and-paste attacks.
On successful authorization, the Token Authority MUST return HTTP 200 OK with a body of type 'application/json' containing the Authority Token.
Protocols used to request an Authority Token MUST convey to the Token Authority the identifier type and value used in the ACME challenge as well as the binding; these MUST be reflected in the issued Authority Token.
The JWT payload MUST contain a new 'atc' claim (Authority Token Challenge) with three mandatory elements: 'tktype' (ATC identifier type, restricted to ACME Identifier Types registry values), 'tkvalue' (identifier value), and 'fingerprint' (binding).
Any CA that sees an Authority Token can learn information about all resources a client can claim. Where this incurs a privacy risk, Authority Token scopes should be limited to only the resources attested by the requested ACME certificate rather than the full entitlement.
The ACME Authority Token Challenge type is identified as 'tkauth-01'. It includes a 'tkauth-type' field to indicate the token subtype and an optional 'token-authority' field to designate a location where a token can be acquired.
The 'atc' tkauth-type specifies a standard JWT (RFC 7519) signed with JWS (RFC 7515). It may be used for any number of different ACME Identifier Types. A non-JWT Authority Token format requires a different tkauth-type.
The optional boolean 'ca' element in the 'atc' claim, when set to true, indicates the Token Authority grants permission to issue a CA certificate rather than an end-entity certificate. If absent, permission for CA issuance is explicitly withheld.
Token acquisition uses an HTTPS POST to a Token Authority URI of the form '/at/account/:id/token'. The request body MUST contain the 'atc' Authority Token Challenge element specifying the requested scope via 'tkvalue', and optionally 'ca'.
IANA has added the 'atc' claim (Authority Token Challenge) to the 'JSON Web Token Claims' registry as defined in RFC 7519.
IANA has added the 'tkauth-01' validation method for identifier type 'TNAuthList' to the 'ACME Validation Methods' subregistry of the ACME Protocol registry group.
IANA has created a new 'ACME Authority Token Challenge Types' registry under a Specification Required policy. Initial entry is 'atc' (JWT challenge type, defined in Section 4). New tkauth-types must address the requirements in Section 3.1.
All ACME transactions and HTTPS REST transactions for token acquisition MUST use TLS to prevent eavesdroppers from capturing Authority Tokens. A preexisting trust relationship between the HTTPS REST client and Token Authority is required for mutual authentication.
All Authority Tokens MUST contain a fingerprint field identifying the ACME client that requested the token, and MUST specify an expiry. ACME services SHOULD NOT issue certificates with a longer expiry than the Authority Token's expiry.
Any protocol used to retrieve Authority Tokens from a Token Authority MUST use confidentiality to prevent eavesdroppers from acquiring tokens. Although a captured fingerprint could be replayed, the ACME server's fingerprint check prevents unauthorized certificate issuance to a different account.
The 'atc' JWT claim is a JSON map with mandatory fields 'tktype' (string, ACME identifier type), 'tkvalue' (string, identifier value), 'fingerprint' (string, ACME account fingerprint), and optional 'ca' (boolean). The JWT header typically carries 'x5u' or 'x5c' for the Token Authority certificate.