Validate representation and preserve trust boundaries
05A repeatable fingerprint identifies a representation. It does not replace key validation, authentication or a complete key-management policy.
An identifier can locate a candidate key. It is not a signature, certificate-chain validation, proof of possession or authorization decision.
Source for this drawing: RFC 7638 · Read RFC section 7 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
- Provenance
- Evidence of where a key came from and why the application trusts it.
- Representation validation
- Checking that fields use the required unambiguous encoding before relying on the fingerprint.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Validate the correct JWK representation before relying on uniqueness for a given key. RSA e AQAB encodes 01 00 01; the incorrect leading-zero spelling AAEAAQ encodes 00 01 00 01 and changes the thumbprint.
- Validate the correct JWK representation before relying on uniqueness for a given key. RSA e AQAB encodes 01 00 01; the incorrect leading-zero spelling AAEAAQ encodes 00 01 00 01 and changes the thumbprint.
- Comparing thumbprints is not a reliable way to blacklist a key or its transformations. RFC 7638 describes a modified RSA modulus 3*N that appears different but can still work about one third of the time.
- A thumbprint alone proves neither who owns a key nor possession of its private part. Key selection must be followed by the application’s actual validation and authorization checks.
- This is a digest over the specified JWK JSON representation, not the digest of an entire X.509 certificate or of its ASN.1 SubjectPublicKeyInfo bytes. A non-JWK key can be used if its defined JWK representation and required key material are available.
The leading-zero example is a validation failure, not an instruction to silently rewrite arbitrary received keys. The blacklist scene rejects the inference that a different digest makes a transformed key safe; it does not demonstrate a real attack. Lookup arrows do not imply a successful signature. Hash-function agreement is needed when recomputing and comparing results, while opaque kid lookup alone does not require the consumer to recompute it.
Read the RFC section ↗