Summary

  • RFC 3652 separated a fixed 20-octet Message Envelope used for delivery and reassembly from a 24-octet Header and operation-specific Body; the Message Credential's digital signature did not cover the Envelope, while it did cover the Header and Body.
  • The Credential could carry either an originator's signature or a MAC based on a pre-established session key. This boundary describes the protocol's integrity scope—not a documented exploit, an implementation failure or a claim that lower-layer protection was impossible.

One message, different trust surfaces

In 2003, the Handle System protocol specification had to describe more than lookup. A client needed to find a responsible Handle server, ask it to resolve or administer a Handle, and interpret the response. The protocol also had to carry large messages over transports that did not present data in the same way. RFC 3652 v2.1 placed those concerns into four adjacent pieces: an Envelope, Header, Body and Credential. RFC 3652

The Envelope was always present and exactly 20 octets. The RFC calls it a delivery wrapper, not application data. Its fields include protocol version and message flags, a session identifier, a request identifier, a sequence number and message length. The Header was also mandatory and 24 octets; it carried common operation fields, including operation and response codes. The Body carried operation-specific data and could be empty. RFC 3652

The trust boundary did not follow the packet boundary. RFC 3652 states that the digital signature in a Message Credential did not protect the Envelope's content. It did protect the Header and Body. A non-empty Credential could contain an originator's digital signature or a one-way message-authentication code (MAC) based on an already established session key. The RFC presents the Credential as a way to authenticate a message and check data integrity in transit. Those are not interchangeable mechanisms: a MAC relies on a shared secret; a digital signature uses a different key model. RFC 3652 RFC 2104

That split made sense in light of what the Envelope did. A Handle client could use UDP datagrams or a TCP byte stream. RFC 3652 limited a UDP-carried message to 512 octets, excluding IP and UDP headers. Longer messages had to be fragmented, and each fragment carried its sequence number in an Envelope so the receiving side could reassemble the message. TCP did not make the Handle-level framing disappear: its byte stream still needed message boundaries, and the protocol could fragment larger messages for reassembly. RFC 3652 RFC 768 RFC 793

The Header and Body, by contrast, described what the client and server were doing. An operation code asked for a kind of Handle operation; a response code reported an outcome such as success, missing value, referral, authorization failure or authentication requirement. The protocol's service model sat on top of a separate Handle namespace and data model, while RFC 3650 described the overall service architecture. The message's protected semantic content therefore began after the delivery wrapper: parsing a fragment was not the same thing as authorizing its operation. RFC 3652 RFC 3650 RFC 3651

Authentication was not authorization

RFC 3652 also separated a client's proof from the server's permission decision. For administrative actions, a server could send a challenge; the client returned a response proving possession of a private or shared secret key. After validating that proof, the server still had to check whether the administrator had enough privilege for the requested operation. A successful challenge-response was not itself approval to change a Handle. The protocol could also establish sessions whose state and keys supported multiple operations. RFC 3652

That distinction matters when describing the Credential. RFC 3552 treats data integrity, peer authentication, confidentiality and systems security as different goals; a signature or MAC does not automatically provide every one of them. RFC 3652's own security section discusses server signatures and client authentication, but the format definition is narrower: the Credential covers Header and Body, not the delivery Envelope. Nothing in that statement, on its own, establishes that an attacker changed a message in a deployed system. A lower-layer channel might supply other protections, and the RFC is a protocol specification rather than an incident report. RFC 3552 RFC 3652

Nor should the Handle Credential be confused with X.509's certificate and revocation-list signature profile. RFC 3279 defines algorithm identifiers and encodings for that PKI profile; it does not expand RFC 3652's signed byte range or turn its Envelope into protected content. That is a useful boundary between cryptographic vocabulary and the exact object being authenticated. RFC 3279 RFC 3652

RFC 3652 is marked Informational, and its IESG note says the discussions had not produced IETF consensus on the Handle System or its fit with the IETF identifier architecture. The document records a proposed system protocol, not proof of universal adoption. Its enduring lesson is more modest: a message can be framed, reassembled and authenticated by different rules, so any claim about integrity must name which bytes the credential actually covers. RFC 3652

Sources