< draft-campbell-sip-messaging-smime-01.txt   draft-campbell-sip-messaging-smime-02.txt >
Network Working Group B. Campbell Network Working Group B. Campbell
Internet-Draft Independent Internet-Draft Standard Velocity
Updates: RFC 3261, RFC 3428, RFC 4975 R. Housley Updates: RFC 3261, RFC 3428, RFC 4975 R. Housley
(if approved) Vigil Security (if approved) Vigil Security
Intended status: Standards Track November 29, 2017 Intended status: Standards Track December 26, 2017
Expires: June 2, 2018 Expires: June 29, 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-01 draft-campbell-sip-messaging-smime-02
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 40
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 June 2, 2018. This Internet-Draft will expire on June 29, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement and Scope . . . . . . . . . . . . . . . . . 3 3. Problem Statement and Scope . . . . . . . . . . . . . . . . . 4
4. Applicability of S/MIME . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . 7 4.4. Certificate Handling . . . . . . . . . . . . . . . . . . 8
4.4.1. Subject Alternative Name . . . . . . . . . . . . . . 7 4.4.1. Subject Alternative Name . . . . . . . . . . . . . . 8
4.4.2. Certificate Validation . . . . . . . . . . . . . . . 7 4.4.2. Certificate Validation . . . . . . . . . . . . . . . 8
5. Transfer Encoding . . . . . . . . . . . . . . . . . . . . . . 8 5. Transfer Encoding . . . . . . . . . . . . . . . . . . . . . . 8
6. User Agent Capabilities . . . . . . . . . . . . . . . . . . . 8 6. User Agent Capabilities . . . . . . . . . . . . . . . . . . . 9
7. Using S/MIME with the SIP MESSAGE Method . . . . . . . . . . 9 7. Using S/MIME with the SIP MESSAGE Method . . . . . . . . . . 10
7.1. Size Limit . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Size Limit . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. User Agent Capabilities . . . . . . . . . . . . . . . . . 9 7.2. User Agent Capabilities . . . . . . . . . . . . . . . . . 10
7.3. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 10 7.3. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 10
8. Using S/MIME with MSRP . . . . . . . . . . . . . . . . . . . 10 8. Using S/MIME with MSRP . . . . . . . . . . . . . . . . . . . 11
8.1. Chunking . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Chunking . . . . . . . . . . . . . . . . . . . . . . . . 11
8.2. Streamed Data . . . . . . . . . . . . . . . . . . . . . . 11 8.2. Streamed Data . . . . . . . . . . . . . . . . . . . . . . 12
8.3. Indicating support for S/MIME . . . . . . . . . . . . . . 11 8.3. Indicating support for S/MIME . . . . . . . . . . . . . . 12
8.4. MSRP URIs . . . . . . . . . . . . . . . . . . . . . . . . 12 8.4. MSRP URIs . . . . . . . . . . . . . . . . . . . . . . . . 13
8.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 12 8.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 13
9. S/MIME Interaction with other SIP Messaging Features . . . . 13 9. S/MIME Interaction with other SIP Messaging Features . . . . 13
9.1. Common Profile for Instant Messaging . . . . . . . . . . 13 9.1. Common Profile for Instant Messaging . . . . . . . . . . 13
9.2. Instant Message Delivery Notifications . . . . . . . . . 14 9.2. Instant Message Delivery Notifications . . . . . . . . . 14
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10.1. Signed Message in SIP Including the Sender's Certificate 15
12. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10.2. Signed Message in SIP with No Certificate . . . . . . . 17
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.3. MSRP Signed and Encrypted Message in a Single Chunk . . 17
13.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.4. MSRP Signed and Encrypted Message sent in Multiple
13.2. Informative References . . . . . . . . . . . . . . . . . 17 Chunks . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
12. Security Considerations . . . . . . . . . . . . . . . . . . . 21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
13.1. Normative References . . . . . . . . . . . . . . . . . . 22
13.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Message Details . . . . . . . . . . . . . . . . . . 26
A.1. Signed Message . . . . . . . . . . . . . . . . . . . . . 26
A.2. Short Signed Message . . . . . . . . . . . . . . . . . . 29
A.3. Signed and Encrypted Message . . . . . . . . . . . . . . 30
A.3.1. Signed Message Prior to Encryption . . . . . . . . . 30
A.3.2. Encrypted Message . . . . . . . . . . . . . . . . . . 33
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
Alliance (OMA) Converged IP Messaging (CPM) [CPM], [RCS] system uses Alliance (OMA) Converged IP Messaging (CPM) [CPM], [RCS] system uses
the SIP Message Method for short "pager mode" messages and MSRP for the SIP Message Method for short "pager mode" messages and MSRP for
skipping to change at page 3, line 31 skipping to change at page 3, line 42
messages, and can break large messages into chunks. messages, and can break large messages into chunks.
While both SIP and MSRP provide mechanisms for hop-by-hop security, While both SIP and MSRP provide mechanisms for hop-by-hop security,
neither provides native end-to-end protection. Instead, they depend neither provides native end-to-end protection. Instead, they depend
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
cryptographic algorithm recommendations and the handling of S/MIME
data objects. It updates RFC 3261 to allow S/MIME signed messages to
be sent without imbedded certificates in some situations. Finally,
it updates RFC 3261, RFC 3428 and RFC 4975 to clarify error 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
skipping to change at page 4, line 37 skipping to change at page 5, line 9
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" send 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, but may be discussed in a future version. document.
Cryptographic algorithm requirements in this document are intended Cryptographic algorithm requirements in this document are intended
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
skipping to change at page 7, line 25 skipping to change at page 7, line 48
the X25519 algorithm identifier are repeated here: the X25519 algorithm identifier are 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
When generating a signed and encrypted message, sending UAs MUST sign RFC 3261 section 23.2 says that when a UAC sends signed and encrypted
the message first, and then encrypt it. data, it should send an EnvelopedData object encapsulated within a
SignedData message. That essentially says that one should encrypt
first, then sign. This document updates RFC 3261 to say that, when
sending signed and encrypted user content in a SIP MESSAGE request,
the sending UAs MUST sign the message first, and then encrypt it.
That is, it must send the SignedData object inside 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
typically expressed 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 a message signer. Any SIP URI present MUST to convey the SIP URI of the subject of a certificate. Any SIP URI
be encoded using the uniformResourceIdentifier CHOICE of the present MUST be encoded using the uniformResourceIdentifier CHOICE of
GeneralName type as described in [RFC5280], Section 4.2.1.6. Since the GeneralName type as described in [RFC5280], Section 4.2.1.6.
the SubjectAltName type is a SEQUENCE OF GeneralName, multiple URIs Since the SubjectAltName type is a SEQUENCE OF GeneralName, multiple
MAY be present. URIs MAY be present.
Open Issue: Should we consider other means of linking the identity to Other methods of identifying a certificate subject MAY be used.
the certificate other than a SIP URI? For example, a specially
constructed domain name for a cert issued via an ACME service? One
approach might to be to say to use a SIP URI in the absence of other
mechanisms.
4.4.2. Certificate Validation 4.4.2. Certificate Validation
When validating a certificate, receiving UAs MUST support the When validating a certificate, receiving UAs MUST support the
Elliptic Curve Digital Signature Algorithm (ECDSA) using the NIST Elliptic Curve Digital Signature Algorithm (ECDSA) using the NIST
P256 elliptic curve and the SHA-256 message digest algorithm P256 elliptic curve and the SHA-256 message digest algorithm
[RFC5480]. [RFC5480].
Sending and receiving UAs MAY support other digital signature Sending and receiving UAs MAY support other digital signature
algorithms for certificate validation. algorithms for certificate validation.
skipping to change at page 9, line 35 skipping to change at page 10, line 22
7.1. Size Limit 7.1. Size Limit
SIP MESSAGE requests are typically limited to 1300 octets. That SIP MESSAGE requests are typically limited to 1300 octets. That
limit applies to the entire message, including both SIP header fields limit applies to the entire message, including both SIP header fields
and the message content. This is due to the potential for and the message content. This is due to the potential for
fragmentation of larger requests sent over UDP. In general, it is fragmentation of larger requests sent over UDP. In general, it is
hard to be sure that no proxy or other intermediary will forward a hard to be sure that no proxy or other intermediary will forward a
SIP request over UDP somewhere along the path. Therefore, S/MIME SIP request over UDP somewhere along the path. Therefore, S/MIME
messages sent via SIP MESSAGE should be kept as small as possible. messages sent via SIP MESSAGE should be kept as small as possible.
Messages that will not fit within the limit can be sent using MSRP.
[RFC3261] says that a SignedData message MUST contain a certificate Section 23.2 of [RFC3261] says that a SignedData message must contain
to be used to validate the signature. In order to reduce the message a certificate to be used to validate the signature. In order to
size, this document updates that to say that a SignedData message reduce the message size, this document updates that to say that a
sent in a SIP MESSAGE request SHOULD contain the certificate, but MAY SignedData message sent in a SIP MESSAGE request SHOULD contain the
omit it if the sender has reason to believe that the recipient certificate, but MAY omit it if the sender has reason to believe that
already has the certificate in its keychain, or has some other method the recipient already has the certificate in its keychain, or has
of accessing the certificate. some other method of accessing the certificate.
7.2. User Agent Capabilities 7.2. User Agent Capabilities
SIP user agents (UA) can indicate support for S/MIME by including the SIP user agents (UA) can indicate support for S/MIME by including the
appropriate media type or types in the SIP Accept header field in a appropriate media type or types in the SIP Accept header field in a
response to an OPTIONS request, or in a 415 response to a SIP request response to an OPTIONS request, or in a 415 response to a SIP request
that contained an unsupported media type in the body. that contained an unsupported media type in the body.
UAs might be able to use the user agent capabilities framework UAs might be able to use the user agent capabilities framework
[RFC3840] to indicate support. However doing so would require the [RFC3840] to indicate support. However doing so would require the
registration of one or more media feature tags with IANA. registration of one or more media feature tags with IANA.
UAs MAY use other out-of-band methods to indicate their level of UAs MAY use other out-of-band methods to indicate their level of
support for S/MIME. support for S/MIME.
7.3. Failure Cases 7.3. Failure Cases
[RFC3261] requires that the recipient of a SIP request that includes Section 23.2 of [RFC3261] requires that the recipient of a SIP
a body part of an unsupported media type and a Content-Disposition request that includes a body part of an unsupported media type and a
header "handling" parameter of "required" return a 415 "Unsupported Content-Disposition header "handling" parameter of "required" return
Media Type" response. Given that SIP MESSAGE exists for no reason a 415 "Unsupported Media Type" response. Given that SIP MESSAGE
other than to deliver content in the body, it is reasonable to treat exists for no reason other than to deliver content in the body, it is
the top-level body part as always required. However [RFC3428] makes reasonable to treat the top-level body part as always required.
no such assertion. This document updates [RFC3428] to say that a UAC However [RFC3428] makes no such assertion. This document updates
that receives a SIP MESSAGE request with an unsupported media type section 11.3 [RFC3428] to add the statement that a UAC that receives
MUST return a 415 Unsupported Media Type" response. a SIP MESSAGE request with an unsupported media type MUST return a
415 Unsupported Media Type" response.
[RFC3261] says that if a recipient receives an S/MIME body encrypted Section 23.2 of [RFC3261] says that if a recipient receives an S/MIME
to the wrong certificate, it MUST return a SIP 493 (Undecipherable) body encrypted to the wrong certificate, it MUST return a SIP 493
response, and SHOULD send a valid certificate in that response. This (Undecipherable) response, and SHOULD send a valid certificate in
is not always possible in practice for SIP MESSAGE requests. The that response. This is not always possible in practice for SIP
User Agent Server (UAS) may choose not to decrypt a message until the MESSAGE requests. The User Agent Server (UAS) may choose not to
user is ready to read it. Messages may be delivered to a message decrypt a message until the user is ready to read it. Messages may
store, or sent via a store-and-forward service. This document be delivered to a message store, or sent via a store-and-forward
updates RFC 3261 to say that the UAS SHOULD return a SIP 493 response service. This document updates RFC 3261 to say that the UAS SHOULD
if it immediately attempts to decrypt the message and determines the return a SIP 493 response if it immediately attempts to decrypt the
message was encrypted to the wrong certificate. However, it MAY message and determines the message was encrypted to the wrong
return a 2XX class response if decryption is deferred. certificate. However, it MAY return a 2XX class response if
decryption is deferred.
8. Using S/MIME with MSRP 8. Using S/MIME with MSRP
MSRP has features that interact with the use of S/MIME. In MSRP has features that interact with the use of S/MIME. In
particular, the ability to send messages in chunks, the ability to particular, the ability to send messages in chunks, the ability to
send messages of unknown size, and the use of SDP to indicate media- send messages of unknown size, and the use of SDP to indicate media-
type support create considerations for the use of S/MIME. type support create considerations for the use of S/MIME.
8.1. Chunking 8.1. Chunking
skipping to change at page 12, line 34 skipping to change at page 13, line 22
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 Addresses of Record (AoRs) of the peers are used [RFC3261], the SIP AoRs of the peers are used instead.
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 answer. Thus, the 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
skipping to change at page 13, line 23 skipping to change at page 14, line 11
The Common Profile for Instant Messaging (CPIM) [RFC3860] defines an The Common Profile for Instant Messaging (CPIM) [RFC3860] defines an
abstract messaging service, with the goal of creating gateways abstract messaging service, with the goal of creating gateways
between different messaging protocols that could relay instant between different messaging protocols that could relay instant
messages without change. The SIP MESSAGE method and MSRP were messages without change. The SIP MESSAGE method and MSRP were
initially designed to map to the CPIM abstractions. However, at the initially designed to map to the CPIM abstractions. However, at the
time of this writing, CPIM compliant gateways have not been deployed. time of this writing, CPIM compliant gateways have not been deployed.
To the authors' knowledge, no other IM protocols have been explicitly To the authors' knowledge, no other IM protocols have been explicitly
mapped to CPIM. mapped to CPIM.
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. The use time of this writing, the "im:" scheme is not in common use.
of "im:" URIs as subject alternative names in certificates is for
future study.
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, Intant Message Delivery
Notifications (IMDN)[RFC5438] and MSRP Multi-party Chat [RFC7701] Notifications (IMDN)[RFC5438] and MSRP Multi-party Chat [RFC7701]
skipping to change at page 13, line 48 skipping to change at page 14, line 34
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
signatures that cover CPIM metadata, while the latter is not possible signatures that cover CPIM metadata, while the latter is not possible
if the metadata is encrypted. Clients intended for use in such if the metadata is encrypted. Clients intended for use in such
networks MAY choose to apply end-to-end signatures and encryption networks MAY choose to apply end-to-end signatures and encryption
operations to only the CPIM payload, leaving the CPIM metadata operations to only the CPIM payload, leaving the CPIM metadata
unprotected from inspection and modification. unprotected from inspection and modification. UAs that support
S/MIME and CPIM SHOULD be able validate signatures and decrypt
enveloped data both when those operations are applied to the entire
CPIM body, and when they are applied to just the CPIM payload.
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
skipping to change at page 14, line 36 skipping to change at page 15, line 22
servers to aggregate delivery notifications. servers to aggregate delivery notifications.
Such intermediaries will be unable to read end-to-end encrypted Such intermediaries will be unable to read end-to-end encrypted
messages in order to interpret delivery notice requests. messages in order to interpret delivery notice requests.
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
Examples will be added in a future version of this document. The following sections show examples of S/MIME messages in SIP and
MSRP. The examples include the tags "[start-hex]" and "[end-hex]" to
denote binary content shown in hexadecimal. The tags are not part of
the actual message, and do not count towards the Content-Length
header field values. Some SIP header fields are folded to avoid over
running the margins. Folded lines contain leading white space at the
beginning of the line. These folds would not exist in the actual
message.
In all of these examples, the clear text message is the string
"Watson, come here - I want to see you." followed by a newline
character.
The cast of characters includes Alice, with a SIP AoR of
"alice@example.com", and Bob, with a SIP AoR of "bob@example.org".
Appendix A shows the detailed content of each S/MIME body.
10.1. Signed Message in SIP Including the Sender's Certificate
Figure 1 shows a message signed by Alice. This body uses the
"application/pcks7-mime" media type with a smime-type parameter value
of "signed-data".
The S/MIME body includes Alice's signing certificate. Even though
the original message content is fairly short and only minimal SIP
header fields are included, the total message size is 1300 octets.
This is the maximum allowed for the SIP MESSAGE method unless the UAC
has advance knowledge that no hop will use a transport protocol
without congestion control.
MESSAGE sip:bob@example.org SIP/2.0
Via: SIP/2.0/TCP alice-pc.example.com;branch=z9hG4bK776sgdkfie
Max-Forwards: 70
From: sip:alice@example.com;tag=49597
To: sip:bob@example.org
Call-ID: asd88asd66b@1.2.3.4
CSeq: 1 MESSAGE
Content-Transfer-Encoding: binary
Content-Type: application/pkcs7-mime; smime-type=signed-data;
name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Length: 890
[start-hex]
3082037606092a864886f70d010702a082036730820363020101310d300b
0609608648016503040201305306092a864886f70d010701a0460444436f
6e74656e742d547970653a20746578742f706c61696e0d0a0d0a57617473
6f6e2c20636f6d652068657265202d20492077616e7420746f2073656520
796f752e0d0aa082016f3082016b30820110a00302010202090090238790
1727648e300a06082a8648ce3d040302302631143012060355040a0c0b65
78616d706c652e636f6d310e300c06035504030c05416c696365301e170d
3137313232303232353433395a170d3138313232303232353433395a3026
31143012060355040a0c0b6578616d706c652e636f6d310e300c06035504
030c05416c6963653059301306072a8648ce3d020106082a8648ce3d0301
0703420004d87b54729f2c22feebd9ddba0efa40642297a6093887a4dae7
990b23f87fa7ed99db8cf5a314f2ee64106ef1ed61dbfc0a4b91c953cbd0
22a751b914807bb794a327302530230603551d110101ff04193017861573
69703a616c696365406578616d706c652e636f6d300a06082a8648ce3d04
03020349003046022100f16fe739ddf3a1ff072a78142395721f9c0629b5
8458644d855dad94da9b06f20221008ffda4ba4c65087584969bfb2002ba
f5eefebd693181b43666141f363990988431820185308201810201013033
302631143012060355040a0c0b6578616d706c652e636f6d310e300c0603
5504030c05416c696365020900902387901727648e300b06096086480165
03040201a081e4301806092a864886f70d010903310b06092a864886f70d
010701301c06092a864886f70d010905310f170d31373132323032323537
35315a302f06092a864886f70d01090431220420ef778fc940d5e6dc2576
f47a599b3126195a9f1a227adaf35fa22c050d8d195a307906092a864886
f70d01090f316c306a300b060960864801650304012a300b060960864801
6503040116300b0609608648016503040102300a06082a864886f70d0307
300e06082a864886f70d030202020080300d06082a864886f70d03020201
40300706052b0e030207300d06082a864886f70d0302020128300a06082a
8648ce3d0403020447304502200f37c8d68628ed5a52e1208bb091999901
02f1de5766a45d5b4627fe4d87c9cc022100f0de29c03e7d3fcc5329b77f
e31faa10b0003c8249cb011cbb14410d4c9bf93e
[end-hex]
Figure 1: Signed Message in SIP
10.2. Signed Message in SIP with No Certificate
Figure 2 shows the same message from Alice without the imbedded
certificate. The resulting total length of 928 octets is more
manageable.
MESSAGE sip:bob@example.org SIP/2.0
Via: SIP/2.0/TCP alice-pc.example.com;branch=z9hG4bK776sgdkfie
Max-Forwards: 70
From: sip:alice@example.com;tag=49597
To: sip:bob@example.org
Call-ID: asd88asd66b@1.2.3.4
CSeq: 1 MESSAGE
Content-Transfer-Encoding: binary
Content-Type: application/pkcs7-mime; smime-type=signed-data;
name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Length: 518
[start-hex]
3082020206092a864886f70d010702a08201f3308201ef020101310d300b
0609608648016503040201305306092a864886f70d010701a0460444436f
6e74656e742d547970653a20746578742f706c61696e0d0a0d0a57617473
6f6e2c20636f6d652068657265202d20492077616e7420746f2073656520
796f752e0d0a31820184308201800201013033302631143012060355040a
0c0b6578616d706c652e636f6d310e300c06035504030c05416c69636502
0900b8793ec0e4c21530300b0609608648016503040201a081e430180609
2a864886f70d010903310b06092a864886f70d010701301c06092a864886
f70d010905310f170d3137313232313032313230345a302f06092a864886
f70d01090431220420ef778fc940d5e6dc2576f47a599b3126195a9f1a22
7adaf35fa22c050d8d195a307906092a864886f70d01090f316c306a300b
060960864801650304012a300b0609608648016503040116300b06096086
48016503040102300a06082a864886f70d0307300e06082a864886f70d03
0202020080300d06082a864886f70d0302020140300706052b0e03020730
0d06082a864886f70d0302020128300a06082a8648ce3d04030204463044
022057773352edeed4ea693455e2a87b8b098decefe50ddb0ff7e391e84f
7976208a0220089cf365467a1a49e838b51f35a62c7a158e5fc999bf7d8f
bfb5262af5afec93
[end-hex]
Figure 2: Signed Message in SIP with No Certificate Included
10.3. MSRP Signed and Encrypted Message in a Single Chunk
Figure 3 shows a signed and encrypted message from Bob to Alice sent
via MSRP.
MSRP dsdfoe38sd SEND
To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
From-Path: msrp://bobpc.example.org:8888/9di4eae923wzd;tcp
Message-ID: 456so39s
Byte-Range: 1-1567/1567
Content-Disposition: attachment; filename="smime.p7m"
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name="smime.p7m"
[start-hex]
3082061b06092a864886f70d010703a082060c308206080201003182024f
3082024b0201003033302631143012060355040a0c0b6578616d706c652e
636f6d310e300c06035504030c05416c69636502090083f50bb70bd5c40e
300d06092a864886f70d010101050004820200bbab785554a48e6248677b
5c56328528282e172d36611dc2986ae168fc84d49f4120ea2cb895d5967f
f35a22ed2e5fee4d7204e70c8697bf138d9fbd8485c300638f9ef93e6146
5f1e1405fb5bf7b95f2faf12e441fb8cfcdfd5cf1d88d285cfa9fddf0de3
f9c95b8cd750772924c7d919c80aa8677dc2bc63b5abe2a04e76ee0c2e6c
041e08fa29476a4a76851944edd7fa79ada89709107bf65d56ac669b781a
23f0fd7232de26bba07e1dca69f50118bd4955463d2cad403dc2a6749209
dfc02c9e145270d5135ce5548bbf3347c6f356faa093feefdbba5d094f4a
0e23a94686fca77cfa1759aaa4e27748227e6517063fbbd7a013abcb08f9
50b2ac911b72b340d57c24d08e613f4e0a087821c820238e422e85bf3902
c99a9629b0862945e00d1b433f6dc35e8d1cb5098597363624456dd867e6
132d8ee935cc3b4124df6baba88770708af57c9ad70727410d6bf83ec0e5
580e26c67f90608d375750ed93890256bf3f714fb676effcf363db0809b0
21e90994a437353ee41432c7cf60e48cbd45420c659e75906cede2d44a5b
b619014e73a0ba2d54ab3edbe23c63fad898411d1ac790552eadc66a358f
bd4461efec935d0b8bbc2e6cf23e863a1ee7a4e7741f072c1d465ea1e6c3
577b2e77acd1d1152f268235f85ae82f50871acf13e38b17fd69f88f973f
6818682c4043b4ec7db17b22e20ee9becbf2c9f893308203ae06092a8648
86f70d010701301d060960864801650304010204104d8757222eac529411
7f0c12d671a127808203805d4077a1547c5f4699f07531a53eb88344d1a3
b229ff91f3f69c0e94918c77c9f6bda194e35983ef9a38edca15678e65bd
76ce665ca6e999b3a845e42666aa2703a5a4f0d3322d6de01e64545cbccf
09e3c2268dfd86c336116b22cce80098619242fd482ece2fcd71a7c15ff7
7bf133287df0ef7c51713bdc0f6cdada9198ea8fd81a9c5a50c5e9c0958b
3347efc425038fb5b776ab469826227c697aecc6580d0a23a99e15b805ff
3ba155c252f5e72bb9db133d049d992c18f4f4dad60a18dae729ba7c5836
78ffb8604a8f7fe3cc62d0632cc66e1c4f9ba1fa9df56c6d9fd81f19c88b
a6e9710bb0bbb0c5fcf9d2d5ea04d529fda78d60dc487d867c0e392174e9
3ce2c3986cea7aef071e5b07b646c229f9069f27f3749456daea0a4e56bc
491c9be370c544399a273d50c35f160fb37e5f7314c3d389a805c8e4776f
0a2a89f555c9fe52080890abe2e39d2ed77a2b363d1c0fb375790028e962
401230ae93aa4320a5da2ad7017c599508f79c3a0c35f9846e8a2c410a5e
0d77e907c0151ce513e2e899de92ff8d177796238ade9309d75c976e9716
ced4c45e1a339213d7b0824592394076f74a70454cc46565f4a836531646
42827b2e28819ac3781afb529b7c72308b96978539d789d3d27cb1605b1a
0ce966e9c6cb5825d235e523a6c2d948ef9314c902359adf03fe4684221f
afd1f833d759c6f2559b6e0a8897d64e42b49eae0e39dfaccc94ef3e733f
ca2212eb5ccbc7c5d7f042d02bf412d14c7ede0f664d799ea556f9763e74
2cacdd3efc8822bbe6c81fea27de6b0b06448252f9adeb6667b46056f39b
42f18f4d6258111fa243b5c39fdf8961bc6e59d8bd659d46f92a8ced04d1
a6af37e5c089b547a836df6994377cf92e8e74625569df6a6065f6c93bab
ef0d07cfac7af69d8bf87c96e6ebad2ebdb553f776e69143e706e227061e
5e3d0e38a83ab9c2ce62102f3021f7d8b9e56ad6714514039f48d7fab85e
fbafee16e15d7afd8148ccfc9fb273f8bfd5bdebd0281a50095aa192c9e8
7a0f2c44bb57de5f86cfbda3337cd982dfae982a80879878646e03614515
cf94150479d20e3ce521617dda22d53a5829265564fa467e7db9e25f3d25
5a4f9f82fd9514ca177ac81b882acbe89d1cc640c7b980c5a9d5f70921bb
6fbf166d38aa04257e08c51b2df144e93363e0e47e8013df584b3f3130b4
df7c9ae17709f1bfd8ded1385741d80596b7b8d6a2f2e5a2f85029ce97ef
ed2c97f942f77b
[end-hex]
-------dsdfoe38sd$
Figure 3: Signed and Encrypted Message in MSRP
10.4. MSRP Signed and Encrypted Message sent in Multiple Chunks
Figure 4 shows the same message as in Figure 3 except that the
message is broken into two chunks. The S/MIME operations were
performed prior to breaking the message into chunks.
MSRP d93kswow SEND
To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
From-Path: msrp://bobpc.example.org:8888/9di4eae923wzd;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-780/1567
Content-Disposition: attachment; filename="smime.p7m"
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name="smime.p7m"
[start-hex]
3082061b06092a864886f70d010703a082060c308206080201003182024f
3082024b0201003033302631143012060355040a0c0b6578616d706c652e
636f6d310e300c06035504030c05416c69636502090083f50bb70bd5c40e
300d06092a864886f70d010101050004820200bbab785554a48e6248677b
5c56328528282e172d36611dc2986ae168fc84d49f4120ea2cb895d5967f
f35a22ed2e5fee4d7204e70c8697bf138d9fbd8485c300638f9ef93e6146
5f1e1405fb5bf7b95f2faf12e441fb8cfcdfd5cf1d88d285cfa9fddf0de3
f9c95b8cd750772924c7d919c80aa8677dc2bc63b5abe2a04e76ee0c2e6c
041e08fa29476a4a76851944edd7fa79ada89709107bf65d56ac669b781a
23f0fd7232de26bba07e1dca69f50118bd4955463d2cad403dc2a6749209
dfc02c9e145270d5135ce5548bbf3347c6f356faa093feefdbba5d094f4a
0e23a94686fca77cfa1759aaa4e27748227e6517063fbbd7a013abcb08f9
50b2ac911b72b340d57c24d08e613f4e0a087821c820238e422e85bf3902
c99a9629b0862945e00d1b433f6dc35e8d1cb5098597363624456dd867e6
132d8ee935cc3b4124df6baba88770708af57c9ad70727410d6bf83ec0e5
580e26c67f90608d375750ed93890256bf3f714fb676effcf363db0809b0
21e90994a437353ee41432c7cf60e48cbd45420c659e75906cede2d44a5b
b619014e73a0ba2d54ab3edbe23c63fad898411d1ac790552eadc66a358f
bd4461efec935d0b8bbc2e6cf23e863a1ee7a4e7741f072c1d465ea1e6c3
577b2e77acd1d1152f268235f85ae82f50871acf13e38b17fd69f88f973f
6818682c4043b4ec7db17b22e20ee9becbf2c9f893308203ae06092a8648
86f70d010701301d060960864801650304010204104d8757222eac529411
7f0c12d671a127808203805d4077a1547c5f4699f07531a53eb88344d1a3
b229ff91f3f69c0e94918c77c9f6bda194e35983ef9a38edca15678e65bd
76ce665ca6e999b3a845e42666aa2703a5a4f0d3322d6de01e64545cbccf
09e3c2268dfd86c336116b22cce80098619242fd482ece2fcd71a7c15ff7
[end-hex]
-------d93kswow+
MSRP op2nc9a SEND
To-Path: msrp://alicepc.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://bobpc.example.org:7654/iau39soe2843z;tcp
Message-ID: 12339sdqwer
Byte-Range: 781-1567/1567
Content-Disposition: attachment; filename="smime.p7m"
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name="smime.p7m"
[start-hex]
7bf133287df0ef7c51713bdc0f6cdada9198ea8fd81a9c5a50c5e9c0958b
3347efc425038fb5b776ab469826227c697aecc6580d0a23a99e15b805ff
3ba155c252f5e72bb9db133d049d992c18f4f4dad60a18dae729ba7c5836
78ffb8604a8f7fe3cc62d0632cc66e1c4f9ba1fa9df56c6d9fd81f19c88b
a6e9710bb0bbb0c5fcf9d2d5ea04d529fda78d60dc487d867c0e392174e9
3ce2c3986cea7aef071e5b07b646c229f9069f27f3749456daea0a4e56bc
491c9be370c544399a273d50c35f160fb37e5f7314c3d389a805c8e4776f
0a2a89f555c9fe52080890abe2e39d2ed77a2b363d1c0fb375790028e962
401230ae93aa4320a5da2ad7017c599508f79c3a0c35f9846e8a2c410a5e
0d77e907c0151ce513e2e899de92ff8d177796238ade9309d75c976e9716
ced4c45e1a339213d7b0824592394076f74a70454cc46565f4a836531646
42827b2e28819ac3781afb529b7c72308b96978539d789d3d27cb1605b1a
0ce966e9c6cb5825d235e523a6c2d948ef9314c902359adf03fe4684221f
afd1f833d759c6f2559b6e0a8897d64e42b49eae0e39dfaccc94ef3e733f
ca2212eb5ccbc7c5d7f042d02bf412d14c7ede0f664d799ea556f9763e74
2cacdd3efc8822bbe6c81fea27de6b0b06448252f9adeb6667b46056f39b
42f18f4d6258111fa243b5c39fdf8961bc6e59d8bd659d46f92a8ced04d1
a6af37e5c089b547a836df6994377cf92e8e74625569df6a6065f6c93bab
ef0d07cfac7af69d8bf87c96e6ebad2ebdb553f776e69143e706e227061e
5e3d0e38a83ab9c2ce62102f3021f7d8b9e56ad6714514039f48d7fab85e
fbafee16e15d7afd8148ccfc9fb273f8bfd5bdebd0281a50095aa192c9e8
7a0f2c44bb57de5f86cfbda3337cd982dfae982a80879878646e03614515
cf94150479d20e3ce521617dda22d53a5829265564fa467e7db9e25f3d25
5a4f9f82fd9514ca177ac81b882acbe89d1cc640c7b980c5a9d5f70921bb
6fbf166d38aa04257e08c51b2df144e93363e0e47e8013df584b3f3130b4
df7c9ae17709f1bfd8ded1385741d80596b7b8d6a2f2e5a2f85029ce97ef
ed2c97f942f77b
[end-hex]
-------op2nc9a$
Figure 4: MSRP Chunked Signed and Encrypted Message
11. IANA Considerations 11. IANA Considerations
This document makes no requests of the IANA. This document makes no requests of the IANA.
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.
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 [RFC4474], [I-D.ietf-stir-rfc4474bis], and
[I-D.ietf-sipbrandy-rtpsec] are for future study. [I-D.ietf-sipbrandy-rtpsec] are out of scope for this 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. Matching SIP AoRs from match the SIP From and To header fields. Some UAs may extract sender
other header fields, for example, P-Asserted-Identity [RFC3325], is identity from SIP AoRs in other header fields, for example, P-
for future study. Asserted-Identity [RFC3325]. In general, the UAS should compare the
certificate to the identity that it relies upon, for example for
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 vulnerabile to malicious or
compromised intermediaries. compromised intermediaries.
skipping to change at page 19, line 41 skipping to change at page 26, line 19
[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>.
Appendix A. Message Details
The following section shows the detailed content of the S/MIME bodies
used in Section 10.
A.1. Signed Message
Figure 5 shows the details of the message signed by Alice used in the
example in Section 10.1.
CMS_ContentInfo:
contentType: pkcs7-signedData (1.2.840.113549.1.7.2)
d.signedData:
version: 1
digestAlgorithms:
algorithm: sha256 (2.16.840.1.101.3.4.2.1)
parameter: <ABSENT>
encapContentInfo:
eContentType: pkcs7-data (1.2.840.113549.1.7.1)
eContent:
0000 - 43 6f 6e 74 65 6e 74 2d-54 79 70 65 3a 20 74 Content-Type: t
000f - 65 78 74 2f 70 6c 61 69-6e 0d 0a 0d 0a 57 61 ext/plain....Wa
001e - 74 73 6f 6e 2c 20 63 6f-6d 65 20 68 65 72 65 tson, come here
002d - 20 2d 20 49 20 77 61 6e-74 20 74 6f 20 73 65 - I want to se
003c - 65 20 79 6f 75 2e 0d 0a- e you...
certificates:
d.certificate:
cert_info:
version: 2
serialNumber: 10386294218579993742
signature:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
issuer: O=example.com, CN=Alice
validity:
notBefore: Dec 20 22:54:39 2017 GMT
notAfter: Dec 20 22:54:39 2018 GMT
subject: O=example.com, CN=Alice
key:
algor:
algorithm: id-ecPublicKey (1.2.840.10045.2.1)
parameter: OBJECT:prime256v1 (1.2.840.10045.3.1.7)
public_key: (0 unused bits)
0000 - 04 d8 7b 54 72 9f 2c 22-fe eb d9 dd ba 0e ..{Tr.,"......
000e - fa 40 64 22 97 a6 09 38-87 a4 da e7 99 0b .@d"...8......
001c - 23 f8 7f a7 ed 99 db 8c-f5 a3 14 f2 ee 64 #............d
002a - 10 6e f1 ed 61 db fc 0a-4b 91 c9 53 cb d0 .n..a...K..S..
0038 - 22 a7 51 b9 14 80 7b b7-94 ".Q...{..
issuerUID: <ABSENT>
subjectUID: <ABSENT>
extensions:
object: X509v3 Subject Alternative Name (2.5.29.17)
critical: TRUE
value:
0000 - 30 17 86 15 73 69 70 3a-61 6c 69 63 65 0...sip:alice
000d - 40 65 78 61 6d 70 6c 65-2e 63 6f 6d @example.com
sig_alg:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
signature: (0 unused bits)
0000 - 30 46 02 21 00 f1 6f e7-39 dd f3 a1 ff 07 2a 0F.!..o.9.....*
000f - 78 14 23 95 72 1f 9c 06-29 b5 84 58 64 4d 85 x.#.r...)..XdM.
001e - 5d ad 94 da 9b 06 f2 02-21 00 8f fd a4 ba 4c ].......!.....L
002d - 65 08 75 84 96 9b fb 20-02 ba f5 ee fe bd 69 e.u.... ......i
003c - 31 81 b4 36 66 14 1f 36-39 90 98 84 1..6f..69...
crls:
<EMPTY>
signerInfos:
version: 1
d.issuerAndSerialNumber:
issuer: O=example.com, CN=Alice
serialNumber: 10386294218579993742
digestAlgorithm:
algorithm: sha256 (2.16.840.1.101.3.4.2.1)
parameter: <ABSENT>
signedAttrs:
object: contentType (1.2.840.113549.1.9.3)
value.set:
OBJECT:pkcs7-data (1.2.840.113549.1.7.1)
object: signingTime (1.2.840.113549.1.9.5)
value.set:
UTCTIME:Dec 20 22:57:51 2017 GMT
object: messageDigest (1.2.840.113549.1.9.4)
value.set:
OCTET STRING:
0000 - ef 77 8f c9 40 d5 e6 dc-25 76 f4 7a 59 .w..@...%v.zY
000d - 9b 31 26 19 5a 9f 1a 22-7a da f3 5f a2 .1&.Z.."z.._.
001a - 2c 05 0d 8d 19 5a ,....Z
object: S/MIME Capabilities (1.2.840.113549.1.9.15)
value.set:
SEQUENCE:
0:d=0 hl=2 l= 106 cons: SEQUENCE
2:d=1 hl=2 l= 11 cons: SEQUENCE
4:d=2 hl=2 l= 9 prim: OBJECT :aes-256-cbc
15:d=1 hl=2 l= 11 cons: SEQUENCE
17:d=2 hl=2 l= 9 prim: OBJECT :aes-192-cbc
28:d=1 hl=2 l= 11 cons: SEQUENCE
30:d=2 hl=2 l= 9 prim: OBJECT :aes-128-cbc
41:d=1 hl=2 l= 10 cons: SEQUENCE
43:d=2 hl=2 l= 8 prim: OBJECT :des-ede3-cbc
53:d=1 hl=2 l= 14 cons: SEQUENCE
55:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc
65:d=2 hl=2 l= 2 prim: INTEGER :80
69:d=1 hl=2 l= 13 cons: SEQUENCE
71:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc
81:d=2 hl=2 l= 1 prim: INTEGER :40
84:d=1 hl=2 l= 7 cons: SEQUENCE
86:d=2 hl=2 l= 5 prim: OBJECT :des-cbc
93:d=1 hl=2 l= 13 cons: SEQUENCE
95:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc
105:d=2 hl=2 l= 1 prim: INTEGER :28
signatureAlgorithm:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
signature:
0000 - 30 45 02 20 0f 37 c8 d6-86 28 ed 5a 52 e1 20 0E. .7...(.ZR.
000f - 8b b0 91 99 99 01 02 f1-de 57 66 a4 5d 5b 46 .........Wf.][F
001e - 27 fe 4d 87 c9 cc 02 21-00 f0 de 29 c0 3e 7d '.M....!...).>}
002d - 3f cc 53 29 b7 7f e3 1f-aa 10 b0 00 3c 82 49 ?.S)........<.I
003c - cb 01 1c bb 14 41 0d 4c-9b f9 3e .....A.L..>
unsignedAttrs:
<EMPTY>
Figure 5: Signed Message
A.2. Short Signed Message
Figure 6 shows the message signed by Alice with no imbedded
certificate, as used in the example in Section 10.2.
CMS_ContentInfo:
contentType: pkcs7-signedData (1.2.840.113549.1.7.2)
d.signedData:
version: 1
digestAlgorithms:
algorithm: sha256 (2.16.840.1.101.3.4.2.1)
parameter: <ABSENT>
encapContentInfo:
eContentType: pkcs7-data (1.2.840.113549.1.7.1)
eContent:
0000 - 43 6f 6e 74 65 6e 74 2d-54 79 70 65 3a 20 74 Content-Type: t
000f - 65 78 74 2f 70 6c 61 69-6e 0d 0a 0d 0a 57 61 ext/plain....Wa
001e - 74 73 6f 6e 2c 20 63 6f-6d 65 20 68 65 72 65 tson, come here
002d - 20 2d 20 49 20 77 61 6e-74 20 74 6f 20 73 65 - I want to se
003c - 65 20 79 6f 75 2e 0d 0a- e you...
certificates:
<EMPTY>
crls:
<EMPTY>
signerInfos:
version: 1
d.issuerAndSerialNumber:
issuer: O=example.com, CN=Alice
serialNumber: 13292724773353297200
digestAlgorithm:
algorithm: sha256 (2.16.840.1.101.3.4.2.1)
parameter: <ABSENT>
signedAttrs:
object: contentType (1.2.840.113549.1.9.3)
value.set:
OBJECT:pkcs7-data (1.2.840.113549.1.7.1)
object: signingTime (1.2.840.113549.1.9.5)
value.set:
UTCTIME:Dec 21 02:12:04 2017 GMT
object: messageDigest (1.2.840.113549.1.9.4)
value.set:
OCTET STRING:
0000 - ef 77 8f c9 40 d5 e6 dc-25 76 f4 7a 59 .w..@...%v.zY
000d - 9b 31 26 19 5a 9f 1a 22-7a da f3 5f a2 .1&.Z.."z.._.
001a - 2c 05 0d 8d 19 5a ,....Z
object: S/MIME Capabilities (1.2.840.113549.1.9.15)
value.set:
SEQUENCE:
0:d=0 hl=2 l= 106 cons: SEQUENCE
2:d=1 hl=2 l= 11 cons: SEQUENCE
4:d=2 hl=2 l= 9 prim: OBJECT :aes-256-cbc
15:d=1 hl=2 l= 11 cons: SEQUENCE
17:d=2 hl=2 l= 9 prim: OBJECT :aes-192-cbc
28:d=1 hl=2 l= 11 cons: SEQUENCE
30:d=2 hl=2 l= 9 prim: OBJECT :aes-128-cbc
41:d=1 hl=2 l= 10 cons: SEQUENCE
43:d=2 hl=2 l= 8 prim: OBJECT :des-ede3-cbc
53:d=1 hl=2 l= 14 cons: SEQUENCE
55:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc
65:d=2 hl=2 l= 2 prim: INTEGER :80
69:d=1 hl=2 l= 13 cons: SEQUENCE
71:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc
81:d=2 hl=2 l= 1 prim: INTEGER :40
84:d=1 hl=2 l= 7 cons: SEQUENCE
86:d=2 hl=2 l= 5 prim: OBJECT :des-cbc
93:d=1 hl=2 l= 13 cons: SEQUENCE
95:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc
105:d=2 hl=2 l= 1 prim: INTEGER :28
signatureAlgorithm:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
signature:
0000 - 30 44 02 20 57 77 33 52-ed ee d4 ea 69 34 55 0D. Ww3R....i4U
000f - e2 a8 7b 8b 09 8d ec ef-e5 0d db 0f f7 e3 91 ..{............
001e - e8 4f 79 76 20 8a 02 20-08 9c f3 65 46 7a 1a .Oyv .. ...eFz.
002d - 49 e8 38 b5 1f 35 a6 2c-7a 15 8e 5f c9 99 bf I.8..5.,z.._...
003c - 7d 8f bf b5 26 2a f5 af-ec 93 }...&*....
unsignedAttrs:
<EMPTY>
Figure 6: Signed Message without Imbedded Certificate
A.3. Signed and Encrypted Message
The following sections show details for the message signed by Bob and
encrypted to Alice, as used in the examples in Section 10.3 and
Section 10.4.
A.3.1. Signed Message Prior to Encryption
CMS_ContentInfo:
contentType: pkcs7-signedData (1.2.840.113549.1.7.2)
d.signedData:
version: 1
digestAlgorithms:
algorithm: sha256 (2.16.840.1.101.3.4.2.1)
parameter: <ABSENT>
encapContentInfo:
eContentType: pkcs7-data (1.2.840.113549.1.7.1)
eContent:
0000 - 43 6f 6e 74 65 6e 74 2d-54 79 70 65 3a 20 74 Content-Type: t
000f - 65 78 74 2f 70 6c 61 69-6e 0d 0a 0d 0a 57 61 ext/plain....Wa
001e - 74 73 6f 6e 2c 20 63 6f-6d 65 20 68 65 72 65 tson, come here
002d - 20 2d 20 49 20 77 61 6e-74 20 74 6f 20 73 65 - I want to se
003c - 65 20 79 6f 75 2e 0d 0a- e you...
certificates:
d.certificate:
cert_info:
version: 2
serialNumber: 11914627415941064473
signature:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
issuer: O=example.org, CN=Bob
validity:
notBefore: Dec 20 23:07:49 2017 GMT
notAfter: Dec 20 23:07:49 2018 GMT
subject: O=example.org, CN=Bob
key:
algor:
algorithm: id-ecPublicKey (1.2.840.10045.2.1)
parameter: OBJECT:prime256v1 (1.2.840.10045.3.1.7)
public_key: (0 unused bits)
0000 - 04 86 4f ff fc 53 f1 a8-76 ca 69 b1 7e 27 ..O..S..v.i.~'
000e - 48 7a 07 9c 71 52 ae 1b-13 7e 39 3b af 1a Hz..qR...~9;..
001c - ae bd 12 74 3c 7d 41 43-a2 fd 8a 37 0f 02 ...t<}AC...7..
002a - ba 9d 03 b7 30 1f 1d a6-4e 30 55 94 bb 6f ....0...N0U..o
0038 - 95 cb 71 fa 48 b6 d0 a3-83 ..q.H....
issuerUID: <ABSENT>
subjectUID: <ABSENT>
extensions:
object: X509v3 Subject Alternative Name (2.5.29.17)
critical: TRUE
value:
0000 - 30 15 86 13 73 69 70 3a-62 6f 62 40 65 0...sip:bob@e
000d - 78 61 6d 70 6c 65 2e 6f-72 67 xample.org
sig_alg:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
signature: (0 unused bits)
0000 - 30 45 02 21 00 b2 24 8c-92 40 28 22 38 9e c9 0E.!..$..@("8..
000f - 25 7f 64 cc fd 10 6f ba-0b 96 c1 19 07 30 34 %.d...o......04
001e - d5 1b 10 2f 73 39 6c 02-20 15 8e b1 51 f0 85 .../s9l. ...Q..
002d - b9 bd 2e 04 cf 27 8f 0d-52 2e 6b b6 fe 4f 36 .....'..R.k..O6
003c - f7 4c 77 10 b1 5a 4f 47-9d e4 0d .Lw..ZOG...
crls:
<EMPTY>
signerInfos:
version: 1
d.issuerAndSerialNumber:
issuer: O=example.org, CN=Bob
serialNumber: 11914627415941064473
digestAlgorithm:
algorithm: sha256 (2.16.840.1.101.3.4.2.1)
parameter: <ABSENT>
signedAttrs:
object: contentType (1.2.840.113549.1.9.3)
value.set:
OBJECT:pkcs7-data (1.2.840.113549.1.7.1)
object: signingTime (1.2.840.113549.1.9.5)
value.set:
UTCTIME:Dec 22 23:43:18 2017 GMT
object: messageDigest (1.2.840.113549.1.9.4)
value.set:
OCTET STRING:
0000 - ef 77 8f c9 40 d5 e6 dc-25 76 f4 7a 59 .w..@...%v.zY
000d - 9b 31 26 19 5a 9f 1a 22-7a da f3 5f a2 .1&.Z.."z.._.
001a - 2c 05 0d 8d 19 5a ,....Z
object: S/MIME Capabilities (1.2.840.113549.1.9.15)
value.set:
SEQUENCE:
0:d=0 hl=2 l= 106 cons: SEQUENCE
2:d=1 hl=2 l= 11 cons: SEQUENCE
4:d=2 hl=2 l= 9 prim: OBJECT :aes-256-cbc
15:d=1 hl=2 l= 11 cons: SEQUENCE
17:d=2 hl=2 l= 9 prim: OBJECT :aes-192-cbc
28:d=1 hl=2 l= 11 cons: SEQUENCE
30:d=2 hl=2 l= 9 prim: OBJECT :aes-128-cbc
41:d=1 hl=2 l= 10 cons: SEQUENCE
43:d=2 hl=2 l= 8 prim: OBJECT :des-ede3-cbc
53:d=1 hl=2 l= 14 cons: SEQUENCE
55:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc
65:d=2 hl=2 l= 2 prim: INTEGER :80
69:d=1 hl=2 l= 13 cons: SEQUENCE
71:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc
81:d=2 hl=2 l= 1 prim: INTEGER :40
84:d=1 hl=2 l= 7 cons: SEQUENCE
86:d=2 hl=2 l= 5 prim: OBJECT :des-cbc
93:d=1 hl=2 l= 13 cons: SEQUENCE
95:d=2 hl=2 l= 8 prim: OBJECT :rc2-cbc
105:d=2 hl=2 l= 1 prim: INTEGER :28
signatureAlgorithm:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
signature:
0000 - 30 45 02 20 23 e1 e1 2f-c6 9c 7b c3 ae d0 67 0E. #../..{...g
000f - 8a ab 25 71 16 dd 9a 82-7c 36 24 a2 fa e5 fa ..%q....|6$....
001e - 98 52 01 2b 98 c1 02 21-00 9b 8d 7c ad 9a f2 .R.+...!...|...
002d - 09 e8 ac f7 00 aa a7 64-ef 32 d0 3a 47 16 42 .......d.2.:G.B
003c - 79 04 54 90 53 e8 58 aa-6c 69 37 y.T.S.X.li7
unsignedAttrs:
<EMPTY>
Figure 7: Message Signed by Bob prior to Encryption
A.3.2. Encrypted Message
CMS_ContentInfo:
contentType: pkcs7-envelopedData (1.2.840.113549.1.7.3)
d.envelopedData:
version: <ABSENT>
originatorInfo: <ABSENT>
recipientInfos:
d.ktri:
version: <ABSENT>
d.issuerAndSerialNumber:
issuer: O=example.com, CN=Alice
serialNumber: 9508519069068149774
keyEncryptionAlgorithm:
algorithm: rsaEncryption (1.2.840.113549.1.1.1)
parameter: NULL
encryptedKey:
0000 - bb ab 78 55 54 a4 8e 62-48 67 7b 5c 56 32 85 ..xUT..bHg{\V2.
000f - 28 28 2e 17 2d 36 61 1d-c2 98 6a e1 68 fc 84 ((..-6a...j.h..
001e - d4 9f 41 20 ea 2c b8 95-d5 96 7f f3 5a 22 ed ..A .,......Z".
002d - 2e 5f ee 4d 72 04 e7 0c-86 97 bf 13 8d 9f bd ._.Mr..........
003c - 84 85 c3 00 63 8f 9e f9-3e 61 46 5f 1e 14 05 ....c...>aF_...
004b - fb 5b f7 b9 5f 2f af 12-e4 41 fb 8c fc df d5 .[.._/...A.....
005a - cf 1d 88 d2 85 cf a9 fd-df 0d e3 f9 c9 5b 8c .............[.
0069 - d7 50 77 29 24 c7 d9 19-c8 0a a8 67 7d c2 bc .Pw)$......g}..
0078 - 63 b5 ab e2 a0 4e 76 ee-0c 2e 6c 04 1e 08 fa c....Nv...l....
0087 - 29 47 6a 4a 76 85 19 44-ed d7 fa 79 ad a8 97 )GjJv..D...y...
0096 - 09 10 7b f6 5d 56 ac 66-9b 78 1a 23 f0 fd 72 ..{.]V.f.x.#..r
00a5 - 32 de 26 bb a0 7e 1d ca-69 f5 01 18 bd 49 55 2.&..~..i....IU
00b4 - 46 3d 2c ad 40 3d c2 a6-74 92 09 df c0 2c 9e F=,.@=..t....,.
00c3 - 14 52 70 d5 13 5c e5 54-8b bf 33 47 c6 f3 56 .Rp..\.T..3G..V
00d2 - fa a0 93 fe ef db ba 5d-09 4f 4a 0e 23 a9 46 .......].OJ.#.F
00e1 - 86 fc a7 7c fa 17 59 aa-a4 e2 77 48 22 7e 65 ...|..Y...wH"~e
00f0 - 17 06 3f bb d7 a0 13 ab-cb 08 f9 50 b2 ac 91 ..?........P...
00ff - 1b 72 b3 40 d5 7c 24 d0-8e 61 3f 4e 0a 08 78 .r.@.|$..a?N..x
010e - 21 c8 20 23 8e 42 2e 85-bf 39 02 c9 9a 96 29 !. #.B...9....)
011d - b0 86 29 45 e0 0d 1b 43-3f 6d c3 5e 8d 1c b5 ..)E...C?m.^...
012c - 09 85 97 36 36 24 45 6d-d8 67 e6 13 2d 8e e9 ...66$Em.g..-..
013b - 35 cc 3b 41 24 df 6b ab-a8 87 70 70 8a f5 7c 5.;A$.k...pp..|
014a - 9a d7 07 27 41 0d 6b f8-3e c0 e5 58 0e 26 c6 ...'A.k.>..X.&.
0159 - 7f 90 60 8d 37 57 50 ed-93 89 02 56 bf 3f 71 ..`.7WP....V.?q
0168 - 4f b6 76 ef fc f3 63 db-08 09 b0 21 e9 09 94 O.v...c....!...
0177 - a4 37 35 3e e4 14 32 c7-cf 60 e4 8c bd 45 42 .75>..2..`...EB
0186 - 0c 65 9e 75 90 6c ed e2-d4 4a 5b b6 19 01 4e .e.u.l...J[...N
0195 - 73 a0 ba 2d 54 ab 3e db-e2 3c 63 fa d8 98 41 s..-T.>..<c...A
01a4 - 1d 1a c7 90 55 2e ad c6-6a 35 8f bd 44 61 ef ....U...j5..Da.
01b3 - ec 93 5d 0b 8b bc 2e 6c-f2 3e 86 3a 1e e7 a4 ..]....l.>.:...
01c2 - e7 74 1f 07 2c 1d 46 5e-a1 e6 c3 57 7b 2e 77 .t..,.F^...W{.w
01d1 - ac d1 d1 15 2f 26 82 35-f8 5a e8 2f 50 87 1a ..../&.5.Z./P..
01e0 - cf 13 e3 8b 17 fd 69 f8-8f 97 3f 68 18 68 2c ......i...?h.h,
01ef - 40 43 b4 ec 7d b1 7b 22-e2 0e e9 be cb f2 c9 @C..}.{".......
01fe - f8 93 ..
encryptedContentInfo:
contentType: pkcs7-data (1.2.840.113549.1.7.1)
contentEncryptionAlgorithm:
algorithm: aes-128-cbc (2.16.840.1.101.3.4.1.2)
parameter: OCTET STRING:
0000 - 4d 87 57 22 2e ac 52 94-11 7f 0c 12 d6 71 a1 M.W"..R......q.
000f - 27 '
encryptedContent:
0000 - 5d 40 77 a1 54 7c 5f 46-99 f0 75 31 a5 3e b8 ]@w.T|_F..u1.>.
000f - 83 44 d1 a3 b2 29 ff 91-f3 f6 9c 0e 94 91 8c .D...).........
001e - 77 c9 f6 bd a1 94 e3 59-83 ef 9a 38 ed ca 15 w......Y...8...
002d - 67 8e 65 bd 76 ce 66 5c-a6 e9 99 b3 a8 45 e4 g.e.v.f\.....E.
003c - 26 66 aa 27 03 a5 a4 f0-d3 32 2d 6d e0 1e 64 &f.'.....2-m..d
004b - 54 5c bc cf 09 e3 c2 26-8d fd 86 c3 36 11 6b T\.....&....6.k
005a - 22 cc e8 00 98 61 92 42-fd 48 2e ce 2f cd 71 "....a.B.H../.q
0069 - a7 c1 5f f7 7b f1 33 28-7d f0 ef 7c 51 71 3b .._.{.3(}..|Qq;
0078 - dc 0f 6c da da 91 98 ea-8f d8 1a 9c 5a 50 c5 ..l.........ZP.
0087 - e9 c0 95 8b 33 47 ef c4-25 03 8f b5 b7 76 ab ....3G..%....v.
0096 - 46 98 26 22 7c 69 7a ec-c6 58 0d 0a 23 a9 9e F.&"|iz..X..#..
00a5 - 15 b8 05 ff 3b a1 55 c2-52 f5 e7 2b b9 db 13 ....;.U.R..+...
00b4 - 3d 04 9d 99 2c 18 f4 f4-da d6 0a 18 da e7 29 =...,.........)
00c3 - ba 7c 58 36 78 ff b8 60-4a 8f 7f e3 cc 62 d0 .|X6x..`J....b.
00d2 - 63 2c c6 6e 1c 4f 9b a1-fa 9d f5 6c 6d 9f d8 c,.n.O.....lm..
00e1 - 1f 19 c8 8b a6 e9 71 0b-b0 bb b0 c5 fc f9 d2 ......q........
00f0 - d5 ea 04 d5 29 fd a7 8d-60 dc 48 7d 86 7c 0e ....)...`.H}.|.
00ff - 39 21 74 e9 3c e2 c3 98-6c ea 7a ef 07 1e 5b 9!t.<...l.z...[
010e - 07 b6 46 c2 29 f9 06 9f-27 f3 74 94 56 da ea ..F.)...'.t.V..
011d - 0a 4e 56 bc 49 1c 9b e3-70 c5 44 39 9a 27 3d .NV.I...p.D9.'=
012c - 50 c3 5f 16 0f b3 7e 5f-73 14 c3 d3 89 a8 05 P._...~_s......
013b - c8 e4 77 6f 0a 2a 89 f5-55 c9 fe 52 08 08 90 ..wo.*..U..R...
014a - ab e2 e3 9d 2e d7 7a 2b-36 3d 1c 0f b3 75 79 ......z+6=...uy
0159 - 00 28 e9 62 40 12 30 ae-93 aa 43 20 a5 da 2a .(.b@.0...C ..*
0168 - d7 01 7c 59 95 08 f7 9c-3a 0c 35 f9 84 6e 8a ..|Y....:.5..n.
0177 - 2c 41 0a 5e 0d 77 e9 07-c0 15 1c e5 13 e2 e8 ,A.^.w.........
0186 - 99 de 92 ff 8d 17 77 96-23 8a de 93 09 d7 5c ......w.#.....\
0195 - 97 6e 97 16 ce d4 c4 5e-1a 33 92 13 d7 b0 82 .n.....^.3.....
01a4 - 45 92 39 40 76 f7 4a 70-45 4c c4 65 65 f4 a8 E.9@v.JpEL.ee..
01b3 - 36 53 16 46 42 82 7b 2e-28 81 9a c3 78 1a fb 6S.FB.{.(...x..
01c2 - 52 9b 7c 72 30 8b 96 97-85 39 d7 89 d3 d2 7c R.|r0....9....|
01d1 - b1 60 5b 1a 0c e9 66 e9-c6 cb 58 25 d2 35 e5 .`[...f...X%.5.
01e0 - 23 a6 c2 d9 48 ef 93 14-c9 02 35 9a df 03 fe #...H.....5....
01ef - 46 84 22 1f af d1 f8 33-d7 59 c6 f2 55 9b 6e F."....3.Y..U.n
01fe - 0a 88 97 d6 4e 42 b4 9e-ae 0e 39 df ac cc 94 ....NB....9....
020d - ef 3e 73 3f ca 22 12 eb-5c cb c7 c5 d7 f0 42 .>s?."..\.....B
021c - d0 2b f4 12 d1 4c 7e de-0f 66 4d 79 9e a5 56 .+...L~..fMy..V
022b - f9 76 3e 74 2c ac dd 3e-fc 88 22 bb e6 c8 1f .v>t,..>.."....
023a - ea 27 de 6b 0b 06 44 82-52 f9 ad eb 66 67 b4 .'.k..D.R...fg.
0249 - 60 56 f3 9b 42 f1 8f 4d-62 58 11 1f a2 43 b5 `V..B..MbX...C.
0258 - c3 9f df 89 61 bc 6e 59-d8 bd 65 9d 46 f9 2a ....a.nY..e.F.*
0267 - 8c ed 04 d1 a6 af 37 e5-c0 89 b5 47 a8 36 df ......7....G.6.
0276 - 69 94 37 7c f9 2e 8e 74-62 55 69 df 6a 60 65 i.7|...tbUi.j`e
0285 - f6 c9 3b ab ef 0d 07 cf-ac 7a f6 9d 8b f8 7c ..;......z....|
0294 - 96 e6 eb ad 2e bd b5 53-f7 76 e6 91 43 e7 06 .......S.v..C..
02a3 - e2 27 06 1e 5e 3d 0e 38-a8 3a b9 c2 ce 62 10 .'..^=.8.:...b.
02b2 - 2f 30 21 f7 d8 b9 e5 6a-d6 71 45 14 03 9f 48 /0!....j.qE...H
02c1 - d7 fa b8 5e fb af ee 16-e1 5d 7a fd 81 48 cc ...^.....]z..H.
02d0 - fc 9f b2 73 f8 bf d5 bd-eb d0 28 1a 50 09 5a ...s......(.P.Z
02df - a1 92 c9 e8 7a 0f 2c 44-bb 57 de 5f 86 cf bd ....z.,D.W._...
02ee - a3 33 7c d9 82 df ae 98-2a 80 87 98 78 64 6e .3|.....*...xdn
02fd - 03 61 45 15 cf 94 15 04-79 d2 0e 3c e5 21 61 .aE.....y..<.!a
030c - 7d da 22 d5 3a 58 29 26-55 64 fa 46 7e 7d b9 }.".:X)&Ud.F~}.
031b - e2 5f 3d 25 5a 4f 9f 82-fd 95 14 ca 17 7a c8 ._=%ZO.......z.
032a - 1b 88 2a cb e8 9d 1c c6-40 c7 b9 80 c5 a9 d5 ..*.....@......
0339 - f7 09 21 bb 6f bf 16 6d-38 aa 04 25 7e 08 c5 ..!.o..m8..%~..
0348 - 1b 2d f1 44 e9 33 63 e0-e4 7e 80 13 df 58 4b .-.D.3c..~...XK
0357 - 3f 31 30 b4 df 7c 9a e1-77 09 f1 bf d8 de d1 ?10..|..w......
0366 - 38 57 41 d8 05 96 b7 b8-d6 a2 f2 e5 a2 f8 50 8WA...........P
0375 - 29 ce 97 ef ed 2c 97 f9-42 f7 7b )....,..B.{
unprotectedAttrs:
<EMPTY>
Figure 8
Authors' Addresses Authors' Addresses
Ben Campbell Ben Campbell
Independent Standard Velocity
204 Touchdown Dr 204 Touchdown Dr
Irving, TX 75063 Irving, TX 75063
US US
Email: ben@nostrum.com Email: ben@nostrum.com
Russ Housley Russ Housley
Vigil Security Vigil Security
918 Spring Knoll Drive 918 Spring Knoll Drive
Herndon, VA 20170 Herndon, VA 20170
US US
Email: housley@vigilsec.com Email: housley@vigilsec.com
 End of changes. 28 change blocks. 
81 lines changed or deleted 856 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/