draft-ietf-sip-certs-07.txt   draft-ietf-sip-certs-08.txt 
Network Working Group C. Jennings Network Working Group C. Jennings
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: May 7, 2009 J. Fischl, Ed. Intended status: Standards Track J. Fischl, Ed.
CounterPath Corporation Expires: January 14, 2010 Skype
November 3, 2008 July 13, 2009
Certificate Management Service for The Session Initiation Protocol (SIP) Certificate Management Service for The Session Initiation Protocol (SIP)
draft-ietf-sip-certs-07 draft-ietf-sip-certs-08
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 7, 2009. This Internet-Draft will expire on January 14, 2010.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This draft defines a Credential Service that allows Session This draft defines a Credential Service that allows Session
Initiation Protocol (SIP) User Agents (UAs) to use a SIP event Initiation Protocol (SIP) User Agents (UAs) to use a SIP event
package to discover the certificates of other users. This mechanism package to discover the certificates of other users. This mechanism
allows user agents that want to contact a given Address-of-Record allows user agents that want to contact a given Address-of-Record
(AOR) to retrieve that AOR's certificate by subscribing to the (AOR) to retrieve that AOR's certificate by subscribing to the
Credential Service, which returns an authenticated response Credential Service, which returns an authenticated response
containing that certificate. The Credential Service also allows containing that certificate. The Credential Service also allows
skipping to change at page 2, line 39 skipping to change at page 2, line 44
7.2. Event Package Parameters . . . . . . . . . . . . . . . . . 13 7.2. Event Package Parameters . . . . . . . . . . . . . . . . . 13
7.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 13 7.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 13
7.4. Subscription Duration . . . . . . . . . . . . . . . . . . 13 7.4. Subscription Duration . . . . . . . . . . . . . . . . . . 13
7.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 13 7.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 13
7.6. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 14 7.6. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 14
7.7. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 14 7.7. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 14
7.8. Notifier Generation of NOTIFY Requests . . . . . . . . . . 15 7.8. Notifier Generation of NOTIFY Requests . . . . . . . . . . 15
7.9. Generation of PUBLISH Requests . . . . . . . . . . . . . . 15 7.9. Generation of PUBLISH Requests . . . . . . . . . . . . . . 15
7.10. Notifier Processing of PUBLISH Requests . . . . . . . . . 16 7.10. Notifier Processing of PUBLISH Requests . . . . . . . . . 16
7.11. Subscriber Processing of NOTIFY Requests . . . . . . . . . 16 7.11. Subscriber Processing of NOTIFY Requests . . . . . . . . . 16
7.12. Handling of Forked Requests . . . . . . . . . . . . . . . 17 7.12. Handling of Forked Requests . . . . . . . . . . . . . . . 16
7.13. Rate of Notifications . . . . . . . . . . . . . . . . . . 17 7.13. Rate of Notifications . . . . . . . . . . . . . . . . . . 16
7.14. State Agents and Lists . . . . . . . . . . . . . . . . . . 17 7.14. State Agents and Lists . . . . . . . . . . . . . . . . . . 17
7.15. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 17 7.15. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 17
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Encrypted Page Mode IM Message . . . . . . . . . . . . . . 17 8.1. Encrypted Page Mode IM Message . . . . . . . . . . . . . . 17
8.2. Setting and Retrieving UA Credentials . . . . . . . . . . 18 8.2. Setting and Retrieving UA Credentials . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9.1. Certificate Revocation . . . . . . . . . . . . . . . . . . 22 9.1. Certificate Revocation . . . . . . . . . . . . . . . . . . 21
9.2. Certificate Replacement . . . . . . . . . . . . . . . . . 22 9.2. Certificate Replacement . . . . . . . . . . . . . . . . . 22
9.3. Trusting the Identity of a Certificate . . . . . . . . . . 22 9.3. Trusting the Identity of a Certificate . . . . . . . . . . 22
9.4. SACRED Framework . . . . . . . . . . . . . . . . . . . . . 23 9.4. SACRED Framework . . . . . . . . . . . . . . . . . . . . . 23
9.5. Crypto Profiles . . . . . . . . . . . . . . . . . . . . . 24 9.5. Crypto Profiles . . . . . . . . . . . . . . . . . . . . . 23
9.6. User Certificate Generation . . . . . . . . . . . . . . . 24 9.6. User Certificate Generation . . . . . . . . . . . . . . . 23
9.7. Compromised Authentication Service . . . . . . . . . . . . 24 9.7. Compromised Authentication Service . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10.1. Certificate Event Package . . . . . . . . . . . . . . . . 25 10.1. Certificate Event Package . . . . . . . . . . . . . . . . 25
10.2. Credential Event Package . . . . . . . . . . . . . . . . . 25 10.2. Credential Event Package . . . . . . . . . . . . . . . . . 25
10.3. PKCS#8 . . . . . . . . . . . . . . . . . . . . . . . . . . 26 10.3. PKCS#8 . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . . 28 12.1. Normative References . . . . . . . . . . . . . . . . . . . 27
12.2. Informational References . . . . . . . . . . . . . . . . . 29 12.2. Informational References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 31
1. Introduction 1. Introduction
[RFC3261], as ammended by [RFC3853], provides a mechanism for end-to- [RFC3261], as ammended by [RFC3853], provides a mechanism for end-to-
end encryption and integrity using S/MIME [RFC3851]. Several end encryption and integrity using S/MIME [RFC3851]. Several
security properties of [RFC3261] depend on S/MIME, and yet it has not security properties of [RFC3261] depend on S/MIME, and yet it has not
been widely deployed. One reason is the complexity of providing a been widely deployed. One reason is the complexity of providing a
reasonable certificate distribution infrastructure. This reasonable certificate distribution infrastructure. This
specification proposes a way to address discovery, retrieval, and specification proposes a way to address discovery, retrieval, and
management of certificates for SIP deployments. Combined with the management of certificates for SIP deployments. Combined with the
skipping to change at page 6, line 40 skipping to change at page 6, line 40
| | | | | | | | | |
| SUBSCRIBE (certificate) | Alice fetches | | SUBSCRIBE (certificate) | Alice fetches |
|---------->|----->|----->| Bob's cert | |---------->|----->|----->| Bob's cert |
| | |NOTIFY| | | | |NOTIFY| |
| NOTIFY+Identity |<-----| | | NOTIFY+Identity |<-----| |
|<----------+------| | Alice uses cert | |<----------+------| | Alice uses cert |
| | | | to encrypt | | | | | to encrypt |
| MESSAGE | | | message to Bob | | MESSAGE | | | message to Bob |
|---------->|------+------+----------------->| |---------->|------+------+----------------->|
Bob's UA (Bob2) does a TLS [RFC4366] handshake with the credential Bob's UA (Bob2) does a TLS [RFC5246] handshake with the credential
server to authenticate that the UA is connected to the correct server to authenticate that the UA is connected to the correct
credential server. Then Bob's UA publishes his newly created or credential server. Then Bob's UA publishes his newly created or
updated credentials. The credential server digest challenges the UA updated credentials. The credential server digest challenges the UA
to authenticate that the UA knows Bob's shared secret. Once the UA to authenticate that the UA knows Bob's shared secret. Once the UA
is authenticated, the credential server stores Bob's credentials. is authenticated, the credential server stores Bob's credentials.
Another of Bob's User Agents (Bob1) wants to fetch its current Another of Bob's User Agents (Bob1) wants to fetch its current
credentials. It does a TLS [RFC4366] handshake with the credential credentials. It does a TLS [RFC5246] handshake with the credential
server to authenticate that the UA is connected to the correct server to authenticate that the UA is connected to the correct
credential server. Then Bob's UA subscribes for the credentials. credential server. Then Bob's UA subscribes for the credentials.
The credential server digest challenges the UA to authenticate that The credential server digest challenges the UA to authenticate that
the UA knows Bob's shared secret. Once the UA is authenticated, the the UA knows Bob's shared secret. Once the UA is authenticated, the
credential server sends a NOTIFY that contains Bob's credentials. credential server sends a NOTIFY that contains Bob's credentials.
The private key portion of the credential may have been encrypted The private key portion of the credential may have been encrypted
with a secret that only Bob's UA (and not the credential server) with a secret that only Bob's UA (and not the credential server)
knows. In this case, once Bob's UA decrypts the private key it will knows. In this case, once Bob's UA decrypts the private key it will
be ready to go. Typically Bob's UA would do this when it first be ready to go. Typically Bob's UA would do this when it first
registered on the network. registered on the network.
skipping to change at page 8, line 6 skipping to change at page 8, line 6
deployment had users with multiple devices, some other scheme deployment had users with multiple devices, some other scheme
(perhaps even manual provisioning) would be used to get the right (perhaps even manual provisioning) would be used to get the right
private keys onto all the devices that a user uses. private keys onto all the devices that a user uses.
2. Deployments where the credential server stores certificates and 2. Deployments where the credential server stores certificates and
also stores an encrypted version of the private keys. The also stores an encrypted version of the private keys. The
credential server would not know or need the password phrase for credential server would not know or need the password phrase for
decrypting the private key. The credential server would help decrypting the private key. The credential server would help
move the private keys between devices but the user would need to move the private keys between devices but the user would need to
enter a password phrase on each device to allow that device to enter a password phrase on each device to allow that device to
decrypt (and encrypt) the private key information. decrypt (and encrypt) the private key information.
3. Deployments where the credential server stores the certificates 3. Deployments where the credential server generates and stores the
and private keys and also knows the password phrase for certificates and private keys. Deployments such as these may not
decrypting the private keys. Deployments such as these may not use password phrases. Consequently, the private keys are not
even use password phrases, in which case the private keys are not
encrypted inside the PKCS#8 objects. This style of deployment encrypted inside the PKCS#8 objects. This style of deployment
would often have the credential server, instead of the devices, would often have the credential server, instead of the devices,
create the credentials. create the credentials.
4. UA Behavior with Certificates 4. UA Behavior with Certificates
When a User Agent wishes to discover some other user's certificate it When a User Agent wishes to discover some other user's certificate it
subscribes to the "certificate" SIP event package as described in subscribes to the "certificate" SIP event package as described in
Section 6 to get the certificate. While the subscription is active, Section 6 to get the certificate. While the subscription is active,
if the certificate is updated, the Subscriber will receive the if the certificate is updated, the Subscriber will receive the
skipping to change at page 16, line 9 skipping to change at page 16, line 9
following: following:
o The UA MUST use TLS to directly connect to the server acting as o The UA MUST use TLS to directly connect to the server acting as
the credential service or to a server that is authoritative for the credential service or to a server that is authoritative for
the domain of the credential service. The UA MUST NOT connect the domain of the credential service. The UA MUST NOT connect
through an intermediate proxy to the credential service. through an intermediate proxy to the credential service.
o The Expires header field value in the PUBLISH request SHOULD be o The Expires header field value in the PUBLISH request SHOULD be
set to match the time for which the certificate is valid. set to match the time for which the certificate is valid.
o If the certificate includes Basic Constraints, it SHOULD set the o If the certificate includes Basic Constraints, it SHOULD set the
CA flag to false. CA flag to false.
o The PUBLISH request SHOULD include a SIP-If-Match header field
with the previous etag from the subscription. This prevents
multiple User Agents for the same AOR from publishing conflicting
credentials. Note that UAs replace credentials that are about to
expire at a random time (described in Section 5), reducing the
chance of publishing conflicting credentials even without using
the etag.
7.10. Notifier Processing of PUBLISH Requests 7.10. Notifier Processing of PUBLISH Requests
When the credential service receives a PUBLISH to update credentials, When the credential service receives a PUBLISH to update credentials,
it MUST authenticate and authorize this request the same way as for it MUST authenticate and authorize this request the same way as for
subscriptions for credentials. If the authorization succeeds, then subscriptions for credentials. If the authorization succeeds, then
the credential service MUST perform the following check on the the credential service MUST perform the following check on the
certificate: certificate:
o One of the names in the SubjectAltName of the certificate matches o One of the names in the SubjectAltName of the certificate matches
the authorized user making the request. the authorized user making the request.
skipping to change at page 22, line 7 skipping to change at page 21, line 20
to. The connection must be directly connected to the correct server to. The connection must be directly connected to the correct server
or any intermediaries in the TLS path can compromise the certificate or any intermediaries in the TLS path can compromise the certificate
and instead provide a certificate for which the attacker knows the and instead provide a certificate for which the attacker knows the
private key. This may lead the UA that relies on this compromised private key. This may lead the UA that relies on this compromised
certificate to lose confidential information. Failing to use TLS or certificate to lose confidential information. Failing to use TLS or
selecting a poor cipher suite (such as NULL encryption) may result in selecting a poor cipher suite (such as NULL encryption) may result in
credentials, including private keys, being sent unencrypted over the credentials, including private keys, being sent unencrypted over the
network and will render the whole system useless. network and will render the whole system useless.
The correct checking of chained certificates as specified in TLS The correct checking of chained certificates as specified in TLS
[RFC4366] is critical for the client to authenticate the server. If [RFC5246] is critical for the client to authenticate the server. If
the client does not authenticate that it is talking to the correct the client does not authenticate that it is talking to the correct
credential service, a man in the middle attack is possible. credential service, a man in the middle attack is possible.
9.1. Certificate Revocation 9.1. Certificate Revocation
If a particular credential needs to be revoked, the new credential is If a particular credential needs to be revoked, the new credential is
simply published to the credential service. Every device with a copy simply published to the credential service. Every device with a copy
of the old credential or certificate in its cache will have a of the old credential or certificate in its cache will have a
subscription and will rapidly (order of seconds) be notified and subscription and will rapidly (order of seconds) be notified and
replace its cache. Clients that are not subscribed will subscribe replace its cache. Clients that are not subscribed will subscribe
skipping to change at page 22, line 35 skipping to change at page 21, line 48
invalidate the cached information even though no NOTIFY had ever been invalidate the cached information even though no NOTIFY had ever been
received due to the attacker blocking it. received due to the attacker blocking it.
The duration of this cached information is in some ways similar to a The duration of this cached information is in some ways similar to a
device deciding how often to check a CRL list. For many device deciding how often to check a CRL list. For many
applications, a default time of 1 day is suggested, but for some applications, a default time of 1 day is suggested, but for some
applications it may be desirable to set the time to zero so that no applications it may be desirable to set the time to zero so that no
certificates are cached at all and the credential is checked for certificates are cached at all and the credential is checked for
validity every time the certificate is used. validity every time the certificate is used.
The UA MUST NOT cache the certificates for a period longer than that
of the subscription duration. This is to avoid the UA using invalid
cached credentials when the notifier of the new credentials has been
prevented from updating the UA.
9.2. Certificate Replacement 9.2. Certificate Replacement
The UAs in the system replace the certificates close to the time that The UAs in the system replace the certificates close to the time that
the certificates would expire. If a UA has used the same key pair to the certificates would expire. If a UA has used the same key pair to
encrypt a very large volume of traffic, the UA MAY choose to replace encrypt a very large volume of traffic, the UA MAY choose to replace
the credential with a new one before the normal expiration. the credential with a new one before the normal expiration.
9.3. Trusting the Identity of a Certificate 9.3. Trusting the Identity of a Certificate
When a UA wishes to discover the certificate for When a UA wishes to discover the certificate for
skipping to change at page 24, line 12 skipping to change at page 23, line 29
Specifically, Section 7.6, Section 7.7 and Section 7.10 follow the Specifically, Section 7.6, Section 7.7 and Section 7.10 follow the
cTLS architecture described in section 4.2.2 of [RFC3760]. The cTLS architecture described in section 4.2.2 of [RFC3760]. The
client authenticates the server using the server's TLS certificate. client authenticates the server using the server's TLS certificate.
The server authenticates the client using a SIP digest transaction The server authenticates the client using a SIP digest transaction
inside the TLS session. The TLS sessions form a strong session key inside the TLS session. The TLS sessions form a strong session key
that is used to protect the credentials being exchanged. that is used to protect the credentials being exchanged.
9.5. Crypto Profiles 9.5. Crypto Profiles
Credential services SHOULD implement the server name indication Credential services SHOULD implement the server name indication
extensions in [RFC4366] and they MUST support a TLS profile of extensions in [RFC5246] and they MUST support a TLS profile of
TLS_RSA_WITH_AES_128_CBC_SHA as described in [RFC3268] as a profile TLS_RSA_WITH_AES_128_CBC_SHA as described in [RFC5246] as a profile
of TLS_RSA_WITH_3DES_EDE_CBC_SHA. of TLS_RSA_WITH_3DES_EDE_CBC_SHA.
The PKCS#8 in the clients MUST implement PBES2 with a key derivation The PKCS#8 in the clients MUST implement PBES2 with a key derivation
algorithm of PBKDF2 using HMAC with SHA1 and an encryption algorithm algorithm of PBKDF2 using HMAC with SHA1 and an encryption algorithm
of DES-EDE2-CBC-Pad as defined in [RFC2898]. It is RECOMMENDED that of DES-EDE2-CBC-Pad as defined in [RFC2898]. It is RECOMMENDED that
this profile be used when using PKCS#8. A different passphrase this profile be used when using PKCS#8. A different passphrase
SHOULD be used for the PKCS#8 encryption than is used for server SHOULD be used for the PKCS#8 encryption than is used for server
authentication. authentication.
9.6. User Certificate Generation 9.6. User Certificate Generation
skipping to change at page 28, line 24 skipping to change at page 27, line 24
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996. November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP", Infrastructure Operational Protocols: FTP and HTTP",
RFC 2585, May 1999. RFC 2585, May 1999.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, September 2000.
[RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet,
F., Watson, M., and M. Zonoun, "MIME media types for ISUP F., Watson, M., and M. Zonoun, "MIME media types for ISUP
and QSIG Objects", RFC 3204, December 2001. and QSIG Objects", RFC 3204, December 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002. Event Notification", RFC 3265, June 2002.
[RFC3268] Chown, P., "Advanced Encryption Standard (AES)
Ciphersuites for Transport Layer Security (TLS)",
RFC 3268, June 2002.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004. for Event State Publication", RFC 3903, October 2004.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
Specification Version 2.0", RFC 2898, September 2000. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
This reference is normative. The mechanisms used in this
specification from RFC2898 are stable and sutable for use
in a standards track specification. RFC2898 has been used
as a normative reference in several prior standards track
documents including RFC3185, RFC3370, RFC3962, and
RFC4656.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
12.2. Informational References 12.2. Informational References
[RFC3760] Gustafson, D., Just, M., and M. Nystrom, "Securely [RFC3760] Gustafson, D., Just, M., and M. Nystrom, "Securely
Available Credentials (SACRED) - Credential Server Available Credentials (SACRED) - Credential Server
Framework", RFC 3760, April 2004. Framework", RFC 3760, April 2004.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification", Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004. RFC 3851, July 2004.
[RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES)
Requirement for the Session Initiation Protocol (SIP)", Requirement for the Session Initiation Protocol (SIP)",
RFC 3853, July 2004. RFC 3853, July 2004.
[RFC4662] Roach, A., Rosenberg, J., and B. Campbell, "A Session [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session
Initiation Protocol (SIP) Event Notification Extension for Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", RFC 4662, August 2006. Resource Lists", RFC 4662, August 2006.
Authors' Addresses Authors' Addresses
Cullen Jennings Cullen Jennings
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
MS: SJC-21/2 MS: SJC-21/2
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 408 421-9990 Phone: +1 408 421-9990
Email: fluffy@cisco.com Email: fluffy@cisco.com
Jason Fischl (editor) Jason Fischl (editor)
CounterPath Corporation Skype
Suite 300 2145 Hamilton Ave.
One Bentall Centre San Jose, CA 95125
505 Burrard Street USA
Vancouver, BC V7X 1M3
Canada
Phone: +1 604 320-3344
Email: jason@counterpath.com
URI: http://www.counterpath.com
Intellectual Property Statement
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.
Disclaimer of Validity
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, THE IETF TRUST 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 Statement
Copyright (C) The IETF Trust (2008). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the Phone: +1-408-786-5919
Internet Society. Email: jason.fischl@skype.net
 End of changes. 24 change blocks. 
108 lines changed or deleted 49 lines changed or added

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