Summary

  • draft-ietf-dtn-eid-pattern-11 defines text and CBOR forms for selecting sets of Bundle Protocol Endpoint IDs and a PKIX BundleEIDPattern OtherName for certificates.
  • The draft deliberately separates RFC 5280 path validation from the later check of a concrete Node ID against pattern constraints. A valid chain can therefore reach a second identity gate and fail there.
  • A match is local to a processor and use: supported schemes, normalization, elision, size limits and higher-level AND/NOT rules can all change the result or its consequence.

A valid chain is only the first verdict

Imagine a TCPCL peer presenting an end-entity certificate whose chain is cryptographically valid. Every signature verifies. The issuing path reaches an accepted trust anchor. Yet the claimed DTN Node ID is rejected.

Revision 11 makes that outcome correct. Its proposed BundleEIDPattern name form can appear in a Subject Alternative Name and in CA Name Constraints. But EID Patterns have no general-purpose subset relation. A pattern in a CA certificate therefore cannot directly constrain subordinate EID or EID-Pattern SANs during ordinary RFC 5280 path validation. The draft moves that work to ultimate identity validation: the concrete Node ID must satisfy every relevant permitted pattern and avoid every excluded one across the path.

The two verdicts answer different questions. Path validation asks whether the certificate chain is structurally and cryptographically acceptable. Node-ID validation asks whether this particular peer identity is inside the sets the chain permits. A certificate dashboard that records only “valid” erases the second gate.

The document is revision 11, dated 23 September 2026 and expiring 27 March 2027. Datatracker records an active DTN Working Group Internet-Draft and exposes no intended RFC status; the draft header says Standards Track. Those are separate observations, not evidence of an RFC, consensus, implementation or deployment.

The same characters can carry two types

Bundle Protocol uses EIDs as source and destination identifiers. BPSec uses an EID for a security-source identity, and TCPCL uses one for peer identity. Implementations also need sets of EIDs for routing, forwarding, delivery, security policy and convergence-layer policy.

The draft gives those sets a common representation. An EID Pattern can group by node, service or both, with scheme-specific matching and compact ipn ranges. But the notation contains an important type hazard: a one-item text pattern can be identical to the exact EID it matches. The characters alone do not say whether the value is an identifier or a selector. Context must.

That distinction is an access boundary. The security section warns that interpreting an EID as a pattern can elevate access. An initial | can make text unambiguously pattern-shaped, while PKIX distinguishes the values with separate OtherName forms. Systems that reduce both to one generic string surrender that protection before matching begins.

A normalized set may lose its history

Pattern items are logically unordered. Processors may deduplicate, reorder, canonicalize or normalize them. They may discard the original encoding after retaining an equivalent internal set. That is efficient for matching and insufficient for audit unless the application preserves the input separately.

Two processors can also reach different results from the same any-SSP pattern. One may know both the integer and text names of a scheme; another may not. If an encoder elides one form on an assumption about every decoder, the second processor may fail to reconstruct the same set. A future implementation can support a scheme that an older one skipped. A software upgrade can therefore change the meaning of stored configuration without changing its visible text.

The common primitive supplies OR within one pattern. It does not supply a universal AND or NOT across separate patterns. The containing certificate, route table or security policy owns those rules. “Pattern matched” is incomplete evidence unless it also records which processor, supported-scheme inventory and combination policy produced the result.

The default path is part of the decision

Unsupported schemes are not a cosmetic error. The draft allows a processor to fail or skip an unsupported item. In forwarding or routing configuration, that can make an entry unusable and return behavior to an alternative or default.

The operational receipt therefore needs both the rule that matched and the rules that became unavailable. A default route selected after one skipped pattern is not equivalent to a deliberate default. Counting, logging and alarming on unsupported schemes is the difference between visible degradation and an invisible policy change.

Size limits matter too. A lightweight edge node and an interior router may accept different cardinalities. Malformed CBOR lengths and huge but valid sets can exhaust resources. A certificate or configuration service that accepts a pattern must not promise that every target processor can safely decode or evaluate it.

A set is not a universal permission

The draft reuses EID Patterns because the representation is useful. Reuse does not merge authority. In TCPCL, a pattern can participate in authenticating a peer Node ID. In BPSec, it can participate in authenticating the entity associated with a security operation. In a route table, it can select destinations. Those are three uses with three consequences.

Even the match-all form *:** changes meaning with its envelope. In permitted certificate subtrees it adds nothing. In excluded subtrees it effectively prohibits the bundle-security extended key usage. In a forwarding rule it may catch every destination. A familiar token is not a portable grant.

Lu Heng's Minimum Initial Specification offers the useful design limit: standardize the deterministic set notation and matching rules needed for interoperability, then leave each operational consequence explicit and local. Running-Code Primacy makes the deployed processor and concrete identity check stronger evidence than the mere presence of a certificate field. Reality-layer discipline keeps encoded pattern, normalized set, path verdict, Node-ID verdict, session acceptance, forwarding and delivery from collapsing into one green light.

Sources and limits

These sources establish a proposed mechanism and its stated risks. They do not establish an assigned OID, named implementation, certificate practice, interoperability result, exploit, incident, adoption rate, performance effect or delivered business outcome.