GEOPRIV M. Thomson
Internet-Draft J. Winterbottom
Intended status: Standards Track Andrew
Expires: August 1, 2010 January 28, 2010
Digital Signature Methods for Location Dependability
draft-thomson-geopriv-location-dependability-05
Abstract
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.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 1, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Thomson & Winterbottom Expires August 1, 2010 [Page 1]
Internet-Draft Location Dependability January 2010
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Basic Countermeasures . . . . . . . . . . . . . . . . . . 6
2.3. Signing Location Information . . . . . . . . . . . . . . . 6
3. PIDF-LO Signature . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Signature Design . . . . . . . . . . . . . . . . . . . . . 7
3.2. Signed Elements and Semantics . . . . . . . . . . . . . . 8
3.3. Signature Algorithms . . . . . . . . . . . . . . . . . . . 9
3.4. LIS/Signer Identification . . . . . . . . . . . . . . . . 10
4. Limited Validity . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Validity Elements . . . . . . . . . . . . . . . . . . . . 11
5. Signing for a User . . . . . . . . . . . . . . . . . . . . . . 12
5.1. The 'entity' Attribute . . . . . . . . . . . . . . . . . . 12
5.2. Target Identity . . . . . . . . . . . . . . . . . . . . . 13
5.3. Protecting User Anonymity . . . . . . . . . . . . . . . . 13
5.4. Authenticated Identity . . . . . . . . . . . . . . . . . . 14
5.5. Multiple Identity Attack . . . . . . . . . . . . . . . . . 14
6. Target Identity Element . . . . . . . . . . . . . . . . . . . 16
6.1. Identity Types . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Identity Hashing . . . . . . . . . . . . . . . . . . . . . 16
6.3. Authentication Indicator . . . . . . . . . . . . . . . . . 17
7. Requesting Dependable Location Information using HELD . . . . 18
8. Signature Validation . . . . . . . . . . . . . . . . . . . . . 20
9. Code and Examples . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Dependability Data Schema . . . . . . . . . . . . . . . . 22
9.2. HELD Dependability Request Schema . . . . . . . . . . . . 23
9.3. PIDF-LO Transforms . . . . . . . . . . . . . . . . . . . . 24
9.3.1. PIDF-LO Tuple-only Transform . . . . . . . . . . . . . 25
9.3.2. PIDF-LO Selective Transform . . . . . . . . . . . . . 25
9.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 27
10. Location Reference Attribution . . . . . . . . . . . . . . . . 30
11. Security Considerations . . . . . . . . . . . . . . . . . . . 31
11.1. Signature Rules . . . . . . . . . . . . . . . . . . . . . 31
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
12.1. URN Sub-Namespace Registration for
Thomson & Winterbottom Expires August 1, 2010 [Page 2]
Internet-Draft Location Dependability January 2010
urn:ietf:params:xml:ns:pidf:geopriv10:dsig . . . . . . . . 32
12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 32
12.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:pidf:geopriv10:dsig:identity . . . 33
12.4. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:dep . . . . . . . . . 34
12.5. XML Schema Registration . . . . . . . . . . . . . . . . . 34
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
14.1. Normative References . . . . . . . . . . . . . . . . . . . 36
14.2. Informative References . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
Thomson & Winterbottom Expires August 1, 2010 [Page 3]
Internet-Draft Location Dependability January 2010
1. Introduction
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.
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.
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.
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.
1.1. Terminology
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 [RFC2119].
Thomson & Winterbottom Expires August 1, 2010 [Page 4]
Internet-Draft Location Dependability January 2010
2. Goals
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.
The measures outlined in this document are designed to limit exposure
to the following attacks:
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.
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.
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.
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.
These attacks are a subset of those described in
[I-D.ietf-geopriv-l7-lcp-ps].
2.1. Non-Goals
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.
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.
Methods for determining trust in either LIS or Target are out of
scope for this document. This document only describes the means by
Thomson & Winterbottom Expires August 1, 2010 [Page 5]
Internet-Draft Location Dependability January 2010
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.
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.
2.2. Basic Countermeasures
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 [RFC3693].
Location protocols that use TLS [RFC5246] are able to meet this
requirement providing mutual authentication is adequate. HELD
[I-D.ietf-geopriv-http-location-delivery] relies on TLS for this
purpose.
2.3. Signing Location Information
A digital signature provides data integrity and attribution for the
signed information. This document describes how XML-Signature
[RFC3275] can be applied to a Presence Information Data Format -
Location Object (PIDF-LO) [RFC4119]. It also describes the benefits
of signing and how signing can be practically applied.
PIDF-LO contains a number of different units of data: location
information, time, and identity being most important in this context
[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.
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.
Thomson & Winterbottom Expires August 1, 2010 [Page 6]
Internet-Draft Location Dependability January 2010
3. PIDF-LO Signature
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.
In GEOPRIV [I-D.ietf-geopriv-arch] 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.
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.
3.1. Signature Design
[[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.]]
This document uses the XML-Signature [RFC3275] 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.
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.
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
Thomson & Winterbottom Expires August 1, 2010 [Page 7]
Internet-Draft Location Dependability January 2010
unsigned data are stripped out. This is particularly important when
the signature rules (Section 11.1) are applied.
3.2. Signed Elements and Semantics
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.
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:
presence (urn:ietf:params:xml:ns:pidf): The root element of a
presence document [RFC3863], the "presence" element, is signed.
The "entity" attribute is also signed. In most cases, the
"entity" attribute contains an identifier generated by the LIS,
see Section 5 and Section 5.3.
tuple (urn:ietf:params:xml:ns:pidf): Only the tuple that contains
location information is signed. The "id" attribute is signed to
ensure a valid PIDF-LO is produced, but no significance is
attached to its value. Likewise, the "device" and "person"
elements (in the "urn:ietf:params:xml:ns:pidf:data-model"
namespace, [RFC4479]) that contain location information need to be
included by the signature.
geopriv (urn:ietf:params:xml:ns:pidf:geopriv10): The "geopriv"
element is signed, along with select elements within it.
location-info (urn:ietf:params:xml:ns:pidf:geopriv10): The most
important element of the PIDF-LO, "location-info" contains
location data. This element and all its contents are signed.
usage-rules (urn:ietf:params:xml:ns:pidf:geopriv10): Usage rules are
included to ensure the validity of the PIDF-LO. An empty
"usage-rules" 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 [RFC3693]) has
provided values. No decisions can be made on the unsigned content
of usage rules.
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
Thomson & Winterbottom Expires August 1, 2010 [Page 8]
Internet-Draft Location Dependability January 2010
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.
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
[RFC3863] or [RFC4479] is always signed.
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 Section 4,
Section 5.
This document defines two transforms that can be applied to a PIDF-LO
in order to limit what is signed Section 9.3. The first is a
selective transform that only selects the elements listed above. The
second simply selects the enveloping "tuple", "device" or
"person"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.
3.3. Signature Algorithms
As specified in RFC 3275 [RFC3275], implementations of this
specification MUST provide the following algorithms:
digest algorithm: The SHA1 digest, as identified by the URN
"http://www.w3.org/2000/09/xmldsig#sha1".
signature algorithm: DSA with SHA1, as identified by the URN
"http://www.w3.org/2000/09/xmldsig#dsa-sha1".
canonicalization method: Canonical XML [RFC3076], as identified by
the URN "http://www.w3.org/TR/2001/REC-xml-c14n-20010315".
transforms: The enveloped signature transform, as identified by the
URN "http://www.w3.org/2000/09/xmldsig#enveloped-signature"; and
the transforms defined in this document: the tuple-only transform
(Section 9.3.1), as identified by the URN
"urn:ietf:params:xml:ns:pidf:geopriv10:dsig#tuple" and the
selective transform (Section 9.3.2), as identified by the URN
"urn:ietf:params:xml:ns:pidf:geopriv10:dsig#selective".
It is also RECOMMENDED that the PKCS1 (RSA-SHA1) signature algorithm,
Thomson & Winterbottom Expires August 1, 2010 [Page 9]
Internet-Draft Location Dependability January 2010
as idenfied by "http://www.w3.org/2000/09/xmldsig#rsa-sha1" is also
supported.
3.4. LIS/Signer Identification
RFC 3275 [RFC3275] describes a number of methods for describing the
key used to sign the document. For the purpose of signing a location
object, the "KeyInfo" element MUST be provided in the "Signature"
element.
The signer MUST include an X.509v3 certificate in the signature.
This can be either by including an "X509Certificate" element, or by
referencing another certificate in the same docuemnt.
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.
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 "RetrievalMethod" element. The
scheme for the the RetrievalMethod URI MUST be "https:".
Thomson & Winterbottom Expires August 1, 2010 [Page 10]
Internet-Draft Location Dependability January 2010
4. Limited Validity
The simplest attack to address is the Time Shifting attack. The
"timestamp" element provides a basic indication of when location
information was created.
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.
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.
The time constraints can be considered guidelines provided by a
signer. Recipients can choose instead to base decisions purely on
the "timestamp" element. Location recipients MAY choose to implement
a minimum age policy for locations. If present, either the "from"
element or the "timestamp" 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.
4.1. Validity Elements
A "validity" element is defined with two sub-elements, "from" and
"until".
The "from" 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 "timestamp"
element.
The "until" 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.
The signature MUST NOT be considered valid if the current time is
outside of the interval specified in these elements.
Thomson & Winterbottom Expires August 1, 2010 [Page 11]
Internet-Draft Location Dependability January 2010
5. Signing for a User
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.
5.1. The 'entity' Attribute
The "entity" 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.
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 "pres:" URI randomly, using a random
sequence of characters and the host name of the LIS (e.g.,
"pres:f6pc98w1pd49s0p@lis.example.com").
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.
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.
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.
This does not prevent the use of a "real" presentity in this field.
Thomson & Winterbottom Expires August 1, 2010 [Page 12]
Internet-Draft Location Dependability January 2010
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 "entity" field. These conditions are hard to
meet, which leads to two alternative means of including Target
identity, described in the following sections.
5.2. Target Identity
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.
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.
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.
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.
5.3. Protecting User Anonymity
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.
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.
The location recipient authenticates the Target's identity, then
Thomson & Winterbottom Expires August 1, 2010 [Page 13]
Internet-Draft Location Dependability January 2010
compares a hash of the identity to the hash that is included in the
location object to verify that the identity matches.
5.4. Authenticated Identity
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.
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.
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.
5.5. Multiple Identity Attack
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.
In some scenarios, multiple identities can be valid. Examples in
Section 3 of [I-D.ietf-geopriv-l7-lcp-ps] 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.
However, to prevent an attack where a user requests large numbers of
location objects with different identity information, a LIS SHOULD
limit the number of identities that can be served from any particular
network point. Authenticating the Targets in this scenario could
provide some additional surety that each is legitimate. If multiple
Thomson & Winterbottom Expires August 1, 2010 [Page 14]
Internet-Draft Location Dependability January 2010
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.
Thomson & Winterbottom Expires August 1, 2010 [Page 15]
Internet-Draft Location Dependability January 2010
6. Target Identity Element
This document defines an XML "identity" element that can be used to
include identity information in a PIDF-LO. This element is used in
addition to a randomized "entity" attribute for several reasons: a
randomized "entity" attribute can be used to detect replays; the
identity is not necessarily authenticated; and the content can be
other than a presentity identifier.
6.1. Identity Types
The content of this element is dependent on the type associated with
the identifier. The "type" attribute is used to define the nature of
the identity that is included. Two values are provided by default:
URI: A value of
"urn:ietf:params:xml:ns:pidf:geopriv10:dsig:identity#uri" 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.
An X.509 certificate: A value of
"urn:ietf:params:xml:ns:pidf:geopriv10:dsig:identity#x509"
indicates that the contents are an X.509v3 certificate [X509v3],
in the format described in [RFC3275] for "X509Certificate".
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.
6.2. Identity Hashing
To allow for anonymity, the content of the "identity" element MAY be
hashed and the hash value included in this element instead. The
"hash" attribute indicates whether the value has been hashed. A
reserved value of "##none" indicates that the actual value is
included. Otherwise, the attribute includes a hash algorithm
identifier, as defined in [RFC3275]. The SHA1 algorithm MUST be
supported; this is identified by the URN
"http://www.w3.org/2000/09/xmldsig#sha1".
Each different identity type requires a procedure for obtaining the
bytes that are hashed.
Thomson & Winterbottom Expires August 1, 2010 [Page 16]
Internet-Draft Location Dependability January 2010
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.
X.509: For the X.509 type, the input to the hash algorithm is the
distinguished encoding rules (DER) encoded value of the
certificate.
If the "hash" attribute is present and set to a value other than
"##none", the contents of the "identity" element are always the
base64 encoded [RFC3548] result from the hash function.
6.3. Authentication Indicator
If the LIS is able to authenticate the Target, the LIS can indicate
this in the "authenticated" attribute.
This indicator can be used irrespective of the value of the "hash"
attribute. This indicates to the location recipient that user
identity included in the "identity" element was authenticated by the
LIS.
Thomson & Winterbottom Expires August 1, 2010 [Page 17]
Internet-Draft Location Dependability January 2010
7. Requesting Dependable Location Information using HELD
HELD [I-D.ietf-geopriv-http-location-delivery] is used by Devices to
request location information. This section outlines parameters that
can be included in HELD requests to ensure that location. These
parameters MAY also be included by the Device in HELD context
[I-D.winterbottom-geopriv-held-context] messages. Requesting
dependable location information from a context provides less direct
benefit to a Location Recipient that is requesting location
information directly from a LIS.
Inclusion of a "dependability" 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.
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.
The Device SHOULD include an "identity" element, which indicates what
value is to be included in the "identity" element of the signed
PIDF-LO. Location Recipients MUST NOT include this parameter when
requesting location information from a location URI. The "identity"
element is identical to that included in the PIDF-LO (see Section 6)
except that it does not include the "authenticated" attribute.
The following sample HELD location request includes a dependency
element with identity information.
<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>
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
Thomson & Winterbottom Expires August 1, 2010 [Page 18]
Internet-Draft Location Dependability January 2010
by the LIS or by Location Recipients. Including hashed information
ensures that identity information is not revealed to the LIS.
Thomson & Winterbottom Expires August 1, 2010 [Page 19]
Internet-Draft Location Dependability January 2010
8. Signature Validation
A location recipient performs the following steps to validate a
signed location object:
1. Authenticate the entity that provided the location information
(the sender).
2. Check the integrity of the digital certificate.
3. Extract the identity of the LIS from the digital certificate.
4. Remove all unsigned components from the location object.
5. Ensure the validity interval from the location object covers the
present time.
6. 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.
Once this process is complete, the location recipient has the
following information upon which to base any policy decision:
o Whether the location object was signed.
o Whether the signature on the location object was valid.
o The identity of the sender.
o The identity of the LIS.
o Whether the LIS authenticated the sender in generating the
location object.
o The presentity identifier generated by the LIS that distinguishes
this location object.
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.
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
Thomson & Winterbottom Expires August 1, 2010 [Page 20]
Internet-Draft Location Dependability January 2010
contained valid signatures. Similarly, un-authenticated calls could
be given similar treatment.
Thomson & Winterbottom Expires August 1, 2010 [Page 21]
Internet-Draft Location Dependability January 2010
9. Code and Examples
9.1. Dependability Data Schema
The following XML Schema [W3C.REC-xmlschema-1-20041028] defines the
"dependability" element. This element is intended for use in a
PIDF-LO within a "tuple".
<?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"/>
Thomson & Winterbottom Expires August 1, 2010 [Page 22]
Internet-Draft Location Dependability January 2010
</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>
9.2. HELD Dependability Request Schema
The following XML Schema [W3C.REC-xmlschema-1-20041028] defines the
"dependability" element for inclusion in HELD requests.
<?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>
Thomson & Winterbottom Expires August 1, 2010 [Page 23]
Internet-Draft Location Dependability January 2010
</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>
9.3. PIDF-LO Transforms
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.
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.
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.
Thomson & Winterbottom Expires August 1, 2010 [Page 24]
Internet-Draft Location Dependability January 2010
9.3.1. PIDF-LO Tuple-only Transform
The following XPath filter [RFC3275] selects the first "tuple",
"device" or "person" descendant of the signature element and all its
contents. The "presence" element that is the immediate parent of the
tuple is also selected. This transform is identified by the URN
"urn:ietf:params:xml:ns:pidf:geopriv10:dsig#tuple".
<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>
9.3.2. PIDF-LO Selective Transform
Similar to the tuple-only transform, this transform selects a single
"tuple" element and its parent "presence" element. In contrast, this
transform only selects those elements listed in Section 3.2. This
transform allows a Target to make adjustments to non-critical
Thomson & Winterbottom Expires August 1, 2010 [Page 25]
Internet-Draft Location Dependability January 2010
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
"usage-rules" element and other PIDF data, like contact information.
This transform is identified by the URN
"urn:ietf:params:xml:ns:pidf:geopriv10:dsig#selective".
<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)
Thomson & Winterbottom Expires August 1, 2010 [Page 26]
Internet-Draft Location Dependability January 2010
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>
9.4. Example
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.]]
<?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
Thomson & Winterbottom Expires August 1, 2010 [Page 27]
Internet-Draft Location Dependability January 2010
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
Thomson & Winterbottom Expires August 1, 2010 [Page 28]
Internet-Draft Location Dependability January 2010
</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>
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.
<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>
Thomson & Winterbottom Expires August 1, 2010 [Page 29]
Internet-Draft Location Dependability January 2010
10. Location Reference Attribution
Digital signatures are less useful when location is provided by
reference. In this case, the location recipient acquires location
information directly from the LIS.
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).
For use with location by reference, the "dependability" 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.
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.
Validity elements are less critical, since it can be assumed that the
LIS does not provide location information unless it is current. The
PIDF "timestamp" element is sufficient to indicate when location
information was generated.
Thomson & Winterbottom Expires August 1, 2010 [Page 30]
Internet-Draft Location Dependability January 2010
11. Security Considerations
This entire document is about the security properties of location
objects.
11.1. Signature Rules
Three rules that relate to the treatment of signed information are
described in [RFC3275]. These rules are:
o Only What is Signed is Secure
o Only What is "Seen" Should be Signed
o "See" What is Signed
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.
Thomson & Winterbottom Expires August 1, 2010 [Page 31]
Internet-Draft Location Dependability January 2010
12. IANA Considerations
This section registers the dependability elements schema and related
namespace URNs with IANA.
12.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:pidf:geopriv10:dsig
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:pidf:geopriv10:dsig", as per the guidelines
in [RFC3688].
URI: urn:ietf:params:xml:ns:pidf:geopriv10:dsig
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>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
Note: Two fragment identifiers ("#tuple" and "#selective") are added
to this URN to identify the two transforms defined in RFCXXXX.
12.2. XML Schema Registration
This section registers an XML schema as per the guidelines in
[RFC3688].
Thomson & Winterbottom Expires August 1, 2010 [Page 32]
Internet-Draft Location Dependability January 2010
URI: urn:ietf:params:xml:schema:pidf:geopriv10:dsig
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found in Section 9.1 of this
document, between "<?xml version="1.0"?>" and "</xs:schema>"
(inclusive).
12.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:pidf:geopriv10:dsig:identity
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:pidf:geopriv10:dsig:identity", as per the
guidelines in [RFC3688].
URI: urn:ietf:params:xml:ns:pidf:geopriv10:dsig:identity
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>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
Note: Two fragment identifiers ("#uri" and "#x509") are added to
this URN to identify the two types of identity defined in RFCXXXX.
Thomson & Winterbottom Expires August 1, 2010 [Page 33]
Internet-Draft Location Dependability January 2010
12.4. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:dep
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:held:dep", as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:held:dep
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>HELD 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
12.5. XML Schema Registration
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:geopriv:held:dep
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@andrew.com).
Schema: The XML for this schema can be found in Section 9.2 of this
document, between "<?xml version="1.0"?>" and "</xs:schema>"
(inclusive).
Thomson & Winterbottom Expires August 1, 2010 [Page 34]
Internet-Draft Location Dependability January 2010
13. Acknowledgements
The authors would like to acknowledge the contribution of the GEOPRIV
WG; the L7 design team; Hannes Tschofenig and Henning Schulzrinne.
Thomson & Winterbottom Expires August 1, 2010 [Page 35]
Internet-Draft Location Dependability January 2010
14. References
14.1. Normative References
[RFC3076] Boyer, J., "Canonical XML Version 1.0", RFC 3076,
March 2001.
[RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
Language) XML-Signature Syntax and Processing", RFC 3275,
March 2002.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[I-D.ietf-geopriv-l7-lcp-ps]
Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol; Problem Statement and
Requirements", draft-ietf-geopriv-l7-lcp-ps-10 (work in
progress), July 2009.
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003.
[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
W., and J. Peterson, "Presence Information Data Format
(PIDF)", RFC 3863, August 2004.
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479,
July 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[X509v3] ITU-T Recommendation, "Information Technology - Open
Systems Interconnection - The Directory Authentication
Framework", ISO/IEC 9594-8:1997, 1997.
[W3C.REC-xmlschema-1-20041028]
Maloney, M., Thompson, H., Mendelsohn, N., and D. Beech,
"XML Schema Part 1: Structures Second Edition", World Wide
Web Consortium Recommendation REC-xmlschema-1-20041028,
October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[I-D.ietf-geopriv-http-location-delivery]
Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
"HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-16 (work in
Thomson & Winterbottom Expires August 1, 2010 [Page 36]
Internet-Draft Location Dependability January 2010
progress), August 2009.
[I-D.winterbottom-geopriv-held-context]
Winterbottom, J., Tschofenig, H., and M. Thomson,
"Location URI Contexts in HTTP-Enabled Location Delivery
(HELD)", draft-winterbottom-geopriv-held-context-05 (work
in progress), October 2009.
14.2. Informative References
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[I-D.ietf-geopriv-lis-discovery]
Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)",
draft-ietf-geopriv-lis-discovery-13 (work in progress),
December 2009.
[I-D.ietf-geopriv-arch]
Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications",
draft-ietf-geopriv-arch-01 (work in progress),
October 2009.
Thomson & Winterbottom Expires August 1, 2010 [Page 37]
Internet-Draft Location Dependability January 2010
Authors' Addresses
Martin Thomson
Andrew
Andrew Building (39)
Wollongong University Campus
Northfields Avenue
Wollongong, NSW 2522
Australia
Phone: +61 2 4221 2915
Email: martin.thomson@andrew.com
URI: http://www.andrew.com/
James Winterbottom
Andrew
Andrew Building (39)
Wollongong University Campus
Northfields Avenue
Wollongong, NSW 2522
Australia
Phone: +61 2 4221 2938
Email: james.winterbottom@andrew.com
URI: http://www.andrew.com/
Thomson & Winterbottom Expires August 1, 2010 [Page 38]