| Network Working Group | C. Jennings |
| INTERNET DRAFT | Cisco Systems |
| <draft-jennings-sip-sec-flows-02> | K. Ono |
| Category: Standards Track | NTT Corporation |
| Expires: August 2005 | February 2005 |
Example call flows using SIP security mechanisms
draft-jennings-sip-sec-flows-02
By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668.
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 in August 2005.
Copyright (C) The Internet Society (2005). All Rights Reserved.
This document shows call flows demonstrating the use of SIPS, TLS, and S/MIME in SIP. This draft provides information that helps implementers build interoperable SIP software. It is purely informational. To help facilitate interoperability testing, it includes certificates used in the example call flows and a CA certificate to create certificates for testing.
This work is being discussed on the sip@ietf.org mailing list.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1].
1
Introduction
2
Security Considerations
3
Certificates
3.1
CA Certificates
3.2
Host Certificate
3.3
User Certificates
4
Callflow with Message Over TLS
4.1
TLS with Server Authentication
4.2
MESSAGE Message Over TLS
5
Callflow with S/MIME-secured Message
5.1
MESSAGE Message with Signed Body
5.2
MESSAGE Message with Encrypted Body
5.3
MESSAGE Message with Encrypted and Signed Body
6
Test Notes
7
Open Issues
8
IANA Considerations
9
Acknowledgments
10
References
10.1
Normative References
10.2
Informative References
§
Author's Addresses
A
Making Test Certificates
A.1
makeCA script
A.2
makeCert script
B
Certificates for Testing
§
Intellectual Property and Copyright Statements
Several different groups are starting to implement the S/MIME[7] portion of SIP[2]. Over the last several interoperability events, it has become 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 hampered by trying to get certificates signed by some common test root into the appropriate format for various clients. This document addresses both of these issues by providing detailed 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 that can be used for a CA to reduce the time it takes to set up a test at an interoperability event. The document also provides some hints and clarifications for implementers.
A simple SIP call flow using SIPS and TLS is shown in Section 4. The certificates for the hosts used are shown in Section 3.2 and the CA certificates used to sign these are shown in Section 3.1.
The text from Section 5.1 through Section 5.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 3.3. These host certificates are signed with the same CA certificate.
Section 6 presents a partial list of things implementers should check that they do in order to implement a secure system.
A way to make certificates that can be used for interoperability testing is presented in Appendix A, along with methods for converting these to various formats.
The S/MIME messages shown in this document were made using client implementations from the authors' respective companies. These implementations are different code bases and though there may still be errors in these flows, the authors feel that the interoperability of these two clients bodes well for the correctness of the flows in this document.
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.
The S/MIME examples use 3DES, but AES is preferred.
The certificate used by the CA to sign the other certificates is shown below. This is a X509v3 certificate. Note that the basic constraints allow it to be used as a CA.
Version: 3 (0x2)
Serial Number: 0 (0x0)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=California, L=San Jose, O=sipit,
OU=Sipit Test Certificate Authority
Validity
Not Before: Jul 18 12:21:52 2003 GMT
Not After : Jul 15 12:21:52 2013 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:c3:22:1e:83:91:c5:03:2c:3c:8a:f4:11:14:c6:
4b:9d:fa:72:78:c6:b0:95:18:a7:e0:8c:79:ba:5d:
a4:ae:1e:21:2d:9d:f1:0b:1c:cf:bd:5b:29:b3:90:
13:73:66:92:6e:df:4c:b3:b3:1c:1f:2a:82:0a:ba:
07:4d:52:b0:f8:37:7b:e2:0a:27:30:70:dd:f9:2e:
03:ff:2a:76:cd:df:87:1a:bd:71:eb:e1:99:6a:c4:
7f:8e:74:a0:77:85:04:e9:41:ad:fc:03:b6:17:75:
aa:33:ea:0a:16:d9:fb:79:32:2e:f8:cf:4d:c6:34:
a3:ff:1b:d0:68:28:e1:9d:e5
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
6B:46:17:14:EA:94:76:25:80:54:6E:13:54:DA:A1:E3:54:14:A1:B6
X509v3 Authority Key Identifier:
6B:46:17:14:EA:94:76:25:80:54:6E:13:54:DA:A1:E3:54:14:A1:B6
DirName:/C=US/ST=California/L=San Jose/O=sipit/
OU=Sipit Test Certificate Authority
serial:00
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha1WithRSAEncryption
96:6d:1b:ef:d5:91:93:45:7c:5b:1f:cf:c4:aa:47:52:0b:34:
a8:50:fa:ec:fa:b4:2a:47:4c:5d:41:a7:3d:c0:d6:3f:9e:56:
5b:91:1d:ce:a8:07:b3:1b:a4:9f:9a:49:6f:7f:e0:ce:83:94:
71:42:af:fe:63:a2:34:dc:b4:5e:a5:ce:ca:79:50:e9:6a:99:
4c:14:69:e9:7c:ab:22:6c:44:cc:8a:9c:33:6b:23:50:42:05:
1f:e1:c2:81:88:5f:ba:e5:47:bb:85:9b:83:25:ad:84:32:ff:
2a:5b:8b:70:12:11:83:61:c9:69:15:4f:58:a3:3c:92:d4:e8:
6f:52
The ASN.1 parse of the CA certificate is shown below.
0:l= 804 cons: SEQUENCE
4:l= 653 cons: SEQUENCE
8:l= 3 cons: cont [ 0 ]
10:l= 1 prim: INTEGER :02
13:l= 1 prim: INTEGER :00
16:l= 13 cons: SEQUENCE
18:l= 9 prim: OBJECT :sha1WithRSAEncryption
29:l= 0 prim: NULL
31:l= 112 cons: SEQUENCE
33:l= 11 cons: SET
35:l= 9 cons: SEQUENCE
37:l= 3 prim: OBJECT :countryName
42:l= 2 prim: PRINTABLESTRING :US
46:l= 19 cons: SET
48:l= 17 cons: SEQUENCE
50:l= 3 prim: OBJECT :stateOrProvinceName
55:l= 10 prim: PRINTABLESTRING :California
67:l= 17 cons: SET
69:l= 15 cons: SEQUENCE
71:l= 3 prim: OBJECT :localityName
76:l= 8 prim: PRINTABLESTRING :San Jose
86:l= 14 cons: SET
88:l= 12 cons: SEQUENCE
90:l= 3 prim: OBJECT :organizationName
95:l= 5 prim: PRINTABLESTRING :sipit
102:l= 41 cons: SET
104:l= 39 cons: SEQUENCE
106:l= 3 prim: OBJECT :organizationalUnitName
111:l= 32 prim: PRINTABLESTRING :
Sipit Test Certificate Authority
145:l= 30 cons: SEQUENCE
147:l= 13 prim: UTCTIME :030718122152Z
162:l= 13 prim: UTCTIME :130715122152Z
177:l= 112 cons: SEQUENCE
179:l= 11 cons: SET
181:l= 9 cons: SEQUENCE
183:l= 3 prim: OBJECT :countryName
188:l= 2 prim: PRINTABLESTRING :US
192:l= 19 cons: SET
194:l= 17 cons: SEQUENCE
196:l= 3 prim: OBJECT :stateOrProvinceName
201:l= 10 prim: PRINTABLESTRING :California
213:l= 17 cons: SET
215:l= 15 cons: SEQUENCE
217:l= 3 prim: OBJECT :localityName
222:l= 8 prim: PRINTABLESTRING :San Jose
232:l= 14 cons: SET
234:l= 12 cons: SEQUENCE
236:l= 3 prim: OBJECT :organizationName
241:l= 5 prim: PRINTABLESTRING :sipit
248:l= 41 cons: SET
250:l= 39 cons: SEQUENCE
252:l= 3 prim: OBJECT :organizationalUnitName
257:l= 32 prim: PRINTABLESTRING :
Sipit Test Certificate Authority
291:l= 159 cons: SEQUENCE
294:l= 13 cons: SEQUENCE
296:l= 9 prim: OBJECT :rsaEncryption
307:l= 0 prim: NULL
309:l= 141 prim: BIT STRING
00 30 81 89 02 81 81 00-c3 22 1e 83 91 c5 03 2c .0.......".....,
3c 8a f4 11 14 c6 4b 9d-fa 72 78 c6 b0 95 18 a7 <.....K..rx.....
e0 8c 79 ba 5d a4 ae 1e-21 2d 9d f1 0b 1c cf bd ..y.]...!-......
5b 29 b3 90 13 73 66 92-6e df 4c b3 b3 1c 1f 2a [)...sf.n.L....*
82 0a ba 07 4d 52 b0 f8-37 7b e2 0a 27 30 70 dd ....MR..7{..'0p.
f9 2e 03 ff 2a 76 cd df-87 1a bd 71 eb e1 99 6a ....*v.....q...j
c4 7f 8e 74 a0 77 85 04-e9 41 ad fc 03 b6 17 75 ...t.w...A.....u
aa 33 ea 0a 16 d9 fb 79-32 2e f8 cf 4d c6 34 a3 .3.....y2...M.4.
ff 1b d0 68 28 e1 9d e5-02 03 01 00 01 ...h(........
453:l= 205 cons: cont [ 3 ]
456:l= 202 cons: SEQUENCE
459:l= 29 cons: SEQUENCE
461:l= 3 prim: OBJECT :X509v3 Subject Key Identifier
466:l= 22 prim: OCTET STRING
04 14 6b 46 17 14 ea 94-76 25 80 54 6e 13 54 da ..kF....v%.Tn.T.
a1 e3 54 14 a1 b6 ..T...
490:l= 154 cons: SEQUENCE
493:l= 3 prim: OBJECT :X509v3 Authority Key Identifier
498:l= 146 prim: OCTET STRING
30 81 8f 80 14 6b 46 17-14 ea 94 76 25 80 54 6e 0....kF....v%.Tn
13 54 da a1 e3 54 14 a1-b6 a1 74 a4 72 30 70 31 .T...T....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.
01 .
0092 - <SPACES/NULS>
647:l= 12 cons: SEQUENCE
649:l= 3 prim: OBJECT :X509v3 Basic Constraints
654:l= 5 prim: OCTET STRING
30 03 01 01 ff 0....
661:l= 13 cons: SEQUENCE
663:l= 9 prim: OBJECT :sha1WithRSAEncryption
674:l= 0 prim: NULL
676:l= 129 prim: BIT STRING
00 96 6d 1b ef d5 91 93-45 7c 5b 1f cf c4 aa 47 ..m.....E|[....G
52 0b 34 a8 50 fa ec fa-b4 2a 47 4c 5d 41 a7 3d R.4.P....*GL]A.=
c0 d6 3f 9e 56 5b 91 1d-ce a8 07 b3 1b a4 9f 9a ..?.V[..........
49 6f 7f e0 ce 83 94 71-42 af fe 63 a2 34 dc b4 Io.....qB..c.4..
5e a5 ce ca 79 50 e9 6a-99 4c 14 69 e9 7c ab 22 ^...yP.j.L.i.|."
6c 44 cc 8a 9c 33 6b 23-50 42 05 1f e1 c2 81 88 lD...3k#PB......
5f ba e5 47 bb 85 9b 83-25 ad 84 32 ff 2a 5b 8b _..G....%..2.*[.
70 12 11 83 61 c9 69 15-4f 58 a3 3c 92 d4 e8 6f p...a.i.OX.<...o
52 R
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.
Data:
Version: 3 (0x2)
Serial Number:
01:95:00:71:02:33:00:55
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=California, L=San Jose, O=sipit,
OU=Sipit Test Certificate Authority
Validity
Not Before: Feb 3 18:49:08 2005 GMT
Not After : Feb 3 18:49:08 2008 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: (1024 bit)
Modulus (1024 bit):
00:e6:31:76:b5:27:cc:8d:32:85:56:70:f7:c2:33:
33:32:26:42:5e:3c:68:71:7b:1f:79:50:d0:72:27:
3b:4a:af:f2:ce:d1:0c:bc:c0:5f:31:6a:43:e7:7c:
ad:64:bd:c7:e6:25:9f:aa:cd:2d:90:aa:68:84:62:
7b:05:be:43:a5:af:bb:ea:9d:a9:5b:a4:53:9d:22:
8b:da:96:2e:1f:3f:92:46:b8:cc:c8:24:3c:46:cd:
5d:2d:64:85:b1:a4:ca:01:f1:8e:c5:7e:0f:ff:00:
91:a3:ea:cb:3e:12:02:75:a4:bb:08:c8:d0:2a:ef:
b3:bb:72:7a:98:e5:ff:9f:81
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:example.com
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
22:EA:CB:38:66:1D:F1:96:0C:9A:47:B6:BB:1C:52:
44:B0:77:65:8D
Signature Algorithm: sha1WithRSAEncryption
ae:eb:49:ed:1e:f1:8d:26:a9:6d:03:82:92:d5:df:44:c4:1e:
1f:07:75:88:37:e4:76:97:35:12:59:98:79:78:16:6e:3b:b1:
c0:2b:db:85:02:6b:74:c9:5b:19:92:da:7e:f5:41:0b:bc:d2:
dd:45:aa:6f:be:24:dc:48:57:66:d9:2e:82:df:9e:8d:70:03:
73:75:ef:8f:7a:56:4c:cc:42:bd:31:45:b0:5e:ff:d1:3b:c4:
82:ee:fd:a7:c1:10:34:eb:81:49:1a:6b:86:7e:c7:61:1d:b3:
b9:0a:02:bd:84:f8:47:af:cf:f1:a8:73:a8:31:1d:20:7a:06:
7f:ac
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 CPIM gateway. In this example, example.com is the domain for fluffy, the message could be coming from a host called example.com, and the AOR in the user certificate would still be the same. The others are shown in Appendix B.
Data:
Version: 3 (0x2)
Serial Number:
01:95:00:71:02:33:00:58
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=California, L=San Jose, O=sipit,
OU=Sipit Test Certificate Authority
Validity
Not Before: Feb 3 18:49:34 2005 GMT
Not After : Feb 3 18:49:34 2008 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: (1024 bit)
Modulus (1024 bit):
00:ca:ab:9b:9b:4e:3c:d5:45:3c:ce:00:a6:36:a8:
b9:ec:d2:76:e2:b9:9b:e8:28:aa:ba:86:22:c5:cf:
33:3e:4f:6d:56:21:ae:bd:54:84:7c:14:14:f9:7d:
99:85:00:4e:93:d6:fd:6b:d4:d1:d4:55:8e:c9:89:
b1:af:2b:5f:23:99:4a:95:e5:68:65:64:1d:12:a7:
db:d3:d5:97:18:47:35:9c:e6:88:27:9d:a8:6c:ca:
2a:84:e6:62:d8:f1:e9:a2:1a:39:7e:0e:0f:90:a5:
a6:79:21:bc:2a:67:b4:dd:69:90:82:9a:ae:1f:02:
52:8a:58:d3:f5:d0:d4:66:67
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:
EC:DA:98:5E:E9:F7:F7:D7:EC:2B:29:4B:DA:25:EE:C7:C7:
7E:95:70
Signature Algorithm: sha1WithRSAEncryption
4c:46:49:6e:01:48:e2:d4:6e:d7:48:a1:f3:7b:c8:a5:98:37:
a5:44:46:58:9f:4a:37:7d:90:fb:5f:ff:36:bd:67:31:f0:29:
de:0a:e2:ea:b9:f0:5c:9f:ad:a0:de:e5:4e:42:8f:11:d8:41:
ea:68:be:db:c2:1e:fa:e5:8a:2d:7f:66:13:29:e9:da:8f:fb:
80:bf:7e:5e:b6:04:ad:08:5e:58:95:b7:c5:38:85:d5:65:31:
ad:80:cb:28:a7:4c:ad:11:fd:41:3b:37:77:5a:de:85:96:3d:
66:eb:5f:9a:f8:60:5f:8e:b1:fc:4a:43:53:b6:11:4d:2e:f4:
3d:ff
The flow below shows the edited SSLDump output of the host example.com forming a TLS connection to example.net. In this example mutual authentication is not used. Note that the client proposed three protocol suites including the required TLS_RSA_WITH_AES_128_CBC_SHA. 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 [11].
New TCP connection #1: 127.0.0.1(55768) <-> 127.0.0.1(5061)
1 1 0.0060 (0.0060) C>SV3.1(49) Handshake
ClientHello
Version 3.1
random[32]=
42 16 8c c7 82 cd c5 87 42 ba f5 1c 91 04 fb 7d
4d 6c 56 f1 db 1d ce 8a b1 25 71 5a 68 01 a2 14
cipher suites
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
compression methods
NULL
1 2 0.0138 (0.0077) S>CV3.1(74) Handshake
ServerHello
Version 3.1
random[32]=
42 16 8c c7 c9 2c 43 42 bb 69 a5 ba f1 2d 69 75
c3 8d 3a 85 78 19 f2 e4 d9 2b 72 b4 cc dd e4 72
session_id[32]=
06 37 e9 22 56 29 e6 b4 3a 6e 53 fe 56 27 ed 1f
2a 75 34 65 f0 91 fc 79 cf 90 da ac f4 6f 64 b5
cipherSuite TLS_RSA_WITH_AES_256_CBC_SHA
compressionMethod NULL
1 3 0.0138 (0.0000) S>CV3.1(1477) Handshake
Certificate
1 4 0.0138 (0.0000) S>CV3.1(4) Handshake
ServerHelloDone
1 5 0.0183 (0.0045) C>SV3.1(134) Handshake
ClientKeyExchange
EncryptedPreMasterSecret[128]=
a6 bd d9 4b 76 4b 9d 6f 7b 12 8a e4 52 75 9d 74
4f 06 e4 b0 bc 69 96 d7 42 ba 77 01 b6 9e 64 b0
ea c5 aa de 59 41 e4 f3 9e 1c 1c a9 48 f5 0a 3f
5e c3 50 23 15 d7 46 1d 69 79 76 ba 5e c8 ac 39
23 71 d0 0c 18 a6 a9 77 0f 7d 49 61 ef 6f 8d 32
54 f5 a4 1d 19 33 0a 64 ee 56 91 9b f4 f7 50 b1
11 4b 81 46 4c 36 df 70 98 04 dc 5c 8a 16 a9 2e
58 67 ae 5e 7a a9 44 2b 0b 7c 9c 2f 16 25 1a e9
1 6 0.0183 (0.0000) C>SV3.1(1) ChangeCipherSpec
1 7 0.0183 (0.0000) C>SV3.1(48) Handshake
1 8 0.0630 (0.0447) S>CV3.1(1) ChangeCipherSpec
1 9 0.0630 (0.0000) S>CV3.1(48) Handshake
1 10 0.3274 (0.2643) C>SV3.1(32) application_data
1 11 0.3274 (0.0000) C>SV3.1(720) application_data
1 12 0.3324 (0.0050) S>CV3.1(32) application_data
1 13 0.3324 (0.0000) S>CV3.1(384) application_data
1 9.2491 (8.9166) C>S TCP FIN
1 9.4023 (0.1531) S>C TCP FIN
Once the TLS session is set up, the following MESSAGE message 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, it was necessary to break up some of the lines across continuation lines but the original messages have no continuations lines and no breaks in the Identity header field value.
MESSAGE sips:kumiko@example.net SIP/2.0
To: <sips:kumiko@example.net>
From: <sips:fluffy@example.com>;tag=03de46e1
Via: SIP/2.0/TLS 127.0.0.1:5071;
branch=z9hG4bK-d87543-58c826887160f95f-1--d87543-;rport
Call-ID: 0dc68373623af98a@Y2ouY2lzY28uc2lwaXQubmV0
CSeq: 1 MESSAGE
Contact: <sips:fluffy@127.0.0.1:5071;transport=TLS>
Max-Forwards: 70
Content-Transfer-Encoding: binary
Content-Type: text/plain
Date: Sat, 19 Feb 2005 00:48:07 GMT
User-Agent: SIPimp.org/0.2.5 (curses)
Identity: qKUEWvgss+F0pQHJCyarb8IMbDh1d1gi1Aq51ty61bO+ug5ZQzo31xn
MAFHUe0tzNVoyOfmGUY2dIEWJ2iZlGI5EW3RF5hGN9f0y39iCRqGEAE
B4UG5ocU4RzgXfK3Durle/66rkyCaLPJQ/pzgA+qW/nQytSuzewhDrD
FRrCBQ=
Content-Length: 6
Hello!
The response is sent from example.net to example.com over the same TLS connection. It is shown below.
SIP/2.0 200 OK
To: <sips:kumiko@example.net>;tag=4c53f1b8
From: <sips:fluffy@example.com>;tag=03de46e1
Via: SIP/2.0/TLS 127.0.0.1:5071;
branch=z9hG4bK-d87543-58c826887160f95f-1--d87543-;
rport=55768;received=127.0.0.1
Call-ID: 0dc68373623af98a@Y2ouY2lzY28uc2lwaXQubmV0
CSeq: 1 MESSAGE
Contact: <sips:kumiko@127.0.0.1:5061;transport=TLS>
Content-Length: 0
Example Signed Message. The value on the Content-Type line has been broken across lines to fit on the page but it should not broken across lines in actual implementations.
MESSAGE sip:kumiko@example.net SIP/2.0
To: <sip:kumiko@example.net>
From: <sip:fluffy@example.com>;tag=0c523b42
Via: SIP/2.0/UDP 68.122.119.3:5060;
branch=z9hG4bK-d87543-16a1192b7960f635-1--d87543-;rport
Call-ID: 27bb7608596d8914@Y2ouY2lzY28uc2lwaXQubmV0
CSeq: 1 MESSAGE
Contact: <sip:fluffy@68.122.119.3:5060>
Max-Forwards: 70
Content-Transfer-Encoding: binary
Content-Type: multipart/signed;boundary=151aa2144df0f6bd;\
micalg=sha1;protocol=application/pkcs7-signature
Date: Fri, 04 Feb 2005 20:17:12 GMT
User-Agent: SIPimp.org/0.2.5 (curses)
Content-Length: 1544
--151aa2144df0f6bd
Content-Type: text/plain
Content-Transfer-Encoding: binary
Hello
--151aa2144df0f6bd
Content-Type: application/pkcs7-mime;name=smime.p7s
Content-Disposition: attachment;handling=required;filename=smime.p7s
Content-Transfer-Encoding: binary
*******************
* BINARY BLOB 1 *
*******************
--151aa2144df0f6bd--
It is important to note that the signature is computed across includes the header and excludes the boundary. The value on the Message-body line ends with CRLF. The CRLF is included in the boundary and should not be shown.
Content-Type: text/plain Content-Transfer-Encoding: binary Hello
ASN.1 parse of binary Blob 1. Note that at address 30, the hash for the signature is specified as SHA1. Also note that from address 52 to 777, the sender's certificate is attached, although it is optional [8].
0: SEQUENCE {
4: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2)
15: [0] {
19: SEQUENCE {
23: INTEGER 1
26: SET {
28: SEQUENCE {
30: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
37: NULL
: }
: }
39: SEQUENCE {
41: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
: }
52: [0] {
56: SEQUENCE {
60: SEQUENCE {
64: [0] {
66: INTEGER 2
: }
69: INTEGER 01 95 00 71 02 33 00 58
79: SEQUENCE {
81: OBJECT IDENTIFIER
: sha1withRSAEncryption (1 2 840 113549 1 1 5)
92: NULL
: }
94: SEQUENCE {
96: SET {
98: SEQUENCE {
100: OBJECT IDENTIFIER countryName (2 5 4 6)
105: PrintableString 'US'
: }
: }
109: SET {
111: SEQUENCE {
113: OBJECT IDENTIFIER stateOrProvinceName (2 5 4 8)
118: PrintableString 'California'
: }
: }
130: SET {
132: SEQUENCE {
134: OBJECT IDENTIFIER localityName (2 5 4 7)
139: PrintableString 'San Jose'
: }
: }
149: SET {
151: SEQUENCE {
153: OBJECT IDENTIFIER organizationName (2 5 4 10)
158: PrintableString 'sipit'
: }
: }
165: SET {
167: SEQUENCE {
169: OBJECT IDENTIFIER
: organizationalUnitName (2 5 4 11)
174: PrintableString 'Sipit Test Certificate Authority'
: }
: }
: }
208: SEQUENCE {
210: UTCTime 03/02/2005 18:49:34 GMT
225: UTCTime 03/02/2008 18:49:34 GMT
: }
240: SEQUENCE {
242: SET {
244: SEQUENCE {
246: OBJECT IDENTIFIER countryName (2 5 4 6)
251: PrintableString 'US'
: }
: }
255: SET {
257: SEQUENCE {
259: OBJECT IDENTIFIER stateOrProvinceName (2 5 4 8)
264: PrintableString 'California'
: }
: }
276: SET {
278: SEQUENCE {
280: OBJECT IDENTIFIER localityName (2 5 4 7)
285: PrintableString 'San Jose'
: }
: }
295: SET {
297: SEQUENCE {
299: OBJECT IDENTIFIER organizationName (2 5 4 10)
304: PrintableString 'sipit'
: }
: }
311: SET {
313: SEQUENCE {
315: OBJECT IDENTIFIER commonName (2 5 4 3)
320: TeletexString 'fluffy@example.com'
: }
: }
: }
340: SEQUENCE {
343: SEQUENCE {
345: OBJECT IDENTIFIER
: rsaEncryption (1 2 840 113549 1 1 1)
356: NULL
: }
358: BIT STRING, encapsulates {
362: SEQUENCE {
365: INTEGER
: 00 CA AB 9B 9B 4E 3C D5 45 3C CE 00 A6 36 A8 B9
: EC D2 76 E2 B9 9B E8 28 AA BA 86 22 C5 CF 33 3E
: 4F 6D 56 21 AE BD 54 84 7C 14 14 F9 7D 99 85 00
: 4E 93 D6 FD 6B D4 D1 D4 55 8E C9 89 B1 AF 2B 5F
: 23 99 4A 95 E5 68 65 64 1D 12 A7 DB D3 D5 97 18
: 47 35 9C E6 88 27 9D A8 6C CA 2A 84 E6 62 D8 F1
: E9 A2 1A 39 7E 0E 0F 90 A5 A6 79 21 BC 2A 67 B4
: DD 69 90 82 9A AE 1F 02 52 8A 58 D3 F5 D0 D4 66
: [ Another 1 bytes skipped ]
497: INTEGER 65537
: }
: }
: }
502: [3] {
504: SEQUENCE {
506: SEQUENCE {
508: OBJECT IDENTIFIER subjectAltName (2 5 29 17)
513: OCTET STRING, encapsulates {
515: SEQUENCE {
517: [6] 'sip:fluffy@example.com'
541: [6] 'im:fluffy@example.com'
564: [6] 'pres:fluffy@example.com'
: }
: }
: }
589: SEQUENCE {
591: OBJECT IDENTIFIER basicConstraints (2 5 29 19)
596: OCTET STRING, encapsulates {
598: SEQUENCE {}
: }
: }
600: SEQUENCE {
602: OBJECT IDENTIFIER
subjectKeyIdentifier (2 5 29 14)
607: OCTET STRING, encapsulates {
609: OCTET STRING
: EC DA 98 5E E9 F7 F7 D7 EC 2B 29 4B DA 25 EE C7
: C7 7E 95 70
: }
: }
: }
: }
: }
631: SEQUENCE {
633: OBJECT IDENTIFIER
: sha1withRSAEncryption (1 2 840 113549 1 1 5)
644: NULL
: }
646: BIT STRING
: 4C 46 49 6E 01 48 E2 D4 6E D7 48 A1 F3 7B C8 A5
: 98 37 A5 44 46 58 9F 4A 37 7D 90 FB 5F FF 36 BD
: 67 31 F0 29 DE 0A E2 EA B9 F0 5C 9F AD A0 DE E5
: 4E 42 8F 11 D8 41 EA 68 BE DB C2 1E FA E5 8A 2D
: 7F 66 13 29 E9 DA 8F FB 80 BF 7E 5E B6 04 AD 08
: 5E 58 95 B7 C5 38 85 D5 65 31 AD 80 CB 28 A7 4C
: AD 11 FD 41 3B 37 77 5A DE 85 96 3D 66 EB 5F 9A
: F8 60 5F 8E B1 FC 4A 43 53 B6 11 4D 2E F4 3D FF
: }
: }
778: SET {
782: SEQUENCE {
786: INTEGER 1
789: SEQUENCE {
791: SEQUENCE {
793: SET {
795: SEQUENCE {
797: OBJECT IDENTIFIER countryName (2 5 4 6)
802: PrintableString 'US'
: }
: }
806: SET {
808: SEQUENCE {
810: OBJECT IDENTIFIER
stateOrProvinceName (2 5 4 8)
815: PrintableString 'California'
: }
: }
827: SET {
829: SEQUENCE {
831: OBJECT IDENTIFIER localityName (2 5 4 7)
836: PrintableString 'San Jose'
: }
: }
846: SET {
848: SEQUENCE {
850: OBJECT IDENTIFIER organizationName (2 5 4 10)
855: PrintableString 'sipit'
: }
: }
862: SET {
864: SEQUENCE {
866: OBJECT IDENTIFIER
: organizationalUnitName (2 5 4 11)
871: PrintableString
'Sipit Test Certificate Authority'
: }
: }
: }
905: INTEGER 01 95 00 71 02 33 00 58
: }
915: SEQUENCE {
917: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
924: NULL
: }
926: [0] {
929: SEQUENCE {
931: OBJECT IDENTIFIER
contentType (1 2 840 113549 1 9 3)
942: SET {
944: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
: }
: }
955: SEQUENCE {
957: OBJECT IDENTIFIER
signingTime (1 2 840 113549 1 9 5)
968: SET {
970: UTCTime 04/02/2005 20:17:12 GMT
: }
: }
985: SEQUENCE {
987: OBJECT IDENTIFIER
messageDigest (1 2 840 113549 1 9 4)
998: SET {
1000: OCTET STRING
: DA 23 80 0F 1E B9 E1 95 CC 7E 55 3D 49 AE C1 7A
: D5 99 DA 2B
: }
: }
1022: SEQUENCE {
1024: OBJECT IDENTIFIER
: sMIMECapabilities (1 2 840 113549 1 9 15)
1035: SET {
1037: SEQUENCE {
1039: SEQUENCE {
1041: OBJECT IDENTIFIER
: des-EDE3-CBC (1 2 840 113549 3 7)
: }
1051: SEQUENCE {
1053: OBJECT IDENTIFIER
rc2CBC (1 2 840 113549 3 2)
1063: INTEGER 128
: }
1067: SEQUENCE {
1069: OBJECT IDENTIFIER
rc2CBC (1 2 840 113549 3 2)
1079: INTEGER 64
: }
1082: SEQUENCE {
1084: OBJECT IDENTIFIER
desCBC (1 3 14 3 2 7)
: }
1091: SEQUENCE {
1093: OBJECT IDENTIFIER
rc2CBC (1 2 840 113549 3 2)
1103: INTEGER 40
: }
: }
: }
: }
: }
1106: SEQUENCE {
1108: OBJECT IDENTIFIER
rsaEncryption (1 2 840 113549 1 1 1)
1119: NULL
: }
1121: OCTET STRING
: 66 F0 C9 C0 78 69 27 F9 81 05 05 F1 E1 54 B9 5C
: 3A 2B 34 68 0E 31 19 06 DD 00 34 40 66 DF D8 2F
: 0C BC 6C 80 A2 0B 45 5B 68 36 81 C1 F2 8C AF CA
: 0E 9B 9E A0 BD BC 4E 47 2D 99 B6 76 3E F5 9E B7
: 77 78 BB A4 40 35 DE 2E 26 CE AB DA 70 A7 65 BA
: 89 51 E9 AB F1 26 CA 54 1C 05 4D 01 B0 AE 75 6A
: 3F A3 2C 5D 4F A0 46 77 45 6D 11 DE 7C F1 0D C4
: 61 10 67 D2 3D 56 B2 3E A5 C1 2F 6E 0D 5C 4D FC
: }
: }
: }
: }
: }
Example encrypted message:
MESSAGE sip:kumiko@example.net SIP/2.0
To: <sip:kumiko@example.net>
From: <sip:fluffy@example.com>;tag=6d2a39e4
Via: SIP/2.0/UDP 68.122.119.3:5060;
branch=z9hG4bK-d87543-44ddc0a217a51788-1--d87543-;rport
Call-ID: 031be67669ea9799@Y2ouY2lzY28uc2lwaXQubmV0
CSeq: 1 MESSAGE
Contact: <sip:fluffy@68.122.119.3:5060>
Max-Forwards: 70
Content-Disposition: attachment;handling=required;filename=smime.p7
Content-Transfer-Encoding: binary
Content-Type: application/pkcs7-mime;\
smime-type=enveloped-data;name=smime.p7m
Date: Fri, 04 Feb 2005 20:04:10 GMT
User-Agent: SIPimp.org/0.2.5 (curses)
Content-Length: 418
*****************
* BINARY BLOB 2 *
*****************
ASN.1 parse of binary Blob 2. Note that at address 324, the encryption is set to des-ebe3-cbc.
0: SEQUENCE {
4: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
15: [0] {
19: SEQUENCE {
23: INTEGER 0
26: SET {
30: SEQUENCE {
34: INTEGER 0
37: SEQUENCE {
39: SEQUENCE {
41: SET {
43: SEQUENCE {
45: OBJECT IDENTIFIER countryName (2 5 4 6)
50: PrintableString 'US'
: }
: }
54: SET {
56: SEQUENCE {
58: OBJECT IDENTIFIER
stateOrProvinceName (2 5 4 8)
63: PrintableString 'California'
: }
: }
75: SET {
77: SEQUENCE {
79: OBJECT IDENTIFIER localityName (2 5 4 7)
84: PrintableString 'San Jose'
: }
: }
94: SET {
96: SEQUENCE {
98: OBJECT IDENTIFIER organizationName (2 5 4 10)
103: PrintableString 'sipit'
: }
: }
110: SET {
112: SEQUENCE {
114: OBJECT IDENTIFIER
: organizationalUnitName (2 5 4 11)
119: PrintableString
'Sipit Test Certificate Authority'
: }
: }
: }
153: INTEGER 01 95 00 71 02 33 00 57
: }
163: SEQUENCE {
165: OBJECT IDENTIFIER
rsaEncryption (1 2 840 113549 1 1 1)
176: NULL
: }
178: OCTET STRING
: BC 8A DF 69 69 F9 72 2A 13 32 62 DF FA 83 FE EF
: 28 6A 3A 63 75 FC 2F 83 93 13 21 A0 62 FC 29 01
: 35 F7 81 B2 3B 2E FD F8 E4 D3 DD E0 C3 52 32 13
: B0 37 31 9D 5C A0 41 3A C5 A5 95 C9 95 08 DA 47
: E9 1D 72 F8 75 71 B0 05 E0 0A B3 33 60 F2 9C 0B
: CF FB DE 2E BC 1B C5 8F AE 5F BB 9E 73 21 E2 E2
: 2F 34 B7 2F F0 BB B8 94 76 8F 6D 4B 9A 7F CD 4E
: 4A 01 0D 12 ED 70 81 00 8C B8 37 9E 6B 80 66 03
: }
: }
309: SEQUENCE {
311: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
322: SEQUENCE {
324: OBJECT IDENTIFIER des-EDE3-CBC (1 2 840 113549 3 7)
334: OCTET STRING 05 8B C4 DC 50 5E D7 09
: }
344: [0]
: 60 23 E0 B9 79 CC 39 5B 86 E9 87 8C C2 C6 A0 EE
: 7A 15 3F 0A BB D8 F5 6C EF 4D 18 52 C1 25 65 F5
: 84 5F C7 1C 78 52 1D 33 37 2B 41 69 52 D0 7C FD
: 67 A2 2E 96 2E AA 8F 6F 66 F2 9E 2F 74 12 A7 C7
: CC 9E 83 D1 D9 C4 57 A3
: }
: }
: }
: }
In the example below, one of the headers is contained in a box and is split across two lines. This was only done to make it fit in the RFC format. This header should not have the box around it and should be on one line with no whitespace between the "mime;" and the "smime-type". Note that Content-Type is split across lines for formatting but is not split in the real message.
MESSAGE sip:kumiko@example.net SIP/2.0
To: <sip:kumiko@example.net>
From: <sip:fluffy@example.com>;tag=361300da
Via: SIP/2.0/UDP 68.122.119.3:5060;
branch=z9hG4bK-d87543-0710dbfb18ebb8e6-1--d87543-;rport
Call-ID: 5eda27a67de6283d@Y2ouY2lzY28uc2lwaXQubmV0
CSeq: 1 MESSAGE
Contact: <sip:fluffy@68.122.119.3:5060>
Max-Forwards: 70
Content-Transfer-Encoding: binary
Content-Type: multipart/signed;boundary=1af019eb7754ddf7;\
micalg=sha1;protocol=application/pkcs7-signature
Date: Fri, 04 Feb 2005 20:07:14 GMT
User-Agent: SIPimp.org/0.2.5 (curses)
Content-Length: 2079
--1af019eb7754ddf7
|--See note about stuff in this box --------------------|
|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 *
*****************
--1af019eb7754ddf7
Content-Type: application/pkcs7-mime;name=smime.p7s
Content-Disposition: attachment;handling=required;filename=smime.p7s
Content-Transfer-Encoding: binary
*****************
* BINARY BLOB 4 *
*****************
--1af019eb7754ddf7--
Binary blob 3
0: SEQUENCE {
4: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
15: [0] {
19: SEQUENCE {
23: INTEGER 0
26: SET {
30: SEQUENCE {
34: INTEGER 0
37: SEQUENCE {
39: SEQUENCE {
41: SET {
43: SEQUENCE {
45: OBJECT IDENTIFIER countryName (2 5 4 6)
50: PrintableString 'US'
: }
: }
54: SET {
56: SEQUENCE {
58: OBJECT IDENTIFIER
stateOrProvinceName (2 5 4 8)
63: PrintableString 'California'
: }
: }
75: SET {
77: SEQUENCE {
79: OBJECT IDENTIFIER localityName (2 5 4 7)
84: PrintableString 'San Jose'
: }
: }
94: SET {
96: SEQUENCE {
98: OBJECT IDENTIFIER organizationName (2 5 4 10)
103: PrintableString 'sipit'
: }
: }
110: SET {
112: SEQUENCE {
114: OBJECT IDENTIFIER
: organizationalUnitName (2 5 4 11)
119: PrintableString
'Sipit Test Certificate Authority'
: }
: }
: }
153: INTEGER 01 95 00 71 02 33 00 57
: }
163: SEQUENCE {
165: OBJECT IDENTIFIER
rsaEncryption (1 2 840 113549 1 1 1)
176: NULL
: }
178: OCTET STRING
: 0D 65 F7 54 9B A6 A5 42 2B 12 0E AC 70 16 20 52
: 64 22 B8 61 24 DD 88 38 AA 59 B6 55 D9 73 79 B8
: 7B 10 A9 13 1C A3 A4 00 CE F7 0A 81 80 5B 37 E3
: 2E A4 16 58 43 DF A1 FF 8A FD 43 1C 52 D5 79 43
: 79 7F 7A FF CB 09 49 0F 2A 49 12 6C EC C5 58 0F
: 4F 02 75 47 12 8C 8C 8F 84 49 FC 19 F0 24 9F F4
: 7A 22 53 64 92 40 CA 03 41 3B 22 B7 E2 8A B5 79
: 22 22 9F BC 10 65 0D 69 02 1C 51 35 6D A2 9D 77
: }
: }
309: SEQUENCE {
311: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
322: SEQUENCE {
324: OBJECT IDENTIFIER des-EDE3-CBC (1 2 840 113549 3 7)
334: OCTET STRING E2 6A CB 3E F3 BC A2 00
: }
344: [0]
: 62 45 2E 76 6F 99 83 F2 C5 0B 9C 87 9E 66 C5 38
: F1 57 68 5F CF F1 AF 44 5E 02 84 FF C3 76 94 D4
: 9C 34 6B AD 2E 4A 1A 57 4B 88 4C A7 55 7C BF AB
: BB FD 15 E6 20 ED 22 36 73 2E 61 B5 69 37 A8 0C
: 43 D1 A1 02 0E B9 B5 69
: }
: }
: }
: }
Binary Blob 4
0: SEQUENCE {
4: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2)
15: [0] {
19: SEQUENCE {
23: INTEGER 1
26: SET {
28: SEQUENCE {
30: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
37: NULL
: }
: }
39: SEQUENCE {
41: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
: }
52: [0] {
56: SEQUENCE {
60: SEQUENCE {
64: [0] {
66: INTEGER 2
: }
69: INTEGER 01 95 00 71 02 33 00 58
79: SEQUENCE {
81: OBJECT IDENTIFIER
: sha1withRSAEncryption (1 2 840 113549 1 1 5)
92: NULL
: }
94: SEQUENCE {
96: SET {
98: SEQUENCE {
100: OBJECT IDENTIFIER countryName (2 5 4 6)
105: PrintableString 'US'
: }
: }
109: SET {
111: SEQUENCE {
113: OBJECT IDENTIFIER stateOrProvinceName (2 5 4 8)
118: PrintableString 'California'
: }
: }
130: SET {
132: SEQUENCE {
134: OBJECT IDENTIFIER localityName (2 5 4 7)
139: PrintableString 'San Jose'
: }
: }
149: SET {
151: SEQUENCE {
153: OBJECT IDENTIFIER organizationName (2 5 4 10)
158: PrintableString 'sipit'
: }
: }
165: SET {
167: SEQUENCE {
169: OBJECT IDENTIFIER
: organizationalUnitName (2 5 4 11)
174: PrintableString
'Sipit Test Certificate Authority'
: }
: }
: }
208: SEQUENCE {
210: UTCTime 03/02/2005 18:49:34 GMT
225: UTCTime 03/02/2008 18:49:34 GMT
: }
240: SEQUENCE {
242: SET {
244: SEQUENCE {
246: OBJECT IDENTIFIER countryName (2 5 4 6)
251: PrintableString 'US'
: }
: }
255: SET {
257: SEQUENCE {
259: OBJECT IDENTIFIER
stateOrProvinceName (2 5 4 8)
264: PrintableString 'California'
: }
: }
276: SET {
278: SEQUENCE {
280: OBJECT IDENTIFIER localityName (2 5 4 7)
285: PrintableString 'San Jose'
: }
: }
295: SET {
297: SEQUENCE {
299: OBJECT IDENTIFIER organizationName (2 5 4 10)
304: PrintableString 'sipit'
: }
: }
311: SET {
313: SEQUENCE {
315: OBJECT IDENTIFIER commonName (2 5 4 3)
320: TeletexString 'fluffy@example.com'
: }
: }
: }
340: SEQUENCE {
343: SEQUENCE {
345: OBJECT IDENTIFIER
: rsaEncryption (1 2 840 113549 1 1 1)
356: NULL
: }
358: BIT STRING, encapsulates {
362: SEQUENCE {
365: INTEGER
: 00 CA AB 9B 9B 4E 3C D5 45 3C CE 00 A6 36 A8 B9
: EC D2 76 E2 B9 9B E8 28 AA BA 86 22 C5 CF 33 3E
: 4F 6D 56 21 AE BD 54 84 7C 14 14 F9 7D 99 85 00
: 4E 93 D6 FD 6B D4 D1 D4 55 8E C9 89 B1 AF 2B 5F
: 23 99 4A 95 E5 68 65 64 1D 12 A7 DB D3 D5 97 18
: 47 35 9C E6 88 27 9D A8 6C CA 2A 84 E6 62 D8 F1
: E9 A2 1A 39 7E 0E 0F 90 A5 A6 79 21 BC 2A 67 B4
: DD 69 90 82 9A AE 1F 02 52 8A 58 D3 F5 D0 D4 66
: [ Another 1 bytes skipped ]
497: INTEGER 65537
: }
: }
: }
502: [3] {
504: SEQUENCE {
506: SEQUENCE {
508: OBJECT IDENTIFIER subjectAltName (2 5 29 17)
513: OCTET STRING, encapsulates {
515: SEQUENCE {
517: [6] 'sip:fluffy@example.com'
541: [6] 'im:fluffy@example.com'
564: [6] 'pres:fluffy@example.com'
: }
: }
: }
589: SEQUENCE {
591: OBJECT IDENTIFIER
basicConstraints (2 5 29 19)
596: OCTET STRING, encapsulates {
598: SEQUENCE {}
: }
: }
600: SEQUENCE {
602: OBJECT IDENTIFIER
subjectKeyIdentifier (2 5 29 14)
607: OCTET STRING, encapsulates {
609: OCTET STRING
: EC DA 98 5E E9 F7 F7 D7 EC 2B 29 4B DA 25 EE C7
: C7 7E 95 70
: }
: }
: }
: }
: }
631: SEQUENCE {
633: OBJECT IDENTIFIER
: sha1withRSAEncryption (1 2 840 113549 1 1 5)
644: NULL
: }
646: BIT STRING
: 4C 46 49 6E 01 48 E2 D4 6E D7 48 A1 F3 7B C8 A5
: 98 37 A5 44 46 58 9F 4A 37 7D 90 FB 5F FF 36 BD
: 67 31 F0 29 DE 0A E2 EA B9 F0 5C 9F AD A0 DE E5
: 4E 42 8F 11 D8 41 EA 68 BE DB C2 1E FA E5 8A 2D
: 7F 66 13 29 E9 DA 8F FB 80 BF 7E 5E B6 04 AD 08
: 5E 58 95 B7 C5 38 85 D5 65 31 AD 80 CB 28 A7 4C
: AD 11 FD 41 3B 37 77 5A DE 85 96 3D 66 EB 5F 9A
: F8 60 5F 8E B1 FC 4A 43 53 B6 11 4D 2E F4 3D FF
: }
: }
778: SET {
782: SEQUENCE {
786: INTEGER 1
789: SEQUENCE {
791: SEQUENCE {
793: SET {
795: SEQUENCE {
797: OBJECT IDENTIFIER countryName (2 5 4 6)
802: PrintableString 'US'
: }
: }
806: SET {
808: SEQUENCE {
810: OBJECT IDENTIFIER
stateOrProvinceName (2 5 4 8)
815: PrintableString 'California'
: }
: }
827: SET {
829: SEQUENCE {
831: OBJECT IDENTIFIER localityName (2 5 4 7)
836: PrintableString 'San Jose'
: }
: }
846: SET {
848: SEQUENCE {
850: OBJECT IDENTIFIER organizationName (2 5 4 10)
855: PrintableString 'sipit'
: }
: }
862: SET {
864: SEQUENCE {
866: OBJECT IDENTIFIER
: organizationalUnitName (2 5 4 11)
871: PrintableString
'Sipit Test Certificate Authority'
: }
: }
: }
905: INTEGER 01 95 00 71 02 33 00 58
: }
915: SEQUENCE {
917: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
924: NULL
: }
926: [0] {
929: SEQUENCE {
931: OBJECT IDENTIFIER
contentType (1 2 840 113549 1 9 3)
942: SET {
944: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
: }
: }
955: SEQUENCE {
957: OBJECT IDENTIFIER
signingTime (1 2 840 113549 1 9 5)
968: SET {
970: UTCTime 04/02/2005 20:07:14 GMT
: }
: }
985: SEQUENCE {
987: OBJECT IDENTIFIER
messageDigest (1 2 840 113549 1 9 4)
998: SET {
1000: OCTET STRING
: 58 ED 12 DD 68 18 99 96 F9 4C 81 4C A6 51 BD 84
: A8 BA F3 6A
: }
: }
1022: SEQUENCE {
1024: OBJECT IDENTIFIER
: sMIMECapabilities (1 2 840 113549 1 9 15)
1035: SET {
1037: SEQUENCE {
1039: SEQUENCE {
1041: OBJECT IDENTIFIER
: des-EDE3-CBC (1 2 840 113549 3 7)
: }
1051: SEQUENCE {
1053: OBJECT IDENTIFIER
rc2CBC (1 2 840 113549 3 2)
1063: INTEGER 128
: }
1067: SEQUENCE {
1069: OBJECT IDENTIFIER
rc2CBC (1 2 840 113549 3 2)
1079: INTEGER 64
: }
1082: SEQUENCE {
1084: OBJECT IDENTIFIER desCBC (1 3 14 3 2 7)
: }
1091: SEQUENCE {
1093: OBJECT IDENTIFIER
rc2CBC (1 2 840 113549 3 2)
1103: INTEGER 40
: }
: }
: }
: }
: }
1106: SEQUENCE {
1108: OBJECT IDENTIFIER
rsaEncryption (1 2 840 113549 1 1 1)
1119: NULL
: }
1121: OCTET STRING
: 41 3C 43 53 6B EC 3A C2 E4 E2 1B 69 80 1B 68 54
: 80 81 7F 33 05 DD 67 E8 ED D0 03 A0 90 4B AA 43
: D4 54 CA 04 C9 78 97 8A E7 93 C0 05 F6 FA 30 BC
: 59 1B 5D 30 5D E3 92 94 BA 4D D6 23 C0 59 17 F2
: 0A F5 2C 73 0B 54 26 11 C3 3E FE 4C C2 ED 0B 89
: 30 15 55 38 4A 80 D1 D5 AA 11 89 3A 9D 4B 47 C4
: 29 F9 CF B7 44 53 21 E0 36 7E 81 02 CC DB 4C 09
: 2D CA A1 AA 1B 76 F9 83 5C 86 53 24 30 BD 94 69
: }
: }
: }
: }
: }
This section describes some common interoperability problems. Implementers should verify that their clients do the correct things and perhaps make their clients forgiving in what they receive, or at least have them produce reasonable error messages when interacting with software that has these problems.
A common problem in interoperability is that some SIP clients do not support TLS and only do SSLv3. Check that the client does use TLS.
Many SIP clients were found to accept expired certificates with no warning or error.
TLS and S/MIME can provide the identity of the peer that a client is communicating with in the Subject Alternative Name in the certificate. The software must check that this name corresponds to the identity the server is trying to contact. 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 must generate an error or warning of some type. Similarly with S/MIME, if a user is trying to communicate with fluffy@example.com, the Subject Alternate Name field in the certificate must match the AOR for fluffy.
Some implementations used binary MIME encodings while others used base64. There is no reason not to use binary - check that your implementation sends binary and preferably receives both.
The examples here attach the sender's certificates - is this how we want to go?
Need to add Accept header field value with multipart to all of the examples. Might also want to request congestion safety on all of them.
No IANA actions are required.
Many thanks to the developers of all the open source software used to create these call flows. This includes the underling 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 http://www.rtfm.com/ssldump. The book SSL and TLS [11] was a huge help in developing the code for these flows and is a great resource for anyone trying to implement TLS with SIP.
Thanks to Dan Wing and Robert Sparks for catching many silly mistakes and to Tat Chan who caught a key problem in what the signature was being computed over. Also thanks to Lyndsay Campbell.
| [10] | Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. |
| [11] | Rescorla, E.K., "SSL and TLS - Designing and Building Secure Systems", 2001. |
| Cullen Jennings | |
| Cisco Systems | |
| 170 West Tasman Drive Mailstop SJC-21/2 |
|
| San Jose, CA 95134 | |
| USA | |
| Phone: | +1 408 902-3341 |
| EMail: | fluffy@cisco.com |
| Kumiko Ono | |
| NTT Corporation | |
| Musashino-shi, Tokyo 180-8585 | |
| Japan | |
| Phone: | +81 422 59 4508 |
| EMail: | ono.kumiko@lab.ntt.co.jp |
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. 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 filed with a certificate signing request, called example.net.csr, is also created an can be used to get the certificate signed by another CA.
A second argument indicating the number of days for which the 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 with to PKCS#7 with "openssl crl2pkcs7 -nocrl -certfile cert.pem -certfile demoCA/cacert.pem -outform DER -out cert.p7c"
IE, Outlook, and Netscape 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 or one .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.
#!/bin/sh
#set -x
rm -rf demoCA
mkdir demoCA
mkdir demoCA/certs
mkdir demoCA/crl
mkdir demoCA/newcerts
mkdir demoCA/private
#echo "01" > demoCA/serial
hexdump -n 4 -e '4/1 "%04d"' /dev/random > 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
if [ ! -f $CONF ]; then
echo "Can not find file $CONF - set your OPENSSLDIR variable"
exit
fi
cp $CONF openssl.cnf
cat >> openssl.cnf <<EOF
[ cj_cert ]
subjectAltName=\${ENV::ALTNAME}
basicConstraints=CA:FALSE
subjectKeyIdentifier=hash
#authorityKeyIdentifier=keyid,issuer:always
[ cj_req ]
basicConstraints = CA:FALSE
subjectAltName=\${ENV::ALTNAME}
subjectKeyIdentifier=hash
#authorityKeyIdentifier=keyid,issuer:always
#keyUsage = nonRepudiation, digitalSignature, keyEncipherment
EOF
cat > demoCA/private/cakey.pem <<EOF
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,4B47A0A73ADE342E
aHmlPa+ZrOV6v+Jk0SClxzpxoG3j0ZuyoVkF9rzq2bZkzVBKLU6xhWwjMDqwA8dH
3fCRLhMGIUVnmymXYhTW9svI1gpFxMBQHJcKpV/SmgFn/fbYk98Smo2izHOniIiu
NOu2zr+bMiaBphOAZ/OCtVUxUOoBDKN9lR39UCDOgkEQzp9Vbw7l736yu5H9GMHP
JtGLJyx3RhS3TvLfLAJZhjm/wZ/9QM8GjyJEiDhMQRJVeIZGvv4Yr1u6yYHiHfjX
tX2eds8Luc83HbSvjAyjnkLtJsAZ/8cFzrd7pjFzbogLdWuil+kpkkf5h1uzh7oa
um0M1EXBE4tcDHsfg1iqEsDMIei/U+/rWfk1PrzYlklwZp8S03vulkDm1fT76W7d
mRBg4+CrHA6qYn6EPWB37OBtfEqAfINnIcI1dWzso9A0bTPD4EJO0JA0PcZ/2JgT
PaKySgooHQ8AHNQebelch6M5LFExpaOADJKrqauKcc2HeUxXaYIpac5/7drIl3io
UloqUnMlGa3eLP7BZIMsZKCfHZ8oqwU4g6mmmJath2gODRDx3mfhH6yaimDL7v4i
SAIIkrEHXfSyovrTJymfSfQtYxUraVZDqax6oj/eGllRxliGfMLYG9ceU+yU/8FN
LE7P+Cs19H5tHHzx1LlieaK43u/XvbXHlB5mqL/fZdkUIBJsjbBVx0HR8eQl2CH9
YJDMOPLADecwHoyKA0AY59oN9d41oF7yZtN9KwNdslROYH7mNJlqMMenhXCLN+Nz
vVU5/7/ugZFhZqfS46c1WdmSvuqpDp7TBtMeaH/PXjysBr0iZffOxQ==
-----END RSA PRIVATE KEY-----
EOF
cat > demoCA/cacert.pem <<EOF
-----BEGIN CERTIFICATE-----
MIIDJDCCAo2gAwIBAgIBADANBgkqhkiG9w0BAQUFADBwMQswCQYDVQQGEwJVUzET
MBEGA1UECBMKQ2FsaWZvcm5pYTERMA8GA1UEBxMIU2FuIEpvc2UxDjAMBgNVBAoT
BXNpcGl0MSkwJwYDVQQLEyBTaXBpdCBUZXN0IENlcnRpZmljYXRlIEF1dGhvcml0
eTAeFw0wMzA3MTgxMjIxNTJaFw0xMzA3MTUxMjIxNTJaMHAxCzAJBgNVBAYTAlVT
MRMwEQYDVQQIEwpDYWxpZm9ybmlhMREwDwYDVQQHEwhTYW4gSm9zZTEOMAwGA1UE
ChMFc2lwaXQxKTAnBgNVBAsTIFNpcGl0IFRlc3QgQ2VydGlmaWNhdGUgQXV0aG9y
aXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDIh6DkcUDLDyK9BEUxkud
+nJ4xrCVGKfgjHm6XaSuHiEtnfELHM+9WymzkBNzZpJu30yzsxwfKoIKugdNUrD4
N3viCicwcN35LgP/KnbN34cavXHr4ZlqxH+OdKB3hQTpQa38A7YXdaoz6goW2ft5
Mi74z03GNKP/G9BoKOGd5QIDAQABo4HNMIHKMB0GA1UdDgQWBBRrRhcU6pR2JYBU
bhNU2qHjVBShtjCBmgYDVR0jBIGSMIGPgBRrRhcU6pR2JYBUbhNU2qHjVBShtqF0
pHIwcDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcT
CFNhbiBKb3NlMQ4wDAYDVQQKEwVzaXBpdDEpMCcGA1UECxMgU2lwaXQgVGVzdCBD
ZXJ0aWZpY2F0ZSBBdXRob3JpdHmCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0B
AQUFAAOBgQCWbRvv1ZGTRXxbH8/EqkdSCzSoUPrs+rQqR0xdQac9wNY/nlZbkR3O
qAezG6Sfmklvf+DOg5RxQq/+Y6I03LRepc7KeVDpaplMFGnpfKsibETMipwzayNQ
QgUf4cKBiF+65Ue7hZuDJa2EMv8qW4twEhGDYclpFU9YozyS1OhvUg==
-----END CERTIFICATE-----
EOF
# uncomment the following lines to generate your own key pair
#openssl req -newkey rsa:1024 -passin pass:password \
# -passout pass:password \
# -sha1 -x509 -keyout demoCA/private/cakey.pem \
# -out demoCA/cacert.pem -days 3650 <<EOF
#US
#California
#San Jose
#sipit
#Sipit Test Certificate Authority
#
#
#EOF
openssl crl2pkcs7 -nocrl -certfile demoCA/cacert.pem \
-outform DER -out demoCA/cacert.p7c
cp demoCA/cacert.pem root_cert_fluffyCA.pem
#!/bin/sh
#set -x
if [ $# == 1 ]; then
DAYS=1095
elif [ $# == 2 ]; then
DAYS=$2
else
echo "Usage: makeCert test.example.org [days]"
echo " makeCert alice@example.org [days]"
echo "days is how long the certificate is valid"
echo "days set to 0 generates an invalid certificate"
exit 0
fi
ADDR=$1
echo "making cert for ${ADDR}"
rm -f ${ADDR}_*.pem
rm -f ${ADDR}.p12
case ${ADDR} in
*:*) ALTNAME="URI:${ADDR}" ;;
*@*) ALTNAME="URI:sip:${ADDR},URI:im:${ADDR},URI:pres:${ADDR}" ;;
*) ALTNAME="DNS:${ADDR}" ;;
esac
rm -f demoCA/index.txt
touch demoCA/index.txt
rm -f demoCA/newcerts/*
export ALTNAME
openssl genrsa -out ${ADDR}_key.pem 1024
openssl req -new -config openssl.cnf -reqexts cj_req \
-sha1 -key ${ADDR}_key.pem \
-out ${ADDR}.csr -days ${DAYS} <<EOF
US
California
San Jose
sipit
${ADDR}
EOF
if [ $DAYS == 0 ]; then
openssl ca -extensions cj_cert -config openssl.cnf \
-passin pass:password -policy policy_anything \
-md sha1 -batch -notext -out ${ADDR}_cert.pem \
-startdate 990101000000Z \
-enddate 000101000000Z \
-infiles ${ADDR}.csr
else
openssl ca -extensions cj_cert -config openssl.cnf \
-passin pass:password -policy policy_anything \
-md sha1 -days ${DAYS} -batch -notext -out ${ADDR}_cert.pem \
-infiles ${ADDR}.csr
fi
openssl pkcs12 -passin pass:password \
-passout pass:password -export \
-out ${ADDR}.p12 -in ${ADDR}_cert.pem \
-inkey ${ADDR}_key.pem -name ${ADDR} -certfile demoCA/cacert.pem
openssl x509 -in ${ADDR}_cert.pem -noout -text
case ${ADDR} in
*@*) mv ${ADDR}_key.pem user_key_${ADDR}.pem; \
mv ${ADDR}_cert.pem user_cert_${ADDR}.pem ;;
*) mv ${ADDR}_key.pem domain_key_${ADDR}.pem; \
mv ${ADDR}_cert.pem domain_cert_${ADDR}.pem ;;
esac
This section contains various certificates used for testing in PEM format.
Fluffy's certificate.
-----BEGIN CERTIFICATE----- MIICzjCCAjegAwIBAgIIAZUAcQIzAFgwDQYJKoZIhvcNAQEFBQAwcDELMAkGA1UE BhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBKb3NlMQ4w DAYDVQQKEwVzaXBpdDEpMCcGA1UECxMgU2lwaXQgVGVzdCBDZXJ0aWZpY2F0ZSBB dXRob3JpdHkwHhcNMDUwMjAzMTg0OTM0WhcNMDgwMjAzMTg0OTM0WjBiMQswCQYD VQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTERMA8GA1UEBxMIU2FuIEpvc2Ux DjAMBgNVBAoTBXNpcGl0MRswGQYDVQQDFBJmbHVmZnlAZXhhbXBsZS5jb20wgZ8w DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMqrm5tOPNVFPM4ApjaouezSduK5m+go qrqGIsXPMz5PbVYhrr1UhHwUFPl9mYUATpPW/WvU0dRVjsmJsa8rXyOZSpXlaGVk HRKn29PVlxhHNZzmiCedqGzKKoTmYtjx6aIaOX4OD5ClpnkhvCpntN1pkIKarh8C UopY0/XQ1GZnAgMBAAGjfzB9MFEGA1UdEQRKMEiGFnNpcDpmbHVmZnlAZXhhbXBs ZS5jb22GFWltOmZsdWZmeUBleGFtcGxlLmNvbYYXcHJlczpmbHVmZnlAZXhhbXBs ZS5jb20wCQYDVR0TBAIwADAdBgNVHQ4EFgQU7NqYXun399fsKylL2iXux8d+lXAw DQYJKoZIhvcNAQEFBQADgYEATEZJbgFI4tRu10ih83vIpZg3pURGWJ9KN32Q+1// Nr1nMfAp3gri6rnwXJ+toN7lTkKPEdhB6mi+28Ie+uWKLX9mEynp2o/7gL9+XrYE rQheWJW3xTiF1WUxrYDLKKdMrRH9QTs3d1rehZY9ZutfmvhgX46x/EpDU7YRTS70 Pf8= -----END CERTIFICATE-----
Fluffy's private key
-----BEGIN RSA PRIVATE KEY----- MIICXAIBAAKBgQDKq5ubTjzVRTzOAKY2qLns0nbiuZvoKKq6hiLFzzM+T21WIa69 VIR8FBT5fZmFAE6T1v1r1NHUVY7JibGvK18jmUqV5WhlZB0Sp9vT1ZcYRzWc5ogn nahsyiqE5mLY8emiGjl+Dg+QpaZ5IbwqZ7TdaZCCmq4fAlKKWNP10NRmZwIDAQAB AoGAXgtxwoh0jBZ716/PcS+sTut+xUiRwxIT30fdHONACRr8RmqM1khAzf7XmMoi kegJjmrF3+K6l4g4IOcnL3y1wVCtzJ1f2QDTuVzAsvazZqI4+pNB4LaAb+JPNQ+4 BtrQSXADXv7HfkUakzeZpgnJYw+zHWaVogKjcLDKHWdrbOECQQDpH/G+GsJ4mnrp wZF9OxKqKhqBO73ZONHDxu55AukLghGnFh1udqdCQ7EPsaCqLN82RS4gn/WDfnBh WB8DRavxAkEA3o6nMOMyKdsuqBbGyEPvaPDVmw973wtEohIj6MgwdYSUOhdKAurR hs09yVGy0QpjoNHIE0vi5lUhPxJ1+Xvv1wJBAL0Ry14DFfX6U/WBqB2I63pW62gk q7ShAH9nt8EtOxS6SNbaeMQ+Nyjm/ZNc3JEoE2BQezi6gsRCp6JLdduRhgECQD1p V7EhwCHUnVc8kbWJKXLnocmbyC6PyWx/XPFK7DRBVTWCX6XWbeKol7gJlzIfj8Y8 nNzWP9IXA4mH6o3hKRkCQA+1er++Tx24uypEijIi7OK0bfjJUlrhCM9NVWxDKrzO 3zpuUB7yzuxrbcMZI8JKQIHL0sWz7egscepxS+N61y8= -----END RSA PRIVATE KEY-----
Kumiko's certificate
-----BEGIN CERTIFICATE----- MIICzjCCAjegAwIBAgIIAZUAcQIzAFcwDQYJKoZIhvcNAQEFBQAwcDELMAkGA1UE BhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBKb3NlMQ4w DAYDVQQKEwVzaXBpdDEpMCcGA1UECxMgU2lwaXQgVGVzdCBDZXJ0aWZpY2F0ZSBB dXRob3JpdHkwHhcNMDUwMjAzMTg0OTIzWhcNMDgwMjAzMTg0OTIzWjBiMQswCQYD VQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTERMA8GA1UEBxMIU2FuIEpvc2Ux DjAMBgNVBAoTBXNpcGl0MRswGQYDVQQDFBJrdW1pa29AZXhhbXBsZS5uZXQwgZ8w DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANX6dhOhUuf+2I3lymzeuSDwHLZqMqnu 3ISiIji/VlEoVUBFIHYjtxbmhIi40mEl4cqT+tVI6gY6Pe7VrL835Yr3AoLLeUB7 4mXa7T152+jAxA4+nCVnIAkMrPxTDeBFEfn+qyCRPWyQ7WEgH3Vd9AufnC7aeafD pp+dcAOFZ2pBAgMBAAGjfzB9MFEGA1UdEQRKMEiGFnNpcDprdW1pa29AZXhhbXBs ZS5uZXSGFWltOmt1bWlrb0BleGFtcGxlLm5ldIYXcHJlczprdW1pa29AZXhhbXBs ZS5uZXQwCQYDVR0TBAIwADAdBgNVHQ4EFgQUNi5qQQ2G6AsiZK79cPEXYmPsqFIw DQYJKoZIhvcNAQEFBQADgYEABIFd9N/3/05AD7Kt9kKSdy6vFvncU1IaccuFfdXc QPfewY8NWwYKWsu588D4Nu77VQ++6a8AtjlJPSY/742Z4oKq1jfxdA+Uz/Z9cv2v 6aM4oX7R5FTgJTbHRC0ueH32OhNlcLhSNGHzNWSrS8AbtNOlfLRJipZI3N0W5b6q 09Q= -----END CERTIFICATE-----
Kumiko's private key
-----BEGIN RSA PRIVATE KEY----- MIICXQIBAAKBgQDV+nYToVLn/tiN5cps3rkg8By2ajKp7tyEoiI4v1ZRKFVARSB2 I7cW5oSIuNJhJeHKk/rVSOoGOj3u1ay/N+WK9wKCy3lAe+Jl2u09edvowMQOPpwl ZyAJDKz8Uw3gRRH5/qsgkT1skO1hIB91XfQLn5wu2nmnw6afnXADhWdqQQIDAQAB AoGBANJktWrxyanxC47iLdpEWHVJgoHeA7jQ8yS6orl3cPDVnpVWIufmkCTFPfWM /Namv89HF3BVhD3hUHogwP03gcsIdxpccnu1wnmTW7IhSQXjBts0mEDbOw8S+WtS 9NjRI4m1+86OflE+TVa3DtwCE/pEOKhFvcZHvXiosYMnucABAkEA6xqKEwR1zI/V u2B28Lcv0iafkJQDfPB3ooahQ+9qy5qUWgGZzXj6tM8YUusVqR/NCg8auqRC5uWD yonN98phQQJBAOj/Pp9yyO2NCVs4Mp5QSXDOlRAOuruMz6vlmURQO/8uBmHvETfC nkvqxxHjHW7mmusEY+ZIvRxmFV4RZcYByQECQHiT5/TQ+Mmti2TKmLXkffY+MOAp yZAulG0at2LsS82YvjVbVNJ5Fbvd6w+72iQfVz2teXv3+wgI9orOGoDXnwECQGrE I58PCzGHkkUBkHhpE+4kS7wK89hjYvpDAKOEHKoHHhecZAhoHv9suwHgT6l09IJD BcANjtLHmHz9feRpBwECQQCuIn02CMxFy5yhjj4nlmCRQ6w6KBWjY68xnN4Qj/g3 SV+1HtmCclS0bK7e/IV6gOKn+MV3C+14JGdSRM+9HqcZ -----END RSA PRIVATE KEY-----
Certificate for example.com
-----BEGIN CERTIFICATE----- MIICjDCCAfWgAwIBAgIIAZUAcQIzAFUwDQYJKoZIhvcNAQEFBQAwcDELMAkGA1UE BhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBKb3NlMQ4w DAYDVQQKEwVzaXBpdDEpMCcGA1UECxMgU2lwaXQgVGVzdCBDZXJ0aWZpY2F0ZSBB dXRob3JpdHkwHhcNMDUwMjAzMTg0OTA4WhcNMDgwMjAzMTg0OTA4WjBbMQswCQYD VQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTERMA8GA1UEBxMIU2FuIEpvc2Ux DjAMBgNVBAoTBXNpcGl0MRQwEgYDVQQDEwtleGFtcGxlLmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEA5jF2tSfMjTKFVnD3wjMzMiZCXjxocXsfeVDQcic7 Sq/yztEMvMBfMWpD53ytZL3H5iWfqs0tkKpohGJ7Bb5Dpa+76p2pW6RTnSKL2pYu Hz+SRrjMyCQ8Rs1dLWSFsaTKAfGOxX4P/wCRo+rLPhICdaS7CMjQKu+zu3J6mOX/ n4ECAwEAAaNEMEIwFgYDVR0RBA8wDYILZXhhbXBsZS5jb20wCQYDVR0TBAIwADAd BgNVHQ4EFgQUIurLOGYd8ZYMmke2uxxSRLB3ZY0wDQYJKoZIhvcNAQEFBQADgYEA rutJ7R7xjSapbQOCktXfRMQeHwd1iDfkdpc1ElmYeXgWbjuxwCvbhQJrdMlbGZLa fvVBC7zS3UWqb74k3EhXZtkugt+ejXADc3Xvj3pWTMxCvTFFsF7/0TvEgu79p8EQ NOuBSRprhn7HYR2zuQoCvYT4R6/P8ahzqDEdIHoGf6w= -----END CERTIFICATE-----
Private key for example.com
-----BEGIN RSA PRIVATE KEY----- MIICXgIBAAKBgQDmMXa1J8yNMoVWcPfCMzMyJkJePGhxex95UNByJztKr/LO0Qy8 wF8xakPnfK1kvcfmJZ+qzS2QqmiEYnsFvkOlr7vqnalbpFOdIovali4fP5JGuMzI JDxGzV0tZIWxpMoB8Y7Ffg//AJGj6ss+EgJ1pLsIyNAq77O7cnqY5f+fgQIDAQAB AoGBANtRm2FkRv7seJ/wSA6OS6PnUeqJMZWVklo6xi9M86/oTbYA9VrNCqWBMqtW XboTG2dKx4KrtFMWGTiwv7esHLPsUB1jYF7/KEsRh4WoRxfeWoQlAY6VYXycg6b5 X0uORdFMWL+WRxPmo8IhDKEwNyRyCyGQjfKpMj0724WjEqWxAkEA9MFDUQD+fL3N ImRQl9ns3nHIIbcrtfxGCFaj+EJEwsyc5gq7QxRc3niNVt5pogPP7+CxskLaPPKU TJmhtwixLQJBAPDE7hcDCPtsn9DIOXf/ZxXjfZAlAfwVsT+ggWQi5r63lGwjIbCT qO6TijtbSqqD0QqULTabVwpIdYyknQqQlCUCQGnkG322UmQhsdiJUh0Amex7ibyc hPrNVHdTFMnZ0en9oHwedHpHGw7dVTkaLNV9lL8RlY+sQMNRqDuj1EVeK1kCQQCH 945FLI+b/OHbs9bQb0k10TyNdHjEdTOdrPSlKhiIx39n+gcCgsC5ylQb5RgrZzlb 8gX+eocS5YyMmkGdP7yJAkEAsmGKAgt4nTfZY5L8PytPK8lCJjBLcyIllI3QEiMY K/81YWYQcqsg5/cLBZC26KgNvxkyLwxS220Djlm19HJKGQ== -----END RSA PRIVATE KEY-----
Certificate for example.net
-----BEGIN CERTIFICATE----- MIICjDCCAfWgAwIBAgIIAZUAcQIzAFYwDQYJKoZIhvcNAQEFBQAwcDELMAkGA1UE BhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBKb3NlMQ4w DAYDVQQKEwVzaXBpdDEpMCcGA1UECxMgU2lwaXQgVGVzdCBDZXJ0aWZpY2F0ZSBB dXRob3JpdHkwHhcNMDUwMjAzMTg0OTExWhcNMDgwMjAzMTg0OTExWjBbMQswCQYD VQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTERMA8GA1UEBxMIU2FuIEpvc2Ux DjAMBgNVBAoTBXNpcGl0MRQwEgYDVQQDEwtleGFtcGxlLm5ldDCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEA2w4I/bz/vxzVskUEF56EYjf4yUftpG8jhmIiwsA8 AKLwc7CTnceW+tLmdDfUQLWw+HP4ky0tgQQA6pmviPORUNjuSj91dE7EJk3ZKePE 3MZ2M5JL6CEFn3HEFnHOQKv3TMKIGSpUZJjHmm15yRPiAlx0Q2vJ29h4W52X1DPM 62MCAwEAAaNEMEIwFgYDVR0RBA8wDYILZXhhbXBsZS5uZXQwCQYDVR0TBAIwADAd BgNVHQ4EFgQUHNoIc7Or6o1iTsM1PmWPdgbxUAwwDQYJKoZIhvcNAQEFBQADgYEA VlSod7+XfvSKNsybqtWPaM8VnoRLFVXvukgQbsdv4wuv5bnDfwxdU25rdizBbql+ m8Us+ky8ORw190v73mSeOro7KMv0mN1u2BaGUB/wjaRsH2HC+UZb0ok3vzZ+W8Re ECjcVyHNRGVw5Iu2W5iWcO/a/74vPaVBiFQQJBRSLxg= -----END CERTIFICATE-----<
Private key for example.net
-----BEGIN RSA PRIVATE KEY----- MIICXgIBAAKBgQDbDgj9vP+/HNWyRQQXnoRiN/jJR+2kbyOGYiLCwDwAovBzsJOd x5b60uZ0N9RAtbD4c/iTLS2BBADqma+I85FQ2O5KP3V0TsQmTdkp48TcxnYzkkvo IQWfccQWcc5Aq/dMwogZKlRkmMeabXnJE+ICXHRDa8nb2HhbnZfUM8zrYwIDAQAB AoGBAIrUP1CIutEldi3wXaKWfTI+ZPc0FeFz6mDdy0gAS0bf/WJk03lYqFA434Ni aqvEOu+LmEu2gzNUFTyZwE0ciMg3NQ0H57z7OvbnHa0LajiJROo7zkROrmE5GTIV v2WstOKJYsMdcTVa4VZd9cHH6zWXHtWDT+Y2MxrIerFnOYxBAkEA72cBQSE4SStZ KvodDuMjFXG97Z1F927Xe/47iWnYRKhVB/jwN9uYpJog2cQFgsIsRMltozi3huTP L8IKkI5N4QJBAOo95ShiRPcbXIXY1IcUGx1Rulr+paIAJwjuuutwrtCA1CbIKB0j vfGVr3mKBGV2XLmz15nNV+5WFiLRBiUgucMCQQCxf+63KnlADurS6ZTH5/KoQKfw WE568WzFWy8raBXYefJpsdHxqFiZmklHDIaFd5A5BBvNDA1O77EKGNWablghAkEA zbvpPqv4+LRuchy8pZtyKTE0JWHNZlkN79mGEO4ajITqUNmx6c4PsVUQFwayz87C qFQdxDdHyMyRiqjd5dQ1cwJAfJsXNGcOhilkV3xBy95tb3IsVP6G5DqwtID4hrYa Onf9xrVzh9M29Xp+AHcwS4Y0+UgiNrd5BlbZs+ALZPD/jw== -----END RSA PRIVATE KEY-----
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at <http://www.ietf.org/ipr>.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Funding for the RFC Editor function is currently provided by the Internet Society.