idnits 2.17.1 draft-campbell-sip-messaging-smime-03.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 1569 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 (June 25, 2018) is 2132 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-04 -- 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 June 25, 2018 7 Expires: December 27, 2018 9 Securing Session Initiation Protocol (SIP) based Messaging with S/MIME 10 draft-campbell-sip-messaging-smime-03 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 December 27, 2018. 41 Copyright Notice 43 Copyright (c) 2018 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 . . . . . . . . . . 9 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 . . . . . . . . . 31 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 S/MIME 388 deployment. But since UAs can validate signatures even without local 389 certificates, the use case of organizations sending secure 390 notifications to their users becomes a sort of "low hanging fruit". 392 SIP and MSRP UAs advertise their level of support for S/MIME by 393 indicating their capability to receive the "application/pkcs7-mime" 394 media type. 396 The fact that a UA indicates support for the "multipart/signed" media 397 type does not necessarily imply support for S/MIME. The UA might 398 just be able to display clear-signed content without validating the 399 signature. UAs that wish to indicate the ability to validate 400 signatures for clear-signed messages MUST also indicate support for 401 "application/pkcs7-signature". 403 A UA can indicate that it can receive all smime-types by advertising 404 "application/pkcs7-mime" with no parameters. If a UA does not accept 405 all smime-types, it advertises the media type with the appropriate 406 parameters. If more than one are supported, the UA includes a 407 separate instance of the media-type string, appropriately 408 parameterized, for each. 410 For example, a UA that can only received signed-data would advertise 411 "application/pkcs7-mime; smime-type=signed-data". 413 SIP signaling can fork to multiple destinations for a given Address 414 of Record (AoR). A user might have multiple UAs with different 415 capabilities; the capabilities remembered from an interaction with 416 one such UA might not apply to another. 418 UAs can also advertise or discover S/MIME using out of band 419 mechanisms. Such mechanisms are beyond the scope of this document. 421 7. Using S/MIME with the SIP MESSAGE Method 423 The use of S/MIME with the SIP MESSAGE method is described in section 424 11.3 of [RFC3428], and for SIP in general in section 23 of [RFC3261]. 425 This section and its child sections offer clarifications for the use 426 of S/MIME with the SIP MESSAGE method, along with related updates to 427 RFC 3261 and RFC 3428. 429 7.1. Size Limit 431 SIP MESSAGE requests are typically limited to 1300 octets. That 432 limit applies to the entire message, including both SIP header fields 433 and the message content. This is due to the potential for 434 fragmentation of larger requests sent over UDP. In general, it is 435 hard to be sure that no proxy or other intermediary will forward a 436 SIP request over UDP somewhere along the path. Therefore, S/MIME 437 messages sent via SIP MESSAGE should be kept as small as possible. 438 Messages that will not fit within the limit can be sent using MSRP. 440 Section 23.2 of [RFC3261] says that a SignedData message must contain 441 a certificate to be used to validate the signature. In order to 442 reduce the message size, this document updates that to say that a 443 SignedData message sent in a SIP MESSAGE request SHOULD contain the 444 certificate, but MAY omit it if the sender has reason to believe that 445 the recipient already has the certificate in its keychain, or has 446 some other method of accessing the certificate. 448 7.2. User Agent Capabilities 450 SIP user agents (UA) can indicate support for S/MIME by including the 451 appropriate media type or types in the SIP Accept header field in a 452 response to an OPTIONS request, or in a 415 response to a SIP request 453 that contained an unsupported media type in the body. 455 UAs might be able to use the user agent capabilities framework 456 [RFC3840] to indicate support. However doing so would require the 457 registration of one or more media feature tags with IANA. 459 UAs MAY use other out-of-band methods to indicate their level of 460 support for S/MIME. 462 7.3. Failure Cases 464 Section 23.2 of [RFC3261] requires that the recipient of a SIP 465 request that includes a body part of an unsupported media type and a 466 Content-Disposition header "handling" parameter of "required" return 467 a 415 "Unsupported Media Type" response. Given that SIP MESSAGE 468 exists for no reason other than to deliver content in the body, it is 469 reasonable to treat the top-level body part as always required. 470 However [RFC3428] makes no such assertion. This document updates 471 section 11.3 [RFC3428] to add the statement that a UAC that receives 472 a SIP MESSAGE request with an unsupported media type MUST return a 473 415 Unsupported Media Type" response. 475 Section 23.2 of [RFC3261] says that if a recipient receives an S/MIME 476 body encrypted to the wrong certificate, it MUST return a SIP 493 477 (Undecipherable) response, and SHOULD send a valid certificate in 478 that response. This is not always possible in practice for SIP 479 MESSAGE requests. The User Agent Server (UAS) may choose not to 480 decrypt a message until the user is ready to read it. Messages may 481 be delivered to a message store, or sent via a store-and-forward 482 service. This document updates RFC 3261 to say that the UAS SHOULD 483 return a SIP 493 response if it immediately attempts to decrypt the 484 message and determines the message was encrypted to the wrong 485 certificate. However, it MAY return a 2XX class response if 486 decryption is deferred. 488 8. Using S/MIME with MSRP 490 MSRP has features that interact with the use of S/MIME. In 491 particular, the ability to send messages in chunks, the ability to 492 send messages of unknown size, and the use of SDP to indicate media- 493 type support create considerations for the use of S/MIME. 495 8.1. Chunking 497 MSRP allows a message to be broken into "chunks" for transmission. 498 In this context, the term "message" refers to an entire message that 499 one user might send to another. A chunk is a fragment of that 500 message sent in a single MSRP SEND request. All of the chunks that 501 make up a particular message share the same Message-ID value. 503 The sending user agent may break a message into chunks, which the 504 receiving user agent will reassemble to form the complete message. 505 Intermediaries such as MSRP Relays [RFC4976] might break chunks into 506 smaller chunks, or might reassemble chunks into larger ones; 507 therefore the message received by the recipient may be broken into a 508 different number of chunks than were sent by the recipient. 509 Intermediaries might also cause chunks to be received in a different 510 order than sent. 512 The sender MUST apply any S/MIME operations to the whole message 513 prior to breaking it into chunks. Likewise, the receiver needs to 514 reassemble the message from its chunks prior to decrypting, 515 validating a signature, etc. 517 MSRP chunks are framed using an end-line. The end-line comprises 518 seven hyphens, a 64-bit random value taken from the start line, and a 519 continuation flag. MRSP requires the sending user agent to scan data 520 sent in a specific chunk to be sent ensure that the end-line does not 521 accidentally occur as part of the sent data. This scanning occurs on 522 a chunk rather than a whole message, consequently it must occur after 523 the sender applies any S/MIME operations. 525 8.2. Streamed Data 527 MSRP allows a mode of operation where a UA sends some chunks of a 528 message prior to knowing the full length of the message. For 529 example, a sender might send streamed data over MSRP as a single 530 message, even though it doesn't know the full length of that data in 531 advance. This mode is incompatible with S/MIME, since a sending UA 532 must apply S/MIME operations to the entire message in advance of 533 breaking it into chunks. 535 Therefore, when sending a message in an S/MIME format, the sender 536 MUST include the Byte-Range header field for every chunk, including 537 the first chunk. The Byte-Range header field MUST include the total 538 length of the message. 540 A higher layer could choose to break such streamed data into a series 541 of messages prior to applying S/MIME operation, so that each fragment 542 appears as a distinct S/MIME separate message in MSRP. Such 543 mechanisms are beyond the scope for this document. 545 8.3. Indicating support for S/MIME 547 A UA that supports this specification MUST explicitly include the 548 appropriate media type or types in the "accept-types" attribute in 549 any SDP offer or answer that proposes MSRP. It MAY indicate that it 550 requires S/MIME wrappers for all messages by putting appropriate 551 S/MIME media types in the "accept-types" attribute and putting all 552 other supported media types in the "accept-wrapped-types" attribute. 554 For backwards compatibility, a sender MAY treat a peer that includes 555 an asterisk ("*") in the "accept-types" attribute as potentially 556 supporting S/MIME. If the peer returns an MSRP 415 response to an 557 attempt to send an S/MIME message, the sender should treat the peer 558 as not supporting S/MIME for the duration of the session, as 559 indicated in [RFC4975]. 561 While these SDP attributes allow an endpoint to express support for 562 certain media types only when wrapped in a specified envelope type, 563 it does not allow the expression of more complex structures. For 564 example, an endpoint can say that it supports text/plain and text/ 565 html, but only when inside an application/pkcs7 or message/cpim 566 container, but it cannot express a requirement for the leaf types to 567 always be contained in an application/pkcs7 container nested inside a 568 message/cpim container. This has implications for the use of s/mime 569 with the message/cpim format. (See Section 9.1.) 570 MSRP allows multiple reporting modes that provide different levels of 571 feedback. If the sender includes a Failure-Report header field with 572 a value of "no", it will not receive failure reports. This mode 573 should not be used carelessly, since such a sender would never see a 574 415 response as described above, and would have no way to learn that 575 the recipient could not process an S/MIME body. 577 8.4. MSRP URIs 579 MSRP URIs are ephemeral. Endpoints MUST NOT use MSRP URIs to 580 identify certificates, or insert MSRP URIs into certificate Subject 581 Alternative Name fields. When MSRP sessions are negotiated using SIP 582 [RFC3261], the SIP AoRs of the peers are used instead. 584 Note that MSRP allows messages to be sent between peers in either 585 direction. A given MSRP message might be sent from the SIP offerer 586 to the SIP answer. Thus, the the sender and recipient roles may 587 reverse between one message and another in a given session. 589 8.5. Failure Cases 591 Successful delivery of an S/MIME message does not indicate that the 592 recipient successfully decrypted the contents or validated a 593 signature. Decryption and/or validation may not occur immediately on 594 receipt, since since the recipient may not immediately view the 595 message, and the user agent may choose not to attempt decryption or 596 validation until the user requests it. 598 Likewise, successful delivery of S/MIME enveloped data does not, on 599 its own, indicate that the recipient supports the enclosed media 600 type. If the peer only implicitly indicated support for the enclosed 601 media type through the use of a wildcard in the "accept-types" or 602 "accept-wrapped types" SDP attributes, it may not decrypt the message 603 in time to send a 415 response. 605 9. S/MIME Interaction with other SIP Messaging Features 607 9.1. Common Profile for Instant Messaging 609 The Common Profile for Instant Messaging (CPIM) [RFC3860] defines an 610 abstract messaging service, with the goal of creating gateways 611 between different messaging protocols that could relay instant 612 messages without change. The SIP MESSAGE method and MSRP were 613 initially designed to map to the CPIM abstractions. However, at the 614 time of this writing, CPIM compliant gateways have not been deployed. 615 To the authors' knowledge, no other IM protocols have been explicitly 616 mapped to CPIM. 618 CPIM also defines the abstract messaging URI scheme "im:". As of the 619 time of this writing, the "im:" scheme is not in common use. 621 The Common Profile for Instant Messages Message Format [RFC3862] 622 allows UAs to attach transport-neutral metadata to arbitrary MIME 623 content. The format was designed as a canonicalization format to 624 allow signed data to cross protocol-converting gateways without loss 625 of metadata needed to verify the signature. While it has not 626 typically been used for that purpose, it has been used for other 627 metadata applications, for example, Intant Message Delivery 628 Notifications (IMDN)[RFC5438] and MSRP Multi-party Chat [RFC7701] 630 In the general case, a sender applies end-to-end signature and 631 encryption operations to the entire MIME body. However, some 632 messaging systems expect to inspect and in some cases add or modify 633 metadata in CPIM header fields. For example, CPM and RCS based 634 service include application servers that may need to insert time 635 stamps into chat messages, and may use additional metadata to 636 characterize the content and purpose of a message to determine 637 application behavior. The former will cause validation failure for 638 signatures that cover CPIM metadata, while the latter is not possible 639 if the metadata is encrypted. Clients intended for use in such 640 networks MAY choose to apply end-to-end signatures and encryption 641 operations to only the CPIM payload, leaving the CPIM metadata 642 unprotected from inspection and modification. UAs that support 643 S/MIME and CPIM SHOULD be able validate signatures and decrypt 644 enveloped data both when those operations are applied to the entire 645 CPIM body, and when they are applied to just the CPIM payload. 647 If such clients need to provide encrypt or sign CPIM metadata end-to- 648 end, they can nest a protected CPIM message format payload inside an 649 unprotected CPIM message envelope. 651 The use of CPIM metadata fields to identify certificates or to 652 authenticate SIP or MSRP header fields is out of scope for this 653 document. 655 9.2. Instant Message Delivery Notifications 657 The Instant Message Delivery Notification (IMDN) mechanism[RFC5438] 658 allows both endpoints and intermediary application servers to request 659 and to generate delivery notifications. The use of S/MIME does not 660 impact strictly end-to-end use of IMDN. IMDN recommends that devices 661 that are capable of doing so sign delivery notifications. It further 662 requires that delivery notifications that result from encrypted 663 messages also be encrypted. 665 However, IMDN allows intermediary application servers to insert 666 notification requests into messages, to add routing information to 667 messages, and to act on notification requests. It also allows list 668 servers to aggregate delivery notifications. 670 Such intermediaries will be unable to read end-to-end encrypted 671 messages in order to interpret delivery notice requests. 672 Intermediaries that insert information into end-to-end signed 673 messages will cause the signature validation to fail. (See 674 Section 9.1.) 676 10. Examples 678 The following sections show examples of S/MIME messages in SIP and 679 MSRP. The examples include the tags "[start-hex]" and "[end-hex]" to 680 denote binary content shown in hexadecimal. The tags are not part of 681 the actual message, and do not count towards the Content-Length 682 header field values. Some SIP header fields are folded to avoid over 683 running the margins. Folded lines contain leading white space at the 684 beginning of the line. These folds would not exist in the actual 685 message. 687 In all of these examples, the clear text message is the string 688 "Watson, come here - I want to see you." followed by a newline 689 character. 691 The cast of characters includes Alice, with a SIP AoR of 692 "alice@example.com", and Bob, with a SIP AoR of "bob@example.org". 694 Appendix A shows the detailed content of each S/MIME body. 696 10.1. Signed Message in SIP Including the Sender's Certificate 698 Figure 1 shows a message signed by Alice. This body uses the 699 "application/pcks7-mime" media type with a smime-type parameter value 700 of "signed-data". 702 The S/MIME body includes Alice's signing certificate. Even though 703 the original message content is fairly short and only minimal SIP 704 header fields are included, the total message size is 1300 octets. 705 This is the maximum allowed for the SIP MESSAGE method unless the UAC 706 has advance knowledge that no hop will use a transport protocol 707 without congestion control. 709 MESSAGE sip:bob@example.org SIP/2.0 710 Via: SIP/2.0/TCP alice-pc.example.com;branch=z9hG4bK776sgdkfie 711 Max-Forwards: 70 712 From: sip:alice@example.com;tag=49597 713 To: sip:bob@example.org 714 Call-ID: asd88asd66b@1.2.3.4 715 CSeq: 1 MESSAGE 716 Content-Transfer-Encoding: binary 717 Content-Type: application/pkcs7-mime; smime-type=signed-data; 718 name="smime.p7m" 719 Content-Disposition: attachment; filename="smime.p7m" 720 Content-Length: 890 722 [start-hex] 723 3082037606092a864886f70d010702a082036730820363020101310d300b 724 0609608648016503040201305306092a864886f70d010701a0460444436f 725 6e74656e742d547970653a20746578742f706c61696e0d0a0d0a57617473 726 6f6e2c20636f6d652068657265202d20492077616e7420746f2073656520 727 796f752e0d0aa082016f3082016b30820110a00302010202090090238790 728 1727648e300a06082a8648ce3d040302302631143012060355040a0c0b65 729 78616d706c652e636f6d310e300c06035504030c05416c696365301e170d 730 3137313232303232353433395a170d3138313232303232353433395a3026 731 31143012060355040a0c0b6578616d706c652e636f6d310e300c06035504 732 030c05416c6963653059301306072a8648ce3d020106082a8648ce3d0301 733 0703420004d87b54729f2c22feebd9ddba0efa40642297a6093887a4dae7 734 990b23f87fa7ed99db8cf5a314f2ee64106ef1ed61dbfc0a4b91c953cbd0 735 22a751b914807bb794a327302530230603551d110101ff04193017861573 736 69703a616c696365406578616d706c652e636f6d300a06082a8648ce3d04 737 03020349003046022100f16fe739ddf3a1ff072a78142395721f9c0629b5 738 8458644d855dad94da9b06f20221008ffda4ba4c65087584969bfb2002ba 739 f5eefebd693181b43666141f363990988431820185308201810201013033 740 302631143012060355040a0c0b6578616d706c652e636f6d310e300c0603 741 5504030c05416c696365020900902387901727648e300b06096086480165 742 03040201a081e4301806092a864886f70d010903310b06092a864886f70d 743 010701301c06092a864886f70d010905310f170d31373132323032323537 744 35315a302f06092a864886f70d01090431220420ef778fc940d5e6dc2576 745 f47a599b3126195a9f1a227adaf35fa22c050d8d195a307906092a864886 746 f70d01090f316c306a300b060960864801650304012a300b060960864801 747 6503040116300b0609608648016503040102300a06082a864886f70d0307 748 300e06082a864886f70d030202020080300d06082a864886f70d03020201 749 40300706052b0e030207300d06082a864886f70d0302020128300a06082a 750 8648ce3d0403020447304502200f37c8d68628ed5a52e1208bb091999901 751 02f1de5766a45d5b4627fe4d87c9cc022100f0de29c03e7d3fcc5329b77f 752 e31faa10b0003c8249cb011cbb14410d4c9bf93e 753 [end-hex] 755 Figure 1: Signed Message in SIP 757 10.2. Signed Message in SIP with No Certificate 759 Figure 2 shows the same message from Alice without the imbedded 760 certificate. The resulting total length of 928 octets is more 761 manageable. 763 MESSAGE sip:bob@example.org SIP/2.0 764 Via: SIP/2.0/TCP alice-pc.example.com;branch=z9hG4bK776sgdkfie 765 Max-Forwards: 70 766 From: sip:alice@example.com;tag=49597 767 To: sip:bob@example.org 768 Call-ID: asd88asd66b@1.2.3.4 769 CSeq: 1 MESSAGE 770 Content-Transfer-Encoding: binary 771 Content-Type: application/pkcs7-mime; smime-type=signed-data; 772 name="smime.p7m" 773 Content-Disposition: attachment; filename="smime.p7m" 774 Content-Length: 518 776 [start-hex] 777 3082020206092a864886f70d010702a08201f3308201ef020101310d300b 778 0609608648016503040201305306092a864886f70d010701a0460444436f 779 6e74656e742d547970653a20746578742f706c61696e0d0a0d0a57617473 780 6f6e2c20636f6d652068657265202d20492077616e7420746f2073656520 781 796f752e0d0a31820184308201800201013033302631143012060355040a 782 0c0b6578616d706c652e636f6d310e300c06035504030c05416c69636502 783 0900b8793ec0e4c21530300b0609608648016503040201a081e430180609 784 2a864886f70d010903310b06092a864886f70d010701301c06092a864886 785 f70d010905310f170d3137313232313032313230345a302f06092a864886 786 f70d01090431220420ef778fc940d5e6dc2576f47a599b3126195a9f1a22 787 7adaf35fa22c050d8d195a307906092a864886f70d01090f316c306a300b 788 060960864801650304012a300b0609608648016503040116300b06096086 789 48016503040102300a06082a864886f70d0307300e06082a864886f70d03 790 0202020080300d06082a864886f70d0302020140300706052b0e03020730 791 0d06082a864886f70d0302020128300a06082a8648ce3d04030204463044 792 022057773352edeed4ea693455e2a87b8b098decefe50ddb0ff7e391e84f 793 7976208a0220089cf365467a1a49e838b51f35a62c7a158e5fc999bf7d8f 794 bfb5262af5afec93 795 [end-hex] 797 Figure 2: Signed Message in SIP with No Certificate Included 799 10.3. MSRP Signed and Encrypted Message in a Single Chunk 801 Figure 3 shows a signed and encrypted message from Bob to Alice sent 802 via MSRP. 804 MSRP dsdfoe38sd SEND 805 To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp 806 From-Path: msrp://bobpc.example.org:8888/9di4eae923wzd;tcp 807 Message-ID: 456so39s 808 Byte-Range: 1-1567/1567 809 Content-Disposition: attachment; filename="smime.p7m" 810 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; 811 name="smime.p7m" 813 [start-hex] 814 3082061b06092a864886f70d010703a082060c308206080201003182024f 815 3082024b0201003033302631143012060355040a0c0b6578616d706c652e 816 636f6d310e300c06035504030c05416c69636502090083f50bb70bd5c40e 817 300d06092a864886f70d010101050004820200bbab785554a48e6248677b 818 5c56328528282e172d36611dc2986ae168fc84d49f4120ea2cb895d5967f 819 f35a22ed2e5fee4d7204e70c8697bf138d9fbd8485c300638f9ef93e6146 820 5f1e1405fb5bf7b95f2faf12e441fb8cfcdfd5cf1d88d285cfa9fddf0de3 821 f9c95b8cd750772924c7d919c80aa8677dc2bc63b5abe2a04e76ee0c2e6c 822 041e08fa29476a4a76851944edd7fa79ada89709107bf65d56ac669b781a 823 23f0fd7232de26bba07e1dca69f50118bd4955463d2cad403dc2a6749209 824 dfc02c9e145270d5135ce5548bbf3347c6f356faa093feefdbba5d094f4a 825 0e23a94686fca77cfa1759aaa4e27748227e6517063fbbd7a013abcb08f9 826 50b2ac911b72b340d57c24d08e613f4e0a087821c820238e422e85bf3902 827 c99a9629b0862945e00d1b433f6dc35e8d1cb5098597363624456dd867e6 828 132d8ee935cc3b4124df6baba88770708af57c9ad70727410d6bf83ec0e5 829 580e26c67f90608d375750ed93890256bf3f714fb676effcf363db0809b0 830 21e90994a437353ee41432c7cf60e48cbd45420c659e75906cede2d44a5b 831 b619014e73a0ba2d54ab3edbe23c63fad898411d1ac790552eadc66a358f 832 bd4461efec935d0b8bbc2e6cf23e863a1ee7a4e7741f072c1d465ea1e6c3 833 577b2e77acd1d1152f268235f85ae82f50871acf13e38b17fd69f88f973f 834 6818682c4043b4ec7db17b22e20ee9becbf2c9f893308203ae06092a8648 835 86f70d010701301d060960864801650304010204104d8757222eac529411 836 7f0c12d671a127808203805d4077a1547c5f4699f07531a53eb88344d1a3 837 b229ff91f3f69c0e94918c77c9f6bda194e35983ef9a38edca15678e65bd 838 76ce665ca6e999b3a845e42666aa2703a5a4f0d3322d6de01e64545cbccf 839 09e3c2268dfd86c336116b22cce80098619242fd482ece2fcd71a7c15ff7 840 7bf133287df0ef7c51713bdc0f6cdada9198ea8fd81a9c5a50c5e9c0958b 841 3347efc425038fb5b776ab469826227c697aecc6580d0a23a99e15b805ff 842 3ba155c252f5e72bb9db133d049d992c18f4f4dad60a18dae729ba7c5836 843 78ffb8604a8f7fe3cc62d0632cc66e1c4f9ba1fa9df56c6d9fd81f19c88b 844 a6e9710bb0bbb0c5fcf9d2d5ea04d529fda78d60dc487d867c0e392174e9 845 3ce2c3986cea7aef071e5b07b646c229f9069f27f3749456daea0a4e56bc 846 491c9be370c544399a273d50c35f160fb37e5f7314c3d389a805c8e4776f 847 0a2a89f555c9fe52080890abe2e39d2ed77a2b363d1c0fb375790028e962 848 401230ae93aa4320a5da2ad7017c599508f79c3a0c35f9846e8a2c410a5e 849 0d77e907c0151ce513e2e899de92ff8d177796238ade9309d75c976e9716 850 ced4c45e1a339213d7b0824592394076f74a70454cc46565f4a836531646 851 42827b2e28819ac3781afb529b7c72308b96978539d789d3d27cb1605b1a 852 0ce966e9c6cb5825d235e523a6c2d948ef9314c902359adf03fe4684221f 853 afd1f833d759c6f2559b6e0a8897d64e42b49eae0e39dfaccc94ef3e733f 854 ca2212eb5ccbc7c5d7f042d02bf412d14c7ede0f664d799ea556f9763e74 855 2cacdd3efc8822bbe6c81fea27de6b0b06448252f9adeb6667b46056f39b 856 42f18f4d6258111fa243b5c39fdf8961bc6e59d8bd659d46f92a8ced04d1 857 a6af37e5c089b547a836df6994377cf92e8e74625569df6a6065f6c93bab 858 ef0d07cfac7af69d8bf87c96e6ebad2ebdb553f776e69143e706e227061e 859 5e3d0e38a83ab9c2ce62102f3021f7d8b9e56ad6714514039f48d7fab85e 860 fbafee16e15d7afd8148ccfc9fb273f8bfd5bdebd0281a50095aa192c9e8 861 7a0f2c44bb57de5f86cfbda3337cd982dfae982a80879878646e03614515 862 cf94150479d20e3ce521617dda22d53a5829265564fa467e7db9e25f3d25 863 5a4f9f82fd9514ca177ac81b882acbe89d1cc640c7b980c5a9d5f70921bb 864 6fbf166d38aa04257e08c51b2df144e93363e0e47e8013df584b3f3130b4 865 df7c9ae17709f1bfd8ded1385741d80596b7b8d6a2f2e5a2f85029ce97ef 866 ed2c97f942f77b 867 [end-hex] 868 -------dsdfoe38sd$ 870 Figure 3: Signed and Encrypted Message in MSRP 872 10.4. MSRP Signed and Encrypted Message sent in Multiple Chunks 874 Figure 4 shows the same message as in Figure 3 except that the 875 message is broken into two chunks. The S/MIME operations were 876 performed prior to breaking the message into chunks. 878 MSRP d93kswow SEND 879 To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp 880 From-Path: msrp://bobpc.example.org:8888/9di4eae923wzd;tcp 881 Message-ID: 12339sdqwer 882 Byte-Range: 1-780/1567 883 Content-Disposition: attachment; filename="smime.p7m" 884 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; 885 name="smime.p7m" 887 [start-hex] 888 3082061b06092a864886f70d010703a082060c308206080201003182024f 889 3082024b0201003033302631143012060355040a0c0b6578616d706c652e 890 636f6d310e300c06035504030c05416c69636502090083f50bb70bd5c40e 891 300d06092a864886f70d010101050004820200bbab785554a48e6248677b 892 5c56328528282e172d36611dc2986ae168fc84d49f4120ea2cb895d5967f 893 f35a22ed2e5fee4d7204e70c8697bf138d9fbd8485c300638f9ef93e6146 894 5f1e1405fb5bf7b95f2faf12e441fb8cfcdfd5cf1d88d285cfa9fddf0de3 895 f9c95b8cd750772924c7d919c80aa8677dc2bc63b5abe2a04e76ee0c2e6c 896 041e08fa29476a4a76851944edd7fa79ada89709107bf65d56ac669b781a 897 23f0fd7232de26bba07e1dca69f50118bd4955463d2cad403dc2a6749209 898 dfc02c9e145270d5135ce5548bbf3347c6f356faa093feefdbba5d094f4a 899 0e23a94686fca77cfa1759aaa4e27748227e6517063fbbd7a013abcb08f9 900 50b2ac911b72b340d57c24d08e613f4e0a087821c820238e422e85bf3902 901 c99a9629b0862945e00d1b433f6dc35e8d1cb5098597363624456dd867e6 902 132d8ee935cc3b4124df6baba88770708af57c9ad70727410d6bf83ec0e5 903 580e26c67f90608d375750ed93890256bf3f714fb676effcf363db0809b0 904 21e90994a437353ee41432c7cf60e48cbd45420c659e75906cede2d44a5b 905 b619014e73a0ba2d54ab3edbe23c63fad898411d1ac790552eadc66a358f 906 bd4461efec935d0b8bbc2e6cf23e863a1ee7a4e7741f072c1d465ea1e6c3 907 577b2e77acd1d1152f268235f85ae82f50871acf13e38b17fd69f88f973f 908 6818682c4043b4ec7db17b22e20ee9becbf2c9f893308203ae06092a8648 909 86f70d010701301d060960864801650304010204104d8757222eac529411 910 7f0c12d671a127808203805d4077a1547c5f4699f07531a53eb88344d1a3 911 b229ff91f3f69c0e94918c77c9f6bda194e35983ef9a38edca15678e65bd 912 76ce665ca6e999b3a845e42666aa2703a5a4f0d3322d6de01e64545cbccf 913 09e3c2268dfd86c336116b22cce80098619242fd482ece2fcd71a7c15ff7 914 [end-hex] 915 -------d93kswow+ 917 MSRP op2nc9a SEND 918 To-Path: msrp://alicepc.example.com:8888/9di4eae923wzd;tcp 919 From-Path: msrp://bobpc.example.org:7654/iau39soe2843z;tcp 920 Message-ID: 12339sdqwer 921 Byte-Range: 781-1567/1567 922 Content-Disposition: attachment; filename="smime.p7m" 923 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; 924 name="smime.p7m" 926 [start-hex] 927 7bf133287df0ef7c51713bdc0f6cdada9198ea8fd81a9c5a50c5e9c0958b 928 3347efc425038fb5b776ab469826227c697aecc6580d0a23a99e15b805ff 929 3ba155c252f5e72bb9db133d049d992c18f4f4dad60a18dae729ba7c5836 930 78ffb8604a8f7fe3cc62d0632cc66e1c4f9ba1fa9df56c6d9fd81f19c88b 931 a6e9710bb0bbb0c5fcf9d2d5ea04d529fda78d60dc487d867c0e392174e9 932 3ce2c3986cea7aef071e5b07b646c229f9069f27f3749456daea0a4e56bc 933 491c9be370c544399a273d50c35f160fb37e5f7314c3d389a805c8e4776f 934 0a2a89f555c9fe52080890abe2e39d2ed77a2b363d1c0fb375790028e962 935 401230ae93aa4320a5da2ad7017c599508f79c3a0c35f9846e8a2c410a5e 936 0d77e907c0151ce513e2e899de92ff8d177796238ade9309d75c976e9716 937 ced4c45e1a339213d7b0824592394076f74a70454cc46565f4a836531646 938 42827b2e28819ac3781afb529b7c72308b96978539d789d3d27cb1605b1a 939 0ce966e9c6cb5825d235e523a6c2d948ef9314c902359adf03fe4684221f 940 afd1f833d759c6f2559b6e0a8897d64e42b49eae0e39dfaccc94ef3e733f 941 ca2212eb5ccbc7c5d7f042d02bf412d14c7ede0f664d799ea556f9763e74 942 2cacdd3efc8822bbe6c81fea27de6b0b06448252f9adeb6667b46056f39b 943 42f18f4d6258111fa243b5c39fdf8961bc6e59d8bd659d46f92a8ced04d1 944 a6af37e5c089b547a836df6994377cf92e8e74625569df6a6065f6c93bab 945 ef0d07cfac7af69d8bf87c96e6ebad2ebdb553f776e69143e706e227061e 946 5e3d0e38a83ab9c2ce62102f3021f7d8b9e56ad6714514039f48d7fab85e 947 fbafee16e15d7afd8148ccfc9fb273f8bfd5bdebd0281a50095aa192c9e8 948 7a0f2c44bb57de5f86cfbda3337cd982dfae982a80879878646e03614515 949 cf94150479d20e3ce521617dda22d53a5829265564fa467e7db9e25f3d25 950 5a4f9f82fd9514ca177ac81b882acbe89d1cc640c7b980c5a9d5f70921bb 951 6fbf166d38aa04257e08c51b2df144e93363e0e47e8013df584b3f3130b4 952 df7c9ae17709f1bfd8ded1385741d80596b7b8d6a2f2e5a2f85029ce97ef 953 ed2c97f942f77b 954 [end-hex] 955 -------op2nc9a$ 957 Figure 4: MSRP Chunked Signed and Encrypted Message 959 11. IANA Considerations 961 This document makes no requests of the IANA. 963 12. Security Considerations 965 The security considerations from S/MIME [RFC5750][RFC5751] and 966 elliptic curves in CMS [RFC5753] apply. The S/MIME related security 967 considerations from SIP [RFC3261][RFC3853], SIP MESSAGE [RFC3428], 968 and MSRP [RFC4975] apply. 970 The security considerations from algorithms recommended in this 971 document also apply, see [RFC3565], [RFC5480], [RFC5753], [RFC5754], 972 [RFC7748], [RFC8032], [I-D.ietf-curdle-cms-eddsa-signatures], and 973 [I-D.ietf-curdle-cms-ecdh-new-curves]. 975 This document assumes that end-entity certificate validation is 976 provided by a chain of trust to a certification authority (CA), using 977 a public key infrastructure. The security considerations from 978 [RFC5280] apply. However, other validations methods may be possible; 979 for example sending a signed fingerprint for the end-entity in SDP. 980 The relationship of this work and the techniques discussed in 981 [RFC4474], [I-D.ietf-stir-rfc4474bis], and 982 [I-D.ietf-sipbrandy-rtpsec] are out of scope for this document. 984 When matching an end-entity certificate to the sender or recipient 985 identity, the respective SIP AoRs are used. Typically these will 986 match the SIP From and To header fields. Some UAs may extract sender 987 identity from SIP AoRs in other header fields, for example, P- 988 Asserted-Identity [RFC3325]. In general, the UAS should compare the 989 certificate to the identity that it relies upon, for example for 990 display to the end-user or comparison to white lists and blacklists. 992 The secure notification use case discussed in Section 1 has 993 significant vulnerabilities when used in an insecure environment. 994 For example, "phishing" messages could be used to trick users into 995 revealing credentials. Eavesdroppers could learn confirmation codes 996 from unprotected two-factor authentication messages. Unsolicited 997 messages sent by impersonators could tarnish the reputation of an 998 organization. While hop-by-hop protection can mitigate some of those 999 risks, it still leaves messages vulnerabile to malicious or 1000 compromised intermediaries. 1002 Mobile messaging is typically an online application; online 1003 certificate revocation checks should usually be feasible. 1005 Certain messaging services, for example those based on CPM and RCS, 1006 may include intermediaries that attach metadata to user generated 1007 messages. In certain cases this metadata may reveal information to 1008 third parties that would have otherwise been encrypted. Implementors 1009 and operators should consider whether this metadata may create 1010 privacy leaks. Such an analysis is beyond the scope of this 1011 document. 1013 13. References 1015 13.1. Normative References 1017 [I-D.ietf-curdle-cms-ecdh-new-curves] 1018 Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key 1019 Agreement Algorithm with X25519 and X448 in the 1020 Cryptographic Message Syntax (CMS)", draft-ietf-curdle- 1021 cms-ecdh-new-curves-10 (work in progress), August 2017. 1023 [I-D.ietf-curdle-cms-eddsa-signatures] 1024 Housley, R., "Use of EdDSA Signatures in the Cryptographic 1025 Message Syntax (CMS)", draft-ietf-curdle-cms-eddsa- 1026 signatures-08 (work in progress), October 2017. 1028 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1029 Requirement Levels", BCP 14, RFC 2119, 1030 DOI 10.17487/RFC2119, March 1997, 1031 . 1033 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1034 A., Peterson, J., Sparks, R., Handley, M., and E. 1035 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1036 DOI 10.17487/RFC3261, June 2002, 1037 . 1039 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1040 with Session Description Protocol (SDP)", RFC 3264, 1041 DOI 10.17487/RFC3264, June 2002, 1042 . 1044 [RFC3428] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., 1045 Huitema, C., and D. Gurle, "Session Initiation Protocol 1046 (SIP) Extension for Instant Messaging", RFC 3428, 1047 DOI 10.17487/RFC3428, December 2002, 1048 . 1050 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) 1051 Encryption Algorithm in Cryptographic Message Syntax 1052 (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003, 1053 . 1055 [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) 1056 Requirement for the Session Initiation Protocol (SIP)", 1057 RFC 3853, DOI 10.17487/RFC3853, July 2004, 1058 . 1060 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1061 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1062 July 2006, . 1064 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 1065 "The Message Session Relay Protocol (MSRP)", RFC 4975, 1066 DOI 10.17487/RFC4975, September 2007, 1067 . 1069 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1070 Housley, R., and W. Polk, "Internet X.509 Public Key 1071 Infrastructure Certificate and Certificate Revocation List 1072 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1073 . 1075 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 1076 "Elliptic Curve Cryptography Subject Public Key 1077 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 1078 . 1080 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1081 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1082 . 1084 [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1085 Mail Extensions (S/MIME) Version 3.2 Certificate 1086 Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010, 1087 . 1089 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1090 Mail Extensions (S/MIME) Version 3.2 Message 1091 Specification", RFC 5751, DOI 10.17487/RFC5751, January 1092 2010, . 1094 [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve 1095 Cryptography (ECC) Algorithms in Cryptographic Message 1096 Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January 1097 2010, . 1099 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 1100 Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 1101 2010, . 1103 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1104 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1105 May 2017, . 1107 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 1108 One (ASN.1): Specification of basic notation", 1109 ITU-T Recommendation X.680, 2015. 1111 [X690] ITU-T, "Information Technology -- ASN.1 encoding rules: 1112 Specification of Basic Encoding Rules (BER), Canonical 1113 Encoding Rules (CER) and Distinguished Encoding Rules 1114 (DER)", ITU-T Recommendation X.690, 2015. 1116 13.2. Informative References 1118 [CPM] Open Mobile Alliance, "OMA Converged IP Messaging System 1119 Description, Candidate Version 2.2", September 2017. 1121 [I-D.ietf-sipbrandy-rtpsec] 1122 Peterson, J., Rescorla, E., Barnes, R., and R. Housley, 1123 "Best Practices for Securing RTP Media Signaled with SIP", 1124 draft-ietf-sipbrandy-rtpsec-04 (work in progress), May 1125 2018. 1127 [I-D.ietf-stir-rfc4474bis] 1128 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 1129 "Authenticated Identity Management in the Session 1130 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 1131 (work in progress), February 2017. 1133 [RCS] GSMA, "RCS Universal Profile Service Definition Document, 1134 Version 2.0", June 2017. 1136 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1137 Extensions to the Session Initiation Protocol (SIP) for 1138 Asserted Identity within Trusted Networks", RFC 3325, 1139 DOI 10.17487/RFC3325, November 2002, 1140 . 1142 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1143 "Indicating User Agent Capabilities in the Session 1144 Initiation Protocol (SIP)", RFC 3840, 1145 DOI 10.17487/RFC3840, August 2004, 1146 . 1148 [RFC3860] Peterson, J., "Common Profile for Instant Messaging 1149 (CPIM)", RFC 3860, DOI 10.17487/RFC3860, August 2004, 1150 . 1152 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 1153 Messaging (CPIM): Message Format", RFC 3862, 1154 DOI 10.17487/RFC3862, August 2004, 1155 . 1157 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1158 Authenticated Identity Management in the Session 1159 Initiation Protocol (SIP)", RFC 4474, 1160 DOI 10.17487/RFC4474, August 2006, 1161 . 1163 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1164 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1165 . 1167 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 1168 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 1169 DOI 10.17487/RFC4976, September 2007, 1170 . 1172 [RFC5438] Burger, E. and H. Khartabil, "Instant Message Disposition 1173 Notification (IMDN)", RFC 5438, DOI 10.17487/RFC5438, 1174 February 2009, . 1176 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 1177 Protocol (XMPP): Instant Messaging and Presence", 1178 RFC 6121, DOI 10.17487/RFC6121, March 2011, 1179 . 1181 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1182 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 1183 2015, . 1185 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 1186 RFC 7516, DOI 10.17487/RFC7516, May 2015, 1187 . 1189 [RFC7701] Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi- 1190 party Chat Using the Message Session Relay Protocol 1191 (MSRP)", RFC 7701, DOI 10.17487/RFC7701, December 2015, 1192 . 1194 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1195 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1196 2016, . 1198 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1199 Signature Algorithm (EdDSA)", RFC 8032, 1200 DOI 10.17487/RFC8032, January 2017, 1201 . 1203 Appendix A. Message Details 1205 The following section shows the detailed content of the S/MIME bodies 1206 used in Section 10. 1208 A.1. Signed Message 1210 Figure 5 shows the details of the message signed by Alice used in the 1211 example in Section 10.1. 1213 CMS_ContentInfo: 1214 contentType: pkcs7-signedData (1.2.840.113549.1.7.2) 1215 d.signedData: 1216 version: 1 1217 digestAlgorithms: 1218 algorithm: sha256 (2.16.840.1.101.3.4.2.1) 1219 parameter: 1220 encapContentInfo: 1221 eContentType: pkcs7-data (1.2.840.113549.1.7.1) 1222 eContent: 1223 0000 - 43 6f 6e 74 65 6e 74 2d-54 79 70 65 3a 20 74 Content-Type: t 1224 000f - 65 78 74 2f 70 6c 61 69-6e 0d 0a 0d 0a 57 61 ext/plain....Wa 1225 001e - 74 73 6f 6e 2c 20 63 6f-6d 65 20 68 65 72 65 tson, come here 1226 002d - 20 2d 20 49 20 77 61 6e-74 20 74 6f 20 73 65 - I want to se 1227 003c - 65 20 79 6f 75 2e 0d 0a- e you... 1228 certificates: 1229 d.certificate: 1230 cert_info: 1231 version: 2 1232 serialNumber: 10386294218579993742 1233 signature: 1234 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1235 parameter: 1236 issuer: O=example.com, CN=Alice 1237 validity: 1238 notBefore: Dec 20 22:54:39 2017 GMT 1239 notAfter: Dec 20 22:54:39 2018 GMT 1240 subject: O=example.com, CN=Alice 1241 key: 1242 algor: 1243 algorithm: id-ecPublicKey (1.2.840.10045.2.1) 1244 parameter: OBJECT:prime256v1 (1.2.840.10045.3.1.7) 1245 public_key: (0 unused bits) 1246 0000 - 04 d8 7b 54 72 9f 2c 22-fe eb d9 dd ba 0e ..{Tr.,"...... 1247 000e - fa 40 64 22 97 a6 09 38-87 a4 da e7 99 0b .@d"...8...... 1248 001c - 23 f8 7f a7 ed 99 db 8c-f5 a3 14 f2 ee 64 #............d 1249 002a - 10 6e f1 ed 61 db fc 0a-4b 91 c9 53 cb d0 .n..a...K..S.. 1250 0038 - 22 a7 51 b9 14 80 7b b7-94 ".Q...{.. 1251 issuerUID: 1252 subjectUID: 1253 extensions: 1254 object: X509v3 Subject Alternative Name (2.5.29.17) 1255 critical: TRUE 1256 value: 1257 0000 - 30 17 86 15 73 69 70 3a-61 6c 69 63 65 0...sip:alice 1258 000d - 40 65 78 61 6d 70 6c 65-2e 63 6f 6d @example.com 1259 sig_alg: 1260 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1261 parameter: 1262 signature: (0 unused bits) 1263 0000 - 30 46 02 21 00 f1 6f e7-39 dd f3 a1 ff 07 2a 0F.!..o.9.....* 1264 000f - 78 14 23 95 72 1f 9c 06-29 b5 84 58 64 4d 85 x.#.r...)..XdM. 1265 001e - 5d ad 94 da 9b 06 f2 02-21 00 8f fd a4 ba 4c ].......!.....L 1266 002d - 65 08 75 84 96 9b fb 20-02 ba f5 ee fe bd 69 e.u.... ......i 1267 003c - 31 81 b4 36 66 14 1f 36-39 90 98 84 1..6f..69... 1268 crls: 1269 1270 signerInfos: 1271 version: 1 1272 d.issuerAndSerialNumber: 1273 issuer: O=example.com, CN=Alice 1274 serialNumber: 10386294218579993742 1275 digestAlgorithm: 1276 algorithm: sha256 (2.16.840.1.101.3.4.2.1) 1277 parameter: 1278 signedAttrs: 1279 object: contentType (1.2.840.113549.1.9.3) 1280 value.set: 1282 OBJECT:pkcs7-data (1.2.840.113549.1.7.1) 1284 object: signingTime (1.2.840.113549.1.9.5) 1285 value.set: 1286 UTCTIME:Dec 20 22:57:51 2017 GMT 1288 object: messageDigest (1.2.840.113549.1.9.4) 1289 value.set: 1290 OCTET STRING: 1291 0000 - ef 77 8f c9 40 d5 e6 dc-25 76 f4 7a 59 .w..@...%v.zY 1292 000d - 9b 31 26 19 5a 9f 1a 22-7a da f3 5f a2 .1&.Z.."z.._. 1293 001a - 2c 05 0d 8d 19 5a ,....Z 1295 object: S/MIME Capabilities (1.2.840.113549.1.9.15) 1296 value.set: 1297 SEQUENCE: 1298 0:d=0 hl=2 l= 106 cons: SEQUENCE 1299 2:d=1 hl=2 l= 11 cons: SEQUENCE 1300 4:d=2 hl=2 l= 9 prim: OBJECT :aes-256-cbc 1301 15:d=1 hl=2 l= 11 cons: SEQUENCE 1302 17:d=2 hl=2 l= 9 prim: OBJECT :aes-192-cbc 1303 28:d=1 hl=2 l= 11 cons: SEQUENCE 1304 30:d=2 hl=2 l= 9 prim: OBJECT :aes-128-cbc 1305 41:d=1 hl=2 l= 10 cons: SEQUENCE 1306 43:d=2 hl=2 l= 8 prim: OBJECT :des-ede3-cbc 1307 53:d=1 hl=2 l= 14 cons: SEQUENCE 1308 55:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc 1309 65:d=2 hl=2 l= 2 prim: INTEGER :80 1310 69:d=1 hl=2 l= 13 cons: SEQUENCE 1311 71:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc 1312 81:d=2 hl=2 l= 1 prim: INTEGER :40 1313 84:d=1 hl=2 l= 7 cons: SEQUENCE 1314 86:d=2 hl=2 l= 5 prim: OBJECT :des-cbc 1315 93:d=1 hl=2 l= 13 cons: SEQUENCE 1316 95:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc 1317 105:d=2 hl=2 l= 1 prim: INTEGER :28 1318 signatureAlgorithm: 1319 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1320 parameter: 1321 signature: 1322 0000 - 30 45 02 20 0f 37 c8 d6-86 28 ed 5a 52 e1 20 0E. .7...(.ZR. 1323 000f - 8b b0 91 99 99 01 02 f1-de 57 66 a4 5d 5b 46 .........Wf.][F 1324 001e - 27 fe 4d 87 c9 cc 02 21-00 f0 de 29 c0 3e 7d '.M....!...).>} 1325 002d - 3f cc 53 29 b7 7f e3 1f-aa 10 b0 00 3c 82 49 ?.S)........<.I 1326 003c - cb 01 1c bb 14 41 0d 4c-9b f9 3e .....A.L..> 1327 unsignedAttrs: 1328 1329 Figure 5: Signed Message 1331 A.2. Short Signed Message 1333 Figure 6 shows the message signed by Alice with no imbedded 1334 certificate, as used in the example in Section 10.2. 1336 CMS_ContentInfo: 1337 contentType: pkcs7-signedData (1.2.840.113549.1.7.2) 1338 d.signedData: 1339 version: 1 1340 digestAlgorithms: 1341 algorithm: sha256 (2.16.840.1.101.3.4.2.1) 1342 parameter: 1343 encapContentInfo: 1344 eContentType: pkcs7-data (1.2.840.113549.1.7.1) 1345 eContent: 1346 0000 - 43 6f 6e 74 65 6e 74 2d-54 79 70 65 3a 20 74 Content-Type: t 1347 000f - 65 78 74 2f 70 6c 61 69-6e 0d 0a 0d 0a 57 61 ext/plain....Wa 1348 001e - 74 73 6f 6e 2c 20 63 6f-6d 65 20 68 65 72 65 tson, come here 1349 002d - 20 2d 20 49 20 77 61 6e-74 20 74 6f 20 73 65 - I want to se 1350 003c - 65 20 79 6f 75 2e 0d 0a- e you... 1351 certificates: 1352 1353 crls: 1354 1355 signerInfos: 1356 version: 1 1357 d.issuerAndSerialNumber: 1358 issuer: O=example.com, CN=Alice 1359 serialNumber: 13292724773353297200 1360 digestAlgorithm: 1361 algorithm: sha256 (2.16.840.1.101.3.4.2.1) 1362 parameter: 1363 signedAttrs: 1364 object: contentType (1.2.840.113549.1.9.3) 1365 value.set: 1366 OBJECT:pkcs7-data (1.2.840.113549.1.7.1) 1368 object: signingTime (1.2.840.113549.1.9.5) 1369 value.set: 1370 UTCTIME:Dec 21 02:12:04 2017 GMT 1372 object: messageDigest (1.2.840.113549.1.9.4) 1373 value.set: 1374 OCTET STRING: 1375 0000 - ef 77 8f c9 40 d5 e6 dc-25 76 f4 7a 59 .w..@...%v.zY 1376 000d - 9b 31 26 19 5a 9f 1a 22-7a da f3 5f a2 .1&.Z.."z.._. 1378 001a - 2c 05 0d 8d 19 5a ,....Z 1380 object: S/MIME Capabilities (1.2.840.113549.1.9.15) 1381 value.set: 1382 SEQUENCE: 1383 0:d=0 hl=2 l= 106 cons: SEQUENCE 1384 2:d=1 hl=2 l= 11 cons: SEQUENCE 1385 4:d=2 hl=2 l= 9 prim: OBJECT :aes-256-cbc 1386 15:d=1 hl=2 l= 11 cons: SEQUENCE 1387 17:d=2 hl=2 l= 9 prim: OBJECT :aes-192-cbc 1388 28:d=1 hl=2 l= 11 cons: SEQUENCE 1389 30:d=2 hl=2 l= 9 prim: OBJECT :aes-128-cbc 1390 41:d=1 hl=2 l= 10 cons: SEQUENCE 1391 43:d=2 hl=2 l= 8 prim: OBJECT :des-ede3-cbc 1392 53:d=1 hl=2 l= 14 cons: SEQUENCE 1393 55:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc 1394 65:d=2 hl=2 l= 2 prim: INTEGER :80 1395 69:d=1 hl=2 l= 13 cons: SEQUENCE 1396 71:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc 1397 81:d=2 hl=2 l= 1 prim: INTEGER :40 1398 84:d=1 hl=2 l= 7 cons: SEQUENCE 1399 86:d=2 hl=2 l= 5 prim: OBJECT :des-cbc 1400 93:d=1 hl=2 l= 13 cons: SEQUENCE 1401 95:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc 1402 105:d=2 hl=2 l= 1 prim: INTEGER :28 1403 signatureAlgorithm: 1404 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1405 parameter: 1406 signature: 1407 0000 - 30 44 02 20 57 77 33 52-ed ee d4 ea 69 34 55 0D. Ww3R....i4U 1408 000f - e2 a8 7b 8b 09 8d ec ef-e5 0d db 0f f7 e3 91 ..{............ 1409 001e - e8 4f 79 76 20 8a 02 20-08 9c f3 65 46 7a 1a .Oyv .. ...eFz. 1410 002d - 49 e8 38 b5 1f 35 a6 2c-7a 15 8e 5f c9 99 bf I.8..5.,z.._... 1411 003c - 7d 8f bf b5 26 2a f5 af-ec 93 }...&*.... 1412 unsignedAttrs: 1413 1415 Figure 6: Signed Message without Imbedded Certificate 1417 A.3. Signed and Encrypted Message 1419 The following sections show details for the message signed by Bob and 1420 encrypted to Alice, as used in the examples in Section 10.3 and 1421 Section 10.4. 1423 A.3.1. Signed Message Prior to Encryption 1425 CMS_ContentInfo: 1426 contentType: pkcs7-signedData (1.2.840.113549.1.7.2) 1427 d.signedData: 1428 version: 1 1429 digestAlgorithms: 1430 algorithm: sha256 (2.16.840.1.101.3.4.2.1) 1431 parameter: 1432 encapContentInfo: 1433 eContentType: pkcs7-data (1.2.840.113549.1.7.1) 1434 eContent: 1435 0000 - 43 6f 6e 74 65 6e 74 2d-54 79 70 65 3a 20 74 Content-Type: t 1436 000f - 65 78 74 2f 70 6c 61 69-6e 0d 0a 0d 0a 57 61 ext/plain....Wa 1437 001e - 74 73 6f 6e 2c 20 63 6f-6d 65 20 68 65 72 65 tson, come here 1438 002d - 20 2d 20 49 20 77 61 6e-74 20 74 6f 20 73 65 - I want to se 1439 003c - 65 20 79 6f 75 2e 0d 0a- e you... 1440 certificates: 1441 d.certificate: 1442 cert_info: 1443 version: 2 1444 serialNumber: 11914627415941064473 1445 signature: 1446 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1447 parameter: 1448 issuer: O=example.org, CN=Bob 1449 validity: 1450 notBefore: Dec 20 23:07:49 2017 GMT 1451 notAfter: Dec 20 23:07:49 2018 GMT 1452 subject: O=example.org, CN=Bob 1453 key: 1454 algor: 1455 algorithm: id-ecPublicKey (1.2.840.10045.2.1) 1456 parameter: OBJECT:prime256v1 (1.2.840.10045.3.1.7) 1457 public_key: (0 unused bits) 1458 0000 - 04 86 4f ff fc 53 f1 a8-76 ca 69 b1 7e 27 ..O..S..v.i.~' 1459 000e - 48 7a 07 9c 71 52 ae 1b-13 7e 39 3b af 1a Hz..qR...~9;.. 1460 001c - ae bd 12 74 3c 7d 41 43-a2 fd 8a 37 0f 02 ...t<}AC...7.. 1461 002a - ba 9d 03 b7 30 1f 1d a6-4e 30 55 94 bb 6f ....0...N0U..o 1462 0038 - 95 cb 71 fa 48 b6 d0 a3-83 ..q.H.... 1463 issuerUID: 1464 subjectUID: 1465 extensions: 1466 object: X509v3 Subject Alternative Name (2.5.29.17) 1467 critical: TRUE 1468 value: 1469 0000 - 30 15 86 13 73 69 70 3a-62 6f 62 40 65 0...sip:bob@e 1470 000d - 78 61 6d 70 6c 65 2e 6f-72 67 xample.org 1471 sig_alg: 1472 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1473 parameter: 1474 signature: (0 unused bits) 1475 0000 - 30 45 02 21 00 b2 24 8c-92 40 28 22 38 9e c9 0E.!..$..@("8.. 1476 000f - 25 7f 64 cc fd 10 6f ba-0b 96 c1 19 07 30 34 %.d...o......04 1477 001e - d5 1b 10 2f 73 39 6c 02-20 15 8e b1 51 f0 85 .../s9l. ...Q.. 1478 002d - b9 bd 2e 04 cf 27 8f 0d-52 2e 6b b6 fe 4f 36 .....'..R.k..O6 1479 003c - f7 4c 77 10 b1 5a 4f 47-9d e4 0d .Lw..ZOG... 1480 crls: 1481 1482 signerInfos: 1483 version: 1 1484 d.issuerAndSerialNumber: 1485 issuer: O=example.org, CN=Bob 1486 serialNumber: 11914627415941064473 1487 digestAlgorithm: 1488 algorithm: sha256 (2.16.840.1.101.3.4.2.1) 1489 parameter: 1490 signedAttrs: 1491 object: contentType (1.2.840.113549.1.9.3) 1492 value.set: 1493 OBJECT:pkcs7-data (1.2.840.113549.1.7.1) 1495 object: signingTime (1.2.840.113549.1.9.5) 1496 value.set: 1497 UTCTIME:Dec 22 23:43:18 2017 GMT 1499 object: messageDigest (1.2.840.113549.1.9.4) 1500 value.set: 1501 OCTET STRING: 1502 0000 - ef 77 8f c9 40 d5 e6 dc-25 76 f4 7a 59 .w..@...%v.zY 1503 000d - 9b 31 26 19 5a 9f 1a 22-7a da f3 5f a2 .1&.Z.."z.._. 1504 001a - 2c 05 0d 8d 19 5a ,....Z 1506 object: S/MIME Capabilities (1.2.840.113549.1.9.15) 1507 value.set: 1508 SEQUENCE: 1509 0:d=0 hl=2 l= 106 cons: SEQUENCE 1510 2:d=1 hl=2 l= 11 cons: SEQUENCE 1511 4:d=2 hl=2 l= 9 prim: OBJECT :aes-256-cbc 1512 15:d=1 hl=2 l= 11 cons: SEQUENCE 1513 17:d=2 hl=2 l= 9 prim: OBJECT :aes-192-cbc 1514 28:d=1 hl=2 l= 11 cons: SEQUENCE 1515 30:d=2 hl=2 l= 9 prim: OBJECT :aes-128-cbc 1516 41:d=1 hl=2 l= 10 cons: SEQUENCE 1517 43:d=2 hl=2 l= 8 prim: OBJECT :des-ede3-cbc 1518 53:d=1 hl=2 l= 14 cons: SEQUENCE 1519 55:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc 1520 65:d=2 hl=2 l= 2 prim: INTEGER :80 1521 69:d=1 hl=2 l= 13 cons: SEQUENCE 1522 71:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc 1523 81:d=2 hl=2 l= 1 prim: INTEGER :40 1524 84:d=1 hl=2 l= 7 cons: SEQUENCE 1525 86:d=2 hl=2 l= 5 prim: OBJECT :des-cbc 1526 93:d=1 hl=2 l= 13 cons: SEQUENCE 1527 95:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc 1528 105:d=2 hl=2 l= 1 prim: INTEGER :28 1529 signatureAlgorithm: 1530 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1531 parameter: 1532 signature: 1533 0000 - 30 45 02 20 23 e1 e1 2f-c6 9c 7b c3 ae d0 67 0E. #../..{...g 1534 000f - 8a ab 25 71 16 dd 9a 82-7c 36 24 a2 fa e5 fa ..%q....|6$.... 1535 001e - 98 52 01 2b 98 c1 02 21-00 9b 8d 7c ad 9a f2 .R.+...!...|... 1536 002d - 09 e8 ac f7 00 aa a7 64-ef 32 d0 3a 47 16 42 .......d.2.:G.B 1537 003c - 79 04 54 90 53 e8 58 aa-6c 69 37 y.T.S.X.li7 1538 unsignedAttrs: 1539 1541 Figure 7: Message Signed by Bob prior to Encryption 1543 A.3.2. Encrypted Message 1545 CMS_ContentInfo: 1546 contentType: pkcs7-envelopedData (1.2.840.113549.1.7.3) 1547 d.envelopedData: 1548 version: 1549 originatorInfo: 1550 recipientInfos: 1551 d.ktri: 1552 version: 1553 d.issuerAndSerialNumber: 1554 issuer: O=example.com, CN=Alice 1555 serialNumber: 9508519069068149774 1556 keyEncryptionAlgorithm: 1557 algorithm: rsaEncryption (1.2.840.113549.1.1.1) 1558 parameter: NULL 1559 encryptedKey: 1560 0000 - bb ab 78 55 54 a4 8e 62-48 67 7b 5c 56 32 85 ..xUT..bHg{\V2. 1561 000f - 28 28 2e 17 2d 36 61 1d-c2 98 6a e1 68 fc 84 ((..-6a...j.h.. 1562 001e - d4 9f 41 20 ea 2c b8 95-d5 96 7f f3 5a 22 ed ..A .,......Z". 1563 002d - 2e 5f ee 4d 72 04 e7 0c-86 97 bf 13 8d 9f bd ._.Mr.......... 1564 003c - 84 85 c3 00 63 8f 9e f9-3e 61 46 5f 1e 14 05 ....c...>aF_... 1565 004b - fb 5b f7 b9 5f 2f af 12-e4 41 fb 8c fc df d5 .[.._/...A..... 1566 005a - cf 1d 88 d2 85 cf a9 fd-df 0d e3 f9 c9 5b 8c .............[. 1568 0069 - d7 50 77 29 24 c7 d9 19-c8 0a a8 67 7d c2 bc .Pw)$......g}.. 1569 0078 - 63 b5 ab e2 a0 4e 76 ee-0c 2e 6c 04 1e 08 fa c....Nv...l.... 1570 0087 - 29 47 6a 4a 76 85 19 44-ed d7 fa 79 ad a8 97 )GjJv..D...y... 1571 0096 - 09 10 7b f6 5d 56 ac 66-9b 78 1a 23 f0 fd 72 ..{.]V.f.x.#..r 1572 00a5 - 32 de 26 bb a0 7e 1d ca-69 f5 01 18 bd 49 55 2.&..~..i....IU 1573 00b4 - 46 3d 2c ad 40 3d c2 a6-74 92 09 df c0 2c 9e F=,.@=..t....,. 1574 00c3 - 14 52 70 d5 13 5c e5 54-8b bf 33 47 c6 f3 56 .Rp..\.T..3G..V 1575 00d2 - fa a0 93 fe ef db ba 5d-09 4f 4a 0e 23 a9 46 .......].OJ.#.F 1576 00e1 - 86 fc a7 7c fa 17 59 aa-a4 e2 77 48 22 7e 65 ...|..Y...wH"~e 1577 00f0 - 17 06 3f bb d7 a0 13 ab-cb 08 f9 50 b2 ac 91 ..?........P... 1578 00ff - 1b 72 b3 40 d5 7c 24 d0-8e 61 3f 4e 0a 08 78 .r.@.|$..a?N..x 1579 010e - 21 c8 20 23 8e 42 2e 85-bf 39 02 c9 9a 96 29 !. #.B...9....) 1580 011d - b0 86 29 45 e0 0d 1b 43-3f 6d c3 5e 8d 1c b5 ..)E...C?m.^... 1581 012c - 09 85 97 36 36 24 45 6d-d8 67 e6 13 2d 8e e9 ...66$Em.g..-.. 1582 013b - 35 cc 3b 41 24 df 6b ab-a8 87 70 70 8a f5 7c 5.;A$.k...pp..| 1583 014a - 9a d7 07 27 41 0d 6b f8-3e c0 e5 58 0e 26 c6 ...'A.k.>..X.&. 1584 0159 - 7f 90 60 8d 37 57 50 ed-93 89 02 56 bf 3f 71 ..`.7WP....V.?q 1585 0168 - 4f b6 76 ef fc f3 63 db-08 09 b0 21 e9 09 94 O.v...c....!... 1586 0177 - a4 37 35 3e e4 14 32 c7-cf 60 e4 8c bd 45 42 .75>..2..`...EB 1587 0186 - 0c 65 9e 75 90 6c ed e2-d4 4a 5b b6 19 01 4e .e.u.l...J[...N 1588 0195 - 73 a0 ba 2d 54 ab 3e db-e2 3c 63 fa d8 98 41 s..-T.>...:... 1591 01c2 - e7 74 1f 07 2c 1d 46 5e-a1 e6 c3 57 7b 2e 77 .t..,.F^...W{.w 1592 01d1 - ac d1 d1 15 2f 26 82 35-f8 5a e8 2f 50 87 1a ..../&.5.Z./P.. 1593 01e0 - cf 13 e3 8b 17 fd 69 f8-8f 97 3f 68 18 68 2c ......i...?h.h, 1594 01ef - 40 43 b4 ec 7d b1 7b 22-e2 0e e9 be cb f2 c9 @C..}.{"....... 1595 01fe - f8 93 .. 1596 encryptedContentInfo: 1597 contentType: pkcs7-data (1.2.840.113549.1.7.1) 1598 contentEncryptionAlgorithm: 1599 algorithm: aes-128-cbc (2.16.840.1.101.3.4.1.2) 1600 parameter: OCTET STRING: 1601 0000 - 4d 87 57 22 2e ac 52 94-11 7f 0c 12 d6 71 a1 M.W"..R......q. 1602 000f - 27 ' 1603 encryptedContent: 1604 0000 - 5d 40 77 a1 54 7c 5f 46-99 f0 75 31 a5 3e b8 ]@w.T|_F..u1.>. 1605 000f - 83 44 d1 a3 b2 29 ff 91-f3 f6 9c 0e 94 91 8c .D...)......... 1606 001e - 77 c9 f6 bd a1 94 e3 59-83 ef 9a 38 ed ca 15 w......Y...8... 1607 002d - 67 8e 65 bd 76 ce 66 5c-a6 e9 99 b3 a8 45 e4 g.e.v.f\.....E. 1608 003c - 26 66 aa 27 03 a5 a4 f0-d3 32 2d 6d e0 1e 64 &f.'.....2-m..d 1609 004b - 54 5c bc cf 09 e3 c2 26-8d fd 86 c3 36 11 6b T\.....&....6.k 1610 005a - 22 cc e8 00 98 61 92 42-fd 48 2e ce 2f cd 71 "....a.B.H../.q 1611 0069 - a7 c1 5f f7 7b f1 33 28-7d f0 ef 7c 51 71 3b .._.{.3(}..|Qq; 1612 0078 - dc 0f 6c da da 91 98 ea-8f d8 1a 9c 5a 50 c5 ..l.........ZP. 1613 0087 - e9 c0 95 8b 33 47 ef c4-25 03 8f b5 b7 76 ab ....3G..%....v. 1614 0096 - 46 98 26 22 7c 69 7a ec-c6 58 0d 0a 23 a9 9e F.&"|iz..X..#.. 1615 00a5 - 15 b8 05 ff 3b a1 55 c2-52 f5 e7 2b b9 db 13 ....;.U.R..+... 1617 00b4 - 3d 04 9d 99 2c 18 f4 f4-da d6 0a 18 da e7 29 =...,.........) 1618 00c3 - ba 7c 58 36 78 ff b8 60-4a 8f 7f e3 cc 62 d0 .|X6x..`J....b. 1619 00d2 - 63 2c c6 6e 1c 4f 9b a1-fa 9d f5 6c 6d 9f d8 c,.n.O.....lm.. 1620 00e1 - 1f 19 c8 8b a6 e9 71 0b-b0 bb b0 c5 fc f9 d2 ......q........ 1621 00f0 - d5 ea 04 d5 29 fd a7 8d-60 dc 48 7d 86 7c 0e ....)...`.H}.|. 1622 00ff - 39 21 74 e9 3c e2 c3 98-6c ea 7a ef 07 1e 5b 9!t.<...l.z...[ 1623 010e - 07 b6 46 c2 29 f9 06 9f-27 f3 74 94 56 da ea ..F.)...'.t.V.. 1624 011d - 0a 4e 56 bc 49 1c 9b e3-70 c5 44 39 9a 27 3d .NV.I...p.D9.'= 1625 012c - 50 c3 5f 16 0f b3 7e 5f-73 14 c3 d3 89 a8 05 P._...~_s...... 1626 013b - c8 e4 77 6f 0a 2a 89 f5-55 c9 fe 52 08 08 90 ..wo.*..U..R... 1627 014a - ab e2 e3 9d 2e d7 7a 2b-36 3d 1c 0f b3 75 79 ......z+6=...uy 1628 0159 - 00 28 e9 62 40 12 30 ae-93 aa 43 20 a5 da 2a .(.b@.0...C ..* 1629 0168 - d7 01 7c 59 95 08 f7 9c-3a 0c 35 f9 84 6e 8a ..|Y....:.5..n. 1630 0177 - 2c 41 0a 5e 0d 77 e9 07-c0 15 1c e5 13 e2 e8 ,A.^.w......... 1631 0186 - 99 de 92 ff 8d 17 77 96-23 8a de 93 09 d7 5c ......w.#.....\ 1632 0195 - 97 6e 97 16 ce d4 c4 5e-1a 33 92 13 d7 b0 82 .n.....^.3..... 1633 01a4 - 45 92 39 40 76 f7 4a 70-45 4c c4 65 65 f4 a8 E.9@v.JpEL.ee.. 1634 01b3 - 36 53 16 46 42 82 7b 2e-28 81 9a c3 78 1a fb 6S.FB.{.(...x.. 1635 01c2 - 52 9b 7c 72 30 8b 96 97-85 39 d7 89 d3 d2 7c R.|r0....9....| 1636 01d1 - b1 60 5b 1a 0c e9 66 e9-c6 cb 58 25 d2 35 e5 .`[...f...X%.5. 1637 01e0 - 23 a6 c2 d9 48 ef 93 14-c9 02 35 9a df 03 fe #...H.....5.... 1638 01ef - 46 84 22 1f af d1 f8 33-d7 59 c6 f2 55 9b 6e F."....3.Y..U.n 1639 01fe - 0a 88 97 d6 4e 42 b4 9e-ae 0e 39 df ac cc 94 ....NB....9.... 1640 020d - ef 3e 73 3f ca 22 12 eb-5c cb c7 c5 d7 f0 42 .>s?."..\.....B 1641 021c - d0 2b f4 12 d1 4c 7e de-0f 66 4d 79 9e a5 56 .+...L~..fMy..V 1642 022b - f9 76 3e 74 2c ac dd 3e-fc 88 22 bb e6 c8 1f .v>t,..>..".... 1643 023a - ea 27 de 6b 0b 06 44 82-52 f9 ad eb 66 67 b4 .'.k..D.R...fg. 1644 0249 - 60 56 f3 9b 42 f1 8f 4d-62 58 11 1f a2 43 b5 `V..B..MbX...C. 1645 0258 - c3 9f df 89 61 bc 6e 59-d8 bd 65 9d 46 f9 2a ....a.nY..e.F.* 1646 0267 - 8c ed 04 d1 a6 af 37 e5-c0 89 b5 47 a8 36 df ......7....G.6. 1647 0276 - 69 94 37 7c f9 2e 8e 74-62 55 69 df 6a 60 65 i.7|...tbUi.j`e 1648 0285 - f6 c9 3b ab ef 0d 07 cf-ac 7a f6 9d 8b f8 7c ..;......z....| 1649 0294 - 96 e6 eb ad 2e bd b5 53-f7 76 e6 91 43 e7 06 .......S.v..C.. 1650 02a3 - e2 27 06 1e 5e 3d 0e 38-a8 3a b9 c2 ce 62 10 .'..^=.8.:...b. 1651 02b2 - 2f 30 21 f7 d8 b9 e5 6a-d6 71 45 14 03 9f 48 /0!....j.qE...H 1652 02c1 - d7 fa b8 5e fb af ee 16-e1 5d 7a fd 81 48 cc ...^.....]z..H. 1653 02d0 - fc 9f b2 73 f8 bf d5 bd-eb d0 28 1a 50 09 5a ...s......(.P.Z 1654 02df - a1 92 c9 e8 7a 0f 2c 44-bb 57 de 5f 86 cf bd ....z.,D.W._... 1655 02ee - a3 33 7c d9 82 df ae 98-2a 80 87 98 78 64 6e .3|.....*...xdn 1656 02fd - 03 61 45 15 cf 94 15 04-79 d2 0e 3c e5 21 61 .aE.....y..<.!a 1657 030c - 7d da 22 d5 3a 58 29 26-55 64 fa 46 7e 7d b9 }.".:X)&Ud.F~}. 1658 031b - e2 5f 3d 25 5a 4f 9f 82-fd 95 14 ca 17 7a c8 ._=%ZO.......z. 1659 032a - 1b 88 2a cb e8 9d 1c c6-40 c7 b9 80 c5 a9 d5 ..*.....@...... 1660 0339 - f7 09 21 bb 6f bf 16 6d-38 aa 04 25 7e 08 c5 ..!.o..m8..%~.. 1661 0348 - 1b 2d f1 44 e9 33 63 e0-e4 7e 80 13 df 58 4b .-.D.3c..~...XK 1662 0357 - 3f 31 30 b4 df 7c 9a e1-77 09 f1 bf d8 de d1 ?10..|..w...... 1663 0366 - 38 57 41 d8 05 96 b7 b8-d6 a2 f2 e5 a2 f8 50 8WA...........P 1664 0375 - 29 ce 97 ef ed 2c 97 f9-42 f7 7b )....,..B.{ 1665 unprotectedAttrs: 1666 1668 Figure 8 1670 Authors' Addresses 1672 Ben Campbell 1673 Standard Velocity 1674 204 Touchdown Dr 1675 Irving, TX 75063 1676 US 1678 Email: ben@nostrum.com 1680 Russ Housley 1681 Vigil Security 1682 918 Spring Knoll Drive 1683 Herndon, VA 20170 1684 US 1686 Email: housley@vigilsec.com