Skip to main content

Module eab

Module eab 

Source
Expand description

External Account Binding (RFC 8555 §7.3.4): verification of the inner HMAC JWS a newAccount payload may carry, proving the client holds a pre-shared credential an operator issued out-of-band.

Pure verification logic only – no database access. acme_proxy_store::eab is the persistence layer for the credentials themselves (create/find/list/ revoke); this module only checks an already-looked-up secret against an already-parsed request. The same split dns and crate::pemfile draw between “how” and “where from”.

§Shape

The inner object is itself a flattened JWS (RFC 7515), reusing crate::jws::AcmeJwsRequest’s {protected, payload, signature} shape as EabJws – the same three-field envelope, HMAC-signed rather than public-key-signed.

Its protected header (EabHeader) is deliberately its own type rather than a reuse of crate::jws::ProtectedHeader: kid is required here (a distinct namespace from the account kid), there is no jwk member, and there is no nonce – this is a credential bound into a request the outer JWS already authenticates and replay-protects, not a second signed request in its own right. A client that sends a nonce anyway has it silently ignored, like any other unknown field the payload types in this codebase accept.

Its payload is the account’s public key, as a plain JWK JSON object – the same Jwk shape the outer JWS embeds – and verification requires the two to be structurally equal (Jwk derives PartialEq), which is what binds the credential to this account key rather than any other.

Structs§

EabHeader
The inner EAB JWS’s protected header. See the module docs for why this is its own type rather than a reuse of ProtectedHeader.

Enums§

EabError
Why EAB verification failed, in the two buckets eab_problem renders as HTTP status: a shape problem the client can fix by resending correctly formed EAB (Malformed, 400), or a signature that plainly does not verify against the looked-up secret (BadSignature, 401). An unknown or revoked kid is not represented here at all: that decision needs the database, so the caller (verify_eab in lib.rs) makes it directly.

Functions§

eab_problem
Maps an EabError to the Problem the caller rejects with. Structural failures – malformed base64/JSON, an unsupported alg, a url mismatch, or a payload JWK that does not match the account’s own – are malformed (400), mirroring how the outer JWS’s own SignatureError splits shape problems from signature-validity ones. A signature that simply does not verify is unauthorized (401), the same as a bad outer JWS signature.
parse_header
Decodes and validates the inner EAB JWS’s protected header: alg must be HS256, and url must equal expected_url – the same URL the outer JWS’s own header.url was already checked against (RFC 8555 §6.4), i.e. this exact newAccount request.
verify_payload_and_signature
Completes EAB verification once kid’s HMAC secret has been looked up: the inner payload must decode to a Jwk structurally equal to the account’s own embedded JWK (outer_jwk), and the HS256 signature over protected_b64.payload_b64 must verify against hmac_secret.

Type Aliases§

EabJws
The inner EAB JWS: the same flattened {protected, payload, signature} shape as the outer request JWS.