Keep recovery separate from trust
05Different parsing strategies can expose different results; record framing provides no cryptographic integrity.
The entire candidate is not one JSON text. Different outputs expose a security boundary; no integrity guarantee follows.
Source for this drawing: RFC 7464 · Read RFC section 3 ↗
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
- Canonical representation
- One uniquely defined textual form; this format does not provide one.
- Integrity protection
- A way to detect unauthorized changes; record separators do not provide it.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Treat input as untrusted even when recovery succeeds.
- All JSON security considerations apply. Parsers must fail gracefully on malicious input; this framing format provides no cryptographic integrity protection.
- With RS "foo" LF 456 LF RS, an incremental parser might produce "foo" and skip the rest, while a parser requiring the entire candidate to be one JSON text might reject it. The RFC presents both possible outcomes, not a required universal acceptance rule.
- Ignored parse failures and these differences can smuggle data past parsers that do not warn. Repeated parsing and re-encoding can add or strip trailing LF bytes and break signature validation. Neither JSON nor this sequence format defines a canonical text representation.
The drawing compares two possible parsing strategies for the same bytes. It does not call one result authenticated, prescribe a signature scheme or claim that warnings alone prevent every attack. Boundary detection, JSON parsing, application policy and integrity checks are separate concerns.
Read the RFC section ↗