idnits 2.17.1 draft-ietf-geopriv-pidf-lo-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1047. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1024. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1031. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1037. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1053), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 69 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** There are 32 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 9, 2004) is 7140 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 831, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 877, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3851 (ref. '5') (Obsoleted by RFC 5751) ** Obsolete normative reference: RFC 3852 (ref. '6') (Obsoleted by RFC 5652) ** Obsolete normative reference: RFC 3211 (ref. '9') (Obsoleted by RFC 3369, RFC 3370) == Outdated reference: A later version (-04) exists of draft-ietf-geopriv-reqs-03 -- Obsolete informational reference (is this intentional?): RFC 2396 (ref. '14') (Obsoleted by RFC 3986) -- No information found for draft-ietf-geopriv-threats - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 3850 (ref. '18') (Obsoleted by RFC 5750) Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 GEOPRIV WG J. Peterson 2 Internet-Draft NeuStar 3 Expires: March 10, 2005 September 9, 2004 5 A Presence-based GEOPRIV Location Object Format 6 draft-ietf-geopriv-pidf-lo-03 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on March 10, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This document describes an object format for carrying geographical 40 information on the Internet. This location object extends the 41 Presence Information Data Format (PIDF), which was designed for 42 communicating privacy-sensitive presence information and which has 43 similar properties. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Location Object Format . . . . . . . . . . . . . . . . . . . . 4 49 2.1 Baseline PIDF Usage . . . . . . . . . . . . . . . . . . . 4 50 2.2 Extensions to PIDF for Location and Usage Rules . . . . . 5 51 2.2.1 'location-info' element . . . . . . . . . . . . . . . 5 52 2.2.2 'usage-rules' element . . . . . . . . . . . . . . . . 7 53 2.2.3 'method' element . . . . . . . . . . . . . . . . . . . 9 54 2.2.4 'provided-by' element . . . . . . . . . . . . . . . . 9 55 2.2.5 Schema definitions . . . . . . . . . . . . . . . . . . 10 56 2.3 Example Location Objects . . . . . . . . . . . . . . . . . 13 57 3. Carrying PIDF in a Using Protocol . . . . . . . . . . . . . . 15 58 4. Securing PIDF . . . . . . . . . . . . . . . . . . . . . . . . 15 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 61 6.1 'method' tokens . . . . . . . . . . . . . . . . . . . . . 17 62 6.2 'provided-by' elements . . . . . . . . . . . . . . . . . . 18 63 6.3 URN Sub-Namespace Registration for 64 urn:ietf:params:xml:ns:pidf:geopriv10 . . . . . . . . . . 18 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21 66 A. NENA Provided-By Schema . . . . . . . . . . . . . . . . . . . 21 67 A.1 dataProvider XML Schema . . . . . . . . . . . . . . . . . 22 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 69 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 19 70 7.2 Informative References . . . . . . . . . . . . . . . . . . . 20 71 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 72 Intellectual Property and Copyright Statements . . . . . . . . 24 74 1. Introduction 76 Geographical location information describes a physical position in 77 the world that may correspond to the past, present or future location 78 of a person, event or device. Numerous applications used in the 79 Internet today benefit from sharing location information (including 80 mapping/navigation applications, 'friend finders' on cell phones, and 81 so on). However, such applications may disclose the whereabouts of a 82 person in a manner contrary to the user's preferences. Privacy 83 lapses may result from poor protocol security (which permits 84 eavesdroppers to capture location information), inability to 85 articulate or accommodate user preferences, or similar defects common 86 in existing systems. The privacy concerns surrounding the unwanted 87 disclosure of a person's physical location are among the more serious 88 that confront users on the Internet. 90 Consequently, a need has been identified to convey geographical 91 location information within an object that includes a user's privacy 92 and disclosure preferences and which is protected by strong 93 cryptographic security. Previous work [13] has observed that this 94 problem bears some resemblance to the general problem of 95 communicating and securing presence information on the Internet. 96 Presence (which is defined in [12]) provides a real-time 97 communications disposition for a user, and thus has similar 98 requirements for selective distribution and security. 100 Therefore, this document extends the XML-based Presence Information 101 Data Format (PIDF [2]) to allow the encapsulation of location 102 information within a presence document. 104 This document does not invent any format for location information 105 itself. Numerous existing formats based on civil location, 106 geographic coordinates, and the like have been developed in other 107 standards fora. Instead, this document defines an object that is 108 suitable for both identifying and encapsulating pre-existing location 109 information formats, and for providing adequate security and policy 110 controls to regulate the distribution of location information over 111 the Internet. 113 The location object described in this document can be used 114 independently of any 'using protocol', as the term is defined in the 115 GEOPRIV requirements [10]. It is considered an advantage of this 116 proposal that existing presence protocols (such as [15]) would 117 natively accommodate the location object format defined in this 118 document, and be capable of composing location information with other 119 presence information, since this location object is an extension of 120 PIDF. However, the usage of this location object format is not 121 limited to presence using protocols - any protocol that can carry XML 122 or MIME types can carry PIDF. 124 Some of the requirements in [10] and [11] concern data collection and 125 usage policies associated with location objects. This document 126 provides only the minimum markup necessary for a user to express the 127 necessary privacy preferences as specified by the GEOPRIV 128 requirements (the three basic elements in [11]). However, this 129 document does not demonstrate how a full XML-based ruleset 130 accommodating the needs of Location Servers could be embedded in PIDF 131 - it is assumed that other protocols (such as HTTP) will be used to 132 move rules between Rule Holders and Location Servers, and that full 133 rulesets will be defined in a separate document. 135 2. Location Object Format 137 2.1 Baseline PIDF Usage 139 The GEOPRIV requirements [10] (or REQ for short) specify the need for 140 a name for the person, place or thing that location information 141 describes (REQ 2.1). PIDF has such an identifier already, since 142 every PIDF document has an "entity" attribute of the 'presence' 143 element that signifies the URI of the entity whose presence the 144 document describes. Consequently, if location information is 145 contained in a PIDF document, the URI in the "entity" attribute of 146 the 'presence' element indicates the target of that location 147 information (the 'presentity'). The URI in the "entity" attribute 148 generally uses the "pres" URI scheme defined in [3]. Such URIs can 149 serve as unlinkable pseudonyms (per REQ 12). 151 PIDF optionally contains a 'contact' element that provides a URI 152 where the presentity can be reached by some means of communication 153 (usually, the URI scheme in the value of the 'contact' element gives 154 some sense of how the presentity can be reached: if it uses the SIP 155 URI scheme, for example, SIP can be used, and so on). Location 156 information can be provided without any associated means of 157 communication - thus, the 'contact' element may or may not be 158 present, as desired by the creator of the PIDF document. 160 PIDF optionally contains a 'timestamp' element that designates the 161 time at which the PIDF document was created. This element 162 corresponds to REQ 2.7a. 164 PIDF contains a 'status' element, which is mandatory. 'status' 165 contains an optional child element 'basic' that describes the 166 presentity's communications disposition (in very broad terms: either 167 OPEN or CLOSED). For the purposes of this document, it is not 168 necessary for 'basic' status to be included. If, however, 169 communications disposition is included in a PIDF document above and 170 beyond geolocation, then 'basic' status may appear in a PIDF document 171 that uses these extensions. 173 PIDF also contains a 'tuple' umbrella element, which holds an "id" 174 element used to uniquely identify a segment of presence information 175 so that changes to this information can be tracked over time (as 176 multiple notifications of presence are received). 'timestamp', 177 'status', and 'contact' are composed under 'tuple'. 179 2.2 Extensions to PIDF for Location and Usage Rules 181 This XML Schema extends the 'status' element of PIDF with a complex 182 element called 'geopriv'. There are two major subelements that are 183 encapsulated within geopriv: one for location information, and one 184 for usage rules. Both of these subelements are mandatory, and are 185 described in subsequent sections. By composing these two subelements 186 under 'geopriv', the usage rules are clearly and explicitly 187 associated with the location information. 189 For extensibility (see REQ 1.4), the schema allows any other 190 subelements to appear under the 'geopriv' element. Two other 191 optional subelements are included in this document: one that 192 indicates the method by which geographical location was determined, 193 and one that allows an explicit designation of the entity that 194 provided the information. 196 2.2.1 'location-info' element 198 Each 'geopriv' element MUST contain one 'location-info' element. A 199 'location-info' element consists of one or more chunks of location 200 information (per REQ 2.5). The format of the location information 201 (REQ 2.6) is identified by the imported XML Schema describing the 202 namespace in question. All PIDF documents that contain a 'geopriv' 203 element MUST contain one or more import directives indicating the XML 204 Schema(s) that are used for geographic location formats. 206 In order to ensure interoperability of GEOPRIV implementations, it is 207 necessary to select a baseline location format that all compliant 208 implementations support (see REQ 3.1). Since it satisfies REQ 2.5.1, 209 this document works from the assumption that GML 3.0 [16] shall be 210 this mandatory format (a MUST implement for all PIDF implementations 211 supporting the 'geopriv' element). 213 The Geography Markup Language (GML) is an extraordinarily thorough 214 and versatile system for modeling all manner of geographic object 215 types, topologies, metadata, coordinate reference systems and units 216 of measurement. The simplest package for GML supporting location 217 information is the 'feature.xsd' schema. Although 'feature.xsd' can 218 express complicated geographical concepts, it requires very little 219 markup to provide basic coordinates points for the most common use 220 cases. Various format descriptions (including latitude/longitude 221 based location information) are supported by Feature (see section 222 7.4.1.4 of [16] for examples), which resides here: 224 urn:opengis:specification:gml:schema-xsd:feature:v3.0 226 Note that by importing the Feature schema, necessary GML baseline 227 schemas are transitively imported. 229 Complex features (such as modeling topologies and polygons, 230 directions and vectors, temporal indications of the time for which a 231 particular location is valid for a target) are also available in GML, 232 but require importing additional schemas. For the purposes of 233 baseline interoperability as defined by this document, only support 234 for the 'feature.xsd' GML schema is REQUIRED. 236 Implementations MAY support the civil location format (civilLoc) 237 defined in Section 2.2.5. civilLoc provides the following elements: 239 +----------------------+----------------------+---------------------+ 240 | Label | Description | Example | 241 +----------------------+----------------------+---------------------+ 242 | country | The country is | US | 243 | | identified by the | | 244 | | two-letter ISO 3166 | | 245 | | code. | | 246 | | | | 247 | A1 | national | New York | 248 | | subdivisions (state, | | 249 | | region, province, | | 250 | | prefecture) | | 251 | | | | 252 | A2 | county, parish, gun | King's County | 253 | | (JP), district (IN) | | 254 | | | | 255 | A3 | city, township, shi | New York | 256 | | (JP) | | 257 | | | | 258 | A4 | city division, | Manhattan | 259 | | borough, city | | 260 | | district, ward, chou | | 261 | | (JP) | | 262 | | | | 263 | A5 | neighborhood, block | Morningside Heights | 264 | | | | 265 | A6 | street | Broadway | 266 | | | | 267 | PRD | Leading street | N, W | 268 | | direction | | 269 | | | | 270 | POD | Trailing street | SW | 271 | | suffix | | 272 | | | | 273 | STS | Street suffix | Avenue, Platz, | 274 | | | Street | 275 | | | | 276 | HNO | House number, | 123 | 277 | | numeric part only. | | 278 | | | | 279 | HNS | House number suffix | A, 1/2 | 280 | | | | 281 | LMK | Landmark or vanity | Low Library | 282 | | address | | 283 | | | | 284 | LOC | Additional location | Room 543 | 285 | | information | | 286 | | | | 287 | FLR | Floor | 5 | 288 | | | | 289 | NAM | Name (residence, | Joe's Barbershop | 290 | | business or office | | 291 | | occupant) | | 292 | | | | 293 | PC | Postal code | 10027-0401 | 294 +----------------------+----------------------+---------------------+ 296 Either the GML 3.0 geographical information format element, or the 297 location format element ('civilLoc') defined in this document, MAY 298 appear in in a 'location-info' element. Both MAY also be used in the 299 same 'location-info' element. In summary, the feature.xsd schema of 300 GML 3.0 MUST be supported by implementations compliant with this 301 specification, and the civilLoc format MAY be supported by 302 implementations compliant with this specification. 304 2.2.2 'usage-rules' element 306 At the time this document was written, the policy requirements for 307 GEOPRIV objects were not definitively completed. However, the 308 'usage-rules' element exists to satisfy REQ 2.8, and the requirements 309 of the GEOPRIV policy requirements [11] document. Each 'geopriv' 310 element MUST contain one 'usage-rules' element, even if the Rule 311 Maker has requested that all subelements be given their default 312 values. 314 Following the policy requirements document (Section 3.1), there are 315 three fields that need to be expressible in Location Objects 316 throughout their lifecycle (from Generator to Recipient): one field 317 that limits retransmission, one that limits retention, and one that 318 contains a reference to external rulesets. Those three fields are 319 instantiated here by the first three elements. The fourth element 320 provides a generic space for human-readable policy directives. Any 321 of these fields MAY be present in a Location Object 'usage-rules' 322 element; none are required to be. 323 'retransmission-allowed': When the value of this element is 'no', 324 the Recipient of this Location Object is not permitted to share 325 the enclosed Location Information, or the object as a whole, with 326 other parties. When the value of this element is 'yes', 327 distributing this Location is permitted (barring an existing 328 out-of-band agreement or obligation to the contrary). By default, 329 the value MUST be assumed to be 'no'. Implementations MUST 330 include this field, with a value of 'no', if the Rule Maker 331 specifies no preference. 332 'retention-expires': This field specifies an absolute date at 333 which time the Recipient is no longer permitted to possess the 334 location information and its encapsulating Location Object - both 335 may be retained only up until the time specified by this field. 336 By default, the value MUST be assumed to be twenty-four hours from 337 the 'timestamp' element in the PIDF document, if present; if the 338 'timestamp' element is also not present, then twenty-four hours 339 from the time at which the Location Object is received by the 340 Location Recipient. If the value in the 'retention-expires' 341 element has already passed when the Location Recipient receives 342 the Location Object, the Recipient MUST discard the Location 343 Object immediately. 344 'ruleset-reference': This field contains a URI that indicates 345 where a fuller ruleset of policies related to this object can be 346 found. This URI SHOULD use the HTTPS URI scheme, and if it does, 347 the server that holds these rules MUST authenticate any attempt to 348 access these rules - usage rules themselves may divulge private 349 information about a Target or Rule Maker. The URI MAY 350 alternatively use the CID URI scheme [7], in which case it MUST 351 denote a MIME body carried with the Location Object by the using 352 protocol. Rulesets carried as MIME bodies SHOULD be encrypted and 353 signed by the Rule Maker; unsigned rulesets SHOULD NOT be honored 354 by Location Servers or Location Recipients. Note that in order to 355 avoid network lookups that result in an authorization failure, 356 creators of Location Objects MAY put HTTPS-based 357 ruleset-references into an encrypted external MIME body referenced 358 by a CID; in this way, recipients of the Location Object that are 359 unable to decrypt the external MIME body will not learn the HTTPS 360 URI unless they are able to decrypt the MIME body. 361 'note-well': This field contains a block of text containing 362 further generic privacy directives. These directives are intended 363 to be human-readable only, not to be processed by any automaton. 365 2.2.3 'method' element 367 The optional 'method' element describes the way that the location 368 information was derived or discovered. An example of this element 369 (for a geographical position system) is: 371 gps 373 The possible values of the 'method' element are enumerated within an 374 IANA registry. Implementations MUST limit the use of this method to 375 the values shepherded by IANA. This document prepopulates the IANA 376 registry with seven possible values; see Section 6.1 for more 377 information. 379 The 'method' element is useful, for example, when multiple sources 380 are reporting location information for a given user, and some means 381 of determining location might be considered more authoritative than 382 others (i.e. a dynamic, real-time position system versus static 383 provisioning associated with a target device). However, note that 384 inclusion of 'method' might reveal sensitive information when the 385 generator is providing intentionally coarsened location information. 386 For example, when a LO is transmitted with 'DHCP' as the 'method', 387 but the location information indicates only the city in which the 388 generator is located, the sender has good justification to suspect 389 that some location information is being withheld. 391 2.2.4 'provided-by' element 393 The optional 'provided-by' element describes the entity or 394 organization that supplied this location information (beyond the 395 domain information that can be inferred from a signing certificate). 396 An example of this element (for a made-up game system) might be: 398 399 400 West5 401 402 404 Values for the 'provided-by' element MUST be IANA-registered XML 405 namespaces; see Section 6.2 for more information. 407 The 'provided-by' element is not intended for use by most entities, 408 but rather to meet special requirements for which overhead (IANA 409 registration, location object size) and potential location 410 information leakage are acceptable choices. 412 In general cases, the entity that supplied location information is 413 communicated by the subjectAltName of the certificate with which the 414 location object is signed, and thus this element is unnecessary. 415 'Provided-by' is meaningful in particular cases when the creator of a 416 location object wants to designate a particular system or party 417 within a complex administrative domain, including situations 418 envisioned for providing emergency services in a diverse national 419 context. It might assist, for example, the recipient of a malformed 420 or misleading location object in identifying the particular system 421 that malfunctioned. 423 Users should be aware that this information can inadvertently provide 424 additional information to the receiver, increasing the effective 425 resolution of the geospatial or civil information, or even revealing 426 some location information, when it was meant to be entirely 427 protected. Consider if there were circumstances that influenced 428 Columbia University to elect to register and use the provided-by 429 element. If an example LO includes only state-level information, 430 then including the fact that the location information was provided by 431 Columbia University provides a strong indication that the Target is 432 actually located in a four-block area in Manhattan. Accordingly, 433 this element should be used only when organizational functions 434 strongly would depend on it - in all but such usages, the 435 subjectAltName of the certificate suffices, and 'provided-by' SHOULD 436 NOT be used. 438 2.2.5 Schema definitions 440 Note that the XML namespace [4] for this extension to PIDF contains a 441 version number 1.0 (as per REQ 2.10). 443 444 451 452 453 454 456 458 460 462 464 465 467 468 469 471 472 474 475 476 477 478 479 480 482 483 484 486 487 489 491 The 'geopriv10' schema imports, for the 'usage-rules' element, the 492 following policy schema. This schema has been broken out from the 493 basic geolocation object in order to allow for its reuse. The 494 semantics associated with these elements described in Section 2.2.2 495 apply only to the use of these elements to define policy for 496 geolocation objects; any other use of 'usage-rules' must characterize 497 its own semantics for all 'usage-rules' subelements. 499 500 506 507 510 511 512 514 516 518 520 522 523 525 526 527 528 529 530 531 533 535 The following schema is a trivial representation of civil location 536 that MAY be implemented by entities compliant with this 537 specification. 539 540 545 546 547 549 551 553 555 557 559 561 563 565 567 569 571 573 575 577 579 581 583 584 586 588 2.3 Example Location Objects 590 Note that these examples show PIDF documents without any MIME headers 591 or security applied to them (see Section 4 below). 593 The following XML instance document is an example of the use of a 594 simple GML 3.0 markup with a few of the policy directives specified 595 above within a PIDF document. The GPS coordinates given in the 'gml' 596 element are for San Francisco, CA. 598 599 603 604 605 606 607 608 609 37:46:30N 122:25:10W 610 611 612 613 614 no 615 2003-06-23T04:57:29Z 616 617 618 619 2003-06-22T20:57:29Z 620 621 623 The following XML instance document is an example of the use of the 624 civilLoc object with a few of the policy directives specified above 625 within a PIDF document. 627 628 632 633 634 635 636 637 US 638 New York 639 New York 640 Broadway 641 123 642 Suite 75 643 10027-0401 644 645 646 647 yes 648 2003-06-23T04:57:29Z 649 650 651 652 2003-06-22T20:57:29Z 653 654 656 3. Carrying PIDF in a Using Protocol 658 A PIDF document is an XML document, and therefore PIDF might be 659 carried in any protocol that is capable of carrying XML. A MIME type 660 has also been registered for PIDF: 'application/cpim-pidf+xml'. PIDF 661 may therefore be carried as a MIME body in protocols that use MIME 662 (such as SMTP, HTTP, or SIP) with an encapsulating set of MIME 663 headers, including a Content-Type of 'application/cpim-pidf+xml". 665 Further specification of the behavior of using protocols (including 666 subscribing to or requesting presence information) is outside the 667 scope of this document. 669 4. Securing PIDF 671 There are a number of ways in which XML documents can be secured. 672 XML itself supports several ways of partially securing documents, 673 including element-level encryption and digital signature properties. 675 For the purposes of this document, only the securing of a PIDF 676 document as a whole, rather than element-by-element security, is 677 considered. None of the requirements [10] suggest that only part of 678 the information in a location object might need to be protected while 679 other parts are unprotected - virtually any such configuration would 680 introduce potentials for privacy leakage. Consequently, the use of 681 MIME-level security is appropriate. 683 S/MIME [5] allows security properties (including confidentiality, 684 integrity and authentication properties) to be applied to the 685 contents of a MIME body. Therefore, all PIDF implementations that 686 support the XML Schema extensions for location information described 687 in this document MUST support S/MIME, and in particular must support 688 the CMS [6] EnvelopedData and SignedData content types, which are 689 used for encryption and digital signatures respectively. It is 690 believed that this mechanism meets REQs 2.10, 13, 14.1, 14.2, 14.3, 691 14.4. 693 Additionally, all compliant applications MUST implement the AES 694 encryption algorithm for S/MIME, as specified in [8] (and per REQ 695 15.1). Of course, implementations MUST also support the baseline 696 encryption and digital signature algorithms described in the S/MIME 697 specification. 699 S/MIME generally entails the use of X.509 [18] certificates. In 700 order to encrypt a request for a particular destination end-to-end 701 (i.e. to a Location Recipient), the Location Generator must possess 702 credentials (typically an X.509 certificate) that have been issued to 703 the Location Recipient. Implementations of this specification SHOULD 704 support X.509 certificates for S/MIME, and MUST support 705 password-based CMS encryption (see [9]). Any symmetric keying 706 systems SHOULD derive high-entropy content encoding keys (CEKs). 707 When X.509 certificates are used to sign PIDF Location Objects, the 708 subjectAltName of the certificate SHOULD use the "pres" URI scheme. 710 One envisioned deployment model for S/MIME in PIDF documents is the 711 following. Location Servers hold X.509 certificates and share 712 secrets with Location Generators and Location Recipients. When a 713 Generator sends location information to a Server, it can be encrypted 714 with S/MIME (or any lower-layer encryption specific to the using 715 protocol). When a Server forwards location information to a 716 Recipient, location information can be encrypted with password-based 717 CMS encryption. This allows the use of encryption when the Location 718 Recipient does not possess its own X.509 certificate. 720 S/MIME was designed for end-to-end security between email peers that 721 communicate through multiple servers (i.e mail transfer agents) that 722 do not modify message bodies. There is, however, at least one 723 instance in which Location Servers modify Location Objects - namely 724 when Location Servers enforce policies on behalf of the Rule Maker. 725 For example, a Rule Maker may specify that Location Information 726 should be coarsened (made less specific) before it is transmitted to 727 particular recipients. If the Location Server were unable to modify 728 a Location Object, because it was encrypted, signed, or both, it 729 would be unable to accomplish this function. Consequently, when a 730 Location Generator wants to allow a Location Server to modify such 731 messages, they MAY encrypt such messages with a key that can be 732 decrypted by the Location Server (the digital signature, of course, 733 can still be created with keying material from the Location 734 Generator's certificate). After modifying the Location Object, the 735 Location Server can re-sign the Object with its own credentials 736 (encrypting it with any keys issued to the Location Recipient, if 737 they are known to the Server). 739 Note that policies for data collection and usage of location 740 information, in so far as they are carried within a location object, 741 are discussed in Section 2.2.2. 743 5. Security Considerations 745 The threats to which an Internet service carrying geolocation might 746 be subjected are detailed in [17]. The requirements that were 747 identified in that analysis of the threat model were incorporated 748 into [10], in particular within Section 7.4. This document aims to 749 be compliant with the security requirements derived from those two 750 undertakings in so far as they apply to the location object itself 751 (as opposed to the using protocol). 753 Security of the location object defined in this document, including 754 normative requirements for implementations, is discussed in Section 755 4. This security focuses on end-to-end integrity and confidentiality 756 properties that are applied to a location object for its lifetime via 757 S/MIME. 759 Security requirements associated with using protocols (including 760 authentication of subscribers to geographical information, and so on) 761 are outside the scope of this document. 763 6. IANA Considerations 765 6.1 'method' tokens 767 This document requests that the IANA create a new registry for 768 'method' tokens associated with the PIDF-LO object. 'method' tokens 769 are text strings designating the manner in which location information 770 in a PIDF-LO object has been derived or discovered. Any party may 771 register new 'method' tokens with the IANA as needed on a 772 first-come-first-serve basis. 774 This section pre-registers 7 new 'method' tokens associated with the 775 'method' element described above in Section 2.2.3: 776 GPS: Global Positioning System 777 A-GPS: GPS with assistance 778 Manual: entered manually by an operator or user, e.g., based on 779 subscriber billing or service location information 780 DHCP: provided by DHCP (used for wireline access networks, see 781 802.11 below) 782 Triangulation: triangulated from time-of-arrival, signal strength 783 or similar measurements 784 Cell: location of the cellular radio antenna 785 802.11: 802.11 access point (used for DHCP-based provisioning over 786 wireless access networks) 788 6.2 'provided-by' elements 790 This document requests that IANA create a new registry of XML 791 namespaces for 'provided-by' elements for use with PIDF-LO objects. 792 Registrations of new XML namespaces that are used for 'provided-by' 793 MUST be reviewed by an Expert Reviewer designated by the IESG. 795 This document pre-registers a single XML namespace for 'provided-by' 796 which is given in Appendix A. 798 6.3 URN Sub-Namespace Registration for 799 urn:ietf:params:xml:ns:pidf:geopriv10 801 This section registers a new XML namespace, as per the guidelines in 802 [4]. 803 URI: The URI for this namespace is 804 urn:ietf:params:xml:ns:pidf:geopriv10. 805 Registrant Contact: IETF, GEOPRIV working group, 806 (geopriv@ietf.org), Jon Peterson (jon.peterson@neustar.biz). 807 XML: 809 BEGIN 810 811 813 814 815 817 GEOPRIV PIDF Extensions 818 819 820

PIDF Extensions of Geographical Information and Privacy

821

urn:ietf:params:xml:ns:pidf:geopriv10

822

See RFCXXXX.

823 824 825 END 827 7. References 829 7.1 Normative References 831 [1] Bradner, S., "Key words for use in RFCs to indicate requirement 832 levels", RFC 2119, March 1997. 834 [2] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and 835 J. Peterson, "Presence Information Data Format (PIDF)", RFC 836 3863, August 2004. 838 [3] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, 839 October 2003. 841 [4] Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81, January 842 2004. 844 [5] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/ 845 MIME) Version 3.1 Message Specification", RFC 3851, July 2004. 847 [6] Housley, R., "Cryptographic Message Syntax", RFC RFC3852, July 848 2004. 850 [7] Levinson, E., "Content-ID and Message-ID Uniform Resource 851 Locators", RFC 2392, August 1998. 853 [8] Schaad, J., "Use of the Advanced Encryption Standard (AES) 854 Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 855 3565, July 2003. 857 [9] Gutmann, P., "Password-based Encryption for CMS", RFC 3211, 858 December 2001. 860 7.2 Informative References 862 [10] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. 863 Polk, "Geopriv requirements", draft-ietf-geopriv-reqs-03 (work 864 in progress), February 2003. 866 [11] Morris, J., Mulligan, D. and J. Cuellar, "Core Privacy 867 Protections for Geopriv Location Object", 868 draft-morris-geopriv-core-02 (work in progress), June 2003. 870 [12] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 871 Instant Messaging", RFC 2778, February 2000. 873 [13] Peterson, J., "A Presence Architecture for the Distribution of 874 Geopriv Location Objects", draft-peterson-geopriv-pres-00 (work 875 in progress), February 20003. 877 [14] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 878 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 879 1998. 881 [15] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 882 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 883 Session Initiation Protocol", RFC 3261, May 2002. 885 [16] OpenGIS, "Open Geography Markup Language (GML) Implementation 886 Specification", OGC 02-023r4, January 2003, 887 . 889 [17] Danley, M., Morris, J., Mulligan, D. and J. Peterson, "Threat 890 Analysis of the geopriv Protocol", 891 draft-ietf-geopriv-threats-00 (work in progress), February 892 2003. 894 [18] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/ 895 MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004. 897 Author's Address 899 Jon Peterson 900 NeuStar, Inc. 901 1800 Sutter St 902 Suite 570 903 Concord, CA 94520 904 US 906 Phone: +1 925/363-8720 907 EMail: jon.peterson@neustar.biz 908 URI: http://www.neustar.biz/ 910 Appendix A. NENA Provided-By Schema 912 The following registers the XML namespace 913 urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider and the associated 914 schema below, for usage within the 'provided-by' element of PIDF-LO. 915 The dataProvider namespace was developed by the US National Emergency 916 Number Administration (NENA) for next-generation emergency 917 communications needs. 919 This appendix in non-normative for implementers of PIDF-LO - 920 implementations MAY support the dataProvider namespace. Other 921 registrants of 'provided-by' namespaces are invited to use the 922 registration below as an informative example. 923 URI: The URI for this namespace is 924 urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider 925 Registrant Contact: NENA, VoIP working group & IETF, GEOPRIV 926 working group, (geopriv@ietf.org), Nadine Abbott 927 (nabbott@telcordia.com). 928 XML: 930 BEGIN 931 932 934 935 936 938 NENA dataProvider Schema for PIDF-LO 939 940 941

NENA dataProvider Schema for 'provided-by' in PIDF-LO

942

urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider

943

See RFCXXXX.

945 946 947 END 949 A.1 dataProvider XML Schema 951 952 954 959 960 961 NENA registered Company ID for 962 Service Provider supplying location information 963 964 965 967 969 971 972 973 974 975 NENA registered Company 976 ID. 977 978 979 980 981 982 983 984 24x7 Tel URI for the caller's 985 [location data] service provider. To be used for contacting service 986 provider to resolve problems with location data. Possible values TN number, 987 enumerated values when not available. 988 989 990 991 992 993 994 995 996 997 998 999 1001 Appendix B. Acknowledgments 1003 This document was produced with the assistance of many members of the 1004 GEOPRIV IETF working group. Special thanks to Carl Reed of OpenGIS 1005 for a close read of the document. 1007 The civil location format described in this document was proposed by 1008 Henning Schulzrinne for communicating location information in DHCP, 1009 and has been appropriated in its entirety for this document. 1011 James M. Polk provided the text related to the 'method' element, and 1012 much of the text for the 'provided-by' element. The text of Appendix 1013 A was written by Nadine Abbott. 1015 Intellectual Property Statement 1017 The IETF takes no position regarding the validity or scope of any 1018 Intellectual Property Rights or other rights that might be claimed to 1019 pertain to the implementation or use of the technology described in 1020 this document or the extent to which any license under such rights 1021 might or might not be available; nor does it represent that it has 1022 made any independent effort to identify any such rights. Information 1023 on the procedures with respect to rights in RFC documents can be 1024 found in BCP 78 and BCP 79. 1026 Copies of IPR disclosures made to the IETF Secretariat and any 1027 assurances of licenses to be made available, or the result of an 1028 attempt made to obtain a general license or permission for the use of 1029 such proprietary rights by implementers or users of this 1030 specification can be obtained from the IETF on-line IPR repository at 1031 http://www.ietf.org/ipr. 1033 The IETF invites any interested party to bring to its attention any 1034 copyrights, patents or patent applications, or other proprietary 1035 rights that may cover technology that may be required to implement 1036 this standard. Please address the information to the IETF at 1037 ietf-ipr@ietf.org. 1039 Disclaimer of Validity 1041 This document and the information contained herein are provided on an 1042 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1043 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1044 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1045 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1046 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1047 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1049 Copyright Statement 1051 Copyright (C) The Internet Society (2004). This document is subject 1052 to the rights, licenses and restrictions contained in BCP 78, and 1053 except as set forth therein, the authors retain all their rights. 1055 Acknowledgment 1057 Funding for the RFC Editor function is currently provided by the 1058 Internet Society.