idnits 2.17.1 draft-campbell-sip-messaging-smime-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4975, but the abstract doesn't seem to directly say this. It does mention RFC4975 though, so this could be OK. -- The draft header indicates that this document updates RFC3428, but the abstract doesn't seem to directly say this. It does mention RFC3428 though, so this could be OK. -- The draft header indicates that this document updates RFC3261, but the abstract doesn't seem to directly say this. It does mention RFC3261 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1604 has weird spacing: '...6 a2 af b6.....' == Line 1656 has weird spacing: '...7 16 dc n..@...' (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 (January 26, 2019) is 1916 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) ** 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-06 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Campbell 3 Internet-Draft Standard Velocity 4 Updates: 3261, 3428, 4975 (if approved) R. Housley 5 Intended status: Standards Track Vigil Security 6 Expires: July 30, 2019 January 26, 2019 8 SIP-based Messaging with S/MIME 9 draft-campbell-sip-messaging-smime-05 11 Abstract 13 Mobile messaging applications used with the Session Initiation 14 Protocol (SIP) commonly use some combination of the SIP MESSAGE 15 method and the Message Session Relay Protocol (MSRP). While these 16 provide mechanisms for hop-by-hop security, neither natively provides 17 end-to-end protection. This document offers guidance on how to 18 provide end-to-end authentication, integrity protection, and 19 confidentiality using the Secure/Multipurpose Internet Mail 20 Extensions (S/MIME). It updates and provides clarifications for RFC 21 3261, RFC 3428, and RFC 4975. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on July 30, 2019. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Problem Statement and Scope . . . . . . . . . . . . . . . . . 4 60 4. Applicability of S/MIME . . . . . . . . . . . . . . . . . . . 5 61 4.1. Signed Messages . . . . . . . . . . . . . . . . . . . . . 5 62 4.2. Encrypted Messages . . . . . . . . . . . . . . . . . . . 6 63 4.3. Signed and Encrypted Messages . . . . . . . . . . . . . . 7 64 4.4. Certificate Handling . . . . . . . . . . . . . . . . . . 8 65 4.4.1. Subject Alternative Name . . . . . . . . . . . . . . 8 66 4.4.2. Certificate Validation . . . . . . . . . . . . . . . 8 67 5. Transfer Encoding . . . . . . . . . . . . . . . . . . . . . . 8 68 6. User Agent Capabilities . . . . . . . . . . . . . . . . . . . 9 69 7. Using S/MIME with the SIP MESSAGE Method . . . . . . . . . . 10 70 7.1. Size Limit . . . . . . . . . . . . . . . . . . . . . . . 10 71 7.2. SIP User Agent Capabilities . . . . . . . . . . . . . . . 10 72 7.3. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 11 73 8. Using S/MIME with MSRP . . . . . . . . . . . . . . . . . . . 11 74 8.1. Chunking . . . . . . . . . . . . . . . . . . . . . . . . 11 75 8.2. Streamed Data . . . . . . . . . . . . . . . . . . . . . . 12 76 8.3. Indicating support for S/MIME . . . . . . . . . . . . . . 12 77 8.4. MSRP URIs . . . . . . . . . . . . . . . . . . . . . . . . 13 78 8.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 13 79 9. S/MIME Interaction with other SIP Messaging Features . . . . 14 80 9.1. Common Profile for Instant Messaging . . . . . . . . . . 14 81 9.2. Instant Message Delivery Notifications . . . . . . . . . 15 82 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 10.1. Signed Message in SIP Including the Sender's Certificate 16 84 10.2. Signed Message in SIP with No Certificate . . . . . . . 17 85 10.3. MSRP Signed and Encrypted Message in a Single Chunk . . 18 86 10.4. MSRP Signed and Encrypted Message sent in Multiple 87 Chunks . . . . . . . . . . . . . . . . . . . . . . . . . 20 88 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 89 12. Security Considerations . . . . . . . . . . . . . . . . . . . 22 90 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 91 13.1. Normative References . . . . . . . . . . . . . . . . . . 24 92 13.2. Informative References . . . . . . . . . . . . . . . . . 26 93 Appendix A. Message Details . . . . . . . . . . . . . . . . . . 28 94 A.1. Signed Message . . . . . . . . . . . . . . . . . . . . . 28 95 A.2. Short Signed Message . . . . . . . . . . . . . . . . . . 30 96 A.3. Signed and Encrypted Message . . . . . . . . . . . . . . 31 97 A.3.1. Signed Message Prior to Encryption . . . . . . . . . 32 98 A.3.2. Encrypted Message . . . . . . . . . . . . . . . . . . 34 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 101 1. Introduction 103 Several Mobile Messaging systems use the Session Initiation Protocol 104 (SIP) [RFC3261], typically as some combination of the SIP MESSAGE 105 method [RFC3428] and the Message Session Relay Protocol (MSRP) 106 [RFC4975]. For example, Voice over LTE (VoLTE) uses the SIP MESSAGE 107 method to send Short Message Service (SMS) messages. The Open Mobile 108 Alliance (OMA) Converged IP Messaging (CPM) [CPM] system uses the SIP 109 MESSAGE Method for short "pager mode" messages and MSRP for large 110 messages and for sessions of messages. The GSM Association (GMSA) 111 rich communication services (RCS) uses CPM for messaging [RCS]. 113 At the same time, organizations increasingly depend on mobile 114 messaging systems to send notifications to their customers. Many of 115 these notifications are security-sensitive. For example, such 116 notifications are commonly used for notice of financial transactions, 117 notice of login or password change attempts, and sending of two- 118 factor authentication codes. 120 Both SIP and MSRP can be used to transport any content using 121 Multipurpose Internet Mail Extensions (MIME) formats. The SIP 122 MESSAGE method is typically limited to short messages (under 1300 123 octets for the MESSAGE request). MSRP can carry arbitrarily large 124 messages, and can break large messages into chunks. 126 While both SIP and MSRP provide mechanisms for hop-by-hop security, 127 neither provides native end-to-end protection. Instead, they depend 128 on S/MIME [I-D.ietf-lamps-rfc5750-bis][I-D.ietf-lamps-rfc5751-bis]. 129 However at the time of this writing, S/MIME is not in common use for 130 SIP- and MSRP-based messaging services. This document updates and 131 clarifies RFC 3261, RFC 3428, and RFC 4975 in an attempt to make 132 S/MIME for SIP and MSRP easier to implement and deploy in an 133 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 140 reporting 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" sent 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 to 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 [I-D.ietf-lamps-rfc5751-bis] defines 212 MIME 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, the use of application/pkcs7-mime is RECOMMENDED for most 220 signed messages. Experience with the use of S/MIME in electronic 221 mail has shown that multipart/signed bodies are at greater risk of 222 "helpful" tampering by intermediaries, a common cause of signature 223 validation failure. This risk is also present for messaging 224 applications; for example, intermediaries might insert Instant 225 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 (UA) SHOULD 233 follow the conventions specified in [I-D.ietf-lamps-rfc5751-bis] for 234 the application/pkcs7-mime media type with smime-type=signed-data. 235 When validating a signed message, receiving UAs MUST follow the 236 conventions specified in [I-D.ietf-lamps-rfc5751-bis] for the 237 application/pkcs7-mime media type with smime-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 P-256 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) [RFC8032][RFC8419]. For 255 convenience, the ECDSA with SHA-256 algorithm identifier, the object 256 identifier for the well-known NIST P-256 elliptic curve, and the 257 Ed25519 algorithm identifier are repeated here: 259 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { 260 iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 261 ecdsa-with-SHA2(3) 2 } 263 -- Note: the NIST P-256 elliptic curve is also known as secp256r1. 265 secp256r1 OBJECT IDENTIFIER ::= { 266 iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3) 267 prime(1) 7 } 269 id-Ed25519 OBJECT IDENTIFIER ::= { 270 iso(1) identified-organization(3) thawte(101) 112 } 272 4.2. Encrypted Messages 274 When generating an encrypted message, sending UAs MUST follow the 275 conventions specified in [I-D.ietf-lamps-rfc5751-bis] for the 276 application/pkcs7-mime media type with smime-type=auth-enveloped- 277 data. When decrypting a received message, receiving UAs MUST follow 278 the conventions specified in [I-D.ietf-lamps-rfc5751-bis] for the 279 application/pkcs7-mime media type with smime- type=auth-enveloped- 280 data. 282 Sending and receiving UAs MUST support the AES-128-GCM for content 283 encryption [RFC5084]. For convenience, the AES-128-GCM algorithm 284 identifier is repeated here: 286 id-aes128-GCM OBJECT IDENTIFIER ::= { 287 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 288 csor(3) nistAlgorithm(4) aes(1) 6 } 290 Sending and receiving UAs MAY support other content authenticated 291 encryption algorithms. 293 Sending and receiving UAs MUST support the AES-128-WRAP algorithm for 294 encryption of one AES key with another AES key [RFC3565]. For 295 convenience, the AES-128-WRAP algorithm identifier is repeated here: 297 id-aes128-wrap OBJECT IDENTIFIER ::= { 298 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 299 csor(3) nistAlgorithm(4) aes(1) 5 } 301 Sending and receiving UAs MAY support other key encryption 302 algorithms. 304 Symmetric key-encryption keys can be distributed before messages are 305 sent. If sending and receiving UAs support previously distributed 306 key-encryption keys, then they MUST assign a KEKIdentifier [RFC5652] 307 to the previously distributed symmetric key. 309 Alternatively, a key agreement algorithm can be used to establish a 310 single-use key-encryption key. If sending and receiving UAs support 311 key agreement, then they MUST support the Elliptic Curve Diffie- 312 Hellman (ECDH) algorithm using the NIST P-256 elliptic curve and the 313 ANSI-X9.63-KDF key derivation function with the SHA-256 message 314 digest algorithm [RFC5753]. If sending and receiving UAs support key 315 agreement, then they SHOULD support the Elliptic Curve Diffie-Hellman 316 (ECDH) algorithm using curve25519 (X25519) [RFC7748][RFC8418]. For 317 convenience, the identifers for the ECDH algorithm using the ANSI- 318 X9.63-KDF with SHA-256 algorithm and for the X25519 algorithm are 319 repeated here: 321 dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { 322 iso(1) identified-organization(3) certicom(132) 323 schemes(1) 11 1 } 325 id-X25519 OBJECT IDENTIFIER ::= { 326 iso(1) identified-organization(3) thawte(101) 110 } 328 4.3. Signed and Encrypted Messages 330 RFC 3261 section 23.2 says that when a User Agent Client (UAC) sends 331 signed and encrypted data, it "SHOULD" send an EnvelopedData object 332 encapsulated within a SignedData message. That essentially says that 333 one should encrypt first, then sign. This document updates RFC 3261 334 to say that, when sending signed and encrypted user content in a SIP 335 MESSAGE request, the sending UAs MUST sign the message first, and 336 then encrypt it. That is, it must send the SignedData object inside 337 an AuthEnvelopedData object. For interoperability reasons, 338 recipients SHOULD accept messages signed and encrypted in either 339 order. 341 4.4. Certificate Handling 343 Sending and receiving UAs MUST follow the S/MIME certificate handling 344 procedures [I-D.ietf-lamps-rfc5750-bis], with a few exceptions 345 detailed below. 347 4.4.1. Subject Alternative Name 349 In both SIP and MSRP, the identity of the sender of a message is 350 typically expressed as a SIP URI. 352 The subject alternative name extension is used as the preferred means 353 to convey the SIP URI of the subject of a certificate. Any SIP URI 354 present MUST be encoded using the uniformResourceIdentifier CHOICE of 355 the GeneralName type as described in [RFC5280], Section 4.2.1.6. 356 Since the SubjectAltName type is a SEQUENCE OF GeneralName, multiple 357 URIs MAY be present. 359 Other methods of identifying a certificate subject MAY be used. 361 4.4.2. Certificate Validation 363 When validating a certificate, receiving UAs MUST support the 364 Elliptic Curve Digital Signature Algorithm (ECDSA) using the NIST 365 P-256 elliptic curve and the SHA-256 message digest algorithm 366 [RFC5480]. 368 Sending and receiving UAs MAY support other digital signature 369 algorithms for certificate validation. 371 5. Transfer Encoding 373 SIP and MSRP UAs are always capable of receiving binary data. Inner 374 S/MIME entities do not require base64 encoding [RFC4648]. 376 Both SIP and MSRP provide 8-bit safe transport channels; base64 377 encoding is not generally needed for the outer S/MIME entities. 378 However, if there is a chance a message might cross a 7-bit transport 379 (for example, gateways that convert to a 7-bit transport for 380 intermediate transfer), base64 encoding may be needed for the outer 381 entity. 383 6. User Agent Capabilities 385 Messaging UAs may implement a subset of S/MIME capabilities. Even 386 when implemented, some features may not be available due to 387 configuration. For example, UAs that do not have user certificates 388 cannot sign messages on behalf of the user or decrypt encrypted 389 messages sent to the user. At a minimum, a UA that supports S/MIME 390 MUST be able to validate a signed message. 392 End-user certificates have long been a barrier to large-scale S/MIME 393 deployment. But since UAs can validate signatures even without local 394 certificates, the use case of organizations sending secure 395 notifications to their users becomes a sort of "low hanging fruit". 396 That being said, the signed-notification use case still requires 397 shared trust anchors. 399 SIP and MSRP UAs advertise their level of support for S/MIME by 400 indicating their capability to receive the "application/pkcs7-mime" 401 media type. 403 The fact that a UA indicates support for the "multipart/signed" media 404 type does not necessarily imply support for S/MIME. The UA might 405 just be able to display clear-signed content without validating the 406 signature. UAs that wish to indicate the ability to validate 407 signatures for clear-signed messages MUST also indicate support for 408 "application/pkcs7-signature". 410 A UA can indicate that it can receive all smime-types by advertising 411 "application/pkcs7-mime" with no parameters. If a UA does not accept 412 all smime-types, it advertises the media type with the appropriate 413 parameters. If more than one are supported, the UA includes a 414 separate instance of the media-type string, appropriately 415 parameterized, for each. 417 For example, a UA that can only receive signed-data would advertise 418 "application/pkcs7-mime; smime-type=signed-data". 420 SIP signaling can fork to multiple destinations for a given Address 421 of Record (AoR). A user might have multiple UAs with different 422 capabilities; the capabilities remembered from an interaction with 423 one such UA might not apply to another. (See Section 7.2.) 425 UAs can also advertise or discover S/MIME using out-of-band 426 mechanisms. Such mechanisms are beyond the scope of this document. 428 7. Using S/MIME with the SIP MESSAGE Method 430 The use of S/MIME with the SIP MESSAGE method is described in section 431 11.3 of [RFC3428], and for SIP in general in section 23 of [RFC3261]. 432 This section and its child sections offer clarifications for the use 433 of S/MIME with the SIP MESSAGE method, along with related updates to 434 RFC 3261 and RFC 3428. 436 7.1. Size Limit 438 SIP MESSAGE requests are typically limited to 1300 octets. That 439 limit applies to the entire message, including both SIP header fields 440 and the message content. This is due to the potential for 441 fragmentation of larger requests sent over UDP. In general, it is 442 hard to be sure that no proxy or other intermediary will forward a 443 SIP request over UDP somewhere along the path. Therefore, S/MIME 444 messages sent via SIP MESSAGE should be kept as small as possible. 445 Messages that will not fit within the limit can be sent using MSRP. 447 Section 23.2 of [RFC3261] says that a SignedData message must contain 448 a certificate to be used to validate the signature. In order to 449 reduce the message size, this document updates that to say that a 450 SignedData message sent in a SIP MESSAGE request SHOULD contain the 451 certificate, but MAY omit it if the sender has reason to believe that 452 the recipient already has the certificate in its keychain, or has 453 some other method of accessing the certificate. 455 7.2. SIP User Agent Capabilities 457 SIP user agents (UA) can theoretically indicate support for S/MIME by 458 including the appropriate media type or types in the SIP Accept 459 header field in a response to an OPTIONS request, or in a 415 460 response to a SIP request that contained an unsupported media type in 461 the body. Unfortunately, this approach may not be reliable in the 462 general case. In the case where a downstream SIP proxy forks an 463 OPTIONS or other non-INVITE request to multiple UASs, that proxy will 464 only forward the "best" response. If the recipient has multiple 465 devices, the sender may only learn the capabilities of the device 466 that sent the forwarded response. Blindly trusting this information 467 could result in S/MIME messages being sent to UAs that do not support 468 it, which would be at best confusing and at worst misleading to the 469 recipient. 471 UAs might be able to use the user agent capabilities framework 472 [RFC3840] to indicate support. However doing so would require the 473 registration of one or more media feature tags with IANA. 475 UAs MAY use other out-of-band methods to indicate their level of 476 support for S/MIME. 478 7.3. Failure Cases 480 Section 23.2 of [RFC3261] requires that the recipient of a SIP 481 request that includes a body part of an unsupported media type and a 482 Content-Disposition header field "handling" parameter of "required" 483 return a 415 "Unsupported Media Type" response. Given that SIP 484 MESSAGE exists for no reason other than to deliver content in the 485 body, it is reasonable to treat the top-level body part as always 486 required. However [RFC3428] makes no such assertion. This document 487 updates section 11.3 [RFC3428] to add the statement that a UAC that 488 receives a SIP MESSAGE request with an unsupported media type MUST 489 return a 415 "Unsupported Media Type" response. 491 Section 23.2 of [RFC3261] says that if a recipient receives an S/MIME 492 body encrypted to the wrong certificate, it MUST return a SIP 493 493 (Undecipherable) response, and SHOULD send a valid certificate in 494 that response. This is not always possible in practice for SIP 495 MESSAGE requests. The User Agent Server (UAS) may choose not to 496 decrypt a message until the user is ready to read it. Messages may 497 be delivered to a message store, or sent via a store-and-forward 498 service. This document updates RFC 3261 to say that the UAS SHOULD 499 return a SIP 493 response if it immediately attempts to decrypt the 500 message and determines the message was encrypted to the wrong 501 certificate. However, it MAY return a 200-class response if 502 decryption is deferred. 504 8. Using S/MIME with MSRP 506 MSRP has features that interact with the use of S/MIME. In 507 particular, the ability to send messages in chunks, the ability to 508 send messages of unknown size, and the use of SDP to indicate media- 509 type support create considerations for the use of S/MIME. 511 8.1. Chunking 513 MSRP allows a message to be broken into "chunks" for transmission. 514 In this context, the term "message" refers to an entire message that 515 one user might send to another. A chunk is a fragment of that 516 message sent in a single MSRP SEND request. All of the chunks that 517 make up a particular message share the same Message-ID value. 519 The sending user agent may break a message into chunks, which the 520 receiving user agent will reassemble to form the complete message. 521 Intermediaries such as MSRP Relays [RFC4976] might break chunks into 522 smaller chunks, or might reassemble chunks into larger ones; 523 therefore the message received by the recipient may be broken into a 524 different number of chunks than were sent by the recipient. 525 Intermediaries might also cause chunks to be received in a different 526 order than sent. 528 The sender MUST apply any S/MIME operations to the whole message 529 prior to breaking it into chunks. Likewise, the receiver needs to 530 reassemble the message from its chunks prior to decrypting, 531 validating a signature, etc. 533 MSRP chunks are framed using an end-line. The end-line comprises 534 seven hyphens, a 64-bit random value taken from the start line, and a 535 continuation flag. MRSP requires the sending user agent to scan data 536 sent in a specific chunk to be sent ensure that the end-line does not 537 accidentally occur as part of the sent data. This scanning occurs on 538 a chunk rather than a whole message, consequently it must occur after 539 the sender applies any S/MIME operations. 541 8.2. Streamed Data 543 MSRP allows a mode of operation where a UA sends some chunks of a 544 message prior to knowing the full length of the message. For 545 example, a sender might send streamed data over MSRP as a single 546 message, even though it doesn't know the full length of that data in 547 advance. This mode is incompatible with S/MIME, since a sending UA 548 must apply S/MIME operations to the entire message in advance of 549 breaking it into chunks. 551 Therefore, when sending a message in an S/MIME format, the sender 552 MUST include the Byte-Range header field for every chunk, including 553 the first chunk. The Byte-Range header field MUST include the total 554 length of the message. 556 A higher layer could choose to break such streamed data into a series 557 of messages prior to applying S/MIME operation, so that each fragment 558 appears as a distinct S/MIME separate message in MSRP. Such 559 mechanisms are beyond the scope for this document. 561 8.3. Indicating support for S/MIME 563 A UA that supports this specification MUST explicitly include the 564 appropriate media type or types in the "accept-types" attribute in 565 any SDP offer or answer that proposes MSRP. It MAY indicate that it 566 requires S/MIME wrappers for all messages by putting appropriate 567 S/MIME media types in the "accept-types" attribute and putting all 568 other supported media types in the "accept-wrapped-types" attribute. 570 For backwards compatibility, a sender MAY treat a peer that includes 571 an asterisk ("*") in the "accept-types" attribute as potentially 572 supporting S/MIME. If the peer returns an MSRP 415 response to an 573 attempt to send an S/MIME message, the sender should treat the peer 574 as not supporting S/MIME for the duration of the session, as 575 indicated in [RFC4975]. 577 While these SDP attributes allow an endpoint to express support for 578 certain media types only when wrapped in a specified envelope type, 579 it does not allow the expression of more complex structures. For 580 example, an endpoint can say that it supports text/plain and text/ 581 html, but only when inside an application/pkcs7 or message/cpim 582 container, but it cannot express a requirement for the leaf types to 583 always be contained in an application/pkcs7 container nested inside a 584 message/cpim container. This has implications for the use of S/MIME 585 with the message/cpim format. (See Section 9.1.) 587 MSRP allows multiple reporting modes that provide different levels of 588 feedback. If the sender includes a Failure-Report header field with 589 a value of "no", it will not receive failure reports. This mode 590 should not be used carelessly, since such a sender would never see a 591 415 response as described above, and would have no way to learn that 592 the recipient could not process an S/MIME body. 594 8.4. MSRP URIs 596 MSRP URIs are ephemeral. Endpoints MUST NOT use MSRP URIs to 597 identify certificates, or insert MSRP URIs into certificate Subject 598 Alternative Name fields. When MSRP sessions are negotiated using SIP 599 [RFC3261], the SIP AoRs of the peers are used instead. 601 Note that MSRP allows messages to be sent between peers in either 602 direction. A given MSRP message might be sent from the SIP offerer 603 to the SIP answerer. Thus, the sender and recipient roles may 604 reverse between one message and another in a given session. 606 8.5. Failure Cases 608 Successful delivery of an S/MIME message does not indicate that the 609 recipient successfully decrypted the contents or validated a 610 signature. Decryption and/or validation may not occur immediately on 611 receipt, since the recipient may not immediately view the message, 612 and the user agent may choose not to attempt decryption or validation 613 until the user requests it. 615 Likewise, successful delivery of S/MIME enveloped data does not, on 616 its own, indicate that the recipient supports the enclosed media 617 type. If the peer only implicitly indicated support for the enclosed 618 media type through the use of a wildcard in the "accept-types" or 619 "accept-wrapped types" SDP attributes, it may not decrypt the message 620 in time to send a 415 response. 622 9. S/MIME Interaction with other SIP Messaging Features 624 9.1. Common Profile for Instant Messaging 626 The Common Profile for Instant Messaging (CPIM) [RFC3860] defines an 627 abstract messaging service, with the goal of creating gateways 628 between different messaging protocols that could relay instant 629 messages without change. The SIP MESSAGE method and MSRP were 630 initially designed to map to the CPIM abstractions. However, at the 631 time of this writing, CPIM-compliant gateways have not been deployed. 632 To the authors' knowledge, no other IM protocols have been explicitly 633 mapped to CPIM. 635 CPIM also defines the abstract messaging URI scheme "im:". As of the 636 time of this writing, the "im:" scheme is not in common use. 638 The Common Profile for Instant Messages Message Format [RFC3862] 639 allows UAs to attach transport-neutral metadata to arbitrary MIME 640 content. The format was designed as a canonicalization format to 641 allow signed data to cross protocol-converting gateways without loss 642 of metadata needed to verify the signature. While it has not 643 typically been used for that purpose, it has been used for other 644 metadata applications, for example, Instant Message Delivery 645 Notifications (IMDN)[RFC5438] and MSRP Multi-party Chat [RFC7701] 647 In the general case, a sender applies end-to-end signature and 648 encryption operations to the entire MIME body. However, some 649 messaging systems expect to inspect and in some cases add or modify 650 metadata in CPIM header fields. For example, CPM- and RCS-based 651 services include application servers that may need to insert time 652 stamps into chat messages, and may use additional metadata to 653 characterize the content and purpose of a message to determine 654 application behavior. The former will cause validation failure for 655 signatures that cover CPIM metadata, while the latter is not possible 656 if the metadata is encrypted. Clients intended for use in such 657 networks MAY choose to apply end-to-end signatures and encryption 658 operations to only the CPIM payload, leaving the CPIM metadata 659 unprotected from inspection and modification. UAs that support 660 S/MIME and CPIM SHOULD be able validate signatures and decrypt 661 enveloped data both when those operations are applied to the entire 662 CPIM body, and when they are applied to just the CPIM payload. This 663 means that the receiver needs to be flexible in its MIME document 664 parsing and that it cannot make assumptions that S/MIME protected 665 body parts will always be in the same position or level in the 666 message payload. 668 If such clients need to encrypt or sign CPIM metadata end-to-end, 669 they can nest a protected CPIM message format payload inside an 670 unprotected CPIM message envelope. 672 The use of CPIM metadata fields to identify certificates or to 673 authenticate SIP or MSRP header fields is out of scope for this 674 document. 676 9.2. Instant Message Delivery Notifications 678 The Instant Message Delivery Notification (IMDN) mechanism [RFC5438] 679 allows both endpoints and intermediary application servers to request 680 and to generate delivery notifications. The use of S/MIME does not 681 impact strictly end-to-end use of IMDN. IMDN recommends that devices 682 that are capable of doing so sign delivery notifications. It further 683 requires that delivery notifications that result from encrypted 684 messages also be encrypted. 686 However, IMDN allows intermediary application servers to insert 687 notification requests into messages, to add routing information to 688 messages, and to act on notification requests. It also allows list 689 servers to aggregate delivery notifications. 691 Such intermediaries will be unable to read end-to-end encrypted 692 messages in order to interpret delivery notice requests. 693 Intermediaries that insert information into end-to-end signed 694 messages will cause the signature validation to fail. (See 695 Section 9.1.) 697 10. Examples 699 The following sections show examples of S/MIME messages in SIP and 700 MSRP. The examples include the tags "[start-hex]" and "[end-hex]" to 701 denote binary content shown in hexadecimal. The tags are not part of 702 the actual message, and do not count towards the Content-Length 703 header field values. 705 In all of these examples, the clear text message is the string 706 "Watson, come here - I want to see you." followed by a newline 707 character. 709 The cast of characters includes Alice, with a SIP AoR of 710 "alice@example.com", and Bob, with a SIP AoR of "bob@example.org". 712 Appendix A shows the detailed content of each S/MIME body. 714 10.1. Signed Message in SIP Including the Sender's Certificate 716 Figure 1 shows a message signed by Alice. This body uses the 717 "application/pcks7-mime" media type with an smime-type parameter 718 value of "signed-data". 720 The S/MIME body includes Alice's signing certificate. Even though 721 the original message content is fairly short and only minimal SIP 722 header fields are included, the total message size approaches the 723 maximum allowed for the SIP MESSAGE method unless the UAC has advance 724 knowledge that all SIP hops will use congestion-controlled transport 725 protocols. A message that included all the SIP header fields that 726 are commonly in use in some SIP deployments would likely exceed the 727 limit. 729 MESSAGE sip:bob@example.org SIP/2.0 730 Via: SIP/2.0/TCP alice-pc.example.com;branch=z9hG4bK776sgdkfie 731 Max-Forwards: 70 732 From: sip:alice@example.com;tag=49597 733 To: sip:bob@example.org 734 Call-ID: asd88asd66b@1.2.3.4 735 CSeq: 1 MESSAGE 736 Content-Transfer-Encoding: binary 737 Content-Type: application/pkcs7-mime; smime-type=signed-data; 738 name="smime.p7m" 739 Content-Disposition: attachment; filename="smime.p7m" 740 Content-Length: 762 742 [start-hex] 743 308202f606092a864886f70d010702a08202e7308202e3020101310d300b0609 744 608648016503040201305306092a864886f70d010701a0460444436f6e74656e 745 742d547970653a20746578742f706c61696e0d0a0d0a576174736f6e2c20636f 746 6d652068657265202d20492077616e7420746f2073656520796f752e0d0aa082 747 016b308201673082010da003020102020900b8793ec0e4c21530300a06082a86 748 48ce3d040302302631143012060355040a0c0b6578616d706c652e636f6d310e 749 300c06035504030c05416c696365301e170d3137313231393233313230355a17 750 0d3138313231393233313230355a302631143012060355040a0c0b6578616d70 751 6c652e636f6d310e300c06035504030c05416c6963653059301306072a8648ce 752 3d020106082a8648ce3d03010703420004d87b54729f2c22feebd9ddba0efa40 753 642297a6093887a4dae7990b23f87fa7ed99db8cf5a314f2ee64106ef1ed61db 754 fc0a4b91c953cbd022a751b914807bb794a324302230200603551d1104193017 755 86157369703a616c696365406578616d706c652e636f6d300a06082a8648ce3d 756 040302034800304502207879be1c27f846276fdf15e333e53c6f17a757388a02 757 cb7b8ae481c1641ae7a9022100ff99cd9c94076c82b02fea3b1350179a4b7752 758 e16fa30a3f9ab29650b0e2818931820109308201050201013033302631143012 759 060355040a0c0b6578616d706c652e636f6d310e300c06035504030c05416c69 760 6365020900b8793ec0e4c21530300b0609608648016503040201a06930180609 761 2a864886f70d010903310b06092a864886f70d010701301c06092a864886f70d 762 010905310f170d3139303132363036313335345a302f06092a864886f70d0109 763 0431220420ef778fc940d5e6dc2576f47a599b3126195a9f1a227adaf35fa22c 764 050d8d195a300a06082a8648ce3d04030204473045022005fdc2b55b0f444a46 765 be468dfc7ef3b7de30019ef0952a223e8521890b35bb4e02210090e43a9d9846 766 cf2af8159c5c0ef48848fa2f39f998b1bb99b52a6fc6c776f2c8 767 [end-hex] 769 Figure 1: Signed Message in SIP 771 10.2. Signed Message in SIP with No Certificate 773 Figure 2 shows the same message from Alice without the embedded 774 certificate. The shorter total message length may be more 775 manageable. 777 MESSAGE sip:bob@example.org SIP/2.0 778 Via: SIP/2.0/TCP alice-pc.example.com;branch=z9hG4bK776sgdkfie 779 Max-Forwards: 70 780 From: sip:alice@example.com;tag=49597 781 To: sip:bob@example.org 782 Call-ID: asd88asd66b@1.2.3.4 783 CSeq: 1 MESSAGE 784 Content-Transfer-Encoding: binary 785 Content-Type: application/pkcs7-mime; smime-type=signed-data; 786 name="smime.p7m" 787 Content-Disposition: attachment; filename="smime.p7m" 788 Content-Length: 395 790 [start-hex] 791 3082018706092a864886f70d010702a082017830820174020101310d300b0609 792 608648016503040201305306092a864886f70d010701a0460444436f6e74656e 793 742d547970653a20746578742f706c61696e0d0a0d0a576174736f6e2c20636f 794 6d652068657265202d20492077616e7420746f2073656520796f752e0d0a3182 795 0109308201050201013033302631143012060355040a0c0b6578616d706c652e 796 636f6d310e300c06035504030c05416c696365020900b8793ec0e4c21530300b 797 0609608648016503040201a069301806092a864886f70d010903310b06092a86 798 4886f70d010701301c06092a864886f70d010905310f170d3139303132363036 799 313335345a302f06092a864886f70d01090431220420ef778fc940d5e6dc2576 800 f47a599b3126195a9f1a227adaf35fa22c050d8d195a300a06082a8648ce3d04 801 03020447304502203607275592d30c8c5a931041a01804d60c638ac9a8080918 802 87172a0887c8d4aa022100cd9e14bd21817336e9052fe590af2e2bcde16dd3e9 803 48d0f5f78a969e26382682 804 [end-hex] 806 Figure 2: Signed Message in SIP with No Certificate Included 808 10.3. MSRP Signed and Encrypted Message in a Single Chunk 810 Figure 3 shows a signed and encrypted message from Bob to Alice sent 811 via MSRP. 813 MSRP dsdfoe38sd SEND 814 To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp 815 From-Path: msrp://bobpc.example.org:8888/9di4eae923wzd;tcp 816 Message-ID: 456so39s 817 Byte-Range: 1-1940/1940 818 Content-Disposition: attachment; filename="smime.p7m" 819 Content-Type: application/pkcs7-mime; smime-type=auth-enveloped-data; 820 name="smime.p7m" 822 [start-hex] 823 30820790060b2a864886f70d0109100117a082077f3082077b0201003182024f 824 3082024b0201003033302631143012060355040a0c0b6578616d706c652e636f 825 6d310e300c06035504030c05416c69636502090083f50bb70bd5c40e300d0609 826 2a864886f70d010101050004820200759a61b4ddf1f1af24668005635e476110 827 fa2723c1b9e45484b6d33e8387de967dc5e0cafb35571a56a1975cb550e7be31 828 c131da80fb731024845babb8d64cac26040424d9330561c843999415dd644b3c 829 ad95072f71451393c99f282c4883bd0ccc5dd54b931464e00a6e55e592c51a68 830 de1062516ec7d3ca8e764bb8ac789a88377765ef8dc36c0a6ed3ecae5285cac6 831 a29d5059445719a1bdcf906e0ff37e2c2ef0f4ec6225100cc062e1c748963bbc 832 88b8e3dfcf714073729dd5c7583e758acf3d186f2fa417be22c37c9a76c6b427 833 29aad27f73ae44ac98474d1eeb48948c12a403d0b3ce08a218d6af456924897c 834 c5c9664f6dfeb3f18141158dfc3b84090aa60380aa865137e1699c5c81974167 835 9d7a3c90ba79e6d7d5c8d89bb54a667423e43b0b7d6f78c0b4ab67bc343662a6 836 35fe595f1149c53950cac2e0ba318c227e6f76a8d940400fd3d3ea1c8ecea003 837 dcce2f1fb00f5cea335de1303fcbf93d8e1cbfd682f19beb624bacd1d7b8f580 838 f114a13b890894fb4044a5daa764b7f8c5ff92949452b35aeb9639b8ad63c051 839 5c95ccc6f823c2201067ea2262413fef397d48f7b6143f842ae8e1a48cad3ae0 840 1abaa3cf9ee7e36620e05cca0611bfac00eef1a498f2d259b9f0f7da83ef6f1b 841 061f387c2dc48c8b5dbaca862308f32f47925165c9e5ebb467799884918dd697 842 b447f4c407989b889b0c2e9580af783082050f06092a864886f70d010701301e 843 06096086480165030401063011040c4d8757222eac5294117f0c120201108082 844 04e0fe2fb3de0bf06998c39bf4a952fabf8b0fee3d7e2e85181aecf1a89e1a2e 845 decd9404885612dfc6984334d8602b7749b2504e45f57c3b066626b0fc746236 846 1eec267c560139be5cd286a2af9696cf51852278e52c3818cab0a68c598de4fc 847 e14a333884e4de5ddf57edd78867027a31e4a7c0c0299144c5de6bae39699e70 848 0e057eb0f0dad73b8b369f42eb321b41538781d982a11a0b3943ac10c97b54ee 849 b73b38ec131afc5610e373487274d69cafa9541902886c64f6962d42eb33f904 850 1a4ae11b88dc6958d53df50b8bb52aa35e2299885d0aae416b86f0a88d0eb7a9 851 81dbb283e8b94e9d50bf6265c2348a18a169aacb5a37a529bda2f9cb10efddcf 852 14231095d87964637bd33fb13c68b4cff9a1906960c1ea2301d325b7a15c5829 853 f3ea038f24df6b23180377d37131f75db18f41f9d85b653dfa46bf2617126326 854 ccf1cb833457752352c8417a094484d7b64bcf51b26a9beb3a0ed4b9caf1bd23 855 c690c654f7eb9ce9852e2f6d068eef8ba33bc6c4dddca7aef4d3574737d7c4dc 856 1e93770d8f4f22dea61d73083c32c4038c1eb3dd3383a89a8795e241c2ed7cb6 857 80758c041069489860fc9f490e85236072548b3249698f99953acf1ec658b7aa 858 85e554c449701a6d4b039ed103dc458df4b29cb04b8cedd540c84348da79c186 859 56d5188f9f3a9e4b9b840c70664b90296c60b7ac984e918d48a09dbddfb281fc 860 862510db59d9fa9dc93f10f9c6d7bef72931d184cad7ac13c1a5295fc89fe3bb 861 7eb8e02085a828c5a138786e607ade4f5e8d4115909209ba878a79305a5316c2 862 2229e42b886d06481c8473f9d51269e2af6341bce20f768e860d7784ed46150e 863 04ff50cd209c5b127511369fe06bc4aa9a72d8f1fe4fcf0866d664b365ffa86e 864 8c1b43e7a9212aecc16ca350a28efae25fac054dd934bfe7e5fa4f753aa41596 865 8c7ebec439e0ac0270b4874a068d22484c09d9e8abe17f1372b4b2f65f1148e8 866 933eda92e5d1774564963b391c3bbd9f1c27ffe36f832e05155fc39ee6652fa7 867 b4188975ec5c67b32c9f213c8ac6b8e132a5a7c3bf74f016405cd8c201d10521 868 93e186d44358de388d73211ba2f1792f3cfeb9bbde7211d26f56ab06e11ccc9c 869 cde2b88cd8373773eafc37fd85b7a7a2bcaec752e617d6e01c02b86e9d9a40f3 870 20462c5d66f8351716dcd6014bdf30a60f75fc0631c920845ed8c0bad35ddf19 871 84f2241cd3b529dc1028845f8089543df4f1441ede36b1bf31af5afc8c2b708d 872 50b645d4e7db88648c3eefe14765158fb0e8d3bb53ddcbe26d7124c6e1d992f8 873 3230aa953376ee8c68109568e8571f0c9bbda48f4df306fe747f371175148f31 874 832767cd766cf07b450cbf62cad2a7bd71f1f88233f116a1a7f3caf12f34bcf4 875 0d21e79ffc9827221b68b080ff03ad782d6d6d07871676f798943e54f13fd75c 876 89c0b4263bf10f56243f9e72ef3b3899a539d9a3ac5be2b69400a3cf8d196c5c 877 ed697b2ed803b987a5ee85c5095b48da7a5b03b47e2b9fe4cd4bc3098e864e0c 878 e7d467da99cd7f3a9e947b5eea77f7a6be16c8c7e9e0decc1ff132559c234321 879 7b9c2950386e85d2942121086cdfa19658195be6d7f86bca9881b695082964f1 880 2e7cf801025d6792c6882409414d703321ec83abd698d68956118713a0ff1272 881 acbc9a6d148900c74c16921df9b38f29ec46d4f10060fffe5e36bbbacaf2d1ba 882 d7dd057ed3e30ebcd69083f9d3a2a26ef90b751d6a1adfa0590db19da107cf3e 883 a8db0410f6ffc6e1aef19cd23d985a921976352d 884 [end-hex] 885 -------dsdfoe38sd$ 887 Figure 3: Signed and Encrypted Message in MSRP 889 10.4. MSRP Signed and Encrypted Message sent in Multiple Chunks 891 Figure 4 shows the same message as in Figure 3 except that the 892 message is broken into two chunks. The S/MIME operations were 893 performed prior to breaking the message into chunks. 895 MSRP d93kswow SEND 896 To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp 897 From-Path: msrp://bobpc.example.org:8888/9di4eae923wzd;tcp 898 Message-ID: 12339sdqwer 899 Byte-Range: 1-960/1940 900 Content-Disposition: attachment; filename="smime.p7m" 901 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; 902 name="smime.p7m" 904 [start-hex] 905 30820790060b2a864886f70d0109100117a082077f3082077b0201003182024f 906 3082024b0201003033302631143012060355040a0c0b6578616d706c652e636f 907 6d310e300c06035504030c05416c69636502090083f50bb70bd5c40e300d0609 908 2a864886f70d010101050004820200759a61b4ddf1f1af24668005635e476110 909 fa2723c1b9e45484b6d33e8387de967dc5e0cafb35571a56a1975cb550e7be31 910 c131da80fb731024845babb8d64cac26040424d9330561c843999415dd644b3c 911 ad95072f71451393c99f282c4883bd0ccc5dd54b931464e00a6e55e592c51a68 912 de1062516ec7d3ca8e764bb8ac789a88377765ef8dc36c0a6ed3ecae5285cac6 913 a29d5059445719a1bdcf906e0ff37e2c2ef0f4ec6225100cc062e1c748963bbc 914 88b8e3dfcf714073729dd5c7583e758acf3d186f2fa417be22c37c9a76c6b427 915 29aad27f73ae44ac98474d1eeb48948c12a403d0b3ce08a218d6af456924897c 916 c5c9664f6dfeb3f18141158dfc3b84090aa60380aa865137e1699c5c81974167 917 9d7a3c90ba79e6d7d5c8d89bb54a667423e43b0b7d6f78c0b4ab67bc343662a6 918 35fe595f1149c53950cac2e0ba318c227e6f76a8d940400fd3d3ea1c8ecea003 919 dcce2f1fb00f5cea335de1303fcbf93d8e1cbfd682f19beb624bacd1d7b8f580 920 f114a13b890894fb4044a5daa764b7f8c5ff92949452b35aeb9639b8ad63c051 921 5c95ccc6f823c2201067ea2262413fef397d48f7b6143f842ae8e1a48cad3ae0 922 1abaa3cf9ee7e36620e05cca0611bfac00eef1a498f2d259b9f0f7da83ef6f1b 923 061f387c2dc48c8b5dbaca862308f32f47925165c9e5ebb467799884918dd697 924 b447f4c407989b889b0c2e9580af783082050f06092a864886f70d010701301e 925 06096086480165030401063011040c4d8757222eac5294117f0c120201108082 926 04e0fe2fb3de0bf06998c39bf4a952fabf8b0fee3d7e2e85181aecf1a89e1a2e 927 decd9404885612dfc6984334d8602b7749b2504e45f57c3b066626b0fc746236 928 1eec267c560139be5cd286a2af9696cf51852278e52c3818cab0a68c598de4fc 929 e14a333884e4de5ddf57edd78867027a31e4a7c0c0299144c5de6bae39699e70 930 0e057eb0f0dad73b8b369f42eb321b41538781d982a11a0b3943ac10c97b54ee 931 b73b38ec131afc5610e373487274d69cafa9541902886c64f6962d42eb33f904 932 1a4ae11b88dc6958d53df50b8bb52aa35e2299885d0aae416b86f0a88d0eb7a9 933 81dbb283e8b94e9d50bf6265c2348a18a169aacb5a37a529bda2f9cb10efddcf 934 14231095d87964637bd33fb13c68b4cff9a1906960c1ea2301d325b7a15c5829 935 [end-hex] 936 -------d93kswow+ 938 MSRP op2nc9a SEND 939 To-Path: msrp://alicepc.example.com:8888/9di4eae923wzd;tcp 940 From-Path: msrp://bobpc.example.org:7654/iau39soe2843z;tcp 941 Message-ID: 12339sdqwer 942 Byte-Range: 961-1940/1940 943 Content-Disposition: attachment; filename="smime.p7m" 944 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; 945 name="smime.p7m" 947 [start-hex] 948 f3ea038f24df6b23180377d37131f75db18f41f9d85b653dfa46bf2617126326 949 ccf1cb833457752352c8417a094484d7b64bcf51b26a9beb3a0ed4b9caf1bd23 950 c690c654f7eb9ce9852e2f6d068eef8ba33bc6c4dddca7aef4d3574737d7c4dc 951 1e93770d8f4f22dea61d73083c32c4038c1eb3dd3383a89a8795e241c2ed7cb6 952 80758c041069489860fc9f490e85236072548b3249698f99953acf1ec658b7aa 953 85e554c449701a6d4b039ed103dc458df4b29cb04b8cedd540c84348da79c186 954 56d5188f9f3a9e4b9b840c70664b90296c60b7ac984e918d48a09dbddfb281fc 955 862510db59d9fa9dc93f10f9c6d7bef72931d184cad7ac13c1a5295fc89fe3bb 956 7eb8e02085a828c5a138786e607ade4f5e8d4115909209ba878a79305a5316c2 957 2229e42b886d06481c8473f9d51269e2af6341bce20f768e860d7784ed46150e 958 04ff50cd209c5b127511369fe06bc4aa9a72d8f1fe4fcf0866d664b365ffa86e 959 8c1b43e7a9212aecc16ca350a28efae25fac054dd934bfe7e5fa4f753aa41596 960 8c7ebec439e0ac0270b4874a068d22484c09d9e8abe17f1372b4b2f65f1148e8 961 933eda92e5d1774564963b391c3bbd9f1c27ffe36f832e05155fc39ee6652fa7 962 b4188975ec5c67b32c9f213c8ac6b8e132a5a7c3bf74f016405cd8c201d10521 963 93e186d44358de388d73211ba2f1792f3cfeb9bbde7211d26f56ab06e11ccc9c 964 cde2b88cd8373773eafc37fd85b7a7a2bcaec752e617d6e01c02b86e9d9a40f3 965 20462c5d66f8351716dcd6014bdf30a60f75fc0631c920845ed8c0bad35ddf19 966 84f2241cd3b529dc1028845f8089543df4f1441ede36b1bf31af5afc8c2b708d 967 50b645d4e7db88648c3eefe14765158fb0e8d3bb53ddcbe26d7124c6e1d992f8 968 3230aa953376ee8c68109568e8571f0c9bbda48f4df306fe747f371175148f31 969 832767cd766cf07b450cbf62cad2a7bd71f1f88233f116a1a7f3caf12f34bcf4 970 0d21e79ffc9827221b68b080ff03ad782d6d6d07871676f798943e54f13fd75c 971 89c0b4263bf10f56243f9e72ef3b3899a539d9a3ac5be2b69400a3cf8d196c5c 972 ed697b2ed803b987a5ee85c5095b48da7a5b03b47e2b9fe4cd4bc3098e864e0c 973 e7d467da99cd7f3a9e947b5eea77f7a6be16c8c7e9e0decc1ff132559c234321 974 7b9c2950386e85d2942121086cdfa19658195be6d7f86bca9881b695082964f1 975 2e7cf801025d6792c6882409414d703321ec83abd698d68956118713a0ff1272 976 acbc9a6d148900c74c16921df9b38f29ec46d4f10060fffe5e36bbbacaf2d1ba 977 d7dd057ed3e30ebcd69083f9d3a2a26ef90b751d6a1adfa0590db19da107cf3e 978 a8db0410f6ffc6e1aef19cd23d985a921976352d 979 [end-hex] 980 -------op2nc9a$ 982 Figure 4: MSRP Chunked Signed and Encrypted Message 984 11. IANA Considerations 986 This document makes no requests of the IANA. 988 12. Security Considerations 990 The security considerations from S/MIME 991 [I-D.ietf-lamps-rfc5750-bis][I-D.ietf-lamps-rfc5751-bis] and elliptic 992 curves in CMS [RFC5753] apply. The S/MIME related security 993 considerations from SIP [RFC3261][RFC3853], SIP MESSAGE [RFC3428], 994 and MSRP [RFC4975] apply. 996 The security considerations from algorithms recommended in this 997 document also apply, see [RFC3565], [RFC5480], [RFC5753], [RFC5754], 998 [RFC7748], [RFC8032], [RFC8419], and [RFC8418]. 1000 This document assumes that end-entity certificate validation is 1001 provided by a chain of trust to a certification authority (CA), using 1002 a public key infrastructure. The security considerations from 1003 [RFC5280] apply. However, other validations methods may be possible; 1004 for example sending a signed fingerprint for the end-entity in SDP. 1005 The relationship of this work and the techniques discussed in 1006 [RFC8224] and [I-D.ietf-sipbrandy-rtpsec] are out of scope for this 1007 document. 1009 When matching an end-entity certificate to the sender or recipient 1010 identity, the respective SIP AoRs are used. Typically these will 1011 match the SIP From and To header fields. Some UAs may extract sender 1012 identity from SIP AoRs in other header fields, for example, P- 1013 Asserted-Identity [RFC3325]. In general, the UAS should compare the 1014 certificate to the identity that it relies upon, for example for 1015 display to the end-user or comparison against message filtering 1016 rules. 1018 The secure notification use case discussed in Section 1 has 1019 significant vulnerabilities when used in an insecure environment. 1020 For example, "phishing" messages could be used to trick users into 1021 revealing credentials. Eavesdroppers could learn confirmation codes 1022 from unprotected two-factor authentication messages. Unsolicited 1023 messages sent by impersonators could tarnish the reputation of an 1024 organization. While hop-by-hop protection can mitigate some of those 1025 risks, it still leaves messages vulnerable to malicious or 1026 compromised intermediaries. End-to-end protection prevents 1027 modification by intermedies. However, neither provide much 1028 protection unless the recipient knows to expect messages from a 1029 particular sender to be signed and refuses to accept unsigned 1030 messages that appear to be from that source. 1032 Mobile messaging is typically an online application; online 1033 certificate revocation checks should usually be feasible. 1035 S/MIME does not normally protect the SIP or MSRP headers. While it 1036 normally does protect the CPIM header, certain CPIM header fields may 1037 not be protected if the sender excludes them from the encrypted or 1038 signed part of the message. (See Section 9.1.) Certain messaging 1039 services, for example those based on RCS, may include intermediaries 1040 that attach metadata to user generated messages in the form of SIP, 1041 MSRP, or CPIM header fields. This metadata could possibly reveal 1042 information to third parties that the sender might prefer not to send 1043 as cleartext. Implementors and operators should consider whether 1044 inserted metadata may create privacy leaks. Such an analysis is 1045 beyond the scope of this document. 1047 MSRP messages broken into chunks must be reassembled by the recipient 1048 prior to decrypting or validation of signatures (see Section 8.1). 1049 Section 14.5 of [RFC4975] describes a potential denial of service 1050 attack where the attacker puts large values in the byte-range header 1051 field. Implementations should sanity check these values before 1052 allocating memory space for reassembly. 1054 Modification of the ciphertext in EnvelopedData can go undetected if 1055 authentication is not also used, which is the case when sending 1056 EnvelopedData without wrapping it in SignedData or enclosing 1057 SignedData within it. This is one of the reasons for moving from 1058 EnvelopedData to AuthEnvelopedData, as the authenticated encryption 1059 algorithms provide the authentication without needing the SignedData 1060 layer. 1062 An attack on S/MIME implementations of HTML and multipart/mixed 1063 messages is highlighted in [Efail]. To avoid this attack, clients 1064 MUST ensure that a text/html content type is a complete HTML 1065 document. Clients SHOULD treat each of the different pieces of the 1066 multipart/mixed construct as coming from different origins. Clients 1067 MUST treat each encrypted or signed piece of a MIME message as being 1068 from different origins both from unprotected content and from each 1069 other. 1071 13. References 1073 13.1. Normative References 1075 [I-D.ietf-lamps-rfc5750-bis] 1076 Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 1077 Multipurpose Internet Mail Extensions (S/ MIME) Version 1078 4.0 Certificate Handling", draft-ietf-lamps-rfc5750-bis-08 1079 (work in progress), September 2018. 1081 [I-D.ietf-lamps-rfc5751-bis] 1082 Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 1083 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 1084 Message Specification", draft-ietf-lamps-rfc5751-bis-12 1085 (work in progress), September 2018. 1087 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1088 Requirement Levels", BCP 14, RFC 2119, 1089 DOI 10.17487/RFC2119, March 1997, 1090 . 1092 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1093 A., Peterson, J., Sparks, R., Handley, M., and E. 1094 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1095 DOI 10.17487/RFC3261, June 2002, 1096 . 1098 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1099 with Session Description Protocol (SDP)", RFC 3264, 1100 DOI 10.17487/RFC3264, June 2002, 1101 . 1103 [RFC3428] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., 1104 Huitema, C., and D. Gurle, "Session Initiation Protocol 1105 (SIP) Extension for Instant Messaging", RFC 3428, 1106 DOI 10.17487/RFC3428, December 2002, 1107 . 1109 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) 1110 Encryption Algorithm in Cryptographic Message Syntax 1111 (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003, 1112 . 1114 [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) 1115 Requirement for the Session Initiation Protocol (SIP)", 1116 RFC 3853, DOI 10.17487/RFC3853, July 2004, 1117 . 1119 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1120 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1121 July 2006, . 1123 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 1124 "The Message Session Relay Protocol (MSRP)", RFC 4975, 1125 DOI 10.17487/RFC4975, September 2007, 1126 . 1128 [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated 1129 Encryption in the Cryptographic Message Syntax (CMS)", 1130 RFC 5084, DOI 10.17487/RFC5084, November 2007, 1131 . 1133 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1134 Housley, R., and W. Polk, "Internet X.509 Public Key 1135 Infrastructure Certificate and Certificate Revocation List 1136 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1137 . 1139 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 1140 "Elliptic Curve Cryptography Subject Public Key 1141 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 1142 . 1144 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1145 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1146 . 1148 [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve 1149 Cryptography (ECC) Algorithms in Cryptographic Message 1150 Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January 1151 2010, . 1153 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 1154 Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 1155 2010, . 1157 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1158 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1159 May 2017, . 1161 [RFC8418] Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key 1162 Agreement Algorithm with X25519 and X448 in the 1163 Cryptographic Message Syntax (CMS)", RFC 8418, 1164 DOI 10.17487/RFC8418, August 2018, 1165 . 1167 [RFC8419] Housley, R., "Use of Edwards-Curve Digital Signature 1168 Algorithm (EdDSA) Signatures in the Cryptographic Message 1169 Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419, August 1170 2018, . 1172 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 1173 One (ASN.1): Specification of basic notation", 1174 ITU-T Recommendation X.680, 2015. 1176 [X690] ITU-T, "Information Technology -- ASN.1 encoding rules: 1177 Specification of Basic Encoding Rules (BER), Canonical 1178 Encoding Rules (CER) and Distinguished Encoding Rules 1179 (DER)", ITU-T Recommendation X.690, 2015. 1181 13.2. Informative References 1183 [CPM] Open Mobile Alliance, "OMA Converged IP Messaging System 1184 Description, Candidate Version 2.2", September 2017. 1186 [Efail] Poddebniak, D., Dresen, C., Muller, J., Ising, F., 1187 Schinzel, S., Friedberger, S., and J. Somorovsky, "Efail: 1188 Breaking S/MIME and OpenPGP Email Encryption using 1189 Exfiltration Channels", August 2018, 1190 . 1193 [I-D.ietf-sipbrandy-rtpsec] 1194 Peterson, J., Barnes, R., and R. Housley, "Best Practices 1195 for Securing RTP Media Signaled with SIP", draft-ietf- 1196 sipbrandy-rtpsec-06 (work in progress), October 2018. 1198 [RCS] GSMA, "RCS Universal Profile Service Definition Document, 1199 Version 2.0", June 2017. 1201 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1202 Extensions to the Session Initiation Protocol (SIP) for 1203 Asserted Identity within Trusted Networks", RFC 3325, 1204 DOI 10.17487/RFC3325, November 2002, 1205 . 1207 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1208 "Indicating User Agent Capabilities in the Session 1209 Initiation Protocol (SIP)", RFC 3840, 1210 DOI 10.17487/RFC3840, August 2004, 1211 . 1213 [RFC3860] Peterson, J., "Common Profile for Instant Messaging 1214 (CPIM)", RFC 3860, DOI 10.17487/RFC3860, August 2004, 1215 . 1217 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 1218 Messaging (CPIM): Message Format", RFC 3862, 1219 DOI 10.17487/RFC3862, August 2004, 1220 . 1222 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1223 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1224 . 1226 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 1227 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 1228 DOI 10.17487/RFC4976, September 2007, 1229 . 1231 [RFC5438] Burger, E. and H. Khartabil, "Instant Message Disposition 1232 Notification (IMDN)", RFC 5438, DOI 10.17487/RFC5438, 1233 February 2009, . 1235 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 1236 Protocol (XMPP): Instant Messaging and Presence", 1237 RFC 6121, DOI 10.17487/RFC6121, March 2011, 1238 . 1240 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1241 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 1242 2015, . 1244 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 1245 RFC 7516, DOI 10.17487/RFC7516, May 2015, 1246 . 1248 [RFC7701] Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi- 1249 party Chat Using the Message Session Relay Protocol 1250 (MSRP)", RFC 7701, DOI 10.17487/RFC7701, December 2015, 1251 . 1253 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1254 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1255 2016, . 1257 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1258 Signature Algorithm (EdDSA)", RFC 8032, 1259 DOI 10.17487/RFC8032, January 2017, 1260 . 1262 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 1263 "Authenticated Identity Management in the Session 1264 Initiation Protocol (SIP)", RFC 8224, 1265 DOI 10.17487/RFC8224, February 2018, 1266 . 1268 Appendix A. Message Details 1270 The following section shows the detailed content of the S/MIME bodies 1271 used in Section 10. 1273 A.1. Signed Message 1275 Figure 5 shows the details of the message signed by Alice used in the 1276 example in Section 10.1. 1278 CMS_ContentInfo: 1279 contentType: pkcs7-signedData (1.2.840.113549.1.7.2) 1280 d.signedData: 1281 version: 1 1282 digestAlgorithms: 1283 algorithm: sha256 (2.16.840.1.101.3.4.2.1) 1284 parameter: 1285 encapContentInfo: 1286 eContentType: pkcs7-data (1.2.840.113549.1.7.1) 1287 eContent: 1288 0000 - 43 6f 6e 74 65 6e 74 2d-54 79 70 65 3a 20 74 Content-Type: t 1289 000f - 65 78 74 2f 70 6c 61 69-6e 0d 0a 0d 0a 57 61 ext/plain....Wa 1290 001e - 74 73 6f 6e 2c 20 63 6f-6d 65 20 68 65 72 65 tson, come here 1291 002d - 20 2d 20 49 20 77 61 6e-74 20 74 6f 20 73 65 - I want to se 1292 003c - 65 20 79 6f 75 2e 0d 0a- e you... 1293 certificates: 1294 d.certificate: 1295 cert_info: 1297 version: 2 1298 serialNumber: 13292724773353297200 1299 signature: 1300 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1301 parameter: 1302 issuer: O=example.com, CN=Alice 1303 validity: 1304 notBefore: Dec 19 23:12:05 2017 GMT 1305 notAfter: Dec 19 23:12:05 2018 GMT 1306 subject: O=example.com, CN=Alice 1307 key: 1308 algor: 1309 algorithm: id-ecPublicKey (1.2.840.10045.2.1) 1310 parameter: OBJECT:prime256v1 (1.2.840.10045.3.1.7) 1311 public_key: (0 unused bits) 1312 0000 - 04 d8 7b 54 72 9f 2c 22-fe eb d9 dd ba 0e ..{Tr.,"...... 1313 000e - fa 40 64 22 97 a6 09 38-87 a4 da e7 99 0b .@d"...8...... 1314 001c - 23 f8 7f a7 ed 99 db 8c-f5 a3 14 f2 ee 64 #............d 1315 002a - 10 6e f1 ed 61 db fc 0a-4b 91 c9 53 cb d0 .n..a...K..S.. 1316 0038 - 22 a7 51 b9 14 80 7b b7-94 ".Q...{.. 1317 issuerUID: 1318 subjectUID: 1319 extensions: 1320 object: X509v3 Subject Alternative Name (2.5.29.17) 1321 critical: BOOL ABSENT 1322 value: 1323 0000 - 30 17 86 15 73 69 70 3a-61 6c 69 63 65 0...sip:alice 1324 000d - 40 65 78 61 6d 70 6c 65-2e 63 6f 6d @example.com 1325 sig_alg: 1326 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1327 parameter: 1328 signature: (0 unused bits) 1329 0000 - 30 45 02 20 78 79 be 1c-27 f8 46 27 6f df 15 0E. xy..'.F'o.. 1330 000f - e3 33 e5 3c 6f 17 a7 57-38 8a 02 cb 7b 8a e4 .3. 1336 signerInfos: 1337 version: 1 1338 d.issuerAndSerialNumber: 1339 issuer: O=example.com, CN=Alice 1340 serialNumber: 13292724773353297200 1341 digestAlgorithm: 1342 algorithm: sha256 (2.16.840.1.101.3.4.2.1) 1343 parameter: 1344 signedAttrs: 1346 object: contentType (1.2.840.113549.1.9.3) 1347 set: 1348 OBJECT:pkcs7-data (1.2.840.113549.1.7.1) 1350 object: signingTime (1.2.840.113549.1.9.5) 1351 set: 1352 UTCTIME:Jan 24 23:52:56 2019 GMT 1354 object: messageDigest (1.2.840.113549.1.9.4) 1355 set: 1356 OCTET STRING: 1357 0000 - ef 77 8f c9 40 d5 e6 dc-25 76 f4 7a 59 .w..@...%v.zY 1358 000d - 9b 31 26 19 5a 9f 1a 22-7a da f3 5f a2 .1&.Z.."z.._. 1359 001a - 2c 05 0d 8d 19 5a ,....Z 1360 signatureAlgorithm: 1361 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1362 parameter: 1363 signature: 1364 0000 - 30 45 02 20 58 79 cc 62-85 e0 86 06 19 d3 bf 0E. Xy.b....... 1365 000f - 53 d4 67 9f 03 73 d7 45-20 cf 56 10 c2 55 5b S.g..s.E .V..U[ 1366 001e - 7b ec 61 d4 72 dc 02 21-00 83 aa 53 44 28 4d {.a.r..!...SD(M 1367 002d - 4c ef de 31 07 9c f9 71-bd 69 5d 6e c8 71 e9 L..1...q.i]n.q. 1368 003c - a4 60 ec 2e 12 65 2b 77-a4 62 4d .`...e+w.bM 1369 unsignedAttrs: 1370 1372 Figure 5: Signed Message 1374 A.2. Short Signed Message 1376 Figure 6 shows the message signed by Alice with no imbedded 1377 certificate, as used in the example in Section 10.2. 1379 CMS_ContentInfo: 1380 contentType: pkcs7-signedData (1.2.840.113549.1.7.2) 1381 d.signedData: 1382 version: 1 1383 digestAlgorithms: 1384 algorithm: sha256 (2.16.840.1.101.3.4.2.1) 1385 parameter: 1386 encapContentInfo: 1387 eContentType: pkcs7-data (1.2.840.113549.1.7.1) 1388 eContent: 1389 0000 - 43 6f 6e 74 65 6e 74 2d-54 79 70 65 3a 20 74 Content-Type: t 1390 000f - 65 78 74 2f 70 6c 61 69-6e 0d 0a 0d 0a 57 61 ext/plain....Wa 1391 001e - 74 73 6f 6e 2c 20 63 6f-6d 65 20 68 65 72 65 tson, come here 1392 002d - 20 2d 20 49 20 77 61 6e-74 20 74 6f 20 73 65 - I want to se 1393 003c - 65 20 79 6f 75 2e 0d 0a- e you... 1395 certificates: 1396 1397 crls: 1398 1399 signerInfos: 1400 version: 1 1401 d.issuerAndSerialNumber: 1402 issuer: O=example.com, CN=Alice 1403 serialNumber: 13292724773353297200 1404 digestAlgorithm: 1405 algorithm: sha256 (2.16.840.1.101.3.4.2.1) 1406 parameter: 1407 signedAttrs: 1408 object: contentType (1.2.840.113549.1.9.3) 1409 set: 1410 OBJECT:pkcs7-data (1.2.840.113549.1.7.1) 1412 object: signingTime (1.2.840.113549.1.9.5) 1413 set: 1414 UTCTIME:Jan 24 23:52:56 2019 GMT 1416 object: messageDigest (1.2.840.113549.1.9.4) 1417 set: 1418 OCTET STRING: 1419 0000 - ef 77 8f c9 40 d5 e6 dc-25 76 f4 7a 59 .w..@...%v.zY 1420 000d - 9b 31 26 19 5a 9f 1a 22-7a da f3 5f a2 .1&.Z.."z.._. 1421 001a - 2c 05 0d 8d 19 5a ,....Z 1422 signatureAlgorithm: 1423 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1424 parameter: 1425 signature: 1426 0000 - 30 44 02 20 1c 51 6e ed-9c 10 10 a2 87 e1 11 0D. .Qn........ 1427 000f - 6b af 76 1d f1 c4 e6 48-da ea 17 89 bc e2 8a k.v....H....... 1428 001e - 9d 8a f4 a4 ae f9 02 20-72 7f 5e 4b cc e2 0b ....... r.^K... 1429 002d - cf 3c af 07 c8 1c 11 64-f0 21 e7 70 e0 f6 a0 .<.....d.!.p... 1430 003c - 96 2e 0a 7b 19 b7 42 ad-cb 34 ...{..B..4 1431 unsignedAttrs: 1432 1434 Figure 6: Signed Message without Imbedded Certificate 1436 A.3. Signed and Encrypted Message 1438 The following sections show details for the message signed by Bob and 1439 encrypted to Alice, as used in the examples in Section 10.3 and 1440 Section 10.4. 1442 A.3.1. Signed Message Prior to Encryption 1444 CMS_ContentInfo: 1445 contentType: pkcs7-signedData (1.2.840.113549.1.7.2) 1446 d.signedData: 1447 version: 1 1448 digestAlgorithms: 1449 algorithm: sha256 (2.16.840.1.101.3.4.2.1) 1450 parameter: 1451 encapContentInfo: 1452 eContentType: pkcs7-data (1.2.840.113549.1.7.1) 1453 eContent: 1454 0000 - 43 6f 6e 74 65 6e 74 2d-54 79 70 65 3a 20 74 Content-Type: t 1455 000f - 65 78 74 2f 70 6c 61 69-6e 0d 0a 0d 0a 57 61 ext/plain....Wa 1456 001e - 74 73 6f 6e 2c 20 63 6f-6d 65 20 68 65 72 65 tson, come here 1457 002d - 20 2d 20 49 20 77 61 6e-74 20 74 6f 20 73 65 - I want to se 1458 003c - 65 20 79 6f 75 2e 0d 0a- e you... 1459 certificates: 1460 d.certificate: 1461 cert_info: 1462 version: 2 1463 serialNumber: 11914627415941064473 1464 signature: 1465 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1466 parameter: 1467 issuer: O=example.org, CN=Bob 1468 validity: 1469 notBefore: Dec 20 23:07:49 2017 GMT 1470 notAfter: Dec 20 23:07:49 2018 GMT 1471 subject: O=example.org, CN=Bob 1472 key: 1473 algor: 1474 algorithm: id-ecPublicKey (1.2.840.10045.2.1) 1475 parameter: OBJECT:prime256v1 (1.2.840.10045.3.1.7) 1476 public_key: (0 unused bits) 1477 0000 - 04 86 4f ff fc 53 f1 a8-76 ca 69 b1 7e 27 ..O..S..v.i.~' 1478 000e - 48 7a 07 9c 71 52 ae 1b-13 7e 39 3b af 1a Hz..qR...~9;.. 1479 001c - ae bd 12 74 3c 7d 41 43-a2 fd 8a 37 0f 02 ...t<}AC...7.. 1480 002a - ba 9d 03 b7 30 1f 1d a6-4e 30 55 94 bb 6f ....0...N0U..o 1481 0038 - 95 cb 71 fa 48 b6 d0 a3-83 ..q.H.... 1482 issuerUID: 1483 subjectUID: 1484 extensions: 1485 object: X509v3 Subject Alternative Name (2.5.29.17) 1486 critical: TRUE 1487 value: 1488 0000 - 30 15 86 13 73 69 70 3a-62 6f 62 40 65 0...sip:bob@e 1489 000d - 78 61 6d 70 6c 65 2e 6f-72 67 xample.org 1490 sig_alg: 1491 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1492 parameter: 1493 signature: (0 unused bits) 1494 0000 - 30 45 02 21 00 b2 24 8c-92 40 28 22 38 9e c9 0E.!..$..@("8.. 1495 000f - 25 7f 64 cc fd 10 6f ba-0b 96 c1 19 07 30 34 %.d...o......04 1496 001e - d5 1b 10 2f 73 39 6c 02-20 15 8e b1 51 f0 85 .../s9l. ...Q.. 1497 002d - b9 bd 2e 04 cf 27 8f 0d-52 2e 6b b6 fe 4f 36 .....'..R.k..O6 1498 003c - f7 4c 77 10 b1 5a 4f 47-9d e4 0d .Lw..ZOG... 1499 crls: 1500 1501 signerInfos: 1502 version: 1 1503 d.issuerAndSerialNumber: 1504 issuer: O=example.org, CN=Bob 1505 serialNumber: 11914627415941064473 1506 digestAlgorithm: 1507 algorithm: sha256 (2.16.840.1.101.3.4.2.1) 1508 parameter: 1509 signedAttrs: 1510 object: contentType (1.2.840.113549.1.9.3) 1511 set: 1512 OBJECT:pkcs7-data (1.2.840.113549.1.7.1) 1514 object: signingTime (1.2.840.113549.1.9.5) 1515 set: 1516 UTCTIME:Jan 24 23:52:56 2019 GMT 1518 object: messageDigest (1.2.840.113549.1.9.4) 1519 set: 1520 OCTET STRING: 1521 0000 - ef 77 8f c9 40 d5 e6 dc-25 76 f4 7a 59 .w..@...%v.zY 1522 000d - 9b 31 26 19 5a 9f 1a 22-7a da f3 5f a2 .1&.Z.."z.._. 1523 001a - 2c 05 0d 8d 19 5a ,....Z 1524 signatureAlgorithm: 1525 algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2) 1526 parameter: 1527 signature: 1528 0000 - 30 45 02 21 00 f7 88 ed-44 6a b7 0f ff 2c 1f 0E.!....Dj...,. 1529 000f - fa 4c 03 74 fd 08 77 fd-61 ee 91 7c 31 45 b3 .L.t..w.a..|1E. 1530 001e - 89 a6 76 15 c7 46 fa 02-20 77 94 ad c5 7f 00 ..v..F.. w..... 1531 002d - 61 c7 84 b9 61 23 cc 6e-54 bb 82 82 65 b6 d4 a...a#.nT...e.. 1532 003c - cc 12 99 76 a6 b1 fc 6d-bc 28 d6 ...v...m.(. 1533 unsignedAttrs: 1534 1536 Figure 7: Message Signed by Bob prior to Encryption 1538 A.3.2. Encrypted Message 1540 CMS_ContentInfo: 1541 contentType: pkcs7-authEnvelopedData (1.2.840.113549.1.9.16.1.23) 1542 d.authEnvelopedData: 1543 version: 0 1544 originatorInfo: 1545 recipientInfos: 1546 d.ktri: 1547 version: 1548 d.issuerAndSerialNumber: 1549 issuer: O=example.com, CN=Alice 1550 serialNumber: 9508519069068149774 1551 keyEncryptionAlgorithm: 1552 algorithm: rsaEncryption (1.2.840.113549.1.1.1) 1553 parameter: NULL 1554 encryptedKey: 1555 0000 - 75 9a 61 b4 dd f1 f1 af-24 66 80 05 63 5e 47 u.a.....$f..c^G 1556 000f - 61 10 fa 27 23 c1 b9 e4-54 84 b6 d3 3e 83 87 a..'#...T...>.. 1557 001e - de 96 7d c5 e0 ca fb 35-57 1a 56 a1 97 5c b5 ..}....5W.V..\. 1558 002d - 50 e7 be 31 c1 31 da 80-fb 73 10 24 84 5b ab P..1.1...s.$.[. 1559 003c - b8 d6 4c ac 26 04 04 24-d9 33 05 61 c8 43 99 ..L.&..$.3.a.C. 1560 004b - 94 15 dd 64 4b 3c ad 95-07 2f 71 45 13 93 c9 ...dK<.../qE... 1561 005a - 9f 28 2c 48 83 bd 0c cc-5d d5 4b 93 14 64 e0 .(,H....].K..d. 1562 0069 - 0a 6e 55 e5 92 c5 1a 68-de 10 62 51 6e c7 d3 .nU....h..bQn.. 1563 0078 - ca 8e 76 4b b8 ac 78 9a-88 37 77 65 ef 8d c3 ..vK..x..7we... 1564 0087 - 6c 0a 6e d3 ec ae 52 85-ca c6 a2 9d 50 59 44 l.n...R.....PYD 1565 0096 - 57 19 a1 bd cf 90 6e 0f-f3 7e 2c 2e f0 f4 ec W.....n..~,.... 1566 00a5 - 62 25 10 0c c0 62 e1 c7-48 96 3b bc 88 b8 e3 b%...b..H.;.... 1567 00b4 - df cf 71 40 73 72 9d d5-c7 58 3e 75 8a cf 3d ..q@sr...X>u..= 1568 00c3 - 18 6f 2f a4 17 be 22 c3-7c 9a 76 c6 b4 27 29 .o/...".|.v..') 1569 00d2 - aa d2 7f 73 ae 44 ac 98-47 4d 1e eb 48 94 8c ...s.D..GM..H.. 1570 00e1 - 12 a4 03 d0 b3 ce 08 a2-18 d6 af 45 69 24 89 ...........Ei$. 1571 00f0 - 7c c5 c9 66 4f 6d fe b3-f1 81 41 15 8d fc 3b |..fOm....A...; 1572 00ff - 84 09 0a a6 03 80 aa 86-51 37 e1 69 9c 5c 81 ........Q7.i.\. 1573 010e - 97 41 67 9d 7a 3c 90 ba-79 e6 d7 d5 c8 d8 9b .Ag.z<..y...... 1574 011d - b5 4a 66 74 23 e4 3b 0b-7d 6f 78 c0 b4 ab 67 .Jft#.;.}ox...g 1575 012c - bc 34 36 62 a6 35 fe 59-5f 11 49 c5 39 50 ca .46b.5.Y_.I.9P. 1576 013b - c2 e0 ba 31 8c 22 7e 6f-76 a8 d9 40 40 0f d3 ...1."~ov..@@.. 1577 014a - d3 ea 1c 8e ce a0 03 dc-ce 2f 1f b0 0f 5c ea ........./...\. 1578 0159 - 33 5d e1 30 3f cb f9 3d-8e 1c bf d6 82 f1 9b 3].0?..=....... 1579 0168 - eb 62 4b ac d1 d7 b8 f5-80 f1 14 a1 3b 89 08 .bK.........;.. 1580 0177 - 94 fb 40 44 a5 da a7 64-b7 f8 c5 ff 92 94 94 ..@D...d....... 1581 0186 - 52 b3 5a eb 96 39 b8 ad-63 c0 51 5c 95 cc c6 R.Z..9..c.Q\... 1582 0195 - f8 23 c2 20 10 67 ea 22-62 41 3f ef 39 7d 48 .#. .g."bA?.9}H 1583 01a4 - f7 b6 14 3f 84 2a e8 e1-a4 8c ad 3a e0 1a ba ...?.*.....:... 1584 01b3 - a3 cf 9e e7 e3 66 20 e0-5c ca 06 11 bf ac 00 .....f .\...... 1585 01c2 - ee f1 a4 98 f2 d2 59 b9-f0 f7 da 83 ef 6f 1b ......Y......o. 1587 01d1 - 06 1f 38 7c 2d c4 8c 8b-5d ba ca 86 23 08 f3 ..8|-...]...#.. 1588 01e0 - 2f 47 92 51 65 c9 e5 eb-b4 67 79 98 84 91 8d /G.Qe....gy.... 1589 01ef - d6 97 b4 47 f4 c4 07 98-9b 88 9b 0c 2e 95 80 ...G........... 1590 01fe - af 78 .x 1591 authEncryptedContentInfo: 1592 contentType: pkcs7-data (1.2.840.113549.1.7.1) 1593 contentEncryptionAlgorithm: 1594 algorithm: aes-128-gcm (2.16.840.1.101.3.4.1.6) 1595 parameter: 1596 aes-nonce: 1597 0000 - 4d 87 57 22 2e ac 52 94-11 7f 0c 12 M.W"..R..... 1598 aes-ICVlen: 16 1599 encryptedContent: 1600 0000 - fe 2f b3 de 0b f0 69 98-c3 9b f4 a9 52 fa bf ./....i.....R.. 1601 000f - 8b 0f ee 3d 7e 2e 85 18-1a ec f1 a8 9e 1a 2e ...=~.......... 1602 001e - de cd 94 04 88 56 12 df-c6 98 43 34 d8 60 2b .....V....C4..+ 1603 002d - 77 49 b2 50 4e 45 f5 7c-3b 06 66 26 b0 fc 74 wI.PNE.|..f&..t 1604 003c - 62 36 1e ec 26 7c 56 01-39 be 5c d2 86 a2 af b6..&|V.9.\.... 1605 004b - 96 96 cf 51 85 22 78 e5-2c 38 18 ca b0 a6 8c ...Q."x.,8..... 1606 005a - 59 8d e4 fc e1 4a 33 38-84 e4 de 5d df 57 ed Y....J38...].W. 1607 0069 - d7 88 67 02 7a 31 e4 a7-c0 c0 29 91 44 c5 de ..g.z1....).D.. 1608 0078 - 6b ae 39 69 9e 70 0e 05-7e b0 f0 da d7 3b 8b k.9i.p..~...... 1609 0087 - 36 9f 42 eb 32 1b 41 53-87 81 d9 82 a1 1a 0b 6.B.2.AS....... 1610 0096 - 39 43 ac 10 c9 7b 54 ee-b7 3b 38 ec 13 1a fc 9C...{T...8.... 1611 00a5 - 56 10 e3 73 48 72 74 d6-9c af a9 54 19 02 88 V..sHrt....T... 1612 00b4 - 6c 64 f6 96 2d 42 eb 33-f9 04 1a 4a e1 1b 88 ld..-B.3...J... 1613 00c3 - dc 69 58 d5 3d f5 0b 8b-b5 2a a3 5e 22 99 88 .iX.=....*.^".. 1614 00d2 - 5d 0a ae 41 6b 86 f0 a8-8d 0e b7 a9 81 db b2 ]..Ak.......... 1615 00e1 - 83 e8 b9 4e 9d 50 bf 62-65 c2 34 8a 18 a1 69 ...N.P.be.4...i 1616 00f0 - aa cb 5a 37 a5 29 bd a2-f9 cb 10 ef dd cf 14 ..Z7.)......... 1617 00ff - 23 10 95 d8 79 64 63 7b-d3 3f b1 3c 68 b4 cf #...ydc{.?.. 1648 02c1 - 92 e5 d1 77 45 64 96 3b-39 1c 3b bd 9f 1c 27 ...wEd..9...... 1649 02d0 - ff e3 6f 83 2e 05 15 5f-c3 9e e6 65 2f a7 b4 ..o...._...e/.. 1650 02df - 18 89 75 ec 5c 67 b3 2c-9f 21 3c 8a c6 b8 e1 ..u.\g.,.!<.... 1651 02ee - 32 a5 a7 c3 bf 74 f0 16-40 5c d8 c2 01 d1 05 2....t..@\..... 1652 02fd - 21 93 e1 86 d4 43 58 de-38 8d 73 21 1b a2 f1 !....CX.8.s!... 1653 030c - 79 2f 3c fe b9 bb de 72-11 d2 6f 56 ab 06 e1 y/<....r..oV... 1654 031b - 1c cc 9c cd e2 b8 8c d8-37 37 73 ea fc 37 fd ........77s..7. 1655 032a - 85 b7 a7 a2 bc ae c7 52-e6 17 d6 e0 1c 02 b8 .......R....... 1656 0339 - 6e 9d 9a 40 f3 20 46 2c-5d 66 f8 35 17 16 dc n..@..F,]f.5... 1657 0348 - d6 01 4b df 30 a6 0f 75-fc 06 31 c9 20 84 5e ..K.0..u..1...^ 1658 0357 - d8 c0 ba d3 5d df 19 84-f2 24 1c d3 b5 29 dc ....]....$...). 1659 0366 - 10 28 84 5f 80 89 54 3d-f4 f1 44 1e de 36 b1 .(._..T=..D..6. 1660 0375 - bf 31 af 5a fc 8c 2b 70-8d 50 b6 45 d4 e7 db .1.Z..+p.P.E... 1661 0384 - 88 64 8c 3e ef e1 47 65-15 8f b0 e8 d3 bb 53 .d.>..Ge......S 1662 0393 - dd cb e2 6d 71 24 c6 e1-d9 92 f8 32 30 aa 95 ...mq$.....20.. 1663 03a2 - 33 76 ee 8c 68 10 95 68-e8 57 1f 0c 9b bd a4 3v..h..h.W..... 1664 03b1 - 8f 4d f3 06 fe 74 7f 37-11 75 14 8f 31 83 27 .M...t.7.u..1.. 1665 03c0 - 67 cd 76 6c f0 7b 45 0c-bf 62 ca d2 a7 bd 71 g.vl.{E..b....q 1666 03cf - f1 f8 82 33 f1 16 a1 a7-f3 ca f1 2f 34 bc f4 ...3......./4.. 1667 03de - 0d 21 e7 9f fc 98 27 22-1b 68 b0 80 ff 03 ad .!.....".h..... 1668 03ed - 78 2d 6d 6d 07 87 16 76-f7 98 94 3e 54 f1 3f x-mm...v...>T.? 1669 03fc - d7 5c 89 c0 b4 26 3b f1-0f 56 24 3f 9e 72 ef .\...&...V$?.r. 1670 040b - 3b 38 99 a5 39 d9 a3 ac-5b e2 b6 94 00 a3 cf .8..9...[...... 1671 041a - 8d 19 6c 5c ed 69 7b 2e-d8 03 b9 87 a5 ee 85 ..l\.i{........ 1672 0429 - c5 09 5b 48 da 7a 5b 03-b4 7e 2b 9f e4 cd 4b ..[H.z[..~+...K 1673 0438 - c3 09 8e 86 4e 0c e7 d4-67 da 99 cd 7f 3a 9e ....N...g....:. 1674 0447 - 94 7b 5e ea 77 f7 a6 be-16 c8 c7 e9 e0 de cc .{^.w.......... 1675 0456 - 1f f1 32 55 9c 23 43 21-7b 9c 29 50 38 6e 85 ..2U.#C!{.)P8n. 1676 0465 - d2 94 21 21 08 6c df a1-96 58 19 5b e6 d7 f8 ..!!.l...X.[... 1677 0474 - 6b ca 98 81 b6 95 08 29-64 f1 2e 7c f8 01 02 k......)d..|... 1678 0483 - 5d 67 92 c6 88 24 09 41-4d 70 33 21 ec 83 ab ]g...$.AMp3!... 1679 0492 - d6 98 d6 89 56 11 87 13-a0 ff 12 72 ac bc 9a ....V......r... 1680 04a1 - 6d 14 89 00 c7 4c 16 92-1d f9 b3 8f 29 ec 46 m....L......).F 1681 04b0 - d4 f1 00 60 ff fe 5e 36-bb ba ca f2 d1 ba d7 ......^6....... 1682 04bf - dd 05 7e d3 e3 0e bc d6-90 83 f9 d3 a2 a2 6e ..~...........n 1683 04ce - f9 0b 75 1d 6a 1a df a0-59 0d b1 9d a1 07 cf ..u.j...Y...... 1685 04dd - 3e a8 db >.. 1686 authAttrs: 1687 1688 mac: 1689 0000 - f6 ff c6 e1 ae f1 9c d2-3d 98 5a 92 19 76 35 ........=.Z..v5 1690 000f - 2d - 1691 unauthAttrs: 1692 1694 Figure 8 1696 Authors' Addresses 1698 Ben Campbell 1699 Standard Velocity 1700 204 Touchdown Dr 1701 Irving, TX 75063 1702 US 1704 Email: ben@nostrum.com 1706 Russ Housley 1707 Vigil Security 1708 516 Dranesville Rd 1709 Herndon, VA 20170 1710 US 1712 Email: housley@vigilsec.com