Pack a compact binary name
05A binary name uses one header octet followed by the digest bytes. The suite identifier selects the algorithm and truncation length.
Separate received header c3 has reserved bits 11 and the same six-bit suite3. A receiver ignores those reserved bits; a conforming sender still sends 03.
Source for this drawing: RFC 6920 · Read RFC section 6 ↗
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 top two reserved bits MUST be zero when sending and ignored on receipt. The remaining six bits are the Suite ID.
- The top two reserved bits MUST be zero when sending and ignored on receipt. The remaining six bits are the Suite ID.
- A supported truncation MUST take the leftmost bits in network byte order and MUST be indicated in the name (§2). The initial suite3 is sha-256-120 (§9.4).
- For suite3, 1 header byte + 15 digest bytes is a 16-byte name. Registry status current does not promise suitability for a security purpose (§9.4).
Also RFC6920 §§2,8.2,9.4. Schematic field widths are labeled; actual lengths are computed. Worked values are public RFC examples or fictional teaching data. Naming, locating, and checking integrity are distinct operations.
Read the RFC section ↗