Keep integrity and trust separate
07Matching bytes to a name is useful only within an application trust model. A hash name does not identify its author or hide the object.
Anyone can put a domain in a name; low-variation objects can be guessed and hashed. Domain ownership and confidentiality require separate evidence/protection.
Source for this drawing: RFC 6920 · Read RFC section 10 ↗
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
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
The integrity evidence is only as strong as the integrity of the starting name and the selected hash/length. No secret is required to create a matching name.
- The integrity evidence is only as strong as the integrity of the starting name and the selected hash/length. No secret is required to create a matching name.
- Applications MUST NOT infer a relationship between a domain registrant and matching content merely because the ni authority names that domain.
- Malformed ni names MUST NOT match another ni name. Short truncations weaken security; hashes do not protect confidentiality against guessing or lookup.
Also RFC6920 §§2–3,9.4. This is a teaching comparison, not an implemented retrieval, browser-origin policy or cryptographic security certification. Worked values are public RFC examples or fictional teaching data. Naming, locating, and checking integrity are distinct operations.
Read the RFC section ↗