One document matched: draft-thomson-geopriv-location-dependability-07.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3076 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3076.xml">
<!ENTITY RFC3275 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3275.xml">
<!ENTITY RFC3548 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3548.xml">
<!ENTITY RFC3688 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml">
<!ENTITY RFC3693 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3693.xml">
<!ENTITY RFC3863 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3863.xml">
<!ENTITY RFC4119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4119.xml">
<!ENTITY RFC4479 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4479.xml">
<!ENTITY RFC5246 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC5687 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5687.xml">
<!ENTITY RFC5985 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5985.xml">
<!ENTITY RFC5986 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5986.xml">
<!ENTITY W3C.REC-xmlschema-1-20041028 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-xmlschema-1-20041028.xml">
<!ENTITY I-D.ietf-geopriv-arch PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-arch.xml">
]>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<rfc category="std" ipr="trust200902">
<front>
<title abbrev="Location Dependability">
Digital Signature Methods for Location Dependability
</title>
<author initials="M." surname="Thomson"
fullname="Martin Thomson">
<organization>Andrew</organization>
<address>
<postal>
<street>Andrew Building (39)</street>
<street>Wollongong University Campus</street>
<street>Northfields Avenue</street>
<city>Wollongong</city>
<region>NSW</region>
<code>2522</code>
<country>Australia</country>
</postal>
<phone>+61 2 4221 2915</phone>
<email>martin.thomson@andrew.com</email>
<uri>http://www.andrew.com/</uri>
</address>
</author>
<author initials="J." surname="Winterbottom"
fullname="James Winterbottom">
<organization>Andrew</organization>
<address>
<postal>
<street>Andrew Building (39)</street>
<street>Wollongong University Campus</street>
<street>Northfields Avenue</street>
<city>Wollongong</city>
<region>NSW</region>
<code>2522</code>
<country>Australia</country>
</postal>
<phone>+61 2 4221 2938</phone>
<email>james.winterbottom@andrew.com</email>
<uri>http://www.andrew.com/</uri>
</address>
</author>
<date month="March" year="2011"/>
<area>Application</area>
<workgroup>GEOPRIV</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>Location</keyword>
<keyword>Dependability</keyword>
<keyword>PIDF-LO</keyword>
<keyword>HELD</keyword>
<keyword>LIS</keyword>
<abstract>
<t>The dependability of location information is closely related to the degree of trust placed in the source of that information. This document describes techniques that can be used to mitigate the impact of falsifying location information. The application of digital signatures is described, relating these methods to the attacks that they address.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>Location information about a particular person or device is critical to a number of applications. The integrity of this information - whether or not it can be relied upon for correctness - is also important to the user of the data. This is especially important if the recipient of location information expends resources based on the information.
</t>
<t>The quitessential example of an application where the veracity of location information is critical is emergency calling. Location information is used both by routing functions to determine the correct Public Safety Answering Point (PSAP) and by the selected PSAP to determine where to send personnel. If location information were faked, the call could be directed to the wrong PSAP, or personnel could be directed to an incorrect location. In either case, an attacker wastes PSAP resources and risks delaying their life-critical interventions for other legitimate emergency callers.
</t>
<t>This document details several cryptographic methods that limit the scope of attacks on location recipients based on faked or stolen location information. Methods for applying digital signatures are described so that a location recipient can identify the source of the location information, either Location Information Server (LIS) or Target. Identifying the source allows the location recipient to make a judgement on whether or not to trust the content of the location information.
</t>
<t>Ultimately, these methods are limited in practicality by the transient nature of the relationships between LIS (the access network) and the Target. Because these relationships can be arbitrary and temporary, schemes like authentication are not always feasible. The basic goal of this draft is to both limit the scope of attacks and to provide as much information to the location recipient as possible so that they can make a decision on whether or not to act on the location information they are provided.
</t>
<section anchor="terminology" title="Terminology">
<t>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 <xref target="RFC2119"/>.
</t>
</section>
</section>
<section title="Goals">
<t>This document describes several measures that can be applied to limit attacks that rely on using faked or stolen location information. These attacks leave a user of location information vulnerable to exploitation by an attacker.
</t>
<t>The measures outlined in this document are designed to limit exposure to the following attacks:
<list style="hanging">
<t hangText="Place Shifting:">In place shifting, an attacker selects any location (presumably somewhere other than where they are currently located) and constructs a PIDF-LO based on that information.
</t>
<t hangText="Time Shifting:">In a time shifting, or replay, attack the attacker uses location information that was valid in the past, but is no longer valid because the attacker has moved since the location was generated.
</t>
<t hangText="Location Theft:">An attacker that is able to observe the Target's location information can replay this information and thereby appear to be at the same location.
</t>
<t hangText="Location Swapping:">Two colluding attackers can conspire to fake location by exchanging location information. One attacker can pretend to be at the other's location.
</t>
</list>
These attacks are a subset of those described in <xref target="RFC5687"/>.
</t>
<section title="Non-Goals">
<t>The measures outlined in this document cannot address all possible cases where location is spoofed. This section outlines general areas where this document does not provide guidance; more specific limitations are included in the relevant sections.
</t>
<t>Attacks where the authenticated identity of the Target can be reliably mimicked are not included. This includes active collusion, as well as any attacks, network-based or otherwise, on the Target host that result in complete access to the Target's credentials. In addition, this includes attacks that require cooperation between the attacker and Target. If the attacker is able to gain access to the Target's private key, then to all cryptographic means the attacker can pretend to be the Target.
</t>
<t>Methods for determining trust in either LIS or Target are out of scope for this document. This document only describes the means by which an identity can be verified; the decision over whether or not to trust the entity is left to the location recipient. Means for establishing trust will be the topic of a separate work.
</t>
<t>Note that where certificate chains are used for authentication, a domain name-based certificate does not necessarily indicate trustworthiness in the provision of location information. Therefore, verification of LIS identity through a certificate alone is not enough to ensure that the location recipient can trust the LIS, the recipient needs to use additional criteria to decide on whether to trust the LIS.
</t>
</section>
<section title="Basic Countermeasures">
<t>A good minimum requirement for the exchange of location information is that location information is protected from interception and modification by third parties in all protocol exchanges. Confidentiality from unauthorized third parties and integrity protection are required for all location using-protocols <xref target="RFC3693"/>.
</t>
<t>Location protocols that use <xref target="RFC5246">TLS</xref> are able to meet this requirement providing mutual authentication is adequate. <xref target="RFC5985">HELD</xref> relies on TLS for this purpose.
</t>
</section>
<section title="Signing Location Information">
<t>A digital signature provides data integrity and attribution for the signed information. This document describes how <xref target="RFC3275">XML-Signature</xref> can be applied to a <xref target="RFC4119">Presence Information Data Format - Location Object (PIDF-LO)</xref>. It also describes the benefits of signing and how signing can be practically applied.
</t>
<t>PIDF-LO contains a number of different units of data: location information, time, and identity being most important in this context <xref target="I-D.ietf-geopriv-arch"/>. How these are bound in a signature determine what meaning is conveyed. This document describes how certain bindings can be signed.
</t>
<t>In signing a PIDF-LO, the signer makes an assertion about these bindings. It is the signer's responsibility to verify that the bindings it signs are correct and verified. Failure to do so has an impact on how trust in the signer is maintained. Without trust in a signer, the signatures they provide are ineffectual.
</t>
</section>
</section>
<section title="PIDF-LO Signature">
<t>A location recipient can use the signature on a location object to authenticate the identity of the signer, usually the source of the information. The identity of the source is indicated in the certificate that is attached to the signature. The signature also ensures that the contents have not been modified since the location object was signed.
</t>
<t>In <xref target="I-D.ietf-geopriv-arch">GEOPRIV</xref> this entity is likely to be either a location information server (LIS) or the Device that is the subject of the location information. Other providers of location information, or location servers (LS), might also provide signatures.
</t>
<t>It is important to specify the semantics of a certificate of this nature. In essence, information that is signed SHOULD be verifiable by the signer. However, in some cases it is expedient to include some unverifiable information (as is shown in later sections). Therefore, this document assigns a strict semantic to each signed element in the location object.
</t>
<section title="Signature Design">
<t>[[Design Note: It is recognized that XML-Signature has a major failure in its reliance on XML canonicalization. Due to this reliance, very few interoperable implementations of XML-Signature exist. On the other hand, it does offer a great deal of flexibility, such as the ability to select the elements that are signed. The alternative is for the signer to just remove the unsigned portions. Then any alternative signature method could be used, such as the equally widely implemented S/MIME.]]
</t>
<t>This document uses the <xref target="RFC3275">XML-Signature</xref> enveloped signature type; that is, signature elements are included within the normal structure of the PIDF-LO document. This ensures that the location object does not appear to be any different from a regular PIDF-LO document. This permits use of the document in any protocol that carries PIDF-LO without requiring any changes to the protocol. Applications that rely on PIDF-LO can simply ignore the signature elements if they are not supported.
</t>
<t>A signature is applied to a single tuple within the PIDF document. This means that signed location information can be included in a composite presence document without destroying the signature.
</t>
<t>It is also a goal of the signature design to ensure that if unsigned elements are removed from the PIDF-LO, the document remains a valid PIDF-LO. This keeps the PIDF-LO usable if the signature and any unsigned data are stripped out. This is particularly important when the <xref target="rules">signature rules</xref> are applied.
</t>
</section>
<section anchor="elements" title="Signed Elements and Semantics">
<t>When location information is signed by a LIS, each unit of data in the signed document is given certain significance. A location recipient needs to know what significance the LIS has given to each field before it can base any decision on the contents of that field.
</t>
<t>The following list describes each of the elements that are included in a signed LO, justifies their inclusion and outlines the intended semantics of each being signed:
<list style="hanging">
<t hangText="presence (urn:ietf:params:xml:ns:pidf):">
The root element of a <xref target="RFC3863">presence document</xref>, the <spanx style="verb">presence</spanx> element, is signed. The <spanx style="verb">entity</spanx> attribute is also signed. In most cases, the <spanx style="verb">entity</spanx> attribute contains an identifier generated by the LIS, see <xref target="identity"/> and <xref target="anon-identity"/>.
</t>
<t hangText="tuple (urn:ietf:params:xml:ns:pidf):">
Only the tuple that contains location information is signed. The <spanx style="verb">id</spanx> attribute is signed to ensure a valid PIDF-LO is produced, but no significance is attached to its value. Likewise, the <spanx style="verb">device</spanx> and <spanx style="verb">person</spanx> elements (in the <spanx style="verb">urn:ietf:params:xml:ns:pidf:data-model</spanx> namespace, <xref target="RFC4479"/>) that contain location information need to be included by the signature.
</t>
<t hangText="geopriv (urn:ietf:params:xml:ns:pidf:geopriv10):">
The <spanx style="verb">geopriv</spanx> element is signed, along with select elements within it.
</t>
<t hangText="location-info (urn:ietf:params:xml:ns:pidf:geopriv10):">
The most important element of the PIDF-LO, <spanx style="verb">location-info</spanx> contains location data. This element and all its contents are signed.
</t>
<t hangText="usage-rules (urn:ietf:params:xml:ns:pidf:geopriv10):">
Usage rules are included to ensure the validity of the PIDF-LO. An empty <spanx style="verb">usage-rules</spanx> element is valid. The contents of these are not signed to allow a user to enter their preferences upon receipt of the signed LO. A LIS does not typically set policy, so SHOULD NOT sign these elements unless a Rule Maker (see <xref target="RFC3693"/>) has provided values. No decisions can be made on the unsigned content of usage rules.
</t>
<t hangText="method (urn:ietf:params:xml:ns:pidf:geopriv10):">
The method parameter is included, and consequently signed, only if known. The LIS SHOULD verify the accuracy of this field, but MAY opt to include the element without validation. An unvalidated method is allowed because of the informational nature of the data it contains. Method is a metadata element and therefore is not a suitable basis for decision making, especially where a similar decision can be based on location information. A recipient SHOULD NOT use the value of this field as the basis for any decision.
</t>
<t hangText="timestamp (...:pidf or ...:pidf:data-model):">
The time that location is generated (or signed) is extremely important in determining whether location information is valid. This element, defined in <xref target="RFC3863"/> or <xref target="RFC4479"/> is always validated and signed.
</t>
<t hangText="All elements defined in this document:">
This document defines a number of elements that are designed for inclusion in the tuple. These elements limit the effectiveness of certain attacks. Validity intervals and Target identity are defined in <xref target="validity"/>, <xref target="identity"/>.
</t>
</list></t>
<t>This document defines two transforms that can be applied to a PIDF-LO in order to limit what is signed <xref target="transforms"/>. The first is a selective transform that only selects the elements listed above. The second simply selects the enveloping <spanx style="verb">tuple</spanx>, <spanx style="verb">device</spanx> or <spanx style="verb">person</spanx>element. The signing entity MAY choose not to use either transform, but in doing so, all unverified elements MUST be removed before applying the signature.
</t>
</section>
<section title="Signature Algorithms">
<t>As specified in <xref target="RFC3275">RFC 3275</xref>, implementations of this specification MUST provide the following algorithms:
<list style="hanging">
<t hangText="digest algorithm:">The SHA1 digest, as identified by the URN <spanx style="verb">http://www.w3.org/2000/09/xmldsig#sha1</spanx>.
</t>
<t hangText="signature algorithm:">DSA with SHA1, as identified by the URN <spanx style="verb">http://www.w3.org/2000/09/xmldsig#dsa-sha1</spanx>.
</t>
<t hangText="canonicalization method:">Canonical XML <xref target="RFC3076"/>, as identified by the URN <spanx style="verb">http://www.w3.org/TR/2001/REC-xml-c14n-20010315</spanx>.
</t>
<t hangText="transforms:">The enveloped signature transform, as identified by the URN <spanx style="verb">http://www.w3.org/2000/09/xmldsig#enveloped-signature</spanx>; and the transforms defined in this document: the <xref target="transform-tuple">tuple-only transform</xref>, as identified by the URN <spanx style="verb">urn:ietf:params:xml:ns:pidf:geopriv10:dsig#tuple</spanx> and the <xref target="transform-selective">selective transform</xref>, as identified by the URN <spanx style="verb">urn:ietf:params:xml:ns:pidf:geopriv10:dsig#selective</spanx>.
</t>
</list>
</t>
<t>It is also RECOMMENDED that the PKCS1 (RSA-SHA1) signature algorithm, as idenfied by <spanx style="verb">http://www.w3.org/2000/09/xmldsig#rsa-sha1</spanx> is also supported.
</t>
</section>
<section title="LIS/Signer Identification">
<t><xref target="RFC3275">RFC 3275</xref> describes a number of methods for describing the key used to sign the document. For the purpose of signing a location object, the <spanx style="verb">KeyInfo</spanx> element MUST be provided in the <spanx style="verb">Signature</spanx> element.
</t>
<t>The signer MUST include an X.509v3 certificate in the signature. This can be either by including an <spanx style="verb">X509Certificate</spanx> element, or by referencing another certificate in the same document.
</t>
<t>A reference to a certificate within the same document may be made using a fragment identifier URI. Internal references could be applicable where multiple signatures are applied to different parts of the document. This might be the case if a multiple location forms are included.
</t>
<t>The signer MUST NOT reference an external source unless there is a reasonable expectation that the location recipient can successfully retrieve the certificate. A reference to an external certificate MUST be described by URI in the <spanx style="verb">RetrievalMethod</spanx> element. The scheme for the the RetrievalMethod URI MUST be <spanx style="verb">https:</spanx>.
</t>
</section>
</section>
<section anchor="validity" title="Limited Validity">
<t>The simplest attack to address is the Time Shifting attack. The <spanx style="verb">timestamp</spanx> element provides a basic indication of when location information was created.
</t>
<t>However, the basic timestamp doesn't provide any indication of how long that information is likely to be valid for. The signer can specify a limited time period where the location information can be considered valid.
</t>
<t>A known limitation of this method is that the information could become invalid at any time after the document is signed. Once location is generated, the Target can move at any time, thereby invalidating the location object. Therefore, there is a trade-off in selecting a value that minimizes errors, while increasing the chance that the information is useful. The signer might base any chosen period on any knowledge it has about the mobility or current speed of the Target.
</t>
<t>The time constraints can be considered guidelines provided by a signer. Recipients can choose instead to base decisions purely on the <spanx style="verb">timestamp</spanx> element. Location recipients MAY choose to implement a minimum age policy for locations. If present, either the <spanx style="verb">from</spanx> element or the <spanx style="verb">timestamp</spanx> element can be used to determine age, depending on whether elapsed time from validation or time from generation is considered most important to the application.
</t>
<section title="Validity Elements">
<t>A <spanx style="verb">validity</spanx> element is defined with two sub-elements, <spanx style="verb">from</spanx> and <spanx style="verb">until</spanx>.
</t>
<t>The <spanx style="verb">from</spanx> element contains the time that the location information was validated by the signer. This could differ from the time that the location was generated, which is included in the PIDF <spanx style="verb">timestamp</spanx> element.
</t>
<t>The <spanx style="verb">until</spanx> element contains the last time that the signature can be considered valid. Choice of an appropriate validity interval is left to LIS implementations; however, this period MUST NOT exceed one day. The period chosen SHOULD also consider the type of network access in use - location becomes invalid faster in more mobile networks.
</t>
<t>The signature MUST NOT be considered valid if the current time is outside of the interval specified in these elements.
</t>
</section>
</section>
<section anchor="identity" title="Signing for a User">
<t>Signing location information alone, even with a limited validity period does not ensure that it is not reused. Signing some sort of user identifier with the location object provides an additional degree of protection. Most importantly, the location recipient is able to detect duplicate location objects for the same Target. In addition, if some extra data is included from the Target, the location recipient is also able to link the location object with a user identity.
</t>
<section anchor="presentity" title="The 'entity' Attribute">
<t>The <spanx style="verb">entity</spanx> attribute of a presence document is intended to convey the identity of the Target. The signer does not necessarily know this identity. Nor does the LIS necessarily have the means to authenticate the Target. This is especially true for identities in application domains that are not known to the LIS.
</t>
<t>The signer SHOULD construct an "unlinked pseudonym" for the presentity. This pseudonym does not contain any information that could be used to identity the Target. The simplest way to meet this requirement is to generate a <spanx style="verb">pres:</spanx> URI randomly, using a random sequence of characters and the host name of the LIS (e.g., <spanx style="verb">pres:f6pc98w1pd49s0p@lis.example.com</spanx>).
</t>
<t>An unlinked pseudonym provides a limited means of ensuring that location information is not reused or replayed. The presentity identifier used acts as a serial number for each location object, allowing each to be uniquely identified. A location recipient is able to use this identifier to detect multiple uses of the same piece of location information. This limits the effectiveness of replay attacks.
</t>
<t>However, an unlinked pseudonym does not provide any useful identification information. Users of this information are forced to rely on external information to bind the identity of the Target of the document to a specific entity.
</t>
<t>Some continuity can be provided by reusing unlinked pseudonyms for the same Target. If the LIS is able to verify that the Target is the same, the same identifier can be used in multiple PIDF-LO documents, linking these documents. This depends on the means by which location is acquired from the LIS; if session data that links subsequent requests exists, the LIS MAY reuse the presentity identifier. Note that some means is required to break this continuity to allow for a Target that does not wish for this linkage to occur.
</t>
<t>This does not prevent the use of a "real" presentity in this field. If the LIS is able to authenticate the Target, and the Target grants permission to the LIS to use this field, the LIS can include this information in the <spanx style="verb">entity</spanx> field. These conditions are hard to meet, which leads to two alternative means of including Target identity, described in the following sections.
</t>
</section>
<section anchor="target-identity" title="Target Identity">
<t>The unlinked pseudonym used by the LIS acts as an anonymous identifier. The only information that this provides to a location recipient is that two location objects were generated for the same anonymous Target. The location recipient might also wish to link the location object to the identity of a particular user. For example, a PSAP might want to link the location object to the authenticated identity of a emergency caller.
</t>
<t>To achieve this linkage between location object and the Target's identity, the Target sends its identity to the LIS. The LIS includes this identifier in the signed location object, effectively linking the identity to the location information.
</t>
<t>A location recipient verifies that location information was signed for a particular Target by authenticating the Target and comparing the authenticated identity against the one in the signed location object.
</t>
<t>The LIS is not expected to authenticate this identity information, although it MAY do so. This means that an attacker within the network could request a signed location object with any identity they choose. However, the location object could only be used by an entity that can prove that they have the chosen identity, which limits the number of potential attackers.
</t>
</section>
<section anchor="anon-identity" title="Protecting User Anonymity">
<t>The problem with sending the Target's identity to the LIS is that the Target might not wish to provide this information to the access network operator.
</t>
<t>This can be addressed by using a cryptographic hash of the user identity in place of the actual identifier. Since the LIS does not necessarily authenticate the identity, this information provides the same attributes as the real identity. Since the hash is not reversible, the LIS is unable to identify the Target, but the hash cannot be generated from any identifier other than the one used by the Target.
</t>
<t>The location recipient authenticates the Target's identity, then compares a hash of the identity to the hash that is included in the location object to verify that the identity matches.
</t>
</section>
<section anchor="auth-identity" title="Authenticated Identity">
<t>With the above solution, one easy collusion attack exists. One attacker at the actual location requests a location object with another attacker's identity. The second, potentially remote, attacker is able to use this object. If the first attacker is authenticated by the LIS, this attack is limited, because it requires that both attackers have access to the same authentication credentials.
</t>
<t>The effectiveness of this approach is limited by the ability of the LIS to authenticate arbitrary users in the access network. Location recipients cannot rely on the LIS performing authentication.
</t>
<t>Authenticating the Target is complicated by the fact that the identity used in the application domain where location is consumed might be significantly different to the one that a LIS operates in. Identity that might be used by a location recipient might have no meaning (or a completely different meaning) to a LIS.
</t>
</section>
<section anchor="plethora-identity" title="Multiple Identity Attack">
<t>The schemes described in this section rely on the Target providing an identity. A potential attack uses a single attacker in the access network that requests location information using a number of different identities. The attacker requests multiple location objects, using a different identity each time. These objects are passed to any number of other attackers, who are each able to authenticate with the identity that is included in the location object. This potentially allows a large number of distributed attackers to use the same location information to perform a denial of service attack.
</t>
<t>In some scenarios, multiple identities can be valid. Examples in Section 3 of <xref target="RFC5687"/> show that multiple hosts can appear from the same network demarcation point. Ideally, the LIS would still serve these hosts individually because they each have a valid reason to acquire location information under different identities.
</t>
<t>A LIS SHOULD limit the number of identities that can be served from any particular network point to limit attacks where users request large numbers of location objects with different identity information. Authenticating the Targets in this scenario could provide some additional surety that each is legitimate. If multiple Targets legitimately exist at the same location, then these Targets can authenticate with the LIS. The LIS MAY use a higher limit for authenticated Targets.
</t>
</section>
</section>
<section anchor="identity-element" title="Target Identity Element">
<t>This document defines an XML <spanx style="verb">identity</spanx> element that can be used to include identity information in a PIDF-LO. This element is used in addition to a randomized <spanx style="verb">entity</spanx> attribute for several reasons: a randomized <spanx style="verb">entity</spanx> attribute can be used to detect replays; the identity is not necessarily authenticated; and the content can be other than a presentity identifier.
</t>
<section title="Identity Types">
<t>The content of this element is dependent on the type associated with the identifier. The <spanx style="verb">type</spanx> attribute is used to define the nature of the identity that is included. Two values are provided by default:
<list style="hanging">
<t hangText="URI:">A value of <spanx style="verb">urn:ietf:params:xml:ns:pidf:geopriv10:dsig:identity#uri</spanx> for the type attribute indicates that the contents are a URI. This URI can include a presentity URI, or other URI that identifies the target; for example a SIP URI. This type MUST be supported.
</t>
<t hangText="An X.509 certificate:">A value of <spanx style="verb">urn:ietf:params:xml:ns:pidf:geopriv10:dsig:identity#x509</spanx> indicates that the contents are an <xref target="X509v3">X.509v3 certificate</xref>, in the format described in <xref target="RFC3275"/> for <spanx style="verb">X509Certificate</spanx>.
</t>
</list>
</t>
<t>New identity types are identified by URNs, which means that registration is not required to add new types. A location recipient that does not support a particular identity type MUST treat the location object as if no identity information were included.
</t>
</section>
<section title="Identity Hashing">
<t>To allow for anonymity, the content of the <spanx style="verb">identity</spanx> element MAY be hashed and the hash value included in this element instead. The <spanx style="verb">hash</spanx> attribute indicates whether the value has been hashed. A reserved value of <spanx style="verb">##none</spanx> indicates that the actual value is included. Otherwise, the attribute includes a hash algorithm identifier, as defined in <xref target="RFC3275"/>. The SHA1 algorithm MUST be supported; this is identified by the URN <spanx style="verb">http://www.w3.org/2000/09/xmldsig#sha1</spanx>.
</t>
<t>Each different identity type requires a procedure for obtaining the bytes that are hashed.
<list style="hanging">
<t hangText="URI:">For the URI type, the input to the hash algorithm is the UTF-8 bytes of the URI. One consequence of this is that portions of URIs that might be case insensitive are made case sensitive.
</t>
<t hangText="X.509:">For the X.509 type, the input to the hash algorithm is the distinguished encoding rules (DER) encoded value of the certificate.
</t>
</list></t>
<t>If the <spanx style="verb">hash</spanx> attribute is present and set to a value other than <spanx style="verb">##none</spanx>, the contents of the <spanx style="verb">identity</spanx> element are always the <xref target="RFC3548">base64 encoded</xref> result from the hash function.
</t>
</section>
<section title="Authentication Indicator">
<t>If the LIS is able to authenticate the Target, the LIS can indicate this in the <spanx style="verb">authenticated</spanx> attribute.
</t>
<t>This indicator can be used irrespective of the value of the <spanx style="verb">hash</spanx> attribute. This indicates to the location recipient that user identity included in the <spanx style="verb">identity</spanx> element was authenticated by the LIS.
</t>
</section>
</section>
<section title="Requesting Dependable Location Information using HELD">
<t><xref target="RFC5985">HELD</xref> is used by Devices to request location information. This section outlines parameters that can be included in HELD requests to ensure that location. Requesting dependable location information from a context provides less direct benefit to a Location Recipient that is requesting location information directly from a LIS.
</t>
<t>Inclusion of a <spanx style="verb">dependability</spanx> element in a HELD location request indicates that the Device wants signed location information. In a context creation or update requests, the Device can include this information for the LIS to store in the context for use when serving requests to the associated location URI.
</t>
<t>Since this is an extension to the HELD protocol, the LIS might not provide a signature if it does not support this specification or it chooses not to for administrative reasons. The Device is responsible for ensuring that a signature was applied.
</t>
<t>The Device SHOULD include an <spanx style="verb">identity</spanx> element, which indicates what value is to be included in the <spanx style="verb">identity</spanx> element of the signed PIDF-LO. Location Recipients MUST NOT include this parameter when requesting location information from a location URI. The <spanx style="verb">identity</spanx> element is identical to that included in the PIDF-LO (see <xref target="identity-element"/>) except that it does not include the <spanx style="verb">authenticated</spanx> attribute.
</t>
<figure>
<preamble>The following sample HELD location request includes a dependency element with identity information.
</preamble>
<artwork><![CDATA[
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
responseTime="2000">
<locationType exact="true">geodetic</locationType>
<dependency
xmlns="urn:ietf:params:xml:ns:geopriv:held:dep">
<identity
form="urn:ietf:params:xml:ns:pidf:geopriv10:dsig:identity#uri"
hash="http://www.w3.org/2000/09/xmldsig#sha1">
60NvZvtdTB+7UnlLp/H24p7h4bs=
</identity>
</dependency>
</locationRequest>
]]></artwork>
</figure>
<t>Identity information is provided to the LIS under the understanding that the Device identity is included in the PIDF-LO. This information could be used to link identity with location information by the LIS or by Location Recipients. Including hashed information ensures that identity information is not revealed to the LIS.
</t>
</section>
<section title="Signature Validation">
<t>A location recipient performs the following steps to validate a signed location object:
<list style="numbers">
<t>Authenticate the entity that provided the location information (the sender).
</t>
<t>Check the integrity of the digital certificate.
</t>
<t>Extract the identity of the LIS from the digital certificate.
</t>
<t>Remove all unsigned components from the location object.
</t>
<t>Ensure the validity interval from the location object covers the present time.
</t>
<t>Check that the authenticated identity of the identified subject matches the identity in the location object, or that a hash of this identity matches the hashed identity in the location object. How the subject is identified depends on how the location object is acquired by the location recipient.
</t>
</list>
</t>
<t>Once this process is complete, the location recipient has the following information upon which to base any policy decision:
<list style="symbols">
<t>Whether the location object was signed.
</t>
<t>Whether the signature on the location object was valid.
</t>
<t>The identity of the sender.
</t>
<t>The identity of the LIS.
</t>
<t>Whether the LIS authenticated the sender in generating the location object.
</t>
<t>The presentity identifier generated by the LIS that distinguishes this location object.
</t>
</list>
</t>
<t>Policies are set by individual location recipients and are dictated by a range of factors. Even a failure in signature validation does not necessarily require that the location recipient reject the location information.
</t>
<t>For instance, a PSAP might not reject an emergency call with no signature. The PSAP could instead place a lower priority on such a call so that in a busy period the call is queued behind calls that contained valid signatures. Similarly, un-authenticated calls could be given similar treatment.
</t>
</section>
<section title="Code and Examples">
<section anchor="schema" title="Dependability Data Schema">
<figure>
<preamble>The following <xref target="W3C.REC-xmlschema-1-20041028">XML Schema</xref> defines the <spanx style="verb">dependability</spanx> element. This element is intended for use in a PIDF-LO within a <spanx style="verb">tuple</spanx>.
</preamble>
<artwork><![CDATA[
<?xml version="1.0"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:dsig"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:dsig="urn:ietf:params:xml:ns:pidf:geopriv10:dsig"
xmlns:xmldsig="http://www.w3.org/2000/09/xmldsig#"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"/>
<xs:element name="dependability" type="dsig:dependabilityType"/>
<xs:complexType name="dependabilityType">
<xs:sequence>
<xs:element ref="dsig:validity"/>
<xs:element ref="dsig:identity" minOccurs="0"/>
<xs:element ref="xmldsig:Signature" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:element name="validity" type="dsig:validityType"/>
<xs:complexType name="validityType">
<xs:sequence>
<xs:element name="from" type="xs:dateTime" minOccurs="0"/>
<xs:element name="until" type="xs:dateTime"/>
</xs:sequence>
</xs:complexType>
<xs:element name="identity" type="dsig:identityType"/>
<xs:complexType name="identityType">
<xs:simpleContent>
<xs:extension base="xs:anySimpleType">
<xs:attribute name="type" use="required" type="xs:anyURI"/>
<xs:attribute name="hash" default="##none">
<xs:simpleType>
<xs:union memberTypes="xs:anyURI">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="##none"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="authenticated" type="xs:boolean"
default="false"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
]]></artwork>
</figure>
</section>
<section anchor="heldschema" title="HELD Dependability Request Schema">
<figure>
<preamble>The following <xref target="W3C.REC-xmlschema-1-20041028">XML Schema</xref> defines the <spanx style="verb">dependability</spanx> element for inclusion in HELD requests.
</preamble>
<artwork><![CDATA[
<?xml version="1.0"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv:held:dep"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:hd="urn:ietf:params:xml:ns:geopriv:held:dep"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:held:dep">
HELD Dependability Request Elements
</xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
published RFC and remove this note.]] -->
This document defines dependability elements for HELD.
</xs:documentation>
</xs:annotation>
<xs:element name="dependability" type="hd:dependabilityType"/>
<xs:complexType name="dependabilityType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element ref="hd:identity" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="identity" type="hd:identityType"/>
<xs:complexType name="identityType">
<xs:simpleContent>
<xs:extension base="xs:anySimpleType">
<xs:attribute name="type" type="xs:anyURI" use="required"/>
<xs:attribute name="hash" default="##none">
<xs:simpleType>
<xs:union memberTypes="xs:anyURI">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="##none"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
]]></artwork>
</figure>
</section>
<section anchor="transforms" title="PIDF-LO Transforms">
<t>The transforms defined in this section select certain parts of a PIDF-LO document for signing. These transforms ensure that only one tuple is signed, with varying amounts of content. This allows location information to be composed with other tuples and for independent signatures on multiple tuples.
</t>
<t>The LIS MUST use one of these transforms to avoid the implication that only the tuple is signed (where in fact the entire document would be signed). The enveloped signature transform MUST also be used.
</t>
<t>These transforms can be implemented by substituting instances of transforms (identified by URNs) with the XPath transforms below. However, equivalent implementations using other means might provide better performance.
</t>
<section anchor="transform-tuple" title="PIDF-LO Tuple-only Transform">
<figure>
<preamble>The following <xref target="RFC3275">XPath filter</xref> selects the first <spanx style="verb">tuple</spanx>, <spanx style="verb">device</spanx> or <spanx style="verb">person</spanx> descendant of the signature element and all its contents. The <spanx style="verb">presence</spanx> element that is the immediate parent of the tuple is also selected. This transform is identified by the URN <spanx style="verb">urn:ietf:params:xml:ns:pidf:geopriv10:dsig#tuple</spanx>.
</preamble>
<artwork><![CDATA[
<dsig:Transform id="tuple"
Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:XPath
xmlns:pidf="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model">
<!-- The 'tuple' element and all decendants -->
(count(ancestor-or-self::pidf:tuple[1]
| here()/ancestor::pidf:tuple[1]) == 1)
<!-- The 'device' element and all decendants -->
or (count(ancestor-or-self::dm:device[1]
| here()/ancestor::dm:device[1]) == 1)
<!-- The 'person' element and all decendants -->
or (count(ancestor-or-self::dm:person[1]
| here()/ancestor::dm:person[1]) == 1)
<!-- The 'presence' element -->
or (count(self::pidf:presence
| here()/ancestor::pidf:presence[1]) = 1)
<!-- All attributes and namespace declarations
on the presence element -->
or ((count(parent::pidf:presence
| here()/ancestor::pidf:presence[1]) = 1)
and (count(self::node() | parent::*/attribute::*
| parent::*/namespace::*) + 1
== (count(self::node()) + count(parent::*/attribute::*)
+ count(parent::*/namespace::*))))
</dsig:XPath>
</dsig:Transform>
]]></artwork>
</figure>
</section>
<section anchor="transform-selective" title="PIDF-LO Selective Transform">
<figure>
<preamble>Similar to the tuple-only transform, this transform selects a single <spanx style="verb">tuple</spanx> element and its parent <spanx style="verb">presence</spanx> element. In contrast, this transform only selects those elements listed in <xref target="elements"/>. This transform allows a Target to make adjustments to non-critical elements in the PIDF-LO after the signed PIDF-LO is received from the LIS. In particular, this allows the Target to set the content of the <spanx style="verb">usage-rules</spanx> element and other PIDF data, like contact information. This transform is identified by the URN <spanx style="verb">urn:ietf:params:xml:ns:pidf:geopriv10:dsig#selective</spanx>.
</preamble>
<artwork><![CDATA[
<dsig:Transform id="selective"
Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:XPath
xmlns:pidf="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:dep="urn:ietf:params:xml:ns:pidf:geopriv10:dsig"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model">
<!-- The 'presence' element -->
(count(self::pidf:presence
| here()/ancestor::pidf:presence[1]) = 1)
<!-- The 'tuple' element and all selected descendants -->
or (((count(ancestor-or-self::pidf:tuple[1]
| here()/ancestor::pidf:tuple[1]) == 1)
or (count(ancestor-or-self::dm:device[1]
| here()/ancestor::dm:device[1]) == 1)
or (count(ancestor-or-self::dm:person[1]
| here()/ancestor::dm:person[1]) == 1))
and (self::pidf:tuple or self::dm:device
or self::dm:person or self::pidf:status
or ancestor-or-self::pidf:timestamp
or ancestor-or-self::dm:timestamp
or ancestor-or-self::dm:deviceID
or self::gp:geopriv or self::gp:usage-rules
or ancestor-or-self::gp:method
or ancestor-or-self::gp:location-info
or ancestor-or-self::dep:dependability))
<!-- All attributes (including namespace declarations) -->
<!-- Needed for elements without ancestor-or-self rules above -->
or ((count(self::node() | parent::*/attribute::*
| parent::*/namespace::*) + 1
== (count(self::node()) + count(parent::*/attribute::*)
+ count(parent::*/namespace::*)))
and parent::*[
(count(self::pidf:presence
| here()/ancestor::pidf:presence[1]) = 1)
or (((count(ancestor-or-self::pidf:tuple[1]
| here()/ancestor::pidf:tuple[1]) == 1)
or (count(ancestor-or-self::dm:device[1]
| here()/ancestor::dm:device[1]) == 1)
or (count(ancestor-or-self::dm:person[1]
| here()/ancestor::dm:person[1]) == 1))
and (self::pidf:tuple or self::dm:device
or self::dm:person or self::pidf:status
or self::gp:geopriv or self::gp:usage-rules))
])
</dsig:XPath>
</dsig:Transform>
]]></artwork>
</figure>
</section>
</section>
<section anchor="example" title="Example">
<figure>
<preamble>The following PIDF-LO document has been signed using the selective transform. [[NOTE: A proper example, with a verifiable signature, will be created in a later version of this draft.]]
</preamble>
<artwork><![CDATA[
<?xml version="1.0"?>
<presence entity="pres:a6d5bs14vy9pu@lis.example.com"
xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gml="http://opengis.net/gml"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10">
<tuple id="pidflo1a786c3">
<status>
<gp:geopriv>
<gp:location-info>
<gml:position>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4979">
<gml:pos>-34.407 150.88001 34</gml:pos>
</gml:Point>
</gml:position>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>
2004-12-01T21:28:43+10:00
</gp:retention-expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
<dependability
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:dsig">
<validity>
<from>2007-02-16T16:25:24+11:00</from>
<until>2007-02-17T16:25:24+11:00</until>
</validity>
<identity
type="urn:ietf:params:xml:ns:pidf:geopriv10:dsig:identity#uri">
pres:user@example.com</identity>
<dsig:Signature
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:SignedInfo>
<dsig:CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
<dsig:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
<dsig:Reference URI="">
<dsig:Transforms>
<dsig:Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<dsig:Transform
Algorithm="urn:ietf:params:xml:ns:pidf:geopriv10:dsig#selective"/>
</dsig:Transforms>
<dsig:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<dsig:DigestValue>
60NvZvtdTB+7UnlLp/H24p7h4bs=
</dsig:DigestValue>
</dsig:Reference>
</dsig:SignedInfo>
<dsig:SignatureValue>
juS5RhJ884qoFR8flVXd/rbrSDVGn40CapgB7qeQiT+rr0NekEQ6BHhUA
8dT3+BCTBUQI0dBjlml9lwzENXvS83zRECjzXbMRTUtVZiPZG2pqKPnL2
YU3A9645UCjTXU+jgFumv7k78hieAGDzNci+PQ9KRmm//icT7JaYztgt4=
</dsig:SignatureValue>
<dsig:KeyInfo>
<dsig:X509Data>
<dsig:X509Certificate>
MIICeDCCAeGgAwIBAgIEOd3+iDANBgkqhkiG9w0BAQQFADBbMQsw
CQYDVQQGEwJJRTEPMA0GA1UECBMGRHVibGluMSUwIwYDVQQKExxC
YWx0aW1vcmUgVGVjaG5vbG9naWVzLCBMdGQuMRQwEgYDVQQDEwtU
ZXN0IFJTQSBDQTAeFw0wMDEwMDYxNjMyMDdaFw0wMTEwMDYxNjMy
MDRaMF0xCzAJBgNVBAYTAklFMQ8wDQYDVQQIEwZEdWJsaW4xJTAj
BgNVBAoTHEJhbHRpbW9yZSBUZWNobm9sb2dpZXMsIEx0ZC4xFjAU
BgNVBAMTDU1lcmxpbiBIdWdoZXMwgZ8wDQYJKoZIhvcNAQEBBQAD
gY0AMIGJAoGBALgorpKYDmjpq6tXz1Ex9wgF8bhZj47JkuI50ysa
79MNSSnF7SdjN2pGldXf5Gq7yZZnmqNtIzcva/v7ysIm4zO+xft2
yJHjBBpgCFJxXIiZEfooTu2+HE7mJxIvMR7buIjJ+hjgwaBM6hUG
HXfKeL62QbL7OOJ060vKssoW2uuPAgMBAAGjRzBFMB4GA1UdEQQX
MBWBE21lcmxpbkBiYWx0aW1vcmUuaWUwDgYDVR0PAQH/BAQDAgeA
MBMGA1UdIwQMMAqACEngrZIVgu03MA0GCSqGSIb3DQEBBAUAA4GB
AHJu4JVq/WnXK2oqqfLWqes5vHOtfX/ZhCjFyDMhzslI8am62gZe
dwZ9IIZIwlNRMvEDQB2zds/eEBnIAQPl/yRLCLOfZnbA8PXrbFP5
igs3qQWScBUjZVjik748HU2sUVZOa90c0mJl2vJs/RwyLW7/uCAf
C/I/k9xGr7fneoIW
</dsig:X509Certificate></dsig:X509Data>
</dsig:KeyInfo>
</dsig:Signature>
</dependability>
<note>
This note may be changed without affecting the signature.
</note>
<timestamp>2005-05-18T15:03:39.362+10:00</timestamp>
</tuple>
</presence>
]]></artwork>
</figure>
<figure>
<preamble>Once the signature has been checked, the following document is extracted. Only these elements have been included in the signature. Note that whitespace has been added to this example to improve readability and to conform to the limitations of this document format.
</preamble>
<artwork><![CDATA[
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gml="http://opengis.net/gml"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
entity="pres:a6d5bs14vy9pu@lis.example.com">
<tuple id="pidflo1a786c3">
<status>
<gp:geopriv>
<gp:location-info>
<gml:position>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4979">
<gml:pos>-34.407 150.88001 34</gml:pos>
</gml:Point>
</gml:position>
</gp:location-info>
<gp:usage-rules></gp:usage-rules>
</gp:geopriv>
</status>
<dependability
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:dsig">
<validity>
<from>2007-02-16T16:25:24+11:00</from>
<until>2007-02-17T16:25:24+11:00</until>
</validity>
<identity
type="urn:ietf:params:xml:ns:pidf:geopriv10:dsig:identity#uri">
pres:user@example.com</identity>
</dependability>
<timestamp>2005-05-18T15:03:39.362+10:00</timestamp>
</tuple>
</presence>
]]></artwork>
</figure>
</section>
</section>
<section title="Location Reference Attribution">
<t>Digital signatures are less useful when location is provided by reference. In this case, the location recipient acquires location information directly from the LIS.
</t>
<t>The location recipient is able to authenticate the LIS when it establishes a session to retrieve location information (and indeed, this authentication is necessary to protect against other forms of attack). This authentication process reveals to the location recipient the same information that would be included in a digital signature. Therefore, signing the result of a location deference is not necessary, unless the dereferencing entity intends to then pass the location object to another entity (note that this MUST also be permitted by the usage rules in the PIDF-LO).
</t>
<t>For use with location by reference, the <spanx style="verb">dependability</spanx> element can be provided without a signature. Allowing a LIS to provide location information where the attribution is based on the secure dereference channel, but the same information is available.
</t>
<t>Similar constraints apply to a location object that is retrieved by reference as those that apply to a signed location object. The location object that is retrieved by reference needs to include the same identity information that would be included in a signed location object.
</t>
<t>Validity elements are less critical, since it can be assumed that the LIS does not provide location information unless it is current. The PIDF <spanx style="verb">timestamp</spanx> element is sufficient to indicate when location information was generated.
</t>
</section>
<section anchor="security" title="Security Considerations">
<t>This entire document is about the security properties of location objects.
</t>
<section anchor="rules" title="Signature Rules">
<t>Three rules that relate to the treatment of signed information are described in <xref target="RFC3275"/>. These rules are:
<list style="symbols">
<t>Only What is Signed is Secure</t>
<t>Only What is "Seen" Should be Signed</t>
<t>"See" What is Signed</t>
</list>
These rules apply when a location recipient evaluates and uses a location object. These especially apply when displaying location information to a user, unsigned nodes SHOULD NOT be displayed and MUST be clearly marked as unsigned if they are shown.
</t>
</section>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This section registers the dependability elements schema and related namespace URNs with IANA.
</t>
<section title="URN Sub-Namespace Registration for urn:ietf:params:xml:ns:pidf:geopriv10:dsig">
<t>This section registers a new XML namespace, <spanx style="verb">urn:ietf:params:xml:ns:pidf:geopriv10:dsig</spanx>, as per the guidelines in <xref target="RFC3688"/>.
<list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:ns:pidf:geopriv10:dsig</t>
<t hangText="Registrant Contact:">IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).</t>
<t hangText="XML:">
<figure>
<artwork><![CDATA[
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>GEOPRIV Dependability Elements</title>
</head>
<body>
<h1>Namespace for GEOPRIV Dependability Elements</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:dsig</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body>
</html>
END
]]></artwork>
</figure>
</t>
<t hangText="Note:">Two fragment identifiers (<spanx style="verb">#tuple</spanx> and <spanx style="verb">#selective</spanx>) are added to this URN to identify the two transforms defined in RFCXXXX.
</t>
</list>
</t>
</section>
<section title="XML Schema Registration">
<t>This section registers an XML schema as per the guidelines in <xref target="RFC3688"/>.
<list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:schema:pidf:geopriv10:dsig</t>
<t hangText="Registrant Contact:">IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).</t>
<t hangText="Schema:">The XML for this schema can be found in <xref target="schema"/> of this document, between <spanx style="verb"><?xml version="1.0"?></spanx> and <spanx style="verb"></xs:schema></spanx> (inclusive).
</t>
</list>
</t>
</section>
<section title="URN Sub-Namespace Registration for urn:ietf:params:xml:ns:pidf:geopriv10:dsig:identity">
<t>This section registers a new XML namespace, <spanx style="verb">urn:ietf:params:xml:ns:pidf:geopriv10:dsig:identity</spanx>, as per the guidelines in <xref target="RFC3688"/>.
<list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:ns:pidf:geopriv10:dsig:identity</t>
<t hangText="Registrant Contact:">IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).</t>
<t hangText="XML:">
<figure>
<artwork><![CDATA[
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>GEOPRIV Dependability Elements</title>
</head>
<body>
<h1>Namespace for GEOPRIV Dependability Elements:
Identity Identifiers</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:dsig:identity</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body>
</html>
END
]]></artwork>
</figure>
</t>
<t hangText="Note:">Two fragment identifiers (<spanx style="verb">#uri</spanx> and <spanx style="verb">#x509</spanx>) are added to this URN to identify the two types of identity defined in RFCXXXX.
</t>
</list>
</t>
</section>
<section title="URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:held:dep">
<t>This section registers a new XML namespace, <spanx style="verb">urn:ietf:params:xml:ns:geopriv:held:dep</spanx>, as per the guidelines in <xref target="RFC3688"/>.
<list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:ns:geopriv:held:dep</t>
<t hangText="Registrant Contact:">IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).</t>
<t hangText="XML:">
<figure>
<artwork><![CDATA[
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>HELD Dependability Request Elements</title>
</head>
<body>
<h1>Namespace for HELD Dependability Request</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held:dep</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body>
</html>
END
]]></artwork>
</figure>
</t>
</list>
</t>
</section>
<section title="XML Schema Registration">
<t>This section registers an XML schema as per the guidelines in <xref target="RFC3688"/>.
<list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:schema:geopriv:held:dep</t>
<t hangText="Registrant Contact:">IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).</t>
<t hangText="Schema:">The XML for this schema can be found in <xref target="heldschema"/> of this document, between <spanx style="verb"><?xml version="1.0"?></spanx> and <spanx style="verb"></xs:schema></spanx> (inclusive).
</t>
</list>
</t>
</section>
</section>
<section anchor="ack" title="Acknowledgements">
<t>The authors would like to acknowledge the contribution of the GEOPRIV WG; the L7 design team; Hannes Tschofenig and Henning Schulzrinne.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC3076;
&RFC3275;
&RFC4119;
&RFC5687;
&RFC3548;
&RFC3863;
&RFC4479;
&RFC2119;
<reference anchor="X509v3">
<front>
<title>Information Technology - Open Systems Interconnection - The Directory Authentication Framework</title>
<author>
<organization>ITU-T Recommendation</organization>
</author>
<date year="1997"/>
</front>
<seriesInfo name="ISO/IEC" value="9594-8:1997"/>
</reference>
&W3C.REC-xmlschema-1-20041028;
<!--
<reference anchor="RelaxNG" target="http://relaxng.org/compact.html">
<front>
<title>RELAX NG Compact Syntax</title>
<author initials="J." surname="Clark" fullname="James Clark" role="editor">
<organization></organization>
</author>
<date day="21" month="Nov" year="2002"/>
</front>
<seriesInfo name="OASIS" value="relax-ng/compact"/>
<format type="HTML" target="http://relaxng.org/compact.html"/>
</reference>
-->
&RFC5985;
</references>
<references title="Informative References">
&RFC3688;
&RFC3693;
&RFC5246;
&I-D.ietf-geopriv-arch;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 23:52:04 |