SIP-Based Messaging with S/MIME
updates
Extracted elements (34)
MSRP's streaming mode (sending chunks before knowing total message length) is incompatible with S/MIME because S/MIME must operate on the entire message. The Byte-Range header with total length must be present in every chunk to enable reassembly before S/MIME processing.
RFC 3261 Section 23.2 required sign-then-encrypt order (SignedData inside EnvelopedData), but this document reverses it to sign-first-then-encrypt (SignedData inside AuthEnvelopedData) for SIP MESSAGE, because authenticated encryption provides authentication without the SignedData layer and ciphertext modification in EnvelopedData can otherwise go undetected.
SIP OPTIONS-based capability discovery for S/MIME is unreliable because SIP proxies may fork requests and return only the 'best' response, meaning the sender may learn capabilities of only one of the recipient's multiple devices. Out-of-band methods are recommended instead.
The application/pkcs7-mime format is RECOMMENDED over multipart/signed because email experience shows multipart/signed bodies are at greater risk of 'helpful' tampering by intermediaries (e.g., insertion of IMDN requests), which causes signature validation failures. It is also more compact, important for SIP MESSAGE's 1300-octet size limit.
The SIP MESSAGE method is limited to 1300 octets to avoid UDP fragmentation. Certificates embedded in SignedData can push messages past this limit; omitting the certificate when the recipient is known to have it is permitted as a size optimization.
For MSRP, a sender MAY treat a peer advertising '*' in accept-types as potentially supporting S/MIME; if the peer returns MSRP 415, the sender should treat it as not supporting S/MIME for the session duration.
Intermediaries that insert IMDN notification requests or other metadata into end-to-end signed messages will cause signature validation to fail. Systems using S/MIME with IMDN must account for this incompatibility.
Recipients SHOULD accept signed-and-encrypted messages in either order (SignedData inside AuthEnvelopedData, or AuthEnvelopedData inside SignedData) for backwards compatibility, even though the MUST order is sign-first.
UAs that support both S/MIME and CPIM SHOULD be able to validate signatures and decrypt enveloped data whether operations are applied to the entire CPIM body or only the CPIM payload, since some messaging networks require inspection of CPIM metadata.
A SignedData message sent in a SIP MESSAGE request SHOULD contain the certificate but MAY omit it if the sender has reason to believe the recipient already has it or has another access method. This updates RFC 3261 Section 23.2.
A UA supporting this specification MUST explicitly include appropriate S/MIME media type(s) in the accept-types attribute of any SDP offer or answer proposing MSRP.
A UAC that receives a SIP MESSAGE request with an unsupported media type MUST return a 415 (Unsupported Media Type) response. This updates RFC 3428 Section 11.3.
At a minimum, a UA that supports S/MIME MUST be able to validate a signed message. UAs that wish to indicate support for validating clear-signed message signatures MUST also indicate support for application/pkcs7-signature.
Clients MUST ensure that a text/html content type in an S/MIME body is a complete HTML document, and MUST treat each encrypted or signed piece of a MIME message as being from different origins. This mitigates the EFAIL attack.
Endpoints MUST NOT use MSRP URIs to identify certificates or insert them into certificate Subject Alternative Name fields; SIP AoRs MUST be used instead.
Sending and receiving UAs MUST support AES-128-GCM for content encryption and MUST support AES-128-WRAP for key encryption. If key agreement is supported, UAs MUST support ECDH with NIST P-256 and ANSI-X9.63-KDF/SHA-256, and SHOULD support ECDH with X25519.
Sending and receiving UAs MUST support the SHA-256 message digest algorithm and MUST support ECDSA with NIST P-256 and SHA-256 for signing. UAs SHOULD support EdDSA with Ed25519.
SIP URI subject alternative names in certificates MUST be encoded using the uniformResourceIdentifier CHOICE of the GeneralName type as described in RFC 5280 Section 4.2.1.6.
The sender MUST apply any S/MIME operations to the whole MSRP message prior to breaking it into chunks; the receiver must reassemble chunks before decrypting or validating.
The UAS SHOULD return a SIP 493 (Undecipherable) response if it immediately attempts decryption and finds the message was encrypted to the wrong certificate; it MAY return a 200-class response if decryption is deferred. This updates RFC 3261.
When generating a signed message, sending UAs SHOULD follow the conventions in RFC 8551 for application/pkcs7-mime with smime-type=signed-data; when validating, receiving UAs MUST follow those conventions.
When generating an encrypted message, sending UAs MUST follow RFC 8551 conventions for application/pkcs7-mime with smime-type=auth-enveloped-data; receiving UAs MUST follow the same conventions when decrypting.
When sending an S/MIME-formatted MSRP message, the sender MUST include the Byte-Range header field for every chunk including the first, and the Byte-Range header field MUST include the total message length.
When sending signed and encrypted user content in a SIP MESSAGE request, sending UAs MUST sign the message first and then encrypt it (SignedData inside AuthEnvelopedData). Recipients SHOULD accept messages signed and encrypted in either order.
When validating a certificate, receiving UAs MUST support ECDSA with NIST P-256 and SHA-256.
MSRP chunking: S/MIME operations must be applied to the entire message before chunking. Intermediaries may reorder or resize chunks; scanning for MSRP end-lines occurs per chunk after S/MIME operations are applied.
S/MIME encrypted messages use the application/pkcs7-mime media type with smime-type=auth-enveloped-data, replacing the older EnvelopedData type to provide authenticated encryption without a separate SignedData layer.
S/MIME signed messages use the application/pkcs7-mime media type with smime-type=signed-data. The application/pkcs7-mime format is preferred over multipart/signed because it is more compact and less susceptible to intermediary tampering.
UAs advertise S/MIME support by indicating capability to receive application/pkcs7-mime in SIP Accept headers or MSRP SDP accept-types. A UA can advertise all smime-types with no parameters, or specific smime-types with appropriate parameters.
Certificate validation must match the certificate to the SIP AoR the UAS relies upon for display or filtering, typically the From header field or P-Asserted-Identity, not just any header field. Online revocation checks should be performed as mobile messaging is typically an online application.
Modification of ciphertext in EnvelopedData can go undetected without authentication; this is a key reason for the transition to AuthEnvelopedData, which provides authenticated encryption without requiring a separate SignedData wrapper.
MSRP chunk reassembly is vulnerable to denial-of-service via large Byte-Range header values. Implementations must sanity-check these values before allocating memory for reassembly, as described in RFC 4975 Section 14.5.
S/MIME does not normally protect SIP or MSRP headers, only the body. SIP/MSRP/CPIM headers attached by intermediaries (e.g., RCS application servers) may leak metadata. Implementors should assess whether inserted metadata creates privacy leaks.
The secure notification use case (e.g., 2FA codes, financial alerts) is vulnerable to phishing, eavesdropping, and impersonation. End-to-end protection alone is insufficient unless recipients are trained to reject unsigned messages that appear to be from trusted senders.