draft-ietf-sip-certs-03.txt   draft-ietf-sip-certs-04.txt 
Network Working Group C. Jennings Network Working Group C. Jennings
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track J. Peterson Intended status: Standards Track J. Peterson
Expires: September 5, 2007 NeuStar, Inc. Expires: January 9, 2008 NeuStar, Inc.
J. Fischl, Ed. J. Fischl, Ed.
CounterPath Solutions, Inc. CounterPath Solutions, Inc.
March 4, 2007 July 8, 2007
Certificate Management Service for The Session Initiation Protocol (SIP) Certificate Management Service for The Session Initiation Protocol (SIP)
draft-ietf-sip-certs-03 draft-ietf-sip-certs-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes 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. 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
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 September 5, 2007. This Internet-Draft will expire on January 9, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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 package to Initiation Protocol (SIP) User Agents (UAs) to use a SIP package to
discover the certificates of other users. This mechanism allows user discover the certificates of other users. This mechanism allows user
skipping to change at page 2, line 29 skipping to change at page 2, line 29
6.4. Subscription Duration . . . . . . . . . . . . . . . . . . 10 6.4. Subscription Duration . . . . . . . . . . . . . . . . . . 10
6.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 10 6.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 10
6.6. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 11 6.6. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 11
6.7. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 11 6.7. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 11
6.8. Notifier Generation of NOTIFY Requests . . . . . . . . . . 11 6.8. Notifier Generation of NOTIFY Requests . . . . . . . . . . 11
6.9. Subscriber Processing of NOTIFY Requests . . . . . . . . . 12 6.9. Subscriber Processing of NOTIFY Requests . . . . . . . . . 12
6.10. Handling of Forked Requests . . . . . . . . . . . . . . . 12 6.10. Handling of Forked Requests . . . . . . . . . . . . . . . 12
6.11. Rate of Notifications . . . . . . . . . . . . . . . . . . 12 6.11. Rate of Notifications . . . . . . . . . . . . . . . . . . 12
6.12. State Agents and Lists . . . . . . . . . . . . . . . . . . 12 6.12. State Agents and Lists . . . . . . . . . . . . . . . . . . 12
6.13. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 12 6.13. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 12
7. Event Package Formal Definition for "credential" . . . . . . . 12 7. Event Package Formal Definition for "credential" . . . . . . . 13
7.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 13 7.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . 14 7.8. Notifier Generation of NOTIFY Requests . . . . . . . . . . 14
7.9. Generation of PUBLISH Requests . . . . . . . . . . . . . . 15 7.9. Generation of PUBLISH Requests . . . . . . . . . . . . . . 15
7.10. Notifier Processing of PUBLISH Requests . . . . . . . . . 15 7.10. Notifier Processing of PUBLISH Requests . . . . . . . . . 15
7.11. Subscriber Processing of NOTIFY Requests . . . . . . . . . 16 7.11. Subscriber Processing of NOTIFY Requests . . . . . . . . . 16
7.12. Handling of Forked Requests . . . . . . . . . . . . . . . 16 7.12. Handling of Forked Requests . . . . . . . . . . . . . . . 16
7.13. Rate of Notifications . . . . . . . . . . . . . . . . . . 16 7.13. Rate of Notifications . . . . . . . . . . . . . . . . . . 16
7.14. State Agents and Lists . . . . . . . . . . . . . . . . . . 16 7.14. State Agents and Lists . . . . . . . . . . . . . . . . . . 16
7.15. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9.1. Certificate Revocation . . . . . . . . . . . . . . . . . . 21 9.1. Certificate Revocation . . . . . . . . . . . . . . . . . . 21
9.2. Certificate Replacement . . . . . . . . . . . . . . . . . 21 9.2. Certificate Replacement . . . . . . . . . . . . . . . . . 21
9.3. Trusting the Identity of a Certificate . . . . . . . . . . 21 9.3. Trusting the Identity of a Certificate . . . . . . . . . . 21
9.4. SACRED Framework . . . . . . . . . . . . . . . . . . . . . 22 9.4. SACRED Framework . . . . . . . . . . . . . . . . . . . . . 22
9.5. Crypto Profiles . . . . . . . . . . . . . . . . . . . . . 23 9.5. Crypto Profiles . . . . . . . . . . . . . . . . . . . . . 23
9.6. User Certificate Generation . . . . . . . . . . . . . . . 23 9.6. User Certificate Generation . . . . . . . . . . . . . . . 23
9.7. Compromised Authentication Service . . . . . . . . . . . . 23 9.7. Compromised Authentication Service . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10.1. Certificate Event Package . . . . . . . . . . . . . . . . 24 10.1. Certificate Event Package . . . . . . . . . . . . . . . . 24
10.2. Credential Event Package . . . . . . . . . . . . . . . . . 24 10.2. Credential Event Package . . . . . . . . . . . . . . . . . 24
10.3. PKCS#8 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 10.3. PKCS#8 . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . . 27 12.1. Normative References . . . . . . . . . . . . . . . . . . . 27
12.2. Informational References . . . . . . . . . . . . . . . . . 28 12.2. Informational References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . . . . 30
1. Introduction 1. Introduction
SIP [RFC3261] provides a mechanism [RFC3853] for end-to-end SIP [RFC3261] provides a mechanism [RFC3853] for end-to-end
encryption and integrity using S/MIME [RFC3851]. Several security encryption and integrity using S/MIME [RFC3851]. Several security
skipping to change at page 9, line 40 skipping to change at page 9, line 40
There are several different cases in which a UA should generate a new There are several different cases in which a UA should generate a new
credential: credential:
o If the UA receives a NOTIFY with no body for the credential o If the UA receives a NOTIFY with no body for the credential
package. package.
o If the certificate has expired. o If the certificate has expired.
o If the certificate's notAfter date is within the next 600 seconds, o If the certificate's notAfter date is within the next 600 seconds,
the UA SHOULD attempt to create replacement credentials. The UA the UA SHOULD attempt to create replacement credentials. The UA
does this by waiting a random amount of time between 0 and 300 does this by waiting a random amount of time between 0 and 300
seconds. If no new credentials have been received in that time, seconds. If no new credentials have been received in that time,
the UA creates new credentials to replace the expiring ones and the UA creates new credentials to replace the expiring ones and
sends them in a PUBLISH request (with a SIP-If-Match header set to sends them in a PUBLISH request (with a SIP-If-Match header field
the current etag). This makes credential collisions both unlikely set to the current etag). This makes credential collisions both
and harmless. unlikely and harmless.
o If the user of the device has indicated via the user interface o If the user of the device has indicated via the user interface
that they wish to revoke the current certificate and issue a new that they wish to revoke the current certificate and issue a new
one. one.
Credentials are created by creating a new key pair which will require Credentials are created by creating a new key pair which will require
appropriate randomness, and then creating a certificate as described appropriate randomness, and then creating a certificate as described
in Section 9.6. The UA MAY encrypt the private key with a password in Section 9.6. The UA MAY encrypt the private key with a password
phrase supplied by the user. Next, the UA updates the user's phrase supplied by the user. Next, the UA updates the user's
credential by sending a PUBLISH [RFC3903] request with the credential by sending a PUBLISH [RFC3903] request with the
credentials or just the certificate as described in Section 7.9. credentials or just the certificate as described in Section 7.9.
skipping to change at page 10, line 45 skipping to change at page 10, line 45
default subscription duration for this event package is one day. default subscription duration for this event package is one day.
The credential service is encouraged to keep the subscriptions active The credential service is encouraged to keep the subscriptions active
for AORs that are communicating frequently, but the credential for AORs that are communicating frequently, but the credential
service MAY terminate the subscription at any point in time. service MAY terminate the subscription at any point in time.
6.5. NOTIFY Bodies 6.5. NOTIFY Bodies
The body of a NOTIFY request for this package MUST either be empty or The body of a NOTIFY request for this package MUST either be empty or
contain an application/pkix-cert body (as defined in [RFC2585]) that contain an application/pkix-cert body (as defined in [RFC2585]) that
contains the certificate, unless an Accept header has negotiated some contains the certificate, unless an Accept header field has
other type. The Content-Disposition MUST be set to "signal" as negotiated some other type. The Content-Disposition MUST be set to
defined in [RFC3204]. "signal" as defined in [RFC3204].
A future extension MAY define other NOTIFY bodies. If no "Accept" A future extension MAY define other NOTIFY bodies. If no "Accept"
header is present in the SUBSCRIBE, the body type defined in this header field is present in the SUBSCRIBE, the body type defined in
document MUST be assumed. this document MUST be assumed.
Implementations which generate large notifications are reminded to Implementations which generate large notifications are reminded to
follow the message size restrictions for unreliable transports follow the message size restrictions for unreliable transports
articulated in Section 18.1.1 of SIP. articulated in Section 18.1.1 of SIP.
6.6. Subscriber Generation of SUBSCRIBE Requests 6.6. Subscriber Generation of SUBSCRIBE Requests
A UA discovers a certificate by sending a SUBSCRIBE request with an A UA discovers a certificate by sending a SUBSCRIBE request with an
event type of "certificate" to the AOR for which a certificate is event type of "certificate" to the AOR for which a certificate is
desired. In general, the UA stays subscribed to the certificate for desired. In general, the UA stays subscribed to the certificate for
as long as it plans to use and cache the certificate, so that the UA as long as it plans to use and cache the certificate, so that the UA
can be notified about changes or revocations to the certificate. can be notified about changes or revocations to the certificate.
Subscriber User Agents will typically subscribe to certificate Subscriber User Agents will typically subscribe to certificate
information for a period of hours or days, and automatically attempt information for a period of hours or days, and automatically attempt
to re-subscribe just before the subscription is completely expired. to re-subscribe just before the subscription is completely expired.
When a user de-registers from a device (logoff, power down of a When a user de-registers from a device (logoff, power down of a
mobile device, etc.), subscribers SHOULD unsubscribe by sending a mobile device, etc.), subscribers SHOULD unsubscribe by sending a
SUBSCRIBE request with an Expires header of zero. SUBSCRIBE request with an Expires header field of zero.
6.7. Notifier Processing of SUBSCRIBE Requests 6.7. Notifier Processing of SUBSCRIBE Requests
When a SIP credential server receives a SUBSCRIBE request with the When a SIP credential server receives a SUBSCRIBE request with the
certificate event-type, it is not necessary to authenticate the certificate event-type, it is not necessary to authenticate the
subscription request. The Notifier MAY limit the duration of the subscription request. The Notifier MAY limit the duration of the
subscription to an administrator-defined period of time. The subscription to an administrator-defined period of time. The
duration of the subscription does not correspond in any way to the duration of the subscription does not correspond in any way to the
period for which the certificate will be valid. period for which the certificate will be valid.
skipping to change at page 12, line 32 skipping to change at page 12, line 32
This event package does not permit forked requests. At most one This event package does not permit forked requests. At most one
subscription to this event type is permitted per resource. subscription to this event type is permitted per resource.
6.11. Rate of Notifications 6.11. Rate of Notifications
Notifiers SHOULD NOT generate NOTIFY requests more frequently than Notifiers SHOULD NOT generate NOTIFY requests more frequently than
once per minute. once per minute.
6.12. State Agents and Lists 6.12. State Agents and Lists
Implementers MUST NOT implement state agents for this event type. The certificate server described in this section which serves
Likewise, implementations MUST NOT use the event list extension certificates is a state agent and implementions of the certificate
[RFC4662] with this event type. It is not possible to make such an server MUST be implemented as a state agent.
approach work, because the Authentication service would have to
simultaneously assert several different identities. Implementers MUST NOT use the event list extension [RFC4662] with
this event type. It is not possible to make such an approach work,
because the Authentication service would have to simultaneously
assert several different identities.
6.13. Behavior of a Proxy Server 6.13. Behavior of a Proxy Server
There are no additional requirements on a SIP Proxy, other than to There are no additional requirements on a SIP Proxy, other than to
transparently forward the SUBSCRIBE and NOTIFY requests as required transparently forward the SUBSCRIBE and NOTIFY requests as required
in SIP. This specification describes the Proxy, Authentication in SIP. This specification describes the Proxy, Authentication
service, and credential service as three separate services, but it is service, and credential service as three separate services, but it is
certainly possible to build a single SIP network element that certainly possible to build a single SIP network element that
performs all of these services at the same time. performs all of these services at the same time.
skipping to change at page 13, line 18 skipping to change at page 13, line 20
The event-package token name for this package is: The event-package token name for this package is:
credential credential
7.2. Event Package Parameters 7.2. Event Package Parameters
This package defines the "etag" Event header parameter which is valid This package defines the "etag" Event header parameter which is valid
only in NOTIFY requests. It contains a token which represents the only in NOTIFY requests. It contains a token which represents the
SIP etag value at the time the notification was sent. Considering SIP etag value at the time the notification was sent. Considering
how infrequently credentials are updated, this hint is very likely to how infrequently credentials are updated, this hint is very likely to
be the correct etag to use in the SIP-If-Match header in a SIP be the correct etag to use in the SIP-If-Match header field in a SIP
PUBLISH request to update the current credentials. PUBLISH request to update the current credentials.
etag-param = "etag" EQUAL token etag-param = "etag" EQUAL token
7.3. SUBSCRIBE Bodies 7.3. SUBSCRIBE Bodies
This package does not define any SUBSCRIBE bodies. This package does not define any SUBSCRIBE bodies.
7.4. Subscription Duration 7.4. Subscription Duration
skipping to change at page 13, line 45 skipping to change at page 13, line 47
7.5. NOTIFY Bodies 7.5. NOTIFY Bodies
The NOTIFY MUST contain a multipart/mixed (see [RFC2046]) body that The NOTIFY MUST contain a multipart/mixed (see [RFC2046]) body that
contains both an application/pkix-cert body with the certificate and contains both an application/pkix-cert body with the certificate and
an application/pkcs8 body that has the associated private key an application/pkcs8 body that has the associated private key
information for the certificate. The Content-Disposition MUST be set information for the certificate. The Content-Disposition MUST be set
to "signal" as defined in [RFC3204]. to "signal" as defined in [RFC3204].
A future extension MAY define other NOTIFY bodies. If no "Accept" A future extension MAY define other NOTIFY bodies. If no "Accept"
header is present in the SUBSCRIBE, the body type defined in this header field is present in the SUBSCRIBE, the body type defined in
document MUST be assumed. this document MUST be assumed.
The application/pkix-cert body is a DER encoded X.509v3 certificate The application/pkix-cert body is a DER encoded X.509v3 certificate
[RFC2585]. The application/pkcs8 body contains a DER-encoded PKCS#8 [RFC2585]. The application/pkcs8 body contains a DER-encoded PKCS#8
[PKCS.8.1993] object that contains the private key. The PKCS#8 [PKCS.8.1993] object that contains the private key. The PKCS#8
objects MUST be of type PrivateKeyInfo. The integrity and objects MUST be of type PrivateKeyInfo. The integrity and
confidentiality of the PKCS#8 objects is provided by the TLS confidentiality of the PKCS#8 objects is provided by the TLS
transport. The transport encoding of all the MIME bodies is binary. transport. The transport encoding of all the MIME bodies is binary.
7.6. Subscriber Generation of SUBSCRIBE Requests 7.6. Subscriber Generation of SUBSCRIBE Requests
skipping to change at page 14, line 43 skipping to change at page 14, line 45
credential service has to authenticate and authorize the UA and credential service has to authenticate and authorize the UA and
validate that adequate transport security is being used. Only a UA validate that adequate transport security is being used. Only a UA
that can authenticate as being able to register as the AOR is that can authenticate as being able to register as the AOR is
authorized to receive the credentials for that AOR. The credential authorized to receive the credentials for that AOR. The credential
Service MUST digest challenge the UA to authenticate the UA and then Service MUST digest challenge the UA to authenticate the UA and then
decide if it is authorized to receive the credentials. If decide if it is authorized to receive the credentials. If
authentication is successful, the Notifier MAY limit the duration of authentication is successful, the Notifier MAY limit the duration of
the subscription to an administrator-defined period of time. The the subscription to an administrator-defined period of time. The
duration of the subscription MUST not be larger than the length of duration of the subscription MUST not be larger than the length of
time for which the certificate is still valid. The Expires header time for which the certificate is still valid. The Expires header
SHOULD be set so that it is not longer than the notAfter date in the field SHOULD be set so that it is not longer than the notAfter date
certificate. in the certificate.
7.8. Notifier Generation of NOTIFY Requests 7.8. Notifier Generation of NOTIFY Requests
Once the UA has authenticated with the credential service and the Once the UA has authenticated with the credential service and the
subscription is accepted, the credential service MUST immediately subscription is accepted, the credential service MUST immediately
send a Notify request. The Notifier SHOULD include the current etag send a Notify request. The Notifier SHOULD include the current etag
value in the "etag" Event package parameter in the NOTIFY request. value in the "etag" Event package parameter in the NOTIFY request.
The Authentication Service is applied to this NOTIFY request in the The Authentication Service is applied to this NOTIFY request in the
same way as the certificate subscriptions. If the credential is same way as the certificate subscriptions. If the credential is
revoked, the credential service MUST terminate any current revoked, the credential service MUST terminate any current
subscriptions and force the UA to re-authenticate by sending a NOTIFY subscriptions and force the UA to re-authenticate by sending a NOTIFY
with its Subscription-State header set to "terminated" and a reason with its Subscription-State header field set to "terminated" and a
parameter of "deactivated". (This causes a Subscriber to retry the reason parameter of "deactivated". (This causes a Subscriber to
subscription immediately.) This is so that if a secret for retry the subscription immediately.) This is so that if a secret for
retrieving the credentials gets compromised, the rogue UA will not retrieving the credentials gets compromised, the rogue UA will not
continue to receive credentials after the compromised secret has been continue to receive credentials after the compromised secret has been
changed. changed.
Any time the credentials for this URI change, the credential service Any time the credentials for this URI change, the credential service
MUST send a new NOTIFY to any active subscriptions with the new MUST send a new NOTIFY to any active subscriptions with the new
credentials. credentials.
7.9. Generation of PUBLISH Requests 7.9. Generation of PUBLISH Requests
skipping to change at page 16, line 43 skipping to change at page 16, line 43
This event package does not permit forked requests. This event package does not permit forked requests.
7.13. Rate of Notifications 7.13. Rate of Notifications
Notifiers SHOULD NOT generate NOTIFY requests more frequently than Notifiers SHOULD NOT generate NOTIFY requests more frequently than
once per minute. once per minute.
7.14. State Agents and Lists 7.14. State Agents and Lists
Implementers MUST NOT implement state agents for this event type. The credential server described in this section which serves
Likewise, implementations MUST NOT use the event list extension credentials is a state agent and implementions of the credential
[RFC4662] with this event type. server MUST be implemented as a state agent.
Implementers MUST NOT use the event list extension [RFC4662] with
this event type.
7.15. Behavior of a Proxy Server 7.15. Behavior of a Proxy Server
The behavior is identical to behavior described for certificate The behavior is identical to behavior described for certificate
subscriptions described in Section 6.13. subscriptions described in Section 6.13.
8. Examples 8. Examples
In all these examples, large parts of the messages are omitted to In all these examples, large parts of the messages are omitted to
highlight what is relevant to this draft. The lines in the examples highlight what is relevant to this draft. The lines in the examples
skipping to change at page 22, line 4 skipping to change at page 22, line 10
alice@example.com and receives a certificate in the body of a SIP alice@example.com and receives a certificate in the body of a SIP
NOTIFY request. The term original URI is used to describe the URI NOTIFY request. The term original URI is used to describe the URI
that was in the To header field value of the SUBSCRIBE request. So that was in the To header field value of the SUBSCRIBE request. So
in this case the original URI would be sip:alice@example.com. in this case the original URI would be sip:alice@example.com.
If the certificate is signed by a trusted CA, and one of the names in If the certificate is signed by a trusted CA, and one of the names in
the SubjectAltName matches the original URI, then this certificate the SubjectAltName matches the original URI, then this certificate
MAY be used but only for exactly the original URI and not for other MAY be used but only for exactly the original URI and not for other
identities found in the SubjectAltName. Otherwise, there are several identities found in the SubjectAltName. Otherwise, there are several
steps the UA MUST perform before using this certificate. steps the UA MUST perform before using this certificate.
o The From header field in the NOTIFY request MUST match the
o The From header in the NOTIFY request MUST match the original URI original URI that was subscribed to.
that was subscribed to. o The UA MUST check the Identity header field as described in the
o The UA MUST check the Identity header as described in the Identity Identity [RFC4474] specification to validate that bodies have not
[RFC4474] specification to validate that bodies have not been been tampered with and that an Authentication Service has
tampered with and that an Authentication Service has validated validated this From header field.
this From header.
o The UA MUST check the validity time of the certificate and stop o The UA MUST check the validity time of the certificate and stop
using the certificate if it is invalid. (Implementations are using the certificate if it is invalid. (Implementations are
reminded to verify both the notBefore and notAfter validity reminded to verify both the notBefore and notAfter validity
times.) times.)
o The certificate MAY have several names in the SubjectAltName but o The certificate MAY have several names in the SubjectAltName but
the UA MUST only use this certificate when it needs the the UA MUST only use this certificate when it needs the
certificate for the identity asserted by the Authentication certificate for the identity asserted by the Authentication
Service in the NOTIFY. This means that the certificate should Service in the NOTIFY. This means that the certificate should
only be indexed in the certificate cache by the AOR that the only be indexed in the certificate cache by the AOR that the
Authentication Service asserted and not by the value of all the Authentication Service asserted and not by the value of all the
skipping to change at page 26, line 15 skipping to change at page 26, line 15
Subject: Registration of MIME media type application/pkcs8 Subject: Registration of MIME media type application/pkcs8
MIME media type name: application MIME media type name: application
MIME subtype name: pkcs8 MIME subtype name: pkcs8
Required parameters: None Required parameters: None
Optional parameters: None Optional parameters: None
Encoding considerations: The PKCS#8 object inside this MIME type Encoding considerations: binary
MUST be DER-encoded.
This MIME type was designed for use with
protocols which can carry binary-encoded
data. Protocols which do not carry binary
data (which have line length or
character-set restrictions for example)
MUST use a reversible transfer encoding
(such as base64) to carry this MIME type.
Protocols that carry binary data SHOULD
use a transfer encoding of "binary".
Security considerations: Carries a cryptographic private key Security considerations: Carries a cryptographic private key
Interoperability considerations: None Interoperability considerations:
The PKCS#8 object inside this MIME type MUST be DER-encoded
Published specification: Published specification:
RSA Laboratories, "Private-Key Information Syntax Standard, RSA Laboratories, "Private-Key Information Syntax Standard,
Version 1.2", PKCS 8, November 1993. Version 1.2", PKCS 8, November 1993.
Applications which use this media type: Any MIME-compliant transport Applications which use this media type: Any MIME-compliant transport
Additional information: Additional information:
Magic number(s): None Magic number(s): None
File extension(s): .p8 File extension(s): .p8
skipping to change at page 28, line 20 skipping to change at page 28, line 10
and T. Wright, "Transport Layer Security (TLS) and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006. 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 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, September 2000. Specification Version 2.0", RFC 2898, September 2000.
This reference is informational. The mechanisms used in This reference is normative. The mechanisms used in this
this specification from RFC2898 are stable and sutable for specification from RFC2898 are stable and sutable for use
use in a standards track specification. RFC2898 has been in a standards track specification. RFC2898 has been used
used as a normative reference in several prior standards as a normative reference in several prior standards track
track documents including RFC3185, RFC3370, RFC3962, and documents including RFC3185, RFC3370, RFC3962, and
RFC4656. RFC4656.
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",
 End of changes. 22 change blocks. 
58 lines changed or deleted 52 lines changed or added

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