From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001
From: Thomas Voss <mail@thomasvoss.com>
Date: Wed, 27 Nov 2024 20:54:24 +0100
Subject: doc: Add RFC documents

---
 doc/rfc/rfc8591.txt | 2187 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 2187 insertions(+)
 create mode 100644 doc/rfc/rfc8591.txt

(limited to 'doc/rfc/rfc8591.txt')

diff --git a/doc/rfc/rfc8591.txt b/doc/rfc/rfc8591.txt
new file mode 100644
index 0000000..a6fe881
--- /dev/null
+++ b/doc/rfc/rfc8591.txt
@@ -0,0 +1,2187 @@
+
+
+
+
+
+
+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
+
+Abstract
+
+   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
+   https://www.rfc-editor.org/info/rfc8591.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Campbell & Housley           Standards Track                    [Page 1]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+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
+   (https://trustee.ietf.org/license-info) 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Campbell & Housley           Standards Track                    [Page 2]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+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
+
+
+
+
+
+
+Campbell & Housley           Standards Track                    [Page 3]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+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",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "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.
+
+
+
+Campbell & Housley           Standards Track                    [Page 4]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+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
+   document.
+
+
+
+
+
+Campbell & Housley           Standards Track                    [Page 5]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+Campbell & Housley           Standards Track                    [Page 6]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+   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
+   algorithms.
+
+   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
+   smime-type=auth-enveloped-data.
+
+
+
+
+
+
+
+
+
+
+Campbell & Housley           Standards Track                    [Page 7]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+   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
+   algorithms.
+
+   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 }
+
+
+
+
+
+
+Campbell & Housley           Standards Track                    [Page 8]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+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
+   order.
+
+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 4.2.1.6.
+   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.
+
+
+
+Campbell & Housley           Standards Track                    [Page 9]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+   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
+   entity.
+
+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
+   "application/pkcs7-signature".
+
+   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.)
+
+
+
+
+
+Campbell & Housley           Standards Track                   [Page 10]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+   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.
+
+
+
+
+
+Campbell & Housley           Standards Track                   [Page 11]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+   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.
+
+
+
+
+
+Campbell & Housley           Standards Track                   [Page 12]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+Campbell & Housley           Standards Track                   [Page 13]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+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.
+
+
+
+
+
+
+
+Campbell & Housley           Standards Track                   [Page 14]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+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
+
+
+
+Campbell & Housley           Standards Track                   [Page 15]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+   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
+   document.
+
+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.)
+
+
+
+
+
+
+
+
+
+
+Campbell & Housley           Standards Track                   [Page 16]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+10.  Examples
+
+   The following sections show examples of S/MIME messages in SIP and
+   MSRP.  The examples include the tags "[start-hex]" and "[end-hex]" to
+   denote binary content shown in hexadecimal.  The tags are not part of
+   the actual message and do not count towards the Content-Length header
+   field values.
+
+   In all of these examples, the cleartext message is the string
+   "Watson, come here - I want to see you." followed by a newline
+   character.
+
+   The cast of characters includes Alice, with a SIP AoR of
+   "alice@example.com", and Bob, with a SIP AoR of "bob@example.org".
+
+   Appendix A shows the detailed content of each S/MIME body.
+
+10.1.  Signed Message in SIP including the Sender's Certificate
+
+   Figure 1 shows a message signed by Alice.  This body uses the
+   "application/pkcs7-mime" media type with an smime-type parameter
+   value of "signed-data".
+
+   The S/MIME body includes Alice's signing certificate.  Even though
+   the original message content is fairly short and only minimal SIP
+   header fields are included, the total message size approaches the
+   maximum allowed for the SIP MESSAGE method unless the UAC has advance
+   knowledge that all SIP hops will use congestion-controlled transport
+   protocols.  A message that included all the SIP header fields that
+   are commonly in use in some SIP deployments would likely exceed the
+   limit.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Campbell & Housley           Standards Track                   [Page 17]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+   MESSAGE sip:bob@example.org SIP/2.0
+   Via: SIP/2.0/TCP alice-pc.example.com;branch=z9hG4bK776sgdkfie
+   Max-Forwards: 70
+   From: sip:alice@example.com;tag=49597
+   To: sip:bob@example.org
+   Call-ID: asd88asd66b@1.2.3.4
+   CSeq: 1 MESSAGE
+   Content-Transfer-Encoding: binary
+   Content-Type: application/pkcs7-mime; smime-type=signed-data;
+                 name="smime.p7m"
+   Content-Disposition: attachment; filename="smime.p7m"
+   Content-Length: 762
+
+   [start-hex]
+   308202f606092a864886f70d010702a08202e7308202e3020101310d300b0609
+   608648016503040201305306092a864886f70d010701a0460444436f6e74656e
+   742d547970653a20746578742f706c61696e0d0a0d0a576174736f6e2c20636f
+   6d652068657265202d20492077616e7420746f2073656520796f752e0d0aa082
+   016b308201673082010da003020102020900b8793ec0e4c21530300a06082a86
+   48ce3d040302302631143012060355040a0c0b6578616d706c652e636f6d310e
+   300c06035504030c05416c696365301e170d3137313231393233313230355a17
+   0d3138313231393233313230355a302631143012060355040a0c0b6578616d70
+   6c652e636f6d310e300c06035504030c05416c6963653059301306072a8648ce
+   3d020106082a8648ce3d03010703420004d87b54729f2c22feebd9ddba0efa40
+   642297a6093887a4dae7990b23f87fa7ed99db8cf5a314f2ee64106ef1ed61db
+   fc0a4b91c953cbd022a751b914807bb794a324302230200603551d1104193017
+   86157369703a616c696365406578616d706c652e636f6d300a06082a8648ce3d
+   040302034800304502207879be1c27f846276fdf15e333e53c6f17a757388a02
+   cb7b8ae481c1641ae7a9022100ff99cd9c94076c82b02fea3b1350179a4b7752
+   e16fa30a3f9ab29650b0e2818931820109308201050201013033302631143012
+   060355040a0c0b6578616d706c652e636f6d310e300c06035504030c05416c69
+   6365020900b8793ec0e4c21530300b0609608648016503040201a06930180609
+   2a864886f70d010903310b06092a864886f70d010701301c06092a864886f70d
+   010905310f170d3139303132363036313335345a302f06092a864886f70d0109
+   0431220420ef778fc940d5e6dc2576f47a599b3126195a9f1a227adaf35fa22c
+   050d8d195a300a06082a8648ce3d04030204473045022005fdc2b55b0f444a46
+   be468dfc7ef3b7de30019ef0952a223e8521890b35bb4e02210090e43a9d9846
+   cf2af8159c5c0ef48848fa2f39f998b1bb99b52a6fc6c776f2c8
+   [end-hex]
+
+
+                      Figure 1: Signed Message in SIP
+
+
+
+
+
+
+
+
+
+Campbell & Housley           Standards Track                   [Page 18]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+10.2.  Signed Message in SIP with No Certificate
+
+   Figure 2 shows the same message from Alice without the embedded
+   certificate.  The shorter total message length may be more
+   manageable.
+
+   MESSAGE sip:bob@example.org SIP/2.0
+   Via: SIP/2.0/TCP alice-pc.example.com;branch=z9hG4bK776sgdkfie
+   Max-Forwards: 70
+   From: sip:alice@example.com;tag=49597
+   To: sip:bob@example.org
+   Call-ID: asd88asd66b@1.2.3.4
+   CSeq: 1 MESSAGE
+   Content-Transfer-Encoding: binary
+   Content-Type: application/pkcs7-mime; smime-type=signed-data;
+                 name="smime.p7m"
+   Content-Disposition: attachment; filename="smime.p7m"
+   Content-Length: 395
+
+   [start-hex]
+   3082018706092a864886f70d010702a082017830820174020101310d300b0609
+   608648016503040201305306092a864886f70d010701a0460444436f6e74656e
+   742d547970653a20746578742f706c61696e0d0a0d0a576174736f6e2c20636f
+   6d652068657265202d20492077616e7420746f2073656520796f752e0d0a3182
+   0109308201050201013033302631143012060355040a0c0b6578616d706c652e
+   636f6d310e300c06035504030c05416c696365020900b8793ec0e4c21530300b
+   0609608648016503040201a069301806092a864886f70d010903310b06092a86
+   4886f70d010701301c06092a864886f70d010905310f170d3139303132363036
+   313335345a302f06092a864886f70d01090431220420ef778fc940d5e6dc2576
+   f47a599b3126195a9f1a227adaf35fa22c050d8d195a300a06082a8648ce3d04
+   03020447304502203607275592d30c8c5a931041a01804d60c638ac9a8080918
+   87172a0887c8d4aa022100cd9e14bd21817336e9052fe590af2e2bcde16dd3e9
+   48d0f5f78a969e26382682
+   [end-hex]
+
+       Figure 2: Signed Message in SIP with No Certificate Included
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Campbell & Housley           Standards Track                   [Page 19]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+10.3.  MSRP Signed and Encrypted Message in a Single Chunk
+
+   Figure 3 shows a signed and encrypted message from Bob to Alice sent
+   via MSRP.
+
+   MSRP dsdfoe38sd SEND
+   To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
+   From-Path: msrp://bobpc.example.org:8888/9di4eae923wzd;tcp
+   Message-ID: 456so39s
+   Byte-Range: 1-1940/1940
+   Content-Disposition: attachment; filename="smime.p7m"
+   Content-Type: application/pkcs7-mime; smime-type=auth-enveloped-data;
+                 name="smime.p7m"
+
+   [start-hex]
+   30820790060b2a864886f70d0109100117a082077f3082077b0201003182024f
+   3082024b0201003033302631143012060355040a0c0b6578616d706c652e636f
+   6d310e300c06035504030c05416c69636502090083f50bb70bd5c40e300d0609
+   2a864886f70d010101050004820200759a61b4ddf1f1af24668005635e476110
+   fa2723c1b9e45484b6d33e8387de967dc5e0cafb35571a56a1975cb550e7be31
+   c131da80fb731024845babb8d64cac26040424d9330561c843999415dd644b3c
+   ad95072f71451393c99f282c4883bd0ccc5dd54b931464e00a6e55e592c51a68
+   de1062516ec7d3ca8e764bb8ac789a88377765ef8dc36c0a6ed3ecae5285cac6
+   a29d5059445719a1bdcf906e0ff37e2c2ef0f4ec6225100cc062e1c748963bbc
+   88b8e3dfcf714073729dd5c7583e758acf3d186f2fa417be22c37c9a76c6b427
+   29aad27f73ae44ac98474d1eeb48948c12a403d0b3ce08a218d6af456924897c
+   c5c9664f6dfeb3f18141158dfc3b84090aa60380aa865137e1699c5c81974167
+   9d7a3c90ba79e6d7d5c8d89bb54a667423e43b0b7d6f78c0b4ab67bc343662a6
+   35fe595f1149c53950cac2e0ba318c227e6f76a8d940400fd3d3ea1c8ecea003
+   dcce2f1fb00f5cea335de1303fcbf93d8e1cbfd682f19beb624bacd1d7b8f580
+   f114a13b890894fb4044a5daa764b7f8c5ff92949452b35aeb9639b8ad63c051
+   5c95ccc6f823c2201067ea2262413fef397d48f7b6143f842ae8e1a48cad3ae0
+   1abaa3cf9ee7e36620e05cca0611bfac00eef1a498f2d259b9f0f7da83ef6f1b
+   061f387c2dc48c8b5dbaca862308f32f47925165c9e5ebb467799884918dd697
+   b447f4c407989b889b0c2e9580af783082050f06092a864886f70d010701301e
+   06096086480165030401063011040c4d8757222eac5294117f0c120201108082
+   04e0fe2fb3de0bf06998c39bf4a952fabf8b0fee3d7e2e85181aecf1a89e1a2e
+   decd9404885612dfc6984334d8602b7749b2504e45f57c3b066626b0fc746236
+   1eec267c560139be5cd286a2af9696cf51852278e52c3818cab0a68c598de4fc
+   e14a333884e4de5ddf57edd78867027a31e4a7c0c0299144c5de6bae39699e70
+   0e057eb0f0dad73b8b369f42eb321b41538781d982a11a0b3943ac10c97b54ee
+   b73b38ec131afc5610e373487274d69cafa9541902886c64f6962d42eb33f904
+   1a4ae11b88dc6958d53df50b8bb52aa35e2299885d0aae416b86f0a88d0eb7a9
+   81dbb283e8b94e9d50bf6265c2348a18a169aacb5a37a529bda2f9cb10efddcf
+   14231095d87964637bd33fb13c68b4cff9a1906960c1ea2301d325b7a15c5829
+   f3ea038f24df6b23180377d37131f75db18f41f9d85b653dfa46bf2617126326
+   ccf1cb833457752352c8417a094484d7b64bcf51b26a9beb3a0ed4b9caf1bd23
+   c690c654f7eb9ce9852e2f6d068eef8ba33bc6c4dddca7aef4d3574737d7c4dc
+
+
+
+Campbell & Housley           Standards Track                   [Page 20]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+   1e93770d8f4f22dea61d73083c32c4038c1eb3dd3383a89a8795e241c2ed7cb6
+   80758c041069489860fc9f490e85236072548b3249698f99953acf1ec658b7aa
+   85e554c449701a6d4b039ed103dc458df4b29cb04b8cedd540c84348da79c186
+   56d5188f9f3a9e4b9b840c70664b90296c60b7ac984e918d48a09dbddfb281fc
+   862510db59d9fa9dc93f10f9c6d7bef72931d184cad7ac13c1a5295fc89fe3bb
+   7eb8e02085a828c5a138786e607ade4f5e8d4115909209ba878a79305a5316c2
+   2229e42b886d06481c8473f9d51269e2af6341bce20f768e860d7784ed46150e
+   04ff50cd209c5b127511369fe06bc4aa9a72d8f1fe4fcf0866d664b365ffa86e
+   8c1b43e7a9212aecc16ca350a28efae25fac054dd934bfe7e5fa4f753aa41596
+   8c7ebec439e0ac0270b4874a068d22484c09d9e8abe17f1372b4b2f65f1148e8
+   933eda92e5d1774564963b391c3bbd9f1c27ffe36f832e05155fc39ee6652fa7
+   b4188975ec5c67b32c9f213c8ac6b8e132a5a7c3bf74f016405cd8c201d10521
+   93e186d44358de388d73211ba2f1792f3cfeb9bbde7211d26f56ab06e11ccc9c
+   cde2b88cd8373773eafc37fd85b7a7a2bcaec752e617d6e01c02b86e9d9a40f3
+   20462c5d66f8351716dcd6014bdf30a60f75fc0631c920845ed8c0bad35ddf19
+   84f2241cd3b529dc1028845f8089543df4f1441ede36b1bf31af5afc8c2b708d
+   50b645d4e7db88648c3eefe14765158fb0e8d3bb53ddcbe26d7124c6e1d992f8
+   3230aa953376ee8c68109568e8571f0c9bbda48f4df306fe747f371175148f31
+   832767cd766cf07b450cbf62cad2a7bd71f1f88233f116a1a7f3caf12f34bcf4
+   0d21e79ffc9827221b68b080ff03ad782d6d6d07871676f798943e54f13fd75c
+   89c0b4263bf10f56243f9e72ef3b3899a539d9a3ac5be2b69400a3cf8d196c5c
+   ed697b2ed803b987a5ee85c5095b48da7a5b03b47e2b9fe4cd4bc3098e864e0c
+   e7d467da99cd7f3a9e947b5eea77f7a6be16c8c7e9e0decc1ff132559c234321
+   7b9c2950386e85d2942121086cdfa19658195be6d7f86bca9881b695082964f1
+   2e7cf801025d6792c6882409414d703321ec83abd698d68956118713a0ff1272
+   acbc9a6d148900c74c16921df9b38f29ec46d4f10060fffe5e36bbbacaf2d1ba
+   d7dd057ed3e30ebcd69083f9d3a2a26ef90b751d6a1adfa0590db19da107cf3e
+   a8db0410f6ffc6e1aef19cd23d985a921976352d
+   [end-hex]
+   -------dsdfoe38sd$
+
+              Figure 3: Signed and Encrypted Message in MSRP
+
+10.4.  MSRP Signed and Encrypted Message Sent in Multiple Chunks
+
+   Figure 4 shows the same message as in Figure 3 except that the
+   message is broken into two chunks.  The S/MIME operations were
+   performed prior to breaking the message into chunks.
+
+   MSRP d93kswow SEND
+   To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
+   From-Path: msrp://bobpc.example.org:8888/9di4eae923wzd;tcp
+   Message-ID: 12339sdqwer
+   Byte-Range: 1-960/1940
+   Content-Disposition: attachment; filename="smime.p7m"
+   Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
+                 name="smime.p7m"
+
+
+
+
+Campbell & Housley           Standards Track                   [Page 21]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+   [start-hex]
+   30820790060b2a864886f70d0109100117a082077f3082077b0201003182024f
+   3082024b0201003033302631143012060355040a0c0b6578616d706c652e636f
+   6d310e300c06035504030c05416c69636502090083f50bb70bd5c40e300d0609
+   2a864886f70d010101050004820200759a61b4ddf1f1af24668005635e476110
+   fa2723c1b9e45484b6d33e8387de967dc5e0cafb35571a56a1975cb550e7be31
+   c131da80fb731024845babb8d64cac26040424d9330561c843999415dd644b3c
+   ad95072f71451393c99f282c4883bd0ccc5dd54b931464e00a6e55e592c51a68
+   de1062516ec7d3ca8e764bb8ac789a88377765ef8dc36c0a6ed3ecae5285cac6
+   a29d5059445719a1bdcf906e0ff37e2c2ef0f4ec6225100cc062e1c748963bbc
+   88b8e3dfcf714073729dd5c7583e758acf3d186f2fa417be22c37c9a76c6b427
+   29aad27f73ae44ac98474d1eeb48948c12a403d0b3ce08a218d6af456924897c
+   c5c9664f6dfeb3f18141158dfc3b84090aa60380aa865137e1699c5c81974167
+   9d7a3c90ba79e6d7d5c8d89bb54a667423e43b0b7d6f78c0b4ab67bc343662a6
+   35fe595f1149c53950cac2e0ba318c227e6f76a8d940400fd3d3ea1c8ecea003
+   dcce2f1fb00f5cea335de1303fcbf93d8e1cbfd682f19beb624bacd1d7b8f580
+   f114a13b890894fb4044a5daa764b7f8c5ff92949452b35aeb9639b8ad63c051
+   5c95ccc6f823c2201067ea2262413fef397d48f7b6143f842ae8e1a48cad3ae0
+   1abaa3cf9ee7e36620e05cca0611bfac00eef1a498f2d259b9f0f7da83ef6f1b
+   061f387c2dc48c8b5dbaca862308f32f47925165c9e5ebb467799884918dd697
+   b447f4c407989b889b0c2e9580af783082050f06092a864886f70d010701301e
+   06096086480165030401063011040c4d8757222eac5294117f0c120201108082
+   04e0fe2fb3de0bf06998c39bf4a952fabf8b0fee3d7e2e85181aecf1a89e1a2e
+   decd9404885612dfc6984334d8602b7749b2504e45f57c3b066626b0fc746236
+   1eec267c560139be5cd286a2af9696cf51852278e52c3818cab0a68c598de4fc
+   e14a333884e4de5ddf57edd78867027a31e4a7c0c0299144c5de6bae39699e70
+   0e057eb0f0dad73b8b369f42eb321b41538781d982a11a0b3943ac10c97b54ee
+   b73b38ec131afc5610e373487274d69cafa9541902886c64f6962d42eb33f904
+   1a4ae11b88dc6958d53df50b8bb52aa35e2299885d0aae416b86f0a88d0eb7a9
+   81dbb283e8b94e9d50bf6265c2348a18a169aacb5a37a529bda2f9cb10efddcf
+   14231095d87964637bd33fb13c68b4cff9a1906960c1ea2301d325b7a15c5829
+   [end-hex]
+   -------d93kswow+
+
+
+   MSRP op2nc9a SEND
+   To-Path: msrp://alicepc.example.com:8888/9di4eae923wzd;tcp
+   From-Path: msrp://bobpc.example.org:7654/iau39soe2843z;tcp
+   Message-ID: 12339sdqwer
+   Byte-Range: 961-1940/1940
+   Content-Disposition: attachment; filename="smime.p7m"
+   Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
+                 name="smime.p7m"
+
+
+
+
+
+
+
+
+Campbell & Housley           Standards Track                   [Page 22]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+   [start-hex]
+   f3ea038f24df6b23180377d37131f75db18f41f9d85b653dfa46bf2617126326
+   ccf1cb833457752352c8417a094484d7b64bcf51b26a9beb3a0ed4b9caf1bd23
+   c690c654f7eb9ce9852e2f6d068eef8ba33bc6c4dddca7aef4d3574737d7c4dc
+   1e93770d8f4f22dea61d73083c32c4038c1eb3dd3383a89a8795e241c2ed7cb6
+   80758c041069489860fc9f490e85236072548b3249698f99953acf1ec658b7aa
+   85e554c449701a6d4b039ed103dc458df4b29cb04b8cedd540c84348da79c186
+   56d5188f9f3a9e4b9b840c70664b90296c60b7ac984e918d48a09dbddfb281fc
+   862510db59d9fa9dc93f10f9c6d7bef72931d184cad7ac13c1a5295fc89fe3bb
+   7eb8e02085a828c5a138786e607ade4f5e8d4115909209ba878a79305a5316c2
+   2229e42b886d06481c8473f9d51269e2af6341bce20f768e860d7784ed46150e
+   04ff50cd209c5b127511369fe06bc4aa9a72d8f1fe4fcf0866d664b365ffa86e
+   8c1b43e7a9212aecc16ca350a28efae25fac054dd934bfe7e5fa4f753aa41596
+   8c7ebec439e0ac0270b4874a068d22484c09d9e8abe17f1372b4b2f65f1148e8
+   933eda92e5d1774564963b391c3bbd9f1c27ffe36f832e05155fc39ee6652fa7
+   b4188975ec5c67b32c9f213c8ac6b8e132a5a7c3bf74f016405cd8c201d10521
+   93e186d44358de388d73211ba2f1792f3cfeb9bbde7211d26f56ab06e11ccc9c
+   cde2b88cd8373773eafc37fd85b7a7a2bcaec752e617d6e01c02b86e9d9a40f3
+   20462c5d66f8351716dcd6014bdf30a60f75fc0631c920845ed8c0bad35ddf19
+   84f2241cd3b529dc1028845f8089543df4f1441ede36b1bf31af5afc8c2b708d
+   50b645d4e7db88648c3eefe14765158fb0e8d3bb53ddcbe26d7124c6e1d992f8
+   3230aa953376ee8c68109568e8571f0c9bbda48f4df306fe747f371175148f31
+   832767cd766cf07b450cbf62cad2a7bd71f1f88233f116a1a7f3caf12f34bcf4
+   0d21e79ffc9827221b68b080ff03ad782d6d6d07871676f798943e54f13fd75c
+   89c0b4263bf10f56243f9e72ef3b3899a539d9a3ac5be2b69400a3cf8d196c5c
+   ed697b2ed803b987a5ee85c5095b48da7a5b03b47e2b9fe4cd4bc3098e864e0c
+   e7d467da99cd7f3a9e947b5eea77f7a6be16c8c7e9e0decc1ff132559c234321
+   7b9c2950386e85d2942121086cdfa19658195be6d7f86bca9881b695082964f1
+   2e7cf801025d6792c6882409414d703321ec83abd698d68956118713a0ff1272
+   acbc9a6d148900c74c16921df9b38f29ec46d4f10060fffe5e36bbbacaf2d1ba
+   d7dd057ed3e30ebcd69083f9d3a2a26ef90b751d6a1adfa0590db19da107cf3e
+   a8db0410f6ffc6e1aef19cd23d985a921976352d
+   [end-hex]
+   -------op2nc9a$
+
+           Figure 4: Signed, Encrypted, and Chunked MSRP Message
+
+11.  IANA Considerations
+
+   This document has no IANA actions.
+
+12.  Security Considerations
+
+   The security considerations for S/MIME [RFC8550] [RFC8551] and
+   elliptic curves in CMS [RFC5753] apply.  The S/MIME-related security
+   considerations for SIP [RFC3261], SIP MESSAGE [RFC3428], and MSRP
+   [RFC4975] apply.
+
+
+
+
+Campbell & Housley           Standards Track                   [Page 23]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+   The security considerations for algorithms recommended in this
+   document also apply; see [RFC3565], [RFC5480], [RFC5753], [RFC5754],
+   [RFC7748], [RFC8032], [RFC8418], and [RFC8419].
+
+   This document assumes that end-entity certificate validation is
+   provided by a chain of trust to a certification authority (CA), using
+   a public key infrastructure.  The security considerations from
+   [RFC5280] apply.  However, other validations methods may be possible
+   -- for example, sending a signed fingerprint for the end entity in
+   SDP.  The relationship between this work and the techniques discussed
+   in [RFC8224] and [RTP-Sec] are out of scope for this document.
+
+   When matching an end-entity certificate to the sender or recipient
+   identity, the respective SIP AoRs are used.  Typically, these will
+   match the SIP From and To header fields.  Some UAs may extract the
+   sender identity from SIP AoRs in other header fields -- for example,
+   P-Asserted-Identity [RFC3325].  In general, the UAS should compare
+   the certificate to the identity that it relies upon -- for example,
+   for display to the end user or comparison against message-filtering
+   rules.
+
+   The secure notification use case discussed in Section 1 has
+   significant vulnerabilities when used in an insecure environment.
+   For example, "phishing" messages could be used to trick users into
+   revealing credentials.  Eavesdroppers could learn confirmation codes
+   from unprotected two-factor authentication messages.  Unsolicited
+   messages sent by impersonators could tarnish the reputation of an
+   organization.  While hop-by-hop protection can mitigate some of those
+   risks, it still leaves messages vulnerable to malicious or
+   compromised intermediaries.  End-to-end protection prevents
+   modification by intermediaries.  However, neither provides much
+   protection unless the recipient knows to expect messages from a
+   particular sender to be signed and refuses to accept unsigned
+   messages that appear to be from that source.
+
+   Mobile messaging is typically an online application; online
+   certificate revocation checks should usually be feasible.
+
+   S/MIME does not normally protect the SIP or MSRP headers.  While it
+   normally does protect the CPIM header, certain CPIM header fields may
+   not be protected if the sender excludes them from the encrypted or
+   signed part of the message.  (See Section 9.1.)  Certain messaging
+   services -- for example, those based on RCS -- may include
+   intermediaries that attach metadata to user-generated messages in the
+   form of SIP, MSRP, or CPIM header fields.  This metadata could
+   possibly reveal information to third parties that the sender might
+
+
+
+
+
+Campbell & Housley           Standards Track                   [Page 24]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+   prefer not to send as cleartext.  Implementors and operators should
+   consider whether inserted metadata may create privacy leaks.  Such an
+   analysis is beyond the scope of this document.
+
+   MSRP messages broken into chunks must be reassembled by the recipient
+   prior to decrypting or validation of signatures.  (See Section 8.1.)
+   Section 14.5 of [RFC4975] describes a potential denial-of-service
+   attack where the attacker puts large values in the Byte-Range header
+   field.  Implementations should sanity-check these values before
+   allocating memory space for reassembly.
+
+   Modification of the ciphertext in EnvelopedData can go undetected if
+   authentication is not also used, which is the case when sending
+   EnvelopedData without wrapping it in SignedData or enclosing
+   SignedData within it.  This is one of the reasons for moving from
+   EnvelopedData to AuthEnvelopedData, as the authenticated encryption
+   algorithms provide the authentication without needing the SignedData
+   layer.
+
+   An attack on S/MIME implementations of HTML and multipart/mixed
+   messages is highlighted in [Efail].  To avoid this attack, clients
+   MUST ensure that a text/html content type is a complete HTML
+   document.  Clients SHOULD treat each of the different pieces of the
+   multipart/mixed construct as coming from different origins.  Clients
+   MUST treat each encrypted or signed piece of a MIME message as being
+   from different origins both from unprotected content and from each
+   other.
+
+13.  References
+
+13.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+              A., Peterson, J., Sparks, R., Handley, M., and E.
+              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+              DOI 10.17487/RFC3261, June 2002,
+              <https://www.rfc-editor.org/info/rfc3261>.
+
+   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
+              with Session Description Protocol (SDP)", RFC 3264,
+              DOI 10.17487/RFC3264, June 2002,
+              <https://www.rfc-editor.org/info/rfc3264>.
+
+
+
+
+Campbell & Housley           Standards Track                   [Page 25]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+   [RFC3428]  Campbell, B., Ed., Rosenberg, J., Schulzrinne, H.,
+              Huitema, C., and D. Gurle, "Session Initiation Protocol
+              (SIP) Extension for Instant Messaging", RFC 3428,
+              DOI 10.17487/RFC3428, December 2002,
+              <https://www.rfc-editor.org/info/rfc3428>.
+
+   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
+              Encryption Algorithm in Cryptographic Message Syntax
+              (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003,
+              <https://www.rfc-editor.org/info/rfc3565>.
+
+   [RFC3853]  Peterson, J., "S/MIME Advanced Encryption Standard (AES)
+              Requirement for the Session Initiation Protocol (SIP)",
+              RFC 3853, DOI 10.17487/RFC3853, July 2004,
+              <https://www.rfc-editor.org/info/rfc3853>.
+
+   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+              Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
+              July 2006, <https://www.rfc-editor.org/info/rfc4566>.
+
+   [RFC4975]  Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed.,
+              "The Message Session Relay Protocol (MSRP)", RFC 4975,
+              DOI 10.17487/RFC4975, September 2007,
+              <https://www.rfc-editor.org/info/rfc4975>.
+
+   [RFC5084]  Housley, R., "Using AES-CCM and AES-GCM Authenticated
+              Encryption in the Cryptographic Message Syntax (CMS)",
+              RFC 5084, DOI 10.17487/RFC5084, November 2007,
+              <https://www.rfc-editor.org/info/rfc5084>.
+
+   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+              Housley, R., and W. Polk, "Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
+              <https://www.rfc-editor.org/info/rfc5280>.
+
+   [RFC5480]  Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
+              "Elliptic Curve Cryptography Subject Public Key
+              Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
+              <https://www.rfc-editor.org/info/rfc5480>.
+
+   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
+              RFC 5652, DOI 10.17487/RFC5652, September 2009,
+              <https://www.rfc-editor.org/info/rfc5652>.
+
+
+
+
+
+
+
+Campbell & Housley           Standards Track                   [Page 26]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+   [RFC5753]  Turner, S. and D. Brown, "Use of Elliptic Curve
+              Cryptography (ECC) Algorithms in Cryptographic Message
+              Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January
+              2010, <https://www.rfc-editor.org/info/rfc5753>.
+
+   [RFC5754]  Turner, S., "Using SHA2 Algorithms with Cryptographic
+              Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January
+              2010, <https://www.rfc-editor.org/info/rfc5754>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8418]  Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key
+              Agreement Algorithm with X25519 and X448 in the
+              Cryptographic Message Syntax (CMS)", RFC 8418,
+              DOI 10.17487/RFC8418, August 2018,
+              <https://www.rfc-editor.org/info/rfc8418>.
+
+   [RFC8419]  Housley, R., "Use of Edwards-Curve Digital Signature
+              Algorithm (EdDSA) Signatures in the Cryptographic Message
+              Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419, August
+              2018, <https://www.rfc-editor.org/info/rfc8419>.
+
+   [RFC8550]  Schaad, J., Ramsdell, B., and S. Turner, "Secure/
+              Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
+              Certificate Handling", RFC 8550, DOI 10.17487/RFC8550,
+              April 2019, <https://www.rfc-editor.org/info/rfc8550>.
+
+   [RFC8551]  Schaad, J., Ramsdell, B., and S. Turner, "Secure/
+              Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
+              Message Specification", RFC 8551, DOI 10.17487/RFC8551,
+              April 2019, <https://www.rfc-editor.org/info/rfc8551>.
+
+   [X680]     ITU-T, "Information technology -- Abstract Syntax Notation
+              One (ASN.1): Specification of basic notation",
+              ITU-T Recommendation X.680, ISO/IEC 8824-1, August 2015,
+              <https://www.itu.int/rec/T-REC-X.680>.
+
+   [X690]     ITU-T, "Information Technology -- ASN.1 encoding rules:
+              Specification of Basic Encoding Rules (BER), Canonical
+              Encoding Rules (CER) and Distinguished Encoding Rules
+              (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1, August
+              2015, <https://www.itu.int/rec/T-REC-X.690/>.
+
+
+
+
+
+
+
+Campbell & Housley           Standards Track                   [Page 27]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+13.2.  Informative References
+
+   [CPM]      Open Mobile Alliance, "OMA Converged IP Messaging System
+              Description, Candidate Version 2.2", September 2017.
+
+   [Efail]    Poddebniak, D., Dresen, C., Muller, J., Ising, F.,
+              Schinzel, S., Friedberger, S., Somorovsky, J., and J.
+              Schwenk, "Efail: Breaking S/MIME and OpenPGP Email
+              Encryption using Exfiltration Channels", August 2018,
+              <https://www.usenix.org/system/files/conference/
+              usenixsecurity18/sec18-poddebniak.pdf>.
+
+   [RCS]      GSMA, "RCS Universal Profile Service Definition Document,
+              Version 2.2", May 2018,
+              <https://www.gsma.com/futurenetworks/wp-
+              content/uploads/2018/05/
+              Universal-Profile-RCC.71-v2.2.pdf>.
+
+   [RFC3325]  Jennings, C., Peterson, J., and M. Watson, "Private
+              Extensions to the Session Initiation Protocol (SIP) for
+              Asserted Identity within Trusted Networks", RFC 3325,
+              DOI 10.17487/RFC3325, November 2002,
+              <https://www.rfc-editor.org/info/rfc3325>.
+
+   [RFC3840]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
+              "Indicating User Agent Capabilities in the Session
+              Initiation Protocol (SIP)", RFC 3840,
+              DOI 10.17487/RFC3840, August 2004,
+              <https://www.rfc-editor.org/info/rfc3840>.
+
+   [RFC3860]  Peterson, J., "Common Profile for Instant Messaging
+              (CPIM)", RFC 3860, DOI 10.17487/RFC3860, August 2004,
+              <https://www.rfc-editor.org/info/rfc3860>.
+
+   [RFC3862]  Klyne, G. and D. Atkins, "Common Presence and Instant
+              Messaging (CPIM): Message Format", RFC 3862,
+              DOI 10.17487/RFC3862, August 2004,
+              <https://www.rfc-editor.org/info/rfc3862>.
+
+   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
+              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
+              <https://www.rfc-editor.org/info/rfc4648>.
+
+   [RFC4976]  Jennings, C., Mahy, R., and A. Roach, "Relay Extensions
+              for the Message Sessions Relay Protocol (MSRP)", RFC 4976,
+              DOI 10.17487/RFC4976, September 2007,
+              <https://www.rfc-editor.org/info/rfc4976>.
+
+
+
+
+Campbell & Housley           Standards Track                   [Page 28]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+   [RFC5438]  Burger, E. and H. Khartabil, "Instant Message Disposition
+              Notification (IMDN)", RFC 5438, DOI 10.17487/RFC5438,
+              February 2009, <https://www.rfc-editor.org/info/rfc5438>.
+
+   [RFC6121]  Saint-Andre, P., "Extensible Messaging and Presence
+              Protocol (XMPP): Instant Messaging and Presence",
+              RFC 6121, DOI 10.17487/RFC6121, March 2011,
+              <https://www.rfc-editor.org/info/rfc6121>.
+
+   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
+              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
+              2015, <https://www.rfc-editor.org/info/rfc7515>.
+
+   [RFC7516]  Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
+              RFC 7516, DOI 10.17487/RFC7516, May 2015,
+              <https://www.rfc-editor.org/info/rfc7516>.
+
+   [RFC7701]  Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi-
+              party Chat Using the Message Session Relay Protocol
+              (MSRP)", RFC 7701, DOI 10.17487/RFC7701, December 2015,
+              <https://www.rfc-editor.org/info/rfc7701>.
+
+   [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
+              for Security", RFC 7748, DOI 10.17487/RFC7748, January
+              2016, <https://www.rfc-editor.org/info/rfc7748>.
+
+   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
+              Signature Algorithm (EdDSA)", RFC 8032,
+              DOI 10.17487/RFC8032, January 2017,
+              <https://www.rfc-editor.org/info/rfc8032>.
+
+   [RFC8224]  Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
+              "Authenticated Identity Management in the Session
+              Initiation Protocol (SIP)", RFC 8224,
+              DOI 10.17487/RFC8224, February 2018,
+              <https://www.rfc-editor.org/info/rfc8224>.
+
+   [RTP-Sec]  Peterson, J., Barnes, R., and R. Housley, "Best Practices
+              for Securing RTP Media Signaled with SIP", Work in
+              Progress, draft-ietf-sipbrandy-rtpsec-08, April 2019.
+
+
+
+
+
+
+
+
+
+
+
+Campbell & Housley           Standards Track                   [Page 29]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+Appendix A.  Message Details
+
+   The following section shows the detailed content of the S/MIME bodies
+   used in Section 10.
+
+A.1.  Signed Message
+
+   Figure 5 shows the details of the message signed by Alice used in the
+   example in Section 10.1.
+
+ CMS_ContentInfo:
+   contentType: pkcs7-signedData (1.2.840.113549.1.7.2)
+   d.signedData:
+     version: 1
+     digestAlgorithms:
+         algorithm: sha256 (2.16.840.1.101.3.4.2.1)
+         parameter: <ABSENT>
+     encapContentInfo:
+       eContentType: pkcs7-data (1.2.840.113549.1.7.1)
+       eContent:
+   0000 - 43 6f 6e 74 65 6e 74 2d-54 79 70 65 3a 20 74   Content-Type: t
+   000f - 65 78 74 2f 70 6c 61 69-6e 0d 0a 0d 0a 57 61   ext/plain....Wa
+   001e - 74 73 6f 6e 2c 20 63 6f-6d 65 20 68 65 72 65   tson, come here
+   002d - 20 2d 20 49 20 77 61 6e-74 20 74 6f 20 73 65    - I want to se
+   003c - 65 20 79 6f 75 2e 0d 0a-                       e you...
+     certificates:
+       d.certificate:
+         cert_info:
+           version: 2
+           serialNumber: 13292724773353297200
+           signature:
+             algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
+             parameter: <ABSENT>
+           issuer: O=example.com, CN=Alice
+           validity:
+             notBefore: Dec 19 23:12:05 2017 GMT
+             notAfter: Dec 19 23:12:05 2018 GMT
+           subject: O=example.com, CN=Alice
+           key:
+             algor:
+               algorithm: id-ecPublicKey (1.2.840.10045.2.1)
+               parameter: OBJECT:prime256v1 (1.2.840.10045.3.1.7)
+             public_key:  (0 unused bits)
+   0000 - 04 d8 7b 54 72 9f 2c 22-fe eb d9 dd ba 0e   ..{Tr.,"......
+   000e - fa 40 64 22 97 a6 09 38-87 a4 da e7 99 0b   .@d"...8......
+   001c - 23 f8 7f a7 ed 99 db 8c-f5 a3 14 f2 ee 64   #............d
+   002a - 10 6e f1 ed 61 db fc 0a-4b 91 c9 53 cb d0   .n..a...K..S..
+   0038 - 22 a7 51 b9 14 80 7b b7-94                  ".Q...{..
+
+
+
+Campbell & Housley           Standards Track                   [Page 30]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+           issuerUID: <ABSENT>
+           subjectUID: <ABSENT>
+           extensions:
+               object: X509v3 Subject Alternative Name (2.5.29.17)
+               critical: BOOL ABSENT
+               value:
+   0000 - 30 17 86 15 73 69 70 3a-61 6c 69 63 65   0...sip:alice
+   000d - 40 65 78 61 6d 70 6c 65-2e 63 6f 6d      @example.com
+         sig_alg:
+           algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
+           parameter: <ABSENT>
+         signature:  (0 unused bits)
+   0000 - 30 45 02 20 78 79 be 1c-27 f8 46 27 6f df 15   0E. xy..'.F'o..
+   000f - e3 33 e5 3c 6f 17 a7 57-38 8a 02 cb 7b 8a e4   .3.<o..W8...{..
+   001e - 81 c1 64 1a e7 a9 02 21-00 ff 99 cd 9c 94 07   ..d....!.......
+   002d - 6c 82 b0 2f ea 3b 13 50-17 9a 4b 77 52 e1 6f   l../.;.P..KwR.o
+   003c - a3 0a 3f 9a b2 96 50 b0-e2 81 89               ..?...P....
+     crls:
+       <ABSENT>
+     signerInfos:
+         version: 1
+         d.issuerAndSerialNumber:
+           issuer: O=example.com, CN=Alice
+           serialNumber: 13292724773353297200
+         digestAlgorithm:
+           algorithm: sha256 (2.16.840.1.101.3.4.2.1)
+           parameter: <ABSENT>
+         signedAttrs:
+             object: contentType (1.2.840.113549.1.9.3)
+             set:
+               OBJECT:pkcs7-data (1.2.840.113549.1.7.1)
+
+             object: signingTime (1.2.840.113549.1.9.5)
+             set:
+               UTCTIME:Jan 24 23:52:56 2019 GMT
+
+             object: messageDigest (1.2.840.113549.1.9.4)
+             set:
+               OCTET STRING:
+   0000 - ef 77 8f c9 40 d5 e6 dc-25 76 f4 7a 59   .w..@...%v.zY
+   000d - 9b 31 26 19 5a 9f 1a 22-7a da f3 5f a2   .1&.Z.."z.._.
+   001a - 2c 05 0d 8d 19 5a                        ,....Z
+         signatureAlgorithm:
+           algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
+           parameter: <ABSENT>
+
+
+
+
+
+
+Campbell & Housley           Standards Track                   [Page 31]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+         signature:
+   0000 - 30 45 02 20 58 79 cc 62-85 e0 86 06 19 d3 bf   0E. Xy.b.......
+   000f - 53 d4 67 9f 03 73 d7 45-20 cf 56 10 c2 55 5b   S.g..s.E .V..U[
+   001e - 7b ec 61 d4 72 dc 02 21-00 83 aa 53 44 28 4d   {.a.r..!...SD(M
+   002d - 4c ef de 31 07 9c f9 71-bd 69 5d 6e c8 71 e9   L..1...q.i]n.q.
+   003c - a4 60 ec 2e 12 65 2b 77-a4 62 4d               .`...e+w.bM
+         unsignedAttrs:
+           <ABSENT>
+
+                         Figure 5: Signed Message
+
+A.2.  Short Signed Message
+
+   Figure 6 shows the message signed by Alice with no embedded
+   certificate, as used in the example in Section 10.2.
+
+ CMS_ContentInfo:
+   contentType: pkcs7-signedData (1.2.840.113549.1.7.2)
+   d.signedData:
+     version: 1
+     digestAlgorithms:
+         algorithm: sha256 (2.16.840.1.101.3.4.2.1)
+         parameter: <ABSENT>
+     encapContentInfo:
+       eContentType: pkcs7-data (1.2.840.113549.1.7.1)
+       eContent:
+   0000 - 43 6f 6e 74 65 6e 74 2d-54 79 70 65 3a 20 74   Content-Type: t
+   000f - 65 78 74 2f 70 6c 61 69-6e 0d 0a 0d 0a 57 61   ext/plain....Wa
+   001e - 74 73 6f 6e 2c 20 63 6f-6d 65 20 68 65 72 65   tson, come here
+   002d - 20 2d 20 49 20 77 61 6e-74 20 74 6f 20 73 65    - I want to se
+   003c - 65 20 79 6f 75 2e 0d 0a-                       e you...
+     certificates:
+       <ABSENT>
+     crls:
+       <ABSENT>
+     signerInfos:
+         version: 1
+         d.issuerAndSerialNumber:
+           issuer: O=example.com, CN=Alice
+           serialNumber: 13292724773353297200
+         digestAlgorithm:
+           algorithm: sha256 (2.16.840.1.101.3.4.2.1)
+           parameter: <ABSENT>
+         signedAttrs:
+             object: contentType (1.2.840.113549.1.9.3)
+             set:
+               OBJECT:pkcs7-data (1.2.840.113549.1.7.1)
+
+
+
+
+Campbell & Housley           Standards Track                   [Page 32]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+             object: signingTime (1.2.840.113549.1.9.5)
+             set:
+               UTCTIME:Jan 24 23:52:56 2019 GMT
+
+             object: messageDigest (1.2.840.113549.1.9.4)
+             set:
+               OCTET STRING:
+   0000 - ef 77 8f c9 40 d5 e6 dc-25 76 f4 7a 59   .w..@...%v.zY
+   000d - 9b 31 26 19 5a 9f 1a 22-7a da f3 5f a2   .1&.Z.."z.._.
+   001a - 2c 05 0d 8d 19 5a                        ,....Z
+         signatureAlgorithm:
+           algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
+           parameter: <ABSENT>
+         signature:
+   0000 - 30 44 02 20 1c 51 6e ed-9c 10 10 a2 87 e1 11   0D. .Qn........
+   000f - 6b af 76 1d f1 c4 e6 48-da ea 17 89 bc e2 8a   k.v....H.......
+   001e - 9d 8a f4 a4 ae f9 02 20-72 7f 5e 4b cc e2 0b   ....... r.^K...
+   002d - cf 3c af 07 c8 1c 11 64-f0 21 e7 70 e0 f6 a0   .<.....d.!.p...
+   003c - 96 2e 0a 7b 19 b7 42 ad-cb 34                  ...{..B..4
+         unsignedAttrs:
+           <ABSENT>
+
+           Figure 6: Signed Message without Embedded Certificate
+
+A.3.  Signed and Encrypted Message
+
+   The following sections show details for the message signed by Bob and
+   encrypted to Alice, as used in the examples in Sections 10.3
+   and 10.4.
+
+A.3.1.  Signed Message prior to Encryption
+
+ CMS_ContentInfo:
+   contentType: pkcs7-signedData (1.2.840.113549.1.7.2)
+   d.signedData:
+     version: 1
+     digestAlgorithms:
+         algorithm: sha256 (2.16.840.1.101.3.4.2.1)
+         parameter: <ABSENT>
+     encapContentInfo:
+       eContentType: pkcs7-data (1.2.840.113549.1.7.1)
+       eContent:
+   0000 - 43 6f 6e 74 65 6e 74 2d-54 79 70 65 3a 20 74   Content-Type: t
+   000f - 65 78 74 2f 70 6c 61 69-6e 0d 0a 0d 0a 57 61   ext/plain....Wa
+   001e - 74 73 6f 6e 2c 20 63 6f-6d 65 20 68 65 72 65   tson, come here
+   002d - 20 2d 20 49 20 77 61 6e-74 20 74 6f 20 73 65    - I want to se
+   003c - 65 20 79 6f 75 2e 0d 0a-                       e you...
+
+
+
+
+Campbell & Housley           Standards Track                   [Page 33]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+     certificates:
+       d.certificate:
+         cert_info:
+           version: 2
+           serialNumber: 11914627415941064473
+           signature:
+             algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
+             parameter: <ABSENT>
+           issuer: O=example.org, CN=Bob
+           validity:
+             notBefore: Dec 20 23:07:49 2017 GMT
+             notAfter: Dec 20 23:07:49 2018 GMT
+           subject: O=example.org, CN=Bob
+           key:
+             algor:
+               algorithm: id-ecPublicKey (1.2.840.10045.2.1)
+               parameter: OBJECT:prime256v1 (1.2.840.10045.3.1.7)
+             public_key:  (0 unused bits)
+   0000 - 04 86 4f ff fc 53 f1 a8-76 ca 69 b1 7e 27   ..O..S..v.i.~'
+   000e - 48 7a 07 9c 71 52 ae 1b-13 7e 39 3b af 1a   Hz..qR...~9;..
+   001c - ae bd 12 74 3c 7d 41 43-a2 fd 8a 37 0f 02   ...t<}AC...7..
+   002a - ba 9d 03 b7 30 1f 1d a6-4e 30 55 94 bb 6f   ....0...N0U..o
+   0038 - 95 cb 71 fa 48 b6 d0 a3-83                  ..q.H....
+           issuerUID: <ABSENT>
+           subjectUID: <ABSENT>
+           extensions:
+               object: X509v3 Subject Alternative Name (2.5.29.17)
+               critical: TRUE
+               value:
+   0000 - 30 15 86 13 73 69 70 3a-62 6f 62 40 65   0...sip:bob@e
+   000d - 78 61 6d 70 6c 65 2e 6f-72 67            xample.org
+         sig_alg:
+           algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
+           parameter: <ABSENT>
+         signature:  (0 unused bits)
+   0000 - 30 45 02 21 00 b2 24 8c-92 40 28 22 38 9e c9   0E.!..$..@("8..
+   000f - 25 7f 64 cc fd 10 6f ba-0b 96 c1 19 07 30 34   %.d...o......04
+   001e - d5 1b 10 2f 73 39 6c 02-20 15 8e b1 51 f0 85   .../s9l. ...Q..
+   002d - b9 bd 2e 04 cf 27 8f 0d-52 2e 6b b6 fe 4f 36   .....'..R.k..O6
+   003c - f7 4c 77 10 b1 5a 4f 47-9d e4 0d               .Lw..ZOG...
+     crls:
+       <ABSENT>
+     signerInfos:
+         version: 1
+         d.issuerAndSerialNumber:
+           issuer: O=example.org, CN=Bob
+           serialNumber: 11914627415941064473
+
+
+
+
+Campbell & Housley           Standards Track                   [Page 34]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+         digestAlgorithm:
+           algorithm: sha256 (2.16.840.1.101.3.4.2.1)
+           parameter: <ABSENT>
+         signedAttrs:
+             object: contentType (1.2.840.113549.1.9.3)
+             set:
+               OBJECT:pkcs7-data (1.2.840.113549.1.7.1)
+
+             object: signingTime (1.2.840.113549.1.9.5)
+             set:
+               UTCTIME:Jan 24 23:52:56 2019 GMT
+
+             object: messageDigest (1.2.840.113549.1.9.4)
+             set:
+               OCTET STRING:
+   0000 - ef 77 8f c9 40 d5 e6 dc-25 76 f4 7a 59   .w..@...%v.zY
+   000d - 9b 31 26 19 5a 9f 1a 22-7a da f3 5f a2   .1&.Z.."z.._.
+   001a - 2c 05 0d 8d 19 5a                        ,....Z
+         signatureAlgorithm:
+           algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
+           parameter: <ABSENT>
+         signature:
+   0000 - 30 45 02 21 00 f7 88 ed-44 6a b7 0f ff 2c 1f   0E.!....Dj...,.
+   000f - fa 4c 03 74 fd 08 77 fd-61 ee 91 7c 31 45 b3   .L.t..w.a..|1E.
+   001e - 89 a6 76 15 c7 46 fa 02-20 77 94 ad c5 7f 00   ..v..F.. w.....
+   002d - 61 c7 84 b9 61 23 cc 6e-54 bb 82 82 65 b6 d4   a...a#.nT...e..
+   003c - cc 12 99 76 a6 b1 fc 6d-bc 28 d6               ...v...m.(.
+         unsignedAttrs:
+           <ABSENT>
+
+            Figure 7: Message Signed by Bob prior to Encryption
+
+A.3.2.  Encrypted Message
+
+ CMS_ContentInfo:
+   contentType: pkcs7-authEnvelopedData (1.2.840.113549.1.9.16.1.23)
+   d.authEnvelopedData:
+     version: 0
+     originatorInfo: <ABSENT>
+     recipientInfos:
+       d.ktri:
+         version: <ABSENT>
+         d.issuerAndSerialNumber:
+           issuer: O=example.com, CN=Alice
+           serialNumber: 9508519069068149774
+         keyEncryptionAlgorithm:
+           algorithm: rsaEncryption (1.2.840.113549.1.1.1)
+           parameter: NULL
+
+
+
+Campbell & Housley           Standards Track                   [Page 35]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+         encryptedKey:
+   0000 - 75 9a 61 b4 dd f1 f1 af-24 66 80 05 63 5e 47   u.a.....$f..c^G
+   000f - 61 10 fa 27 23 c1 b9 e4-54 84 b6 d3 3e 83 87   a..'#...T...>..
+   001e - de 96 7d c5 e0 ca fb 35-57 1a 56 a1 97 5c b5   ..}....5W.V..\.
+   002d - 50 e7 be 31 c1 31 da 80-fb 73 10 24 84 5b ab   P..1.1...s.$.[.
+   003c - b8 d6 4c ac 26 04 04 24-d9 33 05 61 c8 43 99   ..L.&..$.3.a.C.
+   004b - 94 15 dd 64 4b 3c ad 95-07 2f 71 45 13 93 c9   ...dK<.../qE...
+   005a - 9f 28 2c 48 83 bd 0c cc-5d d5 4b 93 14 64 e0   .(,H....].K..d.
+   0069 - 0a 6e 55 e5 92 c5 1a 68-de 10 62 51 6e c7 d3   .nU....h..bQn..
+   0078 - ca 8e 76 4b b8 ac 78 9a-88 37 77 65 ef 8d c3   ..vK..x..7we...
+   0087 - 6c 0a 6e d3 ec ae 52 85-ca c6 a2 9d 50 59 44   l.n...R.....PYD
+   0096 - 57 19 a1 bd cf 90 6e 0f-f3 7e 2c 2e f0 f4 ec   W.....n..~,....
+   00a5 - 62 25 10 0c c0 62 e1 c7-48 96 3b bc 88 b8 e3   b%...b..H.;....
+   00b4 - df cf 71 40 73 72 9d d5-c7 58 3e 75 8a cf 3d   ..q@sr...X>u..=
+   00c3 - 18 6f 2f a4 17 be 22 c3-7c 9a 76 c6 b4 27 29   .o/...".|.v..')
+   00d2 - aa d2 7f 73 ae 44 ac 98-47 4d 1e eb 48 94 8c   ...s.D..GM..H..
+   00e1 - 12 a4 03 d0 b3 ce 08 a2-18 d6 af 45 69 24 89   ...........Ei$.
+   00f0 - 7c c5 c9 66 4f 6d fe b3-f1 81 41 15 8d fc 3b   |..fOm....A...;
+   00ff - 84 09 0a a6 03 80 aa 86-51 37 e1 69 9c 5c 81   ........Q7.i.\.
+   010e - 97 41 67 9d 7a 3c 90 ba-79 e6 d7 d5 c8 d8 9b   .Ag.z<..y......
+   011d - b5 4a 66 74 23 e4 3b 0b-7d 6f 78 c0 b4 ab 67   .Jft#.;.}ox...g
+   012c - bc 34 36 62 a6 35 fe 59-5f 11 49 c5 39 50 ca   .46b.5.Y_.I.9P.
+   013b - c2 e0 ba 31 8c 22 7e 6f-76 a8 d9 40 40 0f d3   ...1."~ov..@@..
+   014a - d3 ea 1c 8e ce a0 03 dc-ce 2f 1f b0 0f 5c ea   ........./...\.
+   0159 - 33 5d e1 30 3f cb f9 3d-8e 1c bf d6 82 f1 9b   3].0?..=.......
+   0168 - eb 62 4b ac d1 d7 b8 f5-80 f1 14 a1 3b 89 08   .bK.........;..
+   0177 - 94 fb 40 44 a5 da a7 64-b7 f8 c5 ff 92 94 94   ..@D...d.......
+   0186 - 52 b3 5a eb 96 39 b8 ad-63 c0 51 5c 95 cc c6   R.Z..9..c.Q\...
+   0195 - f8 23 c2 20 10 67 ea 22-62 41 3f ef 39 7d 48   .#. .g."bA?.9}H
+   01a4 - f7 b6 14 3f 84 2a e8 e1-a4 8c ad 3a e0 1a ba   ...?.*.....:...
+   01b3 - a3 cf 9e e7 e3 66 20 e0-5c ca 06 11 bf ac 00   .....f .\......
+   01c2 - ee f1 a4 98 f2 d2 59 b9-f0 f7 da 83 ef 6f 1b   ......Y......o.
+   01d1 - 06 1f 38 7c 2d c4 8c 8b-5d ba ca 86 23 08 f3   ..8|-...]...#..
+   01e0 - 2f 47 92 51 65 c9 e5 eb-b4 67 79 98 84 91 8d   /G.Qe....gy....
+   01ef - d6 97 b4 47 f4 c4 07 98-9b 88 9b 0c 2e 95 80   ...G...........
+   01fe - af 78                                          .x
+     authEncryptedContentInfo:
+       contentType: pkcs7-data (1.2.840.113549.1.7.1)
+       contentEncryptionAlgorithm:
+         algorithm: aes-128-gcm (2.16.840.1.101.3.4.1.6)
+         parameter:
+           aes-nonce:
+   0000 - 4d 87 57 22 2e ac 52 94-11 7f 0c 12            M.W"..R.....
+           aes-ICVlen: 16
+       encryptedContent:
+   0000 - fe 2f b3 de 0b f0 69 98-c3 9b f4 a9 52 fa bf   ./....i.....R..
+   000f - 8b 0f ee 3d 7e 2e 85 18-1a ec f1 a8 9e 1a 2e   ...=~..........
+   001e - de cd 94 04 88 56 12 df-c6 98 43 34 d8 60 2b   .....V....C4..+
+
+
+
+Campbell & Housley           Standards Track                   [Page 36]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+   002d - 77 49 b2 50 4e 45 f5 7c-3b 06 66 26 b0 fc 74   wI.PNE.|..f&..t
+   003c - 62 36 1e ec 26 7c 56 01-39 be 5c d2 86 a2 af   b6..&|V.9.\....
+   004b - 96 96 cf 51 85 22 78 e5-2c 38 18 ca b0 a6 8c   ...Q."x.,8.....
+   005a - 59 8d e4 fc e1 4a 33 38-84 e4 de 5d df 57 ed   Y....J38...].W.
+   0069 - d7 88 67 02 7a 31 e4 a7-c0 c0 29 91 44 c5 de   ..g.z1....).D..
+   0078 - 6b ae 39 69 9e 70 0e 05-7e b0 f0 da d7 3b 8b   k.9i.p..~......
+   0087 - 36 9f 42 eb 32 1b 41 53-87 81 d9 82 a1 1a 0b   6.B.2.AS.......
+   0096 - 39 43 ac 10 c9 7b 54 ee-b7 3b 38 ec 13 1a fc   9C...{T...8....
+   00a5 - 56 10 e3 73 48 72 74 d6-9c af a9 54 19 02 88   V..sHrt....T...
+   00b4 - 6c 64 f6 96 2d 42 eb 33-f9 04 1a 4a e1 1b 88   ld..-B.3...J...
+   00c3 - dc 69 58 d5 3d f5 0b 8b-b5 2a a3 5e 22 99 88   .iX.=....*.^"..
+   00d2 - 5d 0a ae 41 6b 86 f0 a8-8d 0e b7 a9 81 db b2   ]..Ak..........
+   00e1 - 83 e8 b9 4e 9d 50 bf 62-65 c2 34 8a 18 a1 69   ...N.P.be.4...i
+   00f0 - aa cb 5a 37 a5 29 bd a2-f9 cb 10 ef dd cf 14   ..Z7.).........
+   00ff - 23 10 95 d8 79 64 63 7b-d3 3f b1 3c 68 b4 cf   #...ydc{.?.<h..
+   010e - f9 a1 90 69 60 c1 ea 23-01 d3 25 b7 a1 5c 58   ...i...#..%..\X
+   011d - 29 f3 ea 03 8f 24 df 6b-23 18 03 77 d3 71 31   )....$.k#..w.q1
+   012c - f7 5d b1 8f 41 f9 d8 5b-65 3d fa 46 bf 26 17   .]..A..[e=.F.&.
+   013b - 12 63 26 cc f1 cb 83 34-57 75 23 52 c8 41 7a   .c&....4Wu#R.Az
+   014a - 09 44 84 d7 b6 4b cf 51-b2 6a 9b eb 3a 0e d4   .D...K.Q.j..:..
+   0159 - b9 ca f1 bd 23 c6 90 c6-54 f7 eb 9c e9 85 2e   ....#...T......
+   0168 - 2f 6d 06 8e ef 8b a3 3b-c6 c4 dd dc a7 ae f4   /m.............
+   0177 - d3 57 47 37 d7 c4 dc 1e-93 77 0d 8f 4f 22 de   .WG7.....w..O".
+   0186 - a6 1d 73 08 3c 32 c4 03-8c 1e b3 dd 33 83 a8   ..s.<2......3..
+   0195 - 9a 87 95 e2 41 c2 ed 7c-b6 80 75 8c 04 10 69   ....A..|..u...i
+   01a4 - 48 98 60 fc 9f 49 0e 85-23 60 72 54 8b 32 49   H....I..#.rT.2I
+   01b3 - 69 8f 99 95 3a cf 1e c6-58 b7 aa 85 e5 54 c4   i...:...X....T.
+   01c2 - 49 70 1a 6d 4b 03 9e d1-03 dc 45 8d f4 b2 9c   Ip.mK.....E....
+   01d1 - b0 4b 8c ed d5 40 c8 43-48 da 79 c1 86 56 d5   .K...@.CH.y..V.
+   01e0 - 18 8f 9f 3a 9e 4b 9b 84-0c 70 66 4b 90 29 6c   ...:.K...pfK.)l
+   01ef - 60 b7 ac 98 4e 91 8d 48-a0 9d bd df b2 81 fc   ....N..H.......
+   01fe - 86 25 10 db 59 d9 fa 9d-c9 3f 10 f9 c6 d7 be   .%..Y....?.....
+   020d - f7 29 31 d1 84 ca d7 ac-13 c1 a5 29 5f c8 9f   .)1........)_..
+   021c - e3 bb 7e b8 e0 20 85 a8-28 c5 a1 38 78 6e 60   ..~.....(..8xn.
+   022b - 7a de 4f 5e 8d 41 15 90-92 09 ba 87 8a 79 30   z.O^.A.......y0
+   023a - 5a 53 16 c2 22 29 e4 2b-88 6d 06 48 1c 84 73   ZS..").+.m.H..s
+   0249 - f9 d5 12 69 e2 af 63 41-bc e2 0f 76 8e 86 0d   ...i..cA...v...
+   0258 - 77 84 ed 46 15 0e 04 ff-50 cd 20 9c 5b 12 75   w..F....P...[.u
+   0267 - 11 36 9f e0 6b c4 aa 9a-72 d8 f1 fe 4f cf 08   .6..k...r...O..
+   0276 - 66 d6 64 b3 65 ff a8 6e-8c 1b 43 e7 a9 21 2a   f.d.e..n..C..!*
+   0285 - ec c1 6c a3 50 a2 8e fa-e2 5f ac 05 4d d9 34   ..l.P...._..M.4
+   0294 - bf e7 e5 fa 4f 75 3a a4-15 96 8c 7e be c4 39   ....Ou:....~..9
+   02a3 - e0 ac 02 70 b4 87 4a 06-8d 22 48 4c 09 d9 e8   ...p..J.."HL...
+   02b2 - ab e1 7f 13 72 b4 b2 f6-5f 11 48 e8 93 3e da   ....r..._.H..>.
+   02c1 - 92 e5 d1 77 45 64 96 3b-39 1c 3b bd 9f 1c 27   ...wEd..9......
+   02d0 - ff e3 6f 83 2e 05 15 5f-c3 9e e6 65 2f a7 b4   ..o...._...e/..
+   02df - 18 89 75 ec 5c 67 b3 2c-9f 21 3c 8a c6 b8 e1   ..u.\g.,.!<....
+   02ee - 32 a5 a7 c3 bf 74 f0 16-40 5c d8 c2 01 d1 05   2....t..@\.....
+
+
+
+Campbell & Housley           Standards Track                   [Page 37]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+   02fd - 21 93 e1 86 d4 43 58 de-38 8d 73 21 1b a2 f1   !....CX.8.s!...
+   030c - 79 2f 3c fe b9 bb de 72-11 d2 6f 56 ab 06 e1   y/<....r..oV...
+   031b - 1c cc 9c cd e2 b8 8c d8-37 37 73 ea fc 37 fd   ........77s..7.
+   032a - 85 b7 a7 a2 bc ae c7 52-e6 17 d6 e0 1c 02 b8   .......R.......
+   0339 - 6e 9d 9a 40 f3 20 46 2c-5d 66 f8 35 17 16 dc   n..@..F,]f.5...
+   0348 - d6 01 4b df 30 a6 0f 75-fc 06 31 c9 20 84 5e   ..K.0..u..1...^
+   0357 - d8 c0 ba d3 5d df 19 84-f2 24 1c d3 b5 29 dc   ....]....$...).
+   0366 - 10 28 84 5f 80 89 54 3d-f4 f1 44 1e de 36 b1   .(._..T=..D..6.
+   0375 - bf 31 af 5a fc 8c 2b 70-8d 50 b6 45 d4 e7 db   .1.Z..+p.P.E...
+   0384 - 88 64 8c 3e ef e1 47 65-15 8f b0 e8 d3 bb 53   .d.>..Ge......S
+   0393 - dd cb e2 6d 71 24 c6 e1-d9 92 f8 32 30 aa 95   ...mq$.....20..
+   03a2 - 33 76 ee 8c 68 10 95 68-e8 57 1f 0c 9b bd a4   3v..h..h.W.....
+   03b1 - 8f 4d f3 06 fe 74 7f 37-11 75 14 8f 31 83 27   .M...t.7.u..1..
+   03c0 - 67 cd 76 6c f0 7b 45 0c-bf 62 ca d2 a7 bd 71   g.vl.{E..b....q
+   03cf - f1 f8 82 33 f1 16 a1 a7-f3 ca f1 2f 34 bc f4   ...3......./4..
+   03de - 0d 21 e7 9f fc 98 27 22-1b 68 b0 80 ff 03 ad   .!.....".h.....
+   03ed - 78 2d 6d 6d 07 87 16 76-f7 98 94 3e 54 f1 3f   x-mm...v...>T.?
+   03fc - d7 5c 89 c0 b4 26 3b f1-0f 56 24 3f 9e 72 ef   .\...&...V$?.r.
+   040b - 3b 38 99 a5 39 d9 a3 ac-5b e2 b6 94 00 a3 cf   .8..9...[......
+   041a - 8d 19 6c 5c ed 69 7b 2e-d8 03 b9 87 a5 ee 85   ..l\.i{........
+   0429 - c5 09 5b 48 da 7a 5b 03-b4 7e 2b 9f e4 cd 4b   ..[H.z[..~+...K
+   0438 - c3 09 8e 86 4e 0c e7 d4-67 da 99 cd 7f 3a 9e   ....N...g....:.
+   0447 - 94 7b 5e ea 77 f7 a6 be-16 c8 c7 e9 e0 de cc   .{^.w..........
+   0456 - 1f f1 32 55 9c 23 43 21-7b 9c 29 50 38 6e 85   ..2U.#C!{.)P8n.
+   0465 - d2 94 21 21 08 6c df a1-96 58 19 5b e6 d7 f8   ..!!.l...X.[...
+   0474 - 6b ca 98 81 b6 95 08 29-64 f1 2e 7c f8 01 02   k......)d..|...
+   0483 - 5d 67 92 c6 88 24 09 41-4d 70 33 21 ec 83 ab   ]g...$.AMp3!...
+   0492 - d6 98 d6 89 56 11 87 13-a0 ff 12 72 ac bc 9a   ....V......r...
+   04a1 - 6d 14 89 00 c7 4c 16 92-1d f9 b3 8f 29 ec 46   m....L......).F
+   04b0 - d4 f1 00 60 ff fe 5e 36-bb ba ca f2 d1 ba d7   ......^6.......
+   04bf - dd 05 7e d3 e3 0e bc d6-90 83 f9 d3 a2 a2 6e   ..~...........n
+   04ce - f9 0b 75 1d 6a 1a df a0-59 0d b1 9d a1 07 cf   ..u.j...Y......
+   04dd - 3e a8 db                                       >..
+     authAttrs:
+       <EMPTY>
+     mac:
+   0000 - f6 ff c6 e1 ae f1 9c d2-3d 98 5a 92 19 76 35   ........=.Z..v5
+   000f - 2d                                             -
+     unauthAttrs:
+       <EMPTY>
+
+               Figure 8: Message Encrypted by Bob for Alice
+
+
+
+
+
+
+
+
+
+Campbell & Housley           Standards Track                   [Page 38]
+
+RFC 8591                S/MIME for SIP Messaging              April 2019
+
+
+Authors' Addresses
+
+   Ben Campbell
+   Standard Velocity, LLC
+
+   Email: ben@nostrum.com
+
+
+   Russ Housley
+   Vigil Security, LLC
+
+   Email: housley@vigilsec.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Campbell & Housley           Standards Track                   [Page 39]
+
-- 
cgit v1.2.3