[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07                                       
GEOPRIV                                                       M. Thomson
Internet-Draft                                           J. Winterbottom
Intended status: Standards Track                                  Andrew
Expires: August 26, 2007                               February 22, 2007


          Digital Signature Methods for Location Dependability
          draft-thomson-geopriv-location-dependability-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 26, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).














Thomson & Winterbottom   Expires August 26, 2007                [Page 1]


Internet-Draft           Location Dependability            February 2007


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.











































Thomson & Winterbottom   Expires August 26, 2007                [Page 2]


Internet-Draft           Location Dependability            February 2007


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  . . . . . . . . . . . . . .  7
     3.3.  Signature Algorithms . . . . . . . . . . . . . . . . . . .  9
     3.4.  LIS/Signer Identification  . . . . . . . . . . . . . . . .  9
   4.  Limited Validity . . . . . . . . . . . . . . . . . . . . . . . 10
     4.1.  Validity Elements  . . . . . . . . . . . . . . . . . . . . 10
   5.  Signing for a User . . . . . . . . . . . . . . . . . . . . . . 11
     5.1.  The 'entity' Attribute . . . . . . . . . . . . . . . . . . 11
     5.2.  Target Identity  . . . . . . . . . . . . . . . . . . . . . 12
     5.3.  Protecting User Anonymity  . . . . . . . . . . . . . . . . 12
     5.4.  Authenticated Identity . . . . . . . . . . . . . . . . . . 13
     5.5.  Multiple Identity Attack . . . . . . . . . . . . . . . . . 13
   6.  Target Identity Element  . . . . . . . . . . . . . . . . . . . 14
     6.1.  Identity Types . . . . . . . . . . . . . . . . . . . . . . 14
     6.2.  Identity Hashing . . . . . . . . . . . . . . . . . . . . . 14
     6.3.  Authentication Indicator . . . . . . . . . . . . . . . . . 15
   7.  Signature Validation . . . . . . . . . . . . . . . . . . . . . 16
   8.  Code and Examples  . . . . . . . . . . . . . . . . . . . . . . 17
     8.1.  Dependability Data Schema  . . . . . . . . . . . . . . . . 17
     8.2.  PIDF-LO Transforms . . . . . . . . . . . . . . . . . . . . 18
       8.2.1.  PIDF-LO Tuple-only Transform . . . . . . . . . . . . . 19
       8.2.2.  PIDF-LO Selective Transform  . . . . . . . . . . . . . 20
     8.3.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . 21
   9.  Location Reference Attribution . . . . . . . . . . . . . . . . 25
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 26
     10.1. Signature Rules  . . . . . . . . . . . . . . . . . . . . . 26
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
     11.1. URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:pidf:geopriv10:dsig . . . . . . . . 27
     11.2. XML Schema Registration  . . . . . . . . . . . . . . . . . 27
     11.3. URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:pidf:geopriv10:dsig:identity  . . . 28
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 30
     13.2. Informative References . . . . . . . . . . . . . . . . . . 30
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
   Intellectual Property and Copyright Statements . . . . . . . . . . 32




Thomson & Winterbottom   Expires August 26, 2007                [Page 3]


Internet-Draft           Location Dependability            February 2007


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 26, 2007                [Page 4]


Internet-Draft           Location Dependability            February 2007


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 hope to address all
   possible cases of fraud.  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 26, 2007                [Page 5]


Internet-Draft           Location Dependability            February 2007


   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.  Location
   protocols that use TLS [RFC4346] are able to meet this requirement.
   Confidentiality from third parties and integrity protection are
   required for all location using-protocols [RFC3693].

2.3.  Signing Location Information

   A digital signature provides data integrity and authentication of the
   source of 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.























Thomson & Winterbottom   Expires August 26, 2007                [Page 6]


Internet-Draft           Location Dependability            February 2007


3.  PIDF-LO Signature

   A location recipient can use the signature on a location object to
   authenticate the identity of the LIS.  This is done through the
   certificate that the LIS attaches with the signature.  The signature
   also ensures that the contents have not been modified since the LIS
   signed the location object.

   It is important to specify the semantics of a certificate of this
   nature.  In essence, information that is signed SHOULD be verifiable
   by the LIS.  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

   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
   unsigned data are stripped out.  This is particularly important when
   the signature rules (Section 10.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:





Thomson & Winterbottom   Expires August 26, 2007                [Page 7]


Internet-Draft           Location Dependability            February 2007


   presence (urn:ietf:params:xml:ns:pidf):  The root element of a
      presence document, the "presence" element, is signed.  The
      "entity" attribute is also signed.  The "entity" attribute SHOULD
      contain 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.

   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.  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
      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.

   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 8.2.  The first is a
   selective transform that only selects the elements listed above.  The
   second simply selects the enveloping tuple.  The LIS MAY choose not
   to use either transform, but in doing so, all unverified elements
   MUST be removed from the signed document.





Thomson & Winterbottom   Expires August 26, 2007                [Page 8]


Internet-Draft           Location Dependability            February 2007


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 8.2.1), as identified by the URN
      "urn:ietf:params:xml:ns:pidf:geopriv10:dsig#tuple" and the
      selective transform (Section 8.2.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,
   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 LIS MUST include an X.509v3 certificate in the signature.  This
   can be either by including an "X509Certificate" element, or by
   referencing another certificate.

   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.

   The LIS SHOULD 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 26, 2007                [Page 9]


Internet-Draft           Location Dependability            February 2007


4.  Limited Validity

   The simplest attack to address is the Time Shifting attack.  The LIS
   can specify a limited time period where the location information can
   be considered valid.  Applying a signature ensures that the
   information is not tampered with.

   A known limitation of this method is that the information could
   become invalid at any time after the LIS signs the document.  Once
   location is generated, the Target can move at any time, thereby
   invalidating the location object.  Therefore, the LIS SHOULD make the
   time period covered by the signature as short as possible to limit
   the impact of such movement.  The LIS can base any chosen period on
   any knowledge it has about the mobility or current speed of the
   Target.

   Location recipients MAY choose to implement a minimum age policy for
   locations, choosing to further restrict the validity interval to
   limit the chances of this occurring.  It is RECOMMENDED that the
   "from" element is used in this case, since the LIS is expected to
   validate location before it signs location information.

4.1.  Validity Elements

   A "validity" element is defined with two sub-elements, "from" and
   "until".

   The "from" element contains the time that the LIS signs the location
   information.  Note that 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, it is RECOMMENDED that this period
   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 26, 2007               [Page 10]


Internet-Draft           Location Dependability            February 2007


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 LIS does not necessarily know this
   identity.  Nor does the LIS necessarily have the means to
   authenticate the Target.

   It is RECOMMENDED that this field be generated by the LIS.  The LIS
   SHOULD construct an "unlinked pseudonym" for the Target that does not
   contain any possible identifying information for 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.

   Presentity identifiers can be reused for the same Target, provided
   that the LIS is able to verify that the Target is the same.  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 the the Target can initiate a
   new session to ensure that a new identifier is generated and thereby
   ensure that their previous and current positions cannot be correlated
   using the presentity identifier.

   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 "entity" field.  These conditions are hard to
   meet, which leads to two alternative means of including Target
   identity, described in the following sections.



Thomson & Winterbottom   Expires August 26, 2007               [Page 11]


Internet-Draft           Location Dependability            February 2007


5.2.  Target Identity

   The unlinked pseudonym used by the LIS acts as an anonymous
   identifier to a location recipient.  The only information that this
   provides 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
   compares a hash of the identity to the hash that is included in the
   location object to verify that the identity matches.







Thomson & Winterbottom   Expires August 26, 2007               [Page 12]


Internet-Draft           Location Dependability            February 2007


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.

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.  However, to prevent an
   attack where a user requests large numbers of location objects with
   different identity information, the 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 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 26, 2007               [Page 13]


Internet-Draft           Location Dependability            February 2007


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 26, 2007               [Page 14]


Internet-Draft           Location Dependability            February 2007


   URI:  For the URI type, the input to the hash algorithm is the UTF-8
      bytes of the URI.

   X.509:  For the X.509 type, the input to the hash algorithm is the
      binary value of the certificate; that is, after the base64
      encoding [RFC2045] is decoded.

   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 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 26, 2007               [Page 15]


Internet-Draft           Location Dependability            February 2007


7.  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 sender matches the
       identity in the location object, or that a hash of this identity
       matches the hashed identity in the location object.

   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
   contained valid signatures.  Similarly, un-authenticated calls could
   be given similar treatment.



Thomson & Winterbottom   Expires August 26, 2007               [Page 16]


Internet-Draft           Location Dependability            February 2007


8.  Code and Examples

8.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:annotation>
       <xs:appinfo
           source="urn:ietf:params:xml:schema:pidf:geopriv10:dsig">
         GEOPRIV PIDF-LO Dependability 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 PIDF-LO.
       </xs:documentation>
     </xs:annotation>

     <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"/>



Thomson & Winterbottom   Expires August 26, 2007               [Page 17]


Internet-Draft           Location Dependability            February 2007


     <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:attribute name="authenticated" type="xs:boolean"
                         default="false"/>

         </xs:extension>
       </xs:simpleContent>
     </xs:complexType>

   </xs:schema>

8.2.  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 26, 2007               [Page 18]


Internet-Draft           Location Dependability            February 2007


8.2.1.  PIDF-LO Tuple-only Transform

   The following XPath filter [RFC3275] selects the first "tuple"
   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">

   <!-- The 'tuple' element and all decendants -->
   (count(ancestor-or-self::pidf:tuple[1]
          | here()/ancestor::pidf:tuple[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>



















Thomson & Winterbottom   Expires August 26, 2007               [Page 19]


Internet-Draft           Location Dependability            February 2007


8.2.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
   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".








































Thomson & Winterbottom   Expires August 26, 2007               [Page 20]


Internet-Draft           Location Dependability            February 2007


   <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">

   <!-- 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)
       and (self::pidf:tuple or self::pidf:status
            or ancestor-or-self::pidf:timestamp
            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)

                 and (self::pidf:tuple or self::pidf:status
                      or self::gp:geopriv or self::gp:usage-rules))
           ])
     </dsig:XPath>
   </dsig:Transform>

8.3.  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"?>



Thomson & Winterbottom   Expires August 26, 2007               [Page 21]


Internet-Draft           Location Dependability            February 2007


   <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>



Thomson & Winterbottom   Expires August 26, 2007               [Page 22]


Internet-Draft           Location Dependability            February 2007


                 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>












Thomson & Winterbottom   Expires August 26, 2007               [Page 23]


Internet-Draft           Location Dependability            February 2007


   Once the signature has been checked, the following document is
   extracted.  Only these elements have been included in the signature.
   Whitespace has been added to this example to improve readability.

   <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 26, 2007               [Page 24]


Internet-Draft           Location Dependability            February 2007


9.  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 be
   permitted by the usage rules).

   Similar constraints apply to a location object that is retrieved by
   reference as those that apply to a signed location object (that is, a
   by-value 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
   LIS MAY include validity elements to provide an indication of the
   limits of the objects validity.

























Thomson & Winterbottom   Expires August 26, 2007               [Page 25]


Internet-Draft           Location Dependability            February 2007


10.  Security Considerations

   This entire document is about the security properties of location
   objects.

10.1.  Signature Rules

   Three rules that relate to the treatment of signed information are
   described in [RFC3275].  These rules are _Only What is Signed is
   Secure_, _Only What is "Seen" Should be Signed_, and _"See" What is
   Signed_.  These should apply when a location recipient evaluates and
   uses a location object.  These especially apply when displaying
   location information to a user.






































Thomson & Winterbottom   Expires August 26, 2007               [Page 26]


Internet-Draft           Location Dependability            February 2007


11.  IANA Considerations

   This section registers the dependability elements schema and related
   namespace URNs with IANA.

11.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.

11.2.  XML Schema Registration

   This section registers an XML schema as per the guidelines in
   [RFC3688].







Thomson & Winterbottom   Expires August 26, 2007               [Page 27]


Internet-Draft           Location Dependability            February 2007


   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 8.1 of this
      document, between "<?xml version="1.0"?>" and "</xs:schema>"
      (inclusive).

11.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 26, 2007               [Page 28]


Internet-Draft           Location Dependability            February 2007


12.  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 26, 2007               [Page 29]


Internet-Draft           Location Dependability            February 2007


13.  References

13.1.  Normative References

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [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-00 (work in
              progress), January 2007.

   [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]
              Beech, D., Thompson, H., Maloney, M., and N. Mendelsohn,
              "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>.

13.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.

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.



Thomson & Winterbottom   Expires August 26, 2007               [Page 30]


Internet-Draft           Location Dependability            February 2007


Authors' Addresses

   Martin Thomson
   Andrew
   PO Box U40
   Wollongong University Campus, NSW  2500
   AU

   Phone: +61 2 4221 2915
   Email: martin.thomson@andrew.com
   URI:   http://www.andrew.com/


   James Winterbottom
   Andrew
   PO Box U40
   Wollongong University Campus, NSW  2500
   AU

   Phone: +61 2 4221 2938
   Email: james.winterbottom@andrew.com
   URI:   http://www.andrew.com/





























Thomson & Winterbottom   Expires August 26, 2007               [Page 31]


Internet-Draft           Location Dependability            February 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Thomson & Winterbottom   Expires August 26, 2007               [Page 32]