Internet Engineering Task Force (IETF) C. Jennings
Request for Comments: 6072 Cisco Systems
Category: Standards Track J. Fischl, Ed.
ISSN: 2070-1721 Skype
February 2011
Internet Engineering Task Force (IETF) C. Jennings
Request for Comments: 6072 Cisco Systems
Category: Standards Track J. Fischl, Ed.
ISSN: 2070-1721 Skype
February 2011
Certificate Management Service for the Session Initiation Protocol (SIP)
会话启动协议（SIP）的证书管理服务
Abstract
摘要
This document defines a credential service that allows Session Initiation Protocol (SIP) User Agents (UAs) to use a SIP event package to discover the certificates of other users. This mechanism allows User Agents that want to contact a given Address-of-Record (AOR) to retrieve that AOR's certificate by subscribing to the credential service, which returns an authenticated response containing that certificate. The credential service also allows users to store and retrieve their own certificates and private keys.
本文档定义了一个凭证服务，该服务允许会话启动协议（SIP）用户代理（UAs）使用SIP事件包来发现其他用户的证书。此机制允许希望联系给定记录地址（AOR）的用户代理通过订阅凭证服务来检索该AOR的证书，凭证服务返回包含该证书的经过身份验证的响应。凭证服务还允许用户存储和检索自己的证书和私钥。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6072.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6072.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. Definitions .....................................................4
3. Overview ........................................................4
4. UA Behavior with Certificates ...................................7
5. UA Behavior with Credentials ....................................8
6. Event Package Formal Definition for "certificate" ...............9
6.1. Event Package Name .........................................9
6.2. SUBSCRIBE Bodies ...........................................9
6.3. Subscription Duration .....................................10
6.4. NOTIFY Bodies .............................................10
6.5. Subscriber Generation of SUBSCRIBE Requests ...............10
6.6. Notifier Processing of SUBSCRIBE Requests .................11
6.7. Notifier Generation of NOTIFY Requests ....................11
6.8. Subscriber Processing of NOTIFY Requests ..................11
6.9. Handling of Forked Requests ...............................11
6.10. Rate of Notifications ....................................12
6.11. State Agents and Lists ...................................12
6.12. Behavior of a Proxy Server ...............................12
1. Introduction ....................................................3
2. Definitions .....................................................4
3. Overview ........................................................4
4. UA Behavior with Certificates ...................................7
5. UA Behavior with Credentials ....................................8
6. Event Package Formal Definition for "certificate" ...............9
6.1. Event Package Name .........................................9
6.2. SUBSCRIBE Bodies ...........................................9
6.3. Subscription Duration .....................................10
6.4. NOTIFY Bodies .............................................10
6.5. Subscriber Generation of SUBSCRIBE Requests ...............10
6.6. Notifier Processing of SUBSCRIBE Requests .................11
6.7. Notifier Generation of NOTIFY Requests ....................11
6.8. Subscriber Processing of NOTIFY Requests ..................11
6.9. Handling of Forked Requests ...............................11
6.10. Rate of Notifications ....................................12
6.11. State Agents and Lists ...................................12
6.12. Behavior of a Proxy Server ...............................12
7. Event Package Formal Definition for "credential" ...............12
7.1. Event Package Name ........................................12
7.2. SUBSCRIBE Bodies ..........................................12
7.3. Subscription Duration .....................................12
7.4. NOTIFY Bodies .............................................13
7.5. Subscriber Generation of SUBSCRIBE Requests ...............13
7.6. Notifier Processing of SUBSCRIBE Requests .................14
7.7. Notifier Generation of NOTIFY Requests ....................14
7.8. Generation of PUBLISH Requests ............................15
7.9. Notifier Processing of PUBLISH Requests ...................15
7.10. Subscriber Processing of NOTIFY Requests .................16
7.11. Handling of Forked Requests ..............................16
7.12. Rate of Notifications ....................................16
7.13. State Agents and Lists ...................................16
7.14. Behavior of a Proxy Server ...............................16
8. Identity Signatures ............................................16
9. Examples .......................................................17
9.1. Encrypted Page Mode Instant Message .......................17
9.2. Setting and Retrieving UA Credentials .....................18
10. Security Considerations .......................................19
10.1. Certificate Revocation ...................................21
10.2. Certificate Replacement ..................................22
10.3. Trusting the Identity of a Certificate ...................22
10.3.1. Extra Assurance ...................................23
10.4. SACRED Framework .........................................24
10.5. Crypto Profiles ..........................................24
10.6. User Certificate Generation ..............................25
10.7. Private Key Storage ......................................25
10.8. Compromised Authentication Service .......................26
11. IANA Considerations ...........................................26
11.1. Certificate Event Package ................................27
11.2. Credential Event Package .................................27
11.3. Identity Algorithm .......................................27
12. Acknowledgments ...............................................27
13. References ....................................................28
13.1. Normative References .....................................28
13.2. Informative References ...................................29
7. Event Package Formal Definition for "credential" ...............12
7.1. Event Package Name ........................................12
7.2. SUBSCRIBE Bodies ..........................................12
7.3. Subscription Duration .....................................12
7.4. NOTIFY Bodies .............................................13
7.5. Subscriber Generation of SUBSCRIBE Requests ...............13
7.6. Notifier Processing of SUBSCRIBE Requests .................14
7.7. Notifier Generation of NOTIFY Requests ....................14
7.8. Generation of PUBLISH Requests ............................15
7.9. Notifier Processing of PUBLISH Requests ...................15
7.10. Subscriber Processing of NOTIFY Requests .................16
7.11. Handling of Forked Requests ..............................16
7.12. Rate of Notifications ....................................16
7.13. State Agents and Lists ...................................16
7.14. Behavior of a Proxy Server ...............................16
8. Identity Signatures ............................................16
9. Examples .......................................................17
9.1. Encrypted Page Mode Instant Message .......................17
9.2. Setting and Retrieving UA Credentials .....................18
10. Security Considerations .......................................19
10.1. Certificate Revocation ...................................21
10.2. Certificate Replacement ..................................22
10.3. Trusting the Identity of a Certificate ...................22
10.3.1. Extra Assurance ...................................23
10.4. SACRED Framework .........................................24
10.5. Crypto Profiles ..........................................24
10.6. User Certificate Generation ..............................25
10.7. Private Key Storage ......................................25
10.8. Compromised Authentication Service .......................26
11. IANA Considerations ...........................................26
11.1. Certificate Event Package ................................27
11.2. Credential Event Package .................................27
11.3. Identity Algorithm .......................................27
12. Acknowledgments ...............................................27
13. References ....................................................28
13.1. Normative References .....................................28
13.2. Informative References ...................................29
[RFC3261], as amended by [RFC3853], provides a mechanism for end-to-end encryption and integrity using Secure/Multipurpose Internet Mail Extensions (S/MIME) [RFC5751]. Several security properties of [RFC3261] depend on S/MIME, and yet it has not been widely deployed. One reason is the complexity of providing a reasonable certificate distribution infrastructure. This specification proposes a way to address discovery, retrieval, and management of certificates for SIP deployments. Combined with the SIP Identity [RFC4474] specification,
[RFC3261]经[RFC3853]修订，提供了一种使用安全/多用途Internet邮件扩展（S/MIME）[RFC5751]实现端到端加密和完整性的机制。[RFC3261]的几个安全属性依赖于S/MIME，但尚未广泛部署。一个原因是提供合理的证书分发基础结构的复杂性。本规范提出了一种解决SIP部署证书的发现、检索和管理问题的方法。结合SIP标识[RFC4474]规范，
this specification allows users to have certificates that are not signed by any well known certification authority while still strongly binding the user's identity to the certificate.
此规范允许用户拥有未经任何知名证书颁发机构签名的证书，同时仍将用户身份与证书紧密绑定。
In addition, this specification provides a mechanism that allows SIP User Agents such as IP phones to enroll and get their credentials without any more configuration information than they commonly have today. The end user expends no extra effort.
此外，该规范提供了一种机制，允许SIP用户代理（如IP电话）注册并获取其凭据，而不需要比现在更多的配置信息。最终用户不需要额外的努力。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Certificate: A Public Key Infrastructure using X.509 (PKIX)- [RFC5280] style certificate containing a public key and a list of identities in the SubjectAltName that are bound to this key. The certificates discussed in this document are generally self-signed and use the mechanisms in the SIP Identity [RFC4474] specification to vouch for their validity. Certificates that are signed by a certification authority can also be used with all the mechanisms in this document; however, they need not be validated by the receiver (although the receiver can validate them for extra assurance; see Section 10.3.1).
证书：使用X.509（PKIX）-[RFC5280]样式证书的公钥基础结构，其中包含公钥和SubjectAltName中绑定到此密钥的标识列表。本文档中讨论的证书通常是自签名的，并使用SIP标识[RFC4474]规范中的机制来证明其有效性。由证书颁发机构签署的证书也可以与本文档中的所有机制一起使用；然而，它们不需要由接收者验证（尽管接收者可以验证它们以获得额外的保证；参见第10.3.1节）。
Credential: For this document, "credential" means the combination of a certificate and the associated private key.
凭证：对于本文档，“凭证”是指证书和相关私钥的组合。
Password Phrase: A password used to encrypt and decrypt a PKCS #8 (Public Key Cryptographic System #8) private key.
密码短语：用于加密和解密PKCS#8（公钥密码系统#8）私钥的密码。
The general approach is to provide a new SIP service referred to as a "credential service" that allows SIP User Agents (UAs) to subscribe to other users' certificates using a new SIP event package [RFC3265]. The certificate is delivered to the subscribing UA in a corresponding SIP NOTIFY request. An authentication service as described in the SIP Identity [RFC4474] specification can be used to vouch for the identity of the sender of the certificate by using the sender's proxy domain certificate to sign the NOTIFY request. The authentication service is vouching that the sender is allowed to populate the SIP From header field value. The sender of the message is vouching that this is an appropriate certificate for the user identified in the SIP From header field value. The credential service can manage public certificates as well as the user's private keys. Users can update their credentials, as stored on the credential service, using a SIP
一般方法是提供称为“凭证服务”的新SIP服务，该服务允许SIP用户代理（UAs）使用新的SIP事件包[RFC3265]订阅其他用户的证书。证书在相应的SIP NOTIFY请求中交付给订阅UA。SIP Identity[RFC4474]规范中描述的身份验证服务可用于通过使用发送方的代理域证书对NOTIFY请求进行签名来证明证书发送方的身份。身份验证服务正在证明允许发送方从标头字段值填充SIP。消息的发送方保证这是SIP From header字段值中标识的用户的适当证书。凭证服务可以管理公共证书以及用户的私钥。用户可以使用SIP更新存储在凭证服务上的凭证
PUBLISH [RFC3903] request. The UA authenticates to the credential service using a shared secret when a UA is updating a credential. Typically the shared secret will be the same one that is used by the UA to authenticate a REGISTER request with the Registrar for the domain (usually with SIP Digest Authentication).
发布[RFC3903]请求。当UA更新凭证时，UA使用共享密钥向凭证服务进行身份验证。通常，共享秘密将与UA用于向域的注册器验证注册请求（通常使用SIP摘要验证）的共享秘密相同。
The following figure shows Bob publishing his credentials from one of his User Agents (e.g., his laptop software client), retrieving his credentials from another of his User Agents (e.g., his mobile phone), and then Alice retrieving Bob's certificate and sending a message to Bob. SIP 200-class responses are omitted from the diagram to make the figure easier to understand.
下图显示Bob从一个用户代理（例如，他的笔记本电脑软件客户端）发布他的凭据，从另一个用户代理（例如，他的手机）检索他的凭据，然后Alice检索Bob的证书并向Bob发送消息。为了使图更容易理解，图中省略了SIP 200类响应。
example.com domain
------------------
Alice Proxy Auth Cred Bob1 Bob2
| | | | TLS Handshake | |
| [ Bob generates ] |<--------------------->|
| [ credentials and ] | PUBLISH (credential) |
| [ publishes them ] |<----------------------|
| | | | Digest Challenge |
| | | |---------------------->|
| | | | PUBLISH + Digest |
| | | |<----------------------|
| | | | |
| | | | time passes... |
| | | | |
| | | | TLS Handshake |
| [ Bob later gets ] |<---------------->|
| [ back his own ] | SUBSCRIBE |
| [ credentials ] | (credential) |
| [ at another ] |<-----------------|
| [ User Agent ] | SUBSCRIBE+Digest |
| | | |<-----------------|
| | | | NOTIFY |
| | | |----------------->|
| | | | Bob decrypts key |
| | | | |
| | | | |
| SUBSCRIBE (certificate) | Alice fetches |
|---------->|----->|----->| Bob's cert |
| | |NOTIFY| |
| NOTIFY+Identity |<-----| |
|<----------+------| | Alice uses cert |
| | | | to encrypt |
| MESSAGE | | | message to Bob |
|---------->|------+------+----------------->|
example.com domain
------------------
Alice Proxy Auth Cred Bob1 Bob2
| | | | TLS Handshake | |
| [ Bob generates ] |<--------------------->|
| [ credentials and ] | PUBLISH (credential) |
| [ publishes them ] |<----------------------|
| | | | Digest Challenge |
| | | |---------------------->|
| | | | PUBLISH + Digest |
| | | |<----------------------|
| | | | |
| | | | time passes... |
| | | | |
| | | | TLS Handshake |
| [ Bob later gets ] |<---------------->|
| [ back his own ] | SUBSCRIBE |
| [ credentials ] | (credential) |
| [ at another ] |<-----------------|
| [ User Agent ] | SUBSCRIBE+Digest |
| | | |<-----------------|
| | | | NOTIFY |
| | | |----------------->|
| | | | Bob decrypts key |
| | | | |
| | | | |
| SUBSCRIBE (certificate) | Alice fetches |
|---------->|----->|----->| Bob's cert |
| | |NOTIFY| |
| NOTIFY+Identity |<-----| |
|<----------+------| | Alice uses cert |
| | | | to encrypt |
| MESSAGE | | | message to Bob |
|---------->|------+------+----------------->|
Bob's UA (Bob2) does a Transport Layer Security (TLS) [RFC5246] handshake with the credential server to authenticate that the UA is connected to the correct credential server. Then Bob's UA publishes his newly created or updated credentials. The credential server challenges the UA using a Digest Authentication scheme to authenticate that the UA knows Bob's shared secret. Once the UA is authenticated, the credential server stores Bob's credentials.
Bob的UA（Bob2）与凭证服务器进行传输层安全（TLS）[RFC5246]握手，以验证UA是否连接到正确的凭证服务器。然后，Bob的UA发布他新创建或更新的凭证。凭证服务器使用摘要身份验证方案向UA发出挑战，以验证UA是否知道Bob的共享秘密。UA通过身份验证后，凭证服务器将存储Bob的凭证。
Another of Bob's User Agents (Bob1) wants to fetch its current credentials. It does a TLS [RFC5246] handshake with the credential server to authenticate that the UA is connected to the correct credential server. Then Bob's UA subscribes for the credentials. The credential server challenges the UA to authenticate that the UA knows Bob's shared secret. Once the UA is authenticated, the credential server sends a NOTIFY that contains Bob's credentials. The private key portion of the credential may have been encrypted 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 be ready to go. Typically Bob's UA would do this when it first registers on the network.
Bob的另一个用户代理（Bob1）希望获取其当前凭据。它与凭证服务器进行TLS[RFC5246]握手，以验证UA是否连接到正确的凭证服务器。然后Bob的UA订阅凭证。凭证服务器要求UA验证UA是否知道Bob的共享秘密。UA通过身份验证后，凭证服务器将发送包含Bob凭证的通知。凭证的私钥部分可能已使用只有Bob的UA（而不是凭证服务器）知道的秘密进行了加密。在这种情况下，一旦Bob的UA解密了私钥，就可以开始了。通常，Bob的UA在首次注册网络时会这样做。
Some time later Alice decides that she wishes to discover Bob's certificate so that she can send him an encrypted message or so that she can verify the signature on a message from Bob. Alice's UA sends a SUBSCRIBE message to Bob's AOR. The proxy in Bob's domain routes this to the credential server via an "authentication service" as defined in [RFC4474]. The credential server returns a NOTIFY that contains Bob's public certificate in the body. This is routed through an authentication service that signs that this message really can validly claim to be from the AOR "sip:bob@example.com". Alice's UA receives the certificate and can use it to encrypt a message to Bob.
一段时间后，Alice决定要发现Bob的证书，以便向他发送加密消息，或者验证Bob消息上的签名。Alice的UA向Bob的AOR发送订阅消息。Bob域中的代理通过[RFC4474]中定义的“身份验证服务”将其路由到凭证服务器。凭证服务器返回一个通知，其中正文中包含Bob的公共证书。这是通过一个身份验证服务路由的，该服务表明此消息确实可以有效地声明来自AOR“sip:bob@example.com". Alice的UA接收证书，并可以使用它对发送给Bob的消息进行加密。
It is critical to understand that the only way that Alice can trust that the certificate really is the one for Bob and that the NOTIFY has not been spoofed is for Alice to check that the Identity [RFC4474] header field value is correct.
关键是要理解，Alice能够信任证书确实是Bob的证书，并且NOTIFY没有被伪造的唯一方法是Alice检查Identity[RFC4474]头字段值是否正确。
The mechanism described in this document works for both self-signed certificates and certificates signed by well known certification authorities. In order to deploy certificates signed by well known certification authorities, certification authorities would have to support adding SIP URIs to the SubjectAltName of the certificates they generate. This is something that has been rarely implemented by commercial certification authorities. However, most UAs would only use self-signed certificates and would use an authentication service as described in [RFC4474] to provide a strong binding of an AOR to the certificates.
本文档中描述的机制适用于自签名证书和由知名证书颁发机构签名的证书。为了部署由知名证书颁发机构签名的证书，证书颁发机构必须支持将SIPURI添加到它们生成的证书的SubjectAltName中。商业认证机构很少实现这一点。然而，大多数UAs将只使用自签名证书，并使用[RFC4474]中所述的身份验证服务来提供AOR与证书的强绑定。
The mechanisms described in this document allow for three different styles of deployment:
The mechanisms described in this document allow for three different styles of deployment:translate error, please retry
1. Deployments where the credential server only stores certificates and does not store any private key information. If the deployment had users with multiple devices, some other scheme (perhaps even manual provisioning) would be used to get the right private keys onto all the devices that a user employs.
1. 凭据服务器仅存储证书而不存储任何私钥信息的部署。如果部署具有多个设备的用户，则将使用其他一些方案（甚至可能是手动配置）将正确的私钥添加到用户使用的所有设备上。
2. Deployments where the credential server stores certificates and also stores an encrypted version of the private keys. The credential server would not know or need the password phrase for decrypting the private key. The credential server would help move the private keys between devices, but the user would need to enter a password phrase on each device to allow that device to decrypt (and encrypt) the private key information.
2. 凭据服务器存储证书并存储私钥加密版本的部署。凭据服务器不知道或不需要密码短语来解密私钥。凭证服务器将有助于在设备之间移动私钥，但用户需要在每个设备上输入密码短语，以允许该设备解密（和加密）私钥信息。
3. Deployments where the credential server generates and stores the certificates and private keys. Deployments such as these may not use password phrases. Consequently, the private keys are not encrypted inside the PKCS #8 objects. This style of deployment would often have the credential server, instead of the devices, create the credentials.
3. 凭据服务器生成并存储证书和私钥的部署。此类部署可能不使用密码短语。因此，PKCS#8对象内的私钥没有加密。这种部署方式通常由凭据服务器（而不是设备）创建凭据。
When a User Agent wishes to discover some other user's certificate, it subscribes to the "certificate" SIP event package as described in Section 6 to get the certificate. While the subscription is active, if the certificate is updated, the Subscriber will receive the updated certificate in a notification.
当用户代理希望发现其他用户的证书时，它订阅第6节中描述的“证书”SIP事件包以获取证书。当订阅处于活动状态时，如果证书已更新，订阅服务器将在通知中收到更新的证书。
The Subscriber needs to decide how long it is willing to trust that the certificate it receives is still valid. If the certificate is revoked before it expires, the Notifier will send a notification with an empty body to indicate that the certificate is no longer valid. If the certificate is renewed before it expires, the Notifier will send a notification with a body containing the new certificate. Note that the Subscriber might not receive the notification if an attacker blocks this traffic. The amount of time that the Subscriber caches a certificate SHOULD be configurable. A default of one day is RECOMMENDED.
订阅者需要决定它愿意相信它收到的证书仍然有效的时间。如果证书在到期前被吊销，通知程序将发送一个正文为空的通知，以指示证书不再有效。如果证书在到期前续订，通知程序将发送一个包含新证书的正文的通知。请注意，如果攻击者阻止此流量，订阅服务器可能不会收到通知。订阅服务器缓存证书的时间量应该是可配置的。建议默认为一天。
Note that the actual duration of the subscription is unrelated to the caching time or validity time of the corresponding certificate. Allowing subscriptions to persist after a certificate is no longer valid ensures that Subscribers receive the replacement certificate in a timely fashion. The Notifier could return an immediate
请注意，订阅的实际持续时间与相应证书的缓存时间或有效期无关。允许订阅在证书不再有效后保持，可确保订阅服务器及时收到替换证书。通知程序可以返回即时消息
notification with the certificate in response to a subscribe request and then immediately terminate subscription, setting the reason parameter to "probation". The Subscriber will have to periodically poll the Notifier to verify the validity of the certificate.
使用证书通知以响应订阅请求，然后立即终止订阅，并将原因参数设置为“试用”。订户必须定期轮询通知程序以验证证书的有效性。
If the UA uses a cached certificate in a request and receives a 437 (Unsupported Certificate) response, it SHOULD remove the certificate it used from the cache and attempt to fetch the certificate again. If the certificate is changed, then the UA SHOULD retry the original request with the new certificate. This situation usually indicates that the certificate was recently updated, and that the Subscriber has not received a corresponding notification. If the certificate fetched is the same as the one that was previously in the cache, then the UA SHOULD NOT try the request again. This situation can happen when the request is retargeted to a different user than the original request. The 437 response is defined in [RFC4474].
如果UA在请求中使用缓存的证书并收到437（不受支持的证书）响应，它应该从缓存中删除它使用的证书并尝试再次获取该证书。如果证书已更改，则UA应使用新证书重试原始请求。这种情况通常表示证书是最近更新的，并且订阅者没有收到相应的通知。如果获取的证书与以前缓存中的证书相同，则UA不应再次尝试该请求。当请求重定目标为与原始请求不同的用户时，可能会发生这种情况。437响应在[RFC4474]中定义。
Note: A UA that has a presence list MAY want to subscribe to the certificates of all the presentities in the list when the UA subscribes to their presence, so that when the user wishes to contact a presentity, the UA will already have the appropriate certificate. Future specifications might consider the possibility of retrieving the certificates along with the presence documents.
注意：具有存在列表的UA可能希望在UA订阅其存在时订阅列表中所有存在实体的证书，以便当用户希望联系存在实体时，UA将已经拥有适当的证书。未来的规范可能考虑与存在文档一起检索证书的可能性。
The details of how a UA deals with receiving encrypted messages is outside the scope of this specification. It is worth noting that if Charlie's User Agent Server (UAS) receives a request that is encrypted to Bob, it would be valid and legal for that UA to send a 302 redirecting the call to Bob.
UA如何处理接收加密消息的详细信息不在本规范的范围内。值得注意的是，如果Charlie的用户代理服务器（UAS）接收到对Bob加密的请求，则UA向Bob发送302重定向呼叫将是有效和合法的。
UAs discover their own credentials by subscribing to their AOR with an event type of "credential" as described in Section 7. After a UA registers, it SHOULD retrieve its credentials by subscribing to them as described in Section 6.5.
UAs通过使用事件类型“凭证”订阅AOR来发现自己的凭证，如第7节所述。UA注册后，应按照第6.5节所述通过订阅来检索其凭证。
When a UA discovers its credential, the private key information might be encrypted with a password phrase. The UA SHOULD request that the user enter the password phrase on the device, and the UA MAY cache this password phrase for future use.
当UA发现其凭证时，可能会使用密码短语对私钥信息进行加密。UA应请求用户在设备上输入密码短语，UA可缓存该密码短语以备将来使用。
There are several different cases in which a UA should generate a new credential:
UA应生成新凭证的情况有几种：
o If the UA receives a NOTIFY with no body for the credential package.
o 如果UA收到凭证包无正文的通知。
o If the certificate has expired.
o 如果证书已过期。
o If the certificate's notAfter date is within the next 600 seconds, the UA SHOULD attempt to create replacement credentials. The UA does this by waiting a random amount of time between 0 and 300 seconds. If no new credentials have been received in that time, the UA creates new credentials to replace the expiring ones and sends them in a PUBLISH request following the rules for modifying event state as described in Section 4.4 of [RFC3903].
o 如果证书的notAfter日期在接下来的600秒内，UA应尝试创建替换凭据。UA通过在0到300秒之间随机等待一段时间来实现这一点。如果在此期间未收到新凭据，UA将创建新凭据以替换过期凭据，并按照[RFC3903]第4.4节中所述的修改事件状态的规则，在发布请求中发送这些凭据。
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 one.
o 如果设备的用户已通过用户界面指示他们希望撤销当前证书并颁发新证书。
Credentials are created by constructing a new key pair that will require appropriate randomness as described in [RFC4086] and then creating a certificate as described in Section 10.6. The UA MAY encrypt the private key with a password phrase supplied by the user as specified in Section 10.5. Next, the UA updates the user's credential by sending a PUBLISH [RFC3903] request with the credentials or just the certificate as described in Section 7.8.
创建凭证的方法是：按照[RFC4086]中的说明，构造需要适当随机性的新密钥对，然后按照第10.6节中的说明创建证书。UA可使用第10.5节规定的用户提供的密码短语对私钥进行加密。接下来，UA通过发送带有凭证的发布[RFC3903]请求或第7.8节中描述的证书来更新用户凭证。
If a UA wishes to revoke the existing certificate without publishing a new one, it MUST send a PUBLISH with an empty body to the credential server.
如果UA希望在不发布新证书的情况下撤销现有证书，则必须向凭据服务器发送带有空正文的发布。
This document defines a SIP event package as defined in [RFC3265]. The event-package token name for this package is:
本文档定义了[RFC3265]中定义的SIP事件包。此包的事件包令牌名称为：
certificate
证明书
This package does not define any SUBSCRIBE bodies.
此包不定义任何订阅主体。
Subscriptions to this event package can range from no time to weeks. Subscriptions in days are more typical and are RECOMMENDED. The default subscription duration for this event package is one day.
订阅此事件包的时间从零到数周不等。以天为单位的订阅更为典型，建议使用。此事件包的默认订阅持续时间为一天。
The credential service is encouraged to keep the subscriptions active for AORs that are communicating frequently, but the credential service MAY terminate the subscription at any point in time.
鼓励凭证服务为频繁通信的AOR保持订阅活动，但凭证服务可以在任何时间点终止订阅。
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 contains the certificate, unless an Accept header field has negotiated some other type. The Content-Disposition MUST be set to "signal" as defined in [RFC3204].
此包的NOTIFY请求正文必须为空或包含包含证书的应用程序/pkix证书正文（如[RFC2585]中定义），除非Accept标头字段协商了其他类型。内容配置必须设置为[RFC3204]中定义的“信号”。
A future extension MAY define other NOTIFY bodies. If no "Accept" header field is present in the SUBSCRIBE, the body type defined in this document MUST be assumed.
将来的扩展可能会定义其他通知机构。如果订阅中不存在“接受”标题字段，则必须采用本文档中定义的正文类型。
Implementations that generate large notifications are reminded to follow the message size restrictions for unreliable transports articulated in Section 18.1.1 of [RFC3261].
提醒生成大型通知的实现遵守[RFC3261]第18.1.1节中阐述的不可靠传输的消息大小限制。
A UA discovers a certificate by sending a SUBSCRIBE request with an event type of "certificate" to the AOR for which a certificate is 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 can be notified about changes or revocations to the certificate.
UA通过向需要证书的AOR发送事件类型为“证书”的订阅请求来发现证书。通常，UA只要计划使用和缓存证书，就会一直订阅该证书，以便UA可以收到证书更改或撤销的通知。
Subscriber User Agents will typically subscribe to certificate information for a period of hours or days, and automatically attempt to re-subscribe just before the subscription is completely expired.
订户用户代理通常会在数小时或数天内订阅证书信息，并在订阅完全过期之前自动尝试重新订阅。
When a user de-registers from a device (logoff, power down of a mobile device, etc.), Subscribers SHOULD unsubscribe by sending a SUBSCRIBE request with an Expires header field of zero.
当用户从设备注销（注销、关闭移动设备电源等）时，订阅者应通过发送带有Expires标头字段零的订阅请求来取消订阅。
When a SIP credential server receives a SUBSCRIBE request with the certificate event-type, it is not necessary to authenticate the subscription request. The Notifier MAY limit the duration of the subscription to an administrator-defined period of time. The duration of the subscription does not correspond in any way to the period for which the certificate will be valid.
当SIP凭据服务器接收到具有证书事件类型的订阅请求时，无需对订阅请求进行身份验证。通知程序可以将订阅的持续时间限制为管理员定义的时间段。订阅的持续时间与证书的有效期不一致。
When the credential server receives a SUBSCRIBE request for a certificate, it first checks to see if it has credentials for the requested URI. If it does not have a certificate, it returns a NOTIFY request with an empty message body.
当凭证服务器收到证书的订阅请求时，它首先检查是否具有所请求URI的凭证。如果它没有证书，则返回一个消息正文为空的NOTIFY请求。
Immediately after a subscription is accepted, the Notifier MUST send a NOTIFY with the current certificate, or an empty body if no certificate is available for the target user. In either case it forms a NOTIFY with the From header field value set to the value of the To header field in the SUBSCRIBE request. This server sending the NOTIFY needs either to implement an authentication service (as described in SIP Identity [RFC4474]) or else the server needs to be set up such that the NOTIFY request will be sent through an authentication service. Sending the NOTIFY request through the authentication service requires the SUBSCRIBE request to have been routed through the authentication service, since the NOTIFY is sent within the dialog formed by the subscription.
接受订阅后，通知程序必须立即使用当前证书发送通知，如果目标用户没有可用的证书，则必须发送空正文。在这两种情况下，它都会形成一个通知，将From头字段值设置为SUBSCRIBE请求中to头字段的值。发送通知的服务器需要实现身份验证服务（如SIP Identity[RFC4474]中所述），或者需要设置服务器，以便通过身份验证服务发送通知请求。通过身份验证服务发送通知请求要求订阅请求已通过身份验证服务路由，因为通知是在订阅形成的对话框中发送的。
The resulting NOTIFY will contain an application/pkix-cert body that contains the requested certificate. The UA MUST follow the procedures in Section 10.3 to decide if the received certificate can be used. The UA needs to cache this certificate for future use. The maximum length of time for which it should be cached is discussed in Section 10.1. The certificate MUST be removed from the cache if the certificate has been revoked (if a NOTIFY with an empty body is received), or if it is updated by a subsequent NOTIFY. The UA MUST check that the NOTIFY is correctly signed by an authentication service as described in [RFC4474]. If the identity asserted by the authentication service does not match the AOR that the UA subscribed to, the certificate in the NOTIFY is discarded and MUST NOT be used.
生成的通知将包含一个包含请求的证书的应用程序/pkix证书正文。UA必须遵循第10.3节中的程序，以决定是否可以使用收到的证书。UA需要缓存此证书以备将来使用。第10.1节讨论了应缓存的最大时间长度。如果证书已被吊销（如果接收到正文为空的通知），或者如果该证书已由后续通知更新，则必须从缓存中删除该证书。UA必须检查NOTIFY是否由[RFC4474]中所述的身份验证服务正确签名。如果身份验证服务断言的身份与UA订阅的AOR不匹配，则NOTIFY中的证书将被丢弃，并且不得使用。
This event package does not permit forked requests. At most one subscription to this event type is permitted per resource.
此事件包不允许分叉请求。每个资源最多允许一个对此事件类型的订阅。
Notifiers SHOULD NOT generate NOTIFY requests more frequently than once per minute.
通知程序生成通知请求的频率不应超过每分钟一次。
The credential server described in this section that serves certificates is a state agent as defined in [RFC3265], and implementations of the credential server MUST be implemented as a state agent.
本节中描述的提供证书的凭证服务器是[RFC3265]中定义的状态代理，凭证服务器的实现必须实现为状态代理。
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.
实施者不得将事件列表扩展[RFC4662]用于此事件类型。这种方法不可能奏效，因为身份验证服务必须同时声明几个不同的身份。
There are no additional requirements on a SIP proxy, other than to transparently forward the SUBSCRIBE and NOTIFY requests as required in SIP. This specification describes the proxy, authentication service, and credential service as three separate services, but it is certainly possible to build a single SIP network element that performs all of these services at the same time.
除了按照SIP中的要求透明地转发订阅和通知请求外，对SIP代理没有其他要求。本规范将代理、身份验证服务和凭证服务描述为三个独立的服务，但当然可以构建一个同时执行所有这些服务的SIP网元。
This document defines a SIP event package as defined in [RFC3265]. The event-package token name for this package is:
本文档定义了[RFC3265]中定义的SIP事件包。此包的事件包令牌名称为：
credential
资质
This package does not define any SUBSCRIBE bodies.
此包不定义任何订阅主体。
Subscriptions to this event package can range from hours to one week. Subscriptions in days are more typical and are RECOMMENDED. The default subscription duration for this event package is one day.
此事件包的订阅时间从小时到一周不等。以天为单位的订阅更为典型，建议使用。此事件包的默认订阅持续时间为一天。
The credential service SHOULD keep subscriptions active for UAs that are currently registered.
凭证服务应使当前注册的UAs的订阅保持活动状态。
An implementation compliant to this specification MUST support the multipart/mixed type (see [RFC2046]). This allows a notification to contain multiple resource documents including at a minimum the application/pkix-cert body with the certificate and an application/ pkcs8 body that has the associated private key information for the certificate. The application/pkcs8 media type is defined in [RFC5958].
符合本规范的实现必须支持多部分/混合类型（请参见[RFC2046]）。这允许通知包含多个资源文档，至少包括带有证书的应用程序/pkix证书正文和具有证书相关私钥信息的应用程序/pkcs8正文。[RFC5958]中定义了应用程序/pkcs8媒体类型。
The absence of an Accept header in the SUBSCRIBE indicates support for multipart/mixed and the content types application/pkix-cert and application/pkcs8. If an Accept header is present, these types MUST be included, in addition to any other types supported by the client.
SUBSCRIBE中缺少Accept标头表示支持多部分/混合以及内容类型application/pkix cert和application/pkcs8。如果存在Accept标头，则除了客户端支持的任何其他类型外，还必须包括这些类型。
The application/pkix-cert body is a Distinguished Encoding Rules (DER)-encoded X.509v3 certificate [RFC2585]. The application/pkcs8 body contains a DER-encoded [RFC5958] object that contains the private key. The PKCS #8 objects MUST be of type PrivateKeyInfo. The integrity and confidentiality of the PKCS #8 objects are provided by the TLS transport. The transport encoding of all the MIME bodies is binary.
应用程序/pkix证书正文是一个可分辨编码规则（DER）编码的X.509v3证书[RFC2585]。application/pkcs8正文包含一个DER编码的[RFC5958]对象，该对象包含私钥。PKCS#8对象必须为PrivateKeyInfo类型。PKCS#8对象的完整性和机密性由TLS传输提供。所有MIME主体的传输编码都是二进制的。
A Subscriber User Agent will subscribe to its credential information for a period of hours or days and will automatically attempt to re-subscribe before the subscription has completely expired.
订户用户代理将在数小时或数天内订阅其凭据信息，并将在订阅完全过期之前自动尝试重新订阅。
The Subscriber SHOULD subscribe to its credentials whenever a new user becomes associated with the device (a new login). The Subscriber SHOULD also renew its subscription immediately after a reboot, or when the Subscriber's network connectivity has just been re-established.
每当新用户与设备关联时（新登录），订阅者应订阅其凭据。订户还应在重新启动后或刚重新建立订户的网络连接时立即续订。
The UA needs to authenticate with the credential service for these operations. 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 domain of the credential service. The UA MUST NOT connect through an intermediate proxy to the credential service. The UA may be configured with a specific name for the credential service; otherwise, normal SIP routing is used. As described in RFC 3261, the TLS connection needs to present a certificate that matches the
UA需要通过凭证服务对这些操作进行身份验证。UA必须使用TLS直接连接到充当凭证服务的服务器或凭证服务域的权威服务器。UA不得通过中间代理连接到凭证服务。UA可以配置有凭证服务的特定名称；否则，将使用正常的SIP路由。如RFC 3261中所述，TLS连接需要提供与
expected name of the server to which the connection was formed, so that the UA knows it is talking to the correct server. Failing to do this may result in the UA publishing its private key information to an attacker. The credential service will authenticate the UA using the usual SIP Digest mechanism, so the UA can expect to receive a SIP challenge to the SUBSCRIBE or PUBLISH requests.
与之建立连接的服务器的预期名称，以便UA知道它正在与正确的服务器通信。否则，UA可能会将其私钥信息发布给攻击者。凭证服务将使用通常的SIP摘要机制对UA进行身份验证，因此UA可以预期收到对订阅或发布请求的SIP质询。
When a credential service receives a SUBSCRIBE for a credential, the credential service has to authenticate and authorize the UA, and validate that adequate transport security is being used. Only a UA that can authenticate as being able to register as the AOR is authorized to receive the credentials for that AOR. The credential service MUST challenge the UA to authenticate the UA and then decide if it is authorized to receive the credentials. If authentication is successful, the Notifier MAY limit the duration of the subscription to an administrator-defined period of time. The duration of the subscription MUST NOT be larger than the length of time for which the certificate is still valid. The Expires header field SHOULD be set so that it is not longer than the notAfter date in the certificate.
当凭证服务收到凭证订阅时，凭证服务必须对UA进行身份验证和授权，并验证是否使用了足够的传输安全性。只有能够认证为能够注册为AOR的UA才有权接收该AOR的凭据。凭证服务必须质询UA对UA进行身份验证，然后决定其是否有权接收凭证。如果身份验证成功，通知程序可以将订阅的持续时间限制为管理员定义的时间段。订阅的持续时间不得大于证书仍然有效的时间长度。应设置Expires标头字段，使其不超过证书中的notAfter日期。
Once the UA has authenticated with the credential service and the subscription is accepted, the credential service MUST immediately send a Notify request. The authentication service is applied to this NOTIFY request in the same way as the certificate subscriptions. If the credential is revoked, the credential service MUST terminate any current subscriptions and force the UA to re-authenticate by sending a NOTIFY with its Subscription-State header field set to "terminated" and a reason parameter set to "deactivated". (This causes a Subscriber to retry the subscription immediately.) This is so that if a secret for retrieving the credentials gets compromised, the rogue UA will not continue to receive credentials after the compromised secret has been changed.
UA通过凭证服务进行身份验证并接受订阅后，凭证服务必须立即发送通知请求。身份验证服务以与证书订阅相同的方式应用于此通知请求。如果凭据被吊销，则凭据服务必须终止任何当前订阅，并通过发送一个通知（其订阅状态标头字段设置为“terminated”，原因参数设置为“deactivated”）来强制UA重新验证。（这会导致订阅者立即重试订阅。）这样，如果用于检索凭据的机密被泄露，流氓UA将不会在泄露的机密被更改后继续接收凭据。
Any time the credentials for this URI change, the credential service MUST send a new NOTIFY to any active subscriptions with the new credentials.
每当此URI的凭据发生更改时，凭据服务必须使用新凭据向任何活动订阅发送新通知。
The notification MUST be sent over TLS so that it is integrity protected, and the TLS needs to be directly connected between the UA and the credential service with no intermediaries.
通知必须通过TLS发送，以使其受到完整性保护，并且TLS需要在UA和凭证服务之间直接连接，无需中介。
A User Agent SHOULD be configurable to control whether it publishes the credential for a user or just the user's certificate.
用户代理应该是可配置的，以控制它是发布用户的凭据还是仅发布用户的证书。
When publishing just a certificate, the body contains an application/ pkix-cert. When publishing a credential, the body contains a multipart/mixed containing both an application/pkix-cert and an application/pkcs8 body.
仅发布证书时，正文包含应用程序/pkix-cert。发布凭据时，正文包含多部分/混合证书，其中包含应用程序/pkix证书和应用程序/pkcs8正文。
When the UA sends the PUBLISH [RFC3903] request, it needs to do the following:
UA发送发布[RFC3903]请求时，需要执行以下操作：
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 domain of the credential service. The UA MUST NOT connect through an intermediate proxy to the credential service.
o UA必须使用TLS直接连接到充当凭证服务的服务器或凭证服务域的权威服务器。UA不得通过中间代理连接到凭证服务。
o The Expires header field value in the PUBLISH request SHOULD be set to match the time for which the certificate is valid.
o 发布请求中的Expires标头字段值应设置为与证书的有效时间相匹配。
o If the certificate includes Basic Constraints, it SHOULD set the cA boolean to false.
o 如果证书包含基本约束，则应将cA布尔值设置为false。
When the credential service receives a PUBLISH request to update credentials, it MUST authenticate and authorize this request in the same way as for subscriptions for credentials. If the authorization succeeds, then the credential service MUST perform the following checks on the certificate:
当凭证服务接收到更新凭证的发布请求时，它必须以与凭证订阅相同的方式对此请求进行身份验证和授权。如果授权成功，则凭据服务必须对证书执行以下检查：
o The notBefore validity time MUST NOT be in the future.
o notBefore有效期不得在将来。
o The notAfter validity time MUST be in the future.
o notAfter有效期必须在将来。
o If a cA BasicConstraints boolean is set in the certificate, it is set to FALSE.
o 如果证书中设置了cA BasicConstraints布尔值，则该值将设置为FALSE。
If all of these succeed, the credential service updates the credential for this URI, processes all the active certificates and credential subscriptions to this URI, and generates a NOTIFY request with the new credential or certificate. Note the SubjectAltName SHOULD NOT be checked, as that would restrict which certificates could be used and offers no additional security guarantees.
如果所有这些操作都成功，则凭据服务将更新此URI的凭据，处理所有活动证书和对此URI的凭据订阅，并使用新凭据或证书生成通知请求。注意：不应检查SubjectAltName，因为这会限制可以使用哪些证书，并且不会提供额外的安全保证。
If the Subscriber submits a PUBLISH request with no body and Expires=0, this revokes the current credentials. Watchers of these credentials will receive an update with no body, indicating that they MUST stop any previously stored credentials. Note that subscriptions to the certificate package are NOT terminated; each Subscriber to the certificate package receives a notification with an empty body.
如果订阅服务器提交了一个没有正文的发布请求，并且Expires=0，则会撤消当前凭据。这些凭据的观察者将收到一个没有正文的更新，指示他们必须停止以前存储的任何凭据。请注意，对证书包的订阅不会终止；证书包的每个订户都会收到一个带有空正文的通知。
When the UA receives a valid NOTIFY request, it should replace its existing credentials with the new received ones. If the UA cannot decrypt the PKCS #8 object, it MUST send a 437 (Unsupported Certificate) response. Later, if the user provides a new password phrase for the private key, the UA can subscribe to the credentials again and attempt to decrypt with the new password phrase.
当UA收到有效的NOTIFY请求时，它应该用新收到的凭据替换其现有凭据。如果UA无法解密PKCS#8对象，则必须发送437（不支持的证书）响应。稍后，如果用户为私钥提供新密码短语，UA可以再次订阅凭据并尝试使用新密码短语解密。
This event package does not permit forked requests.
此事件包不允许分叉请求。
Notifiers SHOULD NOT generate NOTIFY requests more frequently than once per minute.
通知程序生成通知请求的频率不应超过每分钟一次。
The credential server described in this section which serves credentials is a state agent, and implementations of the credential server MUST be implemented as a state agent.
本节中描述的提供凭据的凭据服务器是状态代理，并且凭据服务器的实现必须作为状态代理来实现。
Implementers MUST NOT use the event list extension [RFC4662] with this event type.
实施者不得将事件列表扩展[RFC4662]用于此事件类型。
The behavior is identical to behavior described for certificate subscriptions in Section 6.12.
该行为与第6.12节中描述的证书订阅行为相同。
The [RFC4474] authentication service defined a signature algorithm based on SHA-1 called rsa-sha1. This specification adds a signature algorithm that is roughly the same but based on SHA-256 and called rsa-sha256.
[RFC4474]身份验证服务定义了一种基于SHA-1的签名算法，称为rsa-sha1。此规范添加了一个签名算法，该算法大致相同，但基于SHA-256，称为rsa-sha256。
When using the rsa-sha256 algorithm, the signature MUST be computed in exactly the same way as described in Section 9 of [RFC4474] with the exception that instead of using sha1WithRSAEncryption, the computation is done using sha256WithRSAEncryption as described in [RFC5754].
当使用rsa-sha256算法时，签名的计算方式必须与[RFC4474]第9节中所述的方式完全相同，唯一的例外是使用[RFC5754]中所述的sha256 with rsa加密代替SHA1 with rsa加密进行计算。
Implementations of this specification MUST implement both rsa-sha1 and rsa-sha256. The IANA registration for rsa-sha256 is defined in Section 11.3.
本规范的实现必须同时实现rsa-sha1和rsa-sha256。rsa-sha256的IANA注册定义见第11.3节。
In all of these examples, large parts of the messages are omitted to highlight what is relevant to this document. The lines in the examples that are prefixed by $ represent encrypted blocks of data.
在所有这些示例中，省略了大部分消息，以突出显示与本文档相关的内容。示例中以$为前缀的行表示加密的数据块。
In this example, Alice sends Bob an encrypted page mode instant message. Alice does not already have Bob's public key from previous communications, so she fetches Bob's public key from Bob's credential service:
在本例中，Alice向Bob发送一条加密的页面模式即时消息。Alice尚未从以前的通信中获得Bob的公钥，因此她从Bob的凭据服务获取Bob的公钥：
SUBSCRIBE sip:bob@biloxi.example.com SIP/2.0 ... Event: certificate
订阅sip：bob@biloxi.example.comSIP/2.0。。。事件：证书
The credential service responds with the certificate in a NOTIFY.
凭证服务在通知中使用证书进行响应。
NOTIFY alice@atlanta.example.com SIP/2.0
Subscription-State: active; expires=7200
....
From: <sip:bob@biloxi.example.com>;tag=1234
Identity: ".... stuff removed ...."
Identity-Info: <https://atlanta.example.com/cert>;alg=rsa-sha256
....
Event: certificate
Content-Type: application/pkix-cert
Content-Disposition: signal
NOTIFY alice@atlanta.example.com SIP/2.0
Subscription-State: active; expires=7200
....
From: <sip:bob@biloxi.example.com>;tag=1234
Identity: ".... stuff removed ...."
Identity-Info: <https://atlanta.example.com/cert>;alg=rsa-sha256
....
Event: certificate
Content-Type: application/pkix-cert
Content-Disposition: signal
< certificate data >
<证书数据>
Next, Alice sends a SIP MESSAGE to Bob and can encrypt the body using Bob's public key as shown below.
接下来，Alice向Bob发送一条SIP消息，并可以使用Bob的公钥对正文进行加密，如下所示。
MESSAGE sip:bob@biloxi.example.com SIP/2.0
...
Content-Type: application/pkcs7-mime
Content-Disposition: render
MESSAGE sip:bob@biloxi.example.com SIP/2.0
...
Content-Type: application/pkcs7-mime
Content-Disposition: render
$ Content-Type: text/plain $ $ < encrypted version of "Hello" >
$ 内容类型：text/plain$$<加密版的“Hello”>
When Alice's UA wishes to publish Alice's certificate and private key to the credential service, it sends a PUBLISH request like the one below. This must be sent over a TLS connection directly to the domain of the credential service. The credential service presents a certificate where the SubjectAltName contains an entry that matches the domain name in the request line of the PUBLISH request and challenges the request to authenticate her.
当Alice的UA希望将Alice的证书和私钥发布到凭证服务时，它会发送一个发布请求，如下所示。这必须通过TLS连接直接发送到凭据服务的域。凭证服务提供一个证书，其中SubjectAltName包含一个与发布请求请求行中的域名匹配的条目，并对请求进行验证。
PUBLISH sips:alice@atlanta.example.com SIP/2.0
...
Event: credential
Content-Type: multipart/mixed;boundary=boundary
Content-Disposition: signal
PUBLISH sips:alice@atlanta.example.com SIP/2.0
...
Event: credential
Content-Type: multipart/mixed;boundary=boundary
Content-Disposition: signal
--boundary Content-ID: 123 Content-Type: application/pkix-cert
--边界内容ID:123内容类型：应用程序/pkix证书
< Public certificate for Alice > --boundary Content-ID: 456 Content-Type: application/pkcs8
<Alice公共证书>--边界内容ID:456内容类型：应用程序/pkcs8
< Private Key for Alice > --boundary
<Alice私钥>--边界
If one of Alice's UAs subscribes to the credential event, the credential service will challenge the request to authenticate her, and the NOTIFY will include a body similar to the one in the PUBLISH example above.
如果Alice的一个UAs订阅了凭证事件，凭证服务将质询对她的身份验证请求，通知将包括一个类似于上面发布示例中的主体。
The high-level message flow from a security point of view is summarized in the following figure. The 200 responses are removed from the figure, as they do not have much to do with the overall security.
下图总结了从安全角度来看的高级消息流。图中删除了200个响应，因为它们与总体安全性关系不大。
In this figure, authC refers to authentication and authZ refers to authorization.
在该图中，authC表示身份验证，authZ表示授权。
Alice Server Bob UA
| | TLS Handshake | 1) Client authC/Z server
| |<---------------->|
| | PUBLISH | 2) Client sends request
| |<-----------------| (write credential)
| | Digest Challenge | 3) Server challenges client
| |----------------->|
| | PUBLISH + Digest | 4) Server authC/Z client
| |<-----------------|
| | time... |
| | |
| | TLS Handshake | 5) Client authC/Z server
| |<---------------->|
| | SUBSCRIBE | 6) Client sends request
| |<-----------------| (read credential)
| | Digest Challenge | 7) Server challenges client
| |----------------->|
| | SUBSCRIBE+Digest | 8) Server authC/Z client
| |<-----------------|
| | NOTIFY | 9) Server returns credential
| |----------------->|
| |
| SUBSCRIBE | 10) Client requests certificate
|---------->|
| |
|NOTIFY+AUTH| 11) Server returns user's certificate and signs that
|<----------| it is valid using certificate for the domain
| |
Alice Server Bob UA
| | TLS Handshake | 1) Client authC/Z server
| |<---------------->|
| | PUBLISH | 2) Client sends request
| |<-----------------| (write credential)
| | Digest Challenge | 3) Server challenges client
| |----------------->|
| | PUBLISH + Digest | 4) Server authC/Z client
| |<-----------------|
| | time... |
| | |
| | TLS Handshake | 5) Client authC/Z server
| |<---------------->|
| | SUBSCRIBE | 6) Client sends request
| |<-----------------| (read credential)
| | Digest Challenge | 7) Server challenges client
| |----------------->|
| | SUBSCRIBE+Digest | 8) Server authC/Z client
| |<-----------------|
| | NOTIFY | 9) Server returns credential
| |----------------->|
| |
| SUBSCRIBE | 10) Client requests certificate
|---------->|
| |
|NOTIFY+AUTH| 11) Server returns user's certificate and signs that
|<----------| it is valid using certificate for the domain
| |
When the UA, labeled Bob, first created a credential for Bob, it would store this on the credential server. The UA authenticated the server using the certificates from the TLS handshake. The server authenticated the UA using a digest-style challenge with a shared secret.
当UA（标记为Bob）首次为Bob创建凭证时，它会将其存储在凭证服务器上。UA使用来自TLS握手的证书对服务器进行身份验证。服务器使用带有共享秘密的摘要式质询对UA进行身份验证。
The UA, labeled Bob, wishes to request its credentials from the server. First, it forms a TLS connection to the server, which provides integrity and privacy protection and also authenticates the
标记为Bob的UA希望从服务器请求其凭据。首先，它与服务器形成TLS连接，提供完整性和隐私保护，并对服务器进行身份验证
server to Bob's UA. Next, the UA requests its credentials using a SUBSCRIBE request. The server challenges the SUBSCRIBE Request to authenticate Bob's UA. The server and Bob's UA have a shared secret that is used for this. If the authentication is successful, the server sends the credentials to Bob's UA. The private key in the credentials may have been encrypted using a shared secret that the server does not know.
Bob的UA的服务器。接下来，UA使用订阅请求请求其凭证。服务器挑战订阅请求以验证Bob的UA。服务器和Bob的UA有一个用于此目的的共享秘密。如果身份验证成功，服务器将向Bob的UA发送凭据。凭据中的私钥可能已使用服务器不知道的共享密钥加密。
A similar process would be used for Bob's UA to publish new credentials to the server. Bob's UA would send a PUBLISH request containing the new credentials. When this happened, all the other UAs that were subscribed to Bob's credentials would receive a NOTIFY with the new credentials.
Bob的UA将使用类似的过程向服务器发布新凭据。Bob的UA将发送一个包含新凭据的发布请求。发生这种情况时，订阅Bob凭据的所有其他UAs将收到具有新凭据的通知。
Alice wishes to find Bob's certificate and sends a SUBSCRIBE to the server. The server sends the response in a NOTIFY. This does not need to be sent over a privacy or integrity protected channel, as the authentication service described in [RFC4474] provides integrity protection of this information and signs it with the certificate for the domain.
Alice希望找到Bob的证书并向服务器发送订阅。服务器以通知的形式发送响应。这不需要通过受隐私或完整性保护的通道发送，因为[RFC4474]中描述的身份验证服务提供此信息的完整性保护，并使用域的证书对其进行签名。
This whole scheme is highly dependent on trusting the operators of the credential service and trusting that the credential service will not be compromised. The security of all the users will be compromised if the credential service is compromised.
整个方案高度依赖于信任凭证服务的操作员，并相信凭证服务不会受到损害。如果凭证服务受损，所有用户的安全性都将受损。
Note: There has been significant discussion of the topic of avoiding deployments in which the credential servers store the private keys, even in some encrypted form that the credential server does not know how to decrypt. Various schemes were considered to avoid this, but they all result in either moving the problem to some other server, which does not seem to make the problem any better, or having a different credential for each device. For some deployments where each user has only one device, this is fine, but for deployments with multiple devices, it would require that when Alice went to contact Bob, Alice would have to provide messages encrypted for all of Bob's devices. The SIPPING Working Group did consider this architecture and decided it was not appropriate due both to the information it revealed about the devices and users, and to the amount of signaling required to make it work.
注意：关于避免使用凭据服务器存储私钥的部署的主题已经进行了重要的讨论，即使是以凭据服务器不知道如何解密的某种加密形式。考虑了各种方案来避免这种情况，但它们都会导致将问题转移到其他服务器（这似乎不会使问题变得更好），或者为每个设备提供不同的凭据。对于每个用户只有一台设备的某些部署，这是可以的，但对于具有多台设备的部署，需要Alice联系Bob时，Alice必须为Bob的所有设备提供加密消息。啜饮工作组确实考虑了这一架构，并认为这是不适当的，因为它所揭示的关于设备和用户的信息，以及使其工作所需的信令量。
This specification requires that TLS be used for the SIP communications to place and retrieve a UA's private key. This provides security in two ways:
本规范要求在SIP通信中使用TLS来放置和检索UA的私钥。这可以通过两种方式提供安全性：
1. Confidentiality is provided for the Digest Authentication exchange, thus protecting it from dictionary attacks.
1. 摘要身份验证交换提供了机密性，从而保护它免受字典攻击。
2. Confidentiality is provided for the private key, thus protecting it from being exposed to passive attackers.
2. 为私钥提供了机密性，从而保护其免受被动攻击者的攻击。
In order to prevent man-in-the-middle attacks, TLS clients MUST check that the SubjectAltName of the certificate for the server they connected to exactly matches the server they were trying to connect to. The TLS client must be directly connected to the correct server; otherwise, any intermediaries in the TLS path can compromise the certificate and instead provide a certificate for which the attacker knows the private key. This may lead the UA that relies on this compromised certificate to lose confidential information. Failing to use TLS or selecting a poor cipher suite (such as NULL encryption) may result in credentials, including private keys, being sent unencrypted over the network and will render the whole system useless.
为了防止中间人攻击，TLS客户端必须检查他们连接到的服务器的证书的SubjectAltName是否与他们尝试连接的服务器完全匹配。TLS客户端必须直接连接到正确的服务器；否则，TLS路径中的任何中介都可能破坏该证书，而是提供攻击者知道其私钥的证书。这可能会导致依赖此泄露证书的UA丢失机密信息。未能使用TLS或选择较差的密码套件（如空加密）可能会导致凭据（包括私钥）在网络上未加密发送，并将使整个系统无效。
The correct checking of chained certificates as specified in TLS [RFC5246] is critical for the client to authenticate the server. If the client does not authenticate that it is talking to the correct credential service, a man-in-the-middle attack is possible.
TLS[RFC5246]中规定的链式证书的正确检查对于客户端对服务器进行身份验证至关重要。如果客户端未验证它正在与正确的凭据服务进行通信，则可能会发生中间人攻击。
If a particular credential needs to be revoked, the new credential is simply published to the credential service. Every device with a copy of the old credential or certificate in its cache will have a subscription and will rapidly (order of seconds) be notified and replace its cache. Clients that are not subscribed will subscribe when they next need to use the certificate and will get the new certificate.
如果需要撤销特定凭据，则只需将新凭据发布到凭据服务。缓存中包含旧凭证或证书副本的每个设备都将有一个订阅，并将快速（秒数）收到通知并替换其缓存。未订阅的客户端将在下次需要使用证书时订阅，并将获得新证书。
It is possible that an attacker could mount a denial-of-service (DoS) attack such that the UA that had cached a certificate did not receive the NOTIFY with its revocation. To protect against this attack, the UA needs to limit how long it caches certificates. After this time, the UA would invalidate the cached information, even though no NOTIFY had ever been received due to the attacker blocking it.
攻击者可能会发起拒绝服务（DoS）攻击，使得缓存了证书的UA没有收到撤销证书的通知。为了防止这种攻击，UA需要限制其缓存证书的时间。在此之后，UA将使缓存的信息无效，即使由于攻击者阻止而从未收到通知。
The duration of this cached information is in some ways similar to a device deciding how often to check a Certificate Revocation List (CRL). For many applications, a default time of one day is
此缓存信息的持续时间在某些方面类似于设备决定检查证书吊销列表（CRL）的频率。对于许多应用程序，默认时间为一天
suggested, but for some 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 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.
UA缓存证书的时间不得超过订阅持续时间。这是为了避免UA在新凭据的通知程序被阻止更新UA时使用无效的缓存凭据。
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 encrypt a very large volume of traffic, the UA MAY choose to replace the credential with a new one before the normal expiration.
系统中的UAs会在证书即将到期时更换证书。如果UA使用相同的密钥对加密了非常大的通信量，UA可以选择在正常到期之前用新的凭据替换凭据。
When a UA wishes to discover the certificate for sip:alice@example.com, the UA subscribes to the certificate for 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 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.
当UA希望发现sip的证书时：alice@example.com，UA签署证书，用于alice@example.com并在SIP NOTIFY请求主体中接收证书。术语“原始URI”用于描述订阅请求的to头字段值中的URI。因此，在本例中，原始URI将是sip：alice@example.com.
If the certificate is signed by a trusted certification authority, and one of the names in the SubjectAltName matches the original URI, then this certificate MAY be used, but only for exactly the original URI and not for other identities found in the SubjectAltName. Otherwise, there are several steps the UA MUST perform before using this certificate.
如果证书由受信任的证书颁发机构签名，并且SubjectAltName中的一个名称与原始URI匹配，则可以使用此证书，但只能用于原始URI，而不能用于SubjectAltName中的其他标识。否则，UA在使用此证书之前必须执行几个步骤。
o The From header field in the NOTIFY request MUST match the original URI that was subscribed to.
o NOTIFY请求中的From标头字段必须与订阅的原始URI匹配。
o The UA MUST check the Identity header field as described in the Identity [RFC4474] specification to validate that bodies have not been tampered with and that an authentication service has validated this From header field.
o UA必须检查Identity[RFC4474]规范中所述的Identity header字段，以验证主体是否未被篡改，以及验证服务是否已从header字段对此进行验证。
o The UA MUST check the validity time of the certificate and stop using the certificate if it is invalid. (Implementations are reminded to verify both the notBefore and notAfter validity times.)
o UA必须检查证书的有效期，如果证书无效，则必须停止使用该证书。（提醒实现验证notBefore和notAfter有效时间。）
o The certificate MAY have several names in the SubjectAltName, but the UA MUST only use this certificate when it needs the certificate for the identity asserted by the authentication service in the NOTIFY. This means that the certificate should only be indexed in the certificate cache by the AOR that the authentication service asserted and not by the value of all the identities found in the SubjectAltName list.
o 证书在SubjectAltName中可能有多个名称，但UA必须仅在需要认证服务在NOTIFY中声明的身份的证书时使用此证书。这意味着证书只能由身份验证服务断言的AOR在证书缓存中编制索引，而不能由SubjectAltName列表中找到的所有标识的值编制索引。
These steps result in a chain of bindings that result in a trusted binding between the original AOR that was subscribed to and a public key. The original AOR is forced to match the From header field. The authentication service validates that this request did come from the identity claimed in the From header field value and that the bodies in the request that carry the certificate have not been tampered with. The certificate in the body contains the public key for the identity. Only the UA that can authenticate as this AOR, or devices with access to the private key of the domain, can tamper with this body. This stops other users from being able to provide a false public key. This chain of assertion from original URI, to From, to body, to public key is critical to the security of the mechanism described in this specification. If any of the steps above are not followed, this chain of security will be broken and the system will not work.
这些步骤会产生一个绑定链，从而在订阅的原始AOR和公钥之间产生受信任的绑定。原始AOR被强制与From头字段匹配。身份验证服务验证此请求是否来自from header字段值中声明的标识，以及请求中携带证书的实体是否未被篡改。正文中的证书包含标识的公钥。只有能够作为此AOR进行身份验证的UA，或者能够访问域私钥的设备，才能篡改此主体。这会阻止其他用户提供错误的公钥。从原始URI到from、到body、到公钥的断言链对于本规范中描述的机制的安全性至关重要。如果不遵循上述任何步骤，此安全链将被破坏，系统将无法工作。
Although the certificates used with this document need not be validatable to a trust anchor via PKIX [RFC5280] procedures, certificates that can be validated may also be distributed via this mechanism. Such certificates potentially offer an additional level of security because they can be used with the secure (and partially isolated) certification authority user verification and key issuance toolset, rather than depending on the security of generic SIP implementations.
尽管与本文档一起使用的证书不需要通过PKIX[RFC5280]过程对信任锚进行验证，但可以验证的证书也可以通过该机制分发。此类证书可能提供额外的安全级别，因为它们可以与安全（且部分隔离）的证书颁发机构用户验证和密钥颁发工具集一起使用，而不依赖于通用SIP实现的安全性。
When a relying party receives a certificate that is not self-signed, it MAY attempt to validate the certificate using the rules in Section 6 of [RFC5280]. If the certificate validates successfully and the names correctly match the user's AOR (see Section 10.6), then the implementation SHOULD provide some indication that the certificate has been validated with an external authority. In general, failure to validate a certificate via this mechanism SHOULD NOT be used as a reason to reject the certificate. However, if the certificate is revoked, then the implementation SHOULD reject it.
当依赖方收到未自签名的证书时，可尝试使用[RFC5280]第6节中的规则验证该证书。如果证书验证成功，并且名称与用户的AOR正确匹配（参见第10.6节），则实现应提供一些指示，表明证书已通过外部机构验证。通常，不应将未能通过此机制验证证书作为拒绝证书的理由。但是，如果证书被吊销，那么实现应该拒绝它。
This specification includes a mechanism that allows end users to share the same credentials across different end-user devices. This mechanism is based on the one presented in the Securely Available Credentials (SACRED) Framework [RFC3760]. While this mechanism is fully described in this document, the requirements and background are more thoroughly discussed in [RFC3760].
此规范包括一种机制，允许最终用户在不同的最终用户设备上共享相同的凭据。此机制基于安全可用凭据（神圣）框架[RFC3760]中提供的机制。虽然本文件对该机制进行了全面描述，但[RFC3760]对要求和背景进行了更深入的讨论。
Specifically, Sections 7.5, 7.6, and 7.9 follow the TLS with Client Authentication (cTLS) architecture described in Section 4.2.2 of [RFC3760]. The client authenticates the server using the server's TLS certificate. The server authenticates the client using a SIP Digest transaction inside the TLS session. The TLS sessions form a strong session key that is used to protect the credentials being exchanged.
具体而言，第7.5节、第7.6节和第7.9节遵循[RFC3760]第4.2.2节所述的TLS和客户端身份验证（cTLS）体系结构。客户端使用服务器的TLS证书对服务器进行身份验证。服务器使用TLS会话内的SIP摘要事务对客户端进行身份验证。TLS会话形成一个强会话密钥，用于保护正在交换的凭据。
Credential services SHOULD implement the server name indication extensions in [RFC4366]. As specified in [RFC5246], credential services MUST support the TLS cipher suite TLS_RSA_WITH_AES_128_CBC_SHA. In addition, they MUST support the TLS cipher suite TLS_RSA_WITH_AES_128_CBC_SHA256 as specified in [RFC5246]. If additional cipher suites are supported, then implementations MUST NOT negotiate a cipher suite that employs NULL encryption, integrity, or authentication algorithms.
凭证服务应实现[RFC4366]中的服务器名称指示扩展。如[RFC5246]所述，凭证服务必须支持TLS密码套件TLS_RSA_和_AES_128_CBC_SHA。此外，它们必须支持TLS密码套件TLS_RSA_和[RFC5246]中规定的\u AES_128_CBC_SHA256。如果支持其他密码套件，则实现不得协商使用空加密、完整性或身份验证算法的密码套件。
Implementations of TLS typically support multiple versions of the Transport Layer Security protocol as well as the older Secure Socket Layer (SSL) protocol. Because of known security vulnerabilities, clients and servers MUST NOT request, offer, or use SSL 2.0. See Appendix E.2 of [RFC5246] for further details.
TLS的实现通常支持传输层安全协议的多个版本以及较旧的安全套接字层（SSL）协议。由于已知的安全漏洞，客户端和服务器不得请求、提供或使用SSL 2.0。有关更多详细信息，请参见[RFC5246]的附录E.2。
The PKCS #8 encryption in the clients MUST implement PBES2 with a key derivation algorithm of PBKDF2 using HMAC. Clients MUST implement this HMAC with both SHA-1 [RFC3370] and SHA-256 [RFC5754]. Clients MUST implement an encryption algorithm of id-aes128-wrap-pad as defined in [RFC5649]. Some pre-standard deployments of this specification used DES-EDE2-CBC-Pad as defined in [RFC2898] so, for some implementations, it may be desirable to also support that algorithm. A different password SHOULD be used for the PKCS #8 encryption than is used for authentication of the client. It is important to choose sufficiently strong passwords. Specific advice on the password can be found in Section 6 of [RFC5959].
客户端中的PKCS#8加密必须使用HMAC使用PBKDF2密钥派生算法实现PBES2。客户机必须使用SHA-1[RFC3370]和SHA-256[RFC5754]实现此HMAC。客户端必须实现[RFC5649]中定义的id-aes128-wrap-pad加密算法。本规范的一些预标准部署使用了[RFC2898]中定义的DES-EDE2-CBC-Pad，因此，对于某些实现，可能还需要支持该算法。PKCS#8加密应使用与客户端身份验证不同的密码。选择足够强的密码非常重要。有关密码的具体建议，请参见[RFC5959]第6节。
The certificates need to be consistent with [RFC5280]. The sha1WithRSAEncryption and sha256WithRSAEncryption algorithms for the signatureAlgorithm MUST be implemented. The Issuers SHOULD be the same as the subject. Given the ease of issuing new certificates with this system, the Validity field can be relatively short. A Validity value of one year or less is RECOMMENDED. The SubjectAltName must have a URI type that is set to the SIP URL corresponding to the user AOR. It MAY be desirable to put some randomness into the length of time for which the certificates are valid so that it does not become necessary to renew all the certificates in the system at the same time.
证书需要与[RFC5280]一致。必须实现签名算法的SHA1 WITHRSA加密和SH256 WITHRSA加密算法。发行人应与主体相同。考虑到使用该系统颁发新证书的方便性，有效性字段可能相对较短。建议有效期为一年或更短。SubjectAltName的URI类型必须设置为与用户AOR对应的SIP URL。可能希望在证书有效的时间长度中加入一些随机性，以便不需要同时更新系统中的所有证书。
When creating a new key pair for a certificate, it is critical to have appropriate randomness as described in [RFC4086]. This can be challenging on some embedded devices, such as some IP phones, and implementers should pay particular attention to this point.
为证书创建新密钥对时，具有[RFC4086]中所述的适当随机性是至关重要的。这在一些嵌入式设备上可能是一个挑战，例如一些IP电话，实现人员应该特别注意这一点。
It is worth noting that a UA can discover the current time by looking at the Date header field value in the 200 response to a REGISTER request.
值得注意的是，UA可以通过查看对寄存器请求的200响应中的日期头字段值来发现当前时间。
The protection afforded private keys is a critical security factor. On a small scale, failure of devices to protect the private keys will permit an attacker to masquerade as the user or decrypt their personal information. As noted in the SACRED Framework, when stored on an end-user device, such as a diskette or hard drive, credentials SHOULD NOT be in the clear. It is RECOMMENDED that private keys be stored securely in the device, more specifically, encrypting them using tamper-resistant hardware encryption and exposing them only when required: for example, the private key is decrypted when necessary to generate a digital signature, and re-encrypted immediately to limit exposure in the RAM to a short period of time. Some implementations may limit access to private keys by prompting users for a PIN prior to allowing access to the private key.
私钥的保护是一个关键的安全因素。在小范围内，如果设备无法保护私钥，攻击者就可以伪装成用户或解密其个人信息。如神圣框架中所述，当存储在最终用户设备（如软盘或硬盘驱动器）上时，凭证不应处于透明状态。建议将私钥安全地存储在设备中，更具体地说，使用防篡改硬件加密对其进行加密，并仅在需要时公开私钥：例如，在需要生成数字签名时解密私钥，并立即重新加密，以将RAM中的暴露限制在短时间内。一些实现可能会通过在允许访问私钥之前提示用户输入PIN来限制对私钥的访问。
On the server side, the protection of unencrypted PKCS #8 objects is equally important. Failure of a server to protect the private keys would be catastrophic, as attackers with access to unencrypted PKCS #8 objects could masquerade as any user whose private key was not encrypted. Therefore, it is also recommended that the private keys be stored securely in the server, more specifically, encrypting them using tamper-resistant hardware encryption and exposing them only when required.
在服务器端，保护未加密的PKCS#8对象同样重要。服务器无法保护私钥将是灾难性的，因为访问未加密PKCS#8对象的攻击者可能伪装成私钥未加密的任何用户。因此，还建议将私钥安全地存储在服务器中，更具体地说，使用防篡改硬件加密对其进行加密，并仅在需要时公开它们。
FIPS 140-2 [FIPS-140-2] provides useful guidance on secure storage.
FIPS 140-2[FIPS-140-2]为安全存储提供了有用的指导。
One of the worst attacks against the Certificate Management Service described in this document would be if the authentication service were compromised. This attack is somewhat analogous to a certification authority being compromised in traditional PKI systems. The attacker could make a fake certificate for which it knows the private key, use it to receive any traffic for a given use, and then re-encrypt that traffic with the correct key and forward the communication to the intended receiver. The attacker would thus become a "man in the middle" in the communications.
本文档中描述的针对证书管理服务的最严重攻击之一是身份验证服务遭到破坏。这种攻击在某种程度上类似于传统PKI系统中的证书颁发机构遭到破坏。攻击者可以制作一个知道其私钥的假证书，使用它接收给定用途的任何流量，然后使用正确的密钥重新加密该流量，并将通信转发给预期的接收者。因此，攻击者将成为通信中的“中间人”。
There is not too much that can be done to protect against this type of attack. A UA MAY subscribe to its own certificate under some other identity to try to detect whether the credential server is handing out the correct certificates. It will be difficult to do this in a way that does not allow the credential server to recognize the user's UA.
为了防止这种类型的攻击，我们没有太多可以做的事情。UA可以使用其他身份订阅自己的证书，以尝试检测凭证服务器是否正在分发正确的证书。以不允许凭证服务器识别用户UA的方式执行此操作将很困难。
The UA MAY also save the fingerprints of the cached certificates and warn users when the certificates change significantly before their expiry date.
UA还可以保存缓存证书的指纹，并在证书在到期日之前发生重大变化时向用户发出警告。
The UA MAY also allow the user to see the fingerprints of the cached certificates so that they can be verified by some other out-of-band means.
UA还可以允许用户查看高速缓存证书的指纹，以便可以通过一些其他带外手段对其进行验证。
This specification defines two new event packages that IANA has added to the "Session Initiation Protocol (SIP) Event Types Namespace" registry.
该规范定义了IANA添加到“会话初始化协议（SIP）事件类型命名空间”注册表中的两个新事件包。
To: ietf-sip-events@iana.org Subject: Registration of new SIP event package
致：ietf sip-events@iana.org主题：注册新SIP事件包
Package Name: certificate
包名称：证书
Is this registration for a template-package: No
这是模板包的注册吗：否
Published Specification(s): This document
已发布规范：本文件
New Event header parameters: This package defines no new parameters
新事件头参数：此包不定义新参数
Person & email address to contact for further information:
Cullen Jennings <fluffy@cisco.com>
Person & email address to contact for further information:
Cullen Jennings <fluffy@cisco.com>
To: ietf-sip-events@iana.org Subject: Registration of new SIP event package
致：ietf sip-events@iana.org主题：注册新SIP事件包
Package Name: credential
包名称：凭证
Is this registration for a template-package: No
这是模板包的注册吗：否
Published Specification(s): This document
已发布规范：本文件
Person & email address to contact for further information:
Cullen Jennings <fluffy@cisco.com>
Person & email address to contact for further information:
Cullen Jennings <fluffy@cisco.com>
IANA added the following entry to the "Identity-Info Algorithm Parameter Values" registry.
IANA在“Identity Info算法参数值”注册表中添加了以下条目。
"alg" Parameter Name Reference
---------------------- ---------
rsa-sha256 [RFC6072]
"alg" Parameter Name Reference
---------------------- ---------
rsa-sha256 [RFC6072]
Many thanks to Eric Rescorla, Russ Housley, Jim Schaad, Rohan Mahy, and Sean Turner for significant help, discussion, and text. Many others provided useful comments and text, including Kumiko Ono, Peter Gutmann, Yaron Pdut, Aki Niemi, Magnus Nystrom, Paul Hoffman, Adina Simu, Dan Wing, Mike Hammer, Pasi Eronen, Alexey Melnikov, Tim Polk, John Elwell, Jonathan Rosenberg, and Lyndsay Campbell.
非常感谢Eric Rescorla、Russ Housley、Jim Schaad、Rohan Mahy和Sean Turner提供的重要帮助、讨论和文本。许多其他人提供了有用的评论和文本，包括小野久美子、彼得·古特曼、亚龙·普杜特、阿基·尼米、马格努斯·尼斯特罗姆、保罗·霍夫曼、阿迪娜·西姆、丹·温、迈克·哈默、帕西·埃隆、阿列克谢·梅尔尼科夫、蒂姆·波尔克、约翰·埃尔维尔、乔纳森·罗森博格和林赛·坎贝尔。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 1999.
[RFC2585]Housley，R.和P.Hoffman，“Internet X.509公钥基础设施操作协议：FTP和HTTP”，RFC 25851999年5月。
[RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG Objects", RFC 3204, December 2001.
[RFC3204]Zimmerer，E.，Peterson，J.，Vemuri，A.，Ong，L.，Audet，F.，Watson，M.，和M.Zonoun，“ISUP和QSIG对象的MIME媒体类型”，RFC 32042001年12月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[RFC3370]Housley，R.，“加密消息语法（CMS）算法”，RFC3370，2002年8月。
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[RFC3903]Niemi，A.，“事件状态发布的会话启动协议（SIP）扩展”，RFC 3903，2004年10月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474]Peterson，J.和C.Jennings，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，2006年8月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[RFC4366]Blake Wilson，S.，Nystrom，M.，Hopwood，D.，Mikkelsen，J.，和T.Wright，“传输层安全（TLS）扩展”，RFC 4366，2006年4月。
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, January 2010.
[RFC5754]Turner，S.，“将SHA2算法与加密消息语法结合使用”，RFC 5754，2010年1月。
[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm", RFC 5649, September 2009.
[RFC5649]Housley，R.和M.Dworkin，“带填充算法的高级加密标准（AES）密钥封装”，RFC 5649，2009年9月。
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 2010.
[RFC5958]Turner，S.，“非对称密钥包”，RFC 5958，2010年8月。
[RFC5959] Turner, S., "Algorithms for Asymmetric Key Package Content Type", RFC 5959, August 2010.
[RFC5959]Turner，S.“非对称密钥包内容类型的算法”，RFC 59592010年8月。
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000.
[RFC2898]Kaliski，B.，“PKCS#5：基于密码的加密规范版本2.0”，RFC 28982000年9月。
[RFC3760] Gustafson, D., Just, M., and M. Nystrom, "Securely Available Credentials (SACRED) - Credential Server Framework", RFC 3760, April 2004.
[RFC3760]Gustafson，D.，Just，M.和M.Nystrom，“安全可用凭据（神圣）-凭据服务器框架”，RFC 37602004年4月。
[RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)", RFC 3853, July 2004.
[RFC3853]Peterson，J.，“会话启动协议（SIP）的S/MIME高级加密标准（AES）要求”，RFC3853，2004年7月。
[RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, August 2006.
[RFC4662]Roach，A.，Campbell，B.，和J.Rosenberg，“资源列表的会话启动协议（SIP）事件通知扩展”，RFC 4662，2006年8月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月。
[FIPS-140-2] NIST, "Security Requirements for Cryptographic Modules", May 2001, <http://csrc.nist.gov/publications/ fips/fips140-2/fips1402.pdf>.
[FIPS-140-2]NIST，“加密模块的安全要求”，2001年5月<http://csrc.nist.gov/publications/ fips/fips140-2/fips1402.pdf>。
Authors' Addresses
作者地址
Cullen Jennings Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞西塔斯曼大道170号库伦·詹宁斯思科系统公司，邮编95134
Phone: +1 408 421-9990
EMail: fluffy@cisco.com
Phone: +1 408 421-9990
EMail: fluffy@cisco.com
Jason Fischl (editor) Skype 3210 Porter Drive Palo Alto, CA 94304 USA
杰森·菲舍尔（编辑）Skype 3210 Porter Drive Palo Alto，加利福尼亚州94304
Phone: +1-415-202-5192
EMail: jason.fischl@skype.net
Phone: +1-415-202-5192
EMail: jason.fischl@skype.net