idnits 2.17.1 draft-ietf-sip-certs-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 8, 2009) is 5342 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2898 (Obsoleted by RFC 8018) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) ** Obsolete normative reference: RFC 5208 (Obsoleted by RFC 5958) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 3 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: Standards Track J. Fischl, Ed. 5 Expires: March 12, 2010 Skype 6 September 8, 2009 8 Certificate Management Service for The Session Initiation Protocol (SIP) 9 draft-ietf-sip-certs-09 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on March 12, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 This draft defines a Credential Service that allows Session 58 Initiation Protocol (SIP) User Agents (UAs) to use a SIP event 59 package to discover the certificates of other users. This mechanism 60 allows user agents that want to contact a given Address-of-Record 61 (AOR) to retrieve that AOR's certificate by subscribing to the 62 Credential Service, which returns an authenticated response 63 containing that certificate. The Credential Service also allows 64 users to store and retrieve their own certificates and private keys. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 4. UA Behavior with Certificates . . . . . . . . . . . . . . . . 9 72 5. UA Behavior with Credentials . . . . . . . . . . . . . . . . . 10 73 6. Event Package Formal Definition for "certificate" . . . . . . 11 74 6.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 11 75 6.2. Event Package Parameters . . . . . . . . . . . . . . . . . 11 76 6.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 11 77 6.4. Subscription Duration . . . . . . . . . . . . . . . . . . 11 78 6.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 11 79 6.6. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 12 80 6.7. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 12 81 6.8. Notifier Generation of NOTIFY Requests . . . . . . . . . . 12 82 6.9. Subscriber Processing of NOTIFY Requests . . . . . . . . . 13 83 6.10. Handling of Forked Requests . . . . . . . . . . . . . . . 13 84 6.11. Rate of Notifications . . . . . . . . . . . . . . . . . . 13 85 6.12. State Agents and Lists . . . . . . . . . . . . . . . . . . 13 86 6.13. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 13 87 7. Event Package Formal Definition for "credential" . . . . . . . 14 88 7.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 14 89 7.2. Event Package Parameters . . . . . . . . . . . . . . . . . 14 90 7.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 14 91 7.4. Subscription Duration . . . . . . . . . . . . . . . . . . 14 92 7.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 14 93 7.6. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 15 94 7.7. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 15 95 7.8. Notifier Generation of NOTIFY Requests . . . . . . . . . . 16 96 7.9. Generation of PUBLISH Requests . . . . . . . . . . . . . . 16 97 7.10. Notifier Processing of PUBLISH Requests . . . . . . . . . 17 98 7.11. Subscriber Processing of NOTIFY Requests . . . . . . . . . 17 99 7.12. Handling of Forked Requests . . . . . . . . . . . . . . . 17 100 7.13. Rate of Notifications . . . . . . . . . . . . . . . . . . 17 101 7.14. State Agents and Lists . . . . . . . . . . . . . . . . . . 18 102 7.15. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 18 103 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 104 8.1. Encrypted Page Mode IM Message . . . . . . . . . . . . . . 18 105 8.2. Setting and Retrieving UA Credentials . . . . . . . . . . 19 106 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 107 9.1. Certificate Revocation . . . . . . . . . . . . . . . . . . 22 108 9.2. Certificate Replacement . . . . . . . . . . . . . . . . . 23 109 9.3. Trusting the Identity of a Certificate . . . . . . . . . . 23 110 9.4. SACRED Framework . . . . . . . . . . . . . . . . . . . . . 24 111 9.5. Crypto Profiles . . . . . . . . . . . . . . . . . . . . . 24 112 9.6. User Certificate Generation . . . . . . . . . . . . . . . 24 113 9.7. Compromised Authentication Service . . . . . . . . . . . . 25 115 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 116 10.1. Certificate Event Package . . . . . . . . . . . . . . . . 26 117 10.2. Credential Event Package . . . . . . . . . . . . . . . . . 26 118 10.3. PKCS#8 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 119 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 120 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 121 12.1. Normative References . . . . . . . . . . . . . . . . . . . 28 122 12.2. Informational References . . . . . . . . . . . . . . . . . 29 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 125 1. Introduction 127 [RFC3261], as ammended by [RFC3853], provides a mechanism for end-to- 128 end encryption and integrity using S/MIME [RFC3851]. Several 129 security properties of [RFC3261] depend on S/MIME, and yet it has not 130 been widely deployed. One reason is the complexity of providing a 131 reasonable certificate distribution infrastructure. This 132 specification proposes a way to address discovery, retrieval, and 133 management of certificates for SIP deployments. Combined with the 134 SIP Identity [RFC4474] specification, this specification allows users 135 to have certificates that are not signed by any well known 136 certificate authority while still strongly binding the user's 137 identity to the certificate. 139 In addition, this specification provides a mechanism that allows SIP 140 User Agents such as IP phones to enroll and get their credentials 141 without any more configuration information than they commonly have 142 today. The end user expends no extra effort. 144 2. Definitions 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 Certificate: A PKIX [RFC5280] style certificate containing a public 151 key and a list of identities in the SubjectAltName that are bound 152 to this key. The certificates discussed in this draft are 153 generally self signed and use the mechanisms in the SIP Identity 154 [RFC4474] specification to vouch for their validity. Certificates 155 that are signed by a certificate authority can also be used with 156 all the mechanisms in this draft, but it is expected that they are 157 used purely as a key carrier and that their validity is not 158 checked. 159 Credential: For this document, credential means the combination of a 160 certificate and the associated private key. 161 Password Phrase: A password used to encrypt a PKCS#8 private key. 163 3. Overview 165 The general approach is to provide a new SIP service referred to as a 166 "credential service" that allows SIP User Agents (UAs) to subscribe 167 to other users' certificates using a new SIP event package [RFC3265]. 168 The certificate is delivered to the subscribing UA in a corresponding 169 SIP NOTIFY request. An Authentication Service as described in the 170 SIP Identity [RFC4474] specification can be used to vouch for the 171 identity of the sender of the certificate by using the sender's proxy 172 domain certificate to sign the NOTIFY request. The Authentication 173 Service is vouching that the sender is allowed to populate the SIP 174 From header field value. The sender of the message is vouching that 175 this is an appropriate certificate for the user identified in the SIP 176 from header field value. The credential service can manage public 177 certificates as well as the user's private keys. Users can update 178 their credentials, as stored on the credential service, using a SIP 179 PUBLISH [RFC3903] request. The UA authenticates to the credential 180 service using a shared secret when a UA is updating a credential. 181 Typically the shared secret will be the same one that is used by the 182 UA to authenticate a REGISTER request with the Registrar for the 183 domain (usually with SIP Digest Authentication). 185 The following figure shows Bob publishing his credentials from one of 186 his User Agents (e.g. his laptop software client), retrieving his 187 credentials from another of his User Agents (e.g. his mobile phone), 188 and then Alice retrieving Bob's certificate and sending a message to 189 Bob. SIP 200-class responses are omitted from the diagram to make the 190 figure easier to understand. 192 example.com domain 193 ------------------ 194 Alice Proxy Auth Cred Bob1 Bob2 195 | | | | TLS Handshake | | 196 | [ Bob generates ] |<--------------------->| 197 | [ credentials and ] | PUBLISH (credential) | 198 | [ publishes them ] |<----------------------| 199 | | | | Digest Challenge | 200 | | | |---------------------->| 201 | | | | PUBLISH + Digest | 202 | | | |<----------------------| 203 | | | | | 204 | | | | time passes... | 205 | | | | | 206 | | | | TLS Handshake | 207 | [ Bob later gets ] |<---------------->| 208 | [ back his own ] | SUBSCRIBE | 209 | [ credentials ] | (credential) | 210 | [ at another ] |<-----------------| 211 | [ User Agent ] | SUBSCRIBE+Digest | 212 | | | |<-----------------| 213 | | | | NOTIFY | 214 | | | |----------------->| 215 | | | | Bob Decrypts key | 216 | | | | | 217 | | | | | 218 | SUBSCRIBE (certificate) | Alice fetches | 219 |---------->|----->|----->| Bob's cert | 220 | | |NOTIFY| | 221 | NOTIFY+Identity |<-----| | 222 |<----------+------| | Alice uses cert | 223 | | | | to encrypt | 224 | MESSAGE | | | message to Bob | 225 |---------->|------+------+----------------->| 227 Bob's UA (Bob2) does a TLS [RFC5246] handshake with the credential 228 server to authenticate that the UA is connected to the correct 229 credential server. Then Bob's UA publishes his newly created or 230 updated credentials. The credential server digest challenges the UA 231 to authenticate that the UA knows Bob's shared secret. Once the UA 232 is authenticated, the credential server stores Bob's credentials. 234 Another of Bob's User Agents (Bob1) wants to fetch its current 235 credentials. It does a TLS [RFC5246] handshake with the credential 236 server to authenticate that the UA is connected to the correct 237 credential server. Then Bob's UA subscribes for the credentials. 238 The credential server digest challenges the UA to authenticate that 239 the UA knows Bob's shared secret. Once the UA is authenticated, the 240 credential server sends a NOTIFY that contains Bob's credentials. 241 The private key portion of the credential may have been encrypted 242 with a secret that only Bob's UA (and not the credential server) 243 knows. In this case, once Bob's UA decrypts the private key it will 244 be ready to go. Typically Bob's UA would do this when it first 245 registered on the network. 247 Some time later Alice decides that she wishes to discover Bob's 248 certificate so that she can send him an encrypted message or so that 249 she can verify the signature on a message from Bob. Alice's UA sends 250 a SUBSCRIBE message to Bob's AOR. The proxy in Bob's domain routes 251 this to the credential server via an "authentication service" as 252 defined in [RFC4474]. The credential server returns a NOTIFY that 253 contains Bob's public certificate in the body. This is routed 254 through an authentication service that signs that this message really 255 can validly claim to be from the AOR "sip:bob@example.com". Alice's 256 UA receives the certificate and can use it to encrypt a message to 257 Bob. 259 It is critical to understand that the only way that Alice can trust 260 that the certificate really is the one for Bob and that the NOTIFY 261 has not been spoofed is for Alice to check that the Identity 262 [RFC4474] header field value is correct. 264 The mechanism described in this document works for both self signed 265 certificates and certificates signed by well known certificate 266 authorities. In order to deploy certificates signed by well known 267 certificate authorities, certificate authorities would have to 268 support adding SIP URIs to the subjectAltName of the certificates 269 they generate. This is something which has been rarely implemented 270 by commercial certificate authorities. However, most UAs would only 271 use self signed certificates and would use an Authentication Service 272 as described in [RFC4474] to provide a strong binding of an AOR to 273 the certificates. 275 The mechanisms described in this draft allow for three different 276 styles of deployment: 278 1. Deployments where the credential server only stores certificates 279 and does not store any private key information. If the 280 deployment had users with multiple devices, some other scheme 281 (perhaps even manual provisioning) would be used to get the right 282 private keys onto all the devices that a user uses. 283 2. Deployments where the credential server stores certificates and 284 also stores an encrypted version of the private keys. The 285 credential server would not know or need the password phrase for 286 decrypting the private key. The credential server would help 287 move the private keys between devices but the user would need to 288 enter a password phrase on each device to allow that device to 289 decrypt (and encrypt) the private key information. 290 3. Deployments where the credential server generates and stores the 291 certificates and private keys. Deployments such as these may not 292 use password phrases. Consequently, the private keys are not 293 encrypted inside the PKCS#8 objects. This style of deployment 294 would often have the credential server, instead of the devices, 295 create the credentials. 297 4. UA Behavior with Certificates 299 When a User Agent wishes to discover some other user's certificate it 300 subscribes to the "certificate" SIP event package as described in 301 Section 6 to get the certificate. While the subscription is active, 302 if the certificate is updated, the Subscriber will receive the 303 updated certificate in a notification. 305 The Subscriber needs to decide how long it is willing to trust that 306 the certificate it receives is still valid. If the certificate is 307 revoked before it expires, the Notifier will send a notification with 308 an empty body to indicate that the certificate is no longer valid. 309 If the certificate is renewed before it expires, the Notifier will 310 send a notification with a body containing the new certificate. Note 311 that the Subscriber might not receive the notification if an attacker 312 blocks this traffic. The amount of time that the Subscriber caches a 313 certificate SHOULD be configurable. A default of one day is 314 RECOMMENDED. 316 Note that the actual duration of the subscription is unrelated to the 317 caching time or validity time of the corresponding certificate. 318 Allowing subscriptions to persist after a certificate is no longer 319 valid ensures that Subscribers receive the replacement certificate in 320 a timely fashion. The Notifier could return an immediate 321 notification with the certificate in response to subscribe and then 322 immediately terminate subscription, setting the reason parameter to 323 "probation". The Subscriber will have to periodically poll the 324 Notifier to verify validity of the certificate. 326 If the UA uses a cached certificate in a request and receives a 437 327 (Unsupported Certificate) response, it SHOULD remove the certificate 328 it used from the cache, attempt to fetch the certificate again. If 329 the certificate is changed, then the UA SHOULD retry the original 330 request again with the new certificate. This situation usually 331 indicates that the certificate was recently updated, and that the 332 Subscriber has not received a corresponding notification. If the 333 certificate fetched is the same as the one that was previously in the 334 cache, then the UA SHOULD NOT try the request again. This situation 335 can happened when the request was retargeted to a different user than 336 the original request. The 437 response is defined in [RFC4474]. 338 Note: A UA that has a presence list MAY want to subscribe to the 339 certificates of all the presentities in the list when the UA 340 subscribes to their presence, so that when the user wishes to 341 contact a presentity, the UA will already have the appropriate 342 certificate. Future specifications might consider the possibility 343 of retrieving the certificates along with the presence documents. 345 The details of how a UA deals with receiving encrypted messages is 346 outside the scope of this specification. It is worth noting that if 347 Charlie's UAS receives a request that is encrypted to Bob, it would 348 be valid and legal for that UA to send a 302 redirecting the call to 349 Bob. 351 5. UA Behavior with Credentials 353 UAs discover their own credentials by subscribing to their AOR with 354 an event type of credential as described in Section 7. After a UA 355 registers, it SHOULD retrieve its credentials by subscribing to them 356 as described in Section 6.6. 358 When a UA discovers its credential, the private key information might 359 be encrypted with a password phrase. The UA SHOULD request that the 360 user enter the password phrase on the device, and the UA MAY cache 361 this password phrase for future use. 363 There are several different cases in which a UA should generate a new 364 credential: 365 o If the UA receives a NOTIFY with no body for the credential 366 package. 367 o If the certificate has expired. 368 o If the certificate's notAfter date is within the next 600 seconds, 369 the UA SHOULD attempt to create replacement credentials. The UA 370 does this by waiting a random amount of time between 0 and 300 371 seconds. If no new credentials have been received in that time, 372 the UA creates new credentials to replace the expiring ones and 373 sends them in a PUBLISH request (with a SIP-If-Match header field 374 set to the current etag). This makes credential collisions both 375 unlikely and harmless. 376 o If the user of the device has indicated via the user interface 377 that they wish to revoke the current certificate and issue a new 378 one. 379 Credentials are created by creating a new key pair which will require 380 appropriate randomness, and then creating a certificate as described 381 in Section 9.6. The UA MAY encrypt the private key with a password 382 phrase supplied by the user. Next, the UA updates the user's 383 credential by sending a PUBLISH [RFC3903] request with the 384 credentials or just the certificate as described in Section 7.9. 386 If a UA wishes to revoke the existing certificate without publishing 387 a new one, it MUST send a PUBLISH with an empty body to the 388 credential server. 390 6. Event Package Formal Definition for "certificate" 392 6.1. Event Package Name 394 This document defines a SIP Event Package as defined in [RFC3265]. 395 The event-package token name for this package is: 397 certificate 399 6.2. Event Package Parameters 401 This package defines the "etag" Event header parameter which is valid 402 only in NOTIFY requests. It contains a token which represents the 403 SIP etag value at the time the notification was sent. Considering 404 how infrequently credentials are updated, this hint is very likely to 405 be the correct etag to use in the SIP-If-Match header in a SIP 406 PUBLISH request to update the current credentials. 408 etag-param = "etag" EQUAL token 410 6.3. SUBSCRIBE Bodies 412 This package does not define any SUBSCRIBE bodies. 414 6.4. Subscription Duration 416 Subscriptions to this event package can range from no time to weeks. 417 Subscriptions in days are more typical and are RECOMMENDED. The 418 default subscription duration for this event package is one day. 420 The credential service is encouraged to keep the subscriptions active 421 for AORs that are communicating frequently, but the credential 422 service MAY terminate the subscription at any point in time. 424 6.5. NOTIFY Bodies 426 The body of a NOTIFY request for this package MUST either be empty or 427 contain an application/pkix-cert body (as defined in [RFC2585]) that 428 contains the certificate, unless an Accept header field has 429 negotiated some other type. The Content-Disposition MUST be set to 430 "signal" as defined in [RFC3204]. 432 A future extension MAY define other NOTIFY bodies. If no "Accept" 433 header field is present in the SUBSCRIBE, the body type defined in 434 this document MUST be assumed. 436 Implementations which generate large notifications are reminded to 437 follow the message size restrictions for unreliable transports 438 articulated in Section 18.1.1 of SIP. 440 6.6. Subscriber Generation of SUBSCRIBE Requests 442 A UA discovers a certificate by sending a SUBSCRIBE request with an 443 event type of "certificate" to the AOR for which a certificate is 444 desired. In general, the UA stays subscribed to the certificate for 445 as long as it plans to use and cache the certificate, so that the UA 446 can be notified about changes or revocations to the certificate. 448 Subscriber User Agents will typically subscribe to certificate 449 information for a period of hours or days, and automatically attempt 450 to re-subscribe just before the subscription is completely expired. 452 When a user de-registers from a device (logoff, power down of a 453 mobile device, etc.), subscribers SHOULD unsubscribe by sending a 454 SUBSCRIBE request with an Expires header field of zero. 456 6.7. Notifier Processing of SUBSCRIBE Requests 458 When a SIP credential server receives a SUBSCRIBE request with the 459 certificate event-type, it is not necessary to authenticate the 460 subscription request. The Notifier MAY limit the duration of the 461 subscription to an administrator-defined period of time. The 462 duration of the subscription does not correspond in any way to the 463 period for which the certificate will be valid. 465 When the credential server receives a SUBSCRIBE request for a 466 certificate, it first checks to see if it has credentials for the 467 requested URI. If it does not have a certificate, it returns a 468 NOTIFY request with an empty message body. 470 6.8. Notifier Generation of NOTIFY Requests 472 Immediately after a subscription is accepted, the Notifier MUST send 473 a NOTIFY with the current certificate, or an empty body if no 474 certificate is available for the target user. In either case it 475 forms a NOTIFY with the From header field value set to the value of 476 the To header field in the SUBSCRIBE request. This server sending 477 the NOTIFY needs either to implement an Authentication Service (as 478 described in SIP Identity [RFC4474]) or else the server needs to be 479 set up such that the NOTIFY request will be sent through an 480 Authentication Service. Sending the NOTIFY request through the 481 Authentication Service requires the SUBSCRIBE request to have been 482 routed through the Authentication Service, since the NOTIFY is sent 483 within the dialog formed by the subscription. 485 6.9. Subscriber Processing of NOTIFY Requests 487 The resulting NOTIFY will contain an application/pkix-cert body that 488 contains the requested certificate. The UA MUST follow the 489 procedures in Section 9.3 to decide if the received certificate can 490 be used. The UA needs to cache this certificate for future use. The 491 maximum length of time it should be cached for is discussed in 492 Section 9.1. The certificate MUST be removed from the cache if the 493 certificate has been revoked (if a NOTIFY with an empty body is 494 received), or if it is updated by a subsequent NOTIFY. The UA MUST 495 check that the NOTIFY is correctly signed by an Authentication 496 Service as described in [RFC4474]. If the identity asserted by the 497 Authentication Service does not match the AOR that the UA subscribed 498 to, the certificate in the NOTIFY is discarded and MUST NOT be used. 500 6.10. Handling of Forked Requests 502 This event package does not permit forked requests. At most one 503 subscription to this event type is permitted per resource. 505 6.11. Rate of Notifications 507 Notifiers SHOULD NOT generate NOTIFY requests more frequently than 508 once per minute. 510 6.12. State Agents and Lists 512 The certificate server described in this section which serves 513 certificates is a state agent and implementations of the certificate 514 server MUST be implemented as a state agent. 516 Implementers MUST NOT use the event list extension [RFC4662] with 517 this event type. It is not possible to make such an approach work, 518 because the Authentication service would have to simultaneously 519 assert several different identities. 521 6.13. Behavior of a Proxy Server 523 There are no additional requirements on a SIP Proxy, other than to 524 transparently forward the SUBSCRIBE and NOTIFY requests as required 525 in SIP. This specification describes the Proxy, Authentication 526 service, and credential service as three separate services, but it is 527 certainly possible to build a single SIP network element that 528 performs all of these services at the same time. 530 7. Event Package Formal Definition for "credential" 532 7.1. Event Package Name 534 This document defines a SIP Event Package as defined in [RFC3265]. 535 The event-package token name for this package is: 537 credential 539 7.2. Event Package Parameters 541 This package defines the "etag" Event header parameter which is valid 542 only in NOTIFY requests. It contains a token which represents the 543 SIP etag value at the time the notification was sent. Considering 544 how infrequently credentials are updated, this hint is very likely to 545 be the correct etag to use in the SIP-If-Match header field in a SIP 546 PUBLISH request to update the current credentials. 548 etag-param = "etag" EQUAL token 550 7.3. SUBSCRIBE Bodies 552 This package does not define any SUBSCRIBE bodies. 554 7.4. Subscription Duration 556 Subscriptions to this event package can range from hours to one week. 557 Subscriptions in days are more typical and are RECOMMENDED. The 558 default subscription duration for this event package is one day. 560 The credential service SHOULD keep subscriptions active for UAs that 561 are currently registered. 563 7.5. NOTIFY Bodies 565 The NOTIFY MUST contain a multipart/mixed (see [RFC2046]) body that 566 contains both an application/pkix-cert body with the certificate and 567 an application/pkcs8 body that has the associated private key 568 information for the certificate. The Content-Disposition MUST be set 569 to "signal" as defined in [RFC3204]. 571 A future extension MAY define other NOTIFY bodies. If no "Accept" 572 header field is present in the SUBSCRIBE, the body type defined in 573 this document MUST be assumed. 575 The application/pkix-cert body is a DER encoded X.509v3 certificate 576 [RFC2585]. The application/pkcs8 body contains a DER-encoded 577 [RFC5208] object that contains the private key. The PKCS#8 objects 578 MUST be of type PrivateKeyInfo. The integrity and confidentiality of 579 the PKCS#8 objects is provided by the TLS transport. The transport 580 encoding of all the MIME bodies is binary. 582 7.6. Subscriber Generation of SUBSCRIBE Requests 584 A Subscriber User Agent will subscribe to its credential information 585 for a period of hours or days and will automatically attempt to re- 586 subscribe before the subscription has completely expired. 588 The Subscriber SHOULD subscribe to its credentials whenever a new 589 user becomes associated with the device (a new login). The 590 subscriber SHOULD also renew its subscription immediately after a 591 reboot, or when the subscriber's network connectivity has just been 592 re-established. 594 The UA needs to authenticate with the credential service for these 595 operations. The UA MUST use TLS to directly connect to the server 596 acting as the credential service or to a server that is authoritative 597 for the domain of the credential service. The UA MUST NOT connect 598 through an intermediate proxy to the credential service. The UA may 599 be configured with a specific name for the credential service; 600 otherwise normal SIP routing is used. As described in RFC 3261, the 601 TLS connection needs to present a certificate that matches the 602 expected name of the server to which the connection was formed, so 603 that the UA knows it is talking to the correct server. Failing to do 604 this may result in the UA publishing its private key information to 605 an attacker. The credential service will authenticate the UA using 606 the usual SIP Digest mechanism, so the UA can expect to receive a SIP 607 challenge to the SUBSCRIBE or PUBLISH requests. 609 7.7. Notifier Processing of SUBSCRIBE Requests 611 When a credential service receives a SUBSCRIBE for a credential, the 612 credential service has to authenticate and authorize the UA and 613 validate that adequate transport security is being used. Only a UA 614 that can authenticate as being able to register as the AOR is 615 authorized to receive the credentials for that AOR. The credential 616 Service MUST digest challenge the UA to authenticate the UA and then 617 decide if it is authorized to receive the credentials. If 618 authentication is successful, the Notifier MAY limit the duration of 619 the subscription to an administrator-defined period of time. The 620 duration of the subscription MUST NOT be larger than the length of 621 time for which the certificate is still valid. The Expires header 622 field SHOULD be set so that it is not longer than the notAfter date 623 in the certificate. 625 7.8. Notifier Generation of NOTIFY Requests 627 Once the UA has authenticated with the credential service and the 628 subscription is accepted, the credential service MUST immediately 629 send a Notify request. The Notifier SHOULD include the current etag 630 value in the "etag" Event package parameter in the NOTIFY request. 631 The Authentication Service is applied to this NOTIFY request in the 632 same way as the certificate subscriptions. If the credential is 633 revoked, the credential service MUST terminate any current 634 subscriptions and force the UA to re-authenticate by sending a NOTIFY 635 with its Subscription-State header field set to "terminated" and a 636 reason parameter of "deactivated". (This causes a Subscriber to 637 retry the subscription immediately.) This is so that if a secret for 638 retrieving the credentials gets compromised, the rogue UA will not 639 continue to receive credentials after the compromised secret has been 640 changed. 642 Any time the credentials for this URI change, the credential service 643 MUST send a new NOTIFY to any active subscriptions with the new 644 credentials. 646 The notification MUST be sent over TLS so that it is integrity 647 protected and the TLS needs to be directly connected between the UA 648 and the credential service with no intermediaries. 650 7.9. Generation of PUBLISH Requests 652 A user agent SHOULD be configurable to control whether it publishes 653 the credential for a user or just the user's certificate. 655 When publishing just a certificate, the body contains an application/ 656 pkix-cert. When publishing a credential, the body contains a 657 multipart/mixed containing both an application/pkix-cert and an 658 application/pkcs8 body. 660 When the UA sends the PUBLISH [RFC3903] request, it needs to do the 661 following: 662 o The UA MUST use TLS to directly connect to the server acting as 663 the credential service or to a server that is authoritative for 664 the domain of the credential service. The UA MUST NOT connect 665 through an intermediate proxy to the credential service. 667 o The Expires header field value in the PUBLISH request SHOULD be 668 set to match the time for which the certificate is valid. 669 o If the certificate includes Basic Constraints, it SHOULD set the 670 CA flag to false. 672 7.10. Notifier Processing of PUBLISH Requests 674 When the credential service receives a PUBLISH to update credentials, 675 it MUST authenticate and authorize this request the same way as for 676 subscriptions for credentials. If the authorization succeeds, then 677 the credential service MUST perform the following check on the 678 certificate: 679 o One of the names in the SubjectAltName of the certificate matches 680 the authorized user making the request. 681 o The notBefore validity time MUST NOT be in the future. 682 o The notAfter validity time MUST be in the future. 683 o If a CA Basic Constraint is set in the certificate, it is set to 684 false. 685 If all of these succeed, the credential service updates the 686 credential for this URI, processes all the active certificates and 687 credential subscriptions to this URI, and generates a NOTIFY request 688 with the new credential or certificate. 690 If the Subscriber submits a PUBLISH request with no body, this 691 revokes the current credentials and causes all subscriptions to the 692 credential package to be deactivated as described in the previous 693 section. (Note that subscriptions to the certificate package are NOT 694 terminated; each subscriber to the certificate package receives a 695 notification with an empty body.) 697 7.11. Subscriber Processing of NOTIFY Requests 699 When the UA receives a valid NOTIFY request, it should replace its 700 existing credentials with the new received ones. If the UA cannot 701 decrypt the PKCS#8 object, it MUST send a 437 (Unsupported 702 Certificate) response. Later if the user provides a new password 703 phrase for the private key, the UA can subscribe to the credentials 704 again and attempt to decrypt with the new password phrase. 706 7.12. Handling of Forked Requests 708 This event package does not permit forked requests. 710 7.13. Rate of Notifications 712 Notifiers SHOULD NOT generate NOTIFY requests more frequently than 713 once per minute. 715 7.14. State Agents and Lists 717 The credential server described in this section which serves 718 credentials is a state agent and implementations of the credential 719 server MUST be implemented as a state agent. 721 Implementers MUST NOT use the event list extension [RFC4662] with 722 this event type. 724 7.15. Behavior of a Proxy Server 726 The behavior is identical to behavior described for certificate 727 subscriptions described in Section 6.13. 729 8. Examples 731 In all these examples, large parts of the messages are omitted to 732 highlight what is relevant to this draft. The lines in the examples 733 that are prefixed by $ represent encrypted blocks of data. 735 8.1. Encrypted Page Mode IM Message 737 In this example, Alice sends Bob an encrypted page mode instant 738 message. Alice does not already have Bob's public key from previous 739 communications, so she fetches Bob's public key from Bob's credential 740 service: 742 SUBSCRIBE sip:bob@biloxi.example.com SIP/2.0 743 ... 744 Event: certificate 746 The credential service responds with the certificate in a NOTIFY. 748 NOTIFY alice@atlanta.example.com SIP/2.0 749 Subscription-State: active; expires=7200 750 .... 751 From: ;tag=1234 752 Identity: "NJguAbpmYXjnlxFmlOkumMI+MZXjB2iV/NW5xsFQqzD/p4yiovrJBqhd3T 753 ZkegnsmoHryzk9gTBH7Gj/erixEFIf82o3Anmb+CIbrgdl03gGaD6ICvkp 754 VqoMXZZjdvSpycyHOhh1cmUx3b9Vr3pZuEh+cB01pbMQ8B1ch++iMjw=" 755 Identity-Info: ;alg=rsa-sha1 756 .... 757 Event: certificate 758 Content-Type: application/pkix-cert 759 Content-Disposition: signal 761 < certificate data > 762 Next, Alice sends a SIP MESSAGE message to Bob and can encrypt the 763 body using Bob's public key as shown below. 765 MESSAGE sip:bob@biloxi.example.com SIP/2.0 766 ... 767 Content-Type: application/pkcs7-mime 768 Content-Disposition: render 770 $ Content-Type: text/plain 771 $ 772 $ < encrypted version of "Hello" > 774 8.2. Setting and Retrieving UA Credentials 776 When Alice's UA wishes to publish Alice's public and private keys to 777 the credential service, it sends a PUBLISH request like the one 778 below. This must be sent over a TLS connection directly to the 779 domain of the credential service. The credential service presents a 780 certificate where the subjectAltName contains an entry that matches 781 the domain name in the request line of the PUBLISH request and digest 782 challenges the request to authenticate her. 784 PUBLISH sips:alice@atlanta.example.com SIP/2.0 785 ... 786 Event: credential 787 Content-Type: multipart/mixed;boundary=boundary 788 Content-Disposition: signal 790 --boundary 791 Content-ID: 123 792 Content-Type: application/pkix-cert 794 < Public certificate for Alice > 795 --boundary 796 Content-ID: 456 797 Content-Type: application/pkcs8 799 < Private Key for Alice > 800 --boundary 802 If one of Alice's UAs subscribes to the credential event, the UA will 803 be digest challenged, and the NOTIFY will include a body similar to 804 the one in the PUBLISH section above. 806 9. Security Considerations 808 The high level message flow from a security point of view is 809 summarized in the following figure. The 200 responses are removed 810 from the figure as they do not have much to do with the overall 811 security. 813 In this figure, authC refers to authentication and authZ refers to 814 authorization. 816 Alice Server Bob UA 817 | | TLS Handshake | 1) Client authC/Z server 818 | |<---------------->| 819 | | PUBLISH | 2) Client sends request 820 | |<-----------------| (write credential) 821 | | Digest Challenge | 3) Server challenges client 822 | |----------------->| 823 | | PUBLISH + Digest | 4) Server authC/Z client 824 | |<-----------------| 825 | | time... | 826 | | | 827 | | TLS Handshake | 5) Client authC/Z server 828 | |<---------------->| 829 | | SUBSCRIBE | 6) Client sends request 830 | |<-----------------| (read credential) 831 | | Digest Challenge | 7) Server challenges client 832 | |----------------->| 833 | | SUBSCRIBE+Digest | 8) Server authC/Z client 834 | |<-----------------| 835 | | NOTIFY | 9) Server returns credential 836 | |----------------->| 837 | | 838 | SUBSCRIBE | 10) Client requests certificate 839 |---------->| 840 | | 841 |NOTIFY+AUTH| 11) Server returns user's certificate and signs that 842 |<----------| it is valid using certificate for the domain 843 | | 845 When the UA, labeled Bob, first created a credential for Bob, it 846 would store this on the credential server. The UA authenticated the 847 Server using the certificates from the TLS handshake. The Server 848 authenticated the UA using a digest style challenge with a shared 849 secret. 851 The UA, labeled Bob, wishes to request its credentials from the 852 server. First it forms a TLS connection to the Server, which 853 provides integrity and privacy protection and also authenticates the 854 server to Bob's UA. Next the UA requests its credentials using a 855 SUBSCRIBE request. The Server digest challenges this to authenticate 856 Bob's UA. The server and Bob's UA have a shared secret that is used 857 for this. If the authentication is successful, the server sends the 858 credentials to Bob's UA. The private key in the credentials may have 859 been encrypted using a shared secret that the server does not know. 861 A similar process would be used for Bob's UA to publish new 862 credentials to the server. Bob's UA would send a PUBLISH request 863 containing the new credentials. When this happened, all the other 864 UAs that were subscribed to Bob's credentials would receive a NOTIFY 865 with the new credentials. 867 Alice wishes to find Bob's certificate and sends a SUBSCRIBE to the 868 server. The server sends the response in a NOTIFY. This does not 869 need to be sent over a privacy or integrity protected channel, as the 870 Authentication service described in [RFC4474] provides integrity 871 protection of this information and signs it with the certificate for 872 the domain. 874 This whole scheme is highly dependent on trusting the operators of 875 the credential service and trusting that the credential service will 876 not be compromised. The security of all the users will be 877 compromised if the credential service is compromised. 879 Note: There has been significant discussion of the topic of 880 avoiding deployments in which the credential servers store the 881 private keys, even in some encrypted form that the credential 882 server does not know how to decrypt. Various schemes were 883 considered to avoid this but they all result in either moving the 884 problem to some other server, which does not seem to make the 885 problem any better, or having a different credential for each 886 device. For some deployments where each user has only one device 887 this is fine but for deployments with multiple devices, it would 888 require that when Alice went to contact Bob, Alice would have to 889 provide messages encrypted for all of Bob's devices. The sipping 890 working group did consider this architecture and decided it was 891 not appropriate due both to the information it revealed about the 892 devices and users and the amount of signaling required to make it 893 work. 895 This specification requires that TLS be used for the SIP 896 communications to place and retrieve a UA's private key. This 897 provides security in two ways: 898 1. Confidentiality is provided for the digest authentication 899 exchange, thus protecting it from dictionary attacks. 901 2. Confidentiality is provided for the private key, thus protecting 902 it from being exposed to passive attackers. 903 In order to prevent man-in-the-middle attacks, TLS clients MUST check 904 that the SubjectAltName of the certificate for the server they 905 connected to exactly matches the server they were trying to connect 906 to. The connection must be directly connected to the correct server 907 or any intermediaries in the TLS path can compromise the certificate 908 and instead provide a certificate for which the attacker knows the 909 private key. This may lead the UA that relies on this compromised 910 certificate to lose confidential information. Failing to use TLS or 911 selecting a poor cipher suite (such as NULL encryption) may result in 912 credentials, including private keys, being sent unencrypted over the 913 network and will render the whole system useless. 915 The correct checking of chained certificates as specified in TLS 916 [RFC5246] is critical for the client to authenticate the server. If 917 the client does not authenticate that it is talking to the correct 918 credential service, a man in the middle attack is possible. 920 9.1. Certificate Revocation 922 If a particular credential needs to be revoked, the new credential is 923 simply published to the credential service. Every device with a copy 924 of the old credential or certificate in its cache will have a 925 subscription and will rapidly (order of seconds) be notified and 926 replace its cache. Clients that are not subscribed will subscribe 927 when they next need to use the certificate and will get the new 928 certificate. 930 It is possible that an attacker could mount a DOS attack such that 931 the UA that had cached a certificate did not receive the NOTIFY with 932 its revocation. To protect against this attack, the UA needs to 933 limit how long it caches certificates. After this time, the UA would 934 invalidate the cached information even though no NOTIFY had ever been 935 received due to the attacker blocking it. 937 The duration of this cached information is in some ways similar to a 938 device deciding how often to check a CRL list. For many 939 applications, a default time of 1 day is suggested, but for some 940 applications it may be desirable to set the time to zero so that no 941 certificates are cached at all and the credential is checked for 942 validity every time the certificate is used. 944 The UA MUST NOT cache the certificates for a period longer than that 945 of the subscription duration. This is to avoid the UA using invalid 946 cached credentials when the notifier of the new credentials has been 947 prevented from updating the UA. 949 9.2. Certificate Replacement 951 The UAs in the system replace the certificates close to the time that 952 the certificates would expire. If a UA has used the same key pair to 953 encrypt a very large volume of traffic, the UA MAY choose to replace 954 the credential with a new one before the normal expiration. 956 9.3. Trusting the Identity of a Certificate 958 When a UA wishes to discover the certificate for 959 sip:alice@example.com, the UA subscribes to the certificate for 960 alice@example.com and receives a certificate in the body of a SIP 961 NOTIFY request. The term original URI is used to describe the URI 962 that was in the To header field value of the SUBSCRIBE request. So 963 in this case the original URI would be sip:alice@example.com. 965 If the certificate is signed by a trusted CA, and one of the names in 966 the SubjectAltName matches the original URI, then this certificate 967 MAY be used but only for exactly the original URI and not for other 968 identities found in the SubjectAltName. Otherwise, there are several 969 steps the UA MUST perform before using this certificate. 970 o The From header field in the NOTIFY request MUST match the 971 original URI that was subscribed to. 972 o The UA MUST check the Identity header field as described in the 973 Identity [RFC4474] specification to validate that bodies have not 974 been tampered with and that an Authentication Service has 975 validated this From header field. 976 o The UA MUST check the validity time of the certificate and stop 977 using the certificate if it is invalid. (Implementations are 978 reminded to verify both the notBefore and notAfter validity 979 times.) 980 o The certificate MAY have several names in the SubjectAltName but 981 the UA MUST only use this certificate when it needs the 982 certificate for the identity asserted by the Authentication 983 Service in the NOTIFY. This means that the certificate should 984 only be indexed in the certificate cache by the AOR that the 985 Authentication Service asserted and not by the value of all the 986 identities found in the SubjectAltName list. 987 These steps result in a chain of bindings that result in a trusted 988 binding between the original AOR that was subscribed to and a public 989 key. The original AOR is forced to match the From. The 990 Authentication Service validates that this request did come from the 991 identity claimed in the From header field value and that the bodies 992 in the request that carry the certificate have not been tampered 993 with. The certificate in the body contains the public key for the 994 identity. Only the UA that can authenticate as this AOR, or devices 995 with access to the private key of the domain, can tamper with this 996 body. This stops other users from being able to provide a false 997 public key. This chain of assertion from original URI, to From, to 998 body, to public key is critical to the security of the mechanism 999 described in this specification. If any of the steps above are not 1000 followed, this chain of security will be broken and the system will 1001 not work. 1003 9.4. SACRED Framework 1005 This specification includes a mechanism that allows end users to 1006 share the same credentials across different end-user devices. This 1007 mechanism is based on the one presented in the SACRED Framework 1008 [RFC3760]. While this mechanism is fully described in this document, 1009 the requirements and background are more thoroughly discussed in 1010 [RFC3760]. 1012 Specifically, Section 7.6, Section 7.7 and Section 7.10 follow the 1013 cTLS architecture described in section 4.2.2 of [RFC3760]. The 1014 client authenticates the server using the server's TLS certificate. 1015 The server authenticates the client using a SIP digest transaction 1016 inside the TLS session. The TLS sessions form a strong session key 1017 that is used to protect the credentials being exchanged. 1019 9.5. Crypto Profiles 1021 Credential services SHOULD implement the server name indication 1022 extensions in [RFC5246] and they MUST support a TLS profile of 1023 TLS_RSA_WITH_AES_128_CBC_SHA as described in [RFC5246] as a profile 1024 of TLS_RSA_WITH_3DES_EDE_CBC_SHA. 1026 The PKCS#8 in the clients MUST implement PBES2 with a key derivation 1027 algorithm of PBKDF2 using HMAC with SHA1 and an encryption algorithm 1028 of DES-EDE2-CBC-Pad as defined in [RFC2898]. It is RECOMMENDED that 1029 this profile be used when using PKCS#8. A different passphrase 1030 SHOULD be used for the PKCS#8 encryption than is used for server 1031 authentication. 1033 9.6. User Certificate Generation 1035 The certificates should be consistent with [RFC5280]. A 1036 signatureAlgorithm of sha1WithRSAEncryption MUST be implemented. The 1037 Issuers SHOULD be the same as the subject. Given the ease of issuing 1038 new certificates with this system, the Validity can be relatively 1039 short. A Validity of one year or less is RECOMMENDED. The 1040 subjectAltName must have a URI type that is set to the SIP URL 1041 corresponding to the user AOR. It MAY be desirable to put some 1042 randomness into the length of time for which the certificates are 1043 valid so that it does not become necessary to renew all the 1044 certificates in the system at the same time. 1046 It is worth noting that a UA can discover the current time by looking 1047 at the Date header field value in the 200 response to a REGISTER 1048 request. 1050 9.7. Compromised Authentication Service 1052 One of this worst attacks against this system would be if the 1053 Authentication Service were compromised. This attack is somewhat 1054 analogous to a CA being compromised in traditional PKI systems. The 1055 attacker could make a fake certificate for which it knows the private 1056 key, use it to receive any traffic for a given use, and then re- 1057 encrypt that traffic with the correct key and forward the 1058 communication to the intended receiver. The attacker would thus 1059 become a man in the middle in the communications. 1061 There is not too much that can be done to protect against this. A UA 1062 MAY subscribe to its own certificate under some other identity to try 1063 to detect whether the credential server is handing out the correct 1064 certificates. It will be difficult to do this in a way that does not 1065 allow the credential server to recognize the user's UA. 1067 The UA MAY also save the fingerprints of the cached certificates and 1068 warn users when the certificates change significantly before their 1069 expiry date. 1071 The UA MAY also allow the user to see the fingerprints for the cached 1072 certificates so that they can be verified by some other out of band 1073 means. 1075 10. IANA Considerations 1077 This specification defines two new event packages that IANA is 1078 requested to add the registry at: 1079 http://www.iana.org/assignments/sip-events 1080 It also defines a new mime type that IANA is requested to add to the 1081 registry at: 1082 http://www.iana.org/assignments/media-types/application 1084 10.1. Certificate Event Package 1086 To: ietf-sip-events@iana.org 1087 Subject: Registration of new SIP event package 1089 Package Name: certificate 1091 Is this registration for a Template Package: No 1093 Published Specification(s): This document 1095 New Event header parameters: This package defines no 1096 new parameters 1098 Person & email address to contact for further information: 1099 Cullen Jennings 1101 10.2. Credential Event Package 1103 To: ietf-sip-events@iana.org 1104 Subject: Registration of new SIP event package 1106 Package Name: credential 1108 Is this registration for a Template Package: No 1110 Published Specification(s): This document 1112 New Event header parameters: "etag" 1114 Person & email address to contact for further information: 1115 Cullen Jennings 1117 10.3. PKCS#8 1119 To: ietf-types@iana.org 1120 Subject: Registration of MIME media type application/pkcs8 1122 MIME media type name: application 1124 MIME subtype name: pkcs8 1126 Required parameters: None 1128 Optional parameters: None 1130 Encoding considerations: binary 1132 Security considerations: Carries a cryptographic private key 1134 Interoperability considerations: 1135 The PKCS#8 object inside this MIME type MUST be DER-encoded 1137 Published specification: 1138 RSA Laboratories, "Private-Key Information Syntax Standard, 1139 Version 1.2", PKCS 8, November 1993. 1141 Applications which use this media type: Any MIME-compliant transport 1143 Additional information: 1144 Magic number(s): None 1145 File extension(s): .p8 1146 Macintosh File Type Code(s): none 1148 Person & email address to contact for further information: 1149 Cullen Jennings 1151 Intended usage: COMMON 1153 Author/Change controller: 1154 the IESG 1156 11. Acknowledgments 1158 Many thanks to Eric Rescorla, Jim Schaad, Rohan Mahy for significant 1159 help and discussion. Many others provided useful comments, including 1160 Kumiko Ono, Peter Gutmann, Russ Housley, Yaron Pdut, Aki Niemi, 1161 Magnus Nystrom, Paul Hoffman, Adina Simu, Dan Wing, Mike Hammer and 1162 Lyndsay Campbell. Rohan Mahy, John Elwell, and Jonathan Rosenberg 1163 provided detailed review and text. 1165 12. References 1167 12.1. Normative References 1169 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1170 Extensions (MIME) Part Two: Media Types", RFC 2046, 1171 November 1996. 1173 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1174 Requirement Levels", BCP 14, RFC 2119, March 1997. 1176 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 1177 Infrastructure Operational Protocols: FTP and HTTP", 1178 RFC 2585, May 1999. 1180 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 1181 Specification Version 2.0", RFC 2898, September 2000. 1183 [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, 1184 F., Watson, M., and M. Zonoun, "MIME media types for ISUP 1185 and QSIG Objects", RFC 3204, December 2001. 1187 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1188 A., Peterson, J., Sparks, R., Handley, M., and E. 1189 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1190 June 2002. 1192 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1193 Event Notification", RFC 3265, June 2002. 1195 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 1196 for Event State Publication", RFC 3903, October 2004. 1198 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1199 Authenticated Identity Management in the Session 1200 Initiation Protocol (SIP)", RFC 4474, August 2006. 1202 [RFC5208] Kaliski, B., "Public-Key Cryptography Standards (PKCS) #8: 1203 Private-Key Information Syntax Specification Version 1.2", 1204 RFC 5208, May 2008. 1206 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1207 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1209 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1210 Housley, R., and W. Polk, "Internet X.509 Public Key 1211 Infrastructure Certificate and Certificate Revocation List 1212 (CRL) Profile", RFC 5280, May 2008. 1214 12.2. Informational References 1216 [RFC3760] Gustafson, D., Just, M., and M. Nystrom, "Securely 1217 Available Credentials (SACRED) - Credential Server 1218 Framework", RFC 3760, April 2004. 1220 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 1221 Extensions (S/MIME) Version 3.1 Message Specification", 1222 RFC 3851, July 2004. 1224 [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) 1225 Requirement for the Session Initiation Protocol (SIP)", 1226 RFC 3853, July 2004. 1228 [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session 1229 Initiation Protocol (SIP) Event Notification Extension for 1230 Resource Lists", RFC 4662, August 2006. 1232 Authors' Addresses 1234 Cullen Jennings 1235 Cisco Systems 1236 170 West Tasman Drive 1237 MS: SJC-21/2 1238 San Jose, CA 95134 1239 USA 1241 Phone: +1 408 421-9990 1242 Email: fluffy@cisco.com 1244 Jason Fischl (editor) 1245 Skype 1246 2145 Hamilton Ave. 1247 San Jose, CA 95125 1248 USA 1250 Phone: +1-415-202-5192 1251 Email: jason.fischl@skypelabs.com