End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)
Extracted elements (29)
Arbitrary XMPP data beyond message and presence (including <iq/> stanzas and extended XML child elements) is secured by encapsulating it in the application/xmpp+xml MIME type, since [MSGFMT] allows encapsulating any MIME type, enabling end-to-end security for the full range of XMPP stanza types.
End-to-end encryption applies only to directed presence (with 'to' attribute), not broadcasted presence, because the broadcast case does not map cleanly to the point-to-point S/MIME model and is out of scope per [IMP-REQS].
The 'urn:ietf:params:xml:ns:xmpp-e2e' namespace has no inherent semantics; it is a using protocol only, and versioning is delegated to the encapsulated object specifications (MSGFMT, PIDF, XMPP-CORE). This avoids coupling the e2e wrapper to specific payload versions.
Prior to signing and/or encrypting, the format of an instant message MUST conform to the CPIM Message Format [MSGFMT] and presence information MUST conform to the CPP Presence Information Data Format [PIDF], to enable interoperability with non-XMPP CPIM-compliant systems.
The method enables secure communications through an XMPP-CPIM gateway: the gateway strips or adds the XMPP stanza wrapper around the S/MIME object while leaving the object itself immutable, allowing end-to-end security to span XMPP and non-XMPP services.
A receiving agent MUST provide some certificate retrieval mechanism to gain access to certificates for recipients of digital envelopes; at minimum, a user agent SHOULD automatically generate a message requesting the recipient's certificate.
A wrapped S/MIME object passing through an XMPP-CPIM gateway MUST be immutable and MUST NOT be modified by the gateway; the gateway MUST strip or add the XMPP wrapper but leave the S/MIME object untouched.
All implementations MUST support SHA-1 message digest, RSA (PKCS #1 v1.5) with SHA-1 for CMS SignedData, RSA (PKCS #1 v1.5) key transport for CMS EnvelopedData, and AES-128 in CBC mode for encryption.
All timestamps MUST conform to RFC 3339 and be presented as UTC with no offset. The sending agent MUST ensure timestamps increase monotonically. The receiving application MUST verify that the timestamp is within five minutes of the current time.
Any XMPP address present in a certificate MUST be encoded using the ASN.1 Object Identifier 'id-on-xmppAddr' as specified in Section 5.1.1 of [XMPP-CORE]. Each URI MUST be of the form <im:address> or <pres:address>.
If a stanza is both signed and encrypted, it SHOULD be signed first, then encrypted.
If the receiving agent determines that the signature is invalid, it SHOULD NOT present the stanza to the recipient, SHOULD provide alternate processing (e.g., a warning message), and MAY return a stanza error to the sender.
If the receiving agent is unable to decrypt the encrypted XML stanza, it SHOULD NOT present the stanza to the recipient and SHOULD provide alternate processing (e.g., a warning that the stanza cannot be decrypted).
Receiving agents MUST check that the sending JID matches a JID provided in the signer's certificate, ignoring the resource identifier portion of the JID for matching purposes.
Signing MUST use S/MIME signatures with CMS SignedData, and encryption MUST use S/MIME encryption with CMS EnvelopedData, as specified in [CPIM] and [CPP].
The application/xmpp+xml media type root element <xmpp/> MUST contain one and only one child element corresponding to an XMPP stanza type (message, presence, or iq), and the character encoding MUST be UTF-8.
The transfer encoding for S/MIME objects in XMPP MUST be 'binary', because XMPP applications are not expected to interface with older 7-bit systems.
To sign and/or encrypt a message, a sending agent MUST generate a Message/CPIM object, sign and/or encrypt it using S/MIME, and provide the result within an XML CDATA section in an <e2e/> child of a <message/> stanza qualified by 'urn:ietf:params:xml:ns:xmpp-e2e'.
To sign and/or encrypt presence information, a sending agent MUST generate an application/pidf+xml object, sign and/or encrypt it, and provide the result in an <e2e/> child of a <presence/> stanza that MUST include a 'to' attribute (directed presence only).
When a receiving application does not understand the protocol (Case #1), it MUST do one and only one of: ignore the <e2e/> extension, ignore the entire stanza, or return a <service-unavailable/> error to the sender.
The application/xmpp+xml MIME type, with root element <xmpp/>, encapsulates arbitrary XMPP stanza data (message, presence, or iq) for end-to-end signing and encryption of extended XMPP data beyond CPIM/PIDF formats.
The <e2e/> element, qualified by 'urn:ietf:params:xml:ns:xmpp-e2e', is a wrapper for an XML CDATA section containing a Message/CPIM, application/pidf+xml, or application/xmpp+xml S/MIME object. It appears as a child of <message/>, <presence/>, or other XMPP stanzas.
Three application-specific error condition elements are defined in the xmpp-e2e namespace: <bad-timestamp/> (timestamp check failed), <unverified-signature/> (signature verification failed), and <decryption-failed/> (decryption failed). These supplement standard XMPP stanza errors.
IANA registers the MIME media type 'application/xmpp+xml' for XMPP stanza data. Required parameters: none; encoding must be UTF-8; intended usage: COMMON.
IANA registers the XML namespace 'urn:ietf:params:xml:ns:xmpp-e2e' for signed and encrypted content in XMPP, as specified by RFC 3923.
A gateway that passes end-to-end secured stanzas between XMPP and non-XMPP services MUST be compliant with the minimum security requirements of the instant messaging and presence protocols it interfaces with, as the S/MIME object integrity is preserved end-to-end.
Timestamps in Message/CPIM and application/pidf+xml objects prevent replay attacks. Receivers must verify timestamps are within five minutes of current time and are monotonically increasing relative to recent valid timestamps; failures trigger 'old timestamp', 'future timestamp', or 'decreasing timestamp' warnings.
Encrypted messages use a CMS EnvelopedData object encoded as a base64 string, wrapped in an XML CDATA section inside the <e2e/> element of the XMPP stanza.
Signed messages use a multipart/signed MIME object with two parts: one Content-Type of Message/CPIM (or application/pidf+xml) and one Content-Type of application/pkcs7-signature. The entire object is wrapped in an XML CDATA section inside <e2e/>.