# RFC 7468 Textual Encoding Companion
`base64-ng-pem` owns the complete textual encoding boundary that the core
`PEM_BODY_LF` and `PEM_BODY_CRLF` values intentionally do not claim. Its
normative source is the locked April 2015 RFC 7468 text plus the repository's
reviewed errata disposition.
## Exact Scope
The companion parses and generates:
- case-sensitive `-----BEGIN <label>-----` and `-----END <label>-----`
encapsulation boundaries;
- RFC 7468 label syntax and canonical uppercase generation;
- Standard padded RFC 4648 Base64 bodies;
- strict 64-character non-final body lines, one nonempty 4–64 character final
quantum line, and explicit line endings;
- bounded explanatory or adjacent text and multiple ordered blocks; and
- an explicit compatible parser with a deviation report.
It does not parse or validate the decoded ASN.1 structure. A `CERTIFICATE`
label therefore does not prove that the payload is an X.509 certificate.
Legacy RFC 1421/OpenSSL encapsulated headers, OpenPGP armor, and OpenSSH key
files are different formats and are rejected or handled by other companions.
## Security Boundary
Ordinary parsing is transactional at the document return boundary but returns
ordinary non-wiping `Vec<u8>` payloads. Detailed errors and compatible parsing
are not secret-safe.
The `secrets` feature provides only `parse_pem_secret_block`. It requires one
strict block and an exact expected label before decoding. Encoded body storage
is wiped on drop; decoded plaintext remains inside the core `SecretVecFrame`
until its fixed-work validation gate succeeds and is then returned as a
clear-on-drop `SecretVec`. This does not provide memory locking, prevent swap,
or establish a formal constant-time guarantee.
## Finite Resources
Every operation has explicit limits for source bytes, generated bytes, total
decoded payload, physical line length, label length, number of blocks,
adjacent text, and work before output. Incremental collection cannot exceed
the same input limit and latches terminal after a failure. Both
`PemDocumentParser` and `PemBlockEncoder` are chunk-partition independent;
their final return boundary remains transactional.
Parser work is a cumulative conservative byte-pass budget. Source scanning,
boundary and label classification, legacy-header checks, body compaction,
Base64 validation, exact decoded sizing, and final decoding all charge the
same operation budget. The default work ceiling is twelve times the default
input ceiling so canonical documents retain headroom for every legitimate
pass while callers can select a tighter reviewed policy.
Document parsing consumes physical lines through a cursor and retains no
document-wide line index. Body-layout validation also uses constant-size
metadata, so newline-dense input cannot amplify into per-line heap records.
Both BEGIN and END labels are length-checked before ownership allocation.
## Compatibility
Strict parsing follows the RFC's Figure 3 shape. Compatible parsing accepts
the RFC's documented parser latitude, including CR, LF, CRLF, line-width
variation, bounded ignored body bytes, boundary blanks, and mismatched END
labels. Empty Base64 text remains available only through that compatible
parser; strict parsing and every final generation API reject it because Figure
3 requires a final quantum. `PemBlockEncoder::new` still succeeds before any
payload arrives, but finishing it without an update fails transactionally.
These choices are never silent: `PemParseReport` records deviations.