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）ユーザーエージェント（UAが）他のユーザーの証明書を発見する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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さ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
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,
[RFC3853]によって修正され[RFC3261]は、セキュア/多目的インターネットメール拡張（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.
この仕様は、ユーザーがまだ強く証明書へのユーザーのIDを結合しながら、任意のよく知られた認証局によって署名されていない証明書を持つことができます。
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.
また、この仕様は、彼らが現在一般的に持っているよりも、IP電話などのSIPユーザエージェントは、任意の設定情報の詳細なしに自分の資格情報を登録して取得することを可能にするメカニズムを提供します。エンドユーザーは、余分な労力を消費しません。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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） - 公開鍵と、このキーにバインドされているのSubjectAltNameにおけるアイデンティティのリストを含む[RFC5280]スタイルの証明書。このドキュメントで説明証明書は、一般的に、自己署名であり、その有効性を保証するために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イベントパッケージ[RFC3265]を使用して、他のユーザの証明書に加入するSIPユーザエージェント（UAS）を可能にする「クレデンシャルサービス」と呼ばれる新たなSIPサービスを提供することです。証明書は、対応するSIP NOTIFYリクエストに加入UAに送られます。 SIPアイデンティティ[RFC4474]明細書に記載された認証サービスはNOTIFYリクエストに署名するために、送信者の代理ドメイン証明書を使用して証明書の送信者の身元を保証するために使用することができます。認証サービスは、送信者がヘッダフィールドの値から、SIPを埋めるために許可されていることをバウチングされます。メッセージの送信者は、これがヘッダーフィールド値からSIPに識別されたユーザのために適切な証明書であることをバウチングれます。資格サービスは、パブリック証明書だけでなく、ユーザーの秘密鍵を管理することができます。ユーザーが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は、資格情報を更新しているとき、共有秘密鍵を使用して資格サービスに認証します。典型的には、共有秘密は、（通常SIPダイジェスト認証を伴う）ドメインのレジストラに登録要求を認証するためにUAによって使用されるものと同じであろう。
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.
次の図は、ボブが彼のユーザエージェント（例えば、自分の携帯電話）の別の資格情報を取得し、彼のユーザエージェントの一つ（例えば、彼のラップトップ・ソフトウェア・クライアント）からの資格情報を公開した後、アリスはボブの証明書を取得し、メッセージを送信示しボブへ。 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 |
|---------->|------+------+----------------->|
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.
ボブのUA（BOB2）トランスポート層セキュリティ（TLS）[RFC5246]はUAが正しいクレデンシャルサーバに接続されていることを認証するために、信用証明書サーバとハンドシェイクありません。その後、ボブのUAは、彼の新しく作成または更新の資格情報を公開しています。信用証明書サーバは、UAは、ボブの共有秘密を知っていることを認証するためにダイジェスト認証方式を使用して、UAに挑戦します。 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.
ボブのユーザエージェント（Bob1）のもう一つは、その現在の資格情報を取得したいと考えています。これは、UAが正しい信用証明書サーバに接続されていることを認証するために、信用証明書サーバとのTLS [RFC5246]ハンドシェイクを行います。その後、ボブのUAは、資格情報をサブスクライブします。信用証明書サーバは、UAは、ボブの共有秘密を知っていることを認証するためにUAに挑戦します。 UAが認証されると、信用証明書サーバはそれがボブの資格情報が含まれているNOTIFYを送信します。資格情報の秘密鍵部分はボブのUA（とない信用証明書サーバは）知っている秘密で暗号化されている場合があります。ボブのUAは、秘密鍵を復号化したら、この場合には、行く準備ができます。それは最初にネットワーク上で登録する場合、通常、ボブの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.
しばらくアリスは、彼女は彼女が彼に暗号化されたメッセージを送ることができるように、または彼女はボブからのメッセージに署名を検証できるように、ボブの証明書を発見したいと判断しました。アリスのUAは、BobのAORにSUBSCRIBEメッセージを送信します。 [RFC4474]で定義されている「認証サービス」を経由して信用証明書サーバへのBobのドメインルートこれでプロキシ。信用証明書サーバは、それが体内でボブの公開証明書が含まれているNOTIFYを返します。これは、このメッセージが本当に有効にAOR「：bob@example.com一口」からのものであると主張することができるという署名認証サービスを介してルーティングされます。アリスのUAは、証明書を受け取り、ボブへのメッセージを暗号化するためにそれを使用することができます。
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.
アリスがアイデンティティ[RFC4474]ヘッダフィールドの値が正しいことを確認するアリスは、証明書が本当にボブのための1つであることを信頼できるとNOTIFYことがスプーフィングされていない唯一の方法であることを理解することが重要です。
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.
この文書で説明するメカニズムはよく知られた認証局によって署名された自己署名証明書と証明書の両方で動作します。よく知られた証明機関によって署名された証明書を展開するためには、証明機関は、彼らが生成された証明書ののSubjectAltNameにSIP URIを追加をサポートしなければなりません。これはほとんどの商用証明機関によって実装されていないものです。しかし、ほとんどのUAは、自己署名証明書を使用して、[RFC4474]に記載されるように証明書にAORの強力な結合を提供するために、認証サービスを使用するであろう。
The mechanisms described in this document allow for three different styles of deployment:
このドキュメントで説明するメカニズムは、展開の3つの異なるスタイルを可能に：
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.
加入者は、受信した証明書がまだ有効であることを信頼して喜んでどのくらいかを決定する必要があります。期限が切れる前に、証明書が失効した場合、Notifierは、証明書がもはや有効でないことを示すために、空の体に通知を送信します。期限が切れる前に、証明書が更新された場合、Notifierは新しい証明書を含むボディとの通知を送信します。加入者は、攻撃者はブロックする場合は、このトラフィックを通知を受信しない場合があります。加入者が証明書をキャッシュする時間の量は、設定すべきである（SHOULD）。 1日のデフォルトを推奨します。
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.
サブスクリプションの実際の期間は、キャッシング時間または対応する証明書の有効期間とは無関係であることに注意してください。証明書が有効でなくなった後にサブスクリプションが持続しないように許可する加入者がタイムリーに交換用の証明書を受け取ることを保証します。 Notifierはサブスクライブ要求に応じて証明書を使用して即時通知を返すと、すぐに理由パラメータに「執行猶予」に設定し、サブスクリプションを終了することができます。加入者は、定期的に証明書の有効性を検証するためのNotifierをポーリングする必要があります。
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は、暗号化されたメッセージの受信を扱う方法の詳細は、この仕様の範囲外です。これは、チャーリーのユーザエージェントサーバ（UAS）はボブに、暗号化されたリクエストを受信した場合、そのUAがボブに電話をリダイレクト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.
UAはUAの登録後、セクション7で説明したように「資格」のイベントタイプで自分のAORに加入することで、自分の資格情報を発見し、それはセクション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は、資格のパッケージには、本体とNOTIFYを受信した場合。
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].
証明書のnotAfterの日付が次の600秒以内であればO、UAは、交換用の資格情報を作成しようとすべきです。 UAは、0と300秒の間のランダムな時間を待つことによってこれを行います。新しい資格情報がその時間内に受信されていない場合、UAは、期限切れのものに代わる新しい資格情報を作成し、[RFC3903]のセクション4.4で説明したようにイベントの状態を変更するためのルールを以下のPUBLISHリクエストでそれらを送信します。
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は、7.8節で説明したように資格証明書あるいは単に証明書を使用してPUBLISH [RFC3903]リクエストを送信することにより、ユーザーの資格情報を更新します。
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は、新しいものを公開することなく、既存の証明書を失効させたい場合は、信用証明書サーバに空の体にPUBLISHを送らなければなりません。
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.
このパッケージには、任意の本体をSUBSCRIBE定義されていません。
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.
このイベントパッケージへのサブスクリプションは時間がないから数週間に及ぶことができます。日中のサブスクリプションは、より一般的であると推奨されています。このイベントパッケージのデフォルトのサブスクリプション期間は1日です。
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要求の本体は空であるか、Acceptヘッダーフィールドは、いくつかの他のタイプを交渉していない限り、証明書を含むアプリケーション/ PKIX-CERT本体（[RFC2585]で定義されるように）、含む必要があります。 [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.
将来の拡張は、他の遺体をNOTIFY定義するかもしれません。いかなる「同意」ヘッダフィールドはSUBSCRIBEに存在しない場合、本文書で定義されたボディタイプが想定されなければなりません。
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に、「証明書」のイベント・タイプにSUBSCRIBEリクエストを送信することによって証明書を発見します。一般的に、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ヘッダフィールドとSUBSCRIBEリクエストを送信することによって解除すべきです。
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の資格情報サーバ証明書のイベント型を持つSUBSCRIBEリクエストを受信すると、サブスクリプション要求を認証する必要はありません。 Notifierは、時間の管理者が定義した期間に、サブスクリプションの期間を制限する可能性があります。サブスクリプションの期間は、証明書が有効になる期間にどのような方法で対応していません。
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.
信用証明書サーバ証明書のためのSUBSCRIBEリクエストを受信すると、まず、それが要求された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.
サブスクリプションが受け入れられた直後、Notifierは何の証明書がターゲット・ユーザーのために利用できない場合、現在の証明書、または空の身体とNOTIFY送らなければなりません。いずれの場合では、SUBSCRIBE要求にヘッダーフィールドの値に設定されたヘッダフィールドからの値とNOTIFY形成します。このサーバは、ニーズをNOTIFYいずれかのサーバは、NOTIFYリクエストは、認証サービスを介して送信されるように設定する必要がある他の認証サービス（SIPアイデンティティ[RFC4474]に記載されているように）、またはを実装するために送信します。 NOTIFYは、サブスクリプションによって形成されたダイアログ内で送信されるため、認証サービスを介してNOTIFYリクエストを送信すると、認証サービスを経由してルーティングされているために、SUBSCRIBEリクエストが必要です。
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-CERTの体が含まれていますNOTIFYました。 UAは、受信した証明書を使用できるかどうかを決定するため、セクション10.3の手順に従わなければなりません。 UAは、将来の使用のためにこの証明書をキャッシュする必要があります。それはキャッシュされるべき時間の最大の長さは、セクション10.1で説明されています。証明書は、（空のボディを受信したとNOTIFY場合）、証明書が失効している場合は、キャッシュから除去されなければならない、またはそれがNOTIFY後続によって更新された場合。 UAは、[RFC4474]に記載されているようにNOTIFYが正しく認証サービスによって署名されていることを確認しなければなりません。認証サービスによってアサートアイデンティティはUAが破棄されるNOTIFYに証明書、に加入して使用してはいけませんAORと一致しない場合。
This event package does not permit forked requests. At most one subscription to this event type is permitted per resource.
このイベントパッケージは、フォーク要求を許可していません。このイベント型に最大で1つのサブスクリプションは、リソースごとに許可されています。
Notifiers SHOULD NOT generate NOTIFY requests more frequently than once per minute.
通知機能は、1分に1回よりも頻繁にNOTIFYリクエストを生成するべきではありません。
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に必要に応じて透過的にSUBSCRIBEとNOTIFYリクエストを転送するよりも、他のSIPプロキシには追加の要件は、ありません。この仕様は、3つの独立したサービスとして、プロキシ、認証サービス、および資格サービスを説明したが、同時に、これらのサービスのすべてを実行する単一の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.
このパッケージには、任意の本体をSUBSCRIBE定義されていません。
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.
このイベントパッケージへのサブスクリプションは、時間から1週間の範囲とすることができます。日中のサブスクリプションは、より一般的であると推奨されています。このイベントパッケージのデフォルトのサブスクリプション期間は1日です。
The credential service SHOULD keep subscriptions active for UAs that are currently registered.
資格サービスは、現在登録されているのUAのためのアクティブなサブスクリプションを維持する必要があります。
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]を参照）をサポートしなければなりません。これは、通知は最低でも証明書と証明書の関連する秘密鍵情報を持つアプリケーション/ PKCS8本体とアプリケーション/ PKIX-CERT本体を含む複数のリソースのドキュメントを含めることができます。アプリケーション/ PKCS8メディアタイプは、[RFC5958]で定義されています。
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に受け入れヘッダが存在しないことは、マルチパート/混合し、コンテンツタイプアプリケーション/ PKIX-CERT及びアプリケーション/ 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-CERT体は、識別符号化規則（DER）であるX.509v3証明書[RFC2585]をでエンコード。アプリケーション/ 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 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は直接資格サービスとして、または資格サービスのドメインの権威であるサーバーに動作するサーバーに接続するためにTLSを使用しなければなりません。 UAは、資格サービスに中間プロキシ経由で接続することはできません。 UAは、クレデンシャルサービスのための特定の名前で構成されてもよいです。そうでない場合は、通常のSIPのルーティングが使用されます。 RFC 3261に記載されているように、TLS接続は、UAは、それが正しいサーバと話している知っているように、接続が形成されたために、サーバーの予想される名前と一致する証明書を提示する必要があります。これを行うに失敗すると、攻撃者にその秘密鍵の情報を公開UAをもたらすことができます。 UAがSUBSCRIBEまたはPUBLISHリクエストにSIPの挑戦を受けることを期待することができますので、資格サービスは、通常のSIPダイジェスト・メカニズムを使用してUAを認証します。
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.
資格サービスは、資格認定のためのSUBSCRIBEを受信すると、資格サービスは、認証と認可UAを、そして十分なトランスポートセキュリティが使用されていることを確認する必要があります。唯一のAORとして登録することができることとして認証できるUAは、そのAORの資格情報を受け取ることを許可されています。資格サービスは、UAを認証し、資格情報を受け取るために許可されているかどうかを決定するためにUAに挑戦しなければなりません。認証が成功した場合、Notifierは、時間の管理者が定義した期間に、サブスクリプションの期間を制限する可能性があります。サブスクリプションの期間は、証明書がまだ有効である時間の長さよりも大きくすることはできません。それは、証明書に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は、資格サービスで認証されているサブスクリプションが受け入れられると、資格サービスは、直ちに通知要求を送らなければなりません。認証サービスは、証明書のサブスクリプションと同じように、このNOTIFYリクエストに適用されます。資格が取り消された場合は、資格サービスは、現在のサブスクリプションを終了し、そのSubscription-StateヘッダフィールドセットでNOTIFY「終了」との理由パラメータが「無効」に設定することを送信することにより、再認証する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の変更、資格サービスの資格情報を新しい資格情報を使用して任意のアクティブなサブスクリプションにNOTIFY新しいを送らなければなりません。
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.
ユーザエージェントは、ユーザまたは単にユーザーの証明書のための証明書を発行してかどうかを制御するように設定すべきである（SHOULD）。
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-CERT及びアプリケーション/ PKCS8体の両方を含む混合/マルチパートを含んでいます。
When the UA sends the PUBLISH [RFC3903] request, it needs to do the following:
UAは、PUBLISH [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ザ証明書が有効である時間と一致するように設定する必要がありPUBLISHリクエストのヘッダフィールド値を期限切れ。
o If the certificate includes Basic Constraints, it SHOULD set the cA boolean to false.
証明書は、基本制約が含まれている場合は、O、それは偽へのCAブール値を設定する必要があります。
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:
資格サービスは、資格情報を更新するPUBLISHリクエストを受信すると、資格情報のサブスクリプションの場合と同じように、この要求を認証および承認する必要があります。認証が成功した場合、資格サービスは、証明書に以下のチェックを実行する必要があります。
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.
カリフォルニア州におけるBasicConstraintsブールが証明書に設定されている場合は、O、それが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にすべてのアクティブな証明書と資格のサブスクリプションを処理し、新しい資格または証明書を使用してNOTIFYリクエストを生成します。なお、使用して追加のセキュリティ保証を提供しないことができた証明書を制限するだろうとの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.
加入者がいない体でPUBLISHリクエストを送信し、= 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.
通知機能は、1分に1回よりも頻繁にNOTIFYリクエストを生成するべきではありません。
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アルゴリズムを使用する場合代わりsha1WithRSAEncryptionを使用する、計算は[RFC5754]に記載されているようにsha256WithRSAEncryptionを使用して行われる例外と[RFC4474]のセクション9で説明したように、署名は全く同じ方法で計算されなければなりません。
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:
この例では、アリスはボブに暗号化されたページモードインスタントメッセージを送信します。アリスは、すでに以前の通信からボブの公開鍵を持っていないので、彼女はボブの資格サービスからボブの公開鍵を取り出します。
SUBSCRIBE sip:bob@biloxi.example.com SIP/2.0 ... Event: certificate
SUBSCRIBE SIP：bob@biloxi.example.com SIP / 2.0 ...イベント：証明書
The credential service responds with the certificate in a NOTIFY.
資格サービスは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
alice@atlanta.example.comのSIP / 2.0サブスクリプションステートNOTIFY：活性物質を、 7200 =期限が切れる....から：<SIP：bob@biloxi.example.com>;タグ= 1234アイデンティティ： "....もの取り除か...." アイデンティティ情報：<HTTPS：//atlanta.example .COM / CERT>; ALG = RSA-SHA256 ....イベント：証明書コンテンツタイプ：アプリケーション/ PKIX-CERTコンテンツの廃棄：信号
< certificate data >
<証明書データ>
Next, Alice sends a SIP MESSAGE to Bob and can encrypt the body using Bob's public key as shown below.
次に、アリスはボブにSIPメッセージを送信し、以下に示すように、ボブの公開鍵を使って体を暗号化することができます。
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：アプリケーション/ PKCS7-MIMEのContent-処分：レンダリング
$ Content-Type: text/plain $ $ < encrypted version of "Hello" >
$のContent-Type：text / plainの$ $ < "こんにちは" の暗号化されたバージョン>
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.
アリスのUAは、資格サービスにアリスの証明書と秘密鍵を公開したい場合は、以下のようなPUBLISHリクエストを送信します。これは、資格サービスのドメインに直接TLS接続を介して送信する必要があります。資格サービスはのSubjectAltNameは、PUBLISHリクエストのリクエストラインにドメイン名と一致し、彼女を認証するための要求に挑戦するエントリが含まれている証明書を提示します。
PUBLISH sips:alice@atlanta.example.com SIP/2.0 ... Event: credential Content-Type: multipart/mixed;boundary=boundary Content-Disposition: signal
一口を公開：alice@atlanta.example.com SIP / 2.0 ...イベント：資格のContent-Type：multipart / mixedの;境界=境界のContent-処分：信号
--boundary Content-ID: 123 Content-Type: application/pkix-cert
--boundaryのContent-ID：123のContent-Type：アプリケーション/ PKIX-CERT
< Public certificate for Alice > --boundary Content-ID: 456 Content-Type: application/pkcs8
<アリスのための公的証明書> --boundaryのContent-ID：456のContent-Type：アプリケーション/ PKCS8
< Private Key for Alice > --boundary
<アリスの秘密キー> --boundary
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.
アリスのユーザエージェントの一つは資格のイベントに加入している場合、資格サービスは、彼女を認証するための要求に挑戦し、通知します上記のPUBLISHの例のものと類似体が含まれます。
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
| |
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は、ボブと名付け、最初のボブの資格を作成したとき、それが信用証明書サーバ上でこれを格納します。 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 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.
UAは、ボブはラベルされた、サーバーからの資格情報を要求することを希望します。まず、それは整合性とプライバシー保護を提供し、またボブのUAにサーバを認証サーバーへのTLS接続を形成しています。次に、UAは、SUBSCRIBEリクエストを使用して、その資格情報を要求します。サーバは、ボブのUAを認証するSUBSCRIBEリクエストに挑戦します。サーバーとボブのUAは、このために使用される共有秘密を持っています。認証に成功すると、サーバーは、ボブの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.
同様のプロセスは、サーバーへの新しい認証情報を公開するボブのUAために使用されるであろう。ボブのUAは、新しい資格情報を含むPUBLISHリクエストを送信します。これが起こった場合には、ボブの信用証明書に加入された他のすべてのUAは、新しい資格情報を使用してNOTIFYを受け取ることになります。
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.
アリスは、ボブの証明書を検索したいし、サーバにSUBSCRIBEを送信します。サーバは、NOTIFYで応答を送信します。これは、[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.
注意：でも信用証明書サーバを解読する方法を知らないことを、いくつかの暗号化された形式で、資格のサーバーは、秘密鍵を保存する展開を回避する話題の重要な議論がなされてきました。様々な方式がこれを回避するために考えられますが、それらすべての問題をよりよく作るようには見えない他のいくつかのサーバーに問題を移動、またはデバイスごとに異なる資格を持ついずれかですべての結果ました。各ユーザーは1つのデバイスだけを持っているいくつかの展開では、これは素晴らしいですが、複数のデバイスでの展開のために、それはアリスがボブに連絡を行ったとき、アリスはボブのすべてのデバイスの暗号化されたメッセージを提供しなければならないことを必要とするであろう。 SIPPINGワーキンググループは、このアーキテクチャを考慮しなかったし、それは両方の原因、それはデバイスやユーザについて明らかにした情報に、そしてそれを動作させるために必要なシグナリングの量に適切でないと判断しました。
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:
この仕様は、TLSを配置し、UAの秘密鍵を取得するために、SIP通信に使用されている必要があります。これは、2つの方法でセキュリティを提供します。
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.
man-in-the-middle攻撃を防ぐために、TLSクライアントは、接続されたサーバの証明書ののSubjectAltNameは正確に彼らがに接続しようとしていたサーバーと一致していることをチェックしなければなりません。 TLSクライアントが直接、正しいサーバーに接続する必要があります。そうでない場合は、TLSパス内の任意の仲介は、証明書を侵害し、その代わり、攻撃者が秘密鍵を知っている証明書を提供することができます。これは、機密情報を失い、この妥協証明書に依存しているUAをもたらす可能性があります。 、秘密鍵などの資格証明書になることがあり、TLSを使用するために失敗したり（たとえば、NULL暗号化など）が悪い暗号スイートを選択すると、ネットワーク経由で暗号化されずに送信されていると役に立たないシステム全体をレンダリングします。
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]で指定されているチェーンの証明書の正しいチェックが重要です。クライアントは、それが正しい資格サービスに話していることを認証しない場合は、man-in-the-middle攻撃が可能です。
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.
攻撃者は、証明書をキャッシュしていたUAは、その失効とNOTIFYを受信しなかったようなサービス拒否（DoS）攻撃を仕掛ける可能性があります。この攻撃から保護するために、UAは、それが証明書をキャッシュする期間を制限する必要があります。この時間の後、UAには今までに起因することを阻止する攻撃者に受信されたNOTIFYにもかかわらず、キャッシュされた情報を無効にしないでしょう。
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 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.
このキャッシュされた情報の期間は、証明書失効リスト（CRL）をチェックする頻度を決定する装置と同様に、いくつかの方法です。多くのアプリケーションでは、1日のデフォルト時間が提案されているが、一部の用途のためには、証明書がまったくキャッシュされていないと資格が有効性のために証明書が使用されるたびにチェックされているように、ゼロに時間を設定することが望ましい場合があります。
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.
システムのUAは証明書が期限切れになり、時間に近い証明書を交換してください。 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の証明書をサブスクライブし、NOTIFYリクエストをSIP本体に証明書を受信します。用語「元のURIは、」SUBSCRIBEリクエストのヘッダにフィールド値であったURIを記述するために使用されます。 alice@example.com：だから、この場合には、オリジナルのURIは、SIPだろう。
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リクエストのヘッダからフィールドがサブスクライブされた元の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.
アイデンティティ[RFC4474]明細書に記載のあるO UAは、体が改ざん、認証サービスは、ヘッダフィールドからこれを検証したことをされていないことを検証するためのIdentityヘッダフィールドをチェックしなければなりません。
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に複数の名前を持っているかもしれませんが、それはNOTIFYに認証サービスによってアサートアイデンティティの証明書を必要とするとき、UAはこの証明書を使用しなければなりません。これは、証明書が唯一の認証サービスがアサートされていないのSubjectAltNameリストで見つかったすべてのアイデンティティの値によって、AORにより、証明書のキャッシュにインデックスを作成する必要があることを意味しています。
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ヘッダーフィールド値のいずれかに記載のアイデンティティから来たことを、証明書を携帯リクエストで体が改ざんされていないことを検証します。体内の証明書は、身元の公開鍵が含まれています。このAORとして認証することができUA、またはドメインの秘密鍵へのアクセス権を持つデバイスのみが、この身体を改ざんすることができます。これは、偽の公開鍵を提供することができることから、他のユーザーを停止します。オリジナルのURIから、からの、身体に、公開鍵へのアサーションのこのチェーンは、本明細書に記載されたメカニズムのセキュリティにとって非常に重要です。上記の手順のいずれかに従わない場合は、セキュリティのこの連鎖が破壊され、システムが動作しません。
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でルールを使用して証明書を検証しようとすることができます。 （10.6節を参照）証明書が正常に検証され、名前が正しくユーザーのAORと一致した場合、実装は証明書が外部の機関で検証されていることをいくつかの指標を提供すべきです。一般に、この機構を介して証明書を検証する障害は、証明書を拒絶する理由としては使用しないでください。証明書が失効している場合は、その後、実装はそれを拒否すべきです。
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].
この仕様は、エンドユーザが、異なるエンドユーザデバイス間で同じ資格情報を共有することを可能にする機構を含みます。このメカニズムは確実に利用可能な資格情報（SACRED）フレームワーク[RFC3760]に提示された1つに基づいています。このメカニズムは完全に本文書に記載されているが、必要条件と背景がより完全に[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に記載のクライアント認証（CTL）をアーキテクチャとTLSに従います。クライアントは、サーバの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_WITH_AES_128_CBC_SHAをサポートしなければなりません。 [RFC5246]で指定されるように加えて、それらは、TLS暗号スイートTLS_RSA_WITH_AES_128_CBC_SHA256をサポートしなければなりません。追加の暗号スイートがサポートされている場合、実装はNULL暗号化、整合性、または認証アルゴリズムを採用して暗号スイートを交渉してはなりません。
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の実装は通常、複数のトランスポート層セキュリティプロトコルのバージョンと同様に古いのSecure Socket Layer（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ラップパッドの暗号化アルゴリズムを実装しなければなりません。 [RFC2898]で定義されるように本明細書の一部プレ標準展開はDES-EDE2-CBC-パッドを使用するように、いくつかの実装のために、また、そのアルゴリズムをサポートすることが望ましい場合があります。クライアントの認証に使用されるものとは異なるパスワードは、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]と一致している必要があります。 signatureAlgorithmためsha1WithRSAEncryptionとsha256WithRSAEncryptionアルゴリズムを実装する必要があります。発行者は、被写体と同じでなければなりません。このシステムを使用して新しい証明書を発行するのしやすさを考えると、妥当性フィールドが比較的短くすることができます。 1年以下の妥当性値が推奨されます。 SubjectAltNameは、ユーザーのAORに対応したSIP URLに設定されているURIのタイプを持っている必要があります。同時に、システム内のすべての証明書を更新する必要はならないように、証明書が有効である時間の長さにいくつかのランダム性を配置することが望ましいかもしれません。
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はREGISTER要求に200応答にDateヘッダフィールドの値を見ることで、現在の時刻を知ることができることは注目に値します。
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.
秘密鍵を与えられる保護は重要なセキュリティ要因です。小規模では、秘密鍵を保護するためのデバイスの失敗は、ユーザーになりすましたり、個人情報を復号化するために、攻撃者を可能にします。 SACREDフレームワークで述べたように、ディスケットまたはハードディスクドライブなど、エンドユーザデバイスに格納されている場合、資格情報が明らかにされるべきではありません。秘密鍵を耐タンパ性ハードウェア暗号化を使用して暗号化し、必要な場合にのみ、それらを露光、より具体的には、装置内に安全に格納することをお勧めします。例えば、秘密鍵場合、デジタル署名を生成するために必要な復号化され、そして再短期間に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
To：ietf-sip-events@iana.org件名：新しいSIPイベントパッケージの登録
Package Name: certificate
パッケージ名：証明書
Is this registration for a template-package: No
テンプレートパッケージのため、この登録がある：いいえ
Published Specification(s): This document
公開された仕様（S）：この文書
New Event header parameters: This package defines no new parameters
新規イベントのヘッダパラメータ：このパッケージには、新しいパラメータを定義していません
Person & email address to contact for further information: Cullen Jennings <fluffy@cisco.com>
人とEメールアドレスは、詳細のために連絡する：カレン・ジェニングス<fluffy@cisco.com>
To: ietf-sip-events@iana.org Subject: Registration of new SIP event package
To：ietf-sip-events@iana.org件名：新しいSIPイベントパッケージの登録
Package Name: credential
パッケージ名：資格
Is this registration for a template-package: No
テンプレートパッケージのため、この登録がある：いいえ
Published Specification(s): This document
公開された仕様（S）：この文書
Person & email address to contact for further information: Cullen Jennings <fluffy@cisco.com>
人とEメールアドレスは、詳細のために連絡する：カレン・ジェニングス<fluffy@cisco.com>
IANA added the following entry to the "Identity-Info Algorithm Parameter Values" registry.
IANAは、「アイデンティティ・インフォアルゴリズムパラメータ値」レジストリに次のエントリを追加しました。
"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.
大きな助け、議論、およびテキストのエリックレスコラ、ラスHousley、ジムSchaad、ローハンマーイ、およびショーン・ターナーに感謝します。他の多くは久美子小野、ピーター・ガットマン、ヤロンPDUT、アキニエミ、マグナスNystrom、ポール・ホフマン、アディーナSIMU、ダン・ウィング、マイク・ハマー、パシEronen、アレクセイ・メルニコフ、ティムポーク、ジョンエルウェル、ジョナサン・ローゼンバーグ含め、有益なコメントやテキストを提供しました、とリンゼー・キャンベル。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.ホフマン、 "インターネットX.509公開鍵基盤運用プロトコル：FTPやHTTP"、RFC 2585、1999年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.、ピーターソン、J.、Vemuri、A.、オング、L.、Audet、F.、ワトソン、M.、およびM. Zonoun、 "ISUPとQSIGオブジェクトのMIMEメディアタイプ"、RFC 3204、2001年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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]ローチ、A.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[RFC3370] Housley氏、R.、 "暗号メッセージ構文（CMS）アルゴリズム"、RFC 3370、2002年8月。
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[RFC3903]ニエミ、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]ピーターソン、J.とC.ジェニングス、RFC 4474 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化"、2006年8月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年5月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、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]ブレイク・ウィルソン、S.、Nystrom、M.、ホップウッド、D.、ミケルセン、J.、およびT.ライト、 "トランスポート層セキュリティ（TLS）拡張機能"、RFC 4366、2006年4月。
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, January 2010.
[RFC5754]ターナー、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、 "パディングアルゴリズムとのAdvanced Encryption Standard（AES）キーラップ"、RFC 5649、2009年9月。
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 2010.
[RFC5958]ターナー、S.、 "非対称鍵パッケージ"、RFC 5958、2010年8月。
[RFC5959] Turner, S., "Algorithms for Asymmetric Key Package Content Type", RFC 5959, August 2010.
[RFC5959]ターナー、S.、RFC 5959、2010年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 2898、2000年9月。
[RFC3760] Gustafson, D., Just, M., and M. Nystrom, "Securely Available Credentials (SACRED) - Credential Server Framework", RFC 3760, April 2004.
[RFC3760]グスタフソン、D.、ちょうど、M.、およびM. Nystrom、 "しっかり利用可能な資格情報（SACRED） - 資格・サーバー・フレームワーク"、RFC 3760、2004年4月。
[RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)", RFC 3853, July 2004.
[RFC3853]ピーターソン、J.、 "S / MIMEのAdvanced Encryption Standard（AES）セッション開始プロトコル（SIP）のための要件"、RFC 3853、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]ローチ、A.、キャンベル、B.、およびJ.ローゼンバーグ、 "リソースリストのAのセッション開始プロトコル（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.ターナー、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.2メッセージ仕様"、RFC 5751、2010年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西タスマン・ドライブサンノゼ、CA 95134 USA
Phone: +1 408 421-9990 EMail: fluffy@cisco.com
電話：+1 408 421-9990 Eメール：fluffy@cisco.com
Jason Fischl (editor) Skype 3210 Porter Drive Palo Alto, CA 94304 USA
ジェイソンFischl（編集者）Skypeは3210ポータードライブパロアルト、CA 94304 USA
Phone: +1-415-202-5192 EMail: jason.fischl@skype.net
電話：+ 1-415-202-5192 Eメール：jason.fischl@skype.net