TNAuthList Profile of Automated Certificate Management Environment (ACME) Authority Token
Extracted elements (26)
A client may request an Authority Token scoped to a subset of its own authority. This allows constructing a TNAuthList limited to specific TelephoneNumberRanges or TelephoneNumbers rather than the full scope of an SPC, reducing information exposure to CAs that process the token.
For large or complex noncontiguous sets of telephone numbers, best practice is to split them into multiple STI certificates representing contiguous subsets, rather than encoding an unbounded noncontiguous set in a single identifier object, to avoid excessive identifier object sizes.
The fingerprint in the token request is explicitly not meant to be verified by the Token Authority. Instead, it is signed as part of the token so that the ACME server can verify the token was requested and used by the same party that controls the ACME client, binding the token to a specific account.
The 'token-authority' challenge parameter is currently not used by the SHAKEN (ATIS-1000080) certificate framework governance but may be used by other VoIP frameworks. Its absence requires the ACME client to use locally configured information to identify the Token Authority.
The 'x5u' URL provided in the ACME order object for PASSporT use must respond to a GET request (not POST-as-GET as required for the ACME 'certificate' URL). This requires either the ACME client to download and re-host the certificate, or the CA to host it at a publicly accessible GET endpoint.
If a 'token-authority' parameter is present in the challenge, the ACME client MAY use it to identify the Token Authority URL. If it is not present, the ACME client MUST identify the Token Authority based on locally configured information or local policies.
If all validation steps pass, the ACME server MUST set the challenge object 'status' to 'valid'. If any step of the validation process fails, the 'status' in the challenge object MUST be set to 'invalid'.
If the authorization credentials are invalid or the account identifier does not exist, the Token Authority response code MUST be 403 (Forbidden). Other 4xx and 5xx responses MUST follow standard HTTP error condition conventions (RFC 9110).
In the 'atc' claim, 'tktype' is a required key and MUST be included with value 'TNAuthList'. 'tkvalue' is a required key and MUST be included. 'fingerprint' is a required key and MUST be included; 'ca' is optional and defaults to false if absent.
The 'exp' claim (RFC 7519, Section 4.1.4) MUST be included in the TNAuthList Authority Token and contains the DateTime value of the token's expiration.
The 'jti' claim (RFC 7519, Section 4.1.7) MUST be included and contains a unique identifier for this TNAuthList Authority Token transaction.
The TNAuthList Authority Token payload MUST include the mandatory claims 'exp', 'jti', and 'atc'. The protected header MUST comply with Section 6.2 of RFC 8555 (Request Authentication).
The Token Authority MUST validate that the information in the ASN.1 TNAuthList accurately represents the SPC or TN resources the requesting party is authorized to represent, based on the pre-established and verified relationship between the Token Authority and the requesting party.
The value of the TNAuthList identifier MUST be set to the details of the TNAuthList requested. The string MUST be constructed using base64url encoding without padding characters, and the TNAuthList ASN.1 object MUST be encoded using DER encoding rules.
Any CA that processes an Authority Token can learn what resources a client is authorized to claim. Where this incurs a privacy risk, Authority Token scopes should be limited to only the resources that will be attested by the specific requested ACME certificate, rather than the client's full authorized scope.
An optional 'x5u' field may be added by the ACME server to the order object when the certificate is ready. This URL is suitable for direct reference in the 'x5u' parameter of PASSporT JWS objects and must support plain GET (not POST-as-GET).
Defines a new ACME identifier object type called 'TNAuthList'. The new-order request includes a type set to the string 'TNAuthList' and a value containing the base64url-encoded DER-encoded ASN.1 TNAuthList object representing the identity information to be populated in the certificate.
The ACME client responds to the tkauth-01 challenge by POSTing a JWS object containing a 'tkauth' field with the base64url-encoded TNAuthList Authority Token to the challenge URL from the authorization object.
The 'atc' claim is a JSON object containing four elements: 'tktype' (required, string 'TNAuthList'), 'tkvalue' (required, base64url-encoded DER-encoded TNAuthList ASN.1 object), 'ca' (optional boolean for CA delegation certificate), and 'fingerprint' (required, ACME account key thumbprint per RFC 8555 Section 8.1).
The challenge type used for TNAuthList authorization is 'tkauth-01' with a 'tkauth-type' of 'atc', inherited from RFC 9447. The challenge object may also include a 'token-authority' parameter providing the URL of the Token Authority, and a 'token' nonce.
The TNAuthList Authority Token is a profile instance of the ACME Authority Token (RFC 9447). Its protected header must comply with ACME Request Authentication, and its payload must include 'exp', 'jti', and 'atc' mandatory claims, with 'iss' as an optional claim.
The Token Authority provides tokens via a RESTful HTTP POST to '/at/account/:id/token'. The request body MUST contain a JSON object with 'tktype', 'tkvalue', 'ca', and 'fingerprint' key-value pairs. A successful response returns HTTP 200 with a JSON body containing a 'token' key holding the base64url-encoded atc token.
IANA has added a new identifier object type 'TNAuthList' (referencing RFC 9448) to the 'ACME Identifier Types' registry defined in RFC 8555, Section 9.7.7.
The TNAuthList Authority Token carries credentials scoped to represent telephone numbers, number blocks, or an entire SPC. Its creation, transport, and any storage MUST follow the strictest security best practices, including encrypted transport, to prevent misuse by bad actors for telephone number impersonation.
This document only specifies SHA256 for the fingerprint hash, but the fingerprint object syntax permits other algorithms for future algorithmic agility. Future specifications can define new algorithms as needed; implementations should follow JWT best practices per RFC 8725.
Upon receiving a challenge response, the ACME server performs a nine-step validation process: verify 'atc' JSON structure, verify 'x5u'/'x5c' certificate references, verify the token signature, verify 'tktype' equals 'TNAuthList', verify 'tkvalue' matches the original challenge identifier, verify remaining claims (expiry, etc.), verify 'fingerprint' matches the ACME client account key, and verify 'ca' flag matches the CSR. If all steps pass, the challenge status transitions to 'valid'; any failure transitions it to 'invalid'.