A Conformant Mechanism for Content Binding in Text Streams
draft-condrey-content-binding-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | David Lee Condrey | ||
| Last updated | 2026-04-13 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-condrey-content-binding-00
Individual Submission D. Condrey
Internet-Draft WritersLogic Inc.
Intended status: Informational 10 April 2026
Expires: 12 October 2026
A Conformant Mechanism for Content Binding in Text Streams
draft-condrey-content-binding-00
Abstract
This document proposes a conformant mechanism for binding metadata to
plain text streams using boundary-delimited transport. The mechanism
uses existing ASCII characters to establish a text/non-text boundary,
requiring no new code points and no changes to existing Unicode text
processing algorithms. It defines a delimiter format, a parsing
algorithm, a canonicalization procedure, and correctness criteria
sufficient for two independent implementations to interoperate
without coordination. This RFC is a companion to a Unicode Technical
Standard proposal submitted to the Unicode Technical Committee.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 12 October 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Condrey Expires 12 October 2026 [Page 1]
Internet-Draft Content Binding April 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Prior Art . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. General Structure . . . . . . . . . . . . . . . . . . . . 4
4.2. Primary Mechanism: ASCII Delimiters (No New Code
Points) . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Requirements Satisfaction . . . . . . . . . . . . . . . . 6
4.4. Normalization . . . . . . . . . . . . . . . . . . . . . . 7
4.5. Canonicalization of Text Content . . . . . . . . . . . . 7
4.6. Detection and Parsing . . . . . . . . . . . . . . . . . . 8
4.6.1. ABNF Grammar . . . . . . . . . . . . . . . . . . . . 8
4.6.2. Detection Algorithm . . . . . . . . . . . . . . . . . 9
4.6.3. Error Conditions . . . . . . . . . . . . . . . . . . 10
4.7. Test Vectors . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5.1. Security Model . . . . . . . . . . . . . . . . . . . . . 13
5.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Visibility as a Security Property . . . . . . . . . . . . 15
5.4. Confusable and Homoglyph Concerns . . . . . . . . . . . . 15
5.5. Payload Security . . . . . . . . . . . . . . . . . . . . 15
6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Correctness Criteria . . . . . . . . . . . . . . . . . . 15
7.2. Conformance Requirements . . . . . . . . . . . . . . . . 16
8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
This document specifies a wire format for binding opaque payloads --
signatures, provenance manifests, AI-generated-content markers -- to
plain text streams using boundary-delimited transport: a visible
ASCII start delimiter, an optional header section, a Base64-encoded
payload, and a matching end delimiter. The text preceding the block
is preserved byte-for-byte, satisfying what this document calls the
*Text Self-Containment Invariant*: text MUST remain semantically
complete and self-contained in the absence of any binding mechanism.
OpenPGP cleartext signatures [RFC9580] and PEM-encoded cryptographic
objects [RFC7468] have used this pattern (Class 2, boundary-delimited
transport) for decades. The alternative of hiding metadata inside
the text using invisible or repurposed Unicode characters (Class 1,
Condrey Expires 12 October 2026 [Page 2]
Internet-Draft Content Binding April 2026
in-band encoding) is structurally indistinguishable from
steganographic attacks such as Trojan Source [TROJAN-SOURCE],
GlassWorm [GLASSWORM], and whitespace-replacement techniques
[HELLMEIER2025], and has also been flagged for conformance concerns
by the Unicode Technical Committee [L2-26-042] [L2-25-241]; Class 1
is rejected throughout this document. A companion Unicode problem
statement [L2-26-XXX] presents a related recognition question to the
UTC that is orthogonal to this specification.
*Editor's note:* L2/26-XXX is a placeholder identifier pending UTC
registration and will be updated in a future revision of this draft.
2. Prior Art
Five existing systems occupy nearby points in the design space:
* *OpenPGP cleartext signatures* [RFC9580], 1991. Fixed in-band
ASCII delimiter (-----BEGIN PGP SIGNED MESSAGE-----), Base64
payload, visible, survives copy/paste. Direct precedent.
* *PEM / PKIX / CMS* [RFC7468], originally 1993. Fixed in-band
ASCII delimiter with payload-type label (-----BEGIN
CERTIFICATE-----, etc.), Base64 payload, visible, survives copy/
paste. Direct precedent.
* *MIME multipart* [RFC2046], 1996. Boundary token declared out-of-
band in a Content-Type header. Does not survive copy/paste
because the declaring header is lost.
* *DKIM* [RFC6376], 2007. No body delimiter; signature lives in an
SMTP header field. Does not survive copy/paste.
* *Unicode interlinear annotation characters* (U+FFF9-U+FFFB),
Unicode 3.0 (1999). Dedicated Cf code points delimit annotated
ranges in-band. Invisible to the user, not default-ignorable.
This mechanism follows the PGP/PEM pattern but is payload-agnostic
(no label-to-type binding) and defines an explicit header section.
3. Requirements
In this document, the key words "MUST", "MUST NOT", "SHOULD", and
"MAY" are to be interpreted as described in BCP 14 [RFC2119]
[RFC8174] when, and only when, they appear in all capitals, as shown
here.
Terms used throughout:
Condrey Expires 12 October 2026 [Page 3]
Internet-Draft Content Binding April 2026
* *Text/non-text boundary*: The point in a text stream at which text
processing ends and opaque data begins. Established by a
delimiter (Section 4.2). Content before the boundary is text;
content after it, up to the corresponding end delimiter, is opaque
payload.
* *Content binding block*: A region demarcated by a start delimiter
and an end delimiter, containing an optional header section and a
Base64-encoded payload.
* *Aware implementation*: Software that recognizes content binding
blocks and processes them according to this specification.
* *Unaware implementation*: Software without explicit content
binding support. Unaware implementations treat the block as
ordinary text.
A conformant mechanism must satisfy:
1. No repurposing of existing Unicode characters outside their
defined semantics.
2. The block is logically outside the text for Unicode processing:
it must not participate in grapheme cluster determination,
bidirectional processing, line breaking, normalization,
collation, or default casing. Unaware implementations that treat
it as an ordinary paragraph are acceptable.
3. Survives plain-text operations: copy, paste, transfer, and plain-
text storage.
4. Unambiguously detectable by aware implementations.
5. Degrades gracefully in unaware implementations: text preserved
verbatim, block visible rather than silently stripped.
6. Payload-agnostic via a standard binary encoding (Base64).
7. Clearly distinguishable from adversarial content manipulation.
Payload contents are outside the scope of this document.
4. Specification
4.1. General Structure
A text stream may contain zero or more content binding blocks. The
ABNF grammar (Section 4.6.1) defines the structure: text-content
*(binding-block [text-content]). A block may appear at the start of
the stream, at the end, or between regions of text. Each block
consists of a start delimiter, an optional header section, a
Base64-encoded payload (Section 4 of [RFC4648]; line-wrapped at 76
characters per Section 6.8 of [RFC2045]), and an end delimiter.
Header semantics are defined by higher-level protocols; this document
defines only the syntax.
Condrey Expires 12 October 2026 [Page 4]
Internet-Draft Content Binding April 2026
Aware implementations MUST NOT display the raw Base64 payload as if
it were text content intended for the user, and SHOULD provide a
visual indication that a block is present (e.g., a "content
credentials attached" indicator).
producer consumer
-------- --------
text --+ +--> text
| |
+--> -----BEGIN CONTENT BINDING----- |
| [optional headers] |
payload +--> [Base64 payload] +--> payload
-----END CONTENT BINDING-----
Figure 1: Data flow through a content binding block.
A concrete example with a hypothetical provenance manifest:
The quick brown fox jumps over
the lazy dog.
-----BEGIN CONTENT BINDING-----
Type: application/provenance-manifest+cbor
dGhpcyBpcyBhIHBsYWNlaG9sZGVyIGZvciBh
aWZlc3QgdGhhdCB3b3VsZCBub3JtYWxseSBi
eXRlcyBvZiBCYXNlNjQtZW5jb2RlZCBDQk9S
-----END CONTENT BINDING-----
4.2. Primary Mechanism: ASCII Delimiters (No New Code Points)
The delimiters are -----BEGIN CONTENT BINDING----- and -----END
CONTENT BINDING-----.
Delimiter matching MUST be byte-for-byte and case-sensitive. The
delimiter MUST occupy an entire line, with no leading or trailing
characters other than an optional CR before LF. Visually similar
code points (en-dash U+2013, em-dash U+2014, minus sign U+2212) MUST
NOT match the ASCII hyphen-minus. Per-line matching needs no
lookahead; malformed-block recovery (Section 4.6.2, step 7) rewinds
to the recorded block-start, but that is recovery, not detection.
Normative rules:
* Each delimiter MUST appear on its own line. The start delimiter
MUST be preceded by a blank line (or appear at the beginning of
the text stream). The end delimiter MUST be followed by end-of-
text, a blank line, or another start delimiter.
Condrey Expires 12 October 2026 [Page 5]
Internet-Draft Content Binding April 2026
* Line endings within the content binding block (delimiters,
headers, and Base64 payload) MUST use LF (U+000A).
Implementations MUST accept CRLF and normalize to LF during
parsing. The text content preceding the block MAY use any line-
ending convention.
* The payload region contains an optional header section followed by
Base64-encoded data. Headers, if present, are lines of the form
Name: value using only printable ASCII, terminated by a blank line
before the Base64 data. The header-name grammar (Section 4.6.1)
admits any printable ASCII character except colon; this is
deliberately more permissive than MIME tokens, so higher-level
protocols with their own naming conventions can use content
binding as a transport. Higher-level protocols MAY restrict
header names further within their own namespace.
* Implementations MUST support multiple content binding blocks in a
single text stream.
* Implementations MUST NOT modify the text content preceding the
block.
* Aware implementations MUST NOT present the content binding block
as ordinary text content and SHOULD provide a visual indication of
its presence.
The delimiter string is theoretically possible in ordinary text, but
PGP has shared this risk for three decades without a known collision.
4.3. Requirements Satisfaction
The mechanism satisfies all seven requirements in Section 3:
* _Req 1 (no repurposing)_: ASCII characters are used in their
ordinary capacity.
* _Req 2 (no adverse text-processing effect)_: aware implementations
exclude the block from grapheme, bidi, line-break, normalization,
collation, and casing operations (Unicode Standard Annexes #9,
#14, #15, #29 and UTS #10 [UNICODE]); unaware implementations see
it as an ordinary ASCII paragraph.
* _Req 3 (survives plain-text operations)_: every character is ASCII
and normalization-invariant, as PGP and PEM have demonstrated for
decades.
* _Req 4 (unambiguously detectable)_: exact byte-for-byte string
match.
* _Req 5 (graceful degradation)_: the block is visible in unaware
implementations (like PGP and PEM, unlike DKIM).
* _Req 6 (payload-agnostic)_: opaque Base64; semantics are delegated
to higher-level protocols.
* _Req 7 (distinguishable from adversarial manipulation)_:
visibility (Section 5.3) combined with exact-match rejection of
lookalike delimiters (Section 5.4).
Condrey Expires 12 October 2026 [Page 6]
Internet-Draft Content Binding April 2026
4.4. Normalization
Every character in the delimiters, headers, and Base64 payload is
ASCII, and all ASCII code points are invariant under NFC, NFD, NFKC,
and NFKD (Unicode Standard Annex #15 [UNICODE]). A content binding
block therefore survives any clipboard, storage, or transport layer
that applies Unicode normalization. Aware implementations MUST
detect and extract the block _before_ applying any normalization or
other text transformation to the surrounding text content; otherwise
a transformation applied to the stream could alter the delimiters'
line context.
4.5. Canonicalization of Text Content
Higher-level protocols that sign or digest text content need a
deterministic canonical form; without one, the same logical text
produces different byte sequences across systems and verification
fails. The canonical form of the text content is:
1. Take the text content preceding the first content binding block,
or the entire stream if no block is present.
2. Replace every CR LF (U+000D U+000A) and bare CR (U+000D) with a
single LF (U+000A).
3. Preserve any leading UTF-8 BOM (U+FEFF). Higher-level protocols
that want to exclude the BOM MUST specify that exclusion
themselves.
4. Apply no other modification to the code points. Implementations
MUST NOT apply Unicode normalization (NFC, NFD, NFKC, NFKD) as
part of canonicalization: applying a normalization at the
transport layer would silently alter the text and violate C1.
Because some systems silently normalize on clipboard or storage
(macOS applies NFD; some databases apply NFC), higher-level
protocols that compute signatures SHOULD specify a normalization
form (typically NFC) and apply it at both signing and
verification time.
5. Encode the resulting code point sequence as UTF-8.
Content binding blocks themselves MUST NOT appear in the canonical
form; the signature is computed over the text content only, so
including the block would create a circular dependency. If multiple
blocks are present, each block's signature covers the same canonical
content (the text preceding the first block). Blocks MUST NOT sign
each other; higher-level protocols that need chained signatures MUST
define their own sequencing rules inside the payload.
Condrey Expires 12 October 2026 [Page 7]
Internet-Draft Content Binding April 2026
4.6. Detection and Parsing
This section gives the formal grammar and normative algorithm for
detecting and parsing content binding blocks.
4.6.1. ABNF Grammar
ABNF grammar [RFC5234] for a well-formed content binding block:
text-stream = text-content *(binding-block [text-content])
; text-content: any sequence of Unicode characters not
; containing a start-delimiter at the beginning of a line.
; This production cannot be expressed in ABNF; its boundaries
; are defined by the detection algorithm in Section 4.6.2.
binding-block = blank-line start-line
[header-section] payload-section end-line
start-line = start-delimiter LF
end-line = end-delimiter LF / end-delimiter EOF
start-delimiter = %s"-----BEGIN CONTENT BINDING-----"
end-delimiter = %s"-----END CONTENT BINDING-----"
header-section = 1*header-line blank-line
header-line = header-name ":" SP header-value LF
header-name = 1*(%x21-39 / %x3B-7E) ; printable ASCII except ":"
header-value = *(%x20-7E) ; printable ASCII and SP
blank-line = LF
payload-section = *base64-line [base64-last]
base64-line = 1*76base64-char LF
base64-last = 1*76(base64-char / pad) LF
base64-char = ALPHA / DIGIT / "+" / "/"
pad = "="
LF = %x0A
SP = %x20
EOF = "" ; end of stream
The text-content production cannot be expressed purely in ABNF; its
boundaries are defined operationally by the detection algorithm in
Section 4.6.2. Implementations MUST accept CR LF (%x0D %x0A) in
place of LF in all productions and normalize to LF during parsing.
Condrey Expires 12 October 2026 [Page 8]
Internet-Draft Content Binding April 2026
A leading UTF-8 BOM (U+FEFF) is part of the text content.
Implementations MUST NOT strip it before parsing and MUST preserve it
in the canonical form (Section 4.5). Some I/O libraries silently
strip BOMs on read; applications that use such libraries must re-
introduce the BOM or bypass the stripping.
4.6.2. Detection Algorithm
Normative algorithm:
1. Initialize state to SCANNING. Set block-start to null.
2. Read the next line from the text stream. If end-of-stream, go to
step 8.
3. If state is SCANNING and the line matches start-delimiter
exactly, set state to IN_BLOCK, record block-start position,
initialize an empty header list and an empty payload buffer, set
sub-state to HEADERS, and go to step 2.
4. If state is IN_BLOCK and sub-state is HEADERS, apply the first
matching rule: (4.1) if the line is blank (empty or LF only), set
sub-state to PAYLOAD and go to step 2; (4.2) if the line matches
header-name ":" SP header-value, append it to the header list and
go to step 2; (4.3) otherwise, set sub-state to PAYLOAD and
process this line as step 5.
5. If state is IN_BLOCK and sub-state is PAYLOAD, apply the first
matching rule: (5.1) if the line matches end-delimiter exactly,
go to step 6; (5.2) if the line contains only characters in the
Base64 alphabet, padding, and whitespace, append it to the
payload buffer and go to step 2; (5.3) otherwise, the block is
malformed and go to step 7. The lenient handling of whitespace
in 5.2 is consistent with Section 6.8 of [RFC2045]; the ABNF
grammar describes the canonical form for conformant producers and
does not constrain lenient parsing by consumers.
6. Block complete. Decode the payload buffer as Base64 (Section 4
of [RFC4648]). If decoding fails, the block is malformed; go to
step 7. Otherwise, emit a parsed binding block (headers, decoded
payload), set state to SCANNING, and go to step 2.
7. Malformed block. Discard accumulated headers and payload buffer.
Treat all content from block-start through the current position
as ordinary text. Set state to SCANNING. Go to step 2.
8. End of stream. If state is IN_BLOCK, the block is unclosed;
treat all content from block-start onward as ordinary text. Emit
any accumulated text content. Terminate.
In all cases, the text content preceding and between binding blocks
is preserved unmodified.
Condrey Expires 12 October 2026 [Page 9]
Internet-Draft Content Binding April 2026
4.6.3. Error Conditions
+===========+==============================+=======================+
| Condition | Detection | Required behavior |
+===========+==============================+=======================+
| Unclosed | End-of-stream reached after | Treat block-start |
| block | start-delimiter without | through end-of-stream |
| | matching end-delimiter | as ordinary text |
+-----------+------------------------------+-----------------------+
| Invalid | Characters outside Base64 | Reject block; |
| Base64 | alphabet, padding, and | preserve all text |
| | whitespace in payload region | verbatim |
+-----------+------------------------------+-----------------------+
| Truncated | Valid Base64 characters but | Reject block; |
| Base64 | incorrect padding | preserve all text |
| | | verbatim |
+-----------+------------------------------+-----------------------+
| Nested | start-delimiter appears | Treat as malformed |
| start | inside an open block's | payload; reject block |
| | payload region | |
+-----------+------------------------------+-----------------------+
| Empty | No Base64 lines between | Valid; block carries |
| payload | headers and end-delimiter | empty payload |
+-----------+------------------------------+-----------------------+
| Non-ASCII | Code points outside | Reject block; |
| header | U+0020-U+007E in header-name | preserve all text |
| | or header-value | verbatim |
+-----------+------------------------------+-----------------------+
| Missing | Header lines not terminated | Parser treats first |
| blank | by blank line before payload | non-header, non-blank |
| line | | line as payload start |
| | | (lenient) |
+-----------+------------------------------+-----------------------+
Table 1
4.7. Test Vectors
Test vectors for correct parsing and canonicalization. Two
implementations that agree on these outputs are interoperable.
*Vector 1: Single block, no headers.*
Input (LF line endings):
Condrey Expires 12 October 2026 [Page 10]
Internet-Draft Content Binding April 2026
Hello, world.
This is a test.
-----BEGIN CONTENT BINDING-----
SGVsbG8=
-----END CONTENT BINDING-----
Expected parse result:
* Text content: Hello, world.\nThis is a test. (29 bytes)
* Blocks: 1, no headers, payload = Hello (5 bytes)
* Trailing text: (empty)
Canonical form:
* UTF-8 hex:
48656c6c6f2c20776f726c642e0a54686973206973206120746573742e
* SHA-256:
02b5eda2f3782995430bba0bb2c650fe6f872ae9b253b616da17e81a297c9f43
*Vector 2: CRLF normalization.*
Same input as Vector 1 but with CR LF (0D 0A) line endings
throughout. The canonical form MUST produce the same UTF-8 hex and
SHA-256 as Vector 1 after CR LF is normalized to LF.
*Vector 3: Malformed block (invalid Base64).*
Input:
Some text.
-----BEGIN CONTENT BINDING-----
Not valid base64!@#$
-----END CONTENT BINDING-----
Expected parse result:
* Text: Some text. (10 bytes)
* Blocks: 0 (rejected as malformed)
* Block region preserved as ordinary text
Malformed blocks MUST NOT be interpreted as valid. No partial
decoding or recovery heuristics.
*Vector 4: Headers, multiple blocks, interleaved text.*
Condrey Expires 12 October 2026 [Page 11]
Internet-Draft Content Binding April 2026
Input:
First paragraph.
-----BEGIN CONTENT BINDING-----
Type: application/provenance-manifest+cbor
cHJvdmVuYW5jZSBtYW5pZmVzdCBwbGFj
ZWhvbGRlcg==
-----END CONTENT BINDING-----
Second paragraph.
-----BEGIN CONTENT BINDING-----
Type: application/signature
ZGlnaXRhbCBzaWduYXR1cmUgcGxhY2Vo
b2xkZXI=
-----END CONTENT BINDING-----
Expected parse result:
* Text: First paragraph. (16 bytes)
* Block 1: provenance-manifest+cbor, 31 bytes
* Trailing: Second paragraph.
* Block 2: signature, 28 bytes
Canonical form of text content (Section 4.5):
* UTF-8 hex: 4669727374207061726167726170682e
* SHA-256:
98ea01bc109a52fdf7145c10c648e8b27b8ebc877aaa79405f20b044ecfcacaa
Two independent reference implementations (Python and Rust) sharing
no code, built against the normative algorithm in Section 4.6.2, are
available at https://github.com/writerslogic/unicode-content-binding.
Both produce identical parse results for the test vectors above,
satisfying C2 and C3.
5. Security Considerations
Condrey Expires 12 October 2026 [Page 12]
Internet-Draft Content Binding April 2026
5.1. Security Model
The content binding mechanism provides no authenticity, integrity, or
confidentiality guarantees. It defines only a transport for
associating opaque data with text content. Authenticity and
integrity MUST be established by higher-level protocols operating on
the decoded payload. An attacker can construct a syntactically valid
block with arbitrary payload content.
5.2. Threat Model
The mechanism operates in an environment where an attacker has full
control over the text stream.
Condrey Expires 12 October 2026 [Page 13]
Internet-Draft Content Binding April 2026
+============+=========+========+===============================+
| Threat | Mit. | By | Notes |
+============+=========+========+===============================+
| T1: | No | HLP | Anyone can construct a valid |
| Injection | | | block. Authentication lives |
| | | | in the payload, not the |
| | | | delimiter. |
+------------+---------+--------+-------------------------------+
| T2: | No | HLP | Stripping a block is trivial |
| Removal | | | and silent. Protocol must |
| | | | reference expected bindings |
| | | | so absence is detectable. |
+------------+---------+--------+-------------------------------+
| T3: | No | HLP | Enforce in payload if |
| Reordering | | | ordering matters. |
+------------+---------+--------+-------------------------------+
| T4: | *Yes* | Mech | The one threat this layer |
| Spoofing | | | closes. Exact byte match; |
| | | | en-dash, em-dash, minus sign |
| | | | all rejected. |
+------------+---------+--------+-------------------------------+
| T5: Text | Partial | Both | C1 preserves text byte-for- |
| mod | | | byte. Detecting tampering |
| | | | requires the payload |
| | | | signature, not the mechanism. |
+------------+---------+--------+-------------------------------+
| T6: | No | HLP | Same as any Base64 blob: |
| Payload | | | integrity via signatures. |
| mod | | | |
+------------+---------+--------+-------------------------------+
| T7: | No | HLP+UI | The most subtle attack. |
| Trailing | | | Signature covers text before |
| text | | | first block only; appended |
| | | | text looks continuous. UI |
| | | | SHOULD mark the boundary. |
+------------+---------+--------+-------------------------------+
| T8: Replay | No | HLP | Bind signatures to document |
| | | | identity. Without that, any |
| | | | document with identical text |
| | | | validates. |
+------------+---------+--------+-------------------------------+
Table 2
Condrey Expires 12 October 2026 [Page 14]
Internet-Draft Content Binding April 2026
5.3. Visibility as a Security Property
The mechanism's defense against confusion with adversarial text
manipulation is its visibility (Section 1). A content binding block
is visible by default: unaware implementations render it as ordinary
text, aware implementations acknowledge it (e.g., collapsed to an
indicator). In either case the user can see that metadata is
present, and an attacker cannot inject a block without producing a
visible artifact. In-band encoding schemes have no analogous
property because their entire attack surface is invisible.
5.4. Confusable and Homoglyph Concerns
The ASCII hyphen-minus U+002D in the delimiter has visual lookalikes
in Unicode (en-dash U+2013, em-dash U+2014, minus sign U+2212, and
others) that an attacker could use to construct a spoofed block. The
byte-for-byte matching rule in Section 4.2 closes this avenue:
lookalikes are rejected and no lookalike-to-ASCII normalization is
performed before comparison.
5.5. Payload Security
Payload security is outside the scope of this document. Base64
encoding confines the payload region to printable ASCII, preventing
in-band injection of control characters or bidirectional overrides
[UNICODE]. Implementations that decode a payload MUST treat the
result as untrusted input.
6. Compatibility
The mechanism does not change the meaning of any existing text. The
exact string -----BEGIN CONTENT BINDING----- does not appear in any
public code repository (GitHub, as of 2026), any IANA or [RFC7468]
label registry, or any known natural-language corpus. PGP, SSH, PEM,
and content binding blocks coexist unambiguously because they are
distinguished by label, and the "CONTENT BINDING" label is disjoint
from the RFC 7468 registry (which covers PEM-type encodings of DER/
ASN.1 structures).
7. Conformance
7.1. Correctness Criteria
An implementation is correct if and only if it satisfies all of these
properties:
Condrey Expires 12 October 2026 [Page 15]
Internet-Draft Content Binding April 2026
*C1. Text preservation.* The text content preceding and between
content binding blocks MUST be preserved byte-for-byte, including any
leading UTF-8 BOM. Extracting the text content and encoding it as
UTF-8 MUST produce a byte sequence identical to the canonical form of
the original text content (Section 4.5).
*C2. Deterministic boundary detection.* Given the same input text
stream, all conformant implementations MUST identify the same text/
non-text boundaries at the same positions. Boundary detection MUST
NOT depend on locale, platform, configuration, or payload content.
*C3. Deterministic parsing.* Given the same input text stream, all
conformant implementations MUST produce the same parse result: the
same text content, the same number of blocks, the same headers, and
the same decoded payload bytes.
*C4. Payload opacity.* An implementation MUST NOT interpret,
transform, validate, or act on the decoded payload.
*C5. All-or-nothing rejection.* A malformed block MUST be rejected
as a whole. Implementations MUST NOT partially decode the payload,
extract a subset of headers, or interpret any portion of a malformed
block as valid. On rejection, the entire region from start-delimiter
through the point of failure MUST be treated as ordinary text
(Section 4.6.3).
*C6. Round-trip stability.* Parsing a text stream, extracting the
text content, and re-appending the same content binding blocks MUST
produce a text stream that parses identically to the original.
7.2. Conformance Requirements
A conformant aware implementation MUST satisfy correctness criteria
C1 through C6 (Section 7.1), using the delimiter strings from
Section 4.2, the detection algorithm from Section 4.6.2, and the
error handling from Section 4.6.3.
8. Summary
The mechanism is intended for protocol designers who need to bind
signed or opaque data to plain text in environments where out-of-band
metadata channels (MIME headers, HTTP headers, file-format wrappers)
are unavailable or unreliable. Two independent reference
implementations exist at the URL in Section 4.7. Feedback is welcome
via the IETF mailing list.
Condrey Expires 12 October 2026 [Page 16]
Internet-Draft Content Binding April 2026
9. IANA Considerations
This document has no IANA actions.
10. References
10.1. Normative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References
[GLASSWORM]
Dardikman, I., "GlassWorm: First Self-Propagating Worm
Using Invisible Code Hits OpenVSX Marketplace", 18 October
2025, <https://www.koi.ai/blog/glassworm-first-self-
propagating-worm-using-invisible-code-hits-openvsx-
marketplace>.
[HELLMEIER2025]
Hellmeier, M., Qarawlus, H., Norkowski, H., and F. Howar,
"A Hidden Digital Text Watermarking Method Using Unicode
Whitespace Replacement", HICSS 58, 2025.
[L2-25-241]
Casper, S., Bommasani, R., Reuel, A., Dai, J., Longpre,
S., Bailey, L., and K. Oyin, "UTC Proposal: Watermark
Condrey Expires 12 October 2026 [Page 17]
Internet-Draft Content Binding April 2026
Symbols for AI Training Consent and Text Provenance",
Unicode Document Register L2/25-241, October 2025,
<https://www.unicode.org/L2/L2025/25241-ai-
watermarks.pdf>.
[L2-26-042]
Constable, P. and J. Hadley, "Embedded Metadata in 'Plain'
Text", Unicode Document Register L2/26-042, 13 January
2026, <https://www.unicode.org/L2/L2026/26042-embedded-
metadata-in-plain-text.pdf>.
[L2-26-XXX]
Condrey, D., "Text-Processing Exclusion Zones for
Boundary-Delimited Regions", Unicode Document
Register L2/26-XXX, April 2026.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996,
<https://www.rfc-editor.org/info/rfc2046>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>.
[RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX,
PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468,
April 2015, <https://www.rfc-editor.org/info/rfc7468>.
[RFC9580] Wouters, P., Ed., Huigens, D., Winter, J., and Y. Niibe,
"OpenPGP", RFC 9580, DOI 10.17487/RFC9580, July 2024,
<https://www.rfc-editor.org/info/rfc9580>.
[TROJAN-SOURCE]
Boucher, N. and R. Anderson, "Trojan Source: Invisible
Vulnerabilities", 32nd USENIX Security Symposium, August
2023, <https://trojansource.codes/>.
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version
17.0.0 -- Core Specification", 9 September 2025,
<https://www.unicode.org/versions/Unicode17.0.0/>.
Author's Address
David Condrey
WritersLogic Inc.
Email: david@writerslogic.com
Condrey Expires 12 October 2026 [Page 18]