Network Working Group C. Jennings Internet-Draft Cisco Systems Intended status: Informational K. Ono Expires: May 12, 2011 Columbia University R. Sparks B. Hibbard, Ed. Tekelec November 8, 2010 Example call flows using Session Initiation Protocol (SIP) security mechanisms draft-ietf-sipcore-sec-flows-04 Abstract This document shows example call flows demonstrating the use of Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail Extensions (S/MIME) in Session Initiation Protocol (SIP). It also provides information that helps implementers build interoperable SIP software. To help facilitate interoperability testing, it includes certificates used in the example call flows and processes to create certificates for testing. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 12, 2011. Copyright Notice Jennings, et al. Expires May 12, 2011 [Page 1] Internet-Draft SIP Secure Call Flows November 2010 Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Certificates . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 4 2.2. Host Certificates . . . . . . . . . . . . . . . . . . . . 8 2.3. User Certificates . . . . . . . . . . . . . . . . . . . . 9 3. Callflow with Message Over TLS . . . . . . . . . . . . . . . . 11 3.1. TLS with Server Authentication . . . . . . . . . . . . . . 11 3.2. MESSAGE Transaction Over TLS . . . . . . . . . . . . . . . 13 4. Callflow with S/MIME-secured Message . . . . . . . . . . . . . 14 4.1. MESSAGE Request with Signed Body . . . . . . . . . . . . . 14 4.2. MESSAGE Request with Encrypted Body . . . . . . . . . . . 20 4.3. MESSAGE Request with Encrypted and Signed Body . . . . . . 22 5. Observed Interoperability Issues . . . . . . . . . . . . . . . 27 6. Additional Test Scenarios . . . . . . . . . . . . . . . . . . 29 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 31 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 11.1. Normative References . . . . . . . . . . . . . . . . . . . 33 11.2. Informative References . . . . . . . . . . . . . . . . . . 34 Appendix A. Making Test Certificates . . . . . . . . . . . . . . 35 A.1. makeCA script . . . . . . . . . . . . . . . . . . . . . . 36 A.2. makeCert script . . . . . . . . . . . . . . . . . . . . . 39 Appendix B. Certificates for Testing . . . . . . . . . . . . . . 42 B.1. Certificates Using EKU . . . . . . . . . . . . . . . . . . 42 B.2. Certificates NOT Using EKU . . . . . . . . . . . . . . . . 49 B.3. Certificate Chaining with a Non-Root CA . . . . . . . . . 57 Appendix C. Message Dumps . . . . . . . . . . . . . . . . . . . . 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66 Jennings, et al. Expires May 12, 2011 [Page 2] Internet-Draft SIP Secure Call Flows November 2010 1. Introduction This document is informational and is not normative on any aspect of SIP. SIP with TLS (RFC 5246 [13]) implementations are becoming very common. Several implementations of the S/MIME (RFC 5751 [8]) portion of SIP (RFC 3261 [3]) are also becoming available. After several interoperability events, it is clear that it is difficult to write these systems without any test vectors or examples of "known good" messages to test against. Furthermore, testing at the events is often hindered due to the lack of a commonly trusted certificate authority to sign the certificates used in the events. This document addresses both of these issues by providing messages that give detailed examples that implementers can use for comparison and that 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 Certificate Authority (CA) that can be used during the SIP interoperability events. Certificate requests from the users will be signed by the private key of the mock CA. The document also provides some hints and clarifications for implementers. 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 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 call flows using S/MIME to sign and encrypt the body of the message. The user certificates used in these examples are shown in Section 2.3. These host certificates are signed with the same mock CA private key. Section 5 presents a partial list of items that implementers should consider in order to implement systems that will interoperate. Scripts and instructions to make certificates that can be used for interoperability testing are presented in Appendix A, along with methods for converting these to various formats. The certificates used while creating the examples and test messages in this document are made available in Appendix B. Binary copies of various messages in this document that can be used for testing appear in Appendix C. 2. Certificates Jennings, et al. Expires May 12, 2011 [Page 3] Internet-Draft SIP Secure Call Flows November 2010 2.1. CA Certificates The certificate used by the CA to sign the other certificates is shown below. This is a X509v3 certificate. Note that the X.509v3 Basic Constraints in the certificate allows it to be used as a CA, certificate authority. This certificate is not used directly in the TLS call flow; it is used only to verify user and host certificates. Jennings, et al. Expires May 12, 2011 [Page 4] Internet-Draft SIP Secure Call Flows November 2010 Version: 3 (0x2) Serial Number: 96:a3:84:17:4e:ef:8a:4c Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, ST=California, L=San Jose, O=sipit, OU=Sipit Test Certificate Authority Validity Not Before: May 10 20:54:48 2010 GMT Not After : Apr 16 20:54:48 2110 GMT Subject: C=US, ST=California, L=San Jose, O=sipit, OU=Sipit Test Certificate Authority Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:c6:4d:2b:8b:79:14:07:db:c7:61:88:98:4f:a2: 7c:e3:61:80:fb:27:05:18:ed:3c:c9:0d:e5:f1:dc: 92:4e:eb:ce:77:91:4b:e7:f3:68:60:b0:40:00:6f: 74:5b:4e:1d:c9:97:c8:70:4a:66:fc:13:46:aa:d2: 98:b0:3e:9a:86:de:3c:20:d1:0b:35:a2:2d:e6:92: e6:03:49:b0:db:4c:62:2f:59:86:94:20:69:69:7a: 0a:16:5a:d5:01:a5:08:06:29:6e:85:a6:ae:a1:01: 0b:f6:1f:53:c5:95:b0:6e:b0:b4:8d:0e:f9:e9:cb: 5d:7a:44:21:14:ec:9a:a8:ad Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: 38:AD:80:84:E2:E0:16:6B:93:9F:89:F8:46:51:67:2C:DA:8D:80:9C X509v3 Authority Key Identifier: 38:AD:80:84:E2:E0:16:6B:93:9F:89:F8:46:51:67:2C:DA:8D:80:9C DirName:/C=US/ST=California/L=San Jose/O=sipit/ OU=Sipit Test Certificate Authority serial:96:A3:84:17:4E:EF:8A:4C X509v3 Basic Constraints: CA:TRUE Signature Algorithm: sha1WithRSAEncryption 2f:08:4d:b4:01:9b:79:ff:af:c8:ce:e5:5d:30:3c:fa:99:3a: 48:ba:1b:28:f8:7c:ea:d6:4a:17:85:82:e6:49:81:1b:24:bf: 01:ff:fa:fc:55:12:2b:07:b8:c0:39:fa:10:73:88:59:56:b7: 7f:96:01:30:af:89:0f:0a:6d:4e:ae:d8:04:ae:94:d4:67:78: 2a:c4:36:86:4b:e1:4c:a6:6d:46:d9:2c:73:0f:da:fe:8f:ba: 02:10:09:b7:1b:c6:13:a9:90:a9:02:15:60:61:32:79:c5:e8: 2b:d8:e4:b1:ba:eb:c7:7f:19:0c:69:b1:c6:92:af:ee:1c:74: 55:d5 The ASN.1 parse of the CA certificate is shown below. Jennings, et al. Expires May 12, 2011 [Page 5] Internet-Draft SIP Secure Call Flows November 2010 0:l= 822 cons: SEQUENCE 4:l= 671 cons: SEQUENCE 8:l= 3 cons: cont [ 0 ] 10:l= 1 prim: INTEGER :02 13:l= 9 prim: INTEGER :96A384174EEF8A4C 24:l= 13 cons: SEQUENCE 26:l= 9 prim: OBJECT :sha1WithRSAEncryption 37:l= 0 prim: NULL 39:l= 112 cons: SEQUENCE 41:l= 11 cons: SET 43:l= 9 cons: SEQUENCE 45:l= 3 prim: OBJECT :countryName 50:l= 2 prim: PRINTABLESTRING :US 54:l= 19 cons: SET 56:l= 17 cons: SEQUENCE 58:l= 3 prim: OBJECT :stateOrProvinceName 63:l= 10 prim: PRINTABLESTRING :California 75:l= 17 cons: SET 77:l= 15 cons: SEQUENCE 79:l= 3 prim: OBJECT :localityName 84:l= 8 prim: PRINTABLESTRING :San Jose 94:l= 14 cons: SET 96:l= 12 cons: SEQUENCE 98:l= 3 prim: OBJECT :organizationName 103:l= 5 prim: PRINTABLESTRING :sipit 110:l= 41 cons: SET 112:l= 39 cons: SEQUENCE 114:l= 3 prim: OBJECT :organizationalUnitName 119:l= 32 prim: PRINTABLESTRING :Sipit Test Certificate Authority 153:l= 32 cons: SEQUENCE 155:l= 13 prim: UTCTIME :100510205448Z 170:l= 15 prim: GENERALIZEDTIME :21100416205448Z 187:l= 112 cons: SEQUENCE 189:l= 11 cons: SET 191:l= 9 cons: SEQUENCE 193:l= 3 prim: OBJECT :countryName 198:l= 2 prim: PRINTABLESTRING :US 202:l= 19 cons: SET 204:l= 17 cons: SEQUENCE 206:l= 3 prim: OBJECT :stateOrProvinceName 211:l= 10 prim: PRINTABLESTRING :California 223:l= 17 cons: SET 225:l= 15 cons: SEQUENCE 227:l= 3 prim: OBJECT :localityName 232:l= 8 prim: PRINTABLESTRING :San Jose 242:l= 14 cons: SET 244:l= 12 cons: SEQUENCE 246:l= 3 prim: OBJECT :organizationName Jennings, et al. Expires May 12, 2011 [Page 6] Internet-Draft SIP Secure Call Flows November 2010 251:l= 5 prim: PRINTABLESTRING :sipit 258:l= 41 cons: SET 260:l= 39 cons: SEQUENCE 262:l= 3 prim: OBJECT :organizationalUnitName 267:l= 32 prim: PRINTABLESTRING :Sipit Test Certificate Authority 301:l= 159 cons: SEQUENCE 304:l= 13 cons: SEQUENCE 306:l= 9 prim: OBJECT :rsaEncryption 317:l= 0 prim: NULL 319:l= 141 prim: BIT STRING 00 30 81 89 02 81 81 00-c6 4d 2b 8b 79 14 07 db .0.......M+.y... c7 61 88 98 4f a2 7c e3-61 80 fb 27 05 18 ed 3c .a..O.|.a..'...< c9 0d e5 f1 dc 92 4e eb-ce 77 91 4b e7 f3 68 60 ......N..w.K..h` b0 40 00 6f 74 5b 4e 1d-c9 97 c8 70 4a 66 fc 13 .@.ot[N....pJf.. 46 aa d2 98 b0 3e 9a 86-de 3c 20 d1 0b 35 a2 2d F....>...< ..5.- e6 92 e6 03 49 b0 db 4c-62 2f 59 86 94 20 69 69 ....I..Lb/Y.. ii 7a 0a 16 5a d5 01 a5 08-06 29 6e 85 a6 ae a1 01 z..Z.....)n..... 0b f6 1f 53 c5 95 b0 6e-b0 b4 8d 0e f9 e9 cb 5d ...S...n.......] 7a 44 21 14 ec 9a a8 ad-02 03 01 00 01 zD!.......... 463:l= 213 cons: cont [ 3 ] 466:l= 210 cons: SEQUENCE 469:l= 29 cons: SEQUENCE 471:l= 3 prim: OBJECT :X509v3 Subject Key Identifier 476:l= 22 prim: OCTET STRING 04 14 38 ad 80 84 e2 e0-16 6b 93 9f 89 f8 46 51 ..8......k....FQ 67 2c da 8d 80 9c g,.... 500:l= 162 cons: SEQUENCE 503:l= 3 prim: OBJECT :X509v3 Authority Key Identifier 508:l= 154 prim: OCTET STRING 30 81 97 80 14 38 ad 80-84 e2 e0 16 6b 93 9f 89 0....8......k... f8 46 51 67 2c da 8d 80-9c a1 74 a4 72 30 70 31 .FQg,.....t.r0p1 0b 30 09 06 03 55 04 06-13 02 55 53 31 13 30 11 .0...U....US1.0. 06 03 55 04 08 13 0a 43-61 6c 69 66 6f 72 6e 69 ..U....Californi 61 31 11 30 0f 06 03 55-04 07 13 08 53 61 6e 20 a1.0...U....San 4a 6f 73 65 31 0e 30 0c-06 03 55 04 0a 13 05 73 Jose1.0...U....s 69 70 69 74 31 29 30 27-06 03 55 04 0b 13 20 53 ipit1)0'..U... S 69 70 69 74 20 54 65 73-74 20 43 65 72 74 69 66 ipit Test Certif 69 63 61 74 65 20 41 75-74 68 6f 72 69 74 79 82 icate Authority. 09 00 96 a3 84 17 4e ef-8a 4c ......N..L 665:l= 12 cons: SEQUENCE 667:l= 3 prim: OBJECT :X509v3 Basic Constraints 672:l= 5 prim: OCTET STRING 30 03 01 01 ff 0.... 679:l= 13 cons: SEQUENCE 681:l= 9 prim: OBJECT :sha1WithRSAEncryption 692:l= 0 prim: NULL 694:l= 129 prim: BIT STRING 00 2f 08 4d b4 01 9b 79-ff af c8 ce e5 5d 30 3c ./.M...y.....]0< Jennings, et al. Expires May 12, 2011 [Page 7] Internet-Draft SIP Secure Call Flows November 2010 fa 99 3a 48 ba 1b 28 f8-7c ea d6 4a 17 85 82 e6 ..:H..(.|..J.... 49 81 1b 24 bf 01 ff fa-fc 55 12 2b 07 b8 c0 39 I..$.....U.+...9 fa 10 73 88 59 56 b7 7f-96 01 30 af 89 0f 0a 6d ..s.YV....0....m 4e ae d8 04 ae 94 d4 67-78 2a c4 36 86 4b e1 4c N......gx*.6.K.L a6 6d 46 d9 2c 73 0f da-fe 8f ba 02 10 09 b7 1b .mF.,s.......... c6 13 a9 90 a9 02 15 60-61 32 79 c5 e8 2b d8 e4 .......`a2y..+.. b1 ba eb c7 7f 19 0c 69-b1 c6 92 af ee 1c 74 55 .......i......tU d5 . 2.2. Host Certificates The certificate for the host example.com is shown below. Note that the Subject Alternative Name is set to example.com and is a DNS type. The certificates for the other hosts are shown in Appendix B. Version: 3 (0x2) Serial Number: 49:02:11:01:84:01:5e Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, ST=California, L=San Jose, O=sipit, OU=Sipit Test Certificate Authority Validity Not Before: May 11 20:22:56 2010 GMT Not After : Apr 17 20:22:56 2110 GMT Subject: C=US, ST=California, L=San Jose, O=sipit, CN=example.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:d1:da:2d:b3:77:42:5f:00:99:1e:f4:b6:6c:51: 51:bb:0b:20:b3:f9:c7:93:97:ff:02:ac:81:92:d5: a1:1c:c9:24:16:46:59:d1:92:1d:0d:bf:66:3a:66: c6:5c:aa:3b:07:21:bf:45:40:63:94:20:30:81:e3: 5f:aa:e6:c7:60:aa:6c:22:8f:47:64:94:9a:71:b1: 18:51:2e:81:e9:a3:32:64:b4:38:f4:35:eb:da:3f: 6f:82:f1:7a:4d:dc:e1:c5:e3:05:1b:c1:78:83:48: d4:64:6e:98:4b:4e:ce:85:7f:0d:62:5d:1b:8a:72: c1:9d:bd:85:dc:37:f0:a7:c1:cc:60:ad:b7:39:cb: 20:ff:89:9f:65:06:35:93:5b:61:d0:04:1b:a3:d4: 70:57:d9:d5:c0:52:f4:70:0d:ca:f6:0a:42:8b:52: 47:e2:a1:cb:0e:17:9d:d6:ea:41:e5:6a:5a:29:a8: 11:af:52:65:a4:79:8e:4f:ef:fc:ec:a7:3a:ca:56: 45:b7:87:dd:e9:c7:f9:b7:f7:e8:12:f8:b5:a2:08: ce:9e:c4:cc:70:85:a6:e9:d3:cc:76:6d:11:67:b0: 00:14:a0:55:a6:63:36:fa:c2:e0:bd:45:3c:14:b0: ed:88:f6:19:14:d6:c3:a2:79:ca:be:69:52:d0:78: f1:fd Jennings, et al. Expires May 12, 2011 [Page 8] Internet-Draft SIP Secure Call Flows November 2010 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Alternative Name: DNS:example.com, URI:sip:example.com X509v3 Basic Constraints: CA:FALSE X509v3 Subject Key Identifier: AC:96:21:E6:54:7D:E7:1E:A1:F1:58:86:D9:5F:AD:CB:DC:F1:66:92 X509v3 Authority Key Identifier: 38:AD:80:84:E2:E0:16:6B:93:9F:89:F8:46:51:67:2C:DA:8D:80:9C DirName:/C=US/ST=California/L=San Jose/O=sipit/ OU=Sipit Test Certificate Authority serial:96:A3:84:17:4E:EF:8A:4C X509v3 Key Usage: Digital Signature, Non Repudiation, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, 1.3.6.1.5.5.7.3.20 Signature Algorithm: sha1WithRSAEncryption 52:ae:66:df:55:1d:99:3c:9e:17:09:3d:4a:59:19:88:8f:df: ee:2b:75:ca:c5:b3:36:ce:37:10:5f:6f:0e:f2:4f:2a:62:34: 19:5c:7a:3e:a3:cb:99:ae:a7:7c:a6:34:59:a7:43:a3:dc:ef: e5:80:86:3f:21:21:95:5b:74:4c:23:e3:1e:1d:14:43:86:48: b9:f5:c9:f0:a9:48:a3:1e:52:91:56:d5:ed:b2:56:52:8f:f4: 02:e8:4c:80:83:e6:0c:aa:e0:d6:b0:5c:75:d2:90:39:52:8b: b5:48:dc:68:bc:e5:5c:5c:dd:43:34:af:14:3a:85:60:a3:46: 17:69 The example host certificate above, as well as all the others presented in this document, are signed directly by a root CA. These certificate chains have a length equal to two: the root CA and the host certificate. Non-root CAs exist and may also sign certificates. The certificate chains presented by hosts with certificates signed by non-root CAs will have a length greater than two. For more details on how certificate chains are validated, see section 6.1.4 of RFC 5280 [14]. 2.3. User Certificates User certificates are used by many applications to establish user identity. The user certificate for fluffy@example.com is shown 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 necessary for interoperating with a CPIM gateway. In this example, example.com is the domain for fluffy. The message could be coming from any host in *.example.com, and the AOR in the user certificate would still be the same. The others are shown in Appendix B.1. Jennings, et al. Expires May 12, 2011 [Page 9] Internet-Draft SIP Secure Call Flows November 2010 These certificates make use of the EKU extension discussed in RFC 5924 [15]. Note that the X509v3 Extended Key Usage attribute refers to the SIP OID introduced in RFC 5924 [15], which is 1.3.6.1.5.5.7.3.20 Version: 3 (0x2) Serial Number: 49:02:11:01:84:01:5c Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, ST=California, L=San Jose, O=sipit, OU=Sipit Test Certificate Authority Validity Not Before: May 11 20:22:55 2010 GMT Not After : Apr 17 20:22:55 2110 GMT Subject: C=US, ST=California, L=San Jose, O=sipit, CN=fluffy@example.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:d5:9d:cf:3e:bd:83:4e:2d:df:c9:bf:86:57:cf: 0d:26:a9:e9:08:35:45:e7:5f:ae:a3:5d:60:d1:3c: 2f:6f:db:92:49:fd:05:12:68:6c:d9:ca:66:2d:02: e2:20:8a:8a:10:0a:a1:db:ee:b3:6b:c5:39:e6:4a: 49:b1:41:00:f3:f8:91:07:17:83:40:a6:bc:68:99: a6:32:08:4f:4f:34:64:ae:9f:b1:0f:9c:d5:14:96: fb:40:62:84:85:b7:ba:38:29:cc:1d:ba:19:83:d9: 59:21:ba:1e:4b:04:53:f6:aa:a6:68:4d:9a:5f:36: 90:4d:ae:01:df:58:f2:89:ec:51:c9:a1:20:65:a9: de:5c:c9:f3:57:7f:76:56:0d:23:fc:d6:26:e7:01: 25:75:2a:e4:26:3b:df:db:35:61:02:0c:0f:14:68: 18:70:13:d6:41:0a:a4:d1:5b:99:7b:32:60:78:7b: a8:95:71:80:b5:df:63:fc:ca:f4:9e:f7:a5:a0:0c: 13:6d:55:ad:17:9d:34:f2:80:66:03:86:a0:a7:83: 52:0e:ea:b7:49:ea:75:e4:c9:d8:b7:72:37:dd:30: b1:33:d4:56:26:e8:33:70:c5:97:db:ba:63:89:3f: 9c:65:45:51:18:a8:fb:96:14:09:f0:8e:55:01:f7: ad:99 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Alternative Name: URI:sip:fluffy@example.com, URI:im:fluffy@example.com, URI:pres:fluffy@example.com X509v3 Basic Constraints: CA:FALSE X509v3 Subject Key Identifier: DD:D5:75:00:3E:4C:15:7C:9C:49:C0:07:10:CB:CA:4E:07:A1:CE:4F X509v3 Authority Key Identifier: Jennings, et al. Expires May 12, 2011 [Page 10] Internet-Draft SIP Secure Call Flows November 2010 38:AD:80:84:E2:E0:16:6B:93:9F:89:F8:46:51:67:2C:DA:8D:80:9C DirName:/C=US/ST=California/L=San Jose/O=sipit/ OU=Sipit Test Certificate Authority serial:96:A3:84:17:4E:EF:8A:4C X509v3 Key Usage: Digital Signature, Non Repudiation, Key Encipherment X509v3 Extended Key Usage: E-mail Protection, 1.3.6.1.5.5.7.3.20 Signature Algorithm: sha1WithRSAEncryption 9c:c5:bc:04:88:81:19:35:2b:ba:be:d4:02:8d:41:25:45:95: 8b:cf:f6:a4:95:bc:5b:d8:eb:87:6a:48:29:34:6c:ef:87:e0: e3:73:ca:3a:dd:a3:d2:d6:74:5b:cc:00:7f:28:fc:e4:07:b6: 5c:e8:72:ea:ee:7d:40:99:58:26:b0:7d:5b:0d:36:e2:9e:b1: 40:8d:fc:af:f0:f2:60:d8:36:46:7e:a8:fa:2a:47:52:35:71: 11:ab:ec:fb:28:cf:fa:1d:a9:5d:8b:72:29:67:1d:be:fb:e3: bd:5d:c9:57:6d:75:d5:40:b5:77:52:69:b6:c4:1f:ec:03:60: 1e:a1 Versions of these certificates that do not make use of EKU are also included in Appendix B.2 3. Callflow with Message Over TLS 3.1. TLS with Server Authentication The flow below shows the edited SSLDump output of the host example.com forming a TLS RFC 5246 [13] connection to example.net. In this example mutual authentication is not used. Note that the client proposed three protocol suites including TLS_RSA_WITH_AES_128_CBC_SHA defined in RFC 5246 [13]. The certificate returned by the server contains a Subject Alternative Name that is set to example.net. A detailed discussion of TLS can be found in SSL and TLS [21]. For more details on the SSLDump tool, see the SSLDump Manual [22]. This example does not use the Server Extended Hello (see RFC 4366 [7]). New TCP connection #1: example.com(50713) <-> example.net(5061) 1 1 0.0004 (0.0004) C>SV3.1(101) Handshake ClientHello Version 3.1 random[32]= 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 Jennings, et al. Expires May 12, 2011 [Page 11] Internet-Draft SIP Secure Call Flows November 2010 cipher suites TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDH_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_256_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_DSS_RSA_WITH_AES_256_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDH_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_DES_192_CBC3_SHA TLS_ECDH_RSA_WITH_DES_192_CBC3_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_RC4_128_SHA TLS_ECDH_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 TLS_DHE_RSA_WITH_DES_CBC_SHA TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_WITH_DES_CBC_SHA TLS_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_DSS_WITH_DES_CBC_SHA TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT_WITH_RC4_40_MD5 compression methods NULL 1 2 0.0012 (0.0007) S>CV3.1(48) Handshake ServerHello Version 3.1 random[32]= 4c 09 5b a7 30 87 74 c7 16 98 24 d5 af 35 17 a7 ef c3 78 0c 94 d4 94 d2 7b a6 3f 40 04 25 f6 e0 session_id[0]= cipherSuite TLS_RSA_WITH_AES_256_CBC_SHA compressionMethod NULL 1 3 0.0012 (0.0000) S>CV3.1(1858) Handshake Certificate 1 4 0.0012 (0.0000) S>CV3.1(14) Handshake CertificateRequest certificate_types rsa_sign certificate_types dss_sign certificate_types unknown value ServerHelloDone 1 5 0.0043 (0.0031) C>SV3.1(7) Handshake Jennings, et al. Expires May 12, 2011 [Page 12] Internet-Draft SIP Secure Call Flows November 2010 Certificate 1 6 0.0043 (0.0000) C>SV3.1(262) Handshake ClientKeyExchange 1 7 0.0043 (0.0000) C>SV3.1(1) ChangeCipherSpec 1 8 0.0043 (0.0000) C>SV3.1(48) Handshake 1 9 0.0129 (0.0085) S>CV3.1(170) Handshake 1 10 0.0129 (0.0000) S>CV3.1(1) ChangeCipherSpec 1 11 0.0129 (0.0000) S>CV3.1(48) Handshake 1 12 0.0134 (0.0005) C>SV3.1(32) application_data 1 13 0.0134 (0.0000) C>SV3.1(496) application_data 1 14 0.2150 (0.2016) S>CV3.1(32) application_data 1 15 0.2150 (0.0000) S>CV3.1(336) application_data 1 16 12.2304 (12.0154) S>CV3.1(32) Alert 1 12.2310 (0.0005) S>C TCP FIN 1 17 12.2321 (0.0011) C>SV3.1(32) Alert 3.2. MESSAGE Transaction Over TLS Once the TLS session is set up, the following MESSAGE request (as defined in RFC 3428 [6] is sent from fluffy@example.com to kumiko@example.net. Note that the URI has a SIPS URL and that the VIA indicates that TLS was used. In order to format this document, the convention from RFC 4475 [20] is used to break long lines. The actual message does not contain the linebreaks contained within those tags. MESSAGE sips:kumiko@example.net:5061 SIP/2.0 Via: SIP/2.0/TLS 192.0.2.2:15001; branch=z9hG4bK-d8754z-33d8961795354459-1---d8754z-; rport=50713 Max-Forwards: 70 To: From: ;tag=10f47d62 Call-ID: ODU5YTQzYTMyYjNkZDAyODcyOGJiMWNmOWZmZmY2MGU. CSeq: 4308 MESSAGE Accept: multipart/signed, text/plain, application/pkcs7-mime, application/sdp, multipart/alternative Content-Type: text/plain Content-Length: 6 Hello! When a UA goes to send a message to example.com, the UA can see if it already has a TLS connection to example.com and if it does, it may Jennings, et al. Expires May 12, 2011 [Page 13] Internet-Draft SIP Secure Call Flows November 2010 send the message over this connection. A UA should have some scheme for reusing connections as opening a new TLS connection for every message results in awful performance. Implementers are encouraged to read RFC 5923 [17] and RFC 3263 [4]. The response is sent from example.net to example.com over the same TLS connection. It is shown below. SIP/2.0 200 OK Via: SIP/2.0/TLS 192.0.2.2:15001; branch=z9hG4bK-d8754z-33d8961795354459-1---d8754z-; rport=50713 To: ;tag=a0d41548 From: ;tag=10f47d62 Call-ID: ODU5YTQzYTMyYjNkZDAyODcyOGJiMWNmOWZmZmY2MGU. CSeq: 4308 MESSAGE Content-Length: 0 4. Callflow with S/MIME-secured Message 4.1. MESSAGE Request with Signed Body Below is an example of a signed message. The values on the Content- 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 across lines in actual implementations. Jennings, et al. Expires May 12, 2011 [Page 14] Internet-Draft SIP Secure Call Flows November 2010 MESSAGE sip:kumiko@example.net SIP/2.0 Via: SIP/2.0/TCP 192.0.2.2:15001; branch=z9hG4bK-d8754z-c947ab3f4ea84000-1---d8754z-; rport=50714 Max-Forwards: 70 To: From: ;tag=20fad54c Call-ID: NTMyZGNlOWRkODAyNGY1ZWM0MDI2ZGVmZDBhZTQwYWI. CSeq: 8473 MESSAGE Accept: multipart/signed, text/plain, application/pkcs7-mime, application/sdp, multipart/alternative Content-Type: multipart/signed;boundary=d0c5ff1dcdc8f431; micalg=sha1;protocol="application/pkcs7-signature" Content-Length: 772 --d0c5ff1dcdc8f431 Content-Type: text/plain Content-Transfer-Encoding: binary Hello! --d0c5ff1dcdc8f431 Content-Type: application/pkcs7-signature;name=smime.p7s Content-Disposition: attachment;handling=required; filename=smime.p7s Content-Transfer-Encoding: binary ***************** * BINARY BLOB 1 * ***************** --d0c5ff1dcdc8f431-- It is important to note that the signature ("BINARY BLOB 1") is computed over the MIME headers and body, but excludes the multipart boundary lines. The value on the Message-body line ends with CRLF. The CRLF is included in the boundary and is not part of the signature computation. To be clear, the signature is computed over data starting with the "C" in the "Content-Type" and ending with the "!" in the "Hello!". Jennings, et al. Expires May 12, 2011 [Page 15] Internet-Draft SIP Secure Call Flows November 2010 Content-Type: text/plain Content-Transfer-Encoding: binary Hello! Following is the ASN.1 parsing of encrypted contents referred to above as "BINARY BLOB 1". Note that at address 30, the hash for the signature is specified as SHA-1. Also note that the sender's certificate is not attached as it is optional in RFC 5652 [9]. 0 470: SEQUENCE { 4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) 15 455: [0] { 19 451: SEQUENCE { 23 1: INTEGER 1 26 11: SET { 28 9: SEQUENCE { 30 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 37 0: NULL : } : } 39 11: SEQUENCE { 41 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) : } 52 418: SET { 56 414: SEQUENCE { 60 1: INTEGER 1 63 123: SEQUENCE { 65 112: SEQUENCE { 67 11: SET { 69 9: SEQUENCE { 71 3: OBJECT IDENTIFIER countryName (2 5 4 6) 76 2: PrintableString 'US' : } : } 80 19: SET { 82 17: SEQUENCE { 84 3: OBJECT IDENTIFIER : stateOrProvinceName (2 5 4 8) 89 10: PrintableString 'California' : } : } 101 17: SET { 103 15: SEQUENCE { 105 3: OBJECT IDENTIFIER localityName (2 5 4 7) 110 8: PrintableString 'San Jose' : } : } Jennings, et al. Expires May 12, 2011 [Page 16] Internet-Draft SIP Secure Call Flows November 2010 120 14: SET { 122 12: SEQUENCE { 124 3: OBJECT IDENTIFIER : organizationName (2 5 4 10) 129 5: PrintableString 'sipit' : } : } 136 41: SET { 138 39: SEQUENCE { 140 3: OBJECT IDENTIFIER : organizationalUnitName (2 5 4 11) 145 32: PrintableString 'Sipit Test Certificate Aut hority' : } : } : } 179 7: INTEGER 49 02 11 01 84 01 5C : } 188 9: SEQUENCE { 190 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 197 0: NULL : } 199 13: SEQUENCE { 201 9: OBJECT IDENTIFIER : rsaEncryption (1 2 840 113549 1 1 1) 212 0: NULL : } 214 256: OCTET STRING : 06 AF 96 EE 1F 64 C9 B5 72 A6 07 F8 BF F7 95 4D : D9 7C D7 F6 CB 00 30 46 D4 EF BA 85 11 8A EB B9 : 03 8E F8 34 12 99 0C A9 98 53 C7 17 DE E5 66 5D : 5B A0 66 A0 93 89 53 1D 06 EC F5 10 1C DC 8B 48 : 5A 47 49 FB 02 9F 58 96 B5 2B 01 F2 F9 0A 26 7A : 08 79 1D 31 78 C0 C9 71 CA 30 4A 5A C5 64 89 80 : 62 0A FB F5 C9 5F 15 7B 56 2D 7B 3E A1 66 A8 CC : 5F 42 BD 4D 5A E1 E0 7B EB 2B E7 C5 48 53 62 4A : D0 AA 28 95 A9 0D E3 3C A0 3E 51 41 1C B1 12 5E : 47 AA A2 3A D0 7A 95 E8 6F A8 C6 0D 81 79 FE 03 : 21 50 91 1B 0A 97 DB 11 4C C8 E6 5F 2F C1 22 27 : CF 76 36 1C E0 63 37 95 65 EF BB 7F E7 56 47 5B : C5 A7 1B 76 13 97 6A 13 BD 17 37 1D BC 2B 9A 48 : 6C 20 E9 0C BE BA 4E 9D 2F 31 3E BA A4 6F EC CA : E4 02 1F 2E AD 88 2F 94 F3 C3 5D 3F BF DF 0A 41 : 30 17 1A 9F 1D F6 EB B3 7A 0B E1 42 DF 36 45 BB : } : } : } : } Jennings, et al. Expires May 12, 2011 [Page 17] Internet-Draft SIP Secure Call Flows November 2010 : } SHA-1 parameters may be omitted entirely, instead of being set to NULL, as mentioned in RFC 3370 [5]. The above dump of Blob 1 has SHA-1 parameters set to NULL. Below are the same contents signed with the same key, but omitting the NULL according to RFC 3370 [5]. This is the preferred encoding. This is covered in greater detail in Section 5. 0 466: SEQUENCE { 4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) 15 451: [0] { 19 447: SEQUENCE { 23 1: INTEGER 1 26 9: SET { 28 7: SEQUENCE { 30 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) : } : } 37 11: SEQUENCE { 39 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) : } 50 416: SET { 54 412: SEQUENCE { 58 1: INTEGER 1 61 123: SEQUENCE { 63 112: SEQUENCE { 65 11: SET { 67 9: SEQUENCE { 69 3: OBJECT IDENTIFIER countryName (2 5 4 6) 74 2: PrintableString 'US' : } : } 78 19: SET { 80 17: SEQUENCE { 82 3: OBJECT IDENTIFIER : stateOrProvinceName (2 5 4 8) 87 10: PrintableString 'California' : } : } 99 17: SET { 101 15: SEQUENCE { 103 3: OBJECT IDENTIFIER localityName (2 5 4 7) 108 8: PrintableString 'San Jose' : } : } 118 14: SET { Jennings, et al. Expires May 12, 2011 [Page 18] Internet-Draft SIP Secure Call Flows November 2010 120 12: SEQUENCE { 122 3: OBJECT IDENTIFIER : organizationName (2 5 4 10) 127 5: PrintableString 'sipit' : } : } 134 41: SET { 136 39: SEQUENCE { 138 3: OBJECT IDENTIFIER : organizationalUnitName (2 5 4 11) 143 32: PrintableString 'Sipit Test Certificate Aut hority' : } : } : } 177 7: INTEGER 49 02 11 01 84 01 5C : } 186 7: SEQUENCE { 188 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) : } 195 13: SEQUENCE { 197 9: OBJECT IDENTIFIER : rsaEncryption (1 2 840 113549 1 1 1) 208 0: NULL : } 210 256: OCTET STRING : 06 AF 96 EE 1F 64 C9 B5 72 A6 07 F8 BF F7 95 4D : D9 7C D7 F6 CB 00 30 46 D4 EF BA 85 11 8A EB B9 : 03 8E F8 34 12 99 0C A9 98 53 C7 17 DE E5 66 5D : 5B A0 66 A0 93 89 53 1D 06 EC F5 10 1C DC 8B 48 : 5A 47 49 FB 02 9F 58 96 B5 2B 01 F2 F9 0A 26 7A : 08 79 1D 31 78 C0 C9 71 CA 30 4A 5A C5 64 89 80 : 62 0A FB F5 C9 5F 15 7B 56 2D 7B 3E A1 66 A8 CC : 5F 42 BD 4D 5A E1 E0 7B EB 2B E7 C5 48 53 62 4A : D0 AA 28 95 A9 0D E3 3C A0 3E 51 41 1C B1 12 5E : 47 AA A2 3A D0 7A 95 E8 6F A8 C6 0D 81 79 FE 03 : 21 50 91 1B 0A 97 DB 11 4C C8 E6 5F 2F C1 22 27 : CF 76 36 1C E0 63 37 95 65 EF BB 7F E7 56 47 5B : C5 A7 1B 76 13 97 6A 13 BD 17 37 1D BC 2B 9A 48 : 6C 20 E9 0C BE BA 4E 9D 2F 31 3E BA A4 6F EC CA : E4 02 1F 2E AD 88 2F 94 F3 C3 5D 3F BF DF 0A 41 : 30 17 1A 9F 1D F6 EB B3 7A 0B E1 42 DF 36 45 BB : } : } : } : } : } Jennings, et al. Expires May 12, 2011 [Page 19] Internet-Draft SIP Secure Call Flows November 2010 4.2. MESSAGE Request with Encrypted Body Below is an example of an encrypted text/plain message that says "Hello!". The binary encrypted contents have been replaced with the block "BINARY BLOB 2". MESSAGE sip:kumiko@example.net SIP/2.0 Via: SIP/2.0/TCP 192.0.2.2:15001; branch=z9hG4bK-d8754z-19883b67d813801b-1---d8754z-; rport=50716 Max-Forwards: 70 To: From: ;tag=47e96625 Call-ID: NDg3ZGJjMGVhM2Y4MjdjNjU4ZDYyODhlODZkNGVlOWU. CSeq: 3260 MESSAGE Accept: multipart/signed, text/plain, application/pkcs7-mime, application/sdp, multipart/alternative Content-Disposition: attachment;handling=required; filename=smime.p7 Content-Transfer-Encoding: binary Content-Type: application/pkcs7-mime;smime-type=enveloped-data; name=smime.p7m Content-Length: 563 ***************** * BINARY BLOB 2 * ***************** Following is the ASN.1 parsing of "BINARY BLOB 2". Note that at address 452, the encryption is set to aes128-CBC. 0 559: SEQUENCE { 4 9: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3) 15 544: [0] { 19 540: SEQUENCE { 23 1: INTEGER 0 26 407: SET { 30 403: SEQUENCE { 34 1: INTEGER 0 37 123: SEQUENCE { Jennings, et al. Expires May 12, 2011 [Page 20] Internet-Draft SIP Secure Call Flows November 2010 39 112: SEQUENCE { 41 11: SET { 43 9: SEQUENCE { 45 3: OBJECT IDENTIFIER countryName (2 5 4 6) 50 2: PrintableString 'US' : } : } 54 19: SET { 56 17: SEQUENCE { 58 3: OBJECT IDENTIFIER : stateOrProvinceName (2 5 4 8) 63 10: PrintableString 'California' : } : } 75 17: SET { 77 15: SEQUENCE { 79 3: OBJECT IDENTIFIER localityName (2 5 4 7) 84 8: PrintableString 'San Jose' : } : } 94 14: SET { 96 12: SEQUENCE { 98 3: OBJECT IDENTIFIER : organizationName (2 5 4 10) 103 5: PrintableString 'sipit' : } : } 110 41: SET { 112 39: SEQUENCE { 114 3: OBJECT IDENTIFIER : organizationalUnitName (2 5 4 11) 119 32: PrintableString 'Sipit Test Certificate Aut hority' : } : } : } 153 7: INTEGER 49 02 11 01 84 01 5D : } 162 13: SEQUENCE { 164 9: OBJECT IDENTIFIER : rsaEncryption (1 2 840 113549 1 1 1) 175 0: NULL : } 177 256: OCTET STRING : 40 0B 31 3C 3D 16 C2 B3 C1 74 C8 A3 08 70 6F FB : DC 1B 40 72 A3 BB 84 0A 54 CA AD A7 5E 93 39 36 : D5 0D 29 C8 D9 B0 67 3D 75 88 C7 5B 32 0A 9A 54 : 01 59 F1 F0 AF 07 65 6B 35 4C 24 B0 D0 2A 57 8D Jennings, et al. Expires May 12, 2011 [Page 21] Internet-Draft SIP Secure Call Flows November 2010 : E0 99 1F 54 D2 45 7C 49 7B 59 C9 E2 26 FF 8D 79 : FC AD 06 67 C3 31 0E 2F FF A9 17 8C 24 AA 79 82 : B6 6E EC 87 25 B2 E7 04 88 A4 92 FB 85 AD 9C 26 : A2 D2 E8 3D F6 72 DB CD 20 EF C4 F2 0B 0F 0A 02 : 68 E9 52 B7 2E 69 3B E7 D0 EE 42 9C 9B 3E 0F B5 : DA 3B 7B 27 E0 1F D4 76 DE 0A 4B C1 4C 44 51 E8 : 05 05 FB D8 0D 69 A5 B8 1A 51 08 00 43 E2 45 EA : 8D 98 A0 7E 73 53 41 4D CB D1 77 4C FB 81 AA 26 : F5 F4 82 6E C9 F4 8B 5E 5C 13 44 F4 D6 E2 57 89 : B6 11 DD 60 A4 8A C1 77 48 98 AA BF 82 FA 5C 0E : 58 C7 A8 67 48 9E 09 97 51 2E B4 10 B3 9B 3F 62 : 77 D7 4F 61 C0 E4 AA 70 58 22 4E B4 24 6E 80 4C : } : } 437 124: SEQUENCE { 439 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 450 29: SEQUENCE { 452 9: OBJECT IDENTIFIER : aes128-CBC (2 16 840 1 101 3 4 1 2) 463 16: OCTET STRING : 22 B3 06 78 4E 7E CF 9B 99 C8 08 2F 93 85 6D 5C : } 481 80: [0] : CB F2 22 1B C0 F8 ED 86 6A CB 65 8C 08 7C BE 21 : 8A 53 3D C5 92 EE 23 E3 8A EA D6 DF B3 22 3A 00 : F9 96 4C 5F 8B 75 4F 7E 22 F7 D6 8A D3 13 56 EE : BF B7 D9 24 32 6D F1 0B E8 CF 7C FC 14 90 BE DA : F3 5E 04 38 CC D6 E5 9D 6F AF 44 BF A0 0A 3A 5C : } : } : } : } 4.3. MESSAGE Request with Encrypted and Signed Body In the example below, some of the header values have been split across mutliple lines. Where the lines have been broken, the convention has been used. This was only done to make it fit in the RFC format. Specifically, the application/pkcs7-mime Content-Type line is one line with no whitespace between the "mime;" and the "smime-type". The values are split across lines for formatting, but are not split in the real message. The binary encrypted content has been replaced with "BINARY BLOB 3", and the binary signed content has been replaced with "BINARY BLOB 4". Jennings, et al. Expires May 12, 2011 [Page 22] Internet-Draft SIP Secure Call Flows November 2010 MESSAGE sip:kumiko@example.net SIP/2.0 Via: SIP/2.0/TCP 192.0.2.2:15001; branch=z9hG4bK-d8754z-540c0075b0e6350b-1---d8754z-; rport=50717 Max-Forwards: 70 To: From: ;tag=ead36604 Call-ID: MjhmOTlmMWVmY2ZhNzAxYmZlYzNmODE2YWNhMmU4Zjg. CSeq: 5449 MESSAGE Accept: multipart/signed, text/plain, application/pkcs7-mime, application/sdp, multipart/alternative Content-Type: multipart/signed;boundary=f913571e3a21963d; micalg=sha1;protocol="application/pkcs7-signature" Content-Length: 1451 --f913571e3a21963d Content-Type: application/pkcs7-mime;smime-type=enveloped-data; name=smime.p7m Content-Disposition: attachment;handling=required; filename=smime.p7 Content-Transfer-Encoding: binary ***************** * BINARY BLOB 3 * ***************** --f913571e3a21963d Content-Type: application/pkcs7-signature;name=smime.p7s Content-Disposition: attachment;handling=required; filename=smime.p7s Content-Transfer-Encoding: binary ***************** * BINARY BLOB 4 * ***************** --f913571e3a21963d-- Jennings, et al. Expires May 12, 2011 [Page 23] Internet-Draft SIP Secure Call Flows November 2010 Below is the ASN.1 parsing of "BINARY BLOB 3". 0 559: SEQUENCE { 4 9: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3) 15 544: [0] { 19 540: SEQUENCE { 23 1: INTEGER 0 26 407: SET { 30 403: SEQUENCE { 34 1: INTEGER 0 37 123: SEQUENCE { 39 112: SEQUENCE { 41 11: SET { 43 9: SEQUENCE { 45 3: OBJECT IDENTIFIER countryName (2 5 4 6) 50 2: PrintableString 'US' : } : } 54 19: SET { 56 17: SEQUENCE { 58 3: OBJECT IDENTIFIER : stateOrProvinceName (2 5 4 8) 63 10: PrintableString 'California' : } : } 75 17: SET { 77 15: SEQUENCE { 79 3: OBJECT IDENTIFIER localityName (2 5 4 7) 84 8: PrintableString 'San Jose' : } : } 94 14: SET { 96 12: SEQUENCE { 98 3: OBJECT IDENTIFIER : organizationName (2 5 4 10) 103 5: PrintableString 'sipit' : } : } 110 41: SET { 112 39: SEQUENCE { 114 3: OBJECT IDENTIFIER : organizationalUnitName (2 5 4 11) 119 32: PrintableString 'Sipit Test Certificate Aut hority' : } : } : } 153 7: INTEGER 49 02 11 01 84 01 5D Jennings, et al. Expires May 12, 2011 [Page 24] Internet-Draft SIP Secure Call Flows November 2010 : } 162 13: SEQUENCE { 164 9: OBJECT IDENTIFIER : rsaEncryption (1 2 840 113549 1 1 1) 175 0: NULL : } 177 256: OCTET STRING : 00 50 79 F3 84 E1 0A 63 9E E3 F2 FE 87 5F 81 43 : 55 6E 5B C9 46 91 B0 FF 15 70 03 8C 07 EC 56 5D : 4F F9 8C 22 89 9C 0F EE 81 FB 5C 63 F0 5E 9E DA : AC CC D5 F2 55 CD 04 6F C3 9A 1F 56 C5 F4 FB 08 : 70 4D 07 79 54 83 AF CA 08 75 4B 4A 2A 2F 56 70 : A7 A0 B3 68 2F D0 CF 3F 77 C8 A8 DC B3 E7 81 3E : 72 2A 12 6B E6 D9 B7 23 8A B1 3F 27 D6 48 EF 2C : 14 35 8A D2 84 22 FB 41 B6 1F 23 39 DC 9A 42 60 : CD F6 5F 1C 70 22 20 86 C3 EC 3E 91 D5 62 78 66 : A1 01 3D D7 AE 1E 9A 00 38 AC 0E 21 49 C2 4A 9A : 9F BF 5D AC 50 F3 B0 39 A4 14 89 A6 F3 DA EC E0 : 84 D0 B7 2B 00 C0 C0 2A B9 FA EE DE 7A B0 FE CC : D9 1F A3 1F B7 BC 69 D3 9D 84 6B 7A 37 15 4C DB : 08 6D 55 F8 F7 38 24 3F 87 F5 66 E2 7F 5F 0F 84 : BD 1E 49 16 DD 31 BE BF 1F 7E 3E 07 AE AA 97 52 : F2 EA 8B 34 5D 5A 07 72 DB 48 B8 FE D5 41 14 36 : } : } 437 124: SEQUENCE { 439 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 450 29: SEQUENCE { 452 9: OBJECT IDENTIFIER : aes128-CBC (2 16 840 1 101 3 4 1 2) 463 16: OCTET STRING : 4F 3B 58 6A ED 07 FF BC 84 F4 03 CA 98 B2 1F 65 : } 481 80: [0] : 88 11 C3 C3 70 D0 5B E6 48 F5 50 27 C1 C2 F2 F5 : 31 3D 47 B9 FB 3E E6 AA EB DE 5C 11 40 A7 2A 5A : 7C FF 6F 10 66 68 C1 D9 8E B0 36 94 9C 60 90 30 : 6A 80 0A C6 20 50 F0 E2 03 B6 44 B3 B3 D9 AA 54 : A7 EE 12 7D F9 4D 10 56 DC 92 CE 3C C8 9C C2 F0 : } : } : } : } Below is the ASN.1 parsing of "BINARY BLOB 4". 0 470: SEQUENCE { Jennings, et al. Expires May 12, 2011 [Page 25] Internet-Draft SIP Secure Call Flows November 2010 4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) 15 455: [0] { 19 451: SEQUENCE { 23 1: INTEGER 1 26 11: SET { 28 9: SEQUENCE { 30 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 37 0: NULL : } : } 39 11: SEQUENCE { 41 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) : } 52 418: SET { 56 414: SEQUENCE { 60 1: INTEGER 1 63 123: SEQUENCE { 65 112: SEQUENCE { 67 11: SET { 69 9: SEQUENCE { 71 3: OBJECT IDENTIFIER countryName (2 5 4 6) 76 2: PrintableString 'US' : } : } 80 19: SET { 82 17: SEQUENCE { 84 3: OBJECT IDENTIFIER : stateOrProvinceName (2 5 4 8) 89 10: PrintableString 'California' : } : } 101 17: SET { 103 15: SEQUENCE { 105 3: OBJECT IDENTIFIER localityName (2 5 4 7) 110 8: PrintableString 'San Jose' : } : } 120 14: SET { 122 12: SEQUENCE { 124 3: OBJECT IDENTIFIER : organizationName (2 5 4 10) 129 5: PrintableString 'sipit' : } : } 136 41: SET { 138 39: SEQUENCE { 140 3: OBJECT IDENTIFIER : organizationalUnitName (2 5 4 11) Jennings, et al. Expires May 12, 2011 [Page 26] Internet-Draft SIP Secure Call Flows November 2010 145 32: PrintableString 'Sipit Test Certificate Aut hority' : } : } : } 179 7: INTEGER 49 02 11 01 84 01 5C : } 188 9: SEQUENCE { 190 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 197 0: NULL : } 199 13: SEQUENCE { 201 9: OBJECT IDENTIFIER : rsaEncryption (1 2 840 113549 1 1 1) 212 0: NULL : } 214 256: OCTET STRING : 25 50 A2 07 12 FC 51 08 BB FD CF A5 58 CB 35 58 : 46 79 DD D4 B7 E7 35 D7 F1 12 83 AC 94 9A C0 14 : D1 B7 9A FA 98 78 52 BA 8E DB A6 14 75 CE 1B 84 : 1A 02 DD F4 E6 7A F5 83 29 D5 A2 17 DC E9 53 76 : EF 22 8E FE 76 CC 82 A9 B4 FB 5D 1B 61 90 5E 1E : 1B CF 25 DB 24 8E A8 E1 29 4A A9 E7 BC 1A 2F 03 : 0B 3A 1C 9B 9B 93 9F E6 79 25 77 B6 54 EB 3D 8D : D4 03 69 D5 A0 52 21 1C 44 F6 73 3E 82 50 0A 00 : 46 66 85 A1 C0 8A 8A C3 3E 10 02 F4 F9 8E 63 B6 : 83 3D B2 C2 28 E5 D9 00 92 A5 13 B5 18 7C 01 D4 : 81 5D 2C 1D DB B7 DB CF 10 5E 7B E7 FC 4B 64 E2 : 00 94 B0 64 A6 9B 1D 9B BA E7 A2 D9 2D AF 22 C7 : 5C 04 60 C8 4C C1 6C 9A E5 37 6C 16 C9 00 3A 45 : 18 83 57 5F 32 17 2B 18 54 B3 3F 9F F0 E4 44 36 : 30 CF 25 53 95 1F 33 CD 01 78 DF FC 8D E4 47 40 : AC 9C 9B 5A 6B 97 04 E3 06 F7 3D CE 18 4C 54 6A : } : } : } : } : } 5. Observed Interoperability Issues This section describes some common interoperability problems. These were observed by the authors at SIPit interoperability events. Implementers should be careful to verify that their systems do not introduce these common problems, and, when possible, make their clients forgiving in what they receive. Implementations should take Jennings, et al. Expires May 12, 2011 [Page 27] Internet-Draft SIP Secure Call Flows November 2010 extra care to produce reasonable error messages when interacting with software that has these problems. Some SIP clients incorrectly only do SSLv3 and do not support TLS. Many SIP clients were found to accept expired certificates with no warning or error. When used with SIP, TLS and S/MIME provide the identity of the peer that a client is communicating with in the Subject Alternative Name in the certificate. The software checks that this name corresponds to the identity the server is trying to contact. Normative text describing path validation can be found in section 7 of RFC 5922 [16] and section 6 of RFC 5280 [14]. If a client is trying to set up a TLS connection to good.example.com and it gets a TLS connection set up with a server that presents a valid certificate but with the name evil.example.com, it will typically generate an error or warning of some type. Similarly with S/MIME, if a user is trying to communicate with sip:fluffy@example.com, one of the items in the Subject Alternate Name set in the certificate will need to match according to the certificate validation rules in section 23 of RFC 3261 [3] and section 6 of RFC 5280 [14]. Some implementations used binary MIME encodings while others used base64. It is advisable that implementations send only binary and are prepared to receive either. In several places in this document, the messages contain the encoding for the SHA-1 digest algorithm identifier. The preferred form for encoding as set out in Section 2 of RFC 3370 [5] is the form in which the optional AlgorithmIdentifier parameter field is omitted. However, RFC 3370 also says the recipients need to be able to receive the form in which the AlgorithmIdentifier parameter field is present and set to NULL. Examples of the form using NULL can be found in Section 4.2 of RFC 4134 [19]. Receivers really do need to be able to receive the form that includes the NULL because the NULL form, while not preferred, is what was observed as being generated by most implementations. Implementers should also note that if the algorithm is MD5 instead of SHA-1, then the form that omits the AlgorithmIdentifier parameters field is not allowed and the sender has to use the form where the NULL is included. The preferred encryption algorithm for S/MIME in SIP is AES as defined in RFC 3853 [10]. Observed S/MIME interoperability has been better when UAs did not attach the senders' certificates. Attaching the certificates significantly increases the size of the messages, which should be Jennings, et al. Expires May 12, 2011 [Page 28] Internet-Draft SIP Secure Call Flows November 2010 considered when sending over UDP. Furthermore, the receiver cannot rely on the sender to always send the certificate, so it does not turn out to be useful in most situations. 6. Additional Test Scenarios This section provides a non-exhaustive list of tests that implementations should perform while developing systems that use S/MIME and TLS for SIP. Much of the required behavior for inspecting certificates when using S/MIME and TLS with SIP is currently underspecified. The non- normative recommendations in this document capture the current folklore around that required behavior, guided by both related normative works such as RFC 4474 [11] (particulary, section 13.4 Domain Names and Subordination) and informative works such as RFC 2818 [18] section 3.1. To summarize, test plans should: o For S/MIME secured bodies, assure that the peer's URI (address-of- record, as per RFC 3261 [3] section 23.3) appears in the subjectAltName of the peer's certifcate as a uniformResourceIdentifier field. o For TLS, assure that the peer's hostname appears as described in RFC 5922 [16]. Also: * assure an exact match in a dNSName entry in the subjectAltName if there are any dNSNames in the subjectAltName. Wildcard matching is not allowed against these dNSName entries. See section 7.1 of RFC 5922 [16]. * assure that the most specific CommonName in the Subject field matches if there are no dNSName entries in the subjectAltName at all (which is not the same as there being no matching dNSName entries). This match can be either exact, or against an entry that uses the wildcard matching character '*' The peer's hostname is discovered from the initial DNS query in the server location process RFC 3263 [4]. o IP addresses can appear in subjectAltName (RFC 5280 [14]) of the peer's certificate, e.g. "IP:192.168.0.1". Note that if IP addresses are used in subjectAltName, there are important ramifications regarding the use of Record-Route headers that also need to be considered. See section 7.5 of RFC 5922 [16]. Use of IP addresses instead of domain names is inadvisable. For each of these tests, an implementation will proceed past the verification point only if the certificate is "good". S/MIME protected requests presenting bad certificate data will be rejected. S/MIME protected responses presenting bad certificate information will be ignored. TLS connections involving bad certificate data will not be completed. Jennings, et al. Expires May 12, 2011 [Page 29] Internet-Draft SIP Secure Call Flows November 2010 1. S/MIME : Good peer certificate 2. S/MIME : Bad peer certificate (peer URI does not appear in subjAltName) 3. S/MIME : Bad peer certificate (valid authority chain does not end at a trusted CA) 4. S/MIME : Bad peer certificate (incomplete authority chain) 5. S/MIME : Bad peer certificate (the current time does not fall within the period of validity) 6. S/MIME : Bad peer certificate (certificate or cert in authority chain has been revoked) 7. S/MIME : Bad peer certificate ("Digital Signature" is not specified as an X509v3 Key Usage) 8. TLS : Good peer certificate (hostname appears in dNSName in subjAltName) 9. TLS : Good peer certificate (no dNSNames in subjAltName, hostname appears in CN of Subject) 10. TLS : Good peer certificate (CN of Subject empty, and subjectAltName extension contains an iPAddress stored in the octet string in network byte order form as specified in RFC 791 [1]) 11. TLS : Bad peer certificate (no match in dNSNames or in the Subject CN) 12. TLS : Bad peer certificate (valid authority chain does not end at a trusted CA) 13. TLS : Bad peer certificate (incomplete authority chain) 14. TLS : Bad peer certificate (the current time does not fall within the period of validity) 15. TLS : Bad peer certificate (certificate or cert in authority chain has been revoked) 16. TLS : Bad peer certificate ("TLS Web Server Authentication" is not specified as an X509v3 Key Usage) 17. TLS : Bad peer certificate (Neither "SIP Domain" nor "Any Extended Key Usage" specified as an X509v3 Extended Key Usage, and X509v3 Extended Key Usage is present) 7. IANA Considerations No IANA actions are required. 8. Acknowledgments Many thanks to the developers of all the open source software used to create these call flows. This includes the underlying crypto and TLS software used from openssl.org, the SIP stack from www.resiprocate.org, and the SIMPLE IMPP agent from www.sipimp.org. The TLS flow dumps were done with SSLDump from Jennings, et al. Expires May 12, 2011 [Page 30] Internet-Draft SIP Secure Call Flows November 2010 http://www.rtfm.com/ssldump. The book "SSL and TLS" [21] 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 Chan, and Lyndsay Campbell who all helped find and correct mistakes in this document. Vijay Gurbani and Alan Jeffrey contributed much of the additional test scenario content. 9. Security Considerations Implementers must never use any of the certificates provided in this document in anything but a test environment. Installing the CA root certificates used in this document as a trusted root in operational software would completely destroy the security of the system while giving the user the impression that the system was operating securely. This document recommends some things that implementers might test or verify to improve the security of their implementations. It is impossible to make a comprehensive list of these, and this document only suggests some of the most common mistakes that have been seen at the SIPit interoperability events. Just because an implementation does everything this document recommends does not make it secure. This document does not show any messages to check certificate revocation status (see section 3.3 of RFC 5280 [14]) as that is not part of the SIP call flow. The expectation is that revocation status is checked regularly to protect against the possibility of certificate compromise or repudiation. For more information on how certificate revocation status can be checked, see RFC 2560 [2] (Online Certificate Status Protocol) and RFC 5055 [12] (Server-Based Certificate Validation Protocol). 10. Changelog (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. Jennings, et al. Expires May 12, 2011 [Page 31] Internet-Draft SIP Secure Call Flows November 2010 * 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 RFC 3261 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 convention. * CSeq looks more random. * Serial numbers in certs are non-zero. * All flows re-generated using new certs. 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. Jennings, et al. Expires May 12, 2011 [Page 32] Internet-Draft SIP Secure Call Flows November 2010 -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 [1] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [2] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999. [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [5] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002. [6] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Jennings, et al. Expires May 12, 2011 [Page 33] Internet-Draft SIP Secure Call Flows November 2010 Instant Messaging", RFC 3428, December 2002. [7] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006. [8] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010. [9] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009. [10] Peterson, J., "S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)", RFC 3853, July 2004. [11] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. [12] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. Polk, "Server-Based Certificate Validation Protocol (SCVP)", RFC 5055, December 2007. [13] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [14] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [15] Lawrence, S. and V. Gurbani, "Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates", RFC 5924, June 2010. [16] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Certificates in the Session Initiation Protocol (SIP)", RFC 5922, June 2010. [17] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in the Session Initiation Protocol (SIP)", RFC 5923, June 2010. 11.2. Informative References [18] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [19] Hoffman, P., "Examples of S/MIME Messages", RFC 4134, Jennings, et al. Expires May 12, 2011 [Page 34] Internet-Draft SIP Secure Call Flows November 2010 July 2005. [20] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006. [21] Rescorla, E., "SSL and TLS - Designing and Building Secure Systems", 2001. [22] Rescorla, E., "SSLDump manpage". Appendix A. Making Test Certificates These scripts allow you to make certificates for test purposes. The certificates will all share a common CA root so that everyone running these scripts can have interoperable certificates. WARNING - these certificates are totally insecure and are for test purposes only. All the CA created by this script share the same private key to facilitate interoperability testing, but this totally breaks the security since the private key of the CA is well known. The instructions assume a Unix-like environment with openssl installed, but openssl does work in Windows too. OpenSSL version 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 the makeCA script found in Appendix A.1; this creates a subdirectory called demoCA. If the makeCA script cannot find where your openssl is installed you will have to set an environment variable called OPENSSLDIR to whatever directory contains the file openssl.cnf. You can find this with a "locate openssl.cnf". You are now ready to make certificates. To create certs for use with TLS, run the makeCert script found in Appendix A.2 with the fully qualified domain name of the proxy you are making the certificate for. For example, "makeCert host.example.net". This will generate a private key and a certificate. The private key will be left in a file named domain_key_example.net.pem in pem format. The certificate will be in domain_cert_example.net.pem. Some programs expect both the certificate and private key combined together in a PKCS12 format 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 extension instead of .p12 - just rename the file if needed. A file with a certificate signing request, called example.net.csr, is also created and can be used to get the certificate signed by another CA. A second argument indicating the number of days for which the Jennings, et al. Expires May 12, 2011 [Page 35] Internet-Draft SIP Secure Call Flows November 2010 certificate should be valid can be passed to the makeCert script. It is possible to make an expired certificate using the command "makeCert host.example.net 0". Anywhere that a password is used to protect a certificate, the password is set to the string "password". The root certificate for the CA is in the file root_cert_fluffyCA.pem. For things that need DER format certificates, a certificate can be converted from PEM to DER with "openssl x509 -in cert.pem -inform PEM -out cert.der -outform DER". Some programs expect certificates in PKCS#7 format (with a file extension of .p7c). You can convert these from PEM format to PKCS#7 with "openssl crl2pkcs7 -nocrl -certfile cert.pem -certfile demoCA/ cacert.pem -outform DER -out cert.p7c" IE (version 8), Outlook Express (version 6), and Firefox (version 3.5) can import and export .p12 files and .p7c files. You can convert a pkcs7 certificate to PEM format with "openssl pkcs7 -in cert.p7c -inform DER -outform PEM -out cert.pem". The private key can be converted to pkcs8 format with "openssl 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 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 and private key PEM sections, or a single .p12 file. An S/MIME program will need its private key and certificate, the root certificate of the CA, and the certificate for every other user it communicates with. A.1. makeCA script #!/bin/sh set -x rm -rf demoCA mkdir demoCA mkdir demoCA/certs mkdir demoCA/crl mkdir demoCA/newcerts mkdir demoCA/private # This is done to generate the exact serial number used for the RFC Jennings, et al. Expires May 12, 2011 [Page 36] Internet-Draft SIP Secure Call Flows November 2010 echo "4902110184015C" > demoCA/serial touch demoCA/index.txt # You may need to modify this for where your default file is # you can find where yours in by typing "openssl ca" for D in /etc/ssl /usr/local/ssl /sw/etc/ssl /sw/share/ssl; do CONF=${OPENSSLDIR:=$D}/openssl.cnf [ -f ${CONF} ] && break done CONF=${OPENSSLDIR}/openssl.cnf if [ ! -f $CONF ]; then echo "Can not find file $CONF - set your OPENSSLDIR variable" exit fi cp $CONF openssl.cnf cat >> openssl.cnf < demoCA/private/cakey.pem < demoCA/cacert.pem < demoCA/serial # openssl req -newkey rsa:1024 -passin pass:password \ # -passout pass:password \ # -sha1 -x509 -keyout demoCA/private/cakey.pem \ # -out demoCA/cacert.pem -days 36500 -config ${CONF} <