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