SIP-based Messaging with S/MIME

SIP-based Messaging with S/MIME Standard Velocity

204 Touchdown Dr Irving, TX 75063 US ben@nostrum.com

Vigil Security

516 Dranesville Rd Herndon, VA 20170 US housley@vigilsec.com

Applications and Real-Time Internet-Draft 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 RFC 3261, RFC 3428, and RFC 4975.

Several Mobile Messaging systems use the Session Initiation Protocol (SIP) , typically as some combination of the SIP MESSAGE method and the Message Session Relay Protocol (MSRP) . 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 uses the SIP MESSAGE Method for short “pager mode” messages and MSRP for large messages and for sessions of messages. The GSM Association (GMSA) rich communication services (RCS) uses CPM for messaging . 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 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 . However at the time of this writing, S/MIME is not in common use for SIP- and MSRP-based messaging services. This document updates and clarifies RFC 3261, RFC 3428, and RFC 4975 in an attempt to make S/MIME for SIP and MSRP easier to implement and deploy in an interoperable fashion. This document updates RFC 3261, RFC 3428, and RFC 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 imbedded certificates in some situations. Finally, it updates RFC 3261, RFC 3428, and RFC 4975 to clarify error reporting requirements for certain situations.

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 when, and only when, they appear in all capitals, as shown here.

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) . Likewise, other end-to-end protection formats exist, such as JSON Web Signatures and JSON Web Encryption . 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) offer/answer mechanism 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. , , and already describe the use of S/MIME. 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 application. 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 system would require considerable work around user enrollment, certificate and key generation and management, multiparty 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. Cryptographic algorithm requirements in this document are intended to supplement those already specified for SIP and MSRP.

The Cryptographic Message Syntax (CMS) 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 . The CMS values are generated using ASN.1 , using the Basic Encoding Rules (BER) and Distinguished Encoding Rules (DER) . The S/MIME Message Specification 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 is used to encrypt an encapsulated body part.

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 Delivery notification requests into messages (see ). The application/pkcs7-mime format is also more compact, which can be important for messaging applications, especially when using the SIP MESSAGE method (see ). 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 (UA) SHOULD follow the conventions specified in 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 for the application/pkcs7-mime media type with smime-type=signed-data. Sending and receiving UAs MUST support the SHA-256 message digest algorithm . For convenience, the SHA-256 algorithm identifier is repeated here:

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 . Sending and receiving UAs SHOULD support the Edwards-curve Digital Signature Algorithm (EdDSA) with curve25519 (Ed25519) . 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:

When generating an encrypted message, sending UAs MUST follow the conventions specified in 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 for the application/pkcs7-mime media type with smime- type=auth-enveloped-data. Sending and receiving UAs MUST support the AES-128-GCM for content encryption . For convenience, the AES-128-GCM algorithm identifier is repeated here:

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 . For convenience, the AES-128-WRAP algorithm identifier is repeated here:

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 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 . If sending and receiving UAs support key agreement, then they SHOULD support the Elliptic Curve Diffie-Hellman (ECDH) algorithm using curve25519 (X25519) . For convenience, the identifers for the ECDH algorithm using the ANSI- X9.63-KDF with SHA-256 algorithm and for the X25519 algorithm are repeated here:

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.

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

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 , 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.

When validating a certificate, 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 . Sending and receiving UAs MAY support other digital signature algorithms for certificate validation.

SIP and MSRP UAs are always capable of receiving binary data. Inner S/MIME entities do not require base64 encoding . Both SIP and MSRP provide 8-bit safe transport channels; base64 encoding is not generally needed for the outer S/MIME entities. 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.

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 are 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 .) UAs can also advertise or discover S/MIME using out-of-band mechanisms. Such mechanisms are beyond the scope of this document.

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

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 via SIP MESSAGE should be kept as small as possible. Messages that will not fit within the limit can be sent using MSRP. Section 23.2 of says that a SignedData message must contain a certificate to be used to validate the signature. In order to reduce the message size, this document updates that 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 already has the certificate in its keychain, or has some other method of accessing the certificate.

SIP user agents (UA) 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 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 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. UAs might be able to use the user agent capabilities framework 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.

Section 23.2 of 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 makes no such assertion. This document updates section 11.3 to add the statement that a UAC that receives a SIP MESSAGE request with an unsupported media type MUST return a 415 “Unsupported Media Type” response. Section 23.2 of 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 User Agent Server (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 the message was encrypted to the wrong certificate. However, it MAY return a 200-class response if decryption is deferred.

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.

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. The sending user agent may break a message into chunks, which the receiving user agent will reassemble to form the complete message. Intermediaries such as MSRP Relays 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. MRSP requires the sending user agent to scan data sent in a specific chunk to be sent ensure that the end-line does not accidentally occur as part of the sent data. This scanning occurs on a chunk rather than a whole message, consequently it must occur after the sender applies any S/MIME operations.

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 operation, so that each fragment appears as a distinct S/MIME separate message in MSRP. Such mechanisms are beyond the scope for this document.

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 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 . 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 .) 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.

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 , 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.

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 user agent 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.

The Common Profile for Instant Messaging (CPIM) 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 Common Profile for Instant Messages Message Format 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, Instant Message Delivery Notifications (IMDN) and MSRP Multi-party Chat 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- and RCS-based services include application servers that may need to insert time stamps 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 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 validate signatures and decrypt enveloped data both when those operations are applied to the entire CPIM body, and 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.

The Instant Message Delivery Notification (IMDN) mechanism 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 IMDN. IMDN 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, IMDN 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 .)

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 clear text 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”. shows the detailed content of each S/MIME body.

shows a message signed by Alice. This body uses the “application/pcks7-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.

shows the same message from Alice without the embedded certificate. The shorter total message length may be more manageable.

shows a signed and encrypted message from Bob to Alice sent via MSRP.

shows the same message as in except that the message is broken into two chunks. The S/MIME operations were performed prior to breaking the message into chunks.

This document makes no requests of the IANA.

The security considerations from S/MIME and elliptic curves in CMS apply. The S/MIME related security considerations from SIP , SIP MESSAGE , and MSRP apply. The security considerations from algorithms recommended in this document also apply, see , , , , , , , and . 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 apply. However, other validations methods may be possible; for example sending a signed fingerprint for the end-entity in SDP. The relationship of this work and the techniques discussed in and 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 sender identity from SIP AoRs in other header fields, for example, P-Asserted-Identity . 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 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 intermedies. However, neither provide 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 .) 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 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 14.5 of 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 . 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.

&RFC2119; &RFC8174; &RFC3261; &RFC3264; &RFC3428; &RFC3565; &RFC3853; &RFC4566; &RFC4975; &RFC5084; &RFC5280; &RFC5480; &RFC5652; &I-D.ietf-lamps-rfc5750-bis; &I-D.ietf-lamps-rfc5751-bis; &RFC5753; &RFC5754; &RFC8418; &RFC8419; Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation 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 &RFC3325; &RFC3840; &RFC3860; &RFC3862; &RFC4648; &RFC4976; &RFC5438; &RFC6121; &RFC7515; &RFC7516; &RFC7701; &RFC7748; &RFC8032; &RFC8224; &I-D.ietf-sipbrandy-rtpsec; OMA Converged IP Messaging System Description, Candidate Version 2.2 Open Mobile Alliance RCS Universal Profile Service Definition Document, Version 2.0 GSMA Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels

The following section shows the detailed content of the S/MIME bodies used in .

shows the details of the message signed by Alice used in the example in .

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: 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...{.. issuerUID: subjectUID: 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: 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. 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: 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: 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: ]]>

shows the message signed by Alice with no imbedded certificate, as used in the example in .

The following sections show details for the message signed by Bob and encrypted to Alice, as used in the examples in and .

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: 11914627415941064473 signature: algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) parameter: 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: subjectUID: 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: 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: signerInfos: version: 1 d.issuerAndSerialNumber: issuer: O=example.org, CN=Bob serialNumber: 11914627415941064473 digestAlgorithm: algorithm: sha256 (2.16.840.1.101.3.4.2.1) parameter: 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: 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: ]]>

recipientInfos: d.ktri: version: d.issuerAndSerialNumber: issuer: O=example.com, CN=Alice serialNumber: 9508519069068149774 keyEncryptionAlgorithm: algorithm: rsaEncryption (1.2.840.113549.1.1.1) parameter: NULL 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..+ 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{.?.. 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..@\..... 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: mac: 0000 - f6 ff c6 e1 ae f1 9c d2-3d 98 5a 92 19 76 35 ........=.Z..v5 000f - 2d - unauthAttrs: ]]>