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

PIDF Extensions of Geographical Information and Privacy

803

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

804

See RFCXXXX.

805 806 807 END 809 7. References 810 7.1 Normative References 812 [1] Bradner, S., "Key words for use in RFCs to indicate requirement 813 levels", RFC 2119, March 1997. 815 [2] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and 816 J. Peterson, "CPIM Presence Information Data Format", 817 draft-ietf-impp-cpim-pidf-07 (work in progress), August 2001. 819 [3] Peterson, J., "Common Profile for Presence (CPP)", 820 draft-ietf-impp-pres-04 (work in progress), October 2003. 822 [4] Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81, January 823 2004. 825 [5] Ramsdell, B., "S/MIME Version 3 Message Specification", 826 draft-ietf-smime-rfc2633bis-03 (work in progress), January 2003. 828 [6] Housley, R., "Cryptographic Message Syntax", RFC 3369, August 829 2002. 831 [7] Levinson, E., "Content-ID and Message-ID Uniform Resource 832 Locators", RFC 2392, August 1998. 834 [8] Schaad, J., "Use of the Advanced Encryption Standard (AES) 835 Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 836 3565, July 2003. 838 7.2 Informative References 840 [9] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. 841 Polk, "Geopriv requirements", draft-ietf-geopriv-reqs-03 (work 842 in progress), February 2003. 844 [10] Morris, J., Mulligan, D. and J. Cuellar, "Core Privacy 845 Protections for Geopriv Location Object", 846 draft-morris-geopriv-core-02 (work in progress), June 2003. 848 [11] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 849 Instant Messaging", RFC 2778, February 2000. 851 [12] Peterson, J., "A Presence Architecture for the Distribution of 852 Geopriv Location Objects", draft-peterson-geopriv-pres-00 (work 853 in progress), February 20003. 855 [13] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 856 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 857 1998. 859 [14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 860 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 861 Session Initiation Protocol", RFC 3261, May 2002. 863 [15] OpenGIS, "Open Geography Markup Language (GML) Implementation 864 Specification", OGC 02-023r4, January 2003, 865 . 867 [16] Danley, M., Morris, J., Mulligan, D. and J. Peterson, "Threat 868 Analysis of the geopriv Protocol", 869 draft-ietf-geopriv-threats-00 (work in progress), February 870 2003. 872 [17] ITU-T, "Recommendation X.509 - Open Systems Interconnection - 873 The Directory: Authentication", ITU-T X.509, June 1997, . 876 [18] Gutmann, P., "Password-based Encryption for CMS", RFC 3211, 877 December 2001. 879 Author's Address 881 Jon Peterson 882 NeuStar, Inc. 883 1800 Sutter St 884 Suite 570 885 Concord, CA 94520 886 US 888 Phone: +1 925/363-8720 889 EMail: jon.peterson@neustar.biz 890 URI: http://www.neustar.biz/ 892 Appendix A. Appendix: NENA Provided-By Schema 894 The following registers the XML namespace 895 urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider and the associated 896 schema below, for usage within the 'provided-by' element of PIDF-LO. 897 The dataProvider namespace was developed by the US National Emergency 898 Number Administration (NENA) for next-generation emergency 899 communications needs. 901 This appendix in non-normative for implementers of PIDF-LO - 902 implementations MAY support the dataProvider namespace. Other 903 registrants of 'provided-by' namespaces are invited to use the 904 registration below as an informative example. 906 URI: The URI for this namespace is 907 urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider 908 Registrant Contact: NENA, VoIP working group & IETF, GEOPRIV 909 working group, (geopriv@ietf.org), Nadine Abbott 910 (nabbott@telcordia.com). 911 XML: 913 BEGIN 914 915 917 918 919 921 NENA dataProvider Schema for PIDF-LO 922 923 924

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

925

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

926

See RFCXXXX.

927 928 929 END 931 A.1 dataProvider XML Schema 933 934 936 941 942 943 NENA registered Company ID for 944 Service Provider supplying location information 945 946 947 949 951 953 954 955 956 957 NENA registered Company 958 ID. 959 960 961 962 963 964 965 966 24x7 Tel URI for the caller's 967 [location data] service provider. To be used for contacting service 968 provider to resolve problems with location data. Possible values TN number, 969 enumerated values when not available. 970 971 972 973 974 975 976 977 978 979 980 981 983 Appendix B. Acknowledgments 985 This document was produced with the assistance of many members of the 986 GEOPRIV IETF working group. Special thanks to Carl Reed of OpenGIS 987 for a close read of the document. 989 The civil location format described in this document was proposed by 990 Henning Schulzrinne for communicating location information in DHCP, 991 and has been appropriated in its entirety for this document. 993 James Polk provided the text related to the 'method' element, and 994 much of the text for 996 Intellectual Property Statement 998 The IETF takes no position regarding the validity or scope of any 999 intellectual property or other rights that might be claimed to 1000 pertain to the implementation or use of the technology described in 1001 this document or the extent to which any license under such rights 1002 might or might not be available; neither does it represent that it 1003 has made any effort to identify any such rights. Information on the 1004 IETF's procedures with respect to rights in standards-track and 1005 standards-related documentation can be found in BCP-11. Copies of 1006 claims of rights made available for publication and any assurances of 1007 licenses to be made available, or the result of an attempt made to 1008 obtain a general license or permission for the use of such 1009 proprietary rights by implementors or users of this specification can 1010 be obtained from the IETF Secretariat. 1012 The IETF invites any interested party to bring to its attention any 1013 copyrights, patents or patent applications, or other proprietary 1014 rights which may cover technology that may be required to practice 1015 this standard. Please address the information to the IETF Executive 1016 Director. 1018 Full Copyright Statement 1020 Copyright (C) The Internet Society (2004). All Rights Reserved. 1022 This document and translations of it may be copied and furnished to 1023 others, and derivative works that comment on or otherwise explain it 1024 or assist in its implementation may be prepared, copied, published 1025 and distributed, in whole or in part, without restriction of any 1026 kind, provided that the above copyright notice and this paragraph are 1027 included on all such copies and derivative works. However, this 1028 document itself may not be modified in any way, such as by removing 1029 the copyright notice or references to the Internet Society or other 1030 Internet organizations, except as needed for the purpose of 1031 developing Internet standards in which case the procedures for 1032 copyrights defined in the Internet Standards process must be 1033 followed, or as required to translate it into languages other than 1034 English. 1036 The limited permissions granted above are perpetual and will not be 1037 revoked by the Internet Society or its successors or assignees. 1039 This document and the information contained herein is provided on an 1040 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1041 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1042 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1043 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1044 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1046 Acknowledgment 1048 Funding for the RFC Editor function is currently provided by the 1049 Internet Society.