[Geopriv] review of <draft-thomson-domain-auth-01.txt>
"Tschofenig, Hannes" <hannes.tschofenig@siemens.com> Wed, 27 July 2005 13:05 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxlbA-0000nI-2h; Wed, 27 Jul 2005 09:05:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxlb3-0000mJ-SV for geopriv@megatron.ietf.org; Wed, 27 Jul 2005 09:05:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25559 for <geopriv@ietf.org>; Wed, 27 Jul 2005 09:05:15 -0400 (EDT)
Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxm6J-0004Mm-7S for geopriv@ietf.org; Wed, 27 Jul 2005 09:37:36 -0400
Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j6RD57Oo025254 for <geopriv@ietf.org>; Wed, 27 Jul 2005 15:05:07 +0200
Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j6RD570B030563 for <geopriv@ietf.org>; Wed, 27 Jul 2005 15:05:07 +0200
Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.146]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 27 Jul 2005 15:08:34 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 27 Jul 2005 15:05:06 +0200
Message-ID: <ECDC9C7BC7809340842C0E7FCF48C393421F32@MCHP7IEA.ww002.siemens.net>
Thread-Topic: review of <draft-thomson-domain-auth-01.txt>
Thread-Index: AcWSq88zc+yQ1SLNRw69CiH/aQy/NA==
From: "Tschofenig, Hannes" <hannes.tschofenig@siemens.com>
To: geopriv@ietf.org
X-OriginalArrivalTime: 27 Jul 2005 13:08:34.0953 (UTC) FILETIME=[4B8D9F90:01C592AC]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b07d3562102db4977d20bd3dd0ddf804
Content-Transfer-Encoding: quoted-printable
Subject: [Geopriv] review of <draft-thomson-domain-auth-01.txt>
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
Sender: geopriv-bounces@ietf.org
Errors-To: geopriv-bounces@ietf.org
hi martin, hi james i have a few questions regarding the content of this document. as a high-level statement i think that - the terminology needs to be cleaned-up and aligned with the geopriv terminology to improve readability. - the motivation for XML-DSIG and the individual signing of elements needs to be given. just signing everything would be much simpler. using an s/mime computed signature over the entire pdif-lo would also be better aligned with the current geopriv work. - a motivation for signing location information by the "network" needs to be provided (as we discussed during the interim meeting). i have only reviewed some parts of the document since the answers for the questions raised above have significant impact on the content of the document. please find some minor comments inline. ciao hannes GEOPRIV WG M. Thomson Internet-Draft J. Winterbottom Expires: December 30, 2005 Nortel June 28, 2005 Domain Authorization for PIDF-LO draft-thomson-domain-auth-01.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 December 30, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes a standard method for digitally signing Presence Information Data Format Location Object (PIDF-LO) documents using a subset of the XML Digital Signature specification. A digital signature enables the user of a signed PIDF-LO document to attribute that information to an authorized source within the domain of the target entity. [hannes] this sentence is difficult to understand. A schema is defined for including a domain authorization element in the PIDF-LO and a set of XML Path Language (XPath) filters for selecting the correct elements for signing. Thomson & Winterbottom Expires December 30, 2005 [Page 1] Internet-Draft Domain Auth. June 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Conventions used in this document . . . . . . . . . . . . 3 2. The Domain Authorization Element . . . . . . . . . . . . . . . 5 2.1 'expires' attribute . . . . . . . . . . . . . . . . . . . 5 3. Signature Elements . . . . . . . . . . . . . . . . . . . . . . 6 3.1 PIDF-LO Document Transform . . . . . . . . . . . . . . . . 6 3.2 Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3 Signature Key Data . . . . . . . . . . . . . . . . . . . . 7 4. XML Definitions . . . . . . . . . . . . . . . . . . . . . . . 9 4.1 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2 XPath Filter . . . . . . . . . . . . . . . . . . . . . . . 10 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7.1 URN Sub-Namespace Registration for urn:ietf:params:xml:ns:pidf:geopriv10:domain-auth . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 19 Thomson & Winterbottom Expires December 30, 2005 [Page 2] Internet-Draft Domain Auth. June 2005 1. Introduction Users of location information may desire to be able to attribute this information to an authorized entity. This entity may not have provided the information, but they must be able to vouch for its accuracy. In most cases this will mean that the trusted entity resides within the same domain, or access network, as the target entity. [hannes] i think that the only thing a network want to vouch for is that they generated location information. they cannot give any assurance about the accuracy of the provided location information (and might not even want todo that) i think that the paragraph above needs to be rewritten This specification describes a means by which a domain authority may assume responsibility for the validity of the location information provided in a Presence Information Data Format Location Object (PIDF-LO [I-D.ietf-geopriv-pidf-lo]). A standard form is described whereby a domain authority may digitally sign the PIDF-LO document. This signature ensures that a user of the PIDF-LO can verify that the presentity identified is at the described location within certain time bounds. [hannes] since the term 'user of a location information/pdif-lo' appeared several times i would like to ask what it means. additionally, i think that the signature cannot provide an assurance that a particular presentity was at a particular location. Only selected data are signed within a PIDF, allowing a user freedom to change other parts of the document without affecting the signature. [hannes] why is this necessary? A signature only applies to a single tuple element, allowing separate tuples to be unsigned, or to be signed separately. [hannes] this seems to be very heavy-weight. Elements such as notes, contact information and the privacy preferences described in [I-D.ietf-geopriv-pidf-lo] are not signed to allow for modification. The signed elements are restricted to: the presentity identifier: the entity attribute of the _presence_ element. timestamp: the timestamp associated with the location information location-info: the actual location information expires: the time at which the signature expires, this datum is added by this specification [hannes] the motivation for doing this is quite important since this introduces a certain degree of complexity, usage of XML-DSIG rather than S/MIME. 1.1 Conventions used in this document 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]. The term _presentity_ is used as defined in RFC 2778 [RFC2778]. The term _location user_ is used to refer to the entity that is consuming location information. In the context of RFC 2778 [RFC2778], the location user may be a watcher. Thomson & Winterbottom Expires December 30, 2005 [Page 3] Internet-Draft Domain Auth. June 2005 The term _domain authority_ is used to refer to the entity that assumes responsibility for the accuracy of the information provided in the PIDF-LO. Thomson & Winterbottom Expires December 30, 2005 [Page 4] Internet-Draft Domain Auth. June 2005 2. The Domain Authorization Element This specification describes a new namespace for a domain authorization element. This element contains the digital signature described in RFC 3275 [RFC3275] and an expiry time for the signature. The "domain-auth" element is added to the "tuple" element that contains the "geopriv" element. Separate "tuple" elements are signed separately. The XML Schema definition for the "domain-auth" element is included in Section 4.1. The digital signature signs the PIDF-LO document that includes only the "tuple" element that the "domain-auth" element is included within. Section 3.1 describes the specific means by which the correct elements are selected. 2.1 'expires' attribute The "expires" attribute defines the expiry time for the domain authorization provided. A user of the PIDF-LO document MUST consider the document to be unsigned beyond the expiry time. Thomson & Winterbottom Expires December 30, 2005 [Page 5] Internet-Draft Domain Auth. June 2005 3. Signature Elements The XML Signature specification [RFC3275] describes a means to sign XML documents. The "Signature" element consists of three major parts: 1. a description of the signed elements, which may be an entire document, or selected parts of a document 2. a digital signature 3. information on the key used to sign the document 3.1 PIDF-LO Document Transform Since the content of XML documents is indeterminate based on similar data sets, RFC 3275 [RFC3275] describes a set of transforms that may be applied to a document before applying a digital signature. The input PIDF-LO document MUST be canonicalized using either Canonical XML ("http://www.w3.org/TR/2001/REC-xml-c14n-20010315") or Exclusive Canonical XML ("http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/") [W3C.REC- xml-exc-c14n-20020718]. Note that both of these canonicalization methods remove comments from the source document. The signature form selected for this document is an enveloped signature. Therefore the enveloped signature transform ("http://www.w3.org/2000/09/xmldsig#enveloped-signature") MUST be applied to the document. A filter is applied to the input document in order to select the correct elements for signing. It is RECOMMENDED that the transformed document is also a valid PIDF-LO. In addition, the transform should exclude "tuple" elements other than the element that is directly signed. This ensures that other content may be included in other "tuple" elements, including other digital signatures. The following elements MUST be selected: o the "presence" element, which includes the "entity" attribute o the "location-info" element and all of its contents o the "timestamp" element associated with the signed "tuple" element Thomson & Winterbottom Expires December 30, 2005 [Page 6] Internet-Draft Domain Auth. June 2005 o the "domain-auth" element The minimum set of elements required to ensure that the signed document is a valid PIDF-LO SHOULD also be included. The XML Path Language (XPath) filter defined in Section 4.2 meets the above criteria. For convenience, and to reduce the size of a signed PIDF-LO document, this transform may be identified by the URN "urn:ietf:params:xml:ns:pidf:geopriv10:domain-auth#PIDF-LO". Note that any elements from other namespaces included within the "domain-auth" element are selected by this XPath filter. This ensures that additions to this element are covered by the digital signature. 3.2 Algorithms As recommended 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 transform defined in Section 4.2, as identified by the URN "urn:ietf:params:xml:ns:pidf:geopriv10:domain-auth#PIDF-LO". It is also RECOMMENDED that the following are also supported: signature algorithm: PKCS1 (RSA-SHA1) signature algorithm, as idenfied by "http://www.w3.org/2000/09/xmldsig#rsa-sha1". canonicalization method: Exclusive Canonical XML, as identified by the URN "http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/" [W3C.REC-xml-exc-c14n-20020718]. 3.3 Signature Key Data RFC 3275 [RFC3275] describes a number of methods for describing the key used to sign the document. For this specification, the "KeyInfo" Thomson & Winterbottom Expires December 30, 2005 [Page 7] Internet-Draft Domain Auth. June 2005 element MUST be provided in the "Signature" element. The domain authority MUST also describe a means to retrieve an X.509 certificate that includes the key used to sign the document. 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 the "X509SubjectName" element or a fragment identifier URI. A fragment identifier URI might be applicable where multiple signatures are applied to different parts of the document. External certificate sources SHOULD be described by URI only in the "RetrievalMethod" element. It is RECOMMENDED that the scheme for the RetrievalMethod URI indicates a secure protocol, such as HTTPS. The domain authority MAY include additional information in the "KeyInfo" element that could assist the location user in validating the certificate. For example a certificate chain and certificate revocation list may be added. However, this specification does not specify how the location user validates the certificate. Thomson & Winterbottom Expires December 30, 2005 [Page 8] Internet-Draft Domain Auth. June 2005 4. XML Definitions 4.1 XML Schema The following XML schema describes the "domain-auth" element. This schema defines a new namespace: "urn:ietf:params:xml:ns:pidf:geopriv10:domain-auth". <?xml version="1.0"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:domain-auth" xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:domain-auth" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" elementFormDefault="unqualified" attributeFormDefault="unqualified"> <xsd:import namespace="http://www.w3.org/2000/09/xmldsig#"/> <xsd:annotation> <xsd:documentation> This schema defines a means for providing authentication to a PIDF-LO. This schema is also accompanied by a set of transforms that should be applied to the signed PIDF-LO. </xsd:documentation> </xsd:annotation> <xsd:element name="domain-auth"> <xsd:annotation> <xsd:documentation> The domain authorization that is applied to the PIDF-LO. This element should be included within the scope of a <tuple> element. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:complexContent> <xsd:restriction base="xsd:anyType"> <xsd:sequence> <xsd:element ref="dsig:Signature"/> <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="expires" use="required" type="xsd:dateTime"> <xsd:annotation> <xsd:documentation> The expiry time associated with the authorization. Thomson & Winterbottom Expires December 30, 2005 [Page 9] Internet-Draft Domain Auth. June 2005 </xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:restriction> </xsd:complexContent> </xsd:complexType> </xsd:element> </xsd:schema> 4.2 XPath Filter Thomson & Winterbottom Expires December 30, 2005 [Page 10] Internet-Draft Domain Auth. June 2005 The following XPath transform follows the recommendations in RFC 3275 [RFC3275] to select the elements for signing. This specification defines a new URN for this transform: "urn:ietf:params:xml:ns:pidf:geopriv10:domain-auth#PIDF-LO". Thomson & Winterbottom Expires December 30, 2005 [Page 11] Internet-Draft Domain Auth. June 2005 <?xml version="1.0"?> <dsig:Transform id="PIDF-LO" 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:da="urn:urn:ietf:params:xml:ns:pidf:geopriv10:domain-auth"> <!-- Select elements --> ( <!-- The enclosing presence element --> ((count(self::pidf:presence | here()/ancestor::pidf:presence[1]) = 1) <!-- The enclosing pidf:tuple element --> or (count(self::pidf:tuple | here()/ancestor::pidf:tuple[1]) = 1) <!-- enclosing()/pidf:tuple with the following portions ... --> or ((count(ancestor::pidf:tuple[1] | here()/ancestor::pidf:tuple[1]) = 1) <!-- ... pidf:status, pidf:status/pidf:timestamp[/text()] --> and (self::pidf:status or ancestor-or-self::pidf:timestamp <!-- ... gp:geopriv, gp:usage-rules --> or self::gp:geopriv or self::gp:usage-rules <!-- ... gp:location-info and descendants --> or ancestor-or-self::gp:location-info)) <!-- the enclosing da:domain-auth element --> or (count(self::da:domain-auth | here()/ancestor::da:domain-auth[1]) = 1) ) or ( <!-- Select attributes and xmlns for those elements --> (count(self::node() | parent::*/attribute::* | parent::*/namespace::*) < (count(self::node()) + count(parent::*/attribute::*) + count(parent::*/namespace::*))) and parent::*[ <!-- Repeat of element selection --> ((self::pidf:presence and (count(ancestor::pidf:presence) = 0)) or (count(self::pidf:tuple | here()/ancestor::pidf:tuple[1]) = 1) or ((count(ancestor::pidf:tuple[1] | here()/ancestor::pidf:tuple[1]) = 1) and (self::pidf:status or self::gp:geopriv or self::gp:usage-rules)) or (count(self::da:domain-auth | here()/ancestor::da:domain-auth[1]) = 1)) ]) </dsig:XPath> </dsig:Transform> Thomson & Winterbottom Expires December 30, 2005 [Page 12] Internet-Draft Domain Auth. June 2005 5. Examples A sample, demonstrating a simple form of the signed PIDF-LO document is shown below. <?xml version="1.0"?> <presence entity="pres:user@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:EPSG:geographicCRS: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> <da:domain-auth expires="2005-05-18T15:28:58.061+10:00" xmlns:da="urn:ietf:params:xml:ns:pidf:geopriv10:domain-auth"> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI=""> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="urn:ietf:params:xml:ns:pidf:geopriv10:domain-auth#PIDF-LO" /> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>bKlPmI0oKdmq24c4lV8jlL533K8=</ds:DigestValue> </ds:Reference> Thomson & Winterbottom Expires December 30, 2005 [Page 13] Internet-Draft Domain Auth. June 2005 </ds:SignedInfo> <ds:SignatureValue> iaEl9uK3VjpYci3oF+uyVmB12SA2HEsuJu8TtkwDcJ6f08B6uUll7gqm UsxBvY9tH8ijJsesKJQf/tKQxhmOrg2TfG7/0MOjagrtJglna5YaH1co LAMWlhb+iCMHvkAGxB+2cVr2Qsf6Fo0nw8qNHzswB2NwMFq1lCnaxYhY /fI= </ds:SignatureValue> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> MIICPjCCAacCBEKCkPQwDQYJKoZIhvcNAQEEBQAwZjELMAkGA1UE BhMCQVUxDDAKBgNVBAgTA05TVzETMBEGA1UEBxMKV29sbG9uZ29u ZzEPMA0GA1UEChMGTm9ydGVsMRQwEgYDVQQLEwtJUCBMb2NhdGlv bjENMAsGA1UEAxMEdGVzdDAeFw0wNTA1MTEyMzEwNDRaFw0wNTA4 MDkyMzEwNDRaMGYxCzAJBgNVBAYTAkFVMQwwCgYDVQQIEwNOU1cx EzARBgNVBAcTCldvbGxvbmdvbmcxDzANBgNVBAoTBk5vcnRlbDEU MBIGA1UECxMLSVAgTG9jYXRpb24xDTALBgNVBAMTBHRlc3QwgZ8w DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMgbk4ZIQqcsJp307Ooj bgtEeP8dzvyDLAhyGyb/iFBH3cGXJUBTsD+1kSGuK1VA+ENhCbU0 kHHYW0WLd7HbLoUnDcZqE1B5SoLsUA8n9wEW1BvfDj3A03Z+MRMV +ARWYqMHO8qdwGfIHP3/vrw67vNznZBE+18qk9Mi8EqqqpmfAgMB AAEwDQYJKoZIhvcNAQEEBQADgYEAtNmqmkcvpaMT+4l3pZ+eJba1 W2qgkjaWScxOUDznbAFW6hk1A9eL+Z91Fr025QPbT8cOiCY10mg5 wf6Yf027Z5354an2eZLiPm33FTu1yhI4XlLNa/BtbdFnuiB4N/Sn dvm1fy9uWvfiV8ayO/OsyaGjWfM1+z4kwZZH5c9LJMQ= </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </ds:Signature> </da:domain-auth> <note> This note may be changed without affecting the signature. </note> <timestamp>2005-05-18T15:03:39.362+10:00</timestamp> </tuple> </presence> Note that the digest and signatures are only included to serve as an example. Several elements are included in the above example that should not be signed by the domain authority, as described in Section 3.1, in particular "usage-rules" and "note-well". Thomson & Winterbottom Expires December 30, 2005 [Page 14] Internet-Draft Domain Auth. June 2005 The transform described in Section 3.1 removes extraneous elements, resulting in the following PIDF-LO, which only includes the signed elements (in this example whitespace has been added for 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:user@example.com"> <tuple id="pidflo1a786c3"> <status> <gp:geopriv> <gp:location-info> <gml:position> <gml:Point srsName="urn:EPSG:geographicCRS: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> <da:domain-auth xmlns:da="urn:ietf:params:xml:ns:pidf:geopriv10:domain-auth" expires="2005-05-18T15:28:58.061+10:00"></da:domain-auth> <timestamp>2005-05-18T15:03:39.362+10:00</timestamp> </tuple> </presence> Thomson & Winterbottom Expires December 30, 2005 [Page 15] Internet-Draft Domain Auth. June 2005 6. Security Considerations The security limitations of this specification are no more significant than those already identified in RFC 3275 [RFC3275]. [hannes] hmm. what is the implication? In particular the rules *Only What is Signed is Secure*, [hannes] 'secure' is a big word. maybe it would be good to be a bit more specific. *Only What is "Seen" Should be Signed*, [hannes] only what is seen can be signed and *"See" What is Signed* SHOULD be applied. [hannes] i think we should be a bit more specific about the entity that are involved and the role they play. It is RECOMMENDED that where certitude of information is important that only the signed information is transmitted or stored, that is, the PIDF-LO document formed by performing the transform described in Section 3.1. This ensures that no additional information may be misconstrued as being verifiable. This is particular applicable if the contents of the PIDF-LO document are displayed on screen. A degree of trust must exist between the domain authority and the location user. It is the responsibility of the location user to verify the identity of the domain authority and assert the appropriate level of trust. If the location user is unable to validate the identity of the domain authority for any reason, then the PIDF-LO document MUST be considered unsigned. [hannes] i always suggest not to use the term 'trust' since it makes things just fuzzy. [hannes] the main assumption here is that the entity that finally processes the location information and verifies the digital signature is able to determine that the entity that signed it is indeed authoritive to provide this information. Thomson & Winterbottom Expires December 30, 2005 [Page 16] Internet-Draft Domain Auth. June 2005 7. IANA Considerations 7.1 URN Sub-Namespace Registration for urn:ietf:params:xml:ns:pidf:geopriv10:domain-auth This document registers a new XML namespace, as per the guidelines in [RFC3688]. URI: The URI for this namespace is urn:ietf:params:xml:ns:pidf:geopriv10:domain-auth Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@nortel.com). XML: BEGIN <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>GEOPRIV Domain Authorization Extensions</title> </head> <body> <h1>Domain Authorization Extensions</h1> <h2>urn:ietf:params:xml:ns:pidf:geopriv10:domain-auth</h2> <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p> </body> </html> END 8. References [hannes] separate into normative & informative part. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [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. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. Thomson & Winterbottom Expires December 30, 2005 [Page 17] Internet-Draft Domain Auth. June 2005 [I-D.ietf-geopriv-pidf-lo] Peterson, J., "A Presence-based GEOPRIV Location Object Format", draft-ietf-geopriv-pidf-lo-03 (work in progress), September 2004. [W3C.REC-xml-exc-c14n-20020718] 3rd, D., Boyer, J., and J. Reagle, "Exclusive XML Canonicalization Version 1.0", W3C REC REC-xml-exc-c14n- 20020718, July 2002. ~snip~ ciao hannes _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv
- [Geopriv] review of <draft-thomson-domain-auth-01… Tschofenig, Hannes