[secdir] SECDIR review of draft-ietf-geopriv-geo-uri-04

"Laganier, Julien" <julienl@qualcomm.com> Sat, 05 December 2009 02:08 UTC

Return-Path: <julienl@qualcomm.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1479C3A6800; Fri, 4 Dec 2009 18:08:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.654
X-Spam-Level:
X-Spam-Status: No, score=-105.654 tagged_above=-999 required=5 tests=[AWL=0.945, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+y2j3DVyqRW; Fri, 4 Dec 2009 18:07:59 -0800 (PST)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id C30323A63C9; Fri, 4 Dec 2009 18:07:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1259978867; x=1291514867; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Laganier,=20Julien"=20<julienl@qualcomm.com> |To:=20"secdir@ietf.org"=20<secdir@ietf.org>,=20"iesg@iet f.org"=20<iesg@ietf.org>|CC:=20"draft-ietf-geopriv-geo-ur i@tools.ietf.org"=0D=0A=09<draft-ietf-geopriv-geo-uri@too ls.ietf.org>,=0D=0A=20=20=20=20=20=20=20=20"geopriv-chair s@tools.ietf.org"=0D=0A=09<geopriv-chairs@tools.ietf.org> ,=0D=0A=20=20=20=20=20=20=20=20"geopriv-ads@tools.ietf.or g"=0D=0A=09<geopriv-ads@tools.ietf.org>|Date:=20Fri,=204 =20Dec=202009=2018:07:41=20-0800|Subject:=20SECDIR=20revi ew=20of=20draft-ietf-geopriv-geo-uri-04|Thread-Topic:=20S ECDIR=20review=20of=20draft-ietf-geopriv-geo-uri-04 |Thread-Index:=20Acp1T7n9fjq+iCqPThmWwISnFb6QaA=3D=3D |Message-ID:=20<BF345F63074F8040B58C00A186FCA57F1C65FB2E8 0@NALASEXMB04.na.qualcomm.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 400,1158,5822"=3B=20a=3D"29112405"; bh=W2UuhTq/Oat+n8gDW4XqQoJKl80fmk/PGw6WwLFHrAk=; b=v0SeKrAG+0qZzWJXlzsMdL2m1Mm/Mg6lli4W1z1TiqioSJBXkwBOlDG/ EC80YOvaFkVvpvT8bBgoDuCNnk8AmhtjW0zR3kIEVdHsqwnWXXeTnI96j CmJxNrMTAOMvJLimKdgrdpIALarZ7f5WOihu2pkFYfzzoExD4ZB/lbFmn 8=;
X-IronPort-AV: E=McAfee;i="5400,1158,5822"; a="29112405"
Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 04 Dec 2009 18:07:46 -0800
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nB527kwt008496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 4 Dec 2009 18:07:46 -0800
Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nB527j3O018423 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 Dec 2009 18:07:45 -0800 (PST)
Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 4 Dec 2009 18:07:45 -0800
Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Fri, 4 Dec 2009 18:07:45 -0800
From: "Laganier, Julien" <julienl@qualcomm.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Date: Fri, 4 Dec 2009 18:07:41 -0800
Thread-Topic: SECDIR review of draft-ietf-geopriv-geo-uri-04
Thread-Index: Acp1T7n9fjq+iCqPThmWwISnFb6QaA==
Message-ID: <BF345F63074F8040B58C00A186FCA57F1C65FB2E80@NALASEXMB04.na.qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-ietf-geopriv-geo-uri@tools.ietf.org" <draft-ietf-geopriv-geo-uri@tools.ietf.org>, "geopriv-chairs@tools.ietf.org" <geopriv-chairs@tools.ietf.org>, "geopriv-ads@tools.ietf.org" <geopriv-ads@tools.ietf.org>
Subject: [secdir] SECDIR review of draft-ietf-geopriv-geo-uri-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Dec 2009 02:08:01 -0000

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

Document Abstract:

   This document specifies a Uniform Resource Identifier (URI) for
   geographic locations using the 'geo' scheme name.  A 'geo' URI
   identifies a physical location in a two- or three-dimensional
   coordinate reference system in a compact, simple, human-readable, and
   protocol-independent way.  The default coordinate reference system
   used is WGS-84.

I think the document is fine security wise. I have a couple of questions; mostly to satisfy curiosity:

3.4.3.  Location Uncertainty

   The 'u' ("uncertainty") parameter indicates the amount of uncertainty
   in the location as a value in meters.  Where a 'geo' URI is used to
   identify the location of a particular object, <uval> indicates the
   uncertainty with which the identified location of the subject is
   known.

   The 'u' parameter is optional and it can appear only once.  If it is
   not specified, this indicates that uncertainty is unknown or
   unspecified.  If the intent is to indicate a specific point in space,
   <uval> MAY be set to zero.  Zero uncertainty and absent uncertainty
   are never the same thing.

Shouldn't this MAY be a MUST? (since as you note zero uncertainty and absent uncertainty are never the same thing.)

3.4.4.  URI Comparison

   Two 'geo' URIs are equal when they use the same CRS, and <coord-a>,
   <coord-b>, <coord-c> and 'u' value are mathematically identical
   (including absent <uval> meaning undefined 'u' value).

Hmm. About comparison:

I understand that when <uval> is present you are delimiting a sphere of radius <uval> centered on the point (<coord-a>, <coord-b>, <coord-c>).

When <uval> is absent (undefined) the sphere containing can have any radius, thus two geo URIs with same coordinates but undefined <uval> might correspond to a different spheres in which case it seems to me that they shouldn't be said to be equal. 

5.  URI Operations

   Currently, just one operation on a 'geo' URI is defined - location
   dereference: In that operation, a client dereferences the URI by
   extracting the geographical coordinates from the URI path component
   <geo-path>.  Further use of those coordinates (and the uncertainty
   value from <uval>) is then up to the application processing the URI,
   and might depend on the context of the URI.

It seems that the document is also defining an equality comparison operation between geo URIs.

--julien