< draft-campbell-sip-messaging-smime-03.txt   draft-campbell-sip-messaging-smime-04.txt >
Network Working Group B. Campbell Network Working Group B. Campbell
Internet-Draft Standard Velocity Internet-Draft Standard Velocity
Updates: RFC 3261, RFC 3428, RFC 4975 R. Housley Updates: 3261, 3428, 4975 (if approved) R. Housley
(if approved) Vigil Security Intended status: Standards Track Vigil Security
Intended status: Standards Track June 25, 2018 Expires: April 21, 2019 October 18, 2018
Expires: December 27, 2018
Securing Session Initiation Protocol (SIP) based Messaging with S/MIME Securing Session Initiation Protocol (SIP) based Messaging with S/MIME
draft-campbell-sip-messaging-smime-03 draft-campbell-sip-messaging-smime-04
Abstract Abstract
Mobile messaging applications used with the Session Initiation Mobile messaging applications used with the Session Initiation
Protocol (SIP) commonly use some combination of the SIP MESSAGE Protocol (SIP) commonly use some combination of the SIP MESSAGE
method and the Message Session Relay Protocol (MSRP). While these method and the Message Session Relay Protocol (MSRP). While these
provide mechanisms for hop-by-hop security, neither natively provides provide mechanisms for hop-by-hop security, neither natively provides
end-to-end protection. This document offers guidance on how to end-to-end protection. This document offers guidance on how to
provide end-to-end authentication, integrity protection, and provide end-to-end authentication, integrity protection, and
confidentiality using the Secure/Multipurpose Internet Mail confidentiality using the Secure/Multipurpose Internet Mail
skipping to change at page 1, line 40 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 27, 2018. This Internet-Draft will expire on April 21, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 23
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement and Scope . . . . . . . . . . . . . . . . . 4 3. Problem Statement and Scope . . . . . . . . . . . . . . . . . 4
4. Applicability of S/MIME . . . . . . . . . . . . . . . . . . . 5 4. Applicability of S/MIME . . . . . . . . . . . . . . . . . . . 5
4.1. Signed Messages . . . . . . . . . . . . . . . . . . . . . 5 4.1. Signed Messages . . . . . . . . . . . . . . . . . . . . . 5
4.2. Encrypted Messages . . . . . . . . . . . . . . . . . . . 6 4.2. Encrypted Messages . . . . . . . . . . . . . . . . . . . 6
4.3. Signed and Encrypted Messages . . . . . . . . . . . . . . 7 4.3. Signed and Encrypted Messages . . . . . . . . . . . . . . 7
4.4. Certificate Handling . . . . . . . . . . . . . . . . . . 8 4.4. Certificate Handling . . . . . . . . . . . . . . . . . . 8
4.4.1. Subject Alternative Name . . . . . . . . . . . . . . 8 4.4.1. Subject Alternative Name . . . . . . . . . . . . . . 8
4.4.2. Certificate Validation . . . . . . . . . . . . . . . 8 4.4.2. Certificate Validation . . . . . . . . . . . . . . . 8
5. Transfer Encoding . . . . . . . . . . . . . . . . . . . . . . 8 5. Transfer Encoding . . . . . . . . . . . . . . . . . . . . . . 8
6. User Agent Capabilities . . . . . . . . . . . . . . . . . . . 9 6. User Agent Capabilities . . . . . . . . . . . . . . . . . . . 8
7. Using S/MIME with the SIP MESSAGE Method . . . . . . . . . . 9 7. Using S/MIME with the SIP MESSAGE Method . . . . . . . . . . 9
7.1. Size Limit . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Size Limit . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. User Agent Capabilities . . . . . . . . . . . . . . . . . 10 7.2. User Agent Capabilities . . . . . . . . . . . . . . . . . 10
7.3. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 10 7.3. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 10
8. Using S/MIME with MSRP . . . . . . . . . . . . . . . . . . . 11 8. Using S/MIME with MSRP . . . . . . . . . . . . . . . . . . . 11
8.1. Chunking . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Chunking . . . . . . . . . . . . . . . . . . . . . . . . 11
8.2. Streamed Data . . . . . . . . . . . . . . . . . . . . . . 12 8.2. Streamed Data . . . . . . . . . . . . . . . . . . . . . . 12
8.3. Indicating support for S/MIME . . . . . . . . . . . . . . 12 8.3. Indicating support for S/MIME . . . . . . . . . . . . . . 12
8.4. MSRP URIs . . . . . . . . . . . . . . . . . . . . . . . . 13 8.4. MSRP URIs . . . . . . . . . . . . . . . . . . . . . . . . 13
8.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 13 8.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 13
skipping to change at page 3, line 5 skipping to change at page 3, line 4
Chunks . . . . . . . . . . . . . . . . . . . . . . . . . 19 Chunks . . . . . . . . . . . . . . . . . . . . . . . . . 19
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
12. Security Considerations . . . . . . . . . . . . . . . . . . . 21 12. Security Considerations . . . . . . . . . . . . . . . . . . . 21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
13.1. Normative References . . . . . . . . . . . . . . . . . . 22 13.1. Normative References . . . . . . . . . . . . . . . . . . 22
13.2. Informative References . . . . . . . . . . . . . . . . . 24 13.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Message Details . . . . . . . . . . . . . . . . . . 26 Appendix A. Message Details . . . . . . . . . . . . . . . . . . 26
A.1. Signed Message . . . . . . . . . . . . . . . . . . . . . 26 A.1. Signed Message . . . . . . . . . . . . . . . . . . . . . 26
A.2. Short Signed Message . . . . . . . . . . . . . . . . . . 29 A.2. Short Signed Message . . . . . . . . . . . . . . . . . . 29
A.3. Signed and Encrypted Message . . . . . . . . . . . . . . 30 A.3. Signed and Encrypted Message . . . . . . . . . . . . . . 30
A.3.1. Signed Message Prior to Encryption . . . . . . . . . 31 A.3.1. Signed Message Prior to Encryption . . . . . . . . . 30
A.3.2. Encrypted Message . . . . . . . . . . . . . . . . . . 33 A.3.2. Encrypted Message . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
Several Mobile Messaging systems use the Session Initiation Protocol Several Mobile Messaging systems use the Session Initiation Protocol
(SIP) [RFC3261], typically as some combination of the SIP MESSAGE (SIP) [RFC3261], typically as some combination of the SIP MESSAGE
method [RFC3428] and the Message Session Relay Protocol (MSRP) method [RFC3428] and the Message Session Relay Protocol (MSRP)
[RFC4975]. For example, Voice over LTE (VoLTE) uses the SIP MESSAGE [RFC4975]. For example, Voice over LTE (VoLTE) uses the SIP MESSAGE
method to send Short Message Service (SMS) messages. The Open Mobile method to send Short Message Service (SMS) messages. The Open Mobile
skipping to change at page 3, line 46 skipping to change at page 3, line 45
on S/MIME [RFC5750][RFC5751]. However at the time of this writing, on S/MIME [RFC5750][RFC5751]. However at the time of this writing,
S/MIME is not in common use for SIP and MSRP based messaging S/MIME is not in common use for SIP and MSRP based messaging
services. This document updates and clarifies RFC 3261, RFC 3428, services. This document updates and clarifies RFC 3261, RFC 3428,
and RFC 4975 in an attempt to make the S/MIME for SIP and MSRP easier and RFC 4975 in an attempt to make the S/MIME for SIP and MSRP easier
to implement and deploy in an interoperable fashion. to implement and deploy in an interoperable fashion.
This document updates RFC 3261, RFC 3428, and RFC 4975 to update the This document updates RFC 3261, RFC 3428, and RFC 4975 to update the
cryptographic algorithm recommendations and the handling of S/MIME cryptographic algorithm recommendations and the handling of S/MIME
data objects. It updates RFC 3261 to allow S/MIME signed messages to data objects. It updates RFC 3261 to allow S/MIME signed messages to
be sent without imbedded certificates in some situations. Finally, be sent without imbedded certificates in some situations. Finally,
it updates RFC 3261, RFC 3428 and RFC 4975 to clarify error reporting it updates RFC 3261, RFC 3428, and RFC 4975 to clarify error
requirements for certain situations. reporting requirements for certain situations.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Problem Statement and Scope 3. Problem Statement and Scope
This document discusses the use of S/MIME with SIP based messaging. This document discusses the use of S/MIME with SIP-based messaging.
Other standardized messaging protocols exist, such as the Extensible Other standardized messaging protocols exist, such as the Extensible
Messaging and Presence Protocol (XMPP) [RFC6121]. Likewise, other Messaging and Presence Protocol (XMPP) [RFC6121]. Likewise, other
end-to-end protection formats exist, such as JSON Web Signatures end-to-end protection formats exist, such as JSON Web Signatures
[RFC7515] and JSON Web Encryption [RFC7516]. [RFC7515] and JSON Web Encryption [RFC7516].
This document focuses on SIP-based messaging because its use is This document focuses on SIP-based messaging because its use is
becoming more common in mobile environments. It focuses on S/MIME becoming more common in mobile environments. It focuses on S/MIME
since several mobile operating systems already have S/MIME libraries since several mobile operating systems already have S/MIME libraries
installed. While there may also be value in specifying end-to-end installed. While there may also be value in specifying end-to-end
security for other messaging and security mechanisms, it is out of security for other messaging and security mechanisms, it is out of
scope for this document. scope for this document.
MSRP sessions are negotiated using the Session Description Protocol MSRP sessions are negotiated using the Session Description Protocol
(SDP) [RFC4566] offer/answer mechanism [RFC3264] or similar (SDP) [RFC4566] offer/answer mechanism [RFC3264] or similar
mechanisms. This document assumes that SIP is used for the offer/ mechanisms. This document assumes that SIP is used for the offer/
answer exchange. However, the techniques should be adaptable to answer exchange. However, the techniques should be adaptable to
other signaling protocols. other signaling protocols.
[RFC3261], [RFC3428], and [RFC4975] already describe the use of [RFC3261], [RFC3428], and [RFC4975] already describe the use of
S/MIME. [RFC3853] updates SIP to support the Advanced Encryption S/MIME. [RFC3853] updates SIP to support the Advanced Encryption
Standard (AES). In aggregate that guidance is incomplete, contains Standard (AES). In aggregate that guidance is incomplete, contains
inconsistencies, and is still out of date in terms of supported and inconsistencies, and is still out of date in terms of supported and
recommended algorithms. recommended algorithms.
The guidance in RFC 3261 is based on an implicit assumption that The guidance in RFC 3261 is based on an implicit assumption that
S/MIME is being used to secure signaling applications. That advice S/MIME is being used to secure signaling applications. That advice
is not entirely appropriate for messaging application. For example, is not entirely appropriate for messaging application. For example,
it assumes that message decryption always happens before the SIP it assumes that message decryption always happens before the SIP
transaction completes. transaction completes.
This document offers normative updates and clarifications to the use This document offers normative updates and clarifications to the use
of S/MIME with the SIP MESSAGE method and MSRP. It does not attempt of S/MIME with the SIP MESSAGE method and MSRP. It does not attempt
to define a complete secure messaging system. Such system would to define a complete secure messaging system. Such system would
require considerable work around user enrollment, certificate and key require considerable work around user enrollment, certificate and key
generation and management, multiparty chats, device management, etc. generation and management, multiparty chats, device management, etc.
While nothing herein should preclude those efforts, they are out of While nothing herein should preclude those efforts, they are out of
scope for this document. scope for this document.
This document primarily covers the sending of single messages, for This document primarily covers the sending of single messages, for
example "pager-mode messages" send using the SIP MESSAGE method and example "pager-mode messages" sent using the SIP MESSAGE method and
"large messages" sent in MSRP. Techniques to use a common signing or "large messages" sent in MSRP. Techniques to use a common signing or
encryption key across a session of messages are out of scope for this encryption key across a session of messages are out of scope for this
document. document.
Cryptographic algorithm requirements in this document are intended Cryptographic algorithm requirements in this document are intended to
supplement those already specified for SIP and MSRP. supplement those already specified for SIP and MSRP.
4. Applicability of S/MIME 4. Applicability of S/MIME
The Cryptographic Message Syntax (CMS) [RFC5652] is an encapsulation The Cryptographic Message Syntax (CMS) [RFC5652] is an encapsulation
syntax that is used to digitally sign, digest, authenticate, or syntax that is used to digitally sign, digest, authenticate, or
encrypt arbitrary message content. The CMS supports a variety of encrypt arbitrary message content. The CMS supports a variety of
architectures for certificate-based key management, especially the architectures for certificate-based key management, especially the
one defined by the IETF PKIX (Public Key Infrastructure using X.509) one defined by the IETF PKIX (Public Key Infrastructure using X.509)
working group [RFC5280]. The CMS values are generated using ASN.1 working group [RFC5280]. The CMS values are generated using ASN.1
skipping to change at page 5, line 46 skipping to change at page 5, line 46
risk of "helpful" tampering by intermediaries, a common cause of risk of "helpful" tampering by intermediaries, a common cause of
signature validation failure. This risk is also present for signature validation failure. This risk is also present for
messaging applications; for example, intermediaries might insert messaging applications; for example, intermediaries might insert
Instant Message Delivery notification requests into messages (see Instant Message Delivery notification requests into messages (see
Section 9.2). The application/pkcs7-mime format is also more Section 9.2). The application/pkcs7-mime format is also more
compact, which can be important for messaging applications, compact, which can be important for messaging applications,
especially when using the SIP MESSAGE method (see Section 7.1). The especially when using the SIP MESSAGE method (see Section 7.1). The
use of multipart/signed may still make sense if the message needs to use of multipart/signed may still make sense if the message needs to
be readable by receiving agents that do not support S/MIME. be readable by receiving agents that do not support S/MIME.
When generating a signed message, sending user agents (UAs) SHOULD When generating a signed message, sending user agents (UA) SHOULD
follow the conventions specified in [RFC5751] for the application/ follow the conventions specified in [RFC5751] for the application/
pkcs7-mime media type with smime-type=signed-data. When validating a pkcs7-mime media type with smime-type=signed-data. When validating a
signed message, receiving UAs MUST follow the conventions specified signed message, receiving UAs MUST follow the conventions specified
in [RFC5751] for the application/pkcs7-mime media type with smime- in [RFC5751] for the application/pkcs7-mime media type with smime-
type=signed-data. type=signed-data.
Sending and receiving UAs MUST support the SHA-256 message digest Sending and receiving UAs MUST support the SHA-256 message digest
algorithm [RFC5754]. For convenience, the SHA-256 algorithm algorithm [RFC5754]. For convenience, the SHA-256 algorithm
identifier is repeated here: identifier is repeated here:
skipping to change at page 6, line 20 skipping to change at page 6, line 20
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 1 } csor(3) nistalgorithm(4) hashalgs(2) 1 }
Sending and receiving UAs MAY support other message digest Sending and receiving UAs MAY support other message digest
algorithms. algorithms.
Sending and receiving UAs MUST support the Elliptic Curve Digital Sending and receiving UAs MUST support the Elliptic Curve Digital
Signature Algorithm (ECDSA) using the NIST P256 elliptic curve and Signature Algorithm (ECDSA) using the NIST P256 elliptic curve and
the SHA-256 message digest algorithm [RFC5480][RFC5753]. Sending and the SHA-256 message digest algorithm [RFC5480][RFC5753]. Sending and
receiving UAs SHOULD support the Edwards-curve Digital Signature receiving UAs SHOULD support the Edwards-curve Digital Signature
Algorithm (EdDSA) with curve25519 (Ed25519) Algorithm (EdDSA) with curve25519 (Ed25519) [RFC8032][RFC8419]. For
[RFC8032][I-D.ietf-curdle-cms-eddsa-signatures]. For convenience, convenience, the ECDSA with SHA-256 algorithm identifier, the object
the ECDSA with SHA-256 algorithm identifier, the object identifier identifier for the well-known NIST P256 elliptic curve, and the
for the well-known NIST P256 elliptic curve, and the Ed25519 Ed25519 algorithm identifier are repeated here:
algorithm identifier are repeated here:
ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { ecdsa-with-SHA256 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
ecdsa-with-SHA2(3) 2 } ecdsa-with-SHA2(3) 2 }
-- Note: the NIST P256 elliptic curve is also known as secp256r1. -- Note: the NIST P256 elliptic curve is also known as secp256r1.
secp256r1 OBJECT IDENTIFIER ::= { secp256r1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3) iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3)
prime(1) 7 } prime(1) 7 }
skipping to change at page 7, line 12 skipping to change at page 7, line 8
encryption [RFC3565]. For convenience, the AES-128-CBC algorithm encryption [RFC3565]. For convenience, the AES-128-CBC algorithm
identifier is repeated here: identifier is repeated here:
id-aes128-CBC OBJECT IDENTIFIER ::= { id-aes128-CBC OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistAlgorithm(4) aes(1) 2 } csor(3) nistAlgorithm(4) aes(1) 2 }
Sending and receiving UAs MAY support other content encryption Sending and receiving UAs MAY support other content encryption
algorithms. algorithms.
Sending and receiving UAs MUST support the AES-128-WRAP for Sending and receiving UAs MUST support the AES-128-WRAP algorithm for
encryption of one AES key with another AES key [RFC3565]. For encryption of one AES key with another AES key [RFC3565]. For
convenience, the AES-128-WRAP algorithm identifier is repeated here: convenience, the AES-128-WRAP algorithm identifier is repeated here:
id-aes128-wrap OBJECT IDENTIFIER ::= { id-aes128-wrap OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistAlgorithm(4) aes(1) 5 } csor(3) nistAlgorithm(4) aes(1) 5 }
Sending and receiving UAs MAY support other key encryption Sending and receiving UAs MAY support other key encryption
algorithms. algorithms.
Symmetric key-encryption keys can be distributed before messages are Symmetric key-encryption keys can be distributed before messages are
sent. If sending and receiving UAs support previously distributed sent. If sending and receiving UAs support previously distributed
key-encryption keys, then they MUST assign a KEK identifier [RFC5652] key-encryption keys, then they MUST assign a KEK identifier [RFC5652]
to the previously distributed symmetric key. to the previously distributed symmetric key.
Alternatively, a key agreement algorithm can be used to establish a Alternatively, a key agreement algorithm can be used to establish a
single-use key-encryption key. If sending and receiving UAs support single-use key-encryption key. If sending and receiving UAs support
key agreement, then they MUST support the Elliptic Curve Diffie- key agreement, then they MUST support the Elliptic Curve Diffie-
Hellman (ECDH) using the NIST P256 elliptic curve and the ANSI- Hellman (ECDH) algorithm using the NIST P256 elliptic curve and the
X9.63-KDF key derivation function with the SHA-256 message digest ANSI-X9.63-KDF key derivation function with the SHA-256 message
algorithm [RFC5753]. If sending and receiving UAs support key digest algorithm [RFC5753]. If sending and receiving UAs support key
agreement, then they SHOULD support the Elliptic Curve Diffie-Hellman agreement, then they SHOULD support the Elliptic Curve Diffie-Hellman
(ECDH) using curve25519 (X25519) (ECDH) algorithm using curve25519 (X25519) [RFC7748][RFC8418]. For
[RFC7748][I-D.ietf-curdle-cms-ecdh-new-curves]. For convenience, the convenience, the identifers for the ECDH algorithm using the ANSI-
ECDH using the ANSI-X9.63-KDF with SHA-256 algorithm identifier and X9.63-KDF with SHA-256 algorithm and for the X25519 algorithm are
the X25519 algorithm identifier are repeated here: repeated here:
dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= { dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) iso(1) identified-organization(3) certicom(132)
schemes(1) 11 1 } schemes(1) 11 1 }
id-X25519 OBJECT IDENTIFIER ::= { 1 3 101 110 } id-X25519 OBJECT IDENTIFIER ::= { 1 3 101 110 }
4.3. Signed and Encrypted Messages 4.3. Signed and Encrypted Messages
RFC 3261 section 23.2 says that when a UAC sends signed and encrypted RFC 3261 section 23.2 says that when a User Agent Client (UAC) sends
data, it should send an EnvelopedData object encapsulated within a signed and encrypted data, it should send an EnvelopedData object
SignedData message. That essentially says that one should encrypt encapsulated within a SignedData message. That essentially says that
first, then sign. This document updates RFC 3261 to say that, when one should encrypt first, then sign. This document updates RFC 3261
sending signed and encrypted user content in a SIP MESSAGE request, to say that, when sending signed and encrypted user content in a SIP
the sending UAs MUST sign the message first, and then encrypt it. MESSAGE request, the sending UAs MUST sign the message first, and
That is, it must send the SignedData object inside an EnvelopedData then encrypt it. That is, it must send the SignedData object inside
object. an EnvelopedData object.
4.4. Certificate Handling 4.4. Certificate Handling
Sending and receiving UAs MUST follow the S/MIME certificate handling Sending and receiving UAs MUST follow the S/MIME certificate handling
procedures [RFC5750], with a few exceptions detailed below. procedures [RFC5750], with a few exceptions detailed below.
4.4.1. Subject Alternative Name 4.4.1. Subject Alternative Name
In both SIP and MSRP, the identity of the sender of a message is In both SIP and MSRP, the identity of the sender of a message is
typically expressed a SIP URI. typically expressed as a SIP URI.
The subject alternative name extension is used as the preferred means The subject alternative name extension is used as the preferred means
to convey the SIP URI of the subject of a certificate. Any SIP URI to convey the SIP URI of the subject of a certificate. Any SIP URI
present MUST be encoded using the uniformResourceIdentifier CHOICE of present MUST be encoded using the uniformResourceIdentifier CHOICE of
the GeneralName type as described in [RFC5280], Section 4.2.1.6. the GeneralName type as described in [RFC5280], Section 4.2.1.6.
Since the SubjectAltName type is a SEQUENCE OF GeneralName, multiple Since the SubjectAltName type is a SEQUENCE OF GeneralName, multiple
URIs MAY be present. URIs MAY be present.
Other methods of identifying a certificate subject MAY be used. Other methods of identifying a certificate subject MAY be used.
skipping to change at page 9, line 37 skipping to change at page 9, line 30
signatures for clear-signed messages MUST also indicate support for signatures for clear-signed messages MUST also indicate support for
"application/pkcs7-signature". "application/pkcs7-signature".
A UA can indicate that it can receive all smime-types by advertising A UA can indicate that it can receive all smime-types by advertising
"application/pkcs7-mime" with no parameters. If a UA does not accept "application/pkcs7-mime" with no parameters. If a UA does not accept
all smime-types, it advertises the media type with the appropriate all smime-types, it advertises the media type with the appropriate
parameters. If more than one are supported, the UA includes a parameters. If more than one are supported, the UA includes a
separate instance of the media-type string, appropriately separate instance of the media-type string, appropriately
parameterized, for each. parameterized, for each.
For example, a UA that can only received signed-data would advertise For example, a UA that can only receive signed-data would advertise
"application/pkcs7-mime; smime-type=signed-data". "application/pkcs7-mime; smime-type=signed-data".
SIP signaling can fork to multiple destinations for a given Address SIP signaling can fork to multiple destinations for a given Address
of Record (AoR). A user might have multiple UAs with different of Record (AoR). A user might have multiple UAs with different
capabilities; the capabilities remembered from an interaction with capabilities; the capabilities remembered from an interaction with
one such UA might not apply to another. one such UA might not apply to another.
UAs can also advertise or discover S/MIME using out of band UAs can also advertise or discover S/MIME using out-of-band
mechanisms. Such mechanisms are beyond the scope of this document. mechanisms. Such mechanisms are beyond the scope of this document.
7. Using S/MIME with the SIP MESSAGE Method 7. Using S/MIME with the SIP MESSAGE Method
The use of S/MIME with the SIP MESSAGE method is described in section The use of S/MIME with the SIP MESSAGE method is described in section
11.3 of [RFC3428], and for SIP in general in section 23 of [RFC3261]. 11.3 of [RFC3428], and for SIP in general in section 23 of [RFC3261].
This section and its child sections offer clarifications for the use This section and its child sections offer clarifications for the use
of S/MIME with the SIP MESSAGE method, along with related updates to of S/MIME with the SIP MESSAGE method, along with related updates to
RFC 3261 and RFC 3428. RFC 3261 and RFC 3428.
skipping to change at page 10, line 51 skipping to change at page 10, line 49
Section 23.2 of [RFC3261] requires that the recipient of a SIP Section 23.2 of [RFC3261] requires that the recipient of a SIP
request that includes a body part of an unsupported media type and a request that includes a body part of an unsupported media type and a
Content-Disposition header "handling" parameter of "required" return Content-Disposition header "handling" parameter of "required" return
a 415 "Unsupported Media Type" response. Given that SIP MESSAGE a 415 "Unsupported Media Type" response. Given that SIP MESSAGE
exists for no reason other than to deliver content in the body, it is exists for no reason other than to deliver content in the body, it is
reasonable to treat the top-level body part as always required. reasonable to treat the top-level body part as always required.
However [RFC3428] makes no such assertion. This document updates However [RFC3428] makes no such assertion. This document updates
section 11.3 [RFC3428] to add the statement that a UAC that receives section 11.3 [RFC3428] to add the statement that a UAC that receives
a SIP MESSAGE request with an unsupported media type MUST return a a SIP MESSAGE request with an unsupported media type MUST return a
415 Unsupported Media Type" response. 415 "Unsupported Media Type" response.
Section 23.2 of [RFC3261] says that if a recipient receives an S/MIME Section 23.2 of [RFC3261] says that if a recipient receives an S/MIME
body encrypted to the wrong certificate, it MUST return a SIP 493 body encrypted to the wrong certificate, it MUST return a SIP 493
(Undecipherable) response, and SHOULD send a valid certificate in (Undecipherable) response, and SHOULD send a valid certificate in
that response. This is not always possible in practice for SIP that response. This is not always possible in practice for SIP
MESSAGE requests. The User Agent Server (UAS) may choose not to MESSAGE requests. The User Agent Server (UAS) may choose not to
decrypt a message until the user is ready to read it. Messages may decrypt a message until the user is ready to read it. Messages may
be delivered to a message store, or sent via a store-and-forward be delivered to a message store, or sent via a store-and-forward
service. This document updates RFC 3261 to say that the UAS SHOULD service. This document updates RFC 3261 to say that the UAS SHOULD
return a SIP 493 response if it immediately attempts to decrypt the return a SIP 493 response if it immediately attempts to decrypt the
skipping to change at page 12, line 50 skipping to change at page 12, line 48
as not supporting S/MIME for the duration of the session, as as not supporting S/MIME for the duration of the session, as
indicated in [RFC4975]. indicated in [RFC4975].
While these SDP attributes allow an endpoint to express support for While these SDP attributes allow an endpoint to express support for
certain media types only when wrapped in a specified envelope type, certain media types only when wrapped in a specified envelope type,
it does not allow the expression of more complex structures. For it does not allow the expression of more complex structures. For
example, an endpoint can say that it supports text/plain and text/ example, an endpoint can say that it supports text/plain and text/
html, but only when inside an application/pkcs7 or message/cpim html, but only when inside an application/pkcs7 or message/cpim
container, but it cannot express a requirement for the leaf types to container, but it cannot express a requirement for the leaf types to
always be contained in an application/pkcs7 container nested inside a always be contained in an application/pkcs7 container nested inside a
message/cpim container. This has implications for the use of s/mime message/cpim container. This has implications for the use of S/MIME
with the message/cpim format. (See Section 9.1.) with the message/cpim format. (See Section 9.1.)
MSRP allows multiple reporting modes that provide different levels of MSRP allows multiple reporting modes that provide different levels of
feedback. If the sender includes a Failure-Report header field with feedback. If the sender includes a Failure-Report header field with
a value of "no", it will not receive failure reports. This mode a value of "no", it will not receive failure reports. This mode
should not be used carelessly, since such a sender would never see a should not be used carelessly, since such a sender would never see a
415 response as described above, and would have no way to learn that 415 response as described above, and would have no way to learn that
the recipient could not process an S/MIME body. the recipient could not process an S/MIME body.
8.4. MSRP URIs 8.4. MSRP URIs
MSRP URIs are ephemeral. Endpoints MUST NOT use MSRP URIs to MSRP URIs are ephemeral. Endpoints MUST NOT use MSRP URIs to
identify certificates, or insert MSRP URIs into certificate Subject identify certificates, or insert MSRP URIs into certificate Subject
Alternative Name fields. When MSRP sessions are negotiated using SIP Alternative Name fields. When MSRP sessions are negotiated using SIP
[RFC3261], the SIP AoRs of the peers are used instead. [RFC3261], the SIP AoRs of the peers are used instead.
Note that MSRP allows messages to be sent between peers in either Note that MSRP allows messages to be sent between peers in either
direction. A given MSRP message might be sent from the SIP offerer direction. A given MSRP message might be sent from the SIP offerer
to the SIP answer. Thus, the the sender and recipient roles may to the SIP answerer. Thus, the sender and recipient roles may
reverse between one message and another in a given session. reverse between one message and another in a given session.
8.5. Failure Cases 8.5. Failure Cases
Successful delivery of an S/MIME message does not indicate that the Successful delivery of an S/MIME message does not indicate that the
recipient successfully decrypted the contents or validated a recipient successfully decrypted the contents or validated a
signature. Decryption and/or validation may not occur immediately on signature. Decryption and/or validation may not occur immediately on
receipt, since since the recipient may not immediately view the receipt, since the recipient may not immediately view the message,
message, and the user agent may choose not to attempt decryption or and the user agent may choose not to attempt decryption or validation
validation until the user requests it. until the user requests it.
Likewise, successful delivery of S/MIME enveloped data does not, on Likewise, successful delivery of S/MIME enveloped data does not, on
its own, indicate that the recipient supports the enclosed media its own, indicate that the recipient supports the enclosed media
type. If the peer only implicitly indicated support for the enclosed type. If the peer only implicitly indicated support for the enclosed
media type through the use of a wildcard in the "accept-types" or media type through the use of a wildcard in the "accept-types" or
"accept-wrapped types" SDP attributes, it may not decrypt the message "accept-wrapped types" SDP attributes, it may not decrypt the message
in time to send a 415 response. in time to send a 415 response.
9. S/MIME Interaction with other SIP Messaging Features 9. S/MIME Interaction with other SIP Messaging Features
skipping to change at page 14, line 14 skipping to change at page 14, line 11
CPIM also defines the abstract messaging URI scheme "im:". As of the CPIM also defines the abstract messaging URI scheme "im:". As of the
time of this writing, the "im:" scheme is not in common use. time of this writing, the "im:" scheme is not in common use.
The Common Profile for Instant Messages Message Format [RFC3862] The Common Profile for Instant Messages Message Format [RFC3862]
allows UAs to attach transport-neutral metadata to arbitrary MIME allows UAs to attach transport-neutral metadata to arbitrary MIME
content. The format was designed as a canonicalization format to content. The format was designed as a canonicalization format to
allow signed data to cross protocol-converting gateways without loss allow signed data to cross protocol-converting gateways without loss
of metadata needed to verify the signature. While it has not of metadata needed to verify the signature. While it has not
typically been used for that purpose, it has been used for other typically been used for that purpose, it has been used for other
metadata applications, for example, Intant Message Delivery metadata applications, for example, Instant Message Delivery
Notifications (IMDN)[RFC5438] and MSRP Multi-party Chat [RFC7701] Notifications (IMDN)[RFC5438] and MSRP Multi-party Chat [RFC7701]
In the general case, a sender applies end-to-end signature and In the general case, a sender applies end-to-end signature and
encryption operations to the entire MIME body. However, some encryption operations to the entire MIME body. However, some
messaging systems expect to inspect and in some cases add or modify messaging systems expect to inspect and in some cases add or modify
metadata in CPIM header fields. For example, CPM and RCS based metadata in CPIM header fields. For example, CPM and RCS based
service include application servers that may need to insert time service include application servers that may need to insert time
stamps into chat messages, and may use additional metadata to stamps into chat messages, and may use additional metadata to
characterize the content and purpose of a message to determine characterize the content and purpose of a message to determine
application behavior. The former will cause validation failure for application behavior. The former will cause validation failure for
skipping to change at page 14, line 44 skipping to change at page 14, line 41
If such clients need to provide encrypt or sign CPIM metadata end-to- If such clients need to provide encrypt or sign CPIM metadata end-to-
end, they can nest a protected CPIM message format payload inside an end, they can nest a protected CPIM message format payload inside an
unprotected CPIM message envelope. unprotected CPIM message envelope.
The use of CPIM metadata fields to identify certificates or to The use of CPIM metadata fields to identify certificates or to
authenticate SIP or MSRP header fields is out of scope for this authenticate SIP or MSRP header fields is out of scope for this
document. document.
9.2. Instant Message Delivery Notifications 9.2. Instant Message Delivery Notifications
The Instant Message Delivery Notification (IMDN) mechanism[RFC5438] The Instant Message Delivery Notification (IMDN) mechanism [RFC5438]
allows both endpoints and intermediary application servers to request allows both endpoints and intermediary application servers to request
and to generate delivery notifications. The use of S/MIME does not and to generate delivery notifications. The use of S/MIME does not
impact strictly end-to-end use of IMDN. IMDN recommends that devices impact strictly end-to-end use of IMDN. IMDN recommends that devices
that are capable of doing so sign delivery notifications. It further that are capable of doing so sign delivery notifications. It further
requires that delivery notifications that result from encrypted requires that delivery notifications that result from encrypted
messages also be encrypted. messages also be encrypted.
However, IMDN allows intermediary application servers to insert However, IMDN allows intermediary application servers to insert
notification requests into messages, to add routing information to notification requests into messages, to add routing information to
messages, and to act on notification requests. It also allows list messages, and to act on notification requests. It also allows list
skipping to change at page 15, line 22 skipping to change at page 15, line 17
Intermediaries that insert information into end-to-end signed Intermediaries that insert information into end-to-end signed
messages will cause the signature validation to fail. (See messages will cause the signature validation to fail. (See
Section 9.1.) Section 9.1.)
10. Examples 10. Examples
The following sections show examples of S/MIME messages in SIP and The following sections show examples of S/MIME messages in SIP and
MSRP. The examples include the tags "[start-hex]" and "[end-hex]" to MSRP. The examples include the tags "[start-hex]" and "[end-hex]" to
denote binary content shown in hexadecimal. The tags are not part of denote binary content shown in hexadecimal. The tags are not part of
the actual message, and do not count towards the Content-Length the actual message, and do not count towards the Content-Length
header field values. Some SIP header fields are folded to avoid over header field values. Some SIP header fields are folded to avoid
running the margins. Folded lines contain leading white space at the overrunning the margins. Folded lines contain leading white space at
beginning of the line. These folds would not exist in the actual the beginning of the line. These folds would not exist in the actual
message. message.
In all of these examples, the clear text message is the string In all of these examples, the clear text message is the string
"Watson, come here - I want to see you." followed by a newline "Watson, come here - I want to see you." followed by a newline
character. character.
The cast of characters includes Alice, with a SIP AoR of The cast of characters includes Alice, with a SIP AoR of
"alice@example.com", and Bob, with a SIP AoR of "bob@example.org". "alice@example.com", and Bob, with a SIP AoR of "bob@example.org".
Appendix A shows the detailed content of each S/MIME body. Appendix A shows the detailed content of each S/MIME body.
10.1. Signed Message in SIP Including the Sender's Certificate 10.1. Signed Message in SIP Including the Sender's Certificate
Figure 1 shows a message signed by Alice. This body uses the Figure 1 shows a message signed by Alice. This body uses the
"application/pcks7-mime" media type with a smime-type parameter value "application/pcks7-mime" media type with an smime-type parameter
of "signed-data". value of "signed-data".
The S/MIME body includes Alice's signing certificate. Even though The S/MIME body includes Alice's signing certificate. Even though
the original message content is fairly short and only minimal SIP the original message content is fairly short and only minimal SIP
header fields are included, the total message size is 1300 octets. header fields are included, the total message size is 1300 octets.
This is the maximum allowed for the SIP MESSAGE method unless the UAC This is the maximum allowed for the SIP MESSAGE method unless the UAC
has advance knowledge that no hop will use a transport protocol has advance knowledge that no hop will use a transport protocol
without congestion control. without congestion control.
MESSAGE sip:bob@example.org SIP/2.0 MESSAGE sip:bob@example.org SIP/2.0
Via: SIP/2.0/TCP alice-pc.example.com;branch=z9hG4bK776sgdkfie Via: SIP/2.0/TCP alice-pc.example.com;branch=z9hG4bK776sgdkfie
skipping to change at page 21, line 28 skipping to change at page 21, line 28
12. Security Considerations 12. Security Considerations
The security considerations from S/MIME [RFC5750][RFC5751] and The security considerations from S/MIME [RFC5750][RFC5751] and
elliptic curves in CMS [RFC5753] apply. The S/MIME related security elliptic curves in CMS [RFC5753] apply. The S/MIME related security
considerations from SIP [RFC3261][RFC3853], SIP MESSAGE [RFC3428], considerations from SIP [RFC3261][RFC3853], SIP MESSAGE [RFC3428],
and MSRP [RFC4975] apply. and MSRP [RFC4975] apply.
The security considerations from algorithms recommended in this The security considerations from algorithms recommended in this
document also apply, see [RFC3565], [RFC5480], [RFC5753], [RFC5754], document also apply, see [RFC3565], [RFC5480], [RFC5753], [RFC5754],
[RFC7748], [RFC8032], [I-D.ietf-curdle-cms-eddsa-signatures], and [RFC7748], [RFC8032], [RFC8419], and [RFC8418].
[I-D.ietf-curdle-cms-ecdh-new-curves].
This document assumes that end-entity certificate validation is This document assumes that end-entity certificate validation is
provided by a chain of trust to a certification authority (CA), using provided by a chain of trust to a certification authority (CA), using
a public key infrastructure. The security considerations from a public key infrastructure. The security considerations from
[RFC5280] apply. However, other validations methods may be possible; [RFC5280] apply. However, other validations methods may be possible;
for example sending a signed fingerprint for the end-entity in SDP. for example sending a signed fingerprint for the end-entity in SDP.
The relationship of this work and the techniques discussed in The relationship of this work and the techniques discussed in
[RFC4474], [I-D.ietf-stir-rfc4474bis], and [RFC8224] and [I-D.ietf-sipbrandy-rtpsec] are out of scope for this
[I-D.ietf-sipbrandy-rtpsec] are out of scope for this document. document.
When matching an end-entity certificate to the sender or recipient When matching an end-entity certificate to the sender or recipient
identity, the respective SIP AoRs are used. Typically these will identity, the respective SIP AoRs are used. Typically these will
match the SIP From and To header fields. Some UAs may extract sender match the SIP From and To header fields. Some UAs may extract sender
identity from SIP AoRs in other header fields, for example, P- identity from SIP AoRs in other header fields, for example, P-
Asserted-Identity [RFC3325]. In general, the UAS should compare the Asserted-Identity [RFC3325]. In general, the UAS should compare the
certificate to the identity that it relies upon, for example for certificate to the identity that it relies upon, for example for
display to the end-user or comparison to white lists and blacklists. display to the end-user or comparison to white lists and blacklists.
The secure notification use case discussed in Section 1 has The secure notification use case discussed in Section 1 has
significant vulnerabilities when used in an insecure environment. significant vulnerabilities when used in an insecure environment.
For example, "phishing" messages could be used to trick users into For example, "phishing" messages could be used to trick users into
revealing credentials. Eavesdroppers could learn confirmation codes revealing credentials. Eavesdroppers could learn confirmation codes
from unprotected two-factor authentication messages. Unsolicited from unprotected two-factor authentication messages. Unsolicited
messages sent by impersonators could tarnish the reputation of an messages sent by impersonators could tarnish the reputation of an
organization. While hop-by-hop protection can mitigate some of those organization. While hop-by-hop protection can mitigate some of those
risks, it still leaves messages vulnerabile to malicious or risks, it still leaves messages vulnerable to malicious or
compromised intermediaries. compromised intermediaries.
Mobile messaging is typically an online application; online Mobile messaging is typically an online application; online
certificate revocation checks should usually be feasible. certificate revocation checks should usually be feasible.
Certain messaging services, for example those based on CPM and RCS, S/MIME does not normally protect the SIP or MSRP headers. While it
may include intermediaries that attach metadata to user generated normally does protect the CPIM header, certain CPIM header fields may
messages. In certain cases this metadata may reveal information to not be protected if the sender excludes them from the encrypted or
third parties that would have otherwise been encrypted. Implementors signed part of the message. (See Section 9.1.) Certain messaging
and operators should consider whether this metadata may create services, for example those based on RCS, may include intermediaries
privacy leaks. Such an analysis is beyond the scope of this that attach metadata to user generated messages in the form of SIP,
document. MSRP, or CPIM header fields. This metadata could possibly reveal
information to third parties that the sender might prefer not to send
as cleartext. Implementors and operators should consider whether
inserted metadata may create privacy leaks. Such an analysis is
beyond the scope of this document.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-curdle-cms-ecdh-new-curves]
Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key
Agreement Algorithm with X25519 and X448 in the
Cryptographic Message Syntax (CMS)", draft-ietf-curdle-
cms-ecdh-new-curves-10 (work in progress), August 2017.
[I-D.ietf-curdle-cms-eddsa-signatures]
Housley, R., "Use of EdDSA Signatures in the Cryptographic
Message Syntax (CMS)", draft-ietf-curdle-cms-eddsa-
signatures-08 (work in progress), October 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
skipping to change at page 24, line 23 skipping to change at page 24, line 13
2010, <https://www.rfc-editor.org/info/rfc5753>. 2010, <https://www.rfc-editor.org/info/rfc5753>.
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic
Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January
2010, <https://www.rfc-editor.org/info/rfc5754>. 2010, <https://www.rfc-editor.org/info/rfc5754>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8418] Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key
Agreement Algorithm with X25519 and X448 in the
Cryptographic Message Syntax (CMS)", RFC 8418,
DOI 10.17487/RFC8418, August 2018,
<https://www.rfc-editor.org/info/rfc8418>.
[RFC8419] Housley, R., "Use of Edwards-Curve Digital Signature
Algorithm (EdDSA) Signatures in the Cryptographic Message
Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419, August
2018, <https://www.rfc-editor.org/info/rfc8419>.
[X680] ITU-T, "Information technology -- Abstract Syntax Notation [X680] ITU-T, "Information technology -- Abstract Syntax Notation
One (ASN.1): Specification of basic notation", One (ASN.1): Specification of basic notation",
ITU-T Recommendation X.680, 2015. ITU-T Recommendation X.680, 2015.
[X690] ITU-T, "Information Technology -- ASN.1 encoding rules: [X690] ITU-T, "Information Technology -- ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, 2015. (DER)", ITU-T Recommendation X.690, 2015.
13.2. Informative References 13.2. Informative References
[CPM] Open Mobile Alliance, "OMA Converged IP Messaging System [CPM] Open Mobile Alliance, "OMA Converged IP Messaging System
Description, Candidate Version 2.2", September 2017. Description, Candidate Version 2.2", September 2017.
[I-D.ietf-sipbrandy-rtpsec] [I-D.ietf-sipbrandy-rtpsec]
Peterson, J., Rescorla, E., Barnes, R., and R. Housley, Peterson, J., Barnes, R., and R. Housley, "Best Practices
"Best Practices for Securing RTP Media Signaled with SIP", for Securing RTP Media Signaled with SIP", draft-ietf-
draft-ietf-sipbrandy-rtpsec-04 (work in progress), May sipbrandy-rtpsec-06 (work in progress), October 2018.
2018.
[I-D.ietf-stir-rfc4474bis]
Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session
Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16
(work in progress), February 2017.
[RCS] GSMA, "RCS Universal Profile Service Definition Document, [RCS] GSMA, "RCS Universal Profile Service Definition Document,
Version 2.0", June 2017. Version 2.0", June 2017.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325, Asserted Identity within Trusted Networks", RFC 3325,
DOI 10.17487/RFC3325, November 2002, DOI 10.17487/RFC3325, November 2002,
<https://www.rfc-editor.org/info/rfc3325>. <https://www.rfc-editor.org/info/rfc3325>.
skipping to change at page 25, line 26 skipping to change at page 25, line 20
[RFC3860] Peterson, J., "Common Profile for Instant Messaging [RFC3860] Peterson, J., "Common Profile for Instant Messaging
(CPIM)", RFC 3860, DOI 10.17487/RFC3860, August 2004, (CPIM)", RFC 3860, DOI 10.17487/RFC3860, August 2004,
<https://www.rfc-editor.org/info/rfc3860>. <https://www.rfc-editor.org/info/rfc3860>.
[RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant
Messaging (CPIM): Message Format", RFC 3862, Messaging (CPIM): Message Format", RFC 3862,
DOI 10.17487/RFC3862, August 2004, DOI 10.17487/RFC3862, August 2004,
<https://www.rfc-editor.org/info/rfc3862>. <https://www.rfc-editor.org/info/rfc3862>.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474,
DOI 10.17487/RFC4474, August 2006,
<https://www.rfc-editor.org/info/rfc4474>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions
for the Message Sessions Relay Protocol (MSRP)", RFC 4976, for the Message Sessions Relay Protocol (MSRP)", RFC 4976,
DOI 10.17487/RFC4976, September 2007, DOI 10.17487/RFC4976, September 2007,
<https://www.rfc-editor.org/info/rfc4976>. <https://www.rfc-editor.org/info/rfc4976>.
[RFC5438] Burger, E. and H. Khartabil, "Instant Message Disposition [RFC5438] Burger, E. and H. Khartabil, "Instant Message Disposition
skipping to change at page 26, line 23 skipping to change at page 26, line 14
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>. 2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>. <https://www.rfc-editor.org/info/rfc8032>.
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 8224,
DOI 10.17487/RFC8224, February 2018,
<https://www.rfc-editor.org/info/rfc8224>.
Appendix A. Message Details Appendix A. Message Details
The following section shows the detailed content of the S/MIME bodies The following section shows the detailed content of the S/MIME bodies
used in Section 10. used in Section 10.
A.1. Signed Message A.1. Signed Message
Figure 5 shows the details of the message signed by Alice used in the Figure 5 shows the details of the message signed by Alice used in the
example in Section 10.1. example in Section 10.1.
 End of changes. 37 change blocks. 
91 lines changed or deleted 86 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/