diff options
Diffstat (limited to 'doc/rfc/rfc4119.txt')
| -rw-r--r-- | doc/rfc/rfc4119.txt | 1347 |
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc4119.txt b/doc/rfc/rfc4119.txt new file mode 100644 index 0000000..5e7c19e --- /dev/null +++ b/doc/rfc/rfc4119.txt @@ -0,0 +1,1347 @@ + + + + + + +Network Working Group J. Peterson +Request for Comments: 4119 NeuStar +Category: Standards Track December 2005 + + + A Presence-based GEOPRIV Location Object Format + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document describes an object format for carrying geographical + information on the Internet. This location object extends the + Presence Information Data Format (PIDF), which was designed for + communicating privacy-sensitive presence information and which has + similar properties. + + + + + + + + + + + + + + + + + + + + + + + + + +Peterson Standards Track [Page 1] + +RFC 4119 GEOPRIV Location Object December 2005 + + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Conventions Used in This Document ..........................3 + 2. Location Object Format ..........................................4 + 2.1. Baseline PIDF Usage ........................................4 + 2.2. Extensions to PIDF for Location and Usage Rules ............5 + 2.2.1. 'location-info' Element .............................5 + 2.2.2. 'usage-rules' Element ...............................7 + 2.2.3. 'method' Element ....................................9 + 2.2.4. 'provided-by' Element ...............................9 + 2.2.5. Schema Definitions .................................10 + 2.3. Example Location Objects ..................................14 + 3. Carrying PIDF in a Using Protocol ..............................15 + 4. Securing PIDF ..................................................15 + 5. Security Considerations ........................................17 + 6. IANA Considerations ............................................17 + 6.1. 'method' Tokens ...........................................17 + 6.2. 'provided-by' Elements ....................................18 + 6.3. URN Sub-Namespace Registration for + urn:ietf:params:xml:ns:pidf:geopriv10 .....................18 + 7. Acknowledgements ...............................................19 + A. Appendix: NENA Provided-by Schema ..............................20 + A.1. dataProvider XML Schema ...................................21 + Normative References ..............................................22 + Informative References ............................................22 + +1. Introduction + + Geographical location information describes a physical position in + the world that may correspond to the past, present, or future + location of a person, event, or device. Numerous applications used + in the Internet today benefit from sharing location information + (including mapping/navigation applications, 'friend finders' on cell + phones, and so on). However, such applications may disclose the + whereabouts of a person in a manner contrary to the user's + preferences. Privacy lapses may result from poor protocol security + (which permits eavesdroppers to capture location information), + inability to articulate or accommodate user preferences, or similar + defects common in existing systems. The privacy concerns surrounding + the unwanted disclosure of a person's physical location are among the + more serious issues that confront users on the Internet. + + Consequently, a need has been identified to convey geographical + location information within an object that includes a user's privacy + and disclosure preferences and which is protected by strong + cryptographic security. Previous work [13] has observed that this + problem bears some resemblance to the general problem of + + + +Peterson Standards Track [Page 2] + +RFC 4119 GEOPRIV Location Object December 2005 + + + communicating and securing presence information on the Internet. + Presence (defined in [12]) provides a real-time communications + disposition for a user, and thus has similar requirements for + selective distribution and security. + + Therefore, this document extends the XML-based Presence Information + Data Format (PIDF [2]) to allow the encapsulation of location + information within a presence document. + + This document does not invent any format for location information + itself. Numerous existing formats based on civic location, + geographic coordinates, and the like, have been developed in other + standards fora. Instead, this document defines an object that is + suitable both for identifying and encapsulating preexisting location + information formats, and for providing adequate security and policy + controls to regulate the distribution of location information over + the Internet. + + The location object described in this document can be used + independently of any 'using protocol', as the term is defined in the + GEOPRIV requirements [10]. It is considered an advantage of this + proposal that existing presence protocols (such as [14]) would + natively accommodate the location object format defined in this + document, and be capable of composing location information with other + presence information, because this location object is an extension of + PIDF. However, the usage of this location object format is not + limited to presence-using protocols-- any protocol that can carry XML + or MIME types can carry PIDF. + + Some of the requirements in [10] and [11] concern data collection and + usage policies associated with location objects. This document + provides only the minimum markup necessary for a user to express the + necessary privacy preferences as specified by the GEOPRIV + requirements (the three basic elements in [11]). However, this + document does not demonstrate how a full XML-based ruleset, + accommodating the needs of Location Servers, could be embedded in + PIDF. It is assumed that other protocols (such as HTTP) will be used + to move rules between Rule Holders and Location Servers, and that + full rulesets will be defined in a separate document. + +1.1. Conventions Used in This Document + + 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 [1]. + + + + + + +Peterson Standards Track [Page 3] + +RFC 4119 GEOPRIV Location Object December 2005 + + +2. Location Object Format + +2.1. Baseline PIDF Usage + + The GEOPRIV requirements [10] (or REQ for short) specify the need for + a name for the person, place or thing that location information + describes (REQ 2.1). PIDF has such an identifier already: every + PIDF document has an "entity" attribute of the 'presence' element + that signifies the URI of the entity whose presence the document + describes. Consequently, if location information is contained in a + PIDF document, the URI in the "entity" attribute of the 'presence' + element indicates the target of that location information (the + 'presentity'). The URI in the "entity" attribute generally uses the + "pres" URI scheme defined in [3]. Such URIs can serve as unlinkable + pseudonyms (per REQ 12). + + PIDF optionally contains a 'contact' element that provides a URI + where the presentity can be reached by some means of communication. + Usually, the URI scheme in the value of the 'contact' element gives + some sense of how the presentity can be reached; if it uses the SIP + URI scheme, for example, SIP can be used, and so on. Location + information can be provided without any associated means of + communication. Thus, the 'contact' element may or may not be + present, as desired by the creator of the PIDF document. + + PIDF optionally contains a 'timestamp' element that designates the + time at which the PIDF document was created. This element + corresponds to REQ 2.7a. + + PIDF contains a 'status' element, which is mandatory. 'status' + contains an optional child element, 'basic', that describes the + presentity's communications disposition (in very broad terms: either + OPEN or CLOSED). For the purposes of this document, it is not + necessary for 'basic' status to be included. If, however, + communications disposition is included in a PIDF document above and + beyond geolocation, then 'basic' status may appear in a PIDF document + that uses these extensions. + + PIDF also contains a 'tuple' umbrella element, which holds an "id" + element used to uniquely identify a segment of presence information + so that changes to this information can be tracked over time (as + multiple notifications of presence are received). 'timestamp', + 'status', and 'contact' are composed under 'tuple'. + + + + + + + + +Peterson Standards Track [Page 4] + +RFC 4119 GEOPRIV Location Object December 2005 + + +2.2. Extensions to PIDF for Location and Usage Rules + + This XML Schema extends the 'status' element of PIDF with a complex + element called 'geopriv'. There are two major subelements that are + encapsulated within geopriv: one for location information, and one + for usage rules. Both of these subelements are mandatory, and are + described in subsequent sections. By composing these two subelements + under 'geopriv', the usage rules are clearly and explicitly + associated with the location information. + + For extensibility (see REQ 1.4), the schema allows any other + subelements to appear under the 'geopriv' element. Two other + optional subelements are included in this document: one that + indicates the method by which geographical location was determined, + and one that allows an explicit designation of the entity that + provided the information. + +2.2.1. 'location-info' Element + + Each 'geopriv' element MUST contain one 'location-info' element. A + 'location-info' element consists of one or more chunks of location + information (per REQ 2.5). The format of the location information + (REQ 2.6) is identified by the imported XML Schema, which describes + the namespace in question. All PIDF documents that contain a + 'geopriv' element MUST contain one or more import directives + indicating the XML Schema(s) that are used for geographic location + formats. + + In order to ensure interoperability of GEOPRIV implementations, it is + necessary to select a baseline location format that all compliant + implementations support (see REQ 3.1). Because it satisfies REQ + 2.5.1, this document works from the assumption that Geography Markup + Language (GML) 3.0 [15] shall be this mandatory format (a MUST + implement for all PIDF implementations supporting the 'geopriv' + element). + + GML is an extraordinarily thorough and versatile system for modeling + all manner of geographic object types, topologies, metadata, + coordinate reference systems, and units of measurement. The simplest + package for GML supporting location + + information is the 'feature.xsd' schema. Although 'feature.xsd' can + express complicated geographical concepts, it requires very little + markup to provide basic coordinate points for the most commonly used + cases. Various format descriptions (including latitude/longitude + based location information) are supported by Feature (see section + 7.4.1.4 of [15] for examples), which resides here: + + + + +Peterson Standards Track [Page 5] + +RFC 4119 GEOPRIV Location Object December 2005 + + + urn:opengis:specification:gml:schema-xsd:feature:v3.0 + + Note that by importing the Feature schema, necessary GML baseline + schemas are transitively imported. + + Complex features (such as modeling topologies and polygons, + directions and vectors, temporal indications of the time for which a + particular location is valid for a target) are also available in GML, + but require importing additional schemas. For the purposes of + baseline interoperability as defined by this document, only support + for the 'feature.xsd' GML schema is REQUIRED. + + Implementations MAY support the civic location format (civicLoc) + defined in Section 2.2.5. civicLoc provides the following elements: + + +----------------------+----------------------+---------------------+ + | Label | Description | Example | + +----------------------+----------------------+---------------------+ + | country | The country is | US | + | | identified by the | | + | | two-letter ISO 3166 | | + | | code. | | + | | | | + | A1 | national | New York | + | | subdivisions (state, | | + | | region, province, | | + | | prefecture) | | + | | | | + | A2 | county, parish, gun | King's County | + | | (JP), district (IN) | | + | | | | + | A3 | city, township, shi | New York | + | | (JP) | | + | | | | + | A4 | city division, | Manhattan | + | | borough, city | | + | | district, ward, chou | | + | | (JP) | | + | | | | + | A5 | neighborhood, block | Morningside Heights | + | | | | + | A6 | street | Broadway | + | | | | + | PRD | Leading street | N, W | + | | direction | | + | | | | + | POD | Trailing street | SW | + | | suffix | | + + + +Peterson Standards Track [Page 6] + +RFC 4119 GEOPRIV Location Object December 2005 + + + | | | | + | STS | Street suffix | Avenue, Platz, | + | | | Street | + | | | | + | HNO | House number, | 123 | + | | numeric part only. | | + | | | | + | HNS | House number suffix | A, 1/2 | + | | | | + | LMK | Landmark or vanity | Low Library | + | | address | | + | | | | + | LOC | Additional location | Room 543 | + | | information | | + | | | | + | FLR | Floor | 5 | + | | | | + | NAM | Name (residence, | Joe's Barbershop | + | | business or office | | + | | occupant) | | + | | | | + | PC | Postal code | 10027-0401 | + +----------------------+----------------------+---------------------+ + + Either the GML 3.0 geographical information format element, or the + location format element ('civicLoc') defined in this document, MAY + appear in a 'location-info' element. Both MAY also be used in the + same 'location-info' element. In summary, the feature.xsd schema of + GML 3.0 MUST be supported by implementations compliant with this + specification, and the civicLoc format MAY be supported by + implementations compliant with this specification. + +2.2.2. 'usage-rules' Element + + At the time this document was written, the policy requirements for + GEOPRIV objects were not definitively completed. However, the + 'usage-rules' element exists to satisfy REQ 2.8 and the requirements + of the GEOPRIV policy requirements [11] document. Each 'geopriv' + element MUST contain one 'usage-rules' element, even if the Rule + + Maker has requested that all subelements be given their default + values. + + Following the policy requirements document (Section 3.1), there are + three fields that need to be expressible in Location Objects + throughout their lifecycle (from Generator to Recipient): one field + that limits retransmission, one that limits retention, and one that + contains a reference to external rulesets. Those three fields are + + + +Peterson Standards Track [Page 7] + +RFC 4119 GEOPRIV Location Object December 2005 + + + instantiated here by the first three elements. The fourth element + provides a generic space for human-readable policy directives. Any + of these fields MAY be present in a Location Object 'usage-rules' + element; none are required to be. + + 'retransmission-allowed': When the value of this element is 'no', the + Recipient of this Location Object is not permitted to share the + enclosed Location Information, or the object as a whole, with + other parties. When the value of this element is 'yes', + distributing this Location is permitted (barring an existing out- + of-band agreement or obligation to the contrary). By default, the + value MUST be assumed to be 'no'. Implementations MUST include + this field, with a value of 'no', if the Rule Maker specifies no + preference. + + 'retention-expires': This field specifies an absolute date at which + time the Recipient is no longer permitted to possess the location + information and its encapsulating Location Object; both may be + retained only until the time specified by this field. By default, + the value MUST be assumed to be twenty-four hours from the + 'timestamp' element in the PIDF document, if present; if the + 'timestamp' element is also not present, then the value MUST be + assumed to be twenty-four hours from the time at which the + Location Object is received by the Location Recipient. If the + value in the 'retention-expires' element has already passed when + the Location Recipient receives the Location Object, the Recipient + MUST discard the Location Object immediately. + + 'ruleset-reference': This field contains a URI that indicates where a + fuller ruleset of policies, related to this object, can be found. + This URI SHOULD use the HTTPS URI scheme; and if it does, the + server that holds these rules MUST authenticate any attempt to + access these rules. Usage rules themselves may divulge private + information about a Target or Rule Maker. The URI MAY, + alternatively, use the CID URI scheme [7], in which case it MUST + denote a MIME body carried with the Location Object by the using + protocol. Rulesets carried as MIME bodies SHOULD be encrypted and + signed by the Rule Maker; unsigned rulesets SHOULD NOT be honored + by Location Servers or Location Recipients. Note that in order to + avoid network lookups that result in an authorization failure, + creators of Location Objects MAY put HTTPS-based ruleset- + references into an encrypted external MIME body referenced by a + CID; in this way, recipients of the Location Object that are + unable to decrypt the external MIME body will not learn the HTTPS + URI unless they are able to decrypt the MIME body. + + + + + + +Peterson Standards Track [Page 8] + +RFC 4119 GEOPRIV Location Object December 2005 + + + 'note-well': This field contains a block of text containing further + generic privacy directives. These directives are intended to be + human-readable only, not to be processed by any automaton. + +2.2.3. 'method' Element + + The optional 'method' element describes the way that the location + information was derived or discovered. An example of this element + (for a geographical position system) is: + + <method>gps</method> + + The possible values of the 'method' element are enumerated within an + IANA registry. Implementations MUST limit the use of this method to + the values shepherded by IANA. This document pre-populates the IANA + registry with seven possible values; see Section 6.1 for more + information. + + The 'method' element is useful, for example, when multiple sources + are reporting location information for a given user, and some means + of determining location might be considered more authoritative than + others (i.e., a dynamic, real-time position system versus static + provisioning associated with a target device). However, note that + inclusion of 'method' might reveal sensitive information when the + generator is providing intentionally coarsened location information. + For example, when a LO is transmitted with 'DHCP' as the 'method', + but the location information indicates only the city in which the + generator is located, the sender has good justification to suspect + that some location information is being withheld. + +2.2.4. 'provided-by' Element + + The optional 'provided-by' element describes the entity or + organization that supplied this location information (beyond the + domain information that can be inferred from a signing certificate). + An example of this element (for a made-up game system) might be: + + <provided-by> + <test:game> + West5 + </test:game> + </provided-by> + + Values for the 'provided-by' element MUST be IANA-registered XML + namespaces; see Section 6.2 for more information. + + + + + + +Peterson Standards Track [Page 9] + +RFC 4119 GEOPRIV Location Object December 2005 + + + The 'provided-by' element is not intended for use by most entities, + but rather to meet special requirements for which overhead (IANA + registration, location object size) and potential location + information leakage are acceptable choices. + + In general cases, the entity that supplied location information is + communicated by the subjectAltName of the certificate with which the + location object is signed; thus, this element is unnecessary. + 'Provided-by' is meaningful in particular cases when the creator of a + location object wants to designate a particular system or party + within a complex administrative domain, including situations + envisioned for providing emergency services in a diverse national + context. It might assist, for example, the recipient of a malformed + or misleading location object in identifying the particular system + that malfunctioned. + + Users should be aware that this information can inadvertently provide + additional information to the receiver, increasing the effective + resolution of the geospatial or civic information, or even revealing + some location information, when it was meant to be entirely + protected. Consider if there were circumstances that influenced + Columbia University to elect to register and use the provided-by + element. If an example LO includes only state-level information, + then including the fact that the location information was provided by + Columbia University provides a strong indication that the Target is + actually located in a four-block area in Manhattan. Accordingly, + this element should be used only when organizational functions + strongly would depend on it. In all but such usages, the + subjectAltName of the certificate will suffice, and 'provided-by' + SHOULD NOT be used. + +2.2.5. Schema Definitions + + Note that the XML namespace [4] for this extension to PIDF contains a + version number 1.0 (as per REQ 2.10). + + <?xml version="1.0" encoding="UTF-8"?> + <xs:schema + targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10" + xmlns:tns="urn:ietf:params:xml:ns:pidf:geopriv10" + xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy" + xmlns:xs="http://www.w3.org/2001/XMLSchema" + elementFormDefault="qualified" attributeFormDefault="unqualified"> + + <xs:import namespace= + "urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy" /> + + <!-- This import brings in the XML language attribute xml:lang--> + + + +Peterson Standards Track [Page 10] + +RFC 4119 GEOPRIV Location Object December 2005 + + + <xs:import namespace="http://www.w3.org/XML/1998/namespace" + schemaLocation="http://www.w3.org/2001/xml.xsd"/> + + <xs:element name="geopriv" type="tns:geopriv"/> + + <xs:complexType name="geopriv"> + <xs:sequence> + <xs:element name="location-info" type="tns:locInfoType" + minOccurs="1" maxOccurs="1"/> + <xs:element name="usage-rules" type="gbp:locPolicyType" + minOccurs="1" maxOccurs="1"/> + <xs:element name="method" type="tns:locMethod" + minOccurs="0" maxOccurs="1"/> + <xs:element name="provided-by" type="tns:locProvidedBy" + minOccurs="0" maxOccurs="1"/> + <xs:any namespace="##other" processContents="lax" minOccurs="0" + maxOccurs="unbounded"/> + </xs:sequence> + </xs:complexType> + + <xs:complexType name="locInfoType"> + <xs:sequence> + <xs:any namespace="##other" processContents="lax" minOccurs="0" + maxOccurs="unbounded"/> + </xs:sequence> + </xs:complexType> + + <xs:complexType name="locMethod"> + <xs:simpleContent> + <xs:extension base="xs:string"> + <xs:attribute ref="xml:lang" /> + </xs:extension> + </xs:simpleContent> + </xs:complexType> + + <xs:complexType name="locProvidedBy"> + <xs:sequence> + <xs:any namespace="##other" processContents="skip" + minOccurs="1" maxOccurs="unbounded"/> + </xs:sequence> + </xs:complexType> + + </xs:schema> + + The 'geopriv10' schema imports, for the 'usage-rules' element, the + following policy schema. This schema has been broken out from the + basic geolocation object in order to allow for its reuse. The + semantics associated with these elements, described in Section 2.2.2, + + + +Peterson Standards Track [Page 11] + +RFC 4119 GEOPRIV Location Object December 2005 + + + apply only to the use of these elements to define policy for + geolocation objects; any other use of 'usage-rules' must characterize + its own semantics for all 'usage-rules' subelements. + +<?xml version="1.0" encoding="UTF-8"?> +<xs:schema + targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy" + xmlns:tns="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy" + xmlns:xs="http://www.w3.org/2001/XMLSchema" + elementFormDefault="qualified" attributeFormDefault="unqualified"> + + <!-- This import brings in the XML language attribute xml:lang--> + <xs:import namespace="http://www.w3.org/XML/1998/namespace" + schemaLocation="http://www.w3.org/2001/xml.xsd"/> + + <xs:complexType name="locPolicyType"> + <xs:sequence> + <xs:element name="retransmission-allowed" type="xs:boolean" + minOccurs="0" maxOccurs="1"/> + <xs:element name="retention-expiry" type="xs:dateTime" + minOccurs="0" maxOccurs="1"/> + <xs:element name="external-ruleset" type="xs:anyURI" + minOccurs="0" maxOccurs="1"/> + <xs:element name="note-well" type="tns:notewell" + minOccurs="0" maxOccurs="1"/> + <xs:any namespace="##other" processContents="lax" minOccurs="0" + maxOccurs="unbounded"/> + </xs:sequence> + </xs:complexType> + + <xs:complexType name="notewell"> + <xs:simpleContent> + <xs:extension base="xs:string"> + <xs:attribute ref="xml:lang" /> + </xs:extension> + </xs:simpleContent> + </xs:complexType> + +</xs:schema> + + The following schema is a trivial representation of civic location + that MAY be implemented by entities compliant with this + specification. + + <?xml version="1.0" encoding="UTF-8"?> + <xs:schema + targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc" + xmlns:tns="urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc" + + + +Peterson Standards Track [Page 12] + +RFC 4119 GEOPRIV Location Object December 2005 + + + xmlns:xs="http://www.w3.org/2001/XMLSchema" + elementFormDefault="qualified" attributeFormDefault="unqualified"> + + <xs:complexType name="civicAddress"> + <xs:sequence> + <xs:element name="country" type="xs:string" + minOccurs="0" maxOccurs="1"/> + <xs:element name="A1" type="xs:string" + minOccurs="0" maxOccurs="1"/> + <xs:element name="A2" type="xs:string" + minOccurs="0" maxOccurs="1"/> + <xs:element name="A3" type="xs:string" + minOccurs="0" maxOccurs="1"/> + <xs:element name="A4" type="xs:string" + minOccurs="0" maxOccurs="1"/> + <xs:element name="A5" type="xs:string" + minOccurs="0" maxOccurs="1"/> + <xs:element name="A6" type="xs:string" + minOccurs="0" maxOccurs="1"/> + <xs:element name="PRD" type="xs:string" + minOccurs="0" maxOccurs="1"/> + <xs:element name="POD" type="xs:string" + minOccurs="0" maxOccurs="1"/> + <xs:element name="STS" type="xs:string" + minOccurs="0" maxOccurs="1"/> + <xs:element name="HNO" type="xs:string" + minOccurs="0" maxOccurs="1"/> + <xs:element name="HNS" type="xs:string" + minOccurs="0" maxOccurs="1"/> + <xs:element name="LMK" type="xs:string" + minOccurs="0" maxOccurs="1"/> + <xs:element name="LOC" type="xs:string" + minOccurs="0" maxOccurs="1"/> + <xs:element name="FLR" type="xs:string" + minOccurs="0" maxOccurs="1"/> + <xs:element name="NAM" type="xs:string" + minOccurs="0" maxOccurs="1"/> + <xs:element name="PC" type="xs:string" + minOccurs="0" maxOccurs="1"/> + <xs:any namespace="##other" processContents="lax" minOccurs="0" + maxOccurs="unbounded"/> + </xs:sequence> + </xs:complexType> + + </xs:schema> + + + + + + +Peterson Standards Track [Page 13] + +RFC 4119 GEOPRIV Location Object December 2005 + + +2.3. Example Location Objects + + Note that these examples show PIDF documents without any MIME headers + or security applied to them (see Section 4 below). + + The following XML instance document is an example of the use of a + simple GML 3.0 markup with a few of the policy directives specified + above within a PIDF document. The GPS coordinates given in the 'gml' + element are for San Francisco, CA. + +<?xml version="1.0" encoding="UTF-8"?> + <presence xmlns="urn:ietf:params:xml:ns:pidf" + xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" + xmlns:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0" + entity="pres:geotarget@example.com"> + <tuple id="sg89ae"> + <status> + <gp:geopriv> + <gp:location-info> + <gml:location> + <gml:Point gml:id="point1" srsName="epsg:4326"> + <gml:coordinates>37:46:30N 122:25:10W</gml:coordinates> + </gml:Point> + </gml:location> + </gp:location-info> + <gp:usage-rules> + <gp:retransmission-allowed>no</gp:retransmission-allowed> + <gp:retention-expiry>2003-06-23T04:57:29Z</gp:retention-expiry> + </gp:usage-rules> + </gp:geopriv> + </status> + <timestamp>2003-06-22T20:57:29Z</timestamp> + </tuple> + </presence> + + The following XML instance document is an example of the use of the + civicLoc object with a few of the policy directives specified above + within a PIDF document. + +<?xml version="1.0" encoding="UTF-8"?> + <presence xmlns="urn:ietf:params:xml:ns:pidf" + xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" + xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc" + entity="pres:geotarget@example.com"> + <tuple id="sg89ae"> + <status> + <gp:geopriv> + <gp:location-info> + + + +Peterson Standards Track [Page 14] + +RFC 4119 GEOPRIV Location Object December 2005 + + + <cl:civicAddress> + <cl:country>US</cl:country> + <cl:A1>New York</cl:A1> + <cl:A3>New York</cl:A3> + <cl:A6>Broadway</cl:A6> + <cl:HNO>123</cl:HNO> + <cl:LOC>Suite 75</cl:LOC> + <cl:PC>10027-0401</cl:PC> + </cl:civicAddress> + </gp:location-info> + <gp:usage-rules> + <gp:retransmission-allowed>yes</gp:retransmission-allowed> + <gp:retention-expiry>2003-06-23T04:57:29Z</gp:retention-expiry> + </gp:usage-rules> + </gp:geopriv> + </status> + <timestamp>2003-06-22T20:57:29Z</timestamp> + </tuple> + </presence> + +3. Carrying PIDF in a Using Protocol + + A PIDF document is an XML document; therefore, PIDF might be carried + in any protocol capable of carrying XML. A MIME type has also been + registered for PIDF: 'application/pidf+xml'. PIDF may therefore be + carried as a MIME body in protocols that use MIME (such as SMTP, + HTTP, or SIP) with an encapsulating set of MIME headers, including a + Content-Type of 'application/pidf+xml'. + + Further specification of the behavior of using protocols (including + subscribing to or requesting presence information) is outside the + scope of this document. + +4. Securing PIDF + + There are a number of ways in which XML documents can be secured. + XML itself supports several ways of partially securing documents, + including element-level encryption and digital signature properties. + + For the purposes of this document, only the securing of a PIDF + document as a whole, rather than element-by-element security, is + considered. None of the requirements [10] suggest that only part of + the information in a location object might need to be protected while + other parts are unprotected; virtually any such configuration would + introduce potentials for privacy leakage. Consequently, the use of + MIME-level security is appropriate. + + + + + +Peterson Standards Track [Page 15] + +RFC 4119 GEOPRIV Location Object December 2005 + + + S/MIME [5] allows security properties (including confidentiality, + integrity, and authentication properties) to be applied to the + contents of a MIME body. Therefore, all PIDF implementations that + support the XML Schema extensions for location information described + in this document MUST support S/MIME; in particular, they MUST + support the CMS [6] EnvelopedData and SignedData content types, which + are used for encryption and digital signatures, respectively. It is + believed that this mechanism meets REQs 2.10, 13, 14.1, 14.2, 14.3, + and 14.4. + + Additionally, all compliant applications MUST implement the AES + encryption algorithm for S/MIME, as specified in [8] (and per REQ + 15.1). Of course, implementations MUST also support the baseline + encryption and digital signature algorithms described in the S/MIME + specification. + + S/MIME generally entails the use of X.509 [9] certificates. In order + to encrypt a request for a particular destination end-to-end (i.e., + to a Location Recipient), the Location Generator must possess + credentials (typically an X.509 certificate) that have been issued to + the Location Recipient. Implementations of this specification SHOULD + support X.509 certificates for S/MIME, and MUST support password- + based CMS encryption (see [6]). Any symmetric keying systems SHOULD + derive high-entropy content encoding keys (CEKs). When X.509 + certificates are used to sign PIDF Location Objects, the + subjectAltName of the certificate SHOULD use the "pres" URI scheme. + + One envisioned deployment model for S/MIME in PIDF documents is the + following. Location Servers hold X.509 certificates and share + secrets with Location Generators and Location Recipients. When a + Generator sends location information to a Server, it can be encrypted + with S/MIME (or any lower-layer encryption specific to the using + protocol). When a Server forwards location information to a + Recipient, location information can be encrypted with password-based + CMS encryption. This allows the use of encryption when the Location + Recipient does not possess its own X.509 certificate. + + S/MIME was designed for end-to-end security between email peers that + communicate through multiple servers (i.e mail transfer agents) that + do not modify message bodies. There is, however, at least one + instance in which Location Servers modify Location Objects: when + Location Servers enforce policies on behalf of the Rule Maker. For + example, a Rule Maker may specify that Location Information should be + coarsened (made less specific) before it is transmitted to particular + recipients. If the Location Server were unable to modify a Location + Object, because it was encrypted, signed, or both, it would be unable + to accomplish this function. Consequently, when a Location Generator + wants to allow a Location Server to modify such messages, they MAY + + + +Peterson Standards Track [Page 16] + +RFC 4119 GEOPRIV Location Object December 2005 + + + encrypt such messages with a key that can be decrypted by the + Location Server (the digital signature, of course, can still be + created with keying material from the Location Generator's + certificate). After modifying the Location Object, the Location + + Server can re-sign the Object with its own credentials (encrypting it + with any keys issued to the Location Recipient, if they are known to + the Server). + + Note that policies for data collection and usage of location + information, in so far as they are carried within a location object, + are discussed in Section 2.2.2. + +5. Security Considerations + + The threats facing an Internet protocol that carries geolocation + information are detailed in [16]. The requirements that were + identified in that analysis of the threat model were incorporated + into [10], in particular within Section 7.4. This document aims to + be compliant with the security requirements derived from those two + undertakings, in so far as they apply to the location object itself + (as opposed to the using protocol). + + Security of the location object defined in this document, including + normative requirements for implementations, is discussed in Section + 4. This security focuses on end-to-end integrity and confidentiality + properties that are applied to a location object for its lifetime via + S/MIME. + + Security requirements associated with using protocols (including + authentication of subscribers to geographical information, etc.) are + outside the scope of this document. + +6. IANA Considerations + +6.1. 'method' Tokens + + This document requests that the IANA create a new registry for + 'method' tokens associated with the PIDF-LO object. 'method' tokens + are text strings designating the manner in which location information + in a PIDF-LO object has been derived or discovered. Any party may + register new 'method' tokens with the IANA, as needed, on a first- + come-first-serve basis. + + This section pre-registers 7 new 'method' tokens associated with the + 'method' element described above in Section 2.2.3: + + + + + +Peterson Standards Track [Page 17] + +RFC 4119 GEOPRIV Location Object December 2005 + + + GPS: Global Positioning System + A-GPS: GPS with assistance + Manual: entered manually by an operator or user, e.g., based on + subscriber billing or service location information + DHCP: provided by DHCP (used for wireline access networks, see + 802.11 below) + Triangulation: triangulated from time-of-arrival, signal strength, + or similar measurements + Cell: location of the cellular radio antenna + 802.11: 802.11 access point (used for DHCP-based provisioning over + wireless access networks) + +6.2. 'provided-by' Elements + + This document requests that IANA create a new registry of XML + namespaces for 'provided-by' elements for use with PIDF-LO objects. + Registrations of new XML namespaces that are used for 'provided-by' + MUST be reviewed by an Expert Reviewer designated by the IESG. + + This document pre-registers a single XML namespace for 'provided-by', + which is given in Appendix A. + +6.3. URN Sub-Namespace Registration for + urn:ietf:params:xml:ns:pidf:geopriv10 + + This section registers a new XML namespace, as per the guidelines in + [4]. + + URI: The URI for this namespace is + urn:ietf:params:xml:ns:pidf:geopriv10. + Registrant Contact: IETF, GEOPRIV working group, + (geopriv@ietf.org), Jon Peterson (jon.peterson@neustar.biz). + XML: + + BEGIN + <?xml version="1.0"?> + <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" + "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> + <html xmlns="http://www.w3.org/1999/xhtml"> + <head> + <meta http-equiv="content-type" + content="text/html;charset=iso-8859-1"/> + <title>GEOPRIV PIDF Extensions</title> + </head> + <body> + <h1>PIDF Extensions of Geographical Information and Privacy</h1> + <h2>urn:ietf:params:xml:ns:pidf:geopriv10</h2> + <p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc4119.txt"> + + + +Peterson Standards Track [Page 18] + +RFC 4119 GEOPRIV Location Object December 2005 + + + RFC4119</a>.</p> + </body> + </html> + END + +7. Acknowledgements + + This document was produced with the assistance of many members of the + GEOPRIV IETF working group. Special thanks to Carl Reed of OpenGIS + for a close read of the document. + + The civic location format described in this document was proposed by + Henning Schulzrinne for communicating location information in DHCP, + and has been appropriated in its entirety for this document. + + James M. Polk provided the text related to the 'method' element, and + much of the text for the 'provided-by' element. The text of Appendix + A was written by Nadine Abbott. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Peterson Standards Track [Page 19] + +RFC 4119 GEOPRIV Location Object December 2005 + + +A. Appendix: NENA Provided-By Schema + + The following registers the XML namespace + urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider and the associated + schema below, for usage within the 'provided-by' element of PIDF-LO. + The dataProvider namespace was developed by the US National Emergency + Number Administration (NENA) for next-generation emergency + communications needs. + + This appendix is non-normative for implementers of PIDF-LO + implementations and MAY support the dataProvider namespace. Other + registrants of 'provided-by' namespaces are invited to use the + registration below as an informative example. + + URI: The URI for this namespace is + urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider + Registrant Contact: NENA, VoIP working group & IETF, GEOPRIV + working group, (geopriv@ietf.org), Nadine Abbott + (nabbott@telcordia.com). + XML: + + BEGIN + <?xml version="1.0"?> + <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" + "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> + <html xmlns="http://www.w3.org/1999/xhtml"> + <head> + <meta http-equiv="content-type" + content="text/html;charset=iso-8859-1"/> + <title>NENA dataProvider Schema for PIDF-LO</title> + </head> + <body> + <h1>NENA dataProvider Schema for 'provided-by' in PIDF-LO</h1> + <h2>urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider</h2> + <p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc4119.txt"> + RFC4119</a>.</p> + </body> + </html> + END + + + + + + + + + + + + +Peterson Standards Track [Page 20] + +RFC 4119 GEOPRIV Location Object December 2005 + + +A.1. dataProvider XML Schema + +<?xml version="1.0" encoding="UTF-8"?> +<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com) by +Patricia Bluhm (HBF Group) --> +<xs:schema +targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider" +xmlns:tns="urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider" +xmlns:xs="http://www.w3.org/2001/XMLSchema" +elementFormDefault="qualified" attributeFormDefault="unqualified"> + <xs:element name="nena" type="tns:DataProviderIDType"/> + <xs:complexType name="DataProviderIDType"> + <xs:annotation> + <xs:documentation>NENA registered Company ID +for Service Provider supplying location information</xs:documentation> + </xs:annotation> + <xs:all> + <xs:element name="DataProviderID" +type="tns:NENACompanyIDType" minOccurs="0"/> + <xs:element name="TelURI" +type="tns:TelURI_24x7Type" minOccurs="0"/> + <xs:element name="URL" type="xs:anyURI" +minOccurs="0"/> + </xs:all> + </xs:complexType> + <xs:simpleType name="NENACompanyIDType"> + <xs:annotation> + <xs:documentation>NENA registered Company +ID.</xs:documentation> + </xs:annotation> + <xs:restriction base="xs:string"> + <xs:maxLength value="5"/> + </xs:restriction> + </xs:simpleType> + <xs:simpleType name="TelURI_24x7Type"> + <xs:annotation> + <xs:documentation>24x7 Tel URI for the +caller's [location data] service provider. To be used for contacting +service provider to resolve problems with location data. Possible +values TN number, enumerated values when not +available.</xs:documentation> + </xs:annotation> + <xs:union memberTypes="xs:anyURI"> + <xs:simpleType> + + <xs:restriction base="xs:string"> + <xs:maxLength value="10"/> + <xs:enumeration value="NOT FOUND"/> + + + +Peterson Standards Track [Page 21] + +RFC 4119 GEOPRIV Location Object December 2005 + + + <xs:enumeration value="UNAVAILABLE"/> + </xs:restriction> + </xs:simpleType> + </xs:union> + </xs:simpleType> +</xs:schema> + +Normative References + + [1] Bradner, S., "Key words for use in RFCs to indicate requirement + levels", BCP 14, RFC 2119, March 1997. + + [2] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and + J. Peterson, "Presence Information Data Format (PIDF)", RFC + 3863, August 2004. + + [3] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, + October 2003. + + [4] Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81, January + 2004. + + [5] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions + (S/MIME) Version 3.1 Message Specification", RFC 3851, July + 2004. + + [6] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, + July 2004. + + [7] Levinson, E., "Content-ID and Message-ID Uniform Resource + Locators", RFC 2392, August 1998. + + [8] Schaad, J., "Use of the Advanced Encryption Standard (AES) + Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC + 3565, July 2003. + + [9] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions + (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004. + +Informative References + + [10] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. + Polk, "Geopriv Requirements", RFC 3693, February 2004. + + [11] Morris, J., Mulligan, D., and J. Cuellar, "Core Privacy + Protections for Geopriv Location Object", Work in Progress, + June 2003. + + + + +Peterson Standards Track [Page 22] + +RFC 4119 GEOPRIV Location Object December 2005 + + + [12] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence + and Instant Messaging", RFC 2778, February 2000. + + [13] Peterson, J., "A Presence Architecture for the Distribution of + Geopriv Location Objects", Work in Progress, February 20003. + + [14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., + Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: + Session Initiation Protocol", RFC 3261, May 2002. + + [15] OpenGIS, "Open Geography Markup Language (GML) Implementation + Specification", OGC 02-023r4, January 2003, + <http://www.opengeospatial.org/specs/?page=specs>. + + [16] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat + Analysis of the Geopriv Protocol", RFC 3694, February 2004. + +Author's Address + + Jon Peterson + NeuStar, Inc. + 1800 Sutter St + Suite 570 + Concord, CA 94520 + US + + Phone: +1 925/363-8720 + EMail: jon.peterson@neustar.biz + URI: http://www.neustar.biz/ + + + + + + + + + + + + + + + + + + + + + + +Peterson Standards Track [Page 23] + +RFC 4119 GEOPRIV Location Object December 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Peterson Standards Track [Page 24] + |