idnits 2.17.00 (12 Aug 2021) /tmp/idnits50273/draft-campbell-sip-messaging-smime-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4975, but the abstract doesn't seem to directly say this. It does mention RFC4975 though, so this could be OK. -- The draft header indicates that this document updates RFC3428, but the abstract doesn't seem to directly say this. It does mention RFC3428 though, so this could be OK. -- The draft header indicates that this document updates RFC3261, but the abstract doesn't seem to directly say this. It does mention RFC3261 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1564 has weird spacing: '...e 08 fa c......' (Using the creation date from RFC3261, updated by this document, for RFC5378 checks: 2000-07-17) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 18, 2018) is 1311 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5750 (Obsoleted by RFC 8550) ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) ** Downref: Normative reference to an Informational RFC: RFC 5753 -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' == Outdated reference: draft-ietf-sipbrandy-rtpsec has been published as RFC 8862 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Campbell 3 Internet-Draft Standard Velocity 4 Updates: 3261, 3428, 4975 (if approved) R. Housley 5 Intended status: Standards Track Vigil Security 6 Expires: April 21, 2019 October 18, 2018 8 Securing Session Initiation Protocol (SIP) based Messaging with S/MIME 9 draft-campbell-sip-messaging-smime-04 11 Abstract 13 Mobile messaging applications used with the Session Initiation 14 Protocol (SIP) commonly use some combination of the SIP MESSAGE 15 method and the Message Session Relay Protocol (MSRP). While these 16 provide mechanisms for hop-by-hop security, neither natively provides 17 end-to-end protection. This document offers guidance on how to 18 provide end-to-end authentication, integrity protection, and 19 confidentiality using the Secure/Multipurpose Internet Mail 20 Extensions (S/MIME). It updates and provides clarifications for RFC 21 3261, RFC 3428, and RFC 4975. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 21, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Problem Statement and Scope . . . . . . . . . . . . . . . . . 4 60 4. Applicability of S/MIME . . . . . . . . . . . . . . . . . . . 5 61 4.1. Signed Messages . . . . . . . . . . . . . . . . . . . . . 5 62 4.2. Encrypted Messages . . . . . . . . . . . . . . . . . . . 6 63 4.3. Signed and Encrypted Messages . . . . . . . . . . . . . . 7 64 4.4. Certificate Handling . . . . . . . . . . . . . . . . . . 8 65 4.4.1. Subject Alternative Name . . . . . . . . . . . . . . 8 66 4.4.2. Certificate Validation . . . . . . . . . . . . . . . 8 67 5. Transfer Encoding . . . . . . . . . . . . . . . . . . . . . . 8 68 6. User Agent Capabilities . . . . . . . . . . . . . . . . . . . 8 69 7. Using S/MIME with the SIP MESSAGE Method . . . . . . . . . . 9 70 7.1. Size Limit . . . . . . . . . . . . . . . . . . . . . . . 10 71 7.2. User Agent Capabilities . . . . . . . . . . . . . . . . . 10 72 7.3. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 10 73 8. Using S/MIME with MSRP . . . . . . . . . . . . . . . . . . . 11 74 8.1. Chunking . . . . . . . . . . . . . . . . . . . . . . . . 11 75 8.2. Streamed Data . . . . . . . . . . . . . . . . . . . . . . 12 76 8.3. Indicating support for S/MIME . . . . . . . . . . . . . . 12 77 8.4. MSRP URIs . . . . . . . . . . . . . . . . . . . . . . . . 13 78 8.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 13 79 9. S/MIME Interaction with other SIP Messaging Features . . . . 13 80 9.1. Common Profile for Instant Messaging . . . . . . . . . . 13 81 9.2. Instant Message Delivery Notifications . . . . . . . . . 14 82 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 10.1. Signed Message in SIP Including the Sender's Certificate 15 84 10.2. Signed Message in SIP with No Certificate . . . . . . . 17 85 10.3. MSRP Signed and Encrypted Message in a Single Chunk . . 17 86 10.4. MSRP Signed and Encrypted Message sent in Multiple 87 Chunks . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 89 12. Security Considerations . . . . . . . . . . . . . . . . . . . 21 90 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 13.1. Normative References . . . . . . . . . . . . . . . . . . 22 92 13.2. Informative References . . . . . . . . . . . . . . . . . 24 93 Appendix A. Message Details . . . . . . . . . . . . . . . . . . 26 94 A.1. Signed Message . . . . . . . . . . . . . . . . . . . . . 26 95 A.2. Short Signed Message . . . . . . . . . . . . . . . . . . 29 96 A.3. Signed and Encrypted Message . . . . . . . . . . . . . . 30 97 A.3.1. Signed Message Prior to Encryption . . . . . . . . . 30 98 A.3.2. Encrypted Message . . . . . . . . . . . . . . . . . . 33 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 101 1. Introduction 103 Several Mobile Messaging systems use the Session Initiation Protocol 104 (SIP) [RFC3261], typically as some combination of the SIP MESSAGE 105 method [RFC3428] and the Message Session Relay Protocol (MSRP) 106 [RFC4975]. For example, Voice over LTE (VoLTE) uses the SIP MESSAGE 107 method to send Short Message Service (SMS) messages. The Open Mobile 108 Alliance (OMA) Converged IP Messaging (CPM) [CPM], [RCS] system uses 109 the SIP Message Method for short "pager mode" messages and MSRP for 110 large messages and for sessions of messages. The GSM Association 111 (GMSA) rich communication services (RCS) uses CPM for messaging. 113 At the same time, organizations increasingly depend on mobile 114 messaging systems to send notifications to their customers. Many of 115 these notifications are security sensitive. For example, such 116 notifications are commonly used for notice of financial transactions, 117 notice of login or password change attempts, and sending of two- 118 factor authentication codes. 120 Both SIP and MSRP can be used to transport any content using 121 Multipurpose Internet Mail Extensions (MIME) formats. The SIP 122 MESSAGE method is typically limited to short messages (under 1300 123 octets for the MESSAGE request). MSRP can carry arbitrarily large 124 messages, and can break large messages into chunks. 126 While both SIP and MSRP provide mechanisms for hop-by-hop security, 127 neither provides native end-to-end protection. Instead, they depend 128 on S/MIME [RFC5750][RFC5751]. However at the time of this writing, 129 S/MIME is not in common use for SIP and MSRP based messaging 130 services. This document updates and clarifies RFC 3261, RFC 3428, 131 and RFC 4975 in an attempt to make the S/MIME for SIP and MSRP easier 132 to implement and deploy in an interoperable fashion. 134 This document updates RFC 3261, RFC 3428, and RFC 4975 to update the 135 cryptographic algorithm recommendations and the handling of S/MIME 136 data objects. It updates RFC 3261 to allow S/MIME signed messages to 137 be sent without imbedded certificates in some situations. Finally, 138 it updates RFC 3261, RFC 3428, and RFC 4975 to clarify error 139 reporting requirements for certain situations. 141 2. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in BCP 146 14 [RFC2119][RFC8174] when, and only when, they appear in all 147 capitals, as shown here. 149 3. Problem Statement and Scope 151 This document discusses the use of S/MIME with SIP-based messaging. 152 Other standardized messaging protocols exist, such as the Extensible 153 Messaging and Presence Protocol (XMPP) [RFC6121]. Likewise, other 154 end-to-end protection formats exist, such as JSON Web Signatures 155 [RFC7515] and JSON Web Encryption [RFC7516]. 157 This document focuses on SIP-based messaging because its use is 158 becoming more common in mobile environments. It focuses on S/MIME 159 since several mobile operating systems already have S/MIME libraries 160 installed. While there may also be value in specifying end-to-end 161 security for other messaging and security mechanisms, it is out of 162 scope for this document. 164 MSRP sessions are negotiated using the Session Description Protocol 165 (SDP) [RFC4566] offer/answer mechanism [RFC3264] or similar 166 mechanisms. This document assumes that SIP is used for the offer/ 167 answer exchange. However, the techniques should be adaptable to 168 other signaling protocols. 170 [RFC3261], [RFC3428], and [RFC4975] already describe the use of 171 S/MIME. [RFC3853] updates SIP to support the Advanced Encryption 172 Standard (AES). In aggregate that guidance is incomplete, contains 173 inconsistencies, and is still out of date in terms of supported and 174 recommended algorithms. 176 The guidance in RFC 3261 is based on an implicit assumption that 177 S/MIME is being used to secure signaling applications. That advice 178 is not entirely appropriate for messaging application. For example, 179 it assumes that message decryption always happens before the SIP 180 transaction completes. 182 This document offers normative updates and clarifications to the use 183 of S/MIME with the SIP MESSAGE method and MSRP. It does not attempt 184 to define a complete secure messaging system. Such system would 185 require considerable work around user enrollment, certificate and key 186 generation and management, multiparty chats, device management, etc. 187 While nothing herein should preclude those efforts, they are out of 188 scope for this document. 190 This document primarily covers the sending of single messages, for 191 example "pager-mode messages" sent using the SIP MESSAGE method and 192 "large messages" sent in MSRP. Techniques to use a common signing or 193 encryption key across a session of messages are out of scope for this 194 document. 196 Cryptographic algorithm requirements in this document are intended to 197 supplement those already specified for SIP and MSRP. 199 4. Applicability of S/MIME 201 The Cryptographic Message Syntax (CMS) [RFC5652] is an encapsulation 202 syntax that is used to digitally sign, digest, authenticate, or 203 encrypt arbitrary message content. The CMS supports a variety of 204 architectures for certificate-based key management, especially the 205 one defined by the IETF PKIX (Public Key Infrastructure using X.509) 206 working group [RFC5280]. The CMS values are generated using ASN.1 207 [X680], using the Basic Encoding Rules (BER) and Distinguished 208 Encoding Rules (DER) [X690]. 210 The S/MIME Message Specification version 3.2 [RFC5751] defines MIME 211 body parts based on the CMS. In this document, the application/ 212 pkcs7-mime media type is used to digitally sign an encapsulated body 213 part, and it is also is used to encrypt an encapsulated body part. 215 4.1. Signed Messages 217 While both SIP and MSRP require support for the multipart/signed 218 format, this document recommends the use of application/pkcs7-mime 219 for most signed messages. Experience with the use of S/MIME in 220 electronic mail has shown that multipart/signed bodies are at greater 221 risk of "helpful" tampering by intermediaries, a common cause of 222 signature validation failure. This risk is also present for 223 messaging applications; for example, intermediaries might insert 224 Instant Message Delivery notification requests into messages (see 225 Section 9.2). The application/pkcs7-mime format is also more 226 compact, which can be important for messaging applications, 227 especially when using the SIP MESSAGE method (see Section 7.1). The 228 use of multipart/signed may still make sense if the message needs to 229 be readable by receiving agents that do not support S/MIME. 231 When generating a signed message, sending user agents (UA) SHOULD 232 follow the conventions specified in [RFC5751] for the application/ 233 pkcs7-mime media type with smime-type=signed-data. When validating a 234 signed message, receiving UAs MUST follow the conventions specified 235 in [RFC5751] for the application/pkcs7-mime media type with smime- 236 type=signed-data. 238 Sending and receiving UAs MUST support the SHA-256 message digest 239 algorithm [RFC5754]. For convenience, the SHA-256 algorithm 240 identifier is repeated here: 242 id-sha256 OBJECT IDENTIFIER ::= { 243 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 244 csor(3) nistalgorithm(4) hashalgs(2) 1 } 246 Sending and receiving UAs MAY support other message digest 247 algorithms. 249 Sending and receiving UAs MUST support the Elliptic Curve Digital 250 Signature Algorithm (ECDSA) using the NIST P256 elliptic curve and 251 the SHA-256 message digest algorithm [RFC5480][RFC5753]. Sending and 252 receiving UAs SHOULD support the Edwards-curve Digital Signature 253 Algorithm (EdDSA) with curve25519 (Ed25519) [RFC8032][RFC8419]. For 254 convenience, the ECDSA with SHA-256 algorithm identifier, the object 255 identifier for the well-known NIST P256 elliptic curve, and the 256 Ed25519 algorithm identifier are repeated here: 258 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { 259 iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 260 ecdsa-with-SHA2(3) 2 } 262 -- Note: the NIST P256 elliptic curve is also known as secp256r1. 264 secp256r1 OBJECT IDENTIFIER ::= { 265 iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3) 266 prime(1) 7 } 268 id-Ed25519 OBJECT IDENTIFIER ::= { 1 3 101 112 } 270 4.2. Encrypted Messages 272 When generating an encrypted message, sending UAs MUST follow the 273 conventions specified in [RFC5751] for the application/pkcs7-mime 274 media type with smime-type=enveloped-data. When decrypting a 275 received message, receiving UAs MUST follow the conventions specified 276 in [RFC5751] for the application/pkcs7-mime media type with smime- 277 type=enveloped-data. 279 Sending and receiving UAs MUST support the AES-128-CBC for content 280 encryption [RFC3565]. For convenience, the AES-128-CBC algorithm 281 identifier is repeated here: 283 id-aes128-CBC OBJECT IDENTIFIER ::= { 284 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 285 csor(3) nistAlgorithm(4) aes(1) 2 } 287 Sending and receiving UAs MAY support other content encryption 288 algorithms. 290 Sending and receiving UAs MUST support the AES-128-WRAP algorithm for 291 encryption of one AES key with another AES key [RFC3565]. For 292 convenience, the AES-128-WRAP algorithm identifier is repeated here: 294 id-aes128-wrap OBJECT IDENTIFIER ::= { 295 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 296 csor(3) nistAlgorithm(4) aes(1) 5 } 298 Sending and receiving UAs MAY support other key encryption 299 algorithms. 301 Symmetric key-encryption keys can be distributed before messages are 302 sent. If sending and receiving UAs support previously distributed 303 key-encryption keys, then they MUST assign a KEK identifier [RFC5652] 304 to the previously distributed symmetric key. 306 Alternatively, a key agreement algorithm can be used to establish a 307 single-use key-encryption key. If sending and receiving UAs support 308 key agreement, then they MUST support the Elliptic Curve Diffie- 309 Hellman (ECDH) algorithm using the NIST P256 elliptic curve and the 310 ANSI-X9.63-KDF key derivation function with the SHA-256 message 311 digest algorithm [RFC5753]. If sending and receiving UAs support key 312 agreement, then they SHOULD support the Elliptic Curve Diffie-Hellman 313 (ECDH) algorithm using curve25519 (X25519) [RFC7748][RFC8418]. For 314 convenience, the identifers for the ECDH algorithm using the ANSI- 315 X9.63-KDF with SHA-256 algorithm and for the X25519 algorithm are 316 repeated here: 318 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 319 iso(1) identified-organization(3) certicom(132) 320 schemes(1) 11 1 } 322 id-X25519 OBJECT IDENTIFIER ::= { 1 3 101 110 } 324 4.3. Signed and Encrypted Messages 326 RFC 3261 section 23.2 says that when a User Agent Client (UAC) sends 327 signed and encrypted data, it should send an EnvelopedData object 328 encapsulated within a SignedData message. That essentially says that 329 one should encrypt first, then sign. This document updates RFC 3261 330 to say that, when sending signed and encrypted user content in a SIP 331 MESSAGE request, the sending UAs MUST sign the message first, and 332 then encrypt it. That is, it must send the SignedData object inside 333 an EnvelopedData object. 335 4.4. Certificate Handling 337 Sending and receiving UAs MUST follow the S/MIME certificate handling 338 procedures [RFC5750], with a few exceptions detailed below. 340 4.4.1. Subject Alternative Name 342 In both SIP and MSRP, the identity of the sender of a message is 343 typically expressed as a SIP URI. 345 The subject alternative name extension is used as the preferred means 346 to convey the SIP URI of the subject of a certificate. Any SIP URI 347 present MUST be encoded using the uniformResourceIdentifier CHOICE of 348 the GeneralName type as described in [RFC5280], Section 4.2.1.6. 349 Since the SubjectAltName type is a SEQUENCE OF GeneralName, multiple 350 URIs MAY be present. 352 Other methods of identifying a certificate subject MAY be used. 354 4.4.2. Certificate Validation 356 When validating a certificate, receiving UAs MUST support the 357 Elliptic Curve Digital Signature Algorithm (ECDSA) using the NIST 358 P256 elliptic curve and the SHA-256 message digest algorithm 359 [RFC5480]. 361 Sending and receiving UAs MAY support other digital signature 362 algorithms for certificate validation. 364 5. Transfer Encoding 366 SIP and MSRP UAs are always capable of receiving binary data. Inner 367 S/MIME entities do not require base64 encoding [RFC4648]. 369 Both SIP and MSRP provide 8-bit safe transport channels; base64 370 encoding is not generally needed for the outer S/MIME entities. 371 However, if there is a chance a message might cross a 7-bit transport 372 (for example, gateways that convert to a 7-bit transport for 373 intermediate transfer), base64 encoding may be needed for the outer 374 entity. 376 6. User Agent Capabilities 378 Messaging UAs may implement a subset of S/MIME capabilities. Even 379 when implemented, some features may not be available due to 380 configuration. For example, UAs that do not have user certificates 381 cannot sign messages on behalf of the user or decrypt encrypted 382 messages sent to the user. At a minimum, a UA that supports S/MIME 383 MUST be able to validate a signed message. 385 End-user certificates have long been a barrier to large-scale S/MIME 386 deployment. But since UAs can validate signatures even without local 387 certificates, the use case of organizations sending secure 388 notifications to their users becomes a sort of "low hanging fruit". 390 SIP and MSRP UAs advertise their level of support for S/MIME by 391 indicating their capability to receive the "application/pkcs7-mime" 392 media type. 394 The fact that a UA indicates support for the "multipart/signed" media 395 type does not necessarily imply support for S/MIME. The UA might 396 just be able to display clear-signed content without validating the 397 signature. UAs that wish to indicate the ability to validate 398 signatures for clear-signed messages MUST also indicate support for 399 "application/pkcs7-signature". 401 A UA can indicate that it can receive all smime-types by advertising 402 "application/pkcs7-mime" with no parameters. If a UA does not accept 403 all smime-types, it advertises the media type with the appropriate 404 parameters. If more than one are supported, the UA includes a 405 separate instance of the media-type string, appropriately 406 parameterized, for each. 408 For example, a UA that can only receive signed-data would advertise 409 "application/pkcs7-mime; smime-type=signed-data". 411 SIP signaling can fork to multiple destinations for a given Address 412 of Record (AoR). A user might have multiple UAs with different 413 capabilities; the capabilities remembered from an interaction with 414 one such UA might not apply to another. 416 UAs can also advertise or discover S/MIME using out-of-band 417 mechanisms. Such mechanisms are beyond the scope of this document. 419 7. Using S/MIME with the SIP MESSAGE Method 421 The use of S/MIME with the SIP MESSAGE method is described in section 422 11.3 of [RFC3428], and for SIP in general in section 23 of [RFC3261]. 423 This section and its child sections offer clarifications for the use 424 of S/MIME with the SIP MESSAGE method, along with related updates to 425 RFC 3261 and RFC 3428. 427 7.1. Size Limit 429 SIP MESSAGE requests are typically limited to 1300 octets. That 430 limit applies to the entire message, including both SIP header fields 431 and the message content. This is due to the potential for 432 fragmentation of larger requests sent over UDP. In general, it is 433 hard to be sure that no proxy or other intermediary will forward a 434 SIP request over UDP somewhere along the path. Therefore, S/MIME 435 messages sent via SIP MESSAGE should be kept as small as possible. 436 Messages that will not fit within the limit can be sent using MSRP. 438 Section 23.2 of [RFC3261] says that a SignedData message must contain 439 a certificate to be used to validate the signature. In order to 440 reduce the message size, this document updates that to say that a 441 SignedData message sent in a SIP MESSAGE request SHOULD contain the 442 certificate, but MAY omit it if the sender has reason to believe that 443 the recipient already has the certificate in its keychain, or has 444 some other method of accessing the certificate. 446 7.2. User Agent Capabilities 448 SIP user agents (UA) can indicate support for S/MIME by including the 449 appropriate media type or types in the SIP Accept header field in a 450 response to an OPTIONS request, or in a 415 response to a SIP request 451 that contained an unsupported media type in the body. 453 UAs might be able to use the user agent capabilities framework 454 [RFC3840] to indicate support. However doing so would require the 455 registration of one or more media feature tags with IANA. 457 UAs MAY use other out-of-band methods to indicate their level of 458 support for S/MIME. 460 7.3. Failure Cases 462 Section 23.2 of [RFC3261] requires that the recipient of a SIP 463 request that includes a body part of an unsupported media type and a 464 Content-Disposition header "handling" parameter of "required" return 465 a 415 "Unsupported Media Type" response. Given that SIP MESSAGE 466 exists for no reason other than to deliver content in the body, it is 467 reasonable to treat the top-level body part as always required. 468 However [RFC3428] makes no such assertion. This document updates 469 section 11.3 [RFC3428] to add the statement that a UAC that receives 470 a SIP MESSAGE request with an unsupported media type MUST return a 471 415 "Unsupported Media Type" response. 473 Section 23.2 of [RFC3261] says that if a recipient receives an S/MIME 474 body encrypted to the wrong certificate, it MUST return a SIP 493 475 (Undecipherable) response, and SHOULD send a valid certificate in 476 that response. This is not always possible in practice for SIP 477 MESSAGE requests. The User Agent Server (UAS) may choose not to 478 decrypt a message until the user is ready to read it. Messages may 479 be delivered to a message store, or sent via a store-and-forward 480 service. This document updates RFC 3261 to say that the UAS SHOULD 481 return a SIP 493 response if it immediately attempts to decrypt the 482 message and determines the message was encrypted to the wrong 483 certificate. However, it MAY return a 2XX class response if 484 decryption is deferred. 486 8. Using S/MIME with MSRP 488 MSRP has features that interact with the use of S/MIME. In 489 particular, the ability to send messages in chunks, the ability to 490 send messages of unknown size, and the use of SDP to indicate media- 491 type support create considerations for the use of S/MIME. 493 8.1. Chunking 495 MSRP allows a message to be broken into "chunks" for transmission. 496 In this context, the term "message" refers to an entire message that 497 one user might send to another. A chunk is a fragment of that 498 message sent in a single MSRP SEND request. All of the chunks that 499 make up a particular message share the same Message-ID value. 501 The sending user agent may break a message into chunks, which the 502 receiving user agent will reassemble to form the complete message. 503 Intermediaries such as MSRP Relays [RFC4976] might break chunks into 504 smaller chunks, or might reassemble chunks into larger ones; 505 therefore the message received by the recipient may be broken into a 506 different number of chunks than were sent by the recipient. 507 Intermediaries might also cause chunks to be received in a different 508 order than sent. 510 The sender MUST apply any S/MIME operations to the whole message 511 prior to breaking it into chunks. Likewise, the receiver needs to 512 reassemble the message from its chunks prior to decrypting, 513 validating a signature, etc. 515 MSRP chunks are framed using an end-line. The end-line comprises 516 seven hyphens, a 64-bit random value taken from the start line, and a 517 continuation flag. MRSP requires the sending user agent to scan data 518 sent in a specific chunk to be sent ensure that the end-line does not 519 accidentally occur as part of the sent data. This scanning occurs on 520 a chunk rather than a whole message, consequently it must occur after 521 the sender applies any S/MIME operations. 523 8.2. Streamed Data 525 MSRP allows a mode of operation where a UA sends some chunks of a 526 message prior to knowing the full length of the message. For 527 example, a sender might send streamed data over MSRP as a single 528 message, even though it doesn't know the full length of that data in 529 advance. This mode is incompatible with S/MIME, since a sending UA 530 must apply S/MIME operations to the entire message in advance of 531 breaking it into chunks. 533 Therefore, when sending a message in an S/MIME format, the sender 534 MUST include the Byte-Range header field for every chunk, including 535 the first chunk. The Byte-Range header field MUST include the total 536 length of the message. 538 A higher layer could choose to break such streamed data into a series 539 of messages prior to applying S/MIME operation, so that each fragment 540 appears as a distinct S/MIME separate message in MSRP. Such 541 mechanisms are beyond the scope for this document. 543 8.3. Indicating support for S/MIME 545 A UA that supports this specification MUST explicitly include the 546 appropriate media type or types in the "accept-types" attribute in 547 any SDP offer or answer that proposes MSRP. It MAY indicate that it 548 requires S/MIME wrappers for all messages by putting appropriate 549 S/MIME media types in the "accept-types" attribute and putting all 550 other supported media types in the "accept-wrapped-types" attribute. 552 For backwards compatibility, a sender MAY treat a peer that includes 553 an asterisk ("*") in the "accept-types" attribute as potentially 554 supporting S/MIME. If the peer returns an MSRP 415 response to an 555 attempt to send an S/MIME message, the sender should treat the peer 556 as not supporting S/MIME for the duration of the session, as 557 indicated in [RFC4975]. 559 While these SDP attributes allow an endpoint to express support for 560 certain media types only when wrapped in a specified envelope type, 561 it does not allow the expression of more complex structures. For 562 example, an endpoint can say that it supports text/plain and text/ 563 html, but only when inside an application/pkcs7 or message/cpim 564 container, but it cannot express a requirement for the leaf types to 565 always be contained in an application/pkcs7 container nested inside a 566 message/cpim container. This has implications for the use of S/MIME 567 with the message/cpim format. (See Section 9.1.) 569 MSRP allows multiple reporting modes that provide different levels of 570 feedback. If the sender includes a Failure-Report header field with 571 a value of "no", it will not receive failure reports. This mode 572 should not be used carelessly, since such a sender would never see a 573 415 response as described above, and would have no way to learn that 574 the recipient could not process an S/MIME body. 576 8.4. MSRP URIs 578 MSRP URIs are ephemeral. Endpoints MUST NOT use MSRP URIs to 579 identify certificates, or insert MSRP URIs into certificate Subject 580 Alternative Name fields. When MSRP sessions are negotiated using SIP 581 [RFC3261], the SIP AoRs of the peers are used instead. 583 Note that MSRP allows messages to be sent between peers in either 584 direction. A given MSRP message might be sent from the SIP offerer 585 to the SIP answerer. Thus, the sender and recipient roles may 586 reverse between one message and another in a given session. 588 8.5. Failure Cases 590 Successful delivery of an S/MIME message does not indicate that the 591 recipient successfully decrypted the contents or validated a 592 signature. Decryption and/or validation may not occur immediately on 593 receipt, since the recipient may not immediately view the message, 594 and the user agent may choose not to attempt decryption or validation 595 until the user requests it. 597 Likewise, successful delivery of S/MIME enveloped data does not, on 598 its own, indicate that the recipient supports the enclosed media 599 type. If the peer only implicitly indicated support for the enclosed 600 media type through the use of a wildcard in the "accept-types" or 601 "accept-wrapped types" SDP attributes, it may not decrypt the message 602 in time to send a 415 response. 604 9. S/MIME Interaction with other SIP Messaging Features 606 9.1. Common Profile for Instant Messaging 608 The Common Profile for Instant Messaging (CPIM) [RFC3860] defines an 609 abstract messaging service, with the goal of creating gateways 610 between different messaging protocols that could relay instant 611 messages without change. The SIP MESSAGE method and MSRP were 612 initially designed to map to the CPIM abstractions. However, at the 613 time of this writing, CPIM compliant gateways have not been deployed. 614 To the authors' knowledge, no other IM protocols have been explicitly 615 mapped to CPIM. 617 CPIM also defines the abstract messaging URI scheme "im:". As of the 618 time of this writing, the "im:" scheme is not in common use. 620 The Common Profile for Instant Messages Message Format [RFC3862] 621 allows UAs to attach transport-neutral metadata to arbitrary MIME 622 content. The format was designed as a canonicalization format to 623 allow signed data to cross protocol-converting gateways without loss 624 of metadata needed to verify the signature. While it has not 625 typically been used for that purpose, it has been used for other 626 metadata applications, for example, Instant Message Delivery 627 Notifications (IMDN)[RFC5438] and MSRP Multi-party Chat [RFC7701] 629 In the general case, a sender applies end-to-end signature and 630 encryption operations to the entire MIME body. However, some 631 messaging systems expect to inspect and in some cases add or modify 632 metadata in CPIM header fields. For example, CPM and RCS based 633 service include application servers that may need to insert time 634 stamps into chat messages, and may use additional metadata to 635 characterize the content and purpose of a message to determine 636 application behavior. The former will cause validation failure for 637 signatures that cover CPIM metadata, while the latter is not possible 638 if the metadata is encrypted. Clients intended for use in such 639 networks MAY choose to apply end-to-end signatures and encryption 640 operations to only the CPIM payload, leaving the CPIM metadata 641 unprotected from inspection and modification. UAs that support 642 S/MIME and CPIM SHOULD be able validate signatures and decrypt 643 enveloped data both when those operations are applied to the entire 644 CPIM body, and when they are applied to just the CPIM payload. 646 If such clients need to provide encrypt or sign CPIM metadata end-to- 647 end, they can nest a protected CPIM message format payload inside an 648 unprotected CPIM message envelope. 650 The use of CPIM metadata fields to identify certificates or to 651 authenticate SIP or MSRP header fields is out of scope for this 652 document. 654 9.2. Instant Message Delivery Notifications 656 The Instant Message Delivery Notification (IMDN) mechanism [RFC5438] 657 allows both endpoints and intermediary application servers to request 658 and to generate delivery notifications. The use of S/MIME does not 659 impact strictly end-to-end use of IMDN. IMDN recommends that devices 660 that are capable of doing so sign delivery notifications. It further 661 requires that delivery notifications that result from encrypted 662 messages also be encrypted. 664 However, IMDN allows intermediary application servers to insert 665 notification requests into messages, to add routing information to 666 messages, and to act on notification requests. It also allows list 667 servers to aggregate delivery notifications. 669 Such intermediaries will be unable to read end-to-end encrypted 670 messages in order to interpret delivery notice requests. 671 Intermediaries that insert information into end-to-end signed 672 messages will cause the signature validation to fail. (See 673 Section 9.1.) 675 10. Examples 677 The following sections show examples of S/MIME messages in SIP and 678 MSRP. The examples include the tags "[start-hex]" and "[end-hex]" to 679 denote binary content shown in hexadecimal. The tags are not part of 680 the actual message, and do not count towards the Content-Length 681 header field values. Some SIP header fields are folded to avoid 682 overrunning the margins. Folded lines contain leading white space at 683 the beginning of the line. These folds would not exist in the actual 684 message. 686 In all of these examples, the clear text message is the string 687 "Watson, come here - I want to see you." followed by a newline 688 character. 690 The cast of characters includes Alice, with a SIP AoR of 691 "alice@example.com", and Bob, with a SIP AoR of "bob@example.org". 693 Appendix A shows the detailed content of each S/MIME body. 695 10.1. Signed Message in SIP Including the Sender's Certificate 697 Figure 1 shows a message signed by Alice. This body uses the 698 "application/pcks7-mime" media type with an smime-type parameter 699 value of "signed-data". 701 The S/MIME body includes Alice's signing certificate. Even though 702 the original message content is fairly short and only minimal SIP 703 header fields are included, the total message size is 1300 octets. 704 This is the maximum allowed for the SIP MESSAGE method unless the UAC 705 has advance knowledge that no hop will use a transport protocol 706 without congestion control. 708 MESSAGE sip:bob@example.org SIP/2.0 709 Via: SIP/2.0/TCP alice-pc.example.com;branch=z9hG4bK776sgdkfie 710 Max-Forwards: 70 711 From: sip:alice@example.com;tag=49597 712 To: sip:bob@example.org 713 Call-ID: asd88asd66b@1.2.3.4 714 CSeq: 1 MESSAGE 715 Content-Transfer-Encoding: binary 716 Content-Type: application/pkcs7-mime; smime-type=signed-data; 717 name="smime.p7m" 718 Content-Disposition: attachment; filename="smime.p7m" 719 Content-Length: 890 721 [start-hex] 722 3082037606092a864886f70d010702a082036730820363020101310d300b 723 0609608648016503040201305306092a864886f70d010701a0460444436f 724 6e74656e742d547970653a20746578742f706c61696e0d0a0d0a57617473 725 6f6e2c20636f6d652068657265202d20492077616e7420746f2073656520 726 796f752e0d0aa082016f3082016b30820110a00302010202090090238790 727 1727648e300a06082a8648ce3d040302302631143012060355040a0c0b65 728 78616d706c652e636f6d310e300c06035504030c05416c696365301e170d 729 3137313232303232353433395a170d3138313232303232353433395a3026 730 31143012060355040a0c0b6578616d706c652e636f6d310e300c06035504 731 030c05416c6963653059301306072a8648ce3d020106082a8648ce3d0301 732 0703420004d87b54729f2c22feebd9ddba0efa40642297a6093887a4dae7 733 990b23f87fa7ed99db8cf5a314f2ee64106ef1ed61dbfc0a4b91c953cbd0 734 22a751b914807bb794a327302530230603551d110101ff04193017861573 735 69703a616c696365406578616d706c652e636f6d300a06082a8648ce3d04 736 03020349003046022100f16fe739ddf3a1ff072a78142395721f9c0629b5 737 8458644d855dad94da9b06f20221008ffda4ba4c65087584969bfb2002ba 738 f5eefebd693181b43666141f363990988431820185308201810201013033 739 302631143012060355040a0c0b6578616d706c652e636f6d310e300c0603 740 5504030c05416c696365020900902387901727648e300b06096086480165 741 03040201a081e4301806092a864886f70d010903310b06092a864886f70d 742 010701301c06092a864886f70d010905310f170d31373132323032323537 743 35315a302f06092a864886f70d01090431220420ef778fc940d5e6dc2576 744 f47a599b3126195a9f1a227adaf35fa22c050d8d195a307906092a864886 745 f70d01090f316c306a300b060960864801650304012a300b060960864801 746 6503040116300b0609608648016503040102300a06082a864886f70d0307 747 300e06082a864886f70d030202020080300d06082a864886f70d03020201 748 40300706052b0e030207300d06082a864886f70d0302020128300a06082a 749 8648ce3d0403020447304502200f37c8d68628ed5a52e1208bb091999901 750 02f1de5766a45d5b4627fe4d87c9cc022100f0de29c03e7d3fcc5329b77f 751 e31faa10b0003c8249cb011cbb14410d4c9bf93e 752 [end-hex] 754 Figure 1: Signed Message in SIP 756 10.2. Signed Message in SIP with No Certificate 758 Figure 2 shows the same message from Alice without the imbedded 759 certificate. The resulting total length of 928 octets is more 760 manageable. 762 MESSAGE sip:bob@example.org SIP/2.0 763 Via: SIP/2.0/TCP alice-pc.example.com;branch=z9hG4bK776sgdkfie 764 Max-Forwards: 70 765 From: sip:alice@example.com;tag=49597 766 To: sip:bob@example.org 767 Call-ID: asd88asd66b@1.2.3.4 768 CSeq: 1 MESSAGE 769 Content-Transfer-Encoding: binary 770 Content-Type: application/pkcs7-mime; smime-type=signed-data; 771 name="smime.p7m" 772 Content-Disposition: attachment; filename="smime.p7m" 773 Content-Length: 518 775 [start-hex] 776 3082020206092a864886f70d010702a08201f3308201ef020101310d300b 777 0609608648016503040201305306092a864886f70d010701a0460444436f 778 6e74656e742d547970653a20746578742f706c61696e0d0a0d0a57617473 779 6f6e2c20636f6d652068657265202d20492077616e7420746f2073656520 780 796f752e0d0a31820184308201800201013033302631143012060355040a 781 0c0b6578616d706c652e636f6d310e300c06035504030c05416c69636502 782 0900b8793ec0e4c21530300b0609608648016503040201a081e430180609 783 2a864886f70d010903310b06092a864886f70d010701301c06092a864886 784 f70d010905310f170d3137313232313032313230345a302f06092a864886 785 f70d01090431220420ef778fc940d5e6dc2576f47a599b3126195a9f1a22 786 7adaf35fa22c050d8d195a307906092a864886f70d01090f316c306a300b 787 060960864801650304012a300b0609608648016503040116300b06096086 788 48016503040102300a06082a864886f70d0307300e06082a864886f70d03 789 0202020080300d06082a864886f70d0302020140300706052b0e03020730 790 0d06082a864886f70d0302020128300a06082a8648ce3d04030204463044 791 022057773352edeed4ea693455e2a87b8b098decefe50ddb0ff7e391e84f 792 7976208a0220089cf365467a1a49e838b51f35a62c7a158e5fc999bf7d8f 793 bfb5262af5afec93 794 [end-hex] 796 Figure 2: Signed Message in SIP with No Certificate Included 798 10.3. MSRP Signed and Encrypted Message in a Single Chunk 800 Figure 3 shows a signed and encrypted message from Bob to Alice sent 801 via MSRP. 803 MSRP dsdfoe38sd SEND 804 To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp 805 From-Path: msrp://bobpc.example.org:8888/9di4eae923wzd;tcp 806 Message-ID: 456so39s 807 Byte-Range: 1-1567/1567 808 Content-Disposition: attachment; filename="smime.p7m" 809 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; 810 name="smime.p7m" 812 [start-hex] 813 3082061b06092a864886f70d010703a082060c308206080201003182024f 814 3082024b0201003033302631143012060355040a0c0b6578616d706c652e 815 636f6d310e300c06035504030c05416c69636502090083f50bb70bd5c40e 816 300d06092a864886f70d010101050004820200bbab785554a48e6248677b 817 5c56328528282e172d36611dc2986ae168fc84d49f4120ea2cb895d5967f 818 f35a22ed2e5fee4d7204e70c8697bf138d9fbd8485c300638f9ef93e6146 819 5f1e1405fb5bf7b95f2faf12e441fb8cfcdfd5cf1d88d285cfa9fddf0de3 820 f9c95b8cd750772924c7d919c80aa8677dc2bc63b5abe2a04e76ee0c2e6c 821 041e08fa29476a4a76851944edd7fa79ada89709107bf65d56ac669b781a 822 23f0fd7232de26bba07e1dca69f50118bd4955463d2cad403dc2a6749209 823 dfc02c9e145270d5135ce5548bbf3347c6f356faa093feefdbba5d094f4a 824 0e23a94686fca77cfa1759aaa4e27748227e6517063fbbd7a013abcb08f9 825 50b2ac911b72b340d57c24d08e613f4e0a087821c820238e422e85bf3902 826 c99a9629b0862945e00d1b433f6dc35e8d1cb5098597363624456dd867e6 827 132d8ee935cc3b4124df6baba88770708af57c9ad70727410d6bf83ec0e5 828 580e26c67f90608d375750ed93890256bf3f714fb676effcf363db0809b0 829 21e90994a437353ee41432c7cf60e48cbd45420c659e75906cede2d44a5b 830 b619014e73a0ba2d54ab3edbe23c63fad898411d1ac790552eadc66a358f 831 bd4461efec935d0b8bbc2e6cf23e863a1ee7a4e7741f072c1d465ea1e6c3 832 577b2e77acd1d1152f268235f85ae82f50871acf13e38b17fd69f88f973f 833 6818682c4043b4ec7db17b22e20ee9becbf2c9f893308203ae06092a8648 834 86f70d010701301d060960864801650304010204104d8757222eac529411 835 7f0c12d671a127808203805d4077a1547c5f4699f07531a53eb88344d1a3 836 b229ff91f3f69c0e94918c77c9f6bda194e35983ef9a38edca15678e65bd 837 76ce665ca6e999b3a845e42666aa2703a5a4f0d3322d6de01e64545cbccf 838 09e3c2268dfd86c336116b22cce80098619242fd482ece2fcd71a7c15ff7 839 7bf133287df0ef7c51713bdc0f6cdada9198ea8fd81a9c5a50c5e9c0958b 840 3347efc425038fb5b776ab469826227c697aecc6580d0a23a99e15b805ff 841 3ba155c252f5e72bb9db133d049d992c18f4f4dad60a18dae729ba7c5836 842 78ffb8604a8f7fe3cc62d0632cc66e1c4f9ba1fa9df56c6d9fd81f19c88b 843 a6e9710bb0bbb0c5fcf9d2d5ea04d529fda78d60dc487d867c0e392174e9 844 3ce2c3986cea7aef071e5b07b646c229f9069f27f3749456daea0a4e56bc 845 491c9be370c544399a273d50c35f160fb37e5f7314c3d389a805c8e4776f 846 0a2a89f555c9fe52080890abe2e39d2ed77a2b363d1c0fb375790028e962 847 401230ae93aa4320a5da2ad7017c599508f79c3a0c35f9846e8a2c410a5e 848 0d77e907c0151ce513e2e899de92ff8d177796238ade9309d75c976e9716 849 ced4c45e1a339213d7b0824592394076f74a70454cc46565f4a836531646 850 42827b2e28819ac3781afb529b7c72308b96978539d789d3d27cb1605b1a 851 0ce966e9c6cb5825d235e523a6c2d948ef9314c902359adf03fe4684221f 852 afd1f833d759c6f2559b6e0a8897d64e42b49eae0e39dfaccc94ef3e733f 853 ca2212eb5ccbc7c5d7f042d02bf412d14c7ede0f664d799ea556f9763e74 854 2cacdd3efc8822bbe6c81fea27de6b0b06448252f9adeb6667b46056f39b 855 42f18f4d6258111fa243b5c39fdf8961bc6e59d8bd659d46f92a8ced04d1 856 a6af37e5c089b547a836df6994377cf92e8e74625569df6a6065f6c93bab 857 ef0d07cfac7af69d8bf87c96e6ebad2ebdb553f776e69143e706e227061e 858 5e3d0e38a83ab9c2ce62102f3021f7d8b9e56ad6714514039f48d7fab85e 859 fbafee16e15d7afd8148ccfc9fb273f8bfd5bdebd0281a50095aa192c9e8 860 7a0f2c44bb57de5f86cfbda3337cd982dfae982a80879878646e03614515 861 cf94150479d20e3ce521617dda22d53a5829265564fa467e7db9e25f3d25 862 5a4f9f82fd9514ca177ac81b882acbe89d1cc640c7b980c5a9d5f70921bb 863 6fbf166d38aa04257e08c51b2df144e93363e0e47e8013df584b3f3130b4 864 df7c9ae17709f1bfd8ded1385741d80596b7b8d6a2f2e5a2f85029ce97ef 865 ed2c97f942f77b 866 [end-hex] 867 -------dsdfoe38sd$ 869 Figure 3: Signed and Encrypted Message in MSRP 871 10.4. MSRP Signed and Encrypted Message sent in Multiple Chunks 873 Figure 4 shows the same message as in Figure 3 except that the 874 message is broken into two chunks. The S/MIME operations were 875 performed prior to breaking the message into chunks. 877 MSRP d93kswow SEND 878 To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp 879 From-Path: msrp://bobpc.example.org:8888/9di4eae923wzd;tcp 880 Message-ID: 12339sdqwer 881 Byte-Range: 1-780/1567 882 Content-Disposition: attachment; filename="smime.p7m" 883 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; 884 name="smime.p7m" 886 [start-hex] 887 3082061b06092a864886f70d010703a082060c308206080201003182024f 888 3082024b0201003033302631143012060355040a0c0b6578616d706c652e 889 636f6d310e300c06035504030c05416c69636502090083f50bb70bd5c40e 890 300d06092a864886f70d010101050004820200bbab785554a48e6248677b 891 5c56328528282e172d36611dc2986ae168fc84d49f4120ea2cb895d5967f 892 f35a22ed2e5fee4d7204e70c8697bf138d9fbd8485c300638f9ef93e6146 893 5f1e1405fb5bf7b95f2faf12e441fb8cfcdfd5cf1d88d285cfa9fddf0de3 894 f9c95b8cd750772924c7d919c80aa8677dc2bc63b5abe2a04e76ee0c2e6c 895 041e08fa29476a4a76851944edd7fa79ada89709107bf65d56ac669b781a 896 23f0fd7232de26bba07e1dca69f50118bd4955463d2cad403dc2a6749209 897 dfc02c9e145270d5135ce5548bbf3347c6f356faa093feefdbba5d094f4a 898 0e23a94686fca77cfa1759aaa4e27748227e6517063fbbd7a013abcb08f9 899 50b2ac911b72b340d57c24d08e613f4e0a087821c820238e422e85bf3902 900 c99a9629b0862945e00d1b433f6dc35e8d1cb5098597363624456dd867e6 901 132d8ee935cc3b4124df6baba88770708af57c9ad70727410d6bf83ec0e5 902 580e26c67f90608d375750ed93890256bf3f714fb676effcf363db0809b0 903 21e90994a437353ee41432c7cf60e48cbd45420c659e75906cede2d44a5b 904 b619014e73a0ba2d54ab3edbe23c63fad898411d1ac790552eadc66a358f 905 bd4461efec935d0b8bbc2e6cf23e863a1ee7a4e7741f072c1d465ea1e6c3 906 577b2e77acd1d1152f268235f85ae82f50871acf13e38b17fd69f88f973f 907 6818682c4043b4ec7db17b22e20ee9becbf2c9f893308203ae06092a8648 908 86f70d010701301d060960864801650304010204104d8757222eac529411 909 7f0c12d671a127808203805d4077a1547c5f4699f07531a53eb88344d1a3 910 b229ff91f3f69c0e94918c77c9f6bda194e35983ef9a38edca15678e65bd 911 76ce665ca6e999b3a845e42666aa2703a5a4f0d3322d6de01e64545cbccf 912 09e3c2268dfd86c336116b22cce80098619242fd482ece2fcd71a7c15ff7 913 [end-hex] 914 -------d93kswow+ 916 MSRP op2nc9a SEND 917 To-Path: msrp://alicepc.example.com:8888/9di4eae923wzd;tcp 918 From-Path: msrp://bobpc.example.org:7654/iau39soe2843z;tcp 919 Message-ID: 12339sdqwer 920 Byte-Range: 781-1567/1567 921 Content-Disposition: attachment; filename="smime.p7m" 922 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; 923 name="smime.p7m" 925 [start-hex] 926 7bf133287df0ef7c51713bdc0f6cdada9198ea8fd81a9c5a50c5e9c0958b 927 3347efc425038fb5b776ab469826227c697aecc6580d0a23a99e15b805ff 928 3ba155c252f5e72bb9db133d049d992c18f4f4dad60a18dae729ba7c5836 929 78ffb8604a8f7fe3cc62d0632cc66e1c4f9ba1fa9df56c6d9fd81f19c88b 930 a6e9710bb0bbb0c5fcf9d2d5ea04d529fda78d60dc487d867c0e392174e9 931 3ce2c3986cea7aef071e5b07b646c229f9069f27f3749456daea0a4e56bc 932 491c9be370c544399a273d50c35f160fb37e5f7314c3d389a805c8e4776f 933 0a2a89f555c9fe52080890abe2e39d2ed77a2b363d1c0fb375790028e962 934 401230ae93aa4320a5da2ad7017c599508f79c3a0c35f9846e8a2c410a5e 935 0d77e907c0151ce513e2e899de92ff8d177796238ade9309d75c976e9716 936 ced4c45e1a339213d7b0824592394076f74a70454cc46565f4a836531646 937 42827b2e28819ac3781afb529b7c72308b96978539d789d3d27cb1605b1a 938 0ce966e9c6cb5825d235e523a6c2d948ef9314c902359adf03fe4684221f 939 afd1f833d759c6f2559b6e0a8897d64e42b49eae0e39dfaccc94ef3e733f 940 ca2212eb5ccbc7c5d7f042d02bf412d14c7ede0f664d799ea556f9763e74 941 2cacdd3efc8822bbe6c81fea27de6b0b06448252f9adeb6667b46056f39b 942 42f18f4d6258111fa243b5c39fdf8961bc6e59d8bd659d46f92a8ced04d1 943 a6af37e5c089b547a836df6994377cf92e8e74625569df6a6065f6c93bab 944 ef0d07cfac7af69d8bf87c96e6ebad2ebdb553f776e69143e706e227061e 945 5e3d0e38a83ab9c2ce62102f3021f7d8b9e56ad6714514039f48d7fab85e 946 fbafee16e15d7afd8148ccfc9fb273f8bfd5bdebd0281a50095aa192c9e8 947 7a0f2c44bb57de5f86cfbda3337cd982dfae982a80879878646e03614515 948 cf94150479d20e3ce521617dda22d53a5829265564fa467e7db9e25f3d25 949 5a4f9f82fd9514ca177ac81b882acbe89d1cc640c7b980c5a9d5f70921bb 950 6fbf166d38aa04257e08c51b2df144e93363e0e47e8013df584b3f3130b4 951 df7c9ae17709f1bfd8ded1385741d80596b7b8d6a2f2e5a2f85029ce97ef 952 ed2c97f942f77b 953 [end-hex] 954 -------op2nc9a$ 956 Figure 4: MSRP Chunked Signed and Encrypted Message 958 11. IANA Considerations 960 This document makes no requests of the IANA. 962 12. Security Considerations 964 The security considerations from S/MIME [RFC5750][RFC5751] and 965 elliptic curves in CMS [RFC5753] apply. The S/MIME related security 966 considerations from SIP [RFC3261][RFC3853], SIP MESSAGE [RFC3428], 967 and MSRP [RFC4975] apply. 969 The security considerations from algorithms recommended in this 970 document also apply, see [RFC3565], [RFC5480], [RFC5753], [RFC5754], 971 [RFC7748], [RFC8032], [RFC8419], and [RFC8418]. 973 This document assumes that end-entity certificate validation is 974 provided by a chain of trust to a certification authority (CA), using 975 a public key infrastructure. The security considerations from 976 [RFC5280] apply. However, other validations methods may be possible; 977 for example sending a signed fingerprint for the end-entity in SDP. 978 The relationship of this work and the techniques discussed in 979 [RFC8224] and [I-D.ietf-sipbrandy-rtpsec] are out of scope for this 980 document. 982 When matching an end-entity certificate to the sender or recipient 983 identity, the respective SIP AoRs are used. Typically these will 984 match the SIP From and To header fields. Some UAs may extract sender 985 identity from SIP AoRs in other header fields, for example, P- 986 Asserted-Identity [RFC3325]. In general, the UAS should compare the 987 certificate to the identity that it relies upon, for example for 988 display to the end-user or comparison to white lists and blacklists. 990 The secure notification use case discussed in Section 1 has 991 significant vulnerabilities when used in an insecure environment. 992 For example, "phishing" messages could be used to trick users into 993 revealing credentials. Eavesdroppers could learn confirmation codes 994 from unprotected two-factor authentication messages. Unsolicited 995 messages sent by impersonators could tarnish the reputation of an 996 organization. While hop-by-hop protection can mitigate some of those 997 risks, it still leaves messages vulnerable to malicious or 998 compromised intermediaries. 1000 Mobile messaging is typically an online application; online 1001 certificate revocation checks should usually be feasible. 1003 S/MIME does not normally protect the SIP or MSRP headers. While it 1004 normally does protect the CPIM header, certain CPIM header fields may 1005 not be protected if the sender excludes them from the encrypted or 1006 signed part of the message. (See Section 9.1.) Certain messaging 1007 services, for example those based on RCS, may include intermediaries 1008 that attach metadata to user generated messages in the form of SIP, 1009 MSRP, or CPIM header fields. This metadata could possibly reveal 1010 information to third parties that the sender might prefer not to send 1011 as cleartext. Implementors and operators should consider whether 1012 inserted metadata may create privacy leaks. Such an analysis is 1013 beyond the scope of this document. 1015 13. References 1017 13.1. Normative References 1019 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1020 Requirement Levels", BCP 14, RFC 2119, 1021 DOI 10.17487/RFC2119, March 1997, 1022 . 1024 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1025 A., Peterson, J., Sparks, R., Handley, M., and E. 1026 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1027 DOI 10.17487/RFC3261, June 2002, 1028 . 1030 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1031 with Session Description Protocol (SDP)", RFC 3264, 1032 DOI 10.17487/RFC3264, June 2002, 1033 . 1035 [RFC3428] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., 1036 Huitema, C., and D. Gurle, "Session Initiation Protocol 1037 (SIP) Extension for Instant Messaging", RFC 3428, 1038 DOI 10.17487/RFC3428, December 2002, 1039 . 1041 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) 1042 Encryption Algorithm in Cryptographic Message Syntax 1043 (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003, 1044 . 1046 [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) 1047 Requirement for the Session Initiation Protocol (SIP)", 1048 RFC 3853, DOI 10.17487/RFC3853, July 2004, 1049 . 1051 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1052 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1053 July 2006, . 1055 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 1056 "The Message Session Relay Protocol (MSRP)", RFC 4975, 1057 DOI 10.17487/RFC4975, September 2007, 1058 . 1060 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1061 Housley, R., and W. Polk, "Internet X.509 Public Key 1062 Infrastructure Certificate and Certificate Revocation List 1063 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1064 . 1066 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 1067 "Elliptic Curve Cryptography Subject Public Key 1068 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 1069 . 1071 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1072 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1073 . 1075 [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1076 Mail Extensions (S/MIME) Version 3.2 Certificate 1077 Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010, 1078 . 1080 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1081 Mail Extensions (S/MIME) Version 3.2 Message 1082 Specification", RFC 5751, DOI 10.17487/RFC5751, January 1083 2010, . 1085 [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve 1086 Cryptography (ECC) Algorithms in Cryptographic Message 1087 Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January 1088 2010, . 1090 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 1091 Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 1092 2010, . 1094 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1095 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1096 May 2017, . 1098 [RFC8418] Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key 1099 Agreement Algorithm with X25519 and X448 in the 1100 Cryptographic Message Syntax (CMS)", RFC 8418, 1101 DOI 10.17487/RFC8418, August 2018, 1102 . 1104 [RFC8419] Housley, R., "Use of Edwards-Curve Digital Signature 1105 Algorithm (EdDSA) Signatures in the Cryptographic Message 1106 Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419, August 1107 2018, . 1109 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 1110 One (ASN.1): Specification of basic notation", 1111 ITU-T Recommendation X.680, 2015. 1113 [X690] ITU-T, "Information Technology -- ASN.1 encoding rules: 1114 Specification of Basic Encoding Rules (BER), Canonical 1115 Encoding Rules (CER) and Distinguished Encoding Rules 1116 (DER)", ITU-T Recommendation X.690, 2015. 1118 13.2. Informative References 1120 [CPM] Open Mobile Alliance, "OMA Converged IP Messaging System 1121 Description, Candidate Version 2.2", September 2017. 1123 [I-D.ietf-sipbrandy-rtpsec] 1124 Peterson, J., Barnes, R., and R. Housley, "Best Practices 1125 for Securing RTP Media Signaled with SIP", draft-ietf- 1126 sipbrandy-rtpsec-06 (work in progress), October 2018. 1128 [RCS] GSMA, "RCS Universal Profile Service Definition Document, 1129 Version 2.0", June 2017. 1131 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1132 Extensions to the Session Initiation Protocol (SIP) for 1133 Asserted Identity within Trusted Networks", RFC 3325, 1134 DOI 10.17487/RFC3325, November 2002, 1135 . 1137 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1138 "Indicating User Agent Capabilities in the Session 1139 Initiation Protocol (SIP)", RFC 3840, 1140 DOI 10.17487/RFC3840, August 2004, 1141 . 1143 [RFC3860] Peterson, J., "Common Profile for Instant Messaging 1144 (CPIM)", RFC 3860, DOI 10.17487/RFC3860, August 2004, 1145 . 1147 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 1148 Messaging (CPIM): Message Format", RFC 3862, 1149 DOI 10.17487/RFC3862, August 2004, 1150 . 1152 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1153 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1154 . 1156 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 1157 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 1158 DOI 10.17487/RFC4976, September 2007, 1159 . 1161 [RFC5438] Burger, E. and H. Khartabil, "Instant Message Disposition 1162 Notification (IMDN)", RFC 5438, DOI 10.17487/RFC5438, 1163 February 2009, . 1165 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 1166 Protocol (XMPP): Instant Messaging and Presence", 1167 RFC 6121, DOI 10.17487/RFC6121, March 2011, 1168 . 1170 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1171 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 1172 2015, . 1174 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 1175 RFC 7516, DOI 10.17487/RFC7516, May 2015, 1176 . 1178 [RFC7701] Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi- 1179 party Chat Using the Message Session Relay Protocol 1180 (MSRP)", RFC 7701, DOI 10.17487/RFC7701, December 2015, 1181 . 1183 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1184 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1185 2016, . 1187 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1188 Signature Algorithm (EdDSA)", RFC 8032, 1189 DOI 10.17487/RFC8032, January 2017, 1190 . 1192 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 1193 "Authenticated Identity Management in the Session 1194 Initiation Protocol (SIP)", RFC 8224, 1195 DOI 10.17487/RFC8224, February 2018, 1196 . 1198 Appendix A. Message Details 1200 The following section shows the detailed content of the S/MIME bodies 1201 used in Section 10. 1203 A.1. Signed Message 1205 Figure 5 shows the details of the message signed by Alice used in the 1206 example in Section 10.1. 1208 CMS_ContentInfo: 1209 contentType: pkcs7-signedData (1.2.840.113549.1.7.2) 1210 d.signedData: 1211 version: 1 1212 digestAlgorithms: 1213 algorithm: sha256 (2.16.840.1.101.3.4.2.1) 1214 parameter: 1215 encapContentInfo: 1216 eContentType: pkcs7-data (1.2.840.113549.1.7.1) 1217 eContent: 1218 0000 - 43 6f 6e 74 65 6e 74 2d-54 79 70 65 3a 20 74 Content-Type: t 1219 000f - 65 78 74 2f 70 6c 61 69-6e 0d 0a 0d 0a 57 61 ext/plain....Wa 1220 001e - 74 73 6f 6e 2c 20 63 6f-6d 65 20 68 65 72 65 tson, come here 1221 002d - 20 2d 20 49 20 77 61 6e-74 20 74 6f 20 73 65 - I want to se 1222 003c - 65 20 79 6f 75 2e 0d 0a- e you... 1223 certificates: 1224 d.certificate: 1225 cert_info: 1226 version: 2 1227 serialNumber: 10386294218579993742 1228 signature: 1229 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1230 parameter: 1232 issuer: O=example.com, CN=Alice 1233 validity: 1234 notBefore: Dec 20 22:54:39 2017 GMT 1235 notAfter: Dec 20 22:54:39 2018 GMT 1236 subject: O=example.com, CN=Alice 1237 key: 1238 algor: 1239 algorithm: id-ecPublicKey (1.2.840.10045.2.1) 1240 parameter: OBJECT:prime256v1 (1.2.840.10045.3.1.7) 1241 public_key: (0 unused bits) 1242 0000 - 04 d8 7b 54 72 9f 2c 22-fe eb d9 dd ba 0e ..{Tr.,"...... 1243 000e - fa 40 64 22 97 a6 09 38-87 a4 da e7 99 0b .@d"...8...... 1244 001c - 23 f8 7f a7 ed 99 db 8c-f5 a3 14 f2 ee 64 #............d 1245 002a - 10 6e f1 ed 61 db fc 0a-4b 91 c9 53 cb d0 .n..a...K..S.. 1246 0038 - 22 a7 51 b9 14 80 7b b7-94 ".Q...{.. 1247 issuerUID: 1248 subjectUID: 1249 extensions: 1250 object: X509v3 Subject Alternative Name (2.5.29.17) 1251 critical: TRUE 1252 value: 1253 0000 - 30 17 86 15 73 69 70 3a-61 6c 69 63 65 0...sip:alice 1254 000d - 40 65 78 61 6d 70 6c 65-2e 63 6f 6d @example.com 1255 sig_alg: 1256 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1257 parameter: 1258 signature: (0 unused bits) 1259 0000 - 30 46 02 21 00 f1 6f e7-39 dd f3 a1 ff 07 2a 0F.!..o.9.....* 1260 000f - 78 14 23 95 72 1f 9c 06-29 b5 84 58 64 4d 85 x.#.r...)..XdM. 1261 001e - 5d ad 94 da 9b 06 f2 02-21 00 8f fd a4 ba 4c ].......!.....L 1262 002d - 65 08 75 84 96 9b fb 20-02 ba f5 ee fe bd 69 e.u.... ......i 1263 003c - 31 81 b4 36 66 14 1f 36-39 90 98 84 1..6f..69... 1264 crls: 1265 1266 signerInfos: 1267 version: 1 1268 d.issuerAndSerialNumber: 1269 issuer: O=example.com, CN=Alice 1270 serialNumber: 10386294218579993742 1271 digestAlgorithm: 1272 algorithm: sha256 (2.16.840.1.101.3.4.2.1) 1273 parameter: 1274 signedAttrs: 1275 object: contentType (1.2.840.113549.1.9.3) 1276 value.set: 1277 OBJECT:pkcs7-data (1.2.840.113549.1.7.1) 1279 object: signingTime (1.2.840.113549.1.9.5) 1280 value.set: 1281 UTCTIME:Dec 20 22:57:51 2017 GMT 1283 object: messageDigest (1.2.840.113549.1.9.4) 1284 value.set: 1285 OCTET STRING: 1286 0000 - ef 77 8f c9 40 d5 e6 dc-25 76 f4 7a 59 .w..@...%v.zY 1287 000d - 9b 31 26 19 5a 9f 1a 22-7a da f3 5f a2 .1&.Z.."z.._. 1288 001a - 2c 05 0d 8d 19 5a ,....Z 1290 object: S/MIME Capabilities (1.2.840.113549.1.9.15) 1291 value.set: 1292 SEQUENCE: 1293 0:d=0 hl=2 l= 106 cons: SEQUENCE 1294 2:d=1 hl=2 l= 11 cons: SEQUENCE 1295 4:d=2 hl=2 l= 9 prim: OBJECT :aes-256-cbc 1296 15:d=1 hl=2 l= 11 cons: SEQUENCE 1297 17:d=2 hl=2 l= 9 prim: OBJECT :aes-192-cbc 1298 28:d=1 hl=2 l= 11 cons: SEQUENCE 1299 30:d=2 hl=2 l= 9 prim: OBJECT :aes-128-cbc 1300 41:d=1 hl=2 l= 10 cons: SEQUENCE 1301 43:d=2 hl=2 l= 8 prim: OBJECT :des-ede3-cbc 1302 53:d=1 hl=2 l= 14 cons: SEQUENCE 1303 55:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc 1304 65:d=2 hl=2 l= 2 prim: INTEGER :80 1305 69:d=1 hl=2 l= 13 cons: SEQUENCE 1306 71:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc 1307 81:d=2 hl=2 l= 1 prim: INTEGER :40 1308 84:d=1 hl=2 l= 7 cons: SEQUENCE 1309 86:d=2 hl=2 l= 5 prim: OBJECT :des-cbc 1310 93:d=1 hl=2 l= 13 cons: SEQUENCE 1311 95:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc 1312 105:d=2 hl=2 l= 1 prim: INTEGER :28 1313 signatureAlgorithm: 1314 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1315 parameter: 1316 signature: 1317 0000 - 30 45 02 20 0f 37 c8 d6-86 28 ed 5a 52 e1 20 0E. .7...(.ZR. 1318 000f - 8b b0 91 99 99 01 02 f1-de 57 66 a4 5d 5b 46 .........Wf.][F 1319 001e - 27 fe 4d 87 c9 cc 02 21-00 f0 de 29 c0 3e 7d '.M....!...).>} 1320 002d - 3f cc 53 29 b7 7f e3 1f-aa 10 b0 00 3c 82 49 ?.S)........<.I 1321 003c - cb 01 1c bb 14 41 0d 4c-9b f9 3e .....A.L..> 1322 unsignedAttrs: 1323 1325 Figure 5: Signed Message 1327 A.2. Short Signed Message 1329 Figure 6 shows the message signed by Alice with no imbedded 1330 certificate, as used in the example in Section 10.2. 1332 CMS_ContentInfo: 1333 contentType: pkcs7-signedData (1.2.840.113549.1.7.2) 1334 d.signedData: 1335 version: 1 1336 digestAlgorithms: 1337 algorithm: sha256 (2.16.840.1.101.3.4.2.1) 1338 parameter: 1339 encapContentInfo: 1340 eContentType: pkcs7-data (1.2.840.113549.1.7.1) 1341 eContent: 1342 0000 - 43 6f 6e 74 65 6e 74 2d-54 79 70 65 3a 20 74 Content-Type: t 1343 000f - 65 78 74 2f 70 6c 61 69-6e 0d 0a 0d 0a 57 61 ext/plain....Wa 1344 001e - 74 73 6f 6e 2c 20 63 6f-6d 65 20 68 65 72 65 tson, come here 1345 002d - 20 2d 20 49 20 77 61 6e-74 20 74 6f 20 73 65 - I want to se 1346 003c - 65 20 79 6f 75 2e 0d 0a- e you... 1347 certificates: 1348 1349 crls: 1350 1351 signerInfos: 1352 version: 1 1353 d.issuerAndSerialNumber: 1354 issuer: O=example.com, CN=Alice 1355 serialNumber: 13292724773353297200 1356 digestAlgorithm: 1357 algorithm: sha256 (2.16.840.1.101.3.4.2.1) 1358 parameter: 1359 signedAttrs: 1360 object: contentType (1.2.840.113549.1.9.3) 1361 value.set: 1362 OBJECT:pkcs7-data (1.2.840.113549.1.7.1) 1364 object: signingTime (1.2.840.113549.1.9.5) 1365 value.set: 1366 UTCTIME:Dec 21 02:12:04 2017 GMT 1368 object: messageDigest (1.2.840.113549.1.9.4) 1369 value.set: 1370 OCTET STRING: 1371 0000 - ef 77 8f c9 40 d5 e6 dc-25 76 f4 7a 59 .w..@...%v.zY 1372 000d - 9b 31 26 19 5a 9f 1a 22-7a da f3 5f a2 .1&.Z.."z.._. 1373 001a - 2c 05 0d 8d 19 5a ,....Z 1374 object: S/MIME Capabilities (1.2.840.113549.1.9.15) 1375 value.set: 1376 SEQUENCE: 1377 0:d=0 hl=2 l= 106 cons: SEQUENCE 1378 2:d=1 hl=2 l= 11 cons: SEQUENCE 1379 4:d=2 hl=2 l= 9 prim: OBJECT :aes-256-cbc 1380 15:d=1 hl=2 l= 11 cons: SEQUENCE 1381 17:d=2 hl=2 l= 9 prim: OBJECT :aes-192-cbc 1382 28:d=1 hl=2 l= 11 cons: SEQUENCE 1383 30:d=2 hl=2 l= 9 prim: OBJECT :aes-128-cbc 1384 41:d=1 hl=2 l= 10 cons: SEQUENCE 1385 43:d=2 hl=2 l= 8 prim: OBJECT :des-ede3-cbc 1386 53:d=1 hl=2 l= 14 cons: SEQUENCE 1387 55:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc 1388 65:d=2 hl=2 l= 2 prim: INTEGER :80 1389 69:d=1 hl=2 l= 13 cons: SEQUENCE 1390 71:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc 1391 81:d=2 hl=2 l= 1 prim: INTEGER :40 1392 84:d=1 hl=2 l= 7 cons: SEQUENCE 1393 86:d=2 hl=2 l= 5 prim: OBJECT :des-cbc 1394 93:d=1 hl=2 l= 13 cons: SEQUENCE 1395 95:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc 1396 105:d=2 hl=2 l= 1 prim: INTEGER :28 1397 signatureAlgorithm: 1398 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1399 parameter: 1400 signature: 1401 0000 - 30 44 02 20 57 77 33 52-ed ee d4 ea 69 34 55 0D. Ww3R....i4U 1402 000f - e2 a8 7b 8b 09 8d ec ef-e5 0d db 0f f7 e3 91 ..{............ 1403 001e - e8 4f 79 76 20 8a 02 20-08 9c f3 65 46 7a 1a .Oyv .. ...eFz. 1404 002d - 49 e8 38 b5 1f 35 a6 2c-7a 15 8e 5f c9 99 bf I.8..5.,z.._... 1405 003c - 7d 8f bf b5 26 2a f5 af-ec 93 }...&*.... 1406 unsignedAttrs: 1407 1409 Figure 6: Signed Message without Imbedded Certificate 1411 A.3. Signed and Encrypted Message 1413 The following sections show details for the message signed by Bob and 1414 encrypted to Alice, as used in the examples in Section 10.3 and 1415 Section 10.4. 1417 A.3.1. Signed Message Prior to Encryption 1419 CMS_ContentInfo: 1420 contentType: pkcs7-signedData (1.2.840.113549.1.7.2) 1421 d.signedData: 1423 version: 1 1424 digestAlgorithms: 1425 algorithm: sha256 (2.16.840.1.101.3.4.2.1) 1426 parameter: 1427 encapContentInfo: 1428 eContentType: pkcs7-data (1.2.840.113549.1.7.1) 1429 eContent: 1430 0000 - 43 6f 6e 74 65 6e 74 2d-54 79 70 65 3a 20 74 Content-Type: t 1431 000f - 65 78 74 2f 70 6c 61 69-6e 0d 0a 0d 0a 57 61 ext/plain....Wa 1432 001e - 74 73 6f 6e 2c 20 63 6f-6d 65 20 68 65 72 65 tson, come here 1433 002d - 20 2d 20 49 20 77 61 6e-74 20 74 6f 20 73 65 - I want to se 1434 003c - 65 20 79 6f 75 2e 0d 0a- e you... 1435 certificates: 1436 d.certificate: 1437 cert_info: 1438 version: 2 1439 serialNumber: 11914627415941064473 1440 signature: 1441 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1442 parameter: 1443 issuer: O=example.org, CN=Bob 1444 validity: 1445 notBefore: Dec 20 23:07:49 2017 GMT 1446 notAfter: Dec 20 23:07:49 2018 GMT 1447 subject: O=example.org, CN=Bob 1448 key: 1449 algor: 1450 algorithm: id-ecPublicKey (1.2.840.10045.2.1) 1451 parameter: OBJECT:prime256v1 (1.2.840.10045.3.1.7) 1452 public_key: (0 unused bits) 1453 0000 - 04 86 4f ff fc 53 f1 a8-76 ca 69 b1 7e 27 ..O..S..v.i.~' 1454 000e - 48 7a 07 9c 71 52 ae 1b-13 7e 39 3b af 1a Hz..qR...~9;.. 1455 001c - ae bd 12 74 3c 7d 41 43-a2 fd 8a 37 0f 02 ...t<}AC...7.. 1456 002a - ba 9d 03 b7 30 1f 1d a6-4e 30 55 94 bb 6f ....0...N0U..o 1457 0038 - 95 cb 71 fa 48 b6 d0 a3-83 ..q.H.... 1458 issuerUID: 1459 subjectUID: 1460 extensions: 1461 object: X509v3 Subject Alternative Name (2.5.29.17) 1462 critical: TRUE 1463 value: 1464 0000 - 30 15 86 13 73 69 70 3a-62 6f 62 40 65 0...sip:bob@e 1465 000d - 78 61 6d 70 6c 65 2e 6f-72 67 xample.org 1466 sig_alg: 1467 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1468 parameter: 1469 signature: (0 unused bits) 1470 0000 - 30 45 02 21 00 b2 24 8c-92 40 28 22 38 9e c9 0E.!..$..@("8.. 1472 000f - 25 7f 64 cc fd 10 6f ba-0b 96 c1 19 07 30 34 %.d...o......04 1473 001e - d5 1b 10 2f 73 39 6c 02-20 15 8e b1 51 f0 85 .../s9l. ...Q.. 1474 002d - b9 bd 2e 04 cf 27 8f 0d-52 2e 6b b6 fe 4f 36 .....'..R.k..O6 1475 003c - f7 4c 77 10 b1 5a 4f 47-9d e4 0d .Lw..ZOG... 1476 crls: 1477 1478 signerInfos: 1479 version: 1 1480 d.issuerAndSerialNumber: 1481 issuer: O=example.org, CN=Bob 1482 serialNumber: 11914627415941064473 1483 digestAlgorithm: 1484 algorithm: sha256 (2.16.840.1.101.3.4.2.1) 1485 parameter: 1486 signedAttrs: 1487 object: contentType (1.2.840.113549.1.9.3) 1488 value.set: 1489 OBJECT:pkcs7-data (1.2.840.113549.1.7.1) 1491 object: signingTime (1.2.840.113549.1.9.5) 1492 value.set: 1493 UTCTIME:Dec 22 23:43:18 2017 GMT 1495 object: messageDigest (1.2.840.113549.1.9.4) 1496 value.set: 1497 OCTET STRING: 1498 0000 - ef 77 8f c9 40 d5 e6 dc-25 76 f4 7a 59 .w..@...%v.zY 1499 000d - 9b 31 26 19 5a 9f 1a 22-7a da f3 5f a2 .1&.Z.."z.._. 1500 001a - 2c 05 0d 8d 19 5a ,....Z 1502 object: S/MIME Capabilities (1.2.840.113549.1.9.15) 1503 value.set: 1504 SEQUENCE: 1505 0:d=0 hl=2 l= 106 cons: SEQUENCE 1506 2:d=1 hl=2 l= 11 cons: SEQUENCE 1507 4:d=2 hl=2 l= 9 prim: OBJECT :aes-256-cbc 1508 15:d=1 hl=2 l= 11 cons: SEQUENCE 1509 17:d=2 hl=2 l= 9 prim: OBJECT :aes-192-cbc 1510 28:d=1 hl=2 l= 11 cons: SEQUENCE 1511 30:d=2 hl=2 l= 9 prim: OBJECT :aes-128-cbc 1512 41:d=1 hl=2 l= 10 cons: SEQUENCE 1513 43:d=2 hl=2 l= 8 prim: OBJECT :des-ede3-cbc 1514 53:d=1 hl=2 l= 14 cons: SEQUENCE 1515 55:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc 1516 65:d=2 hl=2 l= 2 prim: INTEGER :80 1517 69:d=1 hl=2 l= 13 cons: SEQUENCE 1518 71:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc 1519 81:d=2 hl=2 l= 1 prim: INTEGER :40 1520 84:d=1 hl=2 l= 7 cons: SEQUENCE 1521 86:d=2 hl=2 l= 5 prim: OBJECT :des-cbc 1522 93:d=1 hl=2 l= 13 cons: SEQUENCE 1523 95:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc 1524 105:d=2 hl=2 l= 1 prim: INTEGER :28 1525 signatureAlgorithm: 1526 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1527 parameter: 1528 signature: 1529 0000 - 30 45 02 20 23 e1 e1 2f-c6 9c 7b c3 ae d0 67 0E. #../..{...g 1530 000f - 8a ab 25 71 16 dd 9a 82-7c 36 24 a2 fa e5 fa ..%q....|6$.... 1531 001e - 98 52 01 2b 98 c1 02 21-00 9b 8d 7c ad 9a f2 .R.+...!...|... 1532 002d - 09 e8 ac f7 00 aa a7 64-ef 32 d0 3a 47 16 42 .......d.2.:G.B 1533 003c - 79 04 54 90 53 e8 58 aa-6c 69 37 y.T.S.X.li7 1534 unsignedAttrs: 1535 1537 Figure 7: Message Signed by Bob prior to Encryption 1539 A.3.2. Encrypted Message 1541 CMS_ContentInfo: 1542 contentType: pkcs7-envelopedData (1.2.840.113549.1.7.3) 1543 d.envelopedData: 1544 version: 1545 originatorInfo: 1546 recipientInfos: 1547 d.ktri: 1548 version: 1549 d.issuerAndSerialNumber: 1550 issuer: O=example.com, CN=Alice 1551 serialNumber: 9508519069068149774 1552 keyEncryptionAlgorithm: 1553 algorithm: rsaEncryption (1.2.840.113549.1.1.1) 1554 parameter: NULL 1555 encryptedKey: 1556 0000 - bb ab 78 55 54 a4 8e 62-48 67 7b 5c 56 32 85 ..xUT..bHg{\V2. 1557 000f - 28 28 2e 17 2d 36 61 1d-c2 98 6a e1 68 fc 84 ((..-6a...j.h.. 1558 001e - d4 9f 41 20 ea 2c b8 95-d5 96 7f f3 5a 22 ed ..A .,......Z". 1559 002d - 2e 5f ee 4d 72 04 e7 0c-86 97 bf 13 8d 9f bd ._.Mr.......... 1560 003c - 84 85 c3 00 63 8f 9e f9-3e 61 46 5f 1e 14 05 ....c...>aF_... 1561 004b - fb 5b f7 b9 5f 2f af 12-e4 41 fb 8c fc df d5 .[.._/...A..... 1562 005a - cf 1d 88 d2 85 cf a9 fd-df 0d e3 f9 c9 5b 8c .............[. 1563 0069 - d7 50 77 29 24 c7 d9 19-c8 0a a8 67 7d c2 bc .Pw)$......g}.. 1564 0078 - 63 b5 ab e2 a0 4e 76 ee-0c 2e 6c 04 1e 08 fa c....Nv...l.... 1565 0087 - 29 47 6a 4a 76 85 19 44-ed d7 fa 79 ad a8 97 )GjJv..D...y... 1566 0096 - 09 10 7b f6 5d 56 ac 66-9b 78 1a 23 f0 fd 72 ..{.]V.f.x.#..r 1567 00a5 - 32 de 26 bb a0 7e 1d ca-69 f5 01 18 bd 49 55 2.&..~..i....IU 1568 00b4 - 46 3d 2c ad 40 3d c2 a6-74 92 09 df c0 2c 9e F=,.@=..t....,. 1569 00c3 - 14 52 70 d5 13 5c e5 54-8b bf 33 47 c6 f3 56 .Rp..\.T..3G..V 1570 00d2 - fa a0 93 fe ef db ba 5d-09 4f 4a 0e 23 a9 46 .......].OJ.#.F 1571 00e1 - 86 fc a7 7c fa 17 59 aa-a4 e2 77 48 22 7e 65 ...|..Y...wH"~e 1572 00f0 - 17 06 3f bb d7 a0 13 ab-cb 08 f9 50 b2 ac 91 ..?........P... 1573 00ff - 1b 72 b3 40 d5 7c 24 d0-8e 61 3f 4e 0a 08 78 .r.@.|$..a?N..x 1574 010e - 21 c8 20 23 8e 42 2e 85-bf 39 02 c9 9a 96 29 !. #.B...9....) 1575 011d - b0 86 29 45 e0 0d 1b 43-3f 6d c3 5e 8d 1c b5 ..)E...C?m.^... 1576 012c - 09 85 97 36 36 24 45 6d-d8 67 e6 13 2d 8e e9 ...66$Em.g..-.. 1577 013b - 35 cc 3b 41 24 df 6b ab-a8 87 70 70 8a f5 7c 5.;A$.k...pp..| 1578 014a - 9a d7 07 27 41 0d 6b f8-3e c0 e5 58 0e 26 c6 ...'A.k.>..X.&. 1579 0159 - 7f 90 60 8d 37 57 50 ed-93 89 02 56 bf 3f 71 ..`.7WP....V.?q 1580 0168 - 4f b6 76 ef fc f3 63 db-08 09 b0 21 e9 09 94 O.v...c....!... 1581 0177 - a4 37 35 3e e4 14 32 c7-cf 60 e4 8c bd 45 42 .75>..2..`...EB 1582 0186 - 0c 65 9e 75 90 6c ed e2-d4 4a 5b b6 19 01 4e .e.u.l...J[...N 1583 0195 - 73 a0 ba 2d 54 ab 3e db-e2 3c 63 fa d8 98 41 s..-T.>...:... 1586 01c2 - e7 74 1f 07 2c 1d 46 5e-a1 e6 c3 57 7b 2e 77 .t..,.F^...W{.w 1587 01d1 - ac d1 d1 15 2f 26 82 35-f8 5a e8 2f 50 87 1a ..../&.5.Z./P.. 1588 01e0 - cf 13 e3 8b 17 fd 69 f8-8f 97 3f 68 18 68 2c ......i...?h.h, 1589 01ef - 40 43 b4 ec 7d b1 7b 22-e2 0e e9 be cb f2 c9 @C..}.{"....... 1590 01fe - f8 93 .. 1591 encryptedContentInfo: 1592 contentType: pkcs7-data (1.2.840.113549.1.7.1) 1593 contentEncryptionAlgorithm: 1594 algorithm: aes-128-cbc (2.16.840.1.101.3.4.1.2) 1595 parameter: OCTET STRING: 1596 0000 - 4d 87 57 22 2e ac 52 94-11 7f 0c 12 d6 71 a1 M.W"..R......q. 1597 000f - 27 ' 1598 encryptedContent: 1599 0000 - 5d 40 77 a1 54 7c 5f 46-99 f0 75 31 a5 3e b8 ]@w.T|_F..u1.>. 1600 000f - 83 44 d1 a3 b2 29 ff 91-f3 f6 9c 0e 94 91 8c .D...)......... 1601 001e - 77 c9 f6 bd a1 94 e3 59-83 ef 9a 38 ed ca 15 w......Y...8... 1602 002d - 67 8e 65 bd 76 ce 66 5c-a6 e9 99 b3 a8 45 e4 g.e.v.f\.....E. 1603 003c - 26 66 aa 27 03 a5 a4 f0-d3 32 2d 6d e0 1e 64 &f.'.....2-m..d 1604 004b - 54 5c bc cf 09 e3 c2 26-8d fd 86 c3 36 11 6b T\.....&....6.k 1605 005a - 22 cc e8 00 98 61 92 42-fd 48 2e ce 2f cd 71 "....a.B.H../.q 1606 0069 - a7 c1 5f f7 7b f1 33 28-7d f0 ef 7c 51 71 3b .._.{.3(}..|Qq; 1607 0078 - dc 0f 6c da da 91 98 ea-8f d8 1a 9c 5a 50 c5 ..l.........ZP. 1608 0087 - e9 c0 95 8b 33 47 ef c4-25 03 8f b5 b7 76 ab ....3G..%....v. 1609 0096 - 46 98 26 22 7c 69 7a ec-c6 58 0d 0a 23 a9 9e F.&"|iz..X..#.. 1610 00a5 - 15 b8 05 ff 3b a1 55 c2-52 f5 e7 2b b9 db 13 ....;.U.R..+... 1611 00b4 - 3d 04 9d 99 2c 18 f4 f4-da d6 0a 18 da e7 29 =...,.........) 1612 00c3 - ba 7c 58 36 78 ff b8 60-4a 8f 7f e3 cc 62 d0 .|X6x..`J....b. 1613 00d2 - 63 2c c6 6e 1c 4f 9b a1-fa 9d f5 6c 6d 9f d8 c,.n.O.....lm.. 1614 00e1 - 1f 19 c8 8b a6 e9 71 0b-b0 bb b0 c5 fc f9 d2 ......q........ 1615 00f0 - d5 ea 04 d5 29 fd a7 8d-60 dc 48 7d 86 7c 0e ....)...`.H}.|. 1617 00ff - 39 21 74 e9 3c e2 c3 98-6c ea 7a ef 07 1e 5b 9!t.<...l.z...[ 1618 010e - 07 b6 46 c2 29 f9 06 9f-27 f3 74 94 56 da ea ..F.)...'.t.V.. 1619 011d - 0a 4e 56 bc 49 1c 9b e3-70 c5 44 39 9a 27 3d .NV.I...p.D9.'= 1620 012c - 50 c3 5f 16 0f b3 7e 5f-73 14 c3 d3 89 a8 05 P._...~_s...... 1621 013b - c8 e4 77 6f 0a 2a 89 f5-55 c9 fe 52 08 08 90 ..wo.*..U..R... 1622 014a - ab e2 e3 9d 2e d7 7a 2b-36 3d 1c 0f b3 75 79 ......z+6=...uy 1623 0159 - 00 28 e9 62 40 12 30 ae-93 aa 43 20 a5 da 2a .(.b@.0...C ..* 1624 0168 - d7 01 7c 59 95 08 f7 9c-3a 0c 35 f9 84 6e 8a ..|Y....:.5..n. 1625 0177 - 2c 41 0a 5e 0d 77 e9 07-c0 15 1c e5 13 e2 e8 ,A.^.w......... 1626 0186 - 99 de 92 ff 8d 17 77 96-23 8a de 93 09 d7 5c ......w.#.....\ 1627 0195 - 97 6e 97 16 ce d4 c4 5e-1a 33 92 13 d7 b0 82 .n.....^.3..... 1628 01a4 - 45 92 39 40 76 f7 4a 70-45 4c c4 65 65 f4 a8 E.9@v.JpEL.ee.. 1629 01b3 - 36 53 16 46 42 82 7b 2e-28 81 9a c3 78 1a fb 6S.FB.{.(...x.. 1630 01c2 - 52 9b 7c 72 30 8b 96 97-85 39 d7 89 d3 d2 7c R.|r0....9....| 1631 01d1 - b1 60 5b 1a 0c e9 66 e9-c6 cb 58 25 d2 35 e5 .`[...f...X%.5. 1632 01e0 - 23 a6 c2 d9 48 ef 93 14-c9 02 35 9a df 03 fe #...H.....5.... 1633 01ef - 46 84 22 1f af d1 f8 33-d7 59 c6 f2 55 9b 6e F."....3.Y..U.n 1634 01fe - 0a 88 97 d6 4e 42 b4 9e-ae 0e 39 df ac cc 94 ....NB....9.... 1635 020d - ef 3e 73 3f ca 22 12 eb-5c cb c7 c5 d7 f0 42 .>s?."..\.....B 1636 021c - d0 2b f4 12 d1 4c 7e de-0f 66 4d 79 9e a5 56 .+...L~..fMy..V 1637 022b - f9 76 3e 74 2c ac dd 3e-fc 88 22 bb e6 c8 1f .v>t,..>..".... 1638 023a - ea 27 de 6b 0b 06 44 82-52 f9 ad eb 66 67 b4 .'.k..D.R...fg. 1639 0249 - 60 56 f3 9b 42 f1 8f 4d-62 58 11 1f a2 43 b5 `V..B..MbX...C. 1640 0258 - c3 9f df 89 61 bc 6e 59-d8 bd 65 9d 46 f9 2a ....a.nY..e.F.* 1641 0267 - 8c ed 04 d1 a6 af 37 e5-c0 89 b5 47 a8 36 df ......7....G.6. 1642 0276 - 69 94 37 7c f9 2e 8e 74-62 55 69 df 6a 60 65 i.7|...tbUi.j`e 1643 0285 - f6 c9 3b ab ef 0d 07 cf-ac 7a f6 9d 8b f8 7c ..;......z....| 1644 0294 - 96 e6 eb ad 2e bd b5 53-f7 76 e6 91 43 e7 06 .......S.v..C.. 1645 02a3 - e2 27 06 1e 5e 3d 0e 38-a8 3a b9 c2 ce 62 10 .'..^=.8.:...b. 1646 02b2 - 2f 30 21 f7 d8 b9 e5 6a-d6 71 45 14 03 9f 48 /0!....j.qE...H 1647 02c1 - d7 fa b8 5e fb af ee 16-e1 5d 7a fd 81 48 cc ...^.....]z..H. 1648 02d0 - fc 9f b2 73 f8 bf d5 bd-eb d0 28 1a 50 09 5a ...s......(.P.Z 1649 02df - a1 92 c9 e8 7a 0f 2c 44-bb 57 de 5f 86 cf bd ....z.,D.W._... 1650 02ee - a3 33 7c d9 82 df ae 98-2a 80 87 98 78 64 6e .3|.....*...xdn 1651 02fd - 03 61 45 15 cf 94 15 04-79 d2 0e 3c e5 21 61 .aE.....y..<.!a 1652 030c - 7d da 22 d5 3a 58 29 26-55 64 fa 46 7e 7d b9 }.".:X)&Ud.F~}. 1653 031b - e2 5f 3d 25 5a 4f 9f 82-fd 95 14 ca 17 7a c8 ._=%ZO.......z. 1654 032a - 1b 88 2a cb e8 9d 1c c6-40 c7 b9 80 c5 a9 d5 ..*.....@...... 1655 0339 - f7 09 21 bb 6f bf 16 6d-38 aa 04 25 7e 08 c5 ..!.o..m8..%~.. 1656 0348 - 1b 2d f1 44 e9 33 63 e0-e4 7e 80 13 df 58 4b .-.D.3c..~...XK 1657 0357 - 3f 31 30 b4 df 7c 9a e1-77 09 f1 bf d8 de d1 ?10..|..w...... 1658 0366 - 38 57 41 d8 05 96 b7 b8-d6 a2 f2 e5 a2 f8 50 8WA...........P 1659 0375 - 29 ce 97 ef ed 2c 97 f9-42 f7 7b )....,..B.{ 1660 unprotectedAttrs: 1661 1663 Figure 8 1665 Authors' Addresses 1667 Ben Campbell 1668 Standard Velocity 1669 204 Touchdown Dr 1670 Irving, TX 75063 1671 US 1673 Email: ben@nostrum.com 1675 Russ Housley 1676 Vigil Security 1677 918 Spring Knoll Drive 1678 Herndon, VA 20170 1679 US 1681 Email: housley@vigilsec.com