idnits 2.17.1 draft-ietf-sipcore-sec-flows-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 3 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 13, 2010) is 4883 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 1171 ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jennings 3 Internet-Draft Cisco Systems 4 Intended status: Informational K. Ono 5 Expires: June 16, 2011 Columbia University 6 R. Sparks 7 B. Hibbard, Ed. 8 Tekelec 9 December 13, 2010 11 Example call flows using Session Initiation Protocol (SIP) security 12 mechanisms 13 draft-ietf-sipcore-sec-flows-07 15 Abstract 17 This document shows example call flows demonstrating the use of 18 Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail 19 Extensions (S/MIME) in Session Initiation Protocol (SIP). It also 20 provides information that helps implementers build interoperable SIP 21 software. To help facilitate interoperability testing, it includes 22 certificates used in the example call flows and processes to create 23 certificates for testing. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 16, 2011. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Certificates . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 4 62 2.2. Host Certificates . . . . . . . . . . . . . . . . . . . . 8 63 2.3. User Certificates . . . . . . . . . . . . . . . . . . . . 9 64 3. Callflow with Message Over TLS . . . . . . . . . . . . . . . . 12 65 3.1. TLS with Server Authentication . . . . . . . . . . . . . . 12 66 3.2. MESSAGE Transaction Over TLS . . . . . . . . . . . . . . . 13 67 4. Callflow with S/MIME-secured Message . . . . . . . . . . . . . 15 68 4.1. MESSAGE Request with Signed Body . . . . . . . . . . . . . 15 69 4.2. MESSAGE Request with Encrypted Body . . . . . . . . . . . 20 70 4.3. MESSAGE Request with Encrypted and Signed Body . . . . . . 22 71 5. Observed Interoperability Issues . . . . . . . . . . . . . . . 29 72 6. Additional Test Scenarios . . . . . . . . . . . . . . . . . . 31 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 74 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 76 10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 37 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 78 11.1. Normative References . . . . . . . . . . . . . . . . . . . 40 79 11.2. Informative References . . . . . . . . . . . . . . . . . . 41 80 Appendix A. Making Test Certificates . . . . . . . . . . . . . . 42 81 A.1. makeCA script . . . . . . . . . . . . . . . . . . . . . . 43 82 A.2. makeCert script . . . . . . . . . . . . . . . . . . . . . 47 83 Appendix B. Certificates for Testing . . . . . . . . . . . . . . 50 84 B.1. Certificates Using EKU . . . . . . . . . . . . . . . . . . 50 85 B.2. Certificates NOT Using EKU . . . . . . . . . . . . . . . . 57 86 B.3. Certificate Chaining with a Non-Root CA . . . . . . . . . 65 87 Appendix C. Message Dumps . . . . . . . . . . . . . . . . . . . . 72 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75 90 1. Introduction 92 This document is informational and is not normative on any aspect of 93 SIP. 95 SIP with TLS ([RFC5246]) implementations are becoming very common. 96 Several implementations of the S/MIME ([RFC5751]) portion of SIP 97 ([RFC3261]) are also becoming available. After several 98 interoperability events, it is clear that it is difficult to write 99 these systems without any test vectors or examples of "known good" 100 messages to test against. Furthermore, testing at the events is 101 often hindered due to the lack of a commonly trusted certificate 102 authority to sign the certificates used in the events. This document 103 addresses both of these issues by providing messages that give 104 detailed examples that implementers can use for comparison and that 105 can also be used for testing. In addition, this document provides a 106 common certificate and private key that can be used to set up a mock 107 Certificate Authority (CA) that can be used during the SIP 108 interoperability events. Certificate requests from the users will be 109 signed by the private key of the mock CA. The document also provides 110 some hints and clarifications for implementers. 112 A simple SIP call flow using SIPS URIs and TLS is shown in Section 3. 113 The certificates for the hosts used are shown in Section 2.2, and the 114 CA certificates used to sign these are shown in Section 2.1. 116 The text from Section 4.1 through Section 4.3 shows some simple SIP 117 call flows using S/MIME to sign and encrypt the body of the message. 118 The user certificates used in these examples are shown in 119 Section 2.3. These host certificates are signed with the same mock 120 CA private key. 122 Section 5 presents a partial list of items that implementers should 123 consider in order to implement systems that will interoperate. 125 Scripts and instructions to make certificates that can be used for 126 interoperability testing are presented in Appendix A, along with 127 methods for converting these to various formats. The certificates 128 used while creating the examples and test messages in this document 129 are made available in Appendix B. 131 Binary copies of various messages in this document that can be used 132 for testing appear in Appendix C. 134 2. Certificates 136 2.1. CA Certificates 138 The certificate used by the CA to sign the other certificates is 139 shown below. This is a X509v3 certificate. Note that the X.509v3 140 Basic Constraints in the certificate allows it to be used as a CA, 141 certificate authority. This certificate is not used directly in the 142 TLS call flow; it is used only to verify user and host certificates. 144 Version: 3 (0x2) 145 Serial Number: 146 96:a3:84:17:4e:ef:8a:4c 147 Signature Algorithm: sha1WithRSAEncryption 148 Issuer: C=US, ST=California, L=San Jose, O=sipit, 149 OU=Sipit Test Certificate Authority 150 Validity 151 Not Before: Dec 6 22:36:29 2010 GMT 152 Not After : Nov 12 22:36:29 2110 GMT 153 Subject: C=US, ST=California, L=San Jose, O=sipit, 154 OU=Sipit Test Certificate Authority 155 Subject Public Key Info: 156 Public Key Algorithm: rsaEncryption 157 RSA Public Key: (2048 bit) 158 Modulus (2048 bit): 159 00:ec:c0:ad:ec:3b:0d:7b:6a:95:24:96:dc:33:c2: 160 1d:f6:b3:0d:af:ed:5f:73:9c:b5:5f:dc:3a:21:95: 161 20:81:c1:29:63:a0:34:86:ed:f1:4c:8a:66:90:37: 162 95:ab:0f:8c:b2:da:55:a9:ca:ca:ae:50:10:eb:34: 163 28:d7:d8:98:5b:14:ec:fc:c4:55:d4:c6:63:5a:ee: 164 e8:ec:41:08:d3:be:28:9e:b1:89:4d:d2:6b:57:f6: 165 aa:77:c9:08:fc:f9:25:a0:a3:e3:cc:bf:f0:c0:f2: 166 99:59:e5:ef:cf:0a:3a:d7:38:bc:6b:f9:6c:ff:6e: 167 a0:d0:b2:62:4f:98:72:f0:f0:1d:1d:40:84:50:05: 168 9b:6e:15:3c:49:b6:9d:58:05:a1:0d:cf:91:ee:ed: 169 28:0f:0f:e1:0f:71:8a:a6:6e:7c:2a:ad:ae:ae:c4: 170 8d:8e:2a:2e:8a:a2:ac:67:85:2e:aa:82:0e:4b:38: 171 b1:e9:f2:84:23:0c:98:e0:57:b8:38:70:f4:89:a9: 172 94:cb:9a:5e:15:52:ba:45:0a:80:9f:33:82:cf:e2: 173 f2:eb:8f:f9:61:3c:8a:eb:74:b1:7c:87:f9:0c:2f: 174 20:ce:0d:be:69:8f:d1:bc:5d:c5:8a:e5:1a:0b:5d: 175 70:65:c8:02:f3:46:85:25:d3:88:8c:dd:80:55:d9: 176 69:9b 177 Exponent: 65537 (0x10001) 178 X509v3 extensions: 179 X509v3 Subject Key Identifier: 180 BB:37:8E:47:C7:5A:34:DB:7A:D9:F8:76:B6:75:8E:D0:E4:13:17:45 181 X509v3 Authority Key Identifier: 183 BB:37:8E:47:C7:5A:34:DB:7A:D9:F8:76:B6:75:8E:D0:E4:13:17:45 184 DirName:/C=US/ST=California/L=San Jose/O=sipit/ 185 OU=Sipit Test Certificate Authority 186 serial:96:A3:84:17:4E:EF:8A:4C 188 X509v3 Basic Constraints: 189 CA:TRUE 190 Signature Algorithm: sha1WithRSAEncryption 191 b1:75:d4:56:ab:70:14:a0:ee:67:a3:ec:07:0c:1d:8b:2c:5f: 192 d7:1c:f3:e3:01:ba:3d:9d:da:47:49:31:d5:81:f5:2d:d2:66: 193 a5:2c:1f:db:c3:2d:8a:32:6a:ec:22:8b:b1:58:63:57:23:88: 194 34:9f:6c:df:8c:7b:73:8c:2a:7c:d3:23:02:97:54:76:f3:34: 195 25:7f:d1:ad:25:87:17:56:30:61:43:f4:16:63:77:0f:7b:a7: 196 b0:0b:97:1b:05:f2:5c:86:2c:a9:d5:3b:cb:73:92:a2:3c:dc: 197 7e:12:30:86:9e:f8:57:6c:a2:a4:28:51:e4:f7:f0:ce:29:9c: 198 82:34:f2:02:3c:43:62:36:94:44:c1:ad:b4:79:f7:6e:f9:e2: 199 bd:f9:15:cc:e8:de:b0:9d:9c:2f:18:30:a9:eb:3f:d4:56:c9: 200 61:8d:78:b2:fb:4e:e5:22:1d:00:c4:cf:ce:9c:fe:d6:f1:4f: 201 01:9d:92:58:e0:78:2a:cb:69:36:18:ac:1b:53:0d:86:b1:91: 202 34:8b:de:05:5d:22:18:2a:67:e5:ea:f2:77:01:d6:9c:60:17: 203 06:84:83:6f:b6:88:7e:ce:c8:63:d4:30:6d:90:72:fe:59:f4: 204 32:04:e6:af:d4:be:99:44:c8:de:3d:01:88:d7:8a:35:30:c2: 205 2d:77:e9:70 207 The ASN.1 parse of the CA certificate is shown below. 209 0:l=1083 cons: SEQUENCE 210 4:l= 803 cons: SEQUENCE 211 8:l= 3 cons: cont [ 0 ] 212 10:l= 1 prim: INTEGER :02 213 13:l= 9 prim: INTEGER :96A384174EEF8A4C 214 24:l= 13 cons: SEQUENCE 215 26:l= 9 prim: OBJECT :sha1WithRSAEncryption 216 37:l= 0 prim: NULL 217 39:l= 112 cons: SEQUENCE 218 41:l= 11 cons: SET 219 43:l= 9 cons: SEQUENCE 220 45:l= 3 prim: OBJECT :countryName 221 50:l= 2 prim: PRINTABLESTRING :US 222 54:l= 19 cons: SET 223 56:l= 17 cons: SEQUENCE 224 58:l= 3 prim: OBJECT :stateOrProvinceName 225 63:l= 10 prim: PRINTABLESTRING :California 226 75:l= 17 cons: SET 227 77:l= 15 cons: SEQUENCE 228 79:l= 3 prim: OBJECT :localityName 229 84:l= 8 prim: PRINTABLESTRING :San Jose 230 94:l= 14 cons: SET 231 96:l= 12 cons: SEQUENCE 232 98:l= 3 prim: OBJECT :organizationName 233 103:l= 5 prim: PRINTABLESTRING :sipit 234 110:l= 41 cons: SET 235 112:l= 39 cons: SEQUENCE 236 114:l= 3 prim: OBJECT :organizationalUnitName 237 119:l= 32 prim: PRINTABLESTRING :Sipit Test Certificate Authority 238 153:l= 32 cons: SEQUENCE 239 155:l= 13 prim: UTCTIME :101206223629Z 240 170:l= 15 prim: GENERALIZEDTIME :21101112223629Z 241 187:l= 112 cons: SEQUENCE 242 189:l= 11 cons: SET 243 191:l= 9 cons: SEQUENCE 244 193:l= 3 prim: OBJECT :countryName 245 198:l= 2 prim: PRINTABLESTRING :US 246 202:l= 19 cons: SET 247 204:l= 17 cons: SEQUENCE 248 206:l= 3 prim: OBJECT :stateOrProvinceName 249 211:l= 10 prim: PRINTABLESTRING :California 250 223:l= 17 cons: SET 251 225:l= 15 cons: SEQUENCE 252 227:l= 3 prim: OBJECT :localityName 253 232:l= 8 prim: PRINTABLESTRING :San Jose 254 242:l= 14 cons: SET 255 244:l= 12 cons: SEQUENCE 256 246:l= 3 prim: OBJECT :organizationName 257 251:l= 5 prim: PRINTABLESTRING :sipit 258 258:l= 41 cons: SET 259 260:l= 39 cons: SEQUENCE 260 262:l= 3 prim: OBJECT :organizationalUnitName 261 267:l= 32 prim: PRINTABLESTRING :Sipit Test Certificate Authority 262 301:l= 290 cons: SEQUENCE 263 305:l= 13 cons: SEQUENCE 264 307:l= 9 prim: OBJECT :rsaEncryption 265 318:l= 0 prim: NULL 266 320:l= 271 prim: BIT STRING 267 00 30 82 01 0a 02 82 01-01 00 ec c0 ad ec 3b 0d .0............;. 268 7b 6a 95 24 96 dc 33 c2-1d f6 b3 0d af ed 5f 73 {j.$..3......._s 269 9c b5 5f dc 3a 21 95 20-81 c1 29 63 a0 34 86 ed .._.:!. ..)c.4.. 270 f1 4c 8a 66 90 37 95 ab-0f 8c b2 da 55 a9 ca ca .L.f.7......U... 271 ae 50 10 eb 34 28 d7 d8-98 5b 14 ec fc c4 55 d4 .P..4(...[....U. 272 c6 63 5a ee e8 ec 41 08-d3 be 28 9e b1 89 4d d2 .cZ...A...(...M. 273 6b 57 f6 aa 77 c9 08 fc-f9 25 a0 a3 e3 cc bf f0 kW..w....%...... 274 c0 f2 99 59 e5 ef cf 0a-3a d7 38 bc 6b f9 6c ff ...Y....:.8.k.l. 275 6e a0 d0 b2 62 4f 98 72-f0 f0 1d 1d 40 84 50 05 n...bO.r....@.P. 276 9b 6e 15 3c 49 b6 9d 58-05 a1 0d cf 91 ee ed 28 .n. example.net(5061) 519 1 1 0.0004 (0.0004) C>SV3.1(101) Handshake 520 ClientHello 521 Version 3.1 522 random[32]= 523 4c 09 5b a7 66 77 eb 43 52 30 dd 98 4d 09 23 d3 524 ff 81 74 ab 04 69 bb 79 8c dc 59 cd c2 1f b7 ec 525 cipher suites 526 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 527 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA 528 TLS_DHE_RSA_WITH_AES_256_SHA 529 TLS_RSA_WITH_AES_256_CBC_SHA 530 TLS_DSS_RSA_WITH_AES_256_SHA 531 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 532 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA 533 TLS_DHE_RSA_WITH_AES_128_CBC_SHA 534 TLS_RSA_WITH_AES_128_CBC_SHA 535 TLS_DHE_DSS_WITH_AES_128_CBC_SHA 536 TLS_ECDHE_RSA_WITH_DES_192_CBC3_SHA 537 TLS_ECDH_RSA_WITH_DES_192_CBC3_SHA 538 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA 539 TLS_RSA_WITH_3DES_EDE_CBC_SHA 540 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 541 TLS_ECDHE_RSA_WITH_RC4_128_SHA 542 TLS_ECDH_RSA_WITH_RC4_128_SHA 543 TLS_RSA_WITH_RC4_128_SHA 544 TLS_RSA_WITH_RC4_128_MD5 545 TLS_DHE_RSA_WITH_DES_CBC_SHA 546 TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA 547 TLS_RSA_WITH_DES_CBC_SHA 548 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA 549 TLS_DHE_DSS_WITH_DES_CBC_SHA 550 TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA 551 TLS_RSA_EXPORT_WITH_RC4_40_MD5 552 compression methods 553 NULL 554 1 2 0.0012 (0.0007) S>CV3.1(48) Handshake 555 ServerHello 556 Version 3.1 557 random[32]= 558 4c 09 5b a7 30 87 74 c7 16 98 24 d5 af 35 17 a7 559 ef c3 78 0c 94 d4 94 d2 7b a6 3f 40 04 25 f6 e0 560 session_id[0]= 562 cipherSuite TLS_RSA_WITH_AES_256_CBC_SHA 563 compressionMethod NULL 564 1 3 0.0012 (0.0000) S>CV3.1(1858) Handshake 565 Certificate 566 1 4 0.0012 (0.0000) S>CV3.1(14) Handshake 567 CertificateRequest 568 certificate_types rsa_sign 569 certificate_types dss_sign 570 certificate_types unknown value 571 ServerHelloDone 572 1 5 0.0043 (0.0031) C>SV3.1(7) Handshake 573 Certificate 574 1 6 0.0043 (0.0000) C>SV3.1(262) Handshake 575 ClientKeyExchange 576 1 7 0.0043 (0.0000) C>SV3.1(1) ChangeCipherSpec 577 1 8 0.0043 (0.0000) C>SV3.1(48) Handshake 578 1 9 0.0129 (0.0085) S>CV3.1(170) Handshake 579 1 10 0.0129 (0.0000) S>CV3.1(1) ChangeCipherSpec 580 1 11 0.0129 (0.0000) S>CV3.1(48) Handshake 581 1 12 0.0134 (0.0005) C>SV3.1(32) application_data 582 1 13 0.0134 (0.0000) C>SV3.1(496) application_data 583 1 14 0.2150 (0.2016) S>CV3.1(32) application_data 584 1 15 0.2150 (0.0000) S>CV3.1(336) application_data 585 1 16 12.2304 (12.0154) S>CV3.1(32) Alert 586 1 12.2310 (0.0005) S>C TCP FIN 587 1 17 12.2321 (0.0011) C>SV3.1(32) Alert 589 3.2. MESSAGE Transaction Over TLS 591 Once the TLS session is set up, the following MESSAGE request (as 592 defined in [RFC3428] is sent from fluffy@example.com to 593 kumiko@example.net. Note that the URI has a SIPS URL and that the 594 VIA indicates that TLS was used. In order to format this document, 595 the convention from [RFC4475] is used to break long 596 lines. The actual message does not contain the linebreaks contained 597 within those tags. 599 MESSAGE sips:kumiko@example.net:5061 SIP/2.0 600 601 Via: SIP/2.0/TLS 192.0.2.2:15001; 602 branch=z9hG4bK-d8754z-3bcb7c685f585679-1---d8754z-; 603 rport=58315 604 605 Max-Forwards: 70 606 To: 607 From: ;tag=b5220b64 608 Call-ID: ZDQ1ZjNhMjQxZjZlYjNkZjUyYjJhMDA5MTAxYjRhMmE. 609 CSeq: 4308 MESSAGE 610 611 Accept: multipart/signed, text/plain, application/pkcs7-mime, 612 application/sdp, multipart/alternative 613 614 Content-Type: text/plain 615 Content-Length: 6 617 Hello! 619 When a User Agent (UA) goes to send a message to example.com, the UA 620 can see if it already has a TLS connection to example.com and if it 621 does, it may send the message over this connection. A UA should have 622 some scheme for reusing connections as opening a new TLS connection 623 for every message results in awful performance. Implementers are 624 encouraged to read [RFC5923] and [RFC3263]. 626 The response is sent from example.net to example.com over the same 627 TLS connection. It is shown below. 629 SIP/2.0 200 OK 630 631 Via: SIP/2.0/TLS 192.0.2.2:15001; 632 branch=z9hG4bK-d8754z-3bcb7c685f585679-1---d8754z-; 633 rport=58315 634 635 To: ;tag=35b8014f 636 From: ;tag=b5220b64 637 Call-ID: ZDQ1ZjNhMjQxZjZlYjNkZjUyYjJhMDA5MTAxYjRhMmE. 638 CSeq: 4308 MESSAGE 639 Content-Length: 0 641 4. Callflow with S/MIME-secured Message 643 4.1. MESSAGE Request with Signed Body 645 Below is an example of a signed message. The values on the Content- 646 Type line (multipart/signed) and on the Content-Disposition line have 647 been broken across lines to fit on the page, but they are not broken 648 across lines in actual implementations. 650 MESSAGE sip:kumiko@example.net SIP/2.0 651 652 Via: SIP/2.0/TCP 192.0.2.2:15001; 653 branch=z9hG4bK-d8754z-81e4f73858c3585d-1---d8754z-; 654 rport=58316 655 656 Max-Forwards: 70 657 To: 658 From: ;tag=74a11610 659 Call-ID: MzBlOGM0NzkwOTExM2MyMGMyMzU3OWMzZGU0Y2Y1MTg. 660 CSeq: 8473 MESSAGE 661 662 Accept: multipart/signed, text/plain, application/pkcs7-mime, 663 application/sdp, multipart/alternative 664 665 666 Content-Type: multipart/signed;boundary=7fbf310bbfc8c71c; 667 micalg=sha1;protocol="application/pkcs7-signature" 668 669 Content-Length: 774 671 --7fbf310bbfc8c71c 672 Content-Type: text/plain 673 Content-Transfer-Encoding: binary 675 Hello! 676 --7fbf310bbfc8c71c 677 Content-Type: application/pkcs7-signature;name=smime.p7s 678 679 Content-Disposition: attachment;handling=required; 680 filename=smime.p7s 681 682 Content-Transfer-Encoding: binary 684 ***************** 685 * BINARY BLOB 1 * 686 ***************** 687 --7fbf310bbfc8c71c-- 688 It is important to note that the signature ("BINARY BLOB 1") is 689 computed over the MIME headers and body, but excludes the multipart 690 boundary lines. The value on the Message-body line ends with CRLF. 691 The CRLF is included in the boundary and is not part of the signature 692 computation. To be clear, the signature is computed over data 693 starting with the "C" in the "Content-Type" and ending with the "!" 694 in the "Hello!". 696 Content-Type: text/plain 697 Content-Transfer-Encoding: binary 699 Hello! 701 Following is the ASN.1 parsing of encrypted contents referred to 702 above as "BINARY BLOB 1". Note that at address 30, the hash for the 703 signature is specified as SHA-1. Also note that the sender's 704 certificate is not attached as it is optional in [RFC5652]. 706 0 472: SEQUENCE { 707 4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) 708 15 457: [0] { 709 19 453: SEQUENCE { 710 23 1: INTEGER 1 711 26 11: SET { 712 28 9: SEQUENCE { 713 30 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 714 37 0: NULL 715 : } 716 : } 717 39 11: SEQUENCE { 718 41 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 719 : } 720 52 420: SET { 721 56 416: SEQUENCE { 722 60 1: INTEGER 1 723 63 125: SEQUENCE { 724 65 112: SEQUENCE { 725 67 11: SET { 726 69 9: SEQUENCE { 727 71 3: OBJECT IDENTIFIER countryName (2 5 4 6) 728 76 2: PrintableString 'US' 729 : } 730 : } 731 80 19: SET { 732 82 17: SEQUENCE { 733 84 3: OBJECT IDENTIFIER 734 : stateOrProvinceName (2 5 4 8) 735 89 10: PrintableString 'California' 736 : } 737 : } 738 101 17: SET { 739 103 15: SEQUENCE { 740 105 3: OBJECT IDENTIFIER localityName (2 5 4 7) 741 110 8: PrintableString 'San Jose' 742 : } 743 : } 744 120 14: SET { 745 122 12: SEQUENCE { 746 124 3: OBJECT IDENTIFIER 747 : organizationName (2 5 4 10) 748 129 5: PrintableString 'sipit' 749 : } 750 : } 751 136 41: SET { 752 138 39: SEQUENCE { 753 140 3: OBJECT IDENTIFIER 754 : organizationalUnitName (2 5 4 11) 755 145 32: PrintableString 'Sipit Test Certificate Aut 756 hority' 757 : } 758 : } 759 : } 760 179 9: INTEGER 00 96 A3 84 17 4E EF 8A 4D 761 : } 762 190 9: SEQUENCE { 763 192 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 764 199 0: NULL 765 : } 766 201 13: SEQUENCE { 767 203 9: OBJECT IDENTIFIER 768 : rsaEncryption (1 2 840 113549 1 1 1) 769 214 0: NULL 770 : } 771 216 256: OCTET STRING 772 : 0F 8A 9A BE F0 A8 9B 91 3D C1 4A E5 62 C1 FB 5D 773 : 69 70 4E 36 F8 3C C5 7A D5 06 6A 62 1E 6C 2E 17 774 : 0D 3C 91 B5 39 C7 81 CF 77 B7 61 3B 2E 97 76 C0 775 : 3A 97 15 A7 32 3B 3E 79 AB FD 97 E0 2E 41 E7 8B 776 : F6 20 19 E1 1B B7 73 E2 16 F8 44 01 4D 59 6E DB 777 : 1B 49 FA 48 7E BE 96 32 4F 92 3E 2B 36 D1 26 2B 778 : 37 9B 01 CD C7 39 FA A5 29 41 A5 ED BD F3 71 DB 779 : 82 5A 2D E9 3A D2 E6 BF 10 F3 41 AF 6A 20 82 D4 780 : 69 50 FB 70 DA 88 A3 C3 91 C5 10 CE 3D 80 55 AE 781 : 8C 99 1E 54 B6 06 3E CA 64 90 FA E2 4F A6 B0 40 782 : 3E A1 9D D2 E8 7C BF 40 69 6E 80 AF 73 6E 2C 7F 783 : DD A3 08 FF 52 F1 41 51 4D 86 34 5A 1C D6 92 3C 784 : 87 C8 0A 52 32 8D AA F6 45 1B 5C A0 6A E7 64 1E 785 : 29 12 84 53 4B 2E 0B 72 0E 5E 5B 9A 4B 4A FE F6 786 : 64 3E 78 8A 5B 9C 45 C0 62 FF E6 F6 89 25 00 73 787 : 19 4B E0 08 D2 F5 FE 32 D2 47 EC F1 4D 74 7C 26 788 : } 789 : } 790 : } 791 : } 792 : } 794 SHA-1 parameters may be omitted entirely, instead of being set to 795 NULL, as mentioned in [RFC3370]. The above dump of Blob 1 has SHA-1 796 parameters set to NULL. Below are the same contents signed with the 797 same key, but omitting the NULL according to [RFC3370]. This is the 798 preferred encoding. This is covered in greater detail in Section 5. 800 0 468: SEQUENCE { 801 4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) 802 15 453: [0] { 803 19 449: SEQUENCE { 804 23 1: INTEGER 1 805 26 9: SET { 806 28 7: SEQUENCE { 807 30 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 808 : } 809 : } 810 37 11: SEQUENCE { 811 39 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 812 : } 813 50 418: SET { 814 54 414: SEQUENCE { 815 58 1: INTEGER 1 816 61 125: SEQUENCE { 817 63 112: SEQUENCE { 818 65 11: SET { 819 67 9: SEQUENCE { 820 69 3: OBJECT IDENTIFIER countryName (2 5 4 6) 821 74 2: PrintableString 'US' 822 : } 823 : } 824 78 19: SET { 825 80 17: SEQUENCE { 826 82 3: OBJECT IDENTIFIER 827 : stateOrProvinceName (2 5 4 8) 828 87 10: PrintableString 'California' 829 : } 830 : } 832 99 17: SET { 833 101 15: SEQUENCE { 834 103 3: OBJECT IDENTIFIER localityName (2 5 4 7) 835 108 8: PrintableString 'San Jose' 836 : } 837 : } 838 118 14: SET { 839 120 12: SEQUENCE { 840 122 3: OBJECT IDENTIFIER 841 : organizationName (2 5 4 10) 842 127 5: PrintableString 'sipit' 843 : } 844 : } 845 134 41: SET { 846 136 39: SEQUENCE { 847 138 3: OBJECT IDENTIFIER 848 : organizationalUnitName (2 5 4 11) 849 143 32: PrintableString 'Sipit Test Certificate Aut 850 hority' 851 : } 852 : } 853 : } 854 177 9: INTEGER 00 96 A3 84 17 4E EF 8A 4D 855 : } 856 188 7: SEQUENCE { 857 190 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 858 : } 859 197 13: SEQUENCE { 860 199 9: OBJECT IDENTIFIER 861 : rsaEncryption (1 2 840 113549 1 1 1) 862 210 0: NULL 863 : } 864 212 256: OCTET STRING 865 : 0F 8A 9A BE F0 A8 9B 91 3D C1 4A E5 62 C1 FB 5D 866 : 69 70 4E 36 F8 3C C5 7A D5 06 6A 62 1E 6C 2E 17 867 : 0D 3C 91 B5 39 C7 81 CF 77 B7 61 3B 2E 97 76 C0 868 : 3A 97 15 A7 32 3B 3E 79 AB FD 97 E0 2E 41 E7 8B 869 : F6 20 19 E1 1B B7 73 E2 16 F8 44 01 4D 59 6E DB 870 : 1B 49 FA 48 7E BE 96 32 4F 92 3E 2B 36 D1 26 2B 871 : 37 9B 01 CD C7 39 FA A5 29 41 A5 ED BD F3 71 DB 872 : 82 5A 2D E9 3A D2 E6 BF 10 F3 41 AF 6A 20 82 D4 873 : 69 50 FB 70 DA 88 A3 C3 91 C5 10 CE 3D 80 55 AE 874 : 8C 99 1E 54 B6 06 3E CA 64 90 FA E2 4F A6 B0 40 875 : 3E A1 9D D2 E8 7C BF 40 69 6E 80 AF 73 6E 2C 7F 876 : DD A3 08 FF 52 F1 41 51 4D 86 34 5A 1C D6 92 3C 877 : 87 C8 0A 52 32 8D AA F6 45 1B 5C A0 6A E7 64 1E 878 : 29 12 84 53 4B 2E 0B 72 0E 5E 5B 9A 4B 4A FE F6 879 : 64 3E 78 8A 5B 9C 45 C0 62 FF E6 F6 89 25 00 73 880 : 19 4B E0 08 D2 F5 FE 32 D2 47 EC F1 4D 74 7C 26 881 : } 882 : } 883 : } 884 : } 885 : } 887 4.2. MESSAGE Request with Encrypted Body 889 Below is an example of an encrypted text/plain message that says 890 "Hello!". The binary encrypted contents have been replaced with the 891 block "BINARY BLOB 2". 893 MESSAGE sip:kumiko@example.net SIP/2.0 894 895 Via: SIP/2.0/TCP 192.0.2.2:15001; 896 branch=z9hG4bK-d8754z-609333791d00044c-1---d8754z-; 897 rport=58318 898 899 Max-Forwards: 70 900 To: 901 From: ;tag=625ceb5b 902 Call-ID: NDY4ZjJjMDllZTA4OTNlYjNhYjQ3NmE1YjIzODk5NGM. 903 CSeq: 3260 MESSAGE 904 905 Accept: multipart/signed, text/plain, application/pkcs7-mime, 906 application/sdp, multipart/alternative 907 908 909 Content-Disposition: attachment;handling=required; 910 filename=smime.p7 911 912 Content-Transfer-Encoding: binary 913 914 Content-Type: application/pkcs7-mime;smime-type=enveloped-data; 915 name=smime.p7m 916 917 Content-Length: 565 919 ***************** 920 * BINARY BLOB 2 * 921 ***************** 923 Following is the ASN.1 parsing of "BINARY BLOB 2". Note that at 924 address 454, the encryption is set to aes128-CBC. 926 0 561: SEQUENCE { 927 4 9: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3) 928 15 546: [0] { 929 19 542: SEQUENCE { 930 23 1: INTEGER 0 931 26 409: SET { 932 30 405: SEQUENCE { 933 34 1: INTEGER 0 934 37 125: SEQUENCE { 935 39 112: SEQUENCE { 936 41 11: SET { 937 43 9: SEQUENCE { 938 45 3: OBJECT IDENTIFIER countryName (2 5 4 6) 939 50 2: PrintableString 'US' 940 : } 941 : } 942 54 19: SET { 943 56 17: SEQUENCE { 944 58 3: OBJECT IDENTIFIER 945 : stateOrProvinceName (2 5 4 8) 946 63 10: PrintableString 'California' 947 : } 948 : } 949 75 17: SET { 950 77 15: SEQUENCE { 951 79 3: OBJECT IDENTIFIER localityName (2 5 4 7) 952 84 8: PrintableString 'San Jose' 953 : } 954 : } 955 94 14: SET { 956 96 12: SEQUENCE { 957 98 3: OBJECT IDENTIFIER 958 : organizationName (2 5 4 10) 959 103 5: PrintableString 'sipit' 960 : } 961 : } 962 110 41: SET { 963 112 39: SEQUENCE { 964 114 3: OBJECT IDENTIFIER 965 : organizationalUnitName (2 5 4 11) 966 119 32: PrintableString 'Sipit Test Certificate Aut 967 hority' 968 : } 969 : } 970 : } 971 153 9: INTEGER 00 96 A3 84 17 4E EF 8A 4E 972 : } 973 164 13: SEQUENCE { 974 166 9: OBJECT IDENTIFIER 975 : rsaEncryption (1 2 840 113549 1 1 1) 976 177 0: NULL 977 : } 978 179 256: OCTET STRING 979 : 13 04 66 18 17 D5 24 A6 2C 67 91 92 A0 1F FC B6 980 : 22 71 09 E7 C0 D9 B3 FB 0D C0 27 CC E4 E0 A1 FF 981 : FC CC AF B4 81 16 B2 D7 C3 53 78 49 59 DD DD 84 982 : DB BC E4 D5 E0 D9 D0 C0 E5 E1 5E 98 3C 2E 20 7B 983 : BC 3A 00 3B AC 88 71 91 46 F2 94 47 D0 D9 05 F6 984 : 1B F3 EA 79 B7 69 21 97 DD E0 64 5D A8 30 56 BE 985 : BF 40 97 73 58 67 65 BE F6 53 C9 C0 D2 B3 61 07 986 : 97 42 CB 68 37 97 E4 C3 AB 10 09 66 53 E9 72 C7 987 : A4 66 0C 09 06 12 E1 49 67 B9 40 D6 0B BA 52 7D 988 : C3 9E B7 30 51 4B 41 CB 5F AF EC A8 A0 AA 69 FF 989 : 30 06 8B A4 23 E5 F7 05 05 86 F5 CE AD 7B FF BA 990 : 5D 46 4C 2E FE 6D 7C E2 21 7A 75 37 10 7E 0D 4D 991 : 82 9E 44 B1 34 AB D0 59 A8 F8 14 6A BD 3D 65 3E 992 : 6B 37 2E F8 54 7B 47 49 2F 55 7B E8 76 2E BD 8E 993 : 3F 1E D9 86 95 1A 05 EC 1A 62 96 0F 56 95 9B 26 994 : CD E2 8A D6 81 EF 1C 92 D1 F2 81 34 83 8C 3F EF 995 : } 996 : } 997 439 124: SEQUENCE { 998 441 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 999 452 29: SEQUENCE { 1000 454 9: OBJECT IDENTIFIER 1001 : aes128-CBC (2 16 840 1 101 3 4 1 2) 1002 465 16: OCTET STRING 1003 : F9 4F C2 92 49 32 EB A9 E0 A5 AC AB EF 01 5D A5 1004 : } 1005 483 80: [0] 1006 : 95 F0 53 3D 18 09 77 30 D2 AC 2B 1E 0A 51 E9 EB 1007 : E4 32 8B CA 69 8D BA E5 46 63 9C 99 35 20 70 D3 1008 : EE 7A 21 4B C3 E9 53 E5 B0 7D 26 9A 6A 5C 11 6F 1009 : 59 72 B3 91 1E 98 95 F6 69 89 41 E6 22 5B 2F EB 1010 : F5 9C 71 29 BB 1E 01 97 9E 96 EB 39 8A A2 C6 FC 1011 : } 1012 : } 1013 : } 1014 : } 1016 4.3. MESSAGE Request with Encrypted and Signed Body 1018 In the example below, some of the header values have been split 1019 across mutliple lines. Where the lines have been broken, the 1020 convention has been used. This was only done to make it 1021 fit in the RFC format. Specifically, the application/pkcs7-mime 1022 Content-Type line is one line with no whitespace between the "mime;" 1023 and the "smime-type". The values are split across lines for 1024 formatting, but are not split in the real message. The binary 1025 encrypted content has been replaced with "BINARY BLOB 3", and the 1026 binary signed content has been replaced with "BINARY BLOB 4". 1028 MESSAGE sip:kumiko@example.net SIP/2.0 1029 1030 Via: SIP/2.0/TCP 192.0.2.2:15001; 1031 branch=z9hG4bK-d8754z-69c41c074ef38f70-1---d8754z-; 1032 rport=58319 1033 1034 Max-Forwards: 70 1035 To: 1036 From: ;tag=85475653 1037 Call-ID: NmVjYjE0NzNhNjczMDEyZGM3YWM5NmRjYWQxY2JlYTI. 1038 CSeq: 5449 MESSAGE 1039 1040 Accept: multipart/signed, text/plain, application/pkcs7-mime, 1041 application/sdp, multipart/alternative 1042 1043 1044 Content-Type: multipart/signed;boundary=30145b1e6548046b; 1045 micalg=sha1;protocol="application/pkcs7-signature" 1046 1047 Content-Length: 1455 1049 --30145b1e6548046b 1050 1051 Content-Type: application/pkcs7-mime;smime-type=enveloped-data; 1052 name=smime.p7m 1053 1054 1055 Content-Disposition: attachment;handling=required; 1056 filename=smime.p7 1057 1058 Content-Transfer-Encoding: binary 1060 ***************** 1061 * BINARY BLOB 3 * 1062 ***************** 1063 --30145b1e6548046b 1064 Content-Type: application/pkcs7-signature;name=smime.p7s 1065 1066 Content-Disposition: attachment;handling=required; 1067 filename=smime.p7s 1068 1069 Content-Transfer-Encoding: binary 1071 ***************** 1072 * BINARY BLOB 4 * 1073 ***************** 1074 --30145b1e6548046b-- 1075 Below is the ASN.1 parsing of "BINARY BLOB 3". 1077 0 561: SEQUENCE { 1078 4 9: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3) 1079 15 546: [0] { 1080 19 542: SEQUENCE { 1081 23 1: INTEGER 0 1082 26 409: SET { 1083 30 405: SEQUENCE { 1084 34 1: INTEGER 0 1085 37 125: SEQUENCE { 1086 39 112: SEQUENCE { 1087 41 11: SET { 1088 43 9: SEQUENCE { 1089 45 3: OBJECT IDENTIFIER countryName (2 5 4 6) 1090 50 2: PrintableString 'US' 1091 : } 1092 : } 1093 54 19: SET { 1094 56 17: SEQUENCE { 1095 58 3: OBJECT IDENTIFIER 1096 : stateOrProvinceName (2 5 4 8) 1097 63 10: PrintableString 'California' 1098 : } 1099 : } 1100 75 17: SET { 1101 77 15: SEQUENCE { 1102 79 3: OBJECT IDENTIFIER localityName (2 5 4 7) 1103 84 8: PrintableString 'San Jose' 1104 : } 1105 : } 1106 94 14: SET { 1107 96 12: SEQUENCE { 1108 98 3: OBJECT IDENTIFIER 1109 : organizationName (2 5 4 10) 1110 103 5: PrintableString 'sipit' 1111 : } 1112 : } 1113 110 41: SET { 1114 112 39: SEQUENCE { 1115 114 3: OBJECT IDENTIFIER 1116 : organizationalUnitName (2 5 4 11) 1117 119 32: PrintableString 'Sipit Test Certificate Aut 1118 hority' 1119 : } 1120 : } 1121 : } 1122 153 9: INTEGER 00 96 A3 84 17 4E EF 8A 4E 1123 : } 1124 164 13: SEQUENCE { 1125 166 9: OBJECT IDENTIFIER 1126 : rsaEncryption (1 2 840 113549 1 1 1) 1127 177 0: NULL 1128 : } 1129 179 256: OCTET STRING 1130 : 74 D6 C9 2B 48 63 97 2B 56 C2 76 FF 0C D1 C4 EB 1131 : D9 F1 DE 46 F5 0E 37 81 60 F8 03 11 39 99 60 F5 1132 : 9F 20 F8 41 53 96 C7 50 4C FF 6D 99 A0 E8 B6 B8 1133 : AB 97 CD 6F A7 19 58 A9 D0 2C F2 C4 B9 89 29 C0 1134 : 66 F5 FF 80 51 CC 24 75 60 A8 D4 5D B5 4C 6D 2B 1135 : DE C5 A5 A8 A5 FA 7D 21 10 A5 E7 0C 98 67 66 48 1136 : 07 EF DD 8F 68 2A 11 6D 46 4E B6 A1 A0 68 EE 51 1137 : 6D 81 57 E9 27 98 75 B3 E5 08 CC A6 DA 7C 77 D4 1138 : DC 16 78 61 C7 A6 B1 CF 96 36 C9 D8 27 AC 1F D3 1139 : A0 AF 1F B1 65 1B C8 EF BA 9C C8 AD 4B E6 AA FC 1140 : 53 03 8C C2 02 1F BF 20 AE 6F E7 3B 37 6D 98 A3 1141 : 13 D1 F4 A3 F4 9A BE E0 B6 75 F5 B6 5B 86 A0 E1 1142 : F6 8E 93 4B 49 01 62 41 87 7B 12 B1 45 83 C6 61 1143 : 44 A5 E8 D1 CD A6 2B 17 B5 C8 25 D3 9C C2 B8 8B 1144 : 62 16 2C F4 50 72 F6 C3 4F 2B 33 30 59 97 BF 22 1145 : 54 36 23 4F 10 06 61 D0 B6 F8 6F 20 BF 88 08 0B 1146 : } 1147 : } 1148 439 124: SEQUENCE { 1149 441 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 1150 452 29: SEQUENCE { 1151 454 9: OBJECT IDENTIFIER 1152 : aes128-CBC (2 16 840 1 101 3 4 1 2) 1153 465 16: OCTET STRING 1154 : 71 3B EA E0 5D FE D0 5E 6D EA AC 0B B9 6B 3A 99 1155 : } 1156 483 80: [0] 1157 : 41 E7 5A B1 AC F0 A6 BC 9F 52 4F 83 D5 C5 6C 23 1158 : 49 17 20 78 9D C9 73 CB CC 48 8A 61 EB 46 2D D4 1159 : 4A 03 6A 4A 31 E9 F7 52 5B 01 A6 34 38 B9 67 DD 1160 : BD 78 53 59 63 5A 45 2E 02 51 18 B0 F2 43 77 4F 1161 : 89 4E EA 21 E7 FC FF 7C FD 82 41 26 C6 D5 35 29 1162 : } 1163 : } 1164 : } 1165 : } 1167 Below is the ASN.1 parsing of "BINARY BLOB 4". 1169 0 472: SEQUENCE { 1170 4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) 1171 15 457: [0] { 1172 19 453: SEQUENCE { 1173 23 1: INTEGER 1 1174 26 11: SET { 1175 28 9: SEQUENCE { 1176 30 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 1177 37 0: NULL 1178 : } 1179 : } 1180 39 11: SEQUENCE { 1181 41 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 1182 : } 1183 52 420: SET { 1184 56 416: SEQUENCE { 1185 60 1: INTEGER 1 1186 63 125: SEQUENCE { 1187 65 112: SEQUENCE { 1188 67 11: SET { 1189 69 9: SEQUENCE { 1190 71 3: OBJECT IDENTIFIER countryName (2 5 4 6) 1191 76 2: PrintableString 'US' 1192 : } 1193 : } 1194 80 19: SET { 1195 82 17: SEQUENCE { 1196 84 3: OBJECT IDENTIFIER 1197 : stateOrProvinceName (2 5 4 8) 1198 89 10: PrintableString 'California' 1199 : } 1200 : } 1201 101 17: SET { 1202 103 15: SEQUENCE { 1203 105 3: OBJECT IDENTIFIER localityName (2 5 4 7) 1204 110 8: PrintableString 'San Jose' 1205 : } 1206 : } 1207 120 14: SET { 1208 122 12: SEQUENCE { 1209 124 3: OBJECT IDENTIFIER 1210 : organizationName (2 5 4 10) 1211 129 5: PrintableString 'sipit' 1212 : } 1213 : } 1214 136 41: SET { 1215 138 39: SEQUENCE { 1216 140 3: OBJECT IDENTIFIER 1217 : organizationalUnitName (2 5 4 11) 1219 145 32: PrintableString 'Sipit Test Certificate Aut 1220 hority' 1221 : } 1222 : } 1223 : } 1224 179 9: INTEGER 00 96 A3 84 17 4E EF 8A 4D 1225 : } 1226 190 9: SEQUENCE { 1227 192 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 1228 199 0: NULL 1229 : } 1230 201 13: SEQUENCE { 1231 203 9: OBJECT IDENTIFIER 1232 : rsaEncryption (1 2 840 113549 1 1 1) 1233 214 0: NULL 1234 : } 1235 216 256: OCTET STRING 1236 : 7E A7 3D FD 62 05 89 BD 84 04 E7 6C E1 9C 12 90 1237 : D5 23 55 65 54 D8 57 30 60 93 14 8A F0 99 E5 B7 1238 : 81 2B 99 14 4A B0 05 A4 DB 5A FD F2 2B E2 F3 43 1239 : 7E 29 37 F3 08 76 95 1C 43 B0 98 E6 09 81 28 95 1240 : FB DF FD CD AF 70 DA 07 21 67 99 11 C4 B9 D6 01 1241 : 9A 6C CC 58 9F 2D A6 44 D3 72 D3 5C 96 3B E1 E2 1242 : F4 90 31 66 A3 B7 66 1B FD 2E 29 58 1D 18 15 BA 1243 : ED 26 D4 B1 A5 F8 67 F4 34 32 45 EA AB 22 AD B7 1244 : 66 BC 3D 2A 07 1C EF 83 67 94 B3 DE A5 FA F5 51 1245 : FD 8B C5 F0 86 06 C4 ED FB FB E1 32 F3 4B C2 41 1246 : FC 8F FD CD 9E FF 9B 1D 09 8C E4 F9 45 0F 65 DC 1247 : C6 83 A3 96 8E 8B 68 E4 B3 3F 33 EC 1C 06 EB 36 1248 : 21 23 4C 47 AB 2C A1 EB 1A 37 01 78 9E 97 5D A8 1249 : FF 7F B6 B2 33 A8 02 01 E3 C5 ED E8 28 0C 6A D9 1250 : A0 7B EA 47 56 3E 9B 24 9C 14 71 40 8F A4 5C 6A 1251 : 34 47 28 DE C4 6B 7C F1 05 5D 2E 31 29 4C 67 E4 1252 : } 1253 : } 1254 : } 1255 : } 1256 : } 1258 5. Observed Interoperability Issues 1260 This section describes some common interoperability problems. These 1261 were observed by the authors at SIPit interoperability events. 1262 Implementers should be careful to verify that their systems do not 1263 introduce these common problems, and, when possible, make their 1264 clients forgiving in what they receive. Implementations should take 1265 extra care to produce reasonable error messages when interacting with 1266 software that has these problems. 1268 Some SIP clients incorrectly only do SSLv3 and do not support TLS. 1269 See Section 26.2.1 of [RFC3261]. 1271 Many SIP clients were found to accept expired certificates with no 1272 warning or error. See Section 4.1.2.5 of [RFC5280]. 1274 When used with SIP, TLS and S/MIME provide the identity of the peer 1275 that a client is communicating with in the Subject Alternative Name 1276 in the certificate. The software checks that this name corresponds 1277 to the identity the server is trying to contact. Normative text 1278 describing path validation can be found in Section 7 of [RFC5922] and 1279 Section 6 of [RFC5280]. If a client is trying to set up a TLS 1280 connection to good.example.com and it gets a TLS connection set up 1281 with a server that presents a valid certificate but with the name 1282 evil.example.com, it will typically generate an error or warning of 1283 some type. Similarly with S/MIME, if a user is trying to communicate 1284 with sip:fluffy@example.com, one of the items in the Subject 1285 Alternate Name set in the certificate will need to match according to 1286 the certificate validation rules in Section 23 of [RFC3261] and 1287 Section 6 of [RFC5280]. 1289 Some implementations used binary MIME encodings while others used 1290 base64. It is advisable that implementations send only binary and 1291 are prepared to receive either. See Section 3.2 of [RFC5621]. 1293 In several places in this document, the messages contain the encoding 1294 for the SHA-1 digest algorithm identifier. The preferred form for 1295 encoding as set out in Section 2 of [RFC3370] is the form in which 1296 the optional AlgorithmIdentifier parameter field is omitted. 1297 However, [RFC3370] also says the recipients need to be able to 1298 receive the form in which the AlgorithmIdentifier parameter field is 1299 present and set to NULL. Examples of the form using NULL can be 1300 found in Section 4.2 of [RFC4134]. Receivers really do need to be 1301 able to receive the form that includes the NULL because the NULL 1302 form, while not preferred, is what was observed as being generated by 1303 most implementations. Implementers should also note that if the 1304 algorithm is MD5 instead of SHA-1, then the form that omits the 1305 AlgorithmIdentifier parameters field is not allowed and the sender 1306 has to use the form where the NULL is included. 1308 The preferred encryption algorithm for S/MIME in SIP is AES as 1309 defined in [RFC3853]. 1311 Observed S/MIME interoperability has been better when UAs did not 1312 attach the senders' certificates. Attaching the certificates 1313 significantly increases the size of the messages, which should be 1314 considered when sending over UDP. Furthermore, the receiver cannot 1315 rely on the sender to always send the certificate, so it does not 1316 turn out to be useful in most situations. 1318 Please note that the certificate path validation algorithm described 1319 in Section 6 of [RFC5280] is a complex algorithm for which all of the 1320 details matter. There are numerous ways in which failing to 1321 precisely implement the algorithm as specified in Section 6 of 1322 [RFC5280] can create a security flaw, a simple example of which is 1323 the failure to check the expiration date that is already mentioned 1324 above. It is important for developers to ensure that this validation 1325 is performed and that the results are verified by their applications 1326 or any libraries that they use. 1328 6. Additional Test Scenarios 1330 This section provides a non-exhaustive list of tests that 1331 implementations should perform while developing systems that use 1332 S/MIME and TLS for SIP. 1334 Much of the required behavior for inspecting certificates when using 1335 S/MIME and TLS with SIP is currently underspecified. The non- 1336 normative recommendations in this document capture the current 1337 folklore around that required behavior, guided by both related 1338 normative works such as [RFC4474] (particulary, Section 13.4 Domain 1339 Names and Subordination) and informative works such as [RFC2818] 1340 Section 3.1. To summarize, test plans should: 1342 o For S/MIME secured bodies, assure that the peer's URI (address-of- 1343 record, as per [RFC3261] Section 23.3) appears in the 1344 subjectAltName of the peer's certifcate as a 1345 uniformResourceIdentifier field. 1347 o For TLS, assure that the peer's hostname appears as described in 1348 [RFC5922]. Also: 1350 * assure an exact match in a dNSName entry in the subjectAltName 1351 if there are any dNSNames in the subjectAltName. Wildcard 1352 matching is not allowed against these dNSName entries. See 1353 Section 7.1 of [RFC5922]. 1355 * assure that the most specific CommonName in the Subject field 1356 matches if there are no dNSName entries in the subjectAltName 1357 at all (which is not the same as there being no matching 1358 dNSName entries). This match can be either exact, or against 1359 an entry that uses the wildcard matching character '*' 1361 The peer's hostname is discovered from the initial DNS query in 1362 the server location process [RFC3263]. 1364 o IP addresses can appear in subjectAltName ([RFC5280]) of the 1365 peer's certificate, e.g. "IP:192.168.0.1". Note that if IP 1366 addresses are used in subjectAltName, there are important 1367 ramifications regarding the use of Record-Route headers that also 1368 need to be considered. See Section 7.5 of [RFC5922]. Use of IP 1369 addresses instead of domain names is inadvisable. 1371 For each of these tests, an implementation will proceed past the 1372 verification point only if the certificate is "good". S/MIME 1373 protected requests presenting bad certificate data will be rejected. 1374 S/MIME protected responses presenting bad certificate information 1375 will be ignored. TLS connections involving bad certificate data will 1376 not be completed. 1378 1. S/MIME : Good peer certificate 1380 2. S/MIME : Bad peer certificate (peer URI does not appear in 1381 subjAltName) 1383 3. S/MIME : Bad peer certificate (valid authority chain does not 1384 end at a trusted CA) 1386 4. S/MIME : Bad peer certificate (incomplete authority chain) 1388 5. S/MIME : Bad peer certificate (the current time does not fall 1389 within the period of validity) 1391 6. S/MIME : Bad peer certificate (certificate or cert in authority 1392 chain has been revoked) 1394 7. S/MIME : Bad peer certificate ("Digital Signature" is not 1395 specified as an X509v3 Key Usage) 1397 8. TLS : Good peer certificate (hostname appears in dNSName in 1398 subjAltName) 1400 9. TLS : Good peer certificate (no dNSNames in subjAltName, 1401 hostname appears in CN of Subject) 1403 10. TLS : Good peer certificate (CN of Subject empty, and 1404 subjectAltName extension contains an iPAddress stored in the 1405 octet string in network byte order form as specified in RFC 791 1406 [RFC0791]) 1408 11. TLS : Bad peer certificate (no match in dNSNames or in the 1409 Subject CN) 1411 12. TLS : Bad peer certificate (valid authority chain does not end 1412 at a trusted CA) 1414 13. TLS : Bad peer certificate (incomplete authority chain) 1416 14. TLS : Bad peer certificate (the current time does not fall 1417 within the period of validity) 1419 15. TLS : Bad peer certificate (certificate or cert in authority 1420 chain has been revoked) 1422 16. TLS : Bad peer certificate ("TLS Web Server Authentication" is 1423 not specified as an X509v3 Key Usage) 1425 17. TLS : Bad peer certificate (Neither "SIP Domain" nor "Any 1426 Extended Key Usage" specified as an X509v3 Extended Key Usage, 1427 and X509v3 Extended Key Usage is present) 1429 7. IANA Considerations 1431 No IANA actions are required. 1433 8. Acknowledgments 1435 Many thanks to the developers of all the open source software used to 1436 create these call flows. This includes the underlying crypto and TLS 1437 software used from openssl.org, the SIP stack from 1438 www.resiprocate.org, and the SIMPLE IMPP agent from www.sipimp.org. 1439 The TLS flow dumps were done with SSLDump from 1440 http://www.rtfm.com/ssldump. The book "SSL and TLS" [EKR-TLS] was a 1441 huge help in developing the code for these flows. It's sad there is 1442 no second edition. 1444 Thanks to Jim Schaad, Russ Housley, Eric Rescorla, Dan Wing, Tat 1445 Chan, and Lyndsay Campbell who all helped find and correct mistakes 1446 in this document. 1448 Vijay Gurbani and Alan Jeffrey contributed much of the additional 1449 test scenario content. 1451 9. Security Considerations 1453 Implementers must never use any of the certificates provided in this 1454 document in anything but a test environment. Installing the CA root 1455 certificates used in this document as a trusted root in operational 1456 software would completely destroy the security of the system while 1457 giving the user the impression that the system was operating 1458 securely. 1460 This document recommends some things that implementers might test or 1461 verify to improve the security of their implementations. It is 1462 impossible to make a comprehensive list of these, and this document 1463 only suggests some of the most common mistakes that have been seen at 1464 the SIPit interoperability events. Just because an implementation 1465 does everything this document recommends does not make it secure. 1467 This document does not show any messages to check certificate 1468 revocation status (see Sections 3.3 and 6.3 of [RFC5280]) as that is 1469 not part of the SIP call flow. The expectation is that revocation 1470 status is checked regularly to protect against the possibility of 1471 certificate compromise or repudiation. For more information on how 1472 certificate revocation status can be checked, see [RFC2560] (Online 1473 Certificate Status Protocol) and [RFC5055] (Server-Based Certificate 1474 Validation Protocol). 1476 10. Changelog 1478 (RFC Editor: remove this section) 1480 -02 to -03 1482 * Re-worded "should" and "must" so that the document doesn't 1483 sound like it is making normative statements. Actual normative 1484 behavior is referred to in the respective RFCs. 1486 * Section 5: re-worded paragraphs 4 and 5 regarding 1487 subjectAltName, and added references. 1489 * Section 6: added references, clarified use of IP addresses, and 1490 clarified which From/To URI is used for comparison (from 1491 section 23.2). Added an EKU test case. 1493 * Section 9: added text about certificate revocation checking. 1495 * Appendix B.3: new section to present certificate chains longer 1496 than 2 (non-root CA). 1498 * Made examples consistently use convention. 1500 * CSeq looks more random. 1502 * Serial numbers in certs are non-zero. 1504 * All flows re-generated using new certs. IP addresses conform 1505 to RFC 5737. 1507 * Updated references. 1509 -01 to -02 1511 * Draft is now informational, not standards track. Normative- 1512 sounding language and references to RFC 2119 removed. 1514 * Add TODO: change "hello" to "Hello!" in example flows for 1515 consistency. 1517 * Add TODO: Fix subjectAltName DNS:com to DNS:example.com and 1518 DNS:net to DNS:example.net. 1520 * Add TODO: use allOneLine convention from RFC4475. 1522 * Section 3: updated open issue regarding contact headers in 1523 MESSAGE. 1525 * Section 3.2: added some text about RFC 3263 and connection 1526 reuse and closed open issue. 1528 * Section 5: clarified text about sender attaching certs, closed 1529 issue. 1531 * Section 5: clarified text about observed problems, closed 1532 issue. 1534 * Section 5: closed issue about clients vs. servers vs. proxies. 1536 * Section 6: updated section text and open issue where IP address 1537 is in subjectAltName. 1539 * Section 6: added normative references and closed "folklore" 1540 issue. 1542 * Section 6: added cases about cert usage and broken chains, 1543 updated OPEN ISSUE: we need a SIP EKU example. 1545 * References: updated references to drafts and re-categorized 1546 informative vs. normative. 1548 * Section 9: added some text about revocation status and closed 1549 issue. 1551 * Appendix B: open issue: do we need non-root-CA certs and host 1552 certs signed by them for help in testing cases in Section 6? 1554 * Miscellaneous minor editorial changes. 1556 -00 to -01 1558 * Addition of OPEN ISSUES. 1560 * Numerous minor edits from mailing list feedback. 1562 to -00 1564 * Changed RFC 3369 references to RFC 3852. 1566 * Changed draft-ietf-sip-identity references to RFC 4474. 1568 * Added an ASN.1 dump of CMS signed content where SHA-1 1569 parameters are omitted instead of being set to ASN.1 NULL. 1571 * Accept headers added to messages. 1573 * User and domain certificates are generated with EKU as 1574 specified in Draft SIP EKU. 1576 * Message content that is shown is computed using certificates 1577 generated with EKU. 1579 * Message dump archive returned. 1581 * Message archive contains messages formed with and without EKU 1582 certificates. 1584 prior to -00 1586 * Incorporated the Test cases from Vijay Gurbani's and Alan 1587 Jeffrey's Use of TLS in SIP draft 1589 * Began to capture the folklore around where identities are 1590 carried in certificates for use with SIP 1592 * Removed the message dump archive pending verification (will 1593 return in -02) 1595 11. References 1597 11.1. Normative References 1599 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1600 September 1981. 1602 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1603 Adams, "X.509 Internet Public Key Infrastructure Online 1604 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 1606 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1607 A., Peterson, J., Sparks, R., Handley, M., and E. 1608 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1609 June 2002. 1611 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1612 Protocol (SIP): Locating SIP Servers", RFC 3263, 1613 June 2002. 1615 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 1616 Algorithms", RFC 3370, August 2002. 1618 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 1619 and D. Gurle, "Session Initiation Protocol (SIP) Extension 1620 for Instant Messaging", RFC 3428, December 2002. 1622 [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) 1623 Requirement for the Session Initiation Protocol (SIP)", 1624 RFC 3853, July 2004. 1626 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1627 Authenticated Identity Management in the Session 1628 Initiation Protocol (SIP)", RFC 4474, August 2006. 1630 [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. 1631 Polk, "Server-Based Certificate Validation Protocol 1632 (SCVP)", RFC 5055, December 2007. 1634 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1635 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1637 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1638 Housley, R., and W. Polk, "Internet X.509 Public Key 1639 Infrastructure Certificate and Certificate Revocation List 1640 (CRL) Profile", RFC 5280, May 2008. 1642 [RFC5621] Camarillo, G., "Message Body Handling in the Session 1643 Initiation Protocol (SIP)", RFC 5621, September 2009. 1645 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1646 RFC 5652, September 2009. 1648 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1649 Mail Extensions (S/MIME) Version 3.2 Message 1650 Specification", RFC 5751, January 2010. 1652 [RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain 1653 Certificates in the Session Initiation Protocol (SIP)", 1654 RFC 5922, June 2010. 1656 [RFC5923] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in 1657 the Session Initiation Protocol (SIP)", RFC 5923, 1658 June 2010. 1660 [RFC5924] Lawrence, S. and V. Gurbani, "Extended Key Usage (EKU) for 1661 Session Initiation Protocol (SIP) X.509 Certificates", 1662 RFC 5924, June 2010. 1664 [X.509] International Telecommunications Union, "Information 1665 technology - Open Systems Interconnection - The Directory: 1666 Public-key and attribute certificate frameworks", ITU- 1667 T Recommendation X.509 (2005), ISO/IEC 9594-8:2005. 1669 [X.683] International Telecommunications Union, "Information 1670 technology - Abstract Syntax Notation One (ASN.1): 1671 Parameterization of ASN.1 specifications", ITU- 1672 T Recommendation X.683 (2002), ISO/IEC 8824-4:2002, 2002. 1674 11.2. Informative References 1676 [EKR-TLS] Rescorla, E., "SSL and TLS - Designing and Building Secure 1677 Systems", 2001. 1679 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1681 [RFC4134] Hoffman, P., "Examples of S/MIME Messages", RFC 4134, 1682 July 2005. 1684 [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., 1685 and H. Schulzrinne, "Session Initiation Protocol (SIP) 1686 Torture Test Messages", RFC 4475, May 2006. 1688 [ssldump-manpage] 1689 Rescorla, E., "SSLDump manpage". 1691 Appendix A. Making Test Certificates 1693 These scripts allow you to make certificates for test purposes. The 1694 certificates will all share a common CA root so that everyone running 1695 these scripts can have interoperable certificates. WARNING - these 1696 certificates are totally insecure and are for test purposes only. 1697 All the CA created by this script share the same private key to 1698 facilitate interoperability testing, but this totally breaks the 1699 security since the private key of the CA is well known. 1701 The instructions assume a Unix-like environment with openssl 1702 installed, but openssl does work in Windows too. OpenSSL version 1703 0.9.8j was used to generate the certificates used in this document. 1704 Make sure you have openssl installed by trying to run "openssl". Run 1705 the makeCA script found in Appendix A.1; this creates a subdirectory 1706 called demoCA. If the makeCA script cannot find where your openssl 1707 is installed you will have to set an environment variable called 1708 OPENSSLDIR to whatever directory contains the file openssl.cnf. You 1709 can find this with a "locate openssl.cnf". You are now ready to make 1710 certificates. 1712 To create certs for use with TLS, run the makeCert script found in 1713 Appendix A.2 with the fully qualified domain name of the proxy you 1714 are making the certificate for. For example, "makeCert 1715 host.example.net". This will generate a private key and a 1716 certificate. The private key will be left in a file named 1717 domain_key_example.net.pem in pem format. The certificate will be in 1718 domain_cert_example.net.pem. Some programs expect both the 1719 certificate and private key combined together in a PKCS12 format 1720 file. This is created by the script and left in a file named 1721 example.net.p12. Some programs expect this file to have a .pfx 1722 extension instead of .p12 - just rename the file if needed. A file 1723 with a certificate signing request, called example.net.csr, is also 1724 created and can be used to get the certificate signed by another CA. 1726 A second argument indicating the number of days for which the 1727 certificate should be valid can be passed to the makeCert script. It 1728 is possible to make an expired certificate using the command 1729 "makeCert host.example.net 0". 1731 Anywhere that a password is used to protect a certificate, the 1732 password is set to the string "password". 1734 The root certificate for the CA is in the file 1735 root_cert_fluffyCA.pem. 1737 For things that need DER format certificates, a certificate can be 1738 converted from PEM to DER with "openssl x509 -in cert.pem -inform PEM 1739 -out cert.der -outform DER". 1741 Some programs expect certificates in PKCS#7 format (with a file 1742 extension of .p7c). You can convert these from PEM format to PKCS#7 1743 with "openssl crl2pkcs7 -nocrl -certfile cert.pem -certfile demoCA/ 1744 cacert.pem -outform DER -out cert.p7c" 1746 IE (version 8), Outlook Express (version 6), and Firefox (version 1747 3.5) can import and export .p12 files and .p7c files. You can 1748 convert a pkcs7 certificate to PEM format with "openssl pkcs7 -in 1749 cert.p7c -inform DER -outform PEM -out cert.pem". 1751 The private key can be converted to pkcs8 format with "openssl pkcs8 1752 -in a_key.pem -topk8 -outform DER -out a_key.p8c" 1754 In general, a TLS client will just need the root certificate of the 1755 CA. A TLS server will need its private key and its certificate. 1756 These could be in two PEM files, a single file with both certificate 1757 and private key PEM sections, or a single .p12 file. An S/MIME 1758 program will need its private key and certificate, the root 1759 certificate of the CA, and the certificate for every other user it 1760 communicates with. 1762 A.1. makeCA script 1764 #!/bin/sh 1765 set -x 1767 rm -rf demoCA 1769 mkdir demoCA 1770 mkdir demoCA/certs 1771 mkdir demoCA/crl 1772 mkdir demoCA/newcerts 1773 mkdir demoCA/private 1774 # This is done to generate the exact serial number used for the RFC 1775 echo "4902110184015C" > demoCA/serial 1776 touch demoCA/index.txt 1778 # You may need to modify this for where your default file is 1779 # you can find where yours in by typing "openssl ca" 1780 for D in /etc/ssl /usr/local/ssl /sw/etc/ssl /sw/share/ssl; do 1781 CONF=${OPENSSLDIR:=$D}/openssl.cnf 1782 [ -f ${CONF} ] && break 1783 done 1785 CONF=${OPENSSLDIR}/openssl.cnf 1786 if [ ! -f $CONF ]; then 1787 echo "Can not find file $CONF - set your OPENSSLDIR variable" 1788 exit 1789 fi 1790 cp $CONF openssl.cnf 1792 cat >> openssl.cnf < demoCA/private/cakey.pem < demoCA/cacert.pem < demoCA/serial 1923 echo 96a384174eef8a4d > demoCA/serial 1924 openssl crl2pkcs7 -nocrl -certfile demoCA/cacert.pem \ 1925 -outform DER -out demoCA/cacert.p7c 1927 cp demoCA/cacert.pem root_cert_fluffyCA.pem 1929 A.2. makeCert script 1931 #!/bin/sh 1932 set -x 1934 # Make a symbolic link to this file called "makeUserCert" 1935 # if you wish to use it to make certs for users. 1937 # ExecName=$(basename $0) 1938 # 1939 # if [ ${ExecName} == "makeUserCert" ]; then 1940 # ExtPrefix="sipuser" 1941 # elif [ ${ExecName} == "makeEkuUserCert" ]; then 1942 # ExtPrefix="sipuser_eku" 1943 # elif [ ${ExecName} == "makeEkuCert" ]; then 1944 # ExtPrefix="sipdomain_eku" 1945 # else 1946 # ExtPrefix="sipdomain" 1947 # fi 1949 if [ $# == 3 ]; then 1950 DAYS=36500 1951 elif [ $# == 4 ]; then 1952 DAYS=$4 1953 else 1954 echo "Usage: makeCert test.example.org user|domain eku|noeku [days]" 1955 echo " makeCert alice@example.org [days]" 1956 echo "days is how long the certificate is valid" 1957 echo "days set to 0 generates an invalid certificate" 1958 exit 0 1959 fi 1961 ExtPrefix="sip"${2} 1963 if [ $3 == "noeku" ]; then 1964 ExtPrefix=${ExtPrefix}"_noeku" 1965 fi 1966 DOMAIN=`echo $1 | perl -ne '{print "$1\n" if (/(\w+\..*)$/)}' ` 1967 ADDR=$1 1968 echo "making cert for $DOMAIN ${ADDR}" 1970 rm -f ${ADDR}_*.pem 1971 rm -f ${ADDR}.p12 1973 case ${ADDR} in 1974 *:*) ALTNAME="URI:${ADDR}" ;; 1975 *@*) ALTNAME="URI:sip:${ADDR},URI:im:${ADDR},URI:pres:${ADDR}" ;; 1976 *) ALTNAME="DNS:${DOMAIN},URI:sip:${ADDR}" ;; 1977 esac 1979 rm -f demoCA/index.txt 1980 touch demoCA/index.txt 1981 rm -f demoCA/newcerts/* 1983 export ALTNAME 1985 openssl genrsa -out ${ADDR}_key.pem 2048 1986 openssl req -new -config openssl.cnf -reqexts ${ExtPrefix}_req \ 1987 -sha1 -key ${ADDR}_key.pem \ 1988 -out ${ADDR}.csr -days ${DAYS} <