[要約] RFC 6072は、SIPのための証明書管理サービスに関する仕様です。このRFCの目的は、SIPセッションのセキュリティを向上させるために、証明書の生成、配布、更新、失効などの管理手順を定義することです。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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, 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.
[RFC3853]によって修正された[RFC3261]は、安全/多目的インターネットメールエクステンション（S/MIME）[RFC5751]を使用して、エンドツーエンドの暗号化と完全性のメカニズムを提供します。[RFC3261]のいくつかのセキュリティプロパティはS/MIMEに依存していますが、広く展開されていません。理由の1つは、合理的な証明書配布インフラストラクチャを提供する複雑さです。この仕様は、SIP展開の証明書の発見、検索、および管理に対処する方法を提案します。SIP ID [RFC4474]仕様と組み合わせることで、この仕様により、ユーザーの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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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]このキーにバインドされている対象の鍵とIDのリストを含むスタイル証明書を使用した公開キーインフラストラクチャ。このドキュメントで説明されている証明書は一般に自己署名されており、SIP ID [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 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).
一般的なアプローチは、SIPユーザーエージェント（UAS）が新しいSIPイベントパッケージ[RFC3265]を使用して他のユーザーの証明書を購読できるようにする「資格情報サービス」と呼ばれる新しいSIPサービスを提供することです。証明書は、対応するSIP通知リクエストで購読するUAに配信されます。SIP ID [RFC4474]仕様に記載されている認証サービスを使用して、送信者のプロキシドメイン証明書を使用して通知要求に署名することにより、証明書の送信者のIDを保証できます。認証サービスは、送信者がヘッダーフィールド値からSIPを入力できることを保証しています。メッセージの送信者は、これがヘッダーフィールド値からSIPで特定されたユーザーにとって適切な証明書であることを保証しています。資格情報は、ユーザーのプライベートキーだけでなく、パブリック証明書を管理できます。ユーザーは、SIPパブリッシュ[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.
次の図は、ボブが彼のユーザーエージェントの1人（例えば、彼のラップトップソフトウェアクライアント）から彼の資格を公開し、彼の別のユーザーエージェント（例：彼の携帯電話）から彼の資格を取得し、アリスがボブの証明書を取得してメッセージを送信することを示していますボブに。図から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.
Bob's UA（BOB2）は、輸送層セキュリティ（TLS）[RFC5246]資格情報サーバーでのハンドシェイクを行い、UAが正しい資格的サーバーに接続されていることを認証します。その後、ボブのUAは、新しく作成または更新された資格情報を公開します。資格的サーバーは、Digest認証スキームを使用して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.
別のボブのユーザーエージェント（BOB1）は、現在の資格情報を取得したいと考えています。資格情報サーバーを使用してTLS [RFC5246]握手を行い、UAが正しい資格情報サーバーに接続されていることを認証します。その後、ボブのUAは資格情報を購読します。資格的サーバーは、UAがBOBの共有秘密を知っていることを認証するようUAに挑戦します。UAが認証されると、クレデンシャルサーバーはボブの資格情報を含む通知を送信します。資格情報の秘密の重要な部分は、Bobの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は、ボブのAORに購読メッセージを送信します。[RFC4474]で定義されている「認証サービス」を介して、Bobのドメインのプロキシは「認証サービス」を介して資格サーバーにこれをルーティングします。資格的サーバーは、ボブのボブの公開証明書が含まれている通知を返します。これは、このメッセージが実際にAOR「sip：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]ヘッダーフィールド値が正しいことを確認することであることを理解することが重要です。
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を追加することをサポートする必要があります。これは、商業認証当局によってめったに実装されていないものです。ただし、ほとんどのUASは自己署名証明書のみを使用し、[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.
サブスクライバーは、受け取る証明書がまだ有効であると信頼することを喜んで決定する必要があります。証明書が期限切れになる前に取り消された場合、通知者は空のボディで通知を送信して、証明書がもはや有効でないことを示します。証明書が期限切れになる前に更新された場合、通知者は新しい証明書を含む機関で通知を送信します。攻撃者がこのトラフィックをブロックした場合、サブスクライバーは通知を受け取っていない可能性があることに注意してください。サブスクライバーが証明書をキャッシュする時間は設定可能である必要があります。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.
サブスクリプションの実際の期間は、対応する証明書のキャッシュ時間または妥当性時間とは無関係であることに注意してください。証明書が有効になった後にサブスクリプションを持続させることにより、サブスクライバーがタイムリーに交換証明書を受け取ることが保証されます。通知者は、購読要求に応じて証明書の即時通知を返すことができ、すぐにサブスクリプションを終了し、理由パラメーターを「保護観察」に設定します。サブスクライバーは、証明書の有効性を確認するために、通知者に定期的に投票する必要があります。
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がその存在を購読したときにリスト内のすべてのプレゼンテーションの証明書を購読したい場合があります。。将来の仕様は、存在書類とともに証明書を取得する可能性を考慮するかもしれません。
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をボブにリダイレクトする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は、セクション7で説明されているように、イベントタイプの「資格情報」でAORを購読することにより、独自の資格情報を発見します。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は、セクション7.8で説明されているように、資格情報または証明書のみを使用してパブリッシュ[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が新しい証明書を公開せずに既存の証明書を取り消すことを希望する場合、空のボディを持つパブリッシュを資格情報サーバーに送信する必要があります。
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.
このイベントパッケージのサブスクリプションは、時間から数週間まで及ぶことができます。日のサブスクリプションはより典型的であり、推奨されます。このイベントパッケージのデフォルトのサブスクリプション期間は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].
このパッケージの通知要求の本文は、認証を含むアプリケーション/PKIX-CERTボディ（[RFC2585]で定義されている）を含むか、受け入れヘッダーフィールドが他のタイプを交渉していない限り、アプリケーション/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.
将来の拡張は、他の通知機関を定義する場合があります。サブスクライブに「受け入れる」ヘッダーフィールドが存在しない場合、このドキュメントで定義されているボディタイプを想定する必要があります。
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.
ユーザーがデバイスからレジスタを解除する場合（ログオフ、モバイルデバイスの電源など）、サブスクライバーは、ゼロの有効期限のあるヘッダーフィールドを使用してサブスクライブリクエストを送信して登録解除する必要があります。
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の資格情報があるかどうかを確認します。証明書がない場合は、空のメッセージ本文で通知要求を返します。
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.
サブスクリプションが受け入れられた直後に、通知者は、ターゲットユーザーが証明書を使用できない場合は、現在の証明書で通知を送信する必要があります。どちらの場合でも、サブスクライブリクエストのヘッダーフィールドからヘッダーフィールドの値に設定されたHeaderフィールド値を使用して通知を形成します。認証サービスを実装するためにNotifyニーズを送信するこのサーバー（SIP ID [RFC4474]に記載されているように）またはサーバーを設定する必要があります。認証サービスを介してNotifyリクエストを送信するには、notifyがサブスクリプションによって形成されたダイアログ内で送信されるため、認証サービスを介してルーティングされたサブスクライブリクエストが必要です。
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.
結果のNotifyには、要求された証明書を含むアプリケーション/PKIX-CERT本文が含まれます。UAは、セクション10.3の手順に従って、受信証明書を使用できるかどうかを決定する必要があります。UAは、将来の使用のためにこの証明書をキャッシュする必要があります。キャッシュする必要がある時間の最大長さについては、セクション10.1で説明します。証明書が取り消された場合（空の本体を持つ通知が受信された場合）、または後続の通知によって更新された場合（キャッシュから証明書を削除する必要があります。UAは、[RFC4474]で説明されているように、通知が認証サービスによって正しく署名されていることを確認する必要があります。認証サービスによって主張されたIDがUAが購読したAORと一致しない場合、Notifyの証明書は破棄され、使用してはなりません。
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回以上頻繁に生成しないでください。
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で必要に応じてサブスクライブを透過的に転送し、要求に通知することを除きます。この仕様では、プロキシ、認証サービス、および資格サービスを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.
このパッケージは、購読団体を定義しません。
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.
資格情報は、現在登録されている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-CERTボディと、証明書の関連する秘密鍵情報を持つアプリケーション/ PKCS8本文を含む複数のリソースドキュメントを含めることができます。アプリケーション/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.
サブスクライブに受け入れヘッダーがないことは、MultiPart/MixedおよびContent Types Application/PKIX-CERTおよびApplication/PKCS8のサポートを示しています。受け入れヘッダーが存在する場合、クライアントがサポートする他のタイプに加えて、これらのタイプを含める必要があります。
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.
Application/PKIX-CERT本体は、著名なエンコードルール（DER）エンコードX.509V3証明書[RFC2585]です。アプリケーション/PKCS8ボディには、秘密鍵を含むderエンコード[RFC5958]オブジェクトが含まれています。PKCS＃8オブジェクトは、PrivateKeyInfoのタイプでなければなりません。PKCS＃8オブジェクトの完全性と機密性は、TLSトランスポートによって提供されます。すべてのマイムボディの輸送エンコードはバイナリです。
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が攻撃者に秘密のキー情報を公開する可能性があります。資格情報は、通常の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を認証するように挑戦し、資格情報を受け取ることが許可されているかどうかを決定する必要があります。認証が成功した場合、通知者はサブスクリプションの期間を管理者定義の期間に制限する場合があります。サブスクリプションの期間は、証明書がまだ有効である時間の長さよりも大きくなければなりません。有効期限は、証明書の日付の記録よりも長くないように設定する必要があります。
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リクエストを送信する必要があります。認証サービスは、証明書サブスクリプションと同じように、この通知リクエストに適用されます。資格情報が取り消された場合、資格情報は現在のサブスクリプションを終了し、サブスクリプションヘッダーフィールドを「終了」に設定し、「非アクティブ化」に設定された理由パラメーターを設定して通知を送信することにより、UAに再認証を強制する必要があります。（これにより、サブスクライバーはすぐにサブスクリプションを再試行します。）これは、資格情報を取得するための秘密が侵害された場合、Rogue 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-CERTとアプリケーション/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 公開要求のヘッダーフィールド値の有効期限は、証明書が有効な時間と一致するように設定する必要があります。
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 妥当性の時間前に将来的にはあってはなりません。
o The notAfter validity time MUST be in the future.
o 妥当性時間は将来的になければなりません。
o If a cA BasicConstraints boolean is set in the certificate, it is set to FALSE.
o CA BasicConstraints Booleanが証明書に設定されている場合、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のすべてのアクティブな証明書と資格情報を処理し、新しい資格情報または証明書で通知要求を生成します。件名をチェックしないでください。これにより、使用できる証明書が制限され、追加のセキュリティ保証は提供されないためです。
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.
サブスクライバーが本文なしで公開要求を提出し、= 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回以上頻繁に生成しないでください。
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]認証サービスは、RSA-Sha1と呼ばれるSHA-1に基づいた署名アルゴリズムを定義しました。この仕様は、ほぼ同じであるが、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で説明されているのとまったく同じ方法で計算する必要があります。
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
購読sip：bob@biloxi.example.com sip/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
< 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
メッセージsip：bob@biloxi.example.com SIP/2.0 ... Content-Type：Application/PKCS7-MIME Content-Disposition：レンダリング
$ Content-Type: text/plain $ $ < encrypted version of "Hello" >
$ コンテンツタイプ：テキスト/プレーン$ $ <暗号化された「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.
アリスのUAがアリスの証明書と資格情報の秘密鍵を公開したい場合、以下のような公開要求を送信します。これは、TLS接続を介して資格情報サービスのドメインに直接送信する必要があります。資格情報には、subjectaltnameに公開要求の要求行のドメイン名と一致するエントリが含まれ、彼女を認証するリクエストに挑戦する証明書を提示します。
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
-Boundary Content-ID：123 Content-Type：Application/PKIX-CERT
< Public certificate for Alice > --boundary Content-ID: 456 Content-Type: application/pkcs8
<Alice>の公開証明書> - Boundary Content-ID：456 Content-Type：Application/PKCS8
< Private Key for Alice > --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.
AliceのUASの1つが資格情報イベントを購読している場合、資格情報は彼女を認証するリクエストに異議を唱え、Notifyには上記のパブリッシュ例の本体に似た本体が含まれます。
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は、サーバーから資格情報を要求したいと考えています。まず、サーバーへのTLS接続を形成します。これは、整合性とプライバシー保護を提供し、ボブのUAにサーバーを認証します。次に、UAはサブスクライブリクエストを使用して資格情報を要求します。サーバーは、ボブのUAを認証するためにサブスクライブリクエストに挑戦します。サーバーとボブの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.
同様のプロセスが、ボブのUAに新しい資格情報をサーバーに公開するために使用されます。ボブのUAは、新しい資格情報を含む公開リクエストを送信します。これが起こったとき、Bobの資格情報に購読された他のすべてのUAは、新しい資格情報との通知を受け取ります。
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.
アリスはボブの証明書を見つけたいと考え、サーバーに購読します。サーバーは、通知で応答を送信します。[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つのデバイスしか持っていない展開の場合、これは問題ありませんが、複数のデバイスを使用した展開には、アリスがボブに連絡するとき、アリスはすべてのボブのデバイスに暗号化されたメッセージを提供する必要があります。すすり泣いたワーキンググループは、このアーキテクチャを検討し、デバイスとユーザーについて明らかにした情報と、それを機能させるために必要なシグナルの量の両方のために適切ではないと判断しました。
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通信がUAの秘密鍵を配置して取得するためにTLを使用する必要があります。これは、2つの方法でセキュリティを提供します。
1. Confidentiality is provided for the Digest Authentication exchange, thus protecting it from dictionary attacks.
1. Digest Authentication Exchangeには機密性が提供されるため、辞書攻撃から保護します。
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クライアントは、接続しているサーバーの証明書の主題が接続しようとしているサーバーと正確に一致することを確認する必要があります。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]で指定されているチェーン証明書の正しいチェックは、クライアントがサーバーを認証するために重要です。クライアントが正しい資格情報と話していることを認証しない場合、中間の攻撃が可能です。
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が取り消しで通知を受け取らなかったように、サービス拒否（DOS）攻撃を実施できる可能性があります。この攻撃から保護するには、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 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.
システム内の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通知リクエストの本文で証明書を受け取ります。「元のURI」という用語は、購読要求のヘッダーフィールド値にある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の名前の1つが元のURIと一致する場合、この証明書は正確に使用される場合がありますが、正確には元のURIでのみ、subjectaltnameで見つかった他のアイデンティティではありません。それ以外の場合、この証明書を使用する前にUAが実行しなければならないいくつかのステップがあります。
o The From header field in the NOTIFY request MUST match the original URI that was subscribed to.
o NotifyリクエストのHeaderフィールドからは、サブスクライブされた元の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は、ID [RFC4474]仕様に記載されているIDヘッダーフィールドをチェックして、身体が改ざんされていないこと、および認証サービスがヘッダーフィールドからこれを検証したことを検証する必要があります。
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は、証明書の有効期間を確認し、無効な場合は証明書の使用を停止する必要があります。（実装は、妥当性とノートの両方の妥当性時間の両方を検証するために思い出されます。）
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は、通知の認証サービスによって主張されたIDの証明書が必要な場合にのみこの証明書を使用する必要があります。つまり、証明書は、認証サービスが主張した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 Headerフィールドに一致させることを余儀なくされています。認証サービスは、この要求がHeaderフィールド値で請求されたIDから来たこと、および証明書を運ぶ要求の団体が改ざんされていないことを検証します。身体内の証明書には、アイデンティティの公開鍵が含まれています。この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で説明されているクライアント認証（CTLS）アーキテクチャを使用して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 Cipher Suite TLS_RSA_WITH_AES_128_CBC_SHAをサポートする必要があります。さらに、[RFC5246]で指定されているように、TLS Cipher Suite TLS_RSA_WITH_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の実装は、通常、Transport Layer Security Protocolの複数のバージョンと、古いセキュアソケットレイヤー（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]と一致する必要があります。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.
登録要求に対する200の応答で日付ヘッダーフィールド値を見ることで、UAが現在の時刻を発見できることは注目に値します。
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.
このドキュメントで説明されている証明書管理サービスに対する最悪の攻撃の1つは、認証サービスが侵害された場合です。この攻撃は、従来の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は、資格情報サーバーが正しい証明書を配布しているかどうかを検出しようとするために、他のIDの下で独自の証明書を購読することができます。資格情報サーバーがユーザーの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）イベントタイプの名前空間」レジストリに追加した2つの新しいイベントパッケージを定義します。
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>
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>
IANA added the following entry to the "Identity-Info Algorithm Parameter Values" registry.
IANAは、「ID-INFOアルゴリズムパラメーター値」レジストリに次のエントリを追加しました。
"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.
エリック・レスコルラ、ラス・ヒューズリー、ジム・シャード、ロハン・マヒー、ショーン・ターナーに、重要な助け、議論、テキストに感謝します。他の多くは、小野kumiko、ピーター・ガットマン、ヤロン・プドゥット、アキ・ニエミ、マグナス・ニセトロム、ポール・ホフマン、アディーナ・シム、ダン・ウィング、マイク・ハンマー、パシ・エロネン、アレクセイ・メルニコフ、ティム・ポーク、ジョン・エルウェ、ジョナサン・ローズ・ローズ・ローズ・ローズ・ローズ・ローズ・ローズ・ローズ・ローズ・ローズ・ローズ・ローズ、およびLyndsay Campbell。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046] Freed、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] 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、「インターネット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.、Peterson、J.、Vemuri、A.、Ong、L.、Audet、F.、Watson、M。、およびM. Zonoun、「ISUPおよびQSIGオブジェクトのMIMEメディアタイプ」、RFC3204、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265] Roach、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] 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。and 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、「The Transport Layer Security（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 5280、2008年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、「Transport Layer Security（TLS）Extensions」、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、「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] Turner、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] Gustafson、D.、Just、M。、およびM. Nystrom、「Securely Availaing Credentials（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] Peterson、J。、「S/MIME Advanced暗号化標準（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] 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、「Secure/Multipurpose Internet Mail Extensions（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
Cullen Jennings Cisco Systems 170 West Tasman Drive San Jose、CA 95134 USA
Phone: +1 408 421-9990
EMail: fluffy@cisco.com
Jason Fischl (editor) Skype 3210 Porter Drive Palo Alto, CA 94304 USA
Jason Fischl（編集者）Skype 3210 Porter Drive Palo Alto、CA 94304 USA
Phone: +1-415-202-5192
EMail: jason.fischl@skype.net