Summary

  • A 30 September revision of the TLS Working Group's trust-anchor identifiers draft reduces the maximum binary identifier from 255 to 32 bytes. The TrustAnchorID structure now carries one to 32 bytes. This is a working-group Internet-Draft with IESG state I-D Exists, not a published RFC.
  • The same revision adds implementation guidance for arbitrarily large OID components: avoid overflow, retain byte-level comparisons where practical, and handle valid identifiers that a local text or configuration system cannot represent. None of this turns an identifier into a decision to trust a CA.

The interesting number in the new draft is 32. It is small enough to look like an implementation detail, yet it sits at the point where a peer's list of trusted certification authorities becomes a signal for selecting a certificate path. The previous version permitted a binary trust-anchor identifier up to 255 bytes; the version dated 30 September caps it at 32 and changes the corresponding TLS vector. The text says the tighter bound keeps both binary and dotted-decimal forms comfortably within 255 bytes. It does not limit a relying party to 32 authorities, and it does not say a 32-byte label proves a certificate trustworthy.

The proposed trust_anchors extension addresses a real coordination problem. A server or other authenticating party can hold more than one certification path, while its peers may accept different sets of certification authorities. A compact identifier can help it choose a path the peer is prepared to validate, without sending long distinguished names in the older certificate_authorities extension. A CA operator would normally allocate an ID for an individual anchor; groups require the parties using them to agree on their meaning. The relying party still decides which anchors belong in its trust store. The authenticating party selects a candidate path. Successful validation remains a separate act.

The new implementation section deals with a second limit that must not be confused with the 32-byte wire limit. An OID component inside a valid identifier, or an integer in a matching pattern, may be arbitrarily large. Software that converts it to a fixed-width integer could overflow or misread it. The draft says implementations must not exhibit undefined behavior and recommends matching the byte representation directly, where individual OID components need not be decoded. That is a stronger operational instruction than merely asking authors to keep labels short.

Some deployments will still want dotted-decimal text in diagnostic output or configuration. Draft 06 permits local bounds in those contexts, but not a careless treatment of valid inputs as malformed. TLS implementations must accept identifiers with arbitrarily large OID components in the specified handshake messages; they may discard an unsupported ID before passing it to another component. If every ID in EncryptedExtensions is discarded, the draft treats that as though the extension were omitted. A bounded text converter is thus not allowed to silently redefine the protocol's trust decision. The draft also says implementations with a component limit should support at least values through 2^32-1, covering the Private Enterprise Number range, and IDs should be allocated to fit it. These are recommendations, not a claim that all software already complies.

The version comparison matters. The old text's 255-byte maximum and the new 32-byte maximum are directly observable in the IETF-hosted copies; the overflow and unsupported-ID discussion is newly added. A versioned-group example also replaces an illustrative 2^64-1 maximum with an open-ended infinity. That example is not an announcement that a live CA registry has changed. Nor does a fresh Internet-Draft settle the standard: Datatracker still lists the TLS WG document as active and the IESG state as I-D Exists. No named product's implementation, deployment rate or security outcome follows from the draft alone.

Sources