Tech-invite   3GPPspecs   RFCs   SIP   Search in Tech-invite

in Index   Prev   Next

RFC 8591

SIP-Based Messaging with S/MIME

Pages: 39
Group: ~sip-sdp
Proposed STD
Updates:  326134284975
Part 1 of 2 – Pages 1 to 16
None   None   Next

Top   ToC   RFC8591 - Page 1
Internet Engineering Task Force (IETF)                       B. Campbell
Request for Comments: 8591                             Standard Velocity
Updates: 3261, 3428, 4975                                     R. Housley
Category: Standards Track                                 Vigil Security
ISSN: 2070-1721                                               April 2019

                    SIP-Based Messaging with S/MIME


   Mobile messaging applications used with the Session Initiation
   Protocol (SIP) commonly use some combination of the SIP MESSAGE
   method and the Message Session Relay Protocol (MSRP).  While these
   provide mechanisms for hop-by-hop security, neither natively provides
   end-to-end protection.  This document offers guidance on how to
   provide end-to-end authentication, integrity protection, and
   confidentiality using the Secure/Multipurpose Internet Mail
   Extensions (S/MIME).  It updates and provides clarifications for RFCs
   3261, 3428, and 4975.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
Top   ToC   RFC8591 - Page 2
Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.
Top   ToC   RFC8591 - Page 3
Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Problem Statement and Scope . . . . . . . . . . . . . . . . .   5
   4.  Applicability of S/MIME . . . . . . . . . . . . . . . . . . .   6
     4.1.  Signed Messages . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Encrypted Messages  . . . . . . . . . . . . . . . . . . .   7
     4.3.  Signed and Encrypted Messages . . . . . . . . . . . . . .   9
     4.4.  Certificate Handling  . . . . . . . . . . . . . . . . . .   9
       4.4.1.  Subject Alternative Name  . . . . . . . . . . . . . .   9
       4.4.2.  Certificate Validation  . . . . . . . . . . . . . . .   9
   5.  Transfer Encoding . . . . . . . . . . . . . . . . . . . . . .   9
   6.  User Agent Capabilities . . . . . . . . . . . . . . . . . . .  10
   7.  Using S/MIME with the SIP MESSAGE Method  . . . . . . . . . .  11
     7.1.  Size Limit  . . . . . . . . . . . . . . . . . . . . . . .  11
     7.2.  SIP User Agent Capabilities . . . . . . . . . . . . . . .  11
     7.3.  Failure Cases . . . . . . . . . . . . . . . . . . . . . .  12
   8.  Using S/MIME with MSRP  . . . . . . . . . . . . . . . . . . .  12
     8.1.  Chunking  . . . . . . . . . . . . . . . . . . . . . . . .  12
     8.2.  Streamed Data . . . . . . . . . . . . . . . . . . . . . .  13
     8.3.  Indicating Support for S/MIME . . . . . . . . . . . . . .  14
     8.4.  MSRP URIs . . . . . . . . . . . . . . . . . . . . . . . .  14
     8.5.  Failure Cases . . . . . . . . . . . . . . . . . . . . . .  15
   9.  S/MIME Interaction with Other SIP Messaging Features  . . . .  15
     9.1.  Common Profile for Instant Messaging  . . . . . . . . . .  15
     9.2.  Instant Message Disposition Notifications . . . . . . . .  16
   10. Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  17
     10.1.  Signed Message in SIP including the Sender's Certificate  17
     10.2.  Signed Message in SIP with No Certificate  . . . . . . .  19
     10.3.  MSRP Signed and Encrypted Message in a Single Chunk  . .  20
     10.4.  MSRP Signed and Encrypted Message Sent in Multiple
            Chunks . . . . . . . . . . . . . . . . . . . . . . . . .  21
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  23
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  25
     13.2.  Informative References . . . . . . . . . . . . . . . . .  28
   Appendix A.  Message Details  . . . . . . . . . . . . . . . . . .  30
     A.1.  Signed Message  . . . . . . . . . . . . . . . . . . . . .  30
     A.2.  Short Signed Message  . . . . . . . . . . . . . . . . . .  32
     A.3.  Signed and Encrypted Message  . . . . . . . . . . . . . .  33
       A.3.1.  Signed Message prior to Encryption  . . . . . . . . .  33
       A.3.2.  Encrypted Message . . . . . . . . . . . . . . . . . .  35
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  39
Top   ToC   RFC8591 - Page 4
1.  Introduction

   Several mobile messaging systems use the Session Initiation Protocol
   (SIP) [RFC3261], typically as some combination of the SIP MESSAGE
   method [RFC3428] and the Message Session Relay Protocol (MSRP)
   [RFC4975].  For example, Voice over LTE (VoLTE) uses the SIP MESSAGE
   method to send Short Message Service (SMS) messages.  The Open Mobile
   Alliance (OMA) Converged IP Messaging (CPM) system [CPM] uses the SIP
   MESSAGE method for short "pager mode" messages and uses MSRP for
   large messages and for sessions of messages.  The Global System for
   Mobile Communications Association (GSMA) Rich Communication Services
   (RCS) uses CPM for messaging [RCS].

   At the same time, organizations increasingly depend on mobile
   messaging systems to send notifications to their customers.  Many of
   these notifications are security sensitive.  For example, such
   notifications are commonly used for notice of financial transactions,
   notice of login or password change attempts, and the sending of
   two-factor authentication codes.

   Both SIP and MSRP can be used to transport any content using
   Multipurpose Internet Mail Extensions (MIME) formats.  The SIP
   MESSAGE method is typically limited to short messages (under
   1300 octets for the MESSAGE request).  MSRP can carry arbitrarily
   large messages and can break large messages into chunks.

   While both SIP and MSRP provide mechanisms for hop-by-hop security,
   neither provides native end-to-end protection.  Instead, they depend
   on S/MIME [RFC8550] [RFC8551].  However, at the time of this writing,
   S/MIME is not in common use for SIP-based and MSRP-based messaging
   services.  This document updates and clarifies RFCs 3261, 3428, and
   4975 in an attempt to make S/MIME for SIP and MSRP easier to
   implement and deploy in an interoperable fashion.

   This document updates RFCs 3261, 3428, and 4975 to update the
   cryptographic algorithm recommendations and the handling of S/MIME
   data objects.  It updates RFC 3261 to allow S/MIME signed messages to
   be sent without embedded certificates in some situations.  Finally,
   it updates RFCs 3261, 3428, and 4975 to clarify error-reporting
   requirements for certain situations.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.
Top   ToC   RFC8591 - Page 5
3.  Problem Statement and Scope

   This document discusses the use of S/MIME with SIP-based messaging.
   Other standardized messaging protocols exist, such as the Extensible
   Messaging and Presence Protocol (XMPP) [RFC6121].  Likewise, other
   end-to-end protection formats exist, such as JSON Web Signatures
   [RFC7515] and JSON Web Encryption [RFC7516].

   This document focuses on SIP-based messaging because its use is
   becoming more common in mobile environments.  It focuses on S/MIME,
   since several mobile operating systems already have S/MIME libraries
   installed.  While there may also be value in specifying end-to-end
   security for other messaging and security mechanisms, it is out of
   scope for this document.

   MSRP sessions are negotiated using the Session Description Protocol
   (SDP) [RFC4566] offer/answer mechanism [RFC3264] or similar
   mechanisms.  This document assumes that SIP is used for the
   offer/answer exchange.  However, the techniques should be adaptable
   to other signaling protocols.

   [RFC3261], [RFC3428], and [RFC4975] already describe the use of
   S/MIME.  [RFC3853] updates SIP to support the Advanced Encryption
   Standard (AES).  In aggregate, that guidance is incomplete, contains
   inconsistencies, and is still out of date in terms of supported and
   recommended algorithms.

   The guidance in RFC 3261 is based on an implicit assumption that
   S/MIME is being used to secure signaling applications.  That advice
   is not entirely appropriate for messaging applications.  For example,
   it assumes that message decryption always happens before the SIP
   transaction completes.

   This document offers normative updates and clarifications to the use
   of S/MIME with the SIP MESSAGE method and MSRP.  It does not attempt
   to define a complete secure messaging system.  Such a system would
   require considerable work around user enrollment, certificate and key
   generation and management, multi-party chats, device management, etc.
   While nothing herein should preclude those efforts, they are out of
   scope for this document.

   This document primarily covers the sending of single messages -- for
   example, "pager-mode messages" sent using the SIP MESSAGE method and
   "large messages" sent in MSRP.  Techniques to use a common signing or
   encryption key across a session of messages are out of scope for this
Top   ToC   RFC8591 - Page 6
   Cryptographic algorithm requirements in this document are intended to
   supplement those already specified for SIP and MSRP.

4.  Applicability of S/MIME

   The Cryptographic Message Syntax (CMS) [RFC5652] is an encapsulation
   syntax that is used to digitally sign, digest, authenticate, or
   encrypt arbitrary message content.  The CMS supports a variety of
   architectures for certificate-based key management, especially the
   one defined by the IETF PKIX (Public Key Infrastructure using X.509)
   Working Group [RFC5280].  The CMS values are generated using ASN.1
   [X680], using the Basic Encoding Rules (BER) and Distinguished
   Encoding Rules (DER) [X690].

   The S/MIME Message Specification [RFC8551] defines MIME body parts
   based on the CMS.  In this document, the application/pkcs7-mime media
   type is used to digitally sign an encapsulated body part, and it is
   also used to encrypt an encapsulated body part.

4.1.  Signed Messages

   While both SIP and MSRP require support for the multipart/signed
   format, the use of application/pkcs7-mime is RECOMMENDED for most
   signed messages.  Experience with the use of S/MIME in electronic
   mail has shown that multipart/signed bodies are at greater risk of
   "helpful" tampering by intermediaries, a common cause of signature
   validation failure.  This risk is also present for messaging
   applications; for example, intermediaries might insert Instant
   Message Disposition Notification (IMDN) requests [RFC5438] into
   messages.  (See Section 9.2.)  The application/pkcs7-mime format is
   also more compact, which can be important for messaging applications,
   especially when using the SIP MESSAGE method.  (See Section 7.1.)
   The use of multipart/signed may still make sense if the message needs
   to be readable by receiving agents that do not support S/MIME.

   When generating a signed message, sending User Agents (UAs) SHOULD
   follow the conventions specified in [RFC8551] for the
   application/pkcs7-mime media type with smime-type=signed-data.  When
   validating a signed message, receiving UAs MUST follow the
   conventions specified in [RFC8551] for the application/pkcs7-mime
   media type with smime-type=signed-data.
Top   ToC   RFC8591 - Page 7
   Sending and receiving UAs MUST support the SHA-256 message digest
   algorithm [RFC5754].  For convenience, the SHA-256 algorithm
   identifier is repeated here:

      id-sha256 OBJECT IDENTIFIER ::= {
        joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
        csor(3) nistalgorithm(4) hashalgs(2) 1 }

   Sending and receiving UAs MAY support other message digest

   Sending and receiving UAs MUST support the Elliptic Curve Digital
   Signature Algorithm (ECDSA) using the NIST P-256 elliptic curve and
   the SHA-256 message digest algorithm [RFC5480] [RFC5753].  Sending
   and receiving UAs SHOULD support the Edwards-curve Digital Signature
   Algorithm (EdDSA) with curve25519 (Ed25519) [RFC8032] [RFC8419].  For
   convenience, the ECDSA with SHA-256 algorithm identifier, the object
   identifier for the well-known NIST P-256 elliptic curve, and the
   Ed25519 algorithm identifier are repeated here:

      ecdsa-with-SHA256 OBJECT IDENTIFIER ::= {
        iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
        ecdsa-with-SHA2(3) 2 }

      -- Note: The NIST P-256 elliptic curve is also known as secp256r1.

      secp256r1 OBJECT IDENTIFIER ::= {
        iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3)
        prime(1) 7 }

      id-Ed25519  OBJECT IDENTIFIER  ::=  {
        iso(1) identified-organization(3) thawte(101) 112 }

4.2.  Encrypted Messages

   When generating an encrypted message, sending UAs MUST follow the
   conventions specified in [RFC8551] for the application/pkcs7-mime
   media type with smime-type=auth-enveloped-data.  When decrypting a
   received message, receiving UAs MUST follow the conventions specified
   in [RFC8551] for the application/pkcs7-mime media type with
Top   ToC   RFC8591 - Page 8
   Sending and receiving UAs MUST support the AES-128-GCM algorithm for
   content encryption [RFC5084].  For convenience, the AES-128-GCM
   algorithm identifier is repeated here:

      id-aes128-GCM OBJECT IDENTIFIER ::=  {
        joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
        csor(3) nistAlgorithm(4) aes(1) 6 }

   Sending and receiving UAs MAY support other content-authenticated
   encryption algorithms.

   Sending and receiving UAs MUST support the AES-128-WRAP algorithm for
   encryption of one AES key with another AES key [RFC3565].  For
   convenience, the AES-128-WRAP algorithm identifier is repeated here:

      id-aes128-wrap OBJECT IDENTIFIER ::=  {
        joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
        csor(3) nistAlgorithm(4) aes(1) 5 }

   Sending and receiving UAs MAY support other key-encryption

   Symmetric key-encryption keys can be distributed before messages are
   sent.  If sending and receiving UAs support previously distributed
   key-encryption keys, then they MUST assign a KEKIdentifier [RFC5652]
   to the previously distributed symmetric key.

   Alternatively, a key agreement algorithm can be used to establish a
   single-use key-encryption key.  If sending and receiving UAs support
   key agreement, then they MUST support the Elliptic Curve
   Diffie-Hellman (ECDH) algorithm using the NIST P-256 elliptic curve
   and the ANSI-X9.63-KDF key derivation function with the SHA-256
   message digest algorithm [RFC5753].  If sending and receiving UAs
   support key agreement, then they SHOULD support the ECDH algorithm
   using curve25519 (X25519) [RFC7748] [RFC8418].  For convenience,
   (1) the identifier for the ECDH algorithm using the ANSI-X9.63-KDF
   with the SHA-256 algorithm and (2) the identifier for the X25519
   algorithm are repeated here:

      dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
        iso(1) identified-organization(3) certicom(132)
        schemes(1) 11 1 }

      id-X25519 OBJECT IDENTIFIER ::= {
        iso(1) identified-organization(3) thawte(101) 110 }
Top   ToC   RFC8591 - Page 9
4.3.  Signed and Encrypted Messages

   RFC 3261, Section 23.2 says that when a User Agent Client (UAC) sends
   signed and encrypted data, it "SHOULD" send an EnvelopedData object
   encapsulated within a SignedData message.  That essentially says that
   one should encrypt first, then sign.  This document updates RFC 3261
   to say that, when sending signed and encrypted user content in a SIP
   MESSAGE request, the sending UAs MUST sign the message first, and
   then encrypt it.  That is, it must send the SignedData object inside
   an AuthEnvelopedData object.  For interoperability reasons,
   recipients SHOULD accept messages signed and encrypted in either

4.4.  Certificate Handling

   Sending and receiving UAs MUST follow the S/MIME certificate-handling
   procedures [RFC8550], with a few exceptions detailed below.

4.4.1.  Subject Alternative Name

   In both SIP and MSRP, the identity of the sender of a message is
   typically expressed as a SIP URI.

   The subject alternative name extension is used as the preferred means
   to convey the SIP URI of the subject of a certificate.  Any SIP URI
   present MUST be encoded using the uniformResourceIdentifier CHOICE of
   the GeneralName type as described in [RFC5280], Section
   Since the SubjectAltName type is a SEQUENCE OF GeneralName, multiple
   URIs MAY be present.

   Other methods of identifying a certificate subject MAY be used.

4.4.2.  Certificate Validation

   When validating a certificate, receiving UAs MUST support the ECDSA
   using the NIST P-256 elliptic curve and the SHA-256 message digest
   algorithm [RFC5480].

   Sending and receiving UAs MAY support other digital signature
   algorithms for certificate validation.

5.  Transfer Encoding

   SIP and MSRP UAs are always capable of receiving binary data.  Inner
   S/MIME entities do not require base64 encoding [RFC4648].

   Both SIP and MSRP provide 8-bit safe transport channels; base64
   encoding is not generally needed for the outer S/MIME entities.
Top   ToC   RFC8591 - Page 10
   However, if there is a chance a message might cross a 7-bit transport
   (for example, gateways that convert to a 7-bit transport for
   intermediate transfer), base64 encoding may be needed for the outer

6.  User Agent Capabilities

   Messaging UAs may implement a subset of S/MIME capabilities.  Even
   when implemented, some features may not be available due to
   configuration.  For example, UAs that do not have user certificates
   cannot sign messages on behalf of the user or decrypt encrypted
   messages sent to the user.  At a minimum, a UA that supports S/MIME
   MUST be able to validate a signed message.

   End-user certificates have long been a barrier to large-scale S/MIME
   deployment.  But since UAs can validate signatures even without local
   certificates, the use case of organizations sending secure
   notifications to their users becomes a sort of "low-hanging fruit".
   That being said, the signed-notification use case still requires
   shared trust anchors.

   SIP and MSRP UAs advertise their level of support for S/MIME by
   indicating their capability to receive the "application/pkcs7-mime"
   media type.

   The fact that a UA indicates support for the "multipart/signed" media
   type does not necessarily imply support for S/MIME.  The UA might
   just be able to display clear-signed content without validating the
   signature.  UAs that wish to indicate the ability to validate
   signatures for clear-signed messages MUST also indicate support for

   A UA can indicate that it can receive all smime-types by advertising
   "application/pkcs7-mime" with no parameters.  If a UA does not accept
   all smime-types, it advertises the media type with the appropriate
   parameters.  If more than one smime-type is supported, the UA
   includes a separate instance of the media-type string, appropriately
   parameterized, for each.

   For example, a UA that can only receive signed-data would advertise
   "application/pkcs7-mime; smime-type=signed-data".

   SIP signaling can fork to multiple destinations for a given Address
   of Record (AoR).  A user might have multiple UAs with different
   capabilities; the capabilities remembered from an interaction with
   one such UA might not apply to another.  (See Section 7.2.)
Top   ToC   RFC8591 - Page 11
   UAs can also advertise or discover S/MIME using out-of-band
   mechanisms.  Such mechanisms are beyond the scope of this document.

7.  Using S/MIME with the SIP MESSAGE Method

   The use of S/MIME with the SIP MESSAGE method is described in
   Section 11.3 of [RFC3428], and for SIP in general in Section 23 of
   [RFC3261].  This section and its child sections offer clarifications
   for the use of S/MIME with the SIP MESSAGE method, along with related
   updates to RFCs 3261 and 3428.

7.1.  Size Limit

   SIP MESSAGE requests are typically limited to 1300 octets.  That
   limit applies to the entire message, including both SIP header fields
   and the message content.  This is due to the potential for
   fragmentation of larger requests sent over UDP.  In general, it is
   hard to be sure that no proxy or other intermediary will forward a
   SIP request over UDP somewhere along the path.  Therefore, S/MIME
   messages sent using the SIP MESSAGE method should be kept as small as
   possible.  Messages that will not fit within the limit can be sent
   using MSRP.

   Section 23.2 of [RFC3261] requires that a SignedData message contain
   a certificate to be used to validate the signature.  In order to
   reduce the message size, this document updates that text to say that
   a SignedData message sent in a SIP MESSAGE request SHOULD contain the
   certificate but MAY omit it if the sender has reason to believe that
   the recipient (1) already has the certificate in its keychain or
   (2) has some other method of accessing the certificate.

7.2.  SIP User Agent Capabilities

   SIP UAs can theoretically indicate support for S/MIME by including
   the appropriate media type or types in the SIP Accept header field in
   a response to an OPTIONS request, or in a 415 (Unsupported Media
   Type) response to a SIP request that contained an unsupported media
   type in the body.  Unfortunately, this approach may not be reliable
   in the general case.  In the case where a downstream SIP proxy forks
   an OPTIONS or other non-INVITE request to multiple User Agent Servers
   (UASs), that proxy will only forward the "best" response.  If the
   recipient has multiple devices, the sender may only learn the
   capabilities of the device that sent the forwarded response.  Blindly
   trusting this information could result in S/MIME messages being sent
   to UAs that do not support it, which would be at best confusing and
   at worst misleading to the recipient.
Top   ToC   RFC8591 - Page 12
   UAs might be able to use the UA capabilities framework [RFC3840] to
   indicate support.  However, doing so would require the registration
   of one or more media feature tags with IANA.

   UAs MAY use other out-of-band methods to indicate their level of
   support for S/MIME.

7.3.  Failure Cases

   Section 23.2 of [RFC3261] requires that the recipient of a SIP
   request that includes a body part of an unsupported media type and a
   Content-Disposition header field "handling" parameter of "required"
   return a 415 (Unsupported Media Type) response.  Given that SIP
   MESSAGE exists for no reason other than to deliver content in the
   body, it is reasonable to treat the top-level body part as always
   required.  However, [RFC3428] makes no such assertion.  This document
   updates Section 11.3 of [RFC3428] to add the statement that a UAC
   that receives a SIP MESSAGE request with an unsupported media type
   MUST return a 415 response.

   Section 23.2 of [RFC3261] says that if a recipient receives an S/MIME
   body encrypted to the wrong certificate, it MUST return a SIP 493
   (Undecipherable) response and SHOULD send a valid certificate in that
   response.  This is not always possible in practice for SIP MESSAGE
   requests.  The UAS may choose not to decrypt a message until the user
   is ready to read it.  Messages may be delivered to a message store or
   sent via a store-and-forward service.  This document updates RFC 3261
   to say that the UAS SHOULD return a SIP 493 response if it
   immediately attempts to decrypt the message and determines that the
   message was encrypted to the wrong certificate.  However, it MAY
   return a 200-class response if decryption is deferred.

8.  Using S/MIME with MSRP

   MSRP has features that interact with the use of S/MIME.  In
   particular, the ability to send messages in chunks, the ability to
   send messages of unknown size, and the use of SDP to indicate
   media-type support create considerations for the use of S/MIME.

8.1.  Chunking

   MSRP allows a message to be broken into "chunks" for transmission.
   In this context, the term "message" refers to an entire message that
   one user might send to another.  A chunk is a fragment of that
   message sent in a single MSRP SEND request.  All of the chunks that
   make up a particular message share the same Message-ID value.
Top   ToC   RFC8591 - Page 13
   The sending UA may break a message into chunks, which the receiving
   UA will reassemble to form the complete message.  Intermediaries such
   as MSRP relays [RFC4976] might break chunks into smaller chunks or
   might reassemble chunks into larger ones; therefore, the message
   received by the recipient may be broken into a different number of
   chunks than were sent by the recipient.  Intermediaries might also
   cause chunks to be received in a different order than sent.

   The sender MUST apply any S/MIME operations to the whole message
   prior to breaking it into chunks.  Likewise, the receiver needs to
   reassemble the message from its chunks prior to decrypting,
   validating a signature, etc.

   MSRP chunks are framed using an end-line.  The end-line comprises
   seven hyphens, a 64-bit random value taken from the start line, and a
   continuation flag.  MSRP requires the sending UA to scan data to be
   sent in a specific chunk to ensure that the end-line does not
   accidentally occur as part of the data.  This scanning occurs on a
   chunk rather than a whole message; consequently, it must occur after
   the sender applies any S/MIME operations.

8.2.  Streamed Data

   MSRP allows a mode of operation where a UA sends some chunks of a
   message prior to knowing the full length of the message.  For
   example, a sender might send streamed data over MSRP as a single
   message, even though it doesn't know the full length of that data in
   advance.  This mode is incompatible with S/MIME, since a sending UA
   must apply S/MIME operations to the entire message in advance of
   breaking it into chunks.

   Therefore, when sending a message in an S/MIME format, the sender
   MUST include the Byte-Range header field for every chunk, including
   the first chunk.  The Byte-Range header field MUST include the total
   length of the message.

   A higher layer could choose to break such streamed data into a series
   of messages prior to applying S/MIME operations, so that each
   fragment appears as a distinct (separate) S/MIME message in MSRP.
   Such mechanisms are beyond the scope of this document.
Top   ToC   RFC8591 - Page 14
8.3.  Indicating Support for S/MIME

   A UA that supports this specification MUST explicitly include the
   appropriate media type or types in the "accept-types" attribute in
   any SDP offer or answer that proposes MSRP.  It MAY indicate that it
   requires S/MIME wrappers for all messages by putting appropriate
   S/MIME media types in the "accept-types" attribute and putting all
   other supported media types in the "accept-wrapped-types" attribute.

   For backwards compatibility, a sender MAY treat a peer that includes
   an asterisk ("*") in the "accept-types" attribute as potentially
   supporting S/MIME.  If the peer returns an MSRP 415 (MIME type not
   understood) response to an attempt to send an S/MIME message, the
   sender should treat the peer as not supporting S/MIME for the
   duration of the session, as indicated in Section 7.3.1 of [RFC4975].

   While these SDP attributes allow an endpoint to express support for
   certain media types only when wrapped in a specified envelope type,
   it does not allow the expression of more complex structures.  For
   example, an endpoint can say that it supports text/plain and
   text/html, but only when inside an application/pkcs7 or message/cpim
   container, but it cannot express a requirement for the leaf types to
   always be contained in an application/pkcs7 container nested inside a
   message/cpim container.  This has implications for the use of S/MIME
   with the message/cpim format.  (See Section 9.1.)

   MSRP allows multiple reporting modes that provide different levels of
   feedback.  If the sender includes a Failure-Report header field with
   a value of "no", it will not receive failure reports.  This mode
   should not be used carelessly, since such a sender would never see a
   415 response as described above and would have no way to learn that
   the recipient could not process an S/MIME body.

8.4.  MSRP URIs

   MSRP URIs are ephemeral.  Endpoints MUST NOT use MSRP URIs to
   identify certificates or insert MSRP URIs into certificate Subject
   Alternative Name fields.  When MSRP sessions are negotiated using SIP
   [RFC3261], the SIP AoRs of the peers are used instead.

   Note that MSRP allows messages to be sent between peers in either
   direction.  A given MSRP message might be sent from the SIP offerer
   to the SIP answerer.  Thus, the sender and recipient roles may
   reverse between one message and another in a given session.
Top   ToC   RFC8591 - Page 15
8.5.  Failure Cases

   Successful delivery of an S/MIME message does not indicate that the
   recipient successfully decrypted the contents or validated a
   signature.  Decryption and/or validation may not occur immediately on
   receipt, since the recipient may not immediately view the message,
   and the UA may choose not to attempt decryption or validation until
   the user requests it.

   Likewise, successful delivery of S/MIME enveloped data does not, on
   its own, indicate that the recipient supports the enclosed media
   type.  If the peer only implicitly indicated support for the enclosed
   media type through the use of a wildcard in the "accept-types" or
   "accept-wrapped types" SDP attributes, it may not decrypt the message
   in time to send a 415 response.

9.  S/MIME Interaction with Other SIP Messaging Features

9.1.  Common Profile for Instant Messaging

   The Common Profile for Instant Messaging (CPIM) [RFC3860] defines an
   abstract messaging service, with the goal of creating gateways
   between different messaging protocols that could relay instant
   messages without change.  The SIP MESSAGE method and MSRP were
   initially designed to map to the CPIM abstractions.  However, at the
   time of this writing, CPIM-compliant gateways have not been deployed.
   To the authors' knowledge, no other IM protocols have been explicitly
   mapped to CPIM.

   CPIM also defines the abstract messaging URI scheme "im:".  As of the
   time of this writing, the "im:" scheme is not in common use.

   The CPIM message format [RFC3862] allows UAs to attach
   transport-neutral metadata to arbitrary MIME content.  The format was
   designed as a canonicalization format to allow signed data to cross
   protocol-converting gateways without loss of metadata needed to
   verify the signature.  While it has not typically been used for that
   purpose, it has been used for other metadata applications -- for
   example, IMDNs [RFC5438] and MSRP multi-party chat [RFC7701].

   In the general case, a sender applies end-to-end signature and
   encryption operations to the entire MIME body.  However, some
   messaging systems expect to inspect and in some cases add or modify
   metadata in CPIM header fields.  For example, CPM-based and RCS-based
   services include application servers that may need to insert
   timestamps into chat messages and may use additional metadata to
   characterize the content and purpose of a message to determine
   application behavior.  The former will cause validation failure for
Top   ToC   RFC8591 - Page 16
   signatures that cover CPIM metadata, while the latter is not possible
   if the metadata is encrypted.  Clients intended for use in such
   networks MAY choose to apply end-to-end signatures and encryption
   operations to only the CPIM payload, leaving the CPIM metadata
   unprotected from inspection and modification.  UAs that support
   S/MIME and CPIM SHOULD be able to validate signatures and decrypt
   enveloped data both (1) when those operations are applied to the
   entire CPIM body and (2) when they are applied to just the CPIM
   payload.  This means that the receiver needs to be flexible in its
   MIME document parsing and that it cannot make assumptions that
   S/MIME-protected body parts will always be in the same position or
   level in the message payload.

   If such clients need to encrypt or sign CPIM metadata end to end,
   they can nest a protected CPIM message format payload inside an
   unprotected CPIM message envelope.

   The use of CPIM metadata fields to identify certificates or to
   authenticate SIP or MSRP header fields is out of scope for this

9.2.  Instant Message Disposition Notifications

   The IMDN mechanism [RFC5438] allows both endpoints and intermediary
   application servers to request and to generate delivery
   notifications.  The use of S/MIME does not impact strictly end-to-end
   use of IMDNs.  The IMDN mechanism recommends that devices that are
   capable of doing so sign delivery notifications.  It further requires
   that delivery notifications that result from encrypted messages also
   be encrypted.

   However, the IMDN mechanism allows intermediary application servers
   to insert notification requests into messages, to add routing
   information to messages, and to act on notification requests.  It
   also allows list servers to aggregate delivery notifications.

   Such intermediaries will be unable to read end-to-end encrypted
   messages in order to interpret delivery notice requests.
   Intermediaries that insert information into end-to-end signed
   messages will cause the signature validation to fail.  (See
   Section 9.1.)

Next Section