[要約] RFC 7199は、ポリシー管理のための場所設定拡張に関する規格であり、要約すると以下のようになります。1. 目的：ポリシー管理システムにおいて、場所設定の拡張機能を提供すること。 2. 要約：このRFCは、場所設定の拡張機能に関する標準化を行い、ポリシー管理の効率と柔軟性を向上させることを目指している。
Internet Engineering Task Force (IETF) R. Barnes
Request for Comments: 7199 M. Thomson
Category: Standards Track Mozilla
ISSN: 2070-1721 J. Winterbottom
Unaffiliated
H. Tschofenig
April 2014
Location Configuration Extensions for Policy Management
ポリシー管理用のロケーション構成拡張
Abstract
概要
Current location configuration protocols are capable of provisioning an Internet host with a location URI that refers to the host's location. These protocols lack a mechanism for the target host to inspect or set the privacy rules that are applied to the URIs they distribute. This document extends the current location configuration protocols to provide hosts with a reference to the rules that are applied to a URI so that the host can view or set these rules.
現在のロケーション構成プロトコルは、ホストのロケーションを参照するロケーションURIを使用してインターネットホストをプロビジョニングできます。これらのプロトコルには、ターゲットホストが配布するURIに適用されるプライバシールールを検査または設定するためのメカニズムがありません。このドキュメントでは、現在の場所の構成プロトコルを拡張して、ホストにURIに適用されるルールへの参照を提供し、ホストがこれらのルールを表示または設定できるようにします。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc7199.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7199で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Policy URIs . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Policy URI Usage . . . . . . . . . . . . . . . . . . . . 5
3.2. Policy URI Allocation . . . . . . . . . . . . . . . . . . 6
3.3. Policy Defaults . . . . . . . . . . . . . . . . . . . . . 7
4. Location Configuration Extensions . . . . . . . . . . . . . . 8
4.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Client Processing . . . . . . . . . . . . . . . . . . . . 9
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Basic Access Control Policy . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:policy . . . . . . . 12
6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7.1. Integrity and Confidentiality for Authorization Policy
Data . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Access Control for Authorization Policy . . . . . . . . . 13
7.3. Location URI Allocation . . . . . . . . . . . . . . . . . 15
7.4. Policy URI Handling . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Example Policy URI Generation Algorithm . . . . . . 18
A critical step in enabling Internet hosts to access location-based services is to provision those hosts with information about their own location. This is accomplished via a Location Configuration Protocol (LCP) [RFC5687], which allows a location provider (e.g., a local access network) to inform a host about its location.
インターネットホストが場所ベースのサービスにアクセスできるようにするための重要なステップは、それらのホストに自分の場所に関する情報をプロビジョニングすることです。これは、ロケーションコンフィグレーションプロトコル（LCP）[RFC5687]を介して行われます。これにより、ロケーションプロバイダー（ローカルアクセスネットワークなど）がホストにそのロケーションを通知できます。
There are two basic patterns for location configuration, namely configuration "by value" and "by reference" [RFC5808]. Configuration by value provisions a host directly with its location, by providing it location information that is directly usable (e.g., coordinates or a civic address). Configuration by reference provides a host with a URI that references the host's location, i.e., one that can be dereferenced to obtain the location (by value) of the host.
ロケーション構成には、「値による」構成と「参照による」構成の2つの基本パターンがあります[RFC5808]。値による構成では、直接使用できる位置情報（座標や市民の住所など）を提供することで、ホストにその位置を直接プロビジョニングします。参照による構成では、ホストの場所を参照するURIをホストに提供します。つまり、逆参照してホストの場所を（値で）取得できるURIを提供します。
In some cases, location by reference offers a few benefits over location by value. From a privacy perspective, the required dereference transaction provides a policy enforcement point so that if suitable privacy policies have been provisioned, the opaque location URI can be safely conveyed over untrusted media. (If the location URI is not subject to privacy rules, then conveying the location URI may pose even greater risk than sending location by value [RFC5606].) If the target host is mobile, an application provider can use a single reference to obtain the location of the host multiple times, saving bandwidth to the host. For some configuration protocols, the location object referenced by a location URI provides a much more expressive syntax for location values than the configuration protocol itself (e.g., DHCP geodetic location [RFC6225] versus Geography Markup Language (GML) in a Presence Information Data Format Location Object (PIDF-LO) [RFC4119]).
場合によっては、参照によるロケーションには、値によるロケーションよりもいくつかの利点があります。プライバシーの観点から、必要な逆参照トランザクションはポリシー実施ポイントを提供するため、適切なプライバシーポリシーがプロビジョニングされている場合、不透明なロケーションURIは信頼できないメディアを介して安全に伝達できます。 （ロケーションURIがプライバシールールの対象ではない場合、ロケーションURIを伝達することは、値でロケーションを送信するよりも大きなリスクをもたらす可能性があります[RFC5606]。）ターゲットホストがモバイルの場合、アプリケーションプロバイダーは単一の参照を使用してホストの場所が複数回あり、帯域幅をホストに節約できます。一部の構成プロトコルでは、ロケーションURIによって参照されるロケーションオブジェクトは、構成プロトコル自体よりもはるかに表現力のあるロケーション値の構文を提供します（たとえば、DHCP測地ロケーション[RFC6225]とプレゼンス情報データ形式のロケーションの地理マークアップ言語（GML））オブジェクト（PIDF-LO）[RFC4119]）。
From a privacy perspective, however, current LCPs are limited in their flexibility, in that they do not provide hosts (the clients in an LCP) with a way to inform the Location Server with policy for how his location information should be handled. This document addresses this gap by defining a simple mechanism for referring to and manipulating policy and by extending current LCPs to carry policy references. Using the mechanisms defined in this document, an LCP server (acting for the Location Server (LS) or Location Information Server (LIS)) can inform a host as to which policy document controls a given location resource, and the host (in its Rule Maker role) can inspect this document and modify it as necessary.
ただし、プライバシーの観点からは、現在のLCPは柔軟性が制限されており、ホスト（LCPのクライアント）に、ロケーション情報の処理方法に関するポリシーをロケーションサーバーに通知する方法を提供していません。このドキュメントでは、ポリシーを参照および操作するための簡単なメカニズムを定義し、現在のLCPを拡張してポリシー参照を伝送することにより、このギャップに対処します。このドキュメントで定義されているメカニズムを使用して、LCPサーバー（ロケーションサーバー（LS）またはロケーション情報サーバー（LIS）の役割を果たす）は、どのポリシードキュメントが特定のロケーションリソースを制御するか、およびホスト（そのルール内）についてホストに通知できます。作成者の役割）は、このドキュメントを検査し、必要に応じて変更できます。
In the following figure, adapted from RFC 5808, this document extends the Location Configuration Protocols (1) and defines a simple protocol for policy exchange (4).
次の図では、RFC 5808を応用して、このドキュメントはLocation Configuration Protocols（1）を拡張し、ポリシー交換（4）のための単純なプロトコルを定義しています。
+---------+---------+ Location +-----------+
| | | Dereference | Location |
| LIS/LS +---------------+ Recipient |
| | | Protocol | |
+----+----+----+----+ (3) +-----+-----+
| | |
| | |
Policy| |Location |Location
Exchange| |Configuration |Conveyance
(4)| |Protocol |Protocol
| |(1) |(2)
| | |
+------+----+----+----+ |
| Rule | Target/ | |
| Maker | Host +---------------------+
| | |
+-----------+---------+
The remainder of this document is structured as follows:
このドキュメントの残りの部分は、次のように構成されています。
After introducing a few relevant terms, we define policy URIs as a channel for referencing, inspecting, and updating policy documents. We then define an extension to the HELD protocol to allow it to carry policy URIs. Examples are given that demonstrate how policy URIs are carried in this protocol and how it can be used by clients.
いくつかの関連用語を紹介した後、ポリシードキュメントを参照、検査、および更新するためのチャネルとしてポリシーURIを定義します。次に、HELDプロトコルの拡張を定義して、ポリシーURIを伝送できるようにします。このプロトコルでポリシーURIがどのように伝送されるか、およびクライアントがそれをどのように使用できるかを示す例が示されています。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
A policy URI is an HTTP [RFC2616] or HTTPS [RFC2818] URI that identifies a policy resource that contains the authorization policy for a linked location resource. Access to the location resource is governed by the contents of the authorization policy.
ポリシーURIは、リンクされた場所リソースの承認ポリシーを含むポリシーリソースを識別するHTTP [RFC2616]またはHTTPS [RFC2818] URIです。ロケーションリソースへのアクセスは、認可ポリシーの内容によって管理されます。
A policy URI identifies an HTTP resource that a Rule Maker can use to inspect and install policy documents that tell a Location Server how it should protect the associated location resource. A policy URI always identifies a resource that can be represented as a common-policy document [RFC4745] (possibly including some extensions; e.g., for geolocation policy [RFC6772]).
ポリシーURIは、関連付けられたロケーションリソースを保護する方法をロケーションサーバに通知するポリシードキュメントを検査およびインストールするためにルールメーカーが使用できるHTTPリソースを識別します。ポリシーURIは常に、共通ポリシードキュメント[RFC4745]として表すことができるリソースを識別します（たとえば、ジオロケーションポリシー[RFC6772]の場合など、いくつかの拡張機能が含まれる可能性があります）。
Note: RFC 3693 [RFC3693] identified the Rule Holder role as the one that stores policy information. In this document, the Location Server is also a Rule Holder.
注：RFC 3693 [RFC3693]は、ルール所有者の役割をポリシー情報を格納する役割として識別しました。このドキュメントでは、ロケーションサーバはルールホルダーでもあります。
A Location Server that is the authority for policy URIs MUST support GET, PUT, and DELETE requests to these URIs, in order to allow clients to inspect, replace, and delete policy documents. Clients support the three request methods as they desire to perform these operations.
ポリシーURIの権限であるロケーションサーバーは、クライアントがポリシードキュメントを検査、置換、および削除できるようにするために、これらのURIへのGET、PUT、およびDELETEリクエストをサポートする必要があります。クライアントは、これらの操作を実行したいときに、3つの要求メソッドをサポートします。
Knowledge of the policy URI can be considered adequate evidence of authorization; a policy URI functions as a shared secret between the client and the server (see Section 7). A Location Server SHOULD allow all requests, but it MAY deny certain requests based on local policy. For instance, a Location Server might allow clients to inspect policy (GET), but not to update it (PUT). Or, a Location Server might require clients to authenticate using HTTP or Transport Layer Security (TLS) client authentication. Clients implementing this specification SHOULD support HTTP client authentication [RFC2617] and MAY support TLS client certificates.
ポリシーURIの知識は、承認の適切な証拠と見なすことができます。ポリシーURIは、クライアントとサーバー間の共有秘密として機能します（セクション7を参照）。ロケーションサーバーはすべてのリクエストを許可する必要がありますが、ローカルポリシーに基づいて特定のリクエストを拒否する場合があります。たとえば、ロケーションサーバーでは、クライアントはポリシーを検査（GET）できますが、更新はできません（PUT）。または、ロケーションサーバーは、HTTPまたはトランスポート層セキュリティ（TLS）クライアント認証を使用してクライアントに認証を要求する場合があります。この仕様を実装するクライアントは、HTTPクライアント認証[RFC2617]をサポートする必要があり（SHOULD）、TLSクライアント証明書をサポートする場合があります（MAY）。
A GET request to a policy URI is a request for the referenced policy information. If the request is authorized, then the Location Server sends an HTTP 200 response containing the complete policy identified by the URI.
ポリシーURIへのGET要求は、参照されるポリシー情報の要求です。リクエストが承認されると、ロケーションサーバーは、URIで識別される完全なポリシーを含むHTTP 200応答を送信します。
A PUT request to a policy URI is a request to replace the current policy. The entity-body of a PUT request includes a complete policy document. When a Location Server receives a PUT request, it MUST validate the policy document included in the body of the request. If the request is valid and authorized, then the Location Server MUST replace the current policy with the policy provided in the request.
ポリシーURIへのPUTリクエストは、現在のポリシーを置き換えるリクエストです。 PUT要求のエンティティ本体には、完全なポリシードキュメントが含まれています。ロケーションサーバーがPUTリクエストを受信すると、リクエストの本文に含まれるポリシードキュメントを検証する必要があります。リクエストが有効で承認されている場合、ロケーションサーバーは現在のポリシーをリクエストで提供されたポリシーに置き換える必要があります。
A DELETE request to a policy URI is a request to delete the referenced policy document. If the request is authorized, then the Location Server MUST delete the policy referenced by the URI and disallow access to the location URIs it governs until a new policy document has been put in place via a PUT request.
ポリシーURIへのDELETE要求は、参照されたポリシードキュメントを削除する要求です。リクエストが承認された場合、ロケーションサーバーは、URIによって参照されるポリシーを削除し、PUTリクエストを介して新しいポリシードキュメントが配置されるまで、それが管理するロケーションURIへのアクセスを禁止する必要があります。
A policy URI is only valid while the corresponding location URI set is valid. A Location Server MUST NOT respond to any requests to a policy URI once the corresponding location URI set has expired. This expiry time is specified by the 'expires' attribute in the HELD locationResponse.
ポリシーURIは、対応するロケーションURIセットが有効である間のみ有効です。対応するロケーションURIセットが期限切れになると、ロケーションサーバーはポリシーURIへの要求に応答してはなりません（MUST NOT）。この有効期限は、HELD locationResponseの「expires」属性で指定されます。
A location URI can thus become invalid in three ways: By the expiration of a validity interval in policy, by the removal of a policy document with a DELETE request, or by the expiry of the LCP-specified validity interval. The former two are temporary, since the policy URI can be used to update the policy. The latter one is permanent, since the expiry causes the policy URI to be invalidated as well.
したがって、ロケーションURIは次の3つの方法で無効になる可能性があります。ポリシーの有効期間の満了、DELETE要求によるポリシードキュメントの削除、またはLCPで指定された有効期間の満了。前の2つは一時的なものです。これは、ポリシーURIを使用してポリシーを更新できるためです。有効期限が切れるとポリシーURIも無効になるため、後者は永続的です。
The Location Server MUST support policy documents in the common-policy format [RFC4745], as identified by the MIME media type of "application/auth-policy+xml". The common-policy format MUST be provided as the default format in response to GET requests that do not include specific "Accept" headers, but content negotiation MAY be used to allow for other formats.
ロケーションサーバーは、「application / auth-policy + xml」のMIMEメディアタイプで識別されるように、common-policy形式[RFC4745]のポリシードキュメントをサポートする必要があります。共通ポリシー形式は、特定の "Accept"ヘッダーを含まないGET要求に応じてデフォルト形式として提供する必要がありますが、他の形式を許可するためにコンテンツネゴシエーションを使用できます（MAY）。
This usage of HTTP is generally compatible with the use of Extensible Markup Language (XML) Configuration Access Protocol (XCAP) [RFC4825] or Web Distributed Authoring and Versioning (WebDAV) [RFC4918] to manage policy documents, but this document does not define or require the use of these protocols.
このHTTPの使用は、一般に、Extensible Markup Language（XML）構成アクセスプロトコル（XCAP）[RFC4825]またはWeb分散オーサリングおよびバージョン管理（WebDAV）[RFC4918]を使用したポリシードキュメントの管理と互換性がありますが、このドキュメントでは、これらのプロトコルを使用する必要があります。
A Location Server creates a policy URI for a specific location resource at the time that the location resource is created; that is, a policy URI is created at the same time as the location URI that it controls. The URI of the policy resource MUST be different from the location URI.
ロケーションサーバーは、ロケーションリソースの作成時に特定のロケーションリソースのポリシーURIを作成します。つまり、ポリシーURIは、それが制御するロケーションURIと同時に作成されます。ポリシーリソースのURIは、ロケーションURIとは異なる必要があります。
A policy URI is provided in response to location configuration requests. A policy URI MUST NOT be provided to an entity that is not authorized to view or set policy. This document does not describe how policy might be provided to entities other than for location configuration, for example, in responses to dereferencing requests [RFC6753] or requests from third parties [RFC6155].
ロケーション構成要求への応答として、ポリシーURIが提供されます。ポリシーの表示または設定を許可されていないエンティティには、ポリシーURIを提供してはなりません。このドキュメントでは、たとえば、逆参照要求[RFC6753]やサードパーティからの要求[RFC6155]への応答などで、ロケーション構成以外のエンティティにポリシーを提供する方法については説明していません。
Each location URI has either one policy URI or no policy URI. The initial policy that is referenced by a policy URI MUST be identical to the policy that would be applied in the absence of a policy URI. A client that does not support policy URIs can continue to use the location URI as they would have if no policy URI were provided.
各ロケーションURIには、ポリシーURIが1つあるか、ポリシーURIがありません。ポリシーURIによって参照される最初のポリシーは、ポリシーURIがない場合に適用されるポリシーと同一である必要があります。ポリシーURIをサポートしないクライアントは、ポリシーURIが提供されなかった場合と同様に、ロケーションURIを引き続き使用できます。
For HELD, the client assumes that the default policy grants any requester access to location information, as long as the request possesses the location URI. To ensure that the authorization policy is less permissive, a client updates the policy prior to distributing the location URI.
HELDの場合、クライアントは、リクエストがロケーションURIを保持している限り、デフォルトのポリシーがリクエスターにロケーション情報へのアクセスを許可すると想定します。許可ポリシーの許容度を低くするために、クライアントはロケーションURIを配布する前にポリシーを更新します。
A Location Server chooses whether or not to provide a policy URI based on local policy. A HELD-specific extension also allows a requester to specifically ask for a policy URI.
ロケーションサーバーは、ローカルポリシーに基づいてポリシーURIを提供するかどうかを選択します。 HELD固有の拡張により、リクエスタはポリシーURIを明確に要求することもできます。
A policy URI is effectively a shared secret between the Location Server and its clients. Knowledge of a policy URI is all that is required to perform any operations allowed on the policy. Thus, a policy URI should be constructed so that it is hard to predict and confidentiality protected when transmitted (see Section 7). To avoid reusing these shared secrets, the Location Server MUST generate a new policy URI whenever it generates a new location URI set.
ポリシーURIは、事実上、ロケーションサーバとそのクライアントの間の共有秘密です。ポリシーで許可されている操作を実行するために必要なのは、ポリシーURIの知識だけです。したがって、ポリシーURIは、送信時に予測が困難になり、機密性が保護されるように構築する必要があります（セクション7を参照）。これらの共有シークレットの再利用を回避するために、ロケーションサーバーは新しいロケーションURIセットを生成するたびに新しいポリシーURIを生成する必要があります。
Client implementors should keep in mind that setting no policy (never performing an HTTP request to a policy URI) is very different from setting an empty policy (performing a PUT with the empty policy). By "the empty policy", we mean a policy containing no rules, which would be represented by the following policy document:
クライアント実装者は、ポリシーを設定しない（ポリシーURIへのHTTPリクエストを実行しない）ことは、空のポリシーを設定すること（空のポリシーでPUTを実行すること）とは大きく異なることに注意する必要があります。 「空のポリシー」とは、ルールを含まないポリシーを意味し、次のポリシードキュメントで表されます。
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
</ruleset>
Figure 1: The Empty Policy
図1：空のポリシー
If no policy is set, then the client tacitly accepts whatever policy the server applies to location URIs, including a policy that provides location to anyone that makes a dereference request. If the empty policy is set, then the opposite is true; the client directs the server to never provide access to location. (Since there are no rules to allow access and the policy language is default-deny.)
ポリシーが設定されていない場合、クライアントは、間接参照要求を行うすべてのユーザーに場所を提供するポリシーを含め、サーバーが場所URIに適用するポリシーを暗黙的に受け入れます。空のポリシーが設定されている場合は、その逆になります。クライアントは、場所へのアクセスを提供しないようにサーバーに指示します。 （アクセスを許可するルールはなく、ポリシー言語はdefault-denyであるため）。
Thus, implementors should consider carefully how to handle the case where the user provides no privacy policy input. On the one hand, an implementation might treat this case as if the user had no privacy preferences and, thus, set no policy. On the other hand, another implementation might decide that if a user provides no positive authorization, then the empty policy should be installed.
したがって、実装者は、ユーザーがプライバシーポリシー入力を提供しない場合の処理方法を慎重に検討する必要があります。一方では、実装はこのケースをユーザーのプライバシー設定がないかのように扱い、ポリシーを設定しない場合があります。一方、別の実装では、ユーザーが明確な承認を提供しない場合、空のポリシーをインストールする必要があると判断する場合があります。
The same reasoning could also be applied to servers, with the caveat that servers do not know whether a given HELD client supports the use of policy URIs. A client that does not understand policy URIs will not be able to set its own policy, so the server must choose a default that is open enough that clients will find it useful. On the other hand, once a client indicates that it understands policy URIs (by including a "requestPolicyUri" element in its HELD request), the server may change its default policy to something more restrictive -- even the empty, default-deny policy -- since the client can specify something more permissive if desired.
同じ推論をサーバーにも適用できます。ただし、サーバーは、特定のHELDクライアントがポリシーURIの使用をサポートしているかどうかを認識しないことに注意してください。ポリシーURIを理解しないクライアントは、独自のポリシーを設定できないため、サーバーは、クライアントが役立つデフォルトを選択する必要があります。一方、クライアントがポリシーのURIを理解していることを（HELDリクエストに "requestPolicyUri"要素を含めることで）示すと、サーバーはデフォルトのポリシーをより制限的なものに変更する可能性があります。 -クライアントは必要に応じてより寛容なものを指定できるため。
Location configuration protocols can provision hosts with location URIs that refer to the host's location. If the target host is to control policy on these URIs, it needs a way to access the policy that the Location Server uses to guide how it serves location URIs. This section defines extensions to LCPs to carry policy URIs that the target can use to control access to location resources.
ロケーション構成プロトコルは、ホストのロケーションを参照するロケーションURIをホストにプロビジョニングできます。ターゲットホストがこれらのURIのポリシーを制御する場合は、ロケーションサーバーがロケーションURIの処理方法をガイドするために使用するポリシーにアクセスする方法が必要です。このセクションでは、ターゲットがロケーションリソースへのアクセスを制御するために使用できるポリシーURIを伝送するためのLCPの拡張を定義します。
The HELD protocol [RFC5985] defines a "locationUriSet" element, which contains a set of one or more location URIs that reference the same resource and share a common access control policy. The schema in Figure 2 defines two extension elements for HELD: an empty "requestPolicyUri" element that is added to a location request to indicate that a Device desires that a policy URI be allocated and a "policyUri" element that is included in the location response.
HELDプロトコル[RFC5985]は、同じリソースを参照し、共通のアクセス制御ポリシーを共有する1つ以上のロケーションURIのセットを含む「locationUriSet」要素を定義します。図2のスキーマは、HELDの2つの拡張要素を定義します。デバイスがポリシーURIの割り当てを希望していることを示すためにロケーション要求に追加される空の「requestPolicyUri」要素と、ロケーション応答に含まれる「policyUri」要素。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv:held:policy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:hp="urn:ietf:params:xml:ns:geopriv:held:policy"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="requestPolicyUri">
<xs:complexType name="empty"/>
</xs:element>
<xs:element name="policyUri" type="xs:anyURI"/>
</xs:schema>
Figure 2: XML Schema for the Policy URI Extension
図2：ポリシーURI拡張のXMLスキーマ
The URI carried in a "policyUri" element refers to the common access control policy for location URIs in the location response. The URI MUST be a policy URI as described in Section 3. A policy URI MUST use the "http:" or "https:" scheme, and the Location Server MUST support the specified operations on the URI.
「policyUri」要素に含まれるURIは、ロケーション応答のロケーションURIの一般的なアクセス制御ポリシーを指します。セクション3で説明されているように、URIはポリシーURIである必要があります。ポリシーURIは「http：」または「https：」スキームを使用する必要があり、ロケーションサーバーはURIで指定された操作をサポートする必要があります。
A HELD request MAY contain an explicit request for a policy URI. The presence of the "requestPolicyUri" element in a location request indicates that a policy URI is desired.
HELDリクエストには、ポリシーURIの明示的なリクエストが含まれる場合があります。ロケーション要求に「requestPolicyUri」要素が存在することは、ポリシーURIが必要であることを示しています。
It is possible that this document will be updated to allow the use of policy URIs that use protocols other than the HTTP-based protocol described above. To ensure that they fail safely when presented with such a URI, clients implementing this specification MUST verify that a policy URI received from HELD uses either the "http:" or "https:" scheme. If the URI does not match those schemes, then the client MUST discard the URI and behave as if no policy URI was provided.
このドキュメントは、上記のHTTPベースのプロトコル以外のプロトコルを使用するポリシーURIの使用を許可するように更新される可能性があります。そのようなURIが提示されたときに安全に失敗することを保証するために、この仕様を実装するクライアントは、HELDから受け取ったポリシーURIが「http：」または「https：」スキームを使用していることを確認する必要があります。 URIがこれらのスキームに一致しない場合、クライアントはURIを破棄し、ポリシーURIが提供されていないかのように動作する必要があります。
In this section, we provide some brief illustrations of how policy URIs are delivered to target hosts and used by those hosts to manage policy.
このセクションでは、ポリシーURIがターゲットホストに配信され、それらのホストがポリシーを管理するためにどのように使用するかを簡単に説明します。
A HELD request that explicitly requests the creation of a policy URI has the following form:
ポリシーURIの作成を明示的に要求するHELD要求の形式は次のとおりです。
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="true">locationURI</locationType>
<requestPolicyUri
xmlns="urn:ietf:params:xml:ns:geopriv:held:policy"/>
</locationRequest>
A HELD response providing a single "locationUriSet", containing two URIs under a common policy, would have the following form:
共通のポリシーに基づく2つのURIを含む単一の「locationUriSet」を提供するHELD応答は、次の形式になります。
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet expires="2011-01-01T13:00:00.0Z">
<locationURI>
https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI>
<locationURI>
sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
</locationURI>
</locationUriSet>
<policyUri xmlns="urn:ietf:params:xml:ns:geopriv:held:policy">
https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b
</policyUri>
</locationResponse>
Consider a client that gets the policy URI <https:// ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b>, as in the above LCP example. The first thing this allows the client to do is inspect the default policy that the LS has assigned to this URI:
上記のLCPの例のように、ポリシーURI <https：// ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b>を取得するクライアントを考えます。これによりクライアントが最初に実行できることは、LSがこのURIに割り当てたデフォルトのポリシーを検査することです。
GET /policy/357lp6f64prlbvhl5nk3b HTTP/1.1
Host: ls.example.com:9768
HTTP/1.1 200 OK
Content-type: application/auth-policy+xml
Content-length: 388
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy">
<rule id="AA56ia9">
<conditions>
<validity>
<until>2011-01-01T13:00:00.0Z</until>
</validity>
</conditions>
<actions/>
<transformations>
<gp:provide-location/>
<gp:set-retransmission-allowed>
false
</gp:set-retransmission-allowed>
<gp:set-retention-expiry>0</gp:set-retention-expiry>
</transformations>
</rule>
</ruleset>
This policy allows any requester to obtain location information, as long as they know the location URI. If the user disagrees with this policy, and prefers for example, to only provide location to one friend, at a city level of granularity, then the client can install this policy on the Location Server: PUT /policy/357lp6f64prlbvhl5nk3b HTTP/1.1 Host: ls.example.com:9768 Content-type: application/auth-policy+xml Content-length: 462
このポリシーでは、リクエスターがロケーションURIを知っている限り、すべてのリクエスターがロケーション情報を取得できます。ユーザーがこのポリシーに同意せず、たとえば都市レベルで1人の友人にのみ場所を提供することを希望する場合、クライアントはこのポリシーをロケーションサーバーにインストールできます。PUT / policy / 357lp6f64prlbvhl5nk3b HTTP / 1.1ホスト： ls.example.com:9768 Content-type：application / auth-policy + xml Content-length：462
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"
xmlns:lp="urn:ietf:params:xml:ns:basic-location-profiles">
<rule id="f3g44r1">
<conditions>
<identity>
<one id="sip:friend@example.com"/>
</identity>
<validity>
<until>2011-01-01T13:00:00.0Z</until>
</validity>
</conditions>
<actions/>
<transformations>
<gp:provide-location
profile="civic-transformation">
<lp:provide-civic>city</lp:provide-civic>
</gp:provide-location>
</transformations>
</rule>
</ruleset>
HTTP/1.1 200 OK
HTTP / 1.1 200 OK
Finally, after using the URI for a period, the user wishes to permanently invalidate the URI.
最後に、URIを一定期間使用した後、ユーザーはURIを永久に無効にしたいと考えています。
DELETE /policy/357lp6f64prlbvhl5nk3b HTTP/1.1
Host: ls.example.com:9768
HTTP/1.1 200 OK
HTTP / 1.1 200 OK
This document requires several IANA registrations, detailed below.
このドキュメントでは、以下に詳述するいくつかのIANA登録が必要です。
6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:policy
This section registers a new XML namespace, "urn:ietf:params:xml:ns:geopriv:held:policy", per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従って、新しいXML名前空間「urn：ietf：params：xml：ns：geopriv：held：policy」を登録します。
URI: urn:ietf:params:xml:ns:geopriv:held:policy
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Richard Barnes (rlb@ipv.sx).
登録者の連絡先：IETF、GEOPRIVワーキンググループ（geopriv@ietf.org）、Richard Barnes（rlb@ipv.sx）。
XML:
XML：
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>HELD Policy URI Extension</title>
</head>
<body>
<h1>Namespace for HELD Policy URI Extension</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held:policy</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7199.txt">
RFC 7199</a>.</p>
</body>
</html>
END
This section registers an XML schema as per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従ってXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:geopriv:held:policy
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Richard Barnes (rlb@ipv.sx)
登録者の連絡先：IETF、GEOPRIVワーキンググループ（geopriv@ietf.org）、Richard Barnes（rlb@ipv.sx）
Schema: The XML for this schema can be found in Section 4.1.
スキーマ：このスキーマのXMLはセクション4.1にあります。
There are two main classes of risks associated with access control policy management: The risk of unauthorized grants or denial of access to the protected resource via manipulation of the policy management process, and the risk of disclosure of policy information itself.
アクセス制御ポリシー管理に関連するリスクには、主に2つのクラスがあります。ポリシー管理プロセスの操作による保護されたリソースへの不正な許可またはアクセス拒否のリスクと、ポリシー情報自体の開示のリスクです。
Protecting the policy management process from manipulation entails two primary requirements. First, the policy URI has to be faithfully and confidentially transmitted to the client; second, the policy document has to be faithfully and confidentially transmitted to the Location Server. The mechanism also needs to ensure that only authorized entities are able to acquire or alter policy.
ポリシー管理プロセスを操作から保護するには、2つの主要な要件があります。まず、ポリシーURIを忠実かつ機密にクライアントに送信する必要があります。 2番目に、ポリシードキュメントはロケーションサーバーに忠実かつ機密に送信する必要があります。このメカニズムでは、承認されたエンティティのみがポリシーを取得または変更できるようにする必要もあります。
Each LCP ensures integrity and confidentiality through different means (see [RFC5985]). These measures ensure that a policy URI is conveyed to the client without modification or interception.
各LCPは、さまざまな手段を通じて完全性と機密性を保証します（[RFC5985]を参照）。これらの手段により、ポリシーURIが変更または傍受されることなくクライアントに確実に伝達されます。
In general, the requirements for TLS on policy transactions are the same as for the dereference transactions they set policy for [RFC6753]. To protect the integrity and confidentiality of policy data during management, the Location Server SHOULD provide policy URIs with the "https:" scheme and require the use of HTTP over TLS [RFC2818]. The cipher suites required by TLS [RFC5246] provide both integrity protection and confidentiality. If other means of protection are available, an "http:" URI MAY be used, but location servers SHOULD reject PUT and DELETE requests for policy URIs that use the "http:" URI scheme.
一般に、ポリシートランザクションでのTLSの要件は、[RFC6753]でポリシーを設定した逆参照トランザクションの要件と同じです。管理中のポリシーデータの完全性と機密性を保護するために、ロケーションサーバーは、ポリシーのURIに「https：」スキームを提供し、HTTP over TLS [RFC2818]の使用を要求する必要があります（SHOULD）。 TLS [RFC5246]で必要な暗号スイートは、整合性保護と機密性の両方を提供します。他の保護手段が利用可能な場合は、「http：」URIを使用できますが、ロケーションサーバーは、「http：」URIスキームを使用するポリシーURIに対するPUTおよびDELETEリクエストを拒否する必要があります（SHOULD）。
Access control for the policy resource is based on knowledge of its URI. The URI of a policy resource operates under the same constraints as a possession model location URI [RFC5808] and is subject to the same constraints:
ポリシーリソースのアクセス制御は、そのURIの知識に基づいています。ポリシーリソースのURIは、所有モデルの場所のURI [RFC5808]と同じ制約の下で動作し、同じ制約を受けます。
o Knowledge of a policy URI MUST be restricted to authorized Rule Makers. Confidentiality and integrity protections SHOULD be used when policy URIs are conveyed in a location configuration protocol and in the requests that are used to inspect, change, or delete the policy resource. Note that in some protocols (such as DHCP), these protections may arise from limiting the use of the protocol to the local network thus relying on lower-layer security mechanisms. When neither application-layer nor network-layer security is provided, location servers MUST reject requests using the PUT and DELETE methods.
oポリシーURIの知識は、承認されたルールメーカーに制限する必要があります。機密性と整合性の保護は、ポリシーURIがロケーション構成プロトコルで伝達される場合、およびポリシーリソースの検査、変更、または削除に使用されるリクエストで使用される必要があります（SHOULD）。一部のプロトコル（DHCPなど）では、これらの保護は、プロトコルの使用をローカルネットワークに制限することで発生し、下位層のセキュリティメカニズムに依存する場合があることに注意してください。アプリケーション層セキュリティもネットワーク層セキュリティも提供されていない場合、ロケーションサーバーはPUTおよびDELETEメソッドを使用してリクエストを拒否する必要があります。
o The Location Server MUST ensure that it is not practical for an attacker to guess a policy URI value, even if the attacker has requested many policy URIs from the Location Server over time. The policy URI MUST NOT be derived solely from information that might be public, including the Target identity or any location URI. The addition of 128 bits or more of random entropy is RECOMMENDED to make it infeasible for a third party to guess a policy URI.
o ロケーションサーバーは、攻撃者が時間の経過とともにロケーションサーバーから多くのポリシーURIを要求した場合でも、攻撃者がポリシーURI値を推測することが実用的でないことを確認する必要があります。ポリシーURIは、ターゲットIDまたは任意のロケーションURIを含む、公開される可能性のある情報のみから派生してはなりません（MUST NOT）。 128ビット以上のランダムエントロピーの追加は、第三者がポリシーURIを推測することを不可能にするために推奨されます。
o Servers SHOULD apply rate limits in order to make brute-force guessing infeasible. If a server allocates location URIs that include N bits of entropy with a lifetime of T seconds, then the server should limit clients to (2^(N/2))/T queries per second. (The lifetime T of a location URI set is specified by the "expires" attribute in HELD.)
o サーバーは、ブルートフォースによる推測を実行不可能にするために、レート制限を適用する必要があります（SHOULD）。サーバーがTビットのライフタイムでNビットのエントロピーを含むロケーションURIを割り当てる場合、サーバーはクライアントを（2 ^（N / 2））/ Tクエリ/秒に制限する必要があります。 （ロケーションURIセットのライフタイムTは、HELDの「expires」属性で指定されます。）
One possible algorithm for generating appropriately unpredictable policy URIs for a location URI set is described in Appendix A.
ロケーションURIセットに対して適切に予測できないポリシーURIを生成するための1つの可能なアルゴリズムは、付録Aで説明されています。
The goal of the above recommendation on rate limiting is to bound the probability that an attacker can guess a policy URI during its lifetime. If an attacker is limited to (2^(N/2))/T queries per second, then he will be able to make at most 2^(N/2) guesses over the lifetime of the URI. Assuming these guesses are distinct, the probability of the attacker guessing any given URI is (2^(N/2))/(2^N), so the probability of compromise over the T-second lifetime of the URI is at most 2^(-N/2). (Of course, if the attacker guesses the URI after the policy URI has expired, then there is no risk.) With N=128, the probability of compromise is 5.4e-20 under this rate-limiting scheme. Operators should choose values for N so that the corresponding risk of compromise presents an acceptable level of risk.
上記のレート制限に関する推奨事項の目標は、攻撃者がその存続期間中にポリシーURIを推測できる確率を制限することです。攻撃者が毎秒（2 ^（N / 2））/ Tクエリに制限されている場合、攻撃者はURIの存続期間中に最大2 ^（N / 2）の推測を行うことができます。これらの推測が異なると仮定すると、攻撃者が特定のURIを推測する確率は（2 ^（N / 2））/（2 ^ N）であるため、URIのT秒の存続期間にわたって妥協する確率は最大で2です。 ^（-N / 2）。 （もちろん、ポリシーURIの有効期限が切れた後で攻撃者がURIを推測した場合、リスクはありません。）N = 128の場合、このレート制限スキームの下での侵害の確率は5.4e-20です。オペレーターは、対応する妥協のリスクが許容可能なレベルのリスクを提示するように、Nの値を選択する必要があります。
If M distinct URIs are issued within the same namespace, then the probability of any of the M URIs being compromised is M*2^(N/2). The example algorithm for generating policy URIs (see Appendix A) places them in independent namespaces (i.e., below the corresponding location URIs), so this compounding does not occur.
M個の異なるURIが同じ名前空間内で発行される場合、M URIのいずれかが侵害される確率はM * 2 ^（N / 2）です。ポリシーURIを生成するためのサンプルアルゴリズム（付録Aを参照）は、ポリシーURIを独立した名前空間（つまり、対応する場所URIの下）に配置するため、この複合は発生しません。
Note that the chosen entropy level will also affect how quickly legitimate clients can query a given URI, especially for very long-lived URIs. If the default lifetime T is greater than 2^(N/2), then clients will have to wait multiple seconds between queries. Operators should choose entropy and lifetime values that result in acceptable high maximum query rates and acceptably low probability of compromise. For example, with 32 bits of entropy (much less than recommended above), the one-query-per-second policy URI lifetime is around 18 hours.
選択されたエントロピーレベルは、特に非常に長期間存続するURIの場合に、正当なクライアントが特定のURIをクエリできる速度にも影響することに注意してください。デフォルトのライフタイムTが2 ^（N / 2）より大きい場合、クライアントはクエリ間で数秒間待機する必要があります。オペレーターは、エントロピーとライフタイムの値を選択する必要があります。これにより、許容可能な最大クエリレートが高くなり、妥協の確率が許容できるほど低くなります。たとえば、32ビットのエントロピー（上記の推奨値よりもはるかに少ない）の場合、1秒あたりのクエリのポリシーURIの有効期間は約18時間です。
A policy URI enables the authorization by access control lists model [RFC5808] for associated location URIs. Under this model, it might be possible to more widely distribute a location URI, relying on the authorization policy to constrain access to location information.
ポリシーURIは、関連するロケーションURIのアクセスコントロールリストモデル[RFC5808]による認証を可能にします。このモデルでは、認可ポリシーに基づいてロケーション情報へのアクセスを制限し、ロケーションURIをより広く配布できる可能性があります。
To allow for wider distribution, authorization by access control lists places additional constraints on the construction of location URIs.
より幅広い配布を可能にするために、アクセス制御リストによる承認は、ロケーションURIの構築に追加の制約を課します。
If multiple Targets share a location URI, an unauthorized location recipient that acquires location URIs for the Targets can determine that the Targets are at the same location by comparing location URIs. With shared policy URIs, Targets are able to see and modify authorization policy for other Targets.
複数のターゲットがロケーションURIを共有している場合、ターゲットのロケーションURIを取得する未承認のロケーション受信者は、ロケーションURIを比較することにより、ターゲットが同じロケーションにあると判断できます。共有ポリシーURIを使用すると、ターゲットは他のターゲットの承認ポリシーを表示および変更できます。
To allow for the creation of Target-specific authorization policies that are adequately privacy protected, each location URI and policy URI that is issued to a different Target MUST be different from other location URIs and policy URIs. That is, two clients MUST NOT receive the same location URI or the same policy URI.
適切にプライバシー保護されたターゲット固有の許可ポリシーの作成を可能にするために、異なるターゲットに発行される各ロケーションURIおよびポリシーURIは、他のロケーションURIおよびポリシーURIとは異なる必要があります。つまり、2つのクライアントが同じ場所URIまたは同じポリシーURIを受信してはなりません（MUST NOT）。
In some deployments, it is not always apparent to an LCP server that two clients are different. In particular, where a middlebox [RFC3234] exists, two or more clients might appear as a single client. An example of a deployment scenario of this nature is described in [RFC5687]. An LCP server MUST create a different location URI and policy URI for every request, unless the requests can be reliably identified as being from the same client.
一部の展開では、LCPサーバーに2つのクライアントが異なることが常に明らかであるとは限りません。特に、ミドルボックス[RFC3234]が存在する場合、2つ以上のクライアントが単一のクライアントとして表示されることがあります。この性質の配備シナリオの例は、[RFC5687]で説明されています。 LCPサーバーは、リクエストが同じクライアントからのものであると確実に識別できない限り、リクエストごとに異なる場所URIとポリシーURIを作成する必要があります。
Although servers may choose to implement access controls on policy URIs, by default, any holder of a policy URI is authorized to access and modify the referenced policy document and, thus, to control access to the associated location resources. Because policy URIs function as shared secrets, clients SHOULD protect them as they would passwords. For example, policy URIs SHOULD NOT be transmitted to other hosts or stored in plaintext.
サーバーはポリシーURIにアクセス制御を実装することを選択できますが、デフォルトでは、ポリシーURIの所有者は、参照されたポリシードキュメントへのアクセスと変更、したがって関連する位置リソースへのアクセスの制御が許可されます。ポリシーURIは共有シークレットとして機能するため、クライアントはパスワードと同様に保護する必要があります（SHOULD）。たとえば、ポリシーURIは他のホストに送信したり、プレーンテキストで保存したりしないでください。
It should be noted that one of the benefits of the policy URI construct is that in most cases, there is not a policy URI to leave the client device to which it is provided. Without policy URIs, location URIs are subject to a default policy set unilaterally by the server, and location URIs must be conveyed to another entity in order to be useful. With policy URIs, location URIs can have more nuanced access controls, and the shared secret used to authenticate the client (i.e., the policy URI) can simply be stored on the client and used to set the access control policy on the location URI. So while policy URIs do use a default model of authorization by possession, they reduce the overall risk to location privacy posed by leakage of shared secret URIs.
ポリシーURI構造の利点の1つは、ほとんどの場合、クライアントURIが提供されたままにするポリシーURIがないことです。ポリシーURIがない場合、ロケーションURIはサーバーによって一方的に設定されたデフォルトのポリシーの影響を受けます。ロケーションURIを使用するには、別のエンティティに伝達する必要があります。ポリシーURIを使用すると、ロケーションURIはより微妙なアクセス制御を持つことができ、クライアントの認証に使用される共有シークレット（つまり、ポリシーURI）はクライアントに単に格納され、ロケーションURIにアクセス制御ポリシーを設定するために使用されます。したがって、ポリシーURIは所有によるデフォルトの承認モデルを使用しますが、共有秘密URIの漏洩によってもたらされる位置プライバシーへの全体的なリスクを軽減します。
Thanks to Mary Barnes and Alissa Cooper for providing critical commentary and input on the ideas described in this document. Also, thanks to Ted Hardie and Adam Roach for helping clarify the relationships between policy URIs, policy documents, and location resources. Thanks to Stephen Farrell for a helpful discussion on security and privacy challenges.
このドキュメントで説明されているアイデアについて批判的な解説と情報を提供してくれたMary BarnesとAlissa Cooperに感謝します。また、ポリシーURI、ポリシードキュメント、およびロケーションリソース間の関係を明確にしてくれたTed HardieとAdam Roachに感謝します。セキュリティとプライバシーの課題について有益な議論をしてくれたStephen Farrellに感謝します。
[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月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。、およびL. Stewart、「HTTP Authentication：Basic and Digest Access Authentication」 、RFC 2617、1999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、E。、「HTTP over TLS」、RFC 2818、2000年5月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling M。、「The IETF XML Registry」、BCP 81、RFC 3688、2004年1月。
[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, "Common Policy: A Document Format for Expressing Privacy Preferences", RFC 4745, February 2007.
[RFC4745] Schulzrinne、H.、Tschofenig、H.、Morris、J.、Cuellar、J.、Polk、J.、J。Rosenberg、「Common Policy：A Document Format for Expressing Privacy Preferences」、RFC 4745、2月2007年
[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）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.
[RFC5985] Barnes、M。、「HTTP-Enabled Location Delivery（HELD）」、RFC 5985、2010年9月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]カーペンター、B。およびS.ブリム、「ミドルボックス：分類と問題」、RFC 3234、2002年2月。
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3693] Cuellar、J.、Morris、J.、Mulligan、D.、Peterson、J。、およびJ. Polk、「Geopriv要件」、RFC 3693、2004年2月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119] Peterson、J。、「A Presence-based GEOPRIV Location Object Format」、RFC 4119、2005年12月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、2006年10月。
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4825] Rosenberg、J。、「Extensible Markup Language（XML）Configuration Access Protocol（XCAP）」、RFC 4825、2007年5月。
[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
[RFC4918] Dusseault、L。、「Web Distributed Authoring and Versioning（WebDAV）のHTTP拡張機能」、RFC 4918、2007年6月。
[RFC5606] Peterson, J., Hardie, T., and J. Morris, "Implications of 'retransmission-allowed' for SIP Location Conveyance", RFC 5606, August 2009.
[RFC5606] Peterson、J.、Hardie、T。、およびJ. Morris、「SIP Location Conveyanceの「再送信許可」の影響」、RFC 5606、2009年8月。
[RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements", RFC 5687, March 2010.
[RFC5687] Tschofenig、H。およびH. Schulzrinne、「GEOPRIV Layer 7 Location Configuration Protocol：Problem Statement and Requirements」、RFC 5687、2010年3月。
[RFC5808] Marshall, R., "Requirements for a Location-by-Reference Mechanism", RFC 5808, May 2010.
[RFC5808] Marshall、R。、「Location-by-Referenceメカニズムの要件」、RFC 5808、2010年5月。
[RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. Barnes, "Use of Device Identity in HTTP-Enabled Location Delivery (HELD)", RFC 6155, March 2011.
[RFC6155] Winterbottom、J.、Thomson、M.、Tschofenig、H。、およびR. Barnes、「Use-Device Identity in HTTP-Enabled Location Delivery（HELD）」、RFC 6155、2011年3月。
[RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information", RFC 6225, July 2011.
[RFC6225] Polk、J.、Linsner、M.、Thomson、M。、およびB. Aboba、「Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information」、RFC 6225、2011年7月。
[RFC6753] Winterbottom, J., Tschofenig, H., Schulzrinne, H., and M. Thomson, "A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD)", RFC 6753, October 2012.
[RFC6753] Winterbottom、J.、Tschofenig、H.、Schulzrinne、H。、およびM. Thomson、「HTTP対応のロケーション配信（HELD）を使用したロケーション逆参照プロトコル」、RFC 6753、2012年10月。
[RFC6772] Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J., Morris, J., and M. Thomson, "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", RFC 6772, January 2013.
[RFC6772] Schulzrinne、H.、Tschofenig、H.、Cuellar、J.、Polk、J.、Morris、J。、およびM. Thomson、「Geolocation Policy：A Document Format for Express Privacy Preferences for Location Information」、RFC 6772、2013年1月。
One possible algorithm for generating appropriately unpredictable policy URIs for a location URI set is as follows:
ロケーションURIセットに対して適切に予測できないポリシーURIを生成するための1つの可能なアルゴリズムは次のとおりです。
1. Choose parameters:
1. パラメータを選択：
* A cryptographic hash function H, e.g., SHA256
* 暗号化ハッシュ関数H（SHA256など）
* A number N of bits of entropy to add, such that N is no more than the length of the output of the hash function
* 追加するエントロピーのビット数N。Nはハッシュ関数の出力の長さ以下です。
2. On allocation of a location URI, generate a policy URI in the following way:
2. ロケーションURIの割り当て時に、次の方法でポリシーURIを生成します。
1. Generate a random value NONCE at least N/8 bytes long
1. N / 8バイト以上のランダムな値を生成する
2. Compute hash = H( Location-URI-Set || NONCE ) using some cryptographic hash function H and some serialization of the location URI set (e.g., the XML from a HELD response)
2. 暗号化ハッシュ関数HとロケーションURIセットのシリアル化を使用して、ハッシュ= H（Location-URI-Set || NONCE）を計算します（たとえば、HELD応答からのXML）
3. Form the policy URI by appending the base64url-encoded form of the hash [RFC4648] to one of the location URIs, e.g., as a query parameter: "http://example.com/loc/ foo?policy=j3WTGUb3smxcZA6eKIqmqdV3ALE"
3. ハッシュの[base64url-encoded]形式[RFC4648]をロケーションURIの1つに追加することにより、ポリシーURIを形成します。たとえば、クエリパラメータとして： "http://example.com/loc/ foo？policy = j3WTGUb3smxcZA6eKIqmqdV3ALE"
Authors' Addresses
著者のアドレス
Richard Barnes Mozilla 331 E. Evelyn Ave. Mountain View, CA 94041 US
リチャードバーンズMozilla 331 E. Evelyn Ave. Mountain View、CA 94041 US
EMail: rlb@ipv.sx
Martin Thomson Mozilla Suite 300 331 E Evelyn Street Mountain View, CA 94041 US
マーティントムソンMozilla Suite 300 331 E Evelyn Street Mountain View、CA 94041 US
EMail: martin.thomson@gmail.com
James Winterbottom Unaffiliated AU
ジェームズウィンターボトムアフィリエイトオーストラリア
EMail: a.james.winterbottom@gmail.com
Hannes Tschofenig Hall in Tirol 6060 Austria
Hannes Tschofenig Hall in Tirol 6060オーストリア
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at