Summary

  • RFC 3923 secured a CPIM message object with S/MIME, then carried it inside an XMPP wrapper; the wrapper namespace itself supplied no message semantics.
  • An XMPP-CPIM gateway could remove or add the outer service wrapper to relay the object, but the object had to pass through unchanged.

The gateway’s permitted edit

A gateway is useful because two messaging services need not speak the same protocol to exchange a message. But the moment one side translates the message, a security question appears: what exactly may the translator change without becoming part of the trust boundary? RFC 3923, published in October 2004 as an IETF Standards Track specification, answered with a deliberately small unit of trust. An XMPP-CPIM gateway could take off one service’s wrapper and put on another’s. It could not alter the signed or encrypted S/MIME object inside.

That distinction made end-to-end protection compatible, at least at the protocol boundary, with an intermediary that understood both services. RFC 3923 did not make the gateway a cryptographic endpoint. It asked the gateway to transport the protected object as an opaque payload. The architecture therefore separated interoperability work from the work of signing, encrypting, and interpreting the content.

A protected object inside an XMPP stanza

The sender first creates a Message/CPIM object. That object contains the message headers as well as its content; RFC 3923 requires both to be covered by the S/MIME signature or encryption operation. The resulting object is then placed in an XML CDATA section inside an <e2e/> child of an XMPP message or presence stanza. For some uses, the enclosed object may instead be a PIDF presence document or an XMPP XML object.

The <e2e/> element is a carrier, not a semantic interpreter. RFC 3923 says its namespace has no inherent semantics: the format-specific standards for CPIM, PIDF, or XMPP define the enclosed object. That choice matters. It avoids asking an intermediary to understand the protected content merely because it can parse the XMPP stanza that carries it.

The gateway rule follows from that division. For traffic leaving XMPP, the gateway removes the XMPP wrapper—including the <e2e> tags—to reveal and route the multipart S/MIME object, adding the non-XMPP service’s wrapper if needed. In the reverse direction, it removes any non-XMPP wrapper, places the same object inside an XMPP wrapper, and routes the stanza. RFC 3923 is explicit that the wrapped S/MIME object must be immutable and must not be modified by the gateway.

A boundary, not a complete security system

Immutability is a strong protocol instruction, but not proof that a deployed gateway obeyed it. Nor does the wrapper make every surrounding fact trustworthy. The recipient still needs certificates, must validate them, and has to decide what a signature establishes about the sender. RFC 3923 leaves certificate enrollment outside its scope and calls for a certificate-retrieval mechanism at the receiving agent. Its security claim is therefore about preserving a protected object across a particular interoperability path, not about solving identity, key distribution, or user-interface problems.

The specification also leaves an operational trade-off in plain view. Opaque transport helps an intermediary carry content it cannot safely rewrite, but it limits the gateway’s ability to transform or inspect that content. If a service requires content conversion, the conversion point and its effect on signatures become consequential: changing a covered object is not a neutral translation. The design moves that decision to the endpoints rather than disguising it as routine gateway work.

RFC 7165, written a decade later, described the S/MIME approach as having failed to gain widespread deployment and cited key-management challenges and the difficulty of processing S/MIME objects as contributing factors. That is a contemporaneous standards document’s account in 2014, not a present-day deployment census or a single-cause explanation. It nevertheless sharpens the historical lesson: a clean boundary can preserve cryptographic meaning while leaving the surrounding product and key-management work difficult. RFC 3923’s lasting design move was not that gateways became trustworthy.

It was that interoperability did not require them to rewrite what the endpoints had protected.

Sources