draft-ietf-sipcore-sec-flows-09.txt   rfc6216.txt 
Network Working Group C. Jennings Internet Engineering Task Force (IETF) C. Jennings
Internet-Draft Cisco Systems Request for Comments: 6216 Cisco Systems
Intended status: Informational K. Ono Category: Informational K. Ono
Expires: August 13, 2011 Columbia University ISSN: 2070-1721 Columbia University
R. Sparks R. Sparks
B. Hibbard, Ed. B. Hibbard, Ed.
Tekelec Tekelec
February 9, 2011 April 2011
Example call flows using Session Initiation Protocol (SIP) security Example Call Flows Using Session Initiation Protocol (SIP)
mechanisms Security Mechanisms
draft-ietf-sipcore-sec-flows-09
Abstract Abstract
This document shows example call flows demonstrating the use of This document shows example call flows demonstrating the use of
Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail
Extensions (S/MIME) in Session Initiation Protocol (SIP). It also Extensions (S/MIME) in Session Initiation Protocol (SIP). It also
provides information that helps implementers build interoperable SIP provides information that helps implementers build interoperable SIP
software. To help facilitate interoperability testing, it includes software. To help facilitate interoperability testing, it includes
certificates used in the example call flows and processes to create certificates used in the example call flows and processes to create
certificates for testing. certificates for testing.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on August 13, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6216.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 19 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Certificates . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Certificates . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 4 2.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 4
2.2. Host Certificates . . . . . . . . . . . . . . . . . . . . 8 2.2. Host Certificates . . . . . . . . . . . . . . . . . . . . 8
2.3. User Certificates . . . . . . . . . . . . . . . . . . . . 10 2.3. User Certificates . . . . . . . . . . . . . . . . . . . . 10
3. Callflow with Message Over TLS . . . . . . . . . . . . . . . . 12 3. Call Flow with Message Over TLS . . . . . . . . . . . . . . . 12
3.1. TLS with Server Authentication . . . . . . . . . . . . . . 12 3.1. TLS with Server Authentication . . . . . . . . . . . . . . 12
3.2. MESSAGE Transaction Over TLS . . . . . . . . . . . . . . . 13 3.2. MESSAGE Transaction Over TLS . . . . . . . . . . . . . . . 13
4. Callflow with S/MIME-secured Message . . . . . . . . . . . . . 15 4. Call Flow with S/MIME-Secured Message . . . . . . . . . . . . 15
4.1. MESSAGE Request with Signed Body . . . . . . . . . . . . . 15 4.1. MESSAGE Request with Signed Body . . . . . . . . . . . . . 15
4.2. MESSAGE Request with Encrypted Body . . . . . . . . . . . 20 4.2. MESSAGE Request with Encrypted Body . . . . . . . . . . . 20
4.3. MESSAGE Request with Encrypted and Signed Body . . . . . . 22 4.3. MESSAGE Request with Encrypted and Signed Body . . . . . . 22
5. Observed Interoperability Issues . . . . . . . . . . . . . . . 29 5. Observed Interoperability Issues . . . . . . . . . . . . . . . 27
6. Additional Test Scenarios . . . . . . . . . . . . . . . . . . 31 6. Additional Test Scenarios . . . . . . . . . . . . . . . . . . 29
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32
9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 37 9.1. Normative References . . . . . . . . . . . . . . . . . . . 32
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 9.2. Informative References . . . . . . . . . . . . . . . . . . 34
11.1. Normative References . . . . . . . . . . . . . . . . . . . 40 Appendix A. Making Test Certificates . . . . . . . . . . . . . . 35
11.2. Informative References . . . . . . . . . . . . . . . . . . 41 A.1. makeCA script . . . . . . . . . . . . . . . . . . . . . . 36
Appendix A. Making Test Certificates . . . . . . . . . . . . . . 43 A.2. makeCert script . . . . . . . . . . . . . . . . . . . . . 40
A.1. makeCA script . . . . . . . . . . . . . . . . . . . . . . 44 Appendix B. Certificates for Testing . . . . . . . . . . . . . . 42
A.2. makeCert script . . . . . . . . . . . . . . . . . . . . . 48 B.1. Certificates Using EKU . . . . . . . . . . . . . . . . . . 42
Appendix B. Certificates for Testing . . . . . . . . . . . . . . 51 B.2. Certificates NOT Using EKU . . . . . . . . . . . . . . . . 51
B.1. Certificates Using EKU . . . . . . . . . . . . . . . . . . 51 B.3. Certificate Chaining with a Non-Root CA . . . . . . . . . 58
B.2. Certificates NOT Using EKU . . . . . . . . . . . . . . . . 58 Appendix C. Message Dumps . . . . . . . . . . . . . . . . . . . . 64
B.3. Certificate Chaining with a Non-Root CA . . . . . . . . . 66
Appendix C. Message Dumps . . . . . . . . . . . . . . . . . . . . 73
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 76
1. Introduction 1. Introduction
This document is informational and is not normative on any aspect of This document is informational and is not normative on any aspect of
SIP. SIP.
SIP with TLS ([RFC5246]) implementations are becoming very common. SIP with TLS ([RFC5246]) implementations are becoming very common.
Several implementations of the S/MIME ([RFC5751]) portion of SIP Several implementations of the S/MIME ([RFC5751]) portion of SIP
([RFC3261]) are also becoming available. After several ([RFC3261]) are also becoming available. After several
interoperability events, it is clear that it is difficult to write interoperability events, it is clear that it is difficult to write
these systems without any test vectors or examples of "known good" these systems without any test vectors or examples of "known good"
messages to test against. Furthermore, testing at the events is messages to test against. Furthermore, testing at the events is
often hindered due to the lack of a commonly trusted certificate often hindered due to the lack of a commonly trusted certification
authority to sign the certificates used in the events. This document authority to sign the certificates used in the events. This document
addresses both of these issues by providing messages that give addresses both of these issues by providing messages that give
detailed examples that implementers can use for comparison and that detailed examples that implementers can use for comparison and that
can also be used for testing. In addition, this document provides a can also be used for testing. In addition, this document provides a
common certificate and private key that can be used to set up a mock common certificate and private key that can be used to set up a mock
Certificate Authority (CA) that can be used during the SIP Certification Authority (CA) that can be used during the SIP
interoperability events. Certificate requests from the users will be interoperability events. Certificate requests from the users will be
signed by the private key of the mock CA. The document also provides signed by the private key of the mock CA. The document also provides
some hints and clarifications for implementers. some hints and clarifications for implementers.
A simple SIP call flow using SIPS URIs and TLS is shown in Section 3. A simple SIP call flow using SIPS URIs and TLS is shown in Section 3.
The certificates for the hosts used are shown in Section 2.2, and the The certificates for the hosts used are shown in Section 2.2, and the
CA certificates used to sign these are shown in Section 2.1. CA certificates used to sign these are shown in Section 2.1.
The text from Section 4.1 through Section 4.3 shows some simple SIP The text from Section 4.1 through Section 4.3 shows some simple SIP
call flows using S/MIME to sign and encrypt the body of the message. call flows using S/MIME to sign and encrypt the body of the message.
skipping to change at page 4, line 10 skipping to change at page 4, line 10
are made available in Appendix B. are made available in Appendix B.
Binary copies of various messages in this document that can be used Binary copies of various messages in this document that can be used
for testing appear in Appendix C. for testing appear in Appendix C.
2. Certificates 2. Certificates
2.1. CA Certificates 2.1. CA Certificates
The certificate used by the CA to sign the other certificates is The certificate used by the CA to sign the other certificates is
shown below. This is a X509v3 certificate. Note that the X.509v3 shown below. This is an X.509v3 ([X.509]) certificate. Note that
Basic Constraints in the certificate allows it to be used as a CA, the X.509v3 Basic Constraints in the certificate allows it to be used
certificate authority. This certificate is not used directly in the as a CA, certification authority. This certificate is not used
TLS call flow; it is used only to verify user and host certificates. directly in the TLS call flow; it is used only to verify user and
host certificates.
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: Serial Number:
96:a3:84:17:4e:ef:8a:4c 96:a3:84:17:4e:ef:8a:4c
Signature Algorithm: sha1WithRSAEncryption Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=California, L=San Jose, O=sipit, Issuer: C=US, ST=California, L=San Jose, O=sipit,
OU=Sipit Test Certificate Authority OU=Sipit Test Certificate Authority
Validity Validity
Not Before: Jan 27 18:36:05 2011 GMT Not Before: Jan 27 18:36:05 2011 GMT
Not After : Jan 3 18:36:05 2111 GMT Not After : Jan 3 18:36:05 2111 GMT
skipping to change at page 4, line 52 skipping to change at page 5, line 4
36:d4:28:15:6b:79:eb:d0:91:1b:21:59:b8:0e:aa: 36:d4:28:15:6b:79:eb:d0:91:1b:21:59:b8:0e:aa:
bf:d5:b1:6c:70:37:a3:3f:a5:7d:0e:95:46:f6:f6: bf:d5:b1:6c:70:37:a3:3f:a5:7d:0e:95:46:f6:f6:
58:67:83:75:42:37:18:0b:a4:41:39:b2:2f:6c:80: 58:67:83:75:42:37:18:0b:a4:41:39:b2:2f:6c:80:
2c:78:ec:a5:0f:be:9c:10:f8:c0:0b:0d:73:99:9e: 2c:78:ec:a5:0f:be:9c:10:f8:c0:0b:0d:73:99:9e:
0d:d7:97:50:cb:cc:45:34:23:49:41:85:22:24:ad: 0d:d7:97:50:cb:cc:45:34:23:49:41:85:22:24:ad:
29:c3 29:c3
Exponent: 65537 (0x10001) Exponent: 65537 (0x10001)
X509v3 extensions: X509v3 extensions:
X509v3 Subject Key Identifier: X509v3 Subject Key Identifier:
95:45:7E:5F:2B:EA:65:98:12:91:04:F3:63:C7:68:9A:58:16:77:27 95:45:7E:5F:2B:EA:65:98:12:91:04:F3:63:C7:68:9A:58:16:77:27
X509v3 Authority Key Identifier:
X509v3 Authority Key Identifier:
95:45:7E:5F:2B:EA:65:98:12:91:04:F3:63:C7:68:9A:58:16:77:27 95:45:7E:5F:2B:EA:65:98:12:91:04:F3:63:C7:68:9A:58:16:77:27
X509v3 Basic Constraints: X509v3 Basic Constraints:
CA:TRUE CA:TRUE
Signature Algorithm: sha1WithRSAEncryption Signature Algorithm: sha1WithRSAEncryption
06:5f:9e:ae:a0:9a:bc:b5:b9:5b:7e:97:33:cc:df:63:98:98: 06:5f:9e:ae:a0:9a:bc:b5:b9:5b:7e:97:33:cc:df:63:98:98:
94:cb:0d:66:a9:83:e8:aa:58:2a:59:a1:9e:47:31:a6:af:5c: 94:cb:0d:66:a9:83:e8:aa:58:2a:59:a1:9e:47:31:a6:af:5c:
3f:a2:25:86:f8:df:05:92:b7:db:69:a1:69:72:87:66:c5:ab: 3f:a2:25:86:f8:df:05:92:b7:db:69:a1:69:72:87:66:c5:ab:
35:89:01:37:19:c9:74:eb:09:d1:3f:88:7b:24:13:42:ca:2d: 35:89:01:37:19:c9:74:eb:09:d1:3f:88:7b:24:13:42:ca:2d:
fb:45:e6:cc:4b:f8:21:78:f3:f5:97:ec:09:92:24:a2:f0:e6: fb:45:e6:cc:4b:f8:21:78:f3:f5:97:ec:09:92:24:a2:f0:e6:
skipping to change at page 5, line 30 skipping to change at page 5, line 31
38:46:28:65:04:e2:01:52:dd:ec:3d:e5:f5:53:74:77:74:75: 38:46:28:65:04:e2:01:52:dd:ec:3d:e5:f5:53:74:77:74:75:
6d:c6:d9:c2:0a:ac:3b:b8:98:5c:55:53:34:74:52:a8:26:b1: 6d:c6:d9:c2:0a:ac:3b:b8:98:5c:55:53:34:74:52:a8:26:b1:
2f:30:22:d0:8b:b7:f3:a0:dd:68:07:33:d5:ae:b7:81:b2:94: 2f:30:22:d0:8b:b7:f3:a0:dd:68:07:33:d5:ae:b7:81:b2:94:
58:72:4e:7c:c6:72:2f:bd:6c:69:fb:b5:17:a8:2a:8d:d7:2c: 58:72:4e:7c:c6:72:2f:bd:6c:69:fb:b5:17:a8:2a:8d:d7:2c:
91:06:c8:0c 91:06:c8:0c
The certificate content shown above and throughout this document was The certificate content shown above and throughout this document was
rendered by the OpenSSL "x509" tool. These dumps are included only rendered by the OpenSSL "x509" tool. These dumps are included only
as informative examples. Output may vary among future revisions of as informative examples. Output may vary among future revisions of
the tool. At the time of this document's publication, there were the tool. At the time of this document's publication, there were
some irregularities in the presentation of Distinguished Names (DN). some irregularities in the presentation of Distinguished Names (DNs).
In particular, note that in the "Issuer" and "Subject" fields, it In particular, note that in the "Issuer" and "Subject" fields, it
appears the intent is to present DNs in Lightweight Directory Access appears the intent is to present DNs in Lightweight Directory Access
Protocol (LDAP) format. If this was intended, the spaces should have Protocol (LDAP) format. If this was intended, the spaces should have
been omitted after the delimiting commas, and the elements should been omitted after the delimiting commas, and the elements should
have been presented in order of most-specific to least-specific. have been presented in order of most-specific to least-specific.
Please refer to Appendix A of [RFC4514]. Using the "Issuer" DN from Please refer to Appendix A of [RFC4514]. Using the "Issuer" DN from
above as an example and following guidelines in [RFC4514], it should above as an example and following guidelines in [RFC4514], it should
have instead appeared as: have instead appeared as:
Issuer: OU=Sipit Test Certificate Authority,O=sipit,L=San Jose, Issuer: OU=Sipit Test Certificate Authority,O=sipit,L=San Jose,
ST=California,C=US ST=California,C=US
The ASN.1 parse of the CA certificate is shown below. The ASN.1 ([X.683]) parse of the CA certificate is shown below.
0:l= 949 cons: SEQUENCE 0:l= 949 cons: SEQUENCE
4:l= 669 cons: SEQUENCE 4:l= 669 cons: SEQUENCE
8:l= 3 cons: cont [ 0 ] 8:l= 3 cons: cont [ 0 ]
10:l= 1 prim: INTEGER :02 10:l= 1 prim: INTEGER :02
13:l= 9 prim: INTEGER :96A384174EEF8A4C 13:l= 9 prim: INTEGER :96A384174EEF8A4C
24:l= 13 cons: SEQUENCE 24:l= 13 cons: SEQUENCE
26:l= 9 prim: OBJECT :sha1WithRSAEncryption 26:l= 9 prim: OBJECT :sha1WithRSAEncryption
37:l= 0 prim: NULL 37:l= 0 prim: NULL
39:l= 112 cons: SEQUENCE 39:l= 112 cons: SEQUENCE
skipping to change at page 10, line 19 skipping to change at page 10, line 17
2.3. User Certificates 2.3. User Certificates
User certificates are used by many applications to establish user User certificates are used by many applications to establish user
identity. The user certificate for fluffy@example.com is shown identity. The user certificate for fluffy@example.com is shown
below. Note that the Subject Alternative Name has a list of names below. Note that the Subject Alternative Name has a list of names
with different URL types such as a sip, im, or pres URL. This is with different URL types such as a sip, im, or pres URL. This is
necessary for interoperating with a Common Profile for Instant necessary for interoperating with a Common Profile for Instant
Messaging (CPIM) gateway. In this example, example.com is the domain Messaging (CPIM) gateway. In this example, example.com is the domain
for fluffy. The message could be coming from any host in for fluffy. The message could be coming from any host in
*.example.com, and the AOR in the user certificate would still be the *.example.com, and the address-of-record (AOR) in the user
same. The others are shown in Appendix B.1. These certificates make certificate would still be the same. The others are shown in
use of the Extended Key Usage (EKU) extension discussed in [RFC5924]. Appendix B.1. These certificates make use of the Extended Key Usage
Note that the X509v3 Extended Key Usage attribute refers to the SIP (EKU) extension discussed in [RFC5924]. Note that the X509v3
OID introduced in [RFC5924], which is 1.3.6.1.5.5.7.3.20 Extended Key Usage attribute refers to the SIP OID introduced in
[RFC5924], which is 1.3.6.1.5.5.7.3.20.
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: Serial Number:
96:a3:84:17:4e:ef:8a:4d 96:a3:84:17:4e:ef:8a:4d
Signature Algorithm: sha1WithRSAEncryption Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=California, L=San Jose, O=sipit, Issuer: C=US, ST=California, L=San Jose, O=sipit,
OU=Sipit Test Certificate Authority OU=Sipit Test Certificate Authority
Validity Validity
Not Before: Feb 7 19:32:17 2011 GMT Not Before: Feb 7 19:32:17 2011 GMT
Not After : Jan 14 19:32:17 2111 GMT Not After : Jan 14 19:32:17 2111 GMT
skipping to change at page 12, line 5 skipping to change at page 12, line 5
aa:9e:b0:62:d3:36:f0:0c:b7:2f:a7:17:92:52:36:29:14:0a: aa:9e:b0:62:d3:36:f0:0c:b7:2f:a7:17:92:52:36:29:14:0a:
d6:65:86:67:73:74:6e:aa:3c:ee:47:38:1e:c8:6e:06:81:85: d6:65:86:67:73:74:6e:aa:3c:ee:47:38:1e:c8:6e:06:81:85:
1c:2e:f0:b6:04:7d:6c:38:db:81:9c:b8:07:e3:07:be:f5:2f: 1c:2e:f0:b6:04:7d:6c:38:db:81:9c:b8:07:e3:07:be:f5:2f:
09:68:63:04:6b:87:0e:36:b9:a1:a3:fb:c8:30:0c:a0:63:8d: 09:68:63:04:6b:87:0e:36:b9:a1:a3:fb:c8:30:0c:a0:63:8d:
6d:ab:0a:f8:44:b0:78:19:1a:38:7e:fa:6a:a1:d4:4b:4b:75: 6d:ab:0a:f8:44:b0:78:19:1a:38:7e:fa:6a:a1:d4:4b:4b:75:
75:bf:6f:09 75:bf:6f:09
Versions of these certificates that do not make use of EKU are also Versions of these certificates that do not make use of EKU are also
included in Appendix B.2 included in Appendix B.2
3. Callflow with Message Over TLS 3. Call Flow with Message Over TLS
3.1. TLS with Server Authentication 3.1. TLS with Server Authentication
The flow below shows the edited SSLDump output of the host The flow below shows the edited SSLDump output of the host
example.com forming a TLS [RFC5246] connection to example.net. In example.com forming a TLS [RFC5246] connection to example.net. In
this example mutual authentication is not used. Note that the client this example, mutual authentication is not used. Note that the
proposed three protocol suites including TLS_RSA_WITH_AES_128_CBC_SHA client proposed three protocol suites including
defined in [RFC5246]. The certificate returned by the server TLS_RSA_WITH_AES_128_CBC_SHA defined in [RFC5246]. The certificate
contains a Subject Alternative Name that is set to example.net. A returned by the server contains a Subject Alternative Name that is
detailed discussion of TLS can be found in SSL and TLS [EKR-TLS]. set to example.net. A detailed discussion of TLS can be found in SSL
For more details on the SSLDump tool, see the SSLDump Manual and TLS [EKR-TLS]. For more details on the SSLDump tool, see the
[ssldump-manpage]. SSLDump Manual [ssldump-manpage].
This example does not use the Server Extended Hello (see [RFC5246]). This example does not use the Server Extended Hello (see [RFC5246]).
New TCP connection #1: example.com(50738) <-> example.net(5061) New TCP connection #1: example.com(50738) <-> example.net(5061)
1 1 0.0004 (0.0004) C>SV3.1(101) Handshake 1 1 0.0004 (0.0004) C>SV3.1(101) Handshake
ClientHello ClientHello
Version 3.1 Version 3.1
random[32]= random[32]=
4c 09 5b a7 66 77 eb 43 52 30 dd 98 4d 09 23 d3 4c 09 5b a7 66 77 eb 43 52 30 dd 98 4d 09 23 d3
ff 81 74 ab 04 69 bb 79 8c dc 59 cd c2 1f b7 ec ff 81 74 ab 04 69 bb 79 8c dc 59 cd c2 1f b7 ec
skipping to change at page 15, line 5 skipping to change at page 15, line 5
Via: SIP/2.0/TLS 192.0.2.2:15001; Via: SIP/2.0/TLS 192.0.2.2:15001;
branch=z9hG4bK-d8754z-c785a077a9a8451b-1---d8754z-; branch=z9hG4bK-d8754z-c785a077a9a8451b-1---d8754z-;
rport=50738 rport=50738
</allOneLine> </allOneLine>
To: <sips:kumiko@example.net:5061>;tag=0d075510 To: <sips:kumiko@example.net:5061>;tag=0d075510
From: <sips:fluffy@example.com:15001>;tag=1a93430b From: <sips:fluffy@example.com:15001>;tag=1a93430b
Call-ID: OTZmMDE2OWNlYTVjNDkzYzBhMWRlMDU4NDExZmU4ZTQ. Call-ID: OTZmMDE2OWNlYTVjNDkzYzBhMWRlMDU4NDExZmU4ZTQ.
CSeq: 4308 MESSAGE CSeq: 4308 MESSAGE
Content-Length: 0 Content-Length: 0
4. Callflow with S/MIME-secured Message 4. Call Flow with S/MIME-Secured Message
4.1. MESSAGE Request with Signed Body 4.1. MESSAGE Request with Signed Body
Below is an example of a signed message. The values on the Content- Below is an example of a signed message. The values on the Content-
Type line (multipart/signed) and on the Content-Disposition line have Type line (multipart/signed) and on the Content-Disposition line have
been broken across lines to fit on the page, but they are not broken been broken across lines to fit on the page, but they are not broken
across lines in actual implementations. across lines in actual implementations.
MESSAGE sip:kumiko@example.net SIP/2.0 MESSAGE sip:kumiko@example.net SIP/2.0
<allOneLine> <allOneLine>
skipping to change at page 31, line 16 skipping to change at page 29, line 33
This section provides a non-exhaustive list of tests that This section provides a non-exhaustive list of tests that
implementations should perform while developing systems that use implementations should perform while developing systems that use
S/MIME and TLS for SIP. S/MIME and TLS for SIP.
Much of the required behavior for inspecting certificates when using Much of the required behavior for inspecting certificates when using
S/MIME and TLS with SIP is currently underspecified. The non- S/MIME and TLS with SIP is currently underspecified. The non-
normative recommendations in this document capture the current normative recommendations in this document capture the current
folklore around that required behavior, guided by both related folklore around that required behavior, guided by both related
normative works such as [RFC4474] (particularly, Section 13.4 Domain normative works such as [RFC4474] (particularly, Section 13.4 Domain
Names and Subordination) and informative works such as [RFC2818] Names and Subordination) and informative works such as [RFC2818],
Section 3.1. To summarize, test plans should: Section 3.1. To summarize, test plans should:
o For S/MIME secured bodies, assure that the peer's URI (address-of- o For S/MIME secured bodies, ensure that the peer's URI (address-of-
record, as per [RFC3261] Section 23.3) appears in the record, as per [RFC3261], Section 23.3) appears in the
subjectAltName of the peer's certificate as a subjectAltName of the peer's certificate as a
uniformResourceIdentifier field. uniformResourceIdentifier field.
o For TLS, assure that the peer's hostname appears as described in o For TLS, ensure that the peer's hostname appears as described in
[RFC5922]. Also: [RFC5922]. Also:
* assure an exact match in a dNSName entry in the subjectAltName * ensure an exact match in a dNSName entry in the subjectAltName
if there are any dNSNames in the subjectAltName. Wildcard if there are any dNSNames in the subjectAltName. Wildcard
matching is not allowed against these dNSName entries. See matching is not allowed against these dNSName entries. See
Section 7.1 of [RFC5922]. Section 7.1 of [RFC5922].
* assure that the most specific CommonName in the Subject field * ensure that the most specific CommonName in the Subject field
matches if there are no dNSName entries in the subjectAltName matches if there are no dNSName entries in the subjectAltName
at all (which is not the same as there being no matching at all (which is not the same as there being no matching
dNSName entries). This match can be either exact, or against dNSName entries). This match can be either exact, or against
an entry that uses the wildcard matching character '*' an entry that uses the wildcard matching character '*'.
The peer's hostname is discovered from the initial DNS query in The peer's hostname is discovered from the initial DNS query in
the server location process [RFC3263]. the server location process [RFC3263].
o IP addresses can appear in subjectAltName ([RFC5280]) of the o IP addresses can appear in subjectAltName ([RFC5280]) of the
peer's certificate, e.g. "IP:192.168.0.1". Note that if IP peer's certificate, e.g., "IP:192.168.0.1". Note that if IP
addresses are used in subjectAltName, there are important addresses are used in subjectAltName, there are important
ramifications regarding the use of Record-Route headers that also ramifications regarding the use of Record-Route headers that also
need to be considered. See Section 7.5 of [RFC5922]. Use of IP need to be considered. See Section 7.5 of [RFC5922]. Use of IP
addresses instead of domain names is inadvisable. addresses instead of domain names is inadvisable.
For each of these tests, an implementation will proceed past the For each of these tests, an implementation will proceed past the
verification point only if the certificate is "good". S/MIME verification point only if the certificate is "good". S/MIME
protected requests presenting bad certificate data will be rejected. protected requests presenting bad certificate data will be rejected.
S/MIME protected responses presenting bad certificate information S/MIME protected responses presenting bad certificate information
will be ignored. TLS connections involving bad certificate data will will be ignored. TLS connections involving bad certificate data will
skipping to change at page 32, line 29 skipping to change at page 30, line 47
6. S/MIME : Bad peer certificate (certificate, or certificate in 6. S/MIME : Bad peer certificate (certificate, or certificate in
authority chain, has been revoked) authority chain, has been revoked)
7. S/MIME : Bad peer certificate ("Digital Signature" is not 7. S/MIME : Bad peer certificate ("Digital Signature" is not
specified as an X509v3 Key Usage) specified as an X509v3 Key Usage)
8. TLS : Good peer certificate (hostname appears in dNSName in 8. TLS : Good peer certificate (hostname appears in dNSName in
subjectAltName) subjectAltName)
9. TLS : Good peer certificate (no dNSNames in subjectAltName, 9. TLS : Good peer certificate (no dNSNames in subjectAltName,
hostname appears in CN of Subject) hostname appears in Common Name (CN) of Subject)
10. TLS : Good peer certificate (CN of Subject empty, and 10. TLS : Good peer certificate (CN of Subject empty, and
subjectAltName extension contains an iPAddress stored in the subjectAltName extension contains an iPAddress stored in the
octet string in network byte order form as specified in RFC 791 octet string in network byte order form as specified in RFC 791
[RFC0791]) [RFC0791])
11. TLS : Bad peer certificate (no match in dNSNames or in the 11. TLS : Bad peer certificate (no match in dNSNames or in the
Subject CN) Subject CN)
12. TLS : Bad peer certificate (valid authority chain does not end 12. TLS : Bad peer certificate (valid authority chain does not end
skipping to change at page 34, line 5 skipping to change at page 31, line 31
15. TLS : Bad peer certificate (certificate, or certificate in 15. TLS : Bad peer certificate (certificate, or certificate in
authority chain, has been revoked) authority chain, has been revoked)
16. TLS : Bad peer certificate ("TLS Web Server Authentication" is 16. TLS : Bad peer certificate ("TLS Web Server Authentication" is
not specified as an X509v3 Key Usage) not specified as an X509v3 Key Usage)
17. TLS : Bad peer certificate (Neither "SIP Domain" nor "Any 17. TLS : Bad peer certificate (Neither "SIP Domain" nor "Any
Extended Key Usage" specified as an X509v3 Extended Key Usage, Extended Key Usage" specified as an X509v3 Extended Key Usage,
and X509v3 Extended Key Usage is present) and X509v3 Extended Key Usage is present)
7. IANA Considerations 7. Acknowledgments
No IANA actions are required.
8. Acknowledgments
Many thanks to the developers of all the open source software used to Many thanks to the developers of all the open source software used to
create these call flows. This includes the underlying crypto and TLS create these call flows. This includes the underlying crypto and TLS
software used from openssl.org, the SIP stack from software used from openssl.org, the SIP stack from
www.resiprocate.org, and the SIMPLE IMPP agent from www.sipimp.org. www.resiprocate.org, and the SIP for Instant Messaging and Presence
The TLS flow dumps were done with SSLDump from Leveraging Extensions (SIMPLE) Instant Messaging and Presence
http://www.rtfm.com/ssldump. The book "SSL and TLS" [EKR-TLS] was a Protocol (IMPP) agent from www.sipimp.org. The TLS flow dumps were
huge help in developing the code for these flows. It's sad there is done with SSLDump from http://www.rtfm.com/ssldump. The book "SSL
no second edition. and TLS" [EKR-TLS] was a huge help in developing the code for these
flows. It's sad there is no second edition.
Thanks to Jim Schaad, Russ Housley, Eric Rescorla, Dan Wing, Tat Thanks to Jim Schaad, Russ Housley, Eric Rescorla, Dan Wing, Tat
Chan, and Lyndsay Campbell who all helped find and correct mistakes Chan, and Lyndsay Campbell, who all helped find and correct mistakes
in this document. in this document.
Vijay Gurbani and Alan Jeffrey contributed much of the additional Vijay Gurbani and Alan Jeffrey contributed much of the additional
test scenario content. test scenario content.
9. Security Considerations 8. Security Considerations
Implementers must never use any of the certificates provided in this Implementers must never use any of the certificates provided in this
document in anything but a test environment. Installing the CA root document in anything but a test environment. Installing the CA root
certificates used in this document as a trusted root in operational certificates used in this document as a trusted root in operational
software would completely destroy the security of the system while software would completely destroy the security of the system while
giving the user the impression that the system was operating giving the user the impression that the system was operating
securely. securely.
This document recommends some things that implementers might test or This document recommends some things that implementers might test or
verify to improve the security of their implementations. It is verify to improve the security of their implementations. It is
skipping to change at page 37, line 5 skipping to change at page 32, line 30
This document does not show any messages to check certificate This document does not show any messages to check certificate
revocation status (see Sections 3.3 and 6.3 of [RFC5280]) as that is revocation status (see Sections 3.3 and 6.3 of [RFC5280]) as that is
not part of the SIP call flow. The expectation is that revocation not part of the SIP call flow. The expectation is that revocation
status is checked regularly to protect against the possibility of status is checked regularly to protect against the possibility of
certificate compromise or repudiation. For more information on how certificate compromise or repudiation. For more information on how
certificate revocation status can be checked, see [RFC2560] (Online certificate revocation status can be checked, see [RFC2560] (Online
Certificate Status Protocol) and [RFC5055] (Server-Based Certificate Certificate Status Protocol) and [RFC5055] (Server-Based Certificate
Validation Protocol). Validation Protocol).
10. Changelog 9. References
(RFC Editor: remove this section)
-02 to -03
* Re-worded "should" and "must" so that the document doesn't
sound like it is making normative statements. Actual normative
behavior is referred to in the respective RFCs.
* Section 5: re-worded paragraphs 4 and 5 regarding
subjectAltName, and added references.
* Section 6: added references, clarified use of IP addresses, and
clarified which From/To URI is used for comparison (from
section 23.2). Added an EKU test case.
* Section 9: added text about certificate revocation checking.
* Appendix B.3: new section to present certificate chains longer
than 2 (non-root CA).
* Made examples consistently use <allOneLine> convention.
* CSeq looks more random.
* Serial numbers in certificates are non-zero.
* All flows re-generated using new certificates. IP addresses
conform to RFC 5737.
* Updated references.
-01 to -02
* Draft is now informational, not standards track. Normative-
sounding language and references to RFC 2119 removed.
* Add TODO: change "hello" to "Hello!" in example flows for
consistency.
* Add TODO: Fix subjectAltName DNS:com to DNS:example.com and
DNS:net to DNS:example.net.
* Add TODO: use allOneLine convention from RFC4475.
* Section 3: updated open issue regarding contact headers in
MESSAGE.
* Section 3.2: added some text about RFC 3263 and connection
reuse and closed open issue.
* Section 5: clarified text about sender attaching certs, closed
issue.
* Section 5: clarified text about observed problems, closed
issue.
* Section 5: closed issue about clients vs. servers vs. proxies.
* Section 6: updated section text and open issue where IP address
is in subjectAltName.
* Section 6: added normative references and closed "folklore"
issue.
* Section 6: added cases about cert usage and broken chains,
updated OPEN ISSUE: we need a SIP EKU example.
* References: updated references to drafts and re-categorized
informative vs. normative.
* Section 9: added some text about revocation status and closed
issue.
* Appendix B: open issue: do we need non-root-CA certs and host
certs signed by them for help in testing cases in Section 6?
* Miscellaneous minor editorial changes.
-00 to -01
* Addition of OPEN ISSUES.
* Numerous minor edits from mailing list feedback.
to -00
* Changed RFC 3369 references to RFC 3852.
* Changed draft-ietf-sip-identity references to RFC 4474.
* Added an ASN.1 dump of CMS signed content where SHA-1
parameters are omitted instead of being set to ASN.1 NULL.
* Accept headers added to messages.
* User and domain certificates are generated with EKU as
specified in Draft SIP EKU.
* Message content that is shown is computed using certificates
generated with EKU.
* Message dump archive returned.
* Message archive contains messages formed with and without EKU
certificates.
prior to -00
* Incorporated the Test cases from Vijay Gurbani's and Alan
Jeffrey's Use of TLS in SIP draft
* Began to capture the folklore around where identities are
carried in certificates for use with SIP
* Removed the message dump archive pending verification (will
return in -02)
11. References
11.1. Normative References 9.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S.,
Adams, "X.509 Internet Public Key Infrastructure Online and C. Adams, "X.509 Internet Public Key
Certificate Status Protocol - OCSP", RFC 2560, June 1999. Infrastructure Online Certificate Status Protocol
- OCSP", RFC 2560, June 1999.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
A., Peterson, J., Sparks, R., Handley, M., and E. Johnston, A., Peterson, J., Sparks, R., Handley,
Schooler, "SIP: Session Initiation Protocol", RFC 3261, M., and E. Schooler, "SIP: Session Initiation
June 2002. Protocol", RFC 3261, June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session
Protocol (SIP): Locating SIP Servers", RFC 3263, Initiation Protocol (SIP): Locating SIP Servers",
June 2002. RFC 3263, June 2002.
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002. Algorithms", RFC 3370, August 2002.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension Huitema, C., and D. Gurle, "Session Initiation
for Instant Messaging", RFC 3428, December 2002. Protocol (SIP) Extension for Instant Messaging",
RFC 3428, December 2002.
[RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard
Requirement for the Session Initiation Protocol (SIP)", (AES) Requirement for the Session Initiation
RFC 3853, July 2004. Protocol (SIP)", RFC 3853, July 2004.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D.,
Polk, "Server-Based Certificate Validation Protocol and W. Polk, "Server-Based Certificate Validation
(SCVP)", RFC 5055, December 2007. Protocol (SCVP)", RFC 5055, December 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
(TLS) Protocol Version 1.2", RFC 5246, August 2008. Security (TLS) Protocol Version 1.2", RFC 5246,
August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen,
Housley, R., and W. Polk, "Internet X.509 Public Key S., Housley, R., and W. Polk, "Internet X.509
Infrastructure Certificate and Certificate Revocation List Public Key Infrastructure Certificate and
(CRL) Profile", RFC 5280, May 2008. Certificate Revocation List (CRL) Profile",
RFC 5280, May 2008.
[RFC5621] Camarillo, G., "Message Body Handling in the Session [RFC5621] Camarillo, G., "Message Body Handling in the
Initiation Protocol (SIP)", RFC 5621, September 2009. Session Initiation Protocol (SIP)", RFC 5621,
September 2009.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 5652, September 2009. STD 70, RFC 5652, September 2009.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose
Mail Extensions (S/MIME) Version 3.2 Message Internet Mail Extensions (S/MIME) Version 3.2
Specification", RFC 5751, January 2010. Message Specification", RFC 5751, January 2010.
[RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain [RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain
Certificates in the Session Initiation Protocol (SIP)", Certificates in the Session Initiation Protocol
RFC 5922, June 2010. (SIP)", RFC 5922, June 2010.
[RFC5923] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in [RFC5923] Gurbani, V., Mahy, R., and B. Tate, "Connection
the Session Initiation Protocol (SIP)", RFC 5923, Reuse in the Session Initiation Protocol (SIP)",
June 2010. RFC 5923, June 2010.
[RFC5924] Lawrence, S. and V. Gurbani, "Extended Key Usage (EKU) for [RFC5924] Lawrence, S. and V. Gurbani, "Extended Key Usage
Session Initiation Protocol (SIP) X.509 Certificates", (EKU) for Session Initiation Protocol (SIP) X.509
RFC 5924, June 2010. Certificates", RFC 5924, June 2010.
[X.509] International Telecommunications Union, "Information [X.509] International Telecommunications Union,
technology - Open Systems Interconnection - The Directory: "Information technology - Open Systems
Public-key and attribute certificate frameworks", ITU- Interconnection - The Directory: Public-key and
T Recommendation X.509 (2005), ISO/IEC 9594-8:2005. attribute certificate frameworks",
ITU-T Recommendation X.509 (2005), ISO/
IEC 9594-8:2005.
[X.683] International Telecommunications Union, "Information [X.683] International Telecommunications Union,
technology - Abstract Syntax Notation One (ASN.1): "Information technology - Abstract Syntax Notation
Parameterization of ASN.1 specifications", ITU- One (ASN.1): Parameterization of ASN.1
T Recommendation X.683 (2002), ISO/IEC 8824-4:2002, 2002. specifications", ITU-T Recommendation X.683
(2002), ISO/IEC 8824-4:2002, 2002.
11.2. Informative References 9.2. Informative References
[EKR-TLS] Rescorla, E., "SSL and TLS - Designing and Building Secure [EKR-TLS] Rescorla, E., "SSL and TLS - Designing and
Systems", 2001. Building Secure Systems", Addison-Wesley, ISBN
0-201-61598-3, 2001.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC4134] Hoffman, P., "Examples of S/MIME Messages", RFC 4134, [RFC4134] Hoffman, P., "Examples of S/MIME Messages",
July 2005. RFC 4134, July 2005.
[RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A.,
and H. Schulzrinne, "Session Initiation Protocol (SIP) Rosenberg, J., and H. Schulzrinne, "Session
Torture Test Messages", RFC 4475, May 2006. Initiation Protocol (SIP) Torture Test Messages",
RFC 4475, May 2006.
[RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol [RFC4514] Zeilenga, K., "Lightweight Directory Access
(LDAP): String Representation of Distinguished Names", Protocol (LDAP): String Representation of
RFC 4514, June 2006. Distinguished Names", RFC 4514, June 2006.
[ssldump-manpage] [ssldump-manpage] Rescorla, E., "SSLDump manpage",
Rescorla, E., "SSLDump manpage". <http://www.rtfm.com/ssldump/Ssldump.html>.
Appendix A. Making Test Certificates Appendix A. Making Test Certificates
These scripts allow you to make certificates for test purposes. The These scripts allow you to make certificates for test purposes. The
certificates will all share a common CA root so that everyone running certificates will all share a common CA root so that everyone running
these scripts can have interoperable certificates. WARNING - these these scripts can have interoperable certificates. WARNING - these
certificates are totally insecure and are for test purposes only. certificates are totally insecure and are for test purposes only.
All the CA created by this script share the same private key to All the CAs created by this script share the same private key to
facilitate interoperability testing, but this totally breaks the facilitate interoperability testing, but this totally breaks the
security since the private key of the CA is well known. security since the private key of the CA is well known.
The instructions assume a Unix-like environment with openssl The instructions assume a Unix-like environment with openssl
installed, but openssl does work in Windows too. OpenSSL version installed, but openssl does work in Windows too. OpenSSL version
0.9.8j was used to generate the certificates used in this document. 0.9.8j was used to generate the certificates used in this document.
Make sure you have openssl installed by trying to run "openssl". Run Make sure you have openssl installed by trying to run "openssl". Run
the makeCA script found in Appendix A.1; this creates a subdirectory the makeCA script found in Appendix A.1; this creates a subdirectory
called demoCA. If the makeCA script cannot find where your openssl called demoCA. If the makeCA script cannot find where your openssl
is installed you will have to set an environment variable called is installed you will have to set an environment variable called
OPENSSLDIR to whatever directory contains the file openssl.cnf. You OPENSSLDIR to whatever directory contains the file openssl.cnf. You
can find this with a "locate openssl.cnf". You are now ready to make can find this with a "locate openssl.cnf". You are now ready to make
certificates. certificates.
To create certificates for use with TLS, run the makeCert script To create certificates for use with TLS, run the makeCert script
found in Appendix A.2 with the fully qualified domain name of the found in Appendix A.2 with the fully qualified domain name of the
proxy you are making the certificate for. For example, "makeCert proxy you are making the certificate for, e.g., "makeCert
host.example.net domain eku". This will generate a private key and a host.example.net domain eku". This will generate a private key and a
certificate. The private key will be left in a file named certificate. The private key will be left in a file named
domain_key_example.net.pem in Privacy Enhanced Mail (PEM) format. domain_key_example.net.pem in Privacy Enhanced Mail (PEM) format.
The certificate will be in domain_cert_example.net.pem. Some The certificate will be in domain_cert_example.net.pem. Some
programs expect both the certificate and private key combined programs expect both the certificate and private key combined
together in a Public-key Cryptography Standards (PKCS) #12 format together in a Public-Key Cryptography Standards (PKCS) #12 format
file. This is created by the script and left in a file named file. This is created by the script and left in a file named
example.net.p12. Some programs expect this file to have a .pfx example.net.p12. Some programs expect this file to have a .pfx
extension instead of .p12 - just rename the file if needed. A file extension instead of .p12 -- just rename the file if needed. A file
with a certificate signing request, called example.net.csr, is also with a certificate signing request, called example.net.csr, is also
created and can be used to get the certificate signed by another CA. created and can be used to get the certificate signed by another CA.
A second argument indicating the number of days for which the A second argument indicating the number of days for which the
certificate should be valid can be passed to the makeCert script. It certificate should be valid can be passed to the makeCert script. It
is possible to make an expired certificate using the command is possible to make an expired certificate using the command
"makeCert host.example.net 0". "makeCert host.example.net 0".
Anywhere that a password is used to protect a certificate, the Anywhere that a password is used to protect a certificate, the
password is set to the string "password". password is set to the string "password".
skipping to change at page 44, line 10 skipping to change at page 36, line 12
The root certificate for the CA is in the file The root certificate for the CA is in the file
root_cert_fluffyCA.pem. root_cert_fluffyCA.pem.
For things that need DER format certificates, a certificate can be For things that need DER format certificates, a certificate can be
converted from PEM to DER with "openssl x509 -in cert.pem -inform PEM converted from PEM to DER with "openssl x509 -in cert.pem -inform PEM
-out cert.der -outform DER". -out cert.der -outform DER".
Some programs expect certificates in PKCS #7 format (with a file Some programs expect certificates in PKCS #7 format (with a file
extension of .p7c). You can convert these from PEM format to PKCS #7 extension of .p7c). You can convert these from PEM format to PKCS #7
with "openssl crl2pkcs7 -nocrl -certfile cert.pem -certfile demoCA/ with "openssl crl2pkcs7 -nocrl -certfile cert.pem -certfile demoCA/
cacert.pem -outform DER -out cert.p7c" cacert.pem -outform DER -out cert.p7c".
IE (version 8), Outlook Express (version 6), and Firefox (version IE (version 8), Outlook Express (version 6), and Firefox (version
3.5) can import and export .p12 files and .p7c files. You can 3.5) can import and export .p12 files and .p7c files. You can
convert a PKCS #7 certificate to PEM format with "openssl pkcs7 -in convert a PKCS #7 certificate to PEM format with "openssl pkcs7 -in
cert.p7c -inform DER -outform PEM -out cert.pem". cert.p7c -inform DER -outform PEM -out cert.pem".
The private key can be converted to PKCS #8 format with "openssl The private key can be converted to PKCS #8 format with "openssl
pkcs8 -in a_key.pem -topk8 -outform DER -out a_key.p8c" pkcs8 -in a_key.pem -topk8 -outform DER -out a_key.p8c".
In general, a TLS client will just need the root certificate of the In general, a TLS client will just need the root certificate of the
CA. A TLS server will need its private key and its certificate. CA. A TLS server will need its private key and its certificate.
These could be in two PEM files, a single file with both certificate These could be in two PEM files, a single file with both certificate
and private key PEM sections, or a single .p12 file. An S/MIME and private key PEM sections, or a single .p12 file. An S/MIME
program will need its private key and certificate, the root program will need its private key and certificate, the root
certificate of the CA, and the certificate for every other user it certificate of the CA, and the certificate for every other user it
communicates with. communicates with.
A.1. makeCA script A.1. makeCA script
skipping to change at page 73, line 7 skipping to change at page 64, line 36
2f+ntWPPm8GdrF6/SfH+LQKBgQCyDaf2kEf/cHCmiXuHxVUhrs4kccTGofE75RDi 2f+ntWPPm8GdrF6/SfH+LQKBgQCyDaf2kEf/cHCmiXuHxVUhrs4kccTGofE75RDi
hqNdyPZNhfFvu9srnTivnY2j5MJPGsksF+Qtvpk3lqySghkVt43HlT9nB/A5p5bb hqNdyPZNhfFvu9srnTivnY2j5MJPGsksF+Qtvpk3lqySghkVt43HlT9nB/A5p5bb
/7muZexQ+ua9k5UMKElOjDNbIcBFk/fFH26UWG7pPSkC/FhYVg9Q3uOvR7PBcAYy /7muZexQ+ua9k5UMKElOjDNbIcBFk/fFH26UWG7pPSkC/FhYVg9Q3uOvR7PBcAYy
cUFN6QKBgBw2k5SDvun41wNV4wxGEli9ia+i4lzg8pwJ1DUxnOcDvlDGzAzCNtW9 cUFN6QKBgBw2k5SDvun41wNV4wxGEli9ia+i4lzg8pwJ1DUxnOcDvlDGzAzCNtW9
wPoR+jvhK6V6X1mI0tqqcYZ07pC3CJBEtAckHj2Ik+ZAEjQMf+eH62Rcv6Sbozq0 wPoR+jvhK6V6X1mI0tqqcYZ07pC3CJBEtAckHj2Ik+ZAEjQMf+eH62Rcv6Sbozq0
5dFCBZwzIe2IQomg3J8+OyILSs/uzFkjGjloJIrP+OtPKSrfR+/Y 5dFCBZwzIe2IQomg3J8+OyILSs/uzFkjGjloJIrP+OtPKSrfR+/Y
-----END RSA PRIVATE KEY----- -----END RSA PRIVATE KEY-----
Appendix C. Message Dumps Appendix C. Message Dumps
This section contains a base64 encoded gzipped, compressed tar file This section contains a base64-encoded, gzipped, compressed tar file
of various Cryptographic Message Syntax (CMS) messages used in this of various Cryptographic Message Syntax (CMS) messages used in this
document. Saving the data in a file foo.tgz.b64 then running a document. Saving the data in a file foo.tgz.b64 then running a
command like "openssl base64 -d -in foo.tgz.b64 | tar xfz -" would command like "openssl base64 -d -in foo.tgz.b64 | tar xfz -" would
recover the CMS messages and allow them to be used as test vectors. recover the CMS messages and allow them to be used as test vectors.
-- BEGIN MESSAGE ARCHIVE -- -- BEGIN MESSAGE ARCHIVE --
H4sIAIpaUE0CA+ybeUATxx7HCSCIHIpoqSIQvFECu5tsDhAEDATQhCsQExTZ H4sIAIpaUE0CA+ybeUATxx7HCSCIHIpoqSIQvFECu5tsDhAEDATQhCsQExTZ
JBtIyGUSIEREREU8i1ZRqVYERVHUCqKiUBWP1vusXCJeeIv3LfpCaRUpSF8f JBtIyGUSIEREREU8i1ZRqVYERVHUCqKiUBWP1vusXCJeeIv3LfpCaRUpSF8f
tJXH/JPdmd3fTjYz8/n+fr8JT6LEKSVCCYqTKCMd+YhKp/0LAABEAgHb8Eki tJXH/JPdmd3fTjYz8/n+fr8JT6LEKSVCCYqTKCMd+YhKp/0LAABEAgHb8Eki
wp98NhSIQACxIAhDBACGIRDCAiCBQCTqYAGdv6HEKFWIQtsVrkKISD9zXVvt wp98NhSIQACxIAhDBACGIRDCAiCBQCTqYAGdv6HEKFWIQtsVrkKISD9zXVvt
skipping to change at page 76, line 15 skipping to change at page 67, line 18
Authors' Addresses Authors' Addresses
Cullen Jennings Cullen Jennings
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
Mailstop SJC-21/2 Mailstop SJC-21/2
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 408 421 9990 Phone: +1 408 421 9990
Email: fluffy@cisco.com EMail: fluffy@cisco.com
Kumiko Ono Kumiko Ono
Columbia University Columbia University
1214 Amsterdam Avenue
MC 0401
New York, NY 10027
USA
Email: kumiko@cs.columbia.edu EMail: kumiko@cs.columbia.edu
Robert Sparks Robert Sparks
Tekelec Tekelec
17210 Campbell Road 17210 Campbell Road
Suite 250 Suite 250
Dallas, TX 75252 Dallas, TX 75252
USA USA
Email: rjsparks@estacado.net EMail: Robert.Sparks@tekelec.com
Brian Hibbard (editor) Brian Hibbard (editor)
Tekelec Tekelec
17210 Campbell Road 17210 Campbell Road
Suite 250 Suite 250
Dallas, TX 75252 Dallas, TX 75252
USA USA
Email: brian@estacado.net EMail: Brian.Hibbard@tekelec.com
 End of changes. 73 change blocks. 
286 lines changed or deleted 175 lines changed or added

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