Visual RFC.
ALL RFCs / RFC 7468
Read the RFC ↗
RFC 7468 / TEXTUAL SECURITY OBJECTS

Parse transport variations without inventing trust

04

A parser receives text from files, mail or copied documents. It must cope safely with transport variations while applying a deliberate policy for what objects to accept.

RFC 7468 · § 2EXAMPLE
4 / 4
Parse transport variations without inventing trustTwo CERTIFICATE instances remain separate in a bundle; context decides order and acceptance, and no trust path is asserted.Handle transport carefullyBundlescan each blockCERTIFICATE block ACERTIFICATE block BKeep two objects, not one merged bodyOrder and acceptance depend on useNo certification path is validatedSafe handling does not mean accept everything
04
Handle each instance in a bundle.

Two schematic CERTIFICATE blocks remain two separate objects. Their order is retained in this display, but the calling context decides its meaning and which objects are acceptable. No path-validation result is shown.

Source for this drawing: RFC 7468 · Read RFC section 2 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
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.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Robust handling and broad acceptance are different decisions.

  • Data before an opening boundary is permitted; parsers MUST NOT malfunction on it. Parsers MUST handle different newline conventions: CRLF (carriage return followed by line feed), CR (carriage return) and LF (line feed). Malformed data MUST be handled gracefully, not allowed to cause a crash or security vulnerability.
  • Parsers SHOULD ignore whitespace and other non-Base64 characters; parsers MAY handle other line sizes. Figure 1’s standard grammar, Figure 2’s lax grammar and Figure 3’s strict output form illustrate different choices. Parsing strategy depends on context, so generator requirements are not universal parser rejection rules.
  • Whitespace here includes ASCII tab, vertical tab, form feed, space, carriage return and line feed. Broadly lax parsing can accidentally accept a snippet that was not intended as input. Compatibility needs and security policy must both be considered.
  • A file MAY contain multiple textual instances. Whether their order matters depends on the context. A certificate bundle does not by itself prove a valid certification path or authorize importing every included object.
DETAILS

The local teaching reader accepts whitespace and all three line endings, but rejects mismatched labels and noncanonical Base64 under its chosen bounded policy. It is not a complete RFC parser or an ASN.1 validator.

Read the RFC section ↗

All chapters in RFC 7468

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗