ToppyMicroServices

RFC 7638 Quiz (EN)

JSON Web Key (JWK) Thumbprint

ENJA
0 / 0

Primary reference

These questions separate deterministic key identification from key provenance, proof of possession, key attributes, and authorization. Section numbers refer to RFC 7638.

Q1: What is a JWK Thumbprint?

Multiple Choice
RFC 7638 Sections 2 and 3 define a JWK Thumbprint as the digest of a precisely constructed JWK representation. That calculation identifies key material; it neither validates a certificate path nor proves possession, owner approval, or authorization. The protocol that consumes the identifier must define those later meanings.

Q2: Which two changes make this implementation follow the RFC 7638 calculation?

Multi-Select

Two agents receive semantically equivalent JWKs with different member order, whitespace, and optional metadata. Their current code hashes each received JSON document unchanged, so it produces different identifiers for the same key.

RFC 7638 Section 3 constructs a JSON object from the required members only, orders their names lexicographically, emits no whitespace, encodes the result as UTF-8, and hashes those octets. Section 3.2.2 deliberately excludes optional members, while Sections 3.3 and 4 do not add Unicode normalization. Interoperability therefore depends on matching the specified members, characters, order, and octets before hashing.

Q3: Which member set should the verifier place in the RSA thumbprint input?

Multiple Choice

A verifier receives an RSA public JWK containing alg, e, kid, kty, n, use, and x5c. It must recompute the RFC 7638 thumbprint used by its peer.

RFC 7638 Section 3.2 specifies `e`, `kty`, and `n`, in that lexicographic order, for an RSA public-key thumbprint. Values such as `alg`, `kid`, `use`, and `x5c` are optional metadata and Section 3.2.2 intentionally excludes them. The hash input comes from the key type's required representation, not from every member that happened to arrive.

Q4: A JWK's kid, use, and alg change while its required key members remain identical. What happens to its thumbprint?

Multiple Choice
RFC 7638 Section 3.2.2 excludes optional members so equivalent representations of the same key produce the same thumbprint. Fields such as `kid`, `use`, and `alg` may remain in the JWK but are not copied into the hash input. The resulting stability is useful for key identification, but it also means the thumbprint does not bind those metadata values to the key.

Q5: Which calculation should both components use for the shared key-pair identifier?

Multiple Choice

A signing service stores a private RSA JWK, while a verifier stores only the corresponding public JWK. The components must independently derive the same RFC 7638 identifier without exposing private parameters.

RFC 7638 Section 3.2.1 defines a private key's thumbprint as the thumbprint of its corresponding public key. This lets holders of either half refer to the same pair without hashing private parameters or unrelated encryption metadata. The identifier therefore names the pair through its public representation; application context must still distinguish public from private use.

Q6: Which two review conclusions correctly separate opaque lookup from recomputation? Select two.

Multi-Select

Profile P requires independent thumbprint recomputation across agents. Profile Q only transports a producer-generated thumbprint as an opaque kid lookup value. Neither profile currently states a hash function.

RFC 7638 Section 3.4 assigns hash selection to the application and requires parties that reproduce a thumbprint to agree on that choice. It presents SHA-256 as a good default at publication time, not an eternal mandate, and defines no length-based algorithm inference. A consumer using a thumbprint-valued `kid` only as an opaque lookup value need not recompute it; a profile that compares calculations must identify the algorithm.

Q7: Which implementation produces the interoperable thumbprint?

Multiple Choice

Library A hashes JSON.stringify(receivedJwk), preserving input order and alg. Library B constructs a new object containing only required members, sorts member names by Unicode code point, emits no whitespace, and hashes its UTF-8 bytes.

RFC 7638 Sections 3 and 3.3 require the implementation to select only required members, sort their names lexicographically, remove whitespace, and hash the UTF-8 octets. Section 3.2.2 excludes optional `alg`, and Section 4 warns that a generic `JSON.stringify` call does not guarantee the sorting step. Semantically equivalent JSON can differ byte-for-byte, so the constructed octets must be checked before comparing digests.

Q8: What may the relying party conclude from this thumbprint match?

Multiple Choice

An Agent Card records thumbprint T for a public key. A later JWK independently computes to T under the profile's agreed SHA-256 rule, but the card itself came from an untrusted directory.

RFC 7638 Sections 3 and 3.2.2 make the thumbprint an identifier for the required key material while excluding associated attributes. Equality can therefore show that two representations name the same key under the calculation, but it cannot authenticate the source, excluded metadata, fresh possession, or authorization. Those properties require separate provenance and protocol checks.

Q9: Which two findings prevent the service from justifying these security uses under Section 7?

Multi-Select

A service publishes SHA-256 thumbprints of low-entropy symmetric keys in logs. It also accepts non-canonical RSA encodings and uses thumbprint inequality as a blacklist for banned keys.

RFC 7638 Section 7 says a symmetric-key thumbprint should typically be concealed unless the application context and hash provide sufficient protection against disclosure; this is a conditional recommendation, not a categorical publication ban. It also says thumbprint comparison is not a reliable key blacklist and conditions uniqueness on a validated, unambiguous JWK representation. Here, the stated low entropy defeats the service's disclosure justification, while acceptance of non-canonical encodings defeats its blacklist assumption.

Q10: Which assessment correctly composes the thumbprint, proof, and backend decision?

Multiple Choice

An OAuth token names JWK Thumbprint T. An A2A gateway verifies a fresh proof made with a JWK that computes to T, then forwards only X-Key-Thumbprint: T to a backend that owns authorization. The header is not integrity-protected from other internal callers.

RFC 7638 Sections 3 and 3.2.2 provide stable key identification, subject to the representation limits in Section 7. A thumbprint contains no nonce, request, or channel binding, so it cannot stand in for fresh possession; re-hashing it cannot recreate a signature. OAuth claim trust, integrity of a derived assertion across hops, and the backend's final authorization decision remain separate guarantees with separate verifiers.