RE: [Uri-review] Request for review

Martin Duerst <duerst@it.aoyama.ac.jp> Tue, 23 May 2006 03:14 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiNLu-0005rR-Sc; Mon, 22 May 2006 23:14:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiNLs-0005pi-M0 for uri-review@ietf.org; Mon, 22 May 2006 23:14:32 -0400
Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiNLq-0005ZA-1A for uri-review@ietf.org; Mon, 22 May 2006 23:14:32 -0400
Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k4N3EMhv021850; Tue, 23 May 2006 12:14:22 +0900 (JST)
Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 5d19_3b76a9a6_ea0a_11da_870d_0014221fa3c9; Tue, 23 May 2006 12:14:22 +0900
Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k4N3C5ep021007; Tue, 23 May 2006 12:12:47 +0900
Message-Id: <6.0.0.20.2.20060523114617.0860fa00@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Version 6J
Date: Tue, 23 May 2006 12:03:32 +0900
To: Andrey Shur <andreysh@exchange.microsoft.com>, Mark Baker <distobj@acm.org>
From: Martin Duerst <duerst@it.aoyama.ac.jp>
Subject: RE: [Uri-review] Request for review
In-Reply-To: <1D4A05136773CF4DB373F6FE4E103150110EEE14@df-pug-msg.exchan ge.corp.microsoft.com>
References: <c70bc85d0605221313o5eb4a19chc35dadfe7b4a415b@mail.gmail.com> <1D4A05136773CF4DB373F6FE4E103150110EEE14@df-pug-msg.exchange.corp.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: "John Calhoon (LCA)" <john.calhoon@microsoft.com>, Ted Hardie <hardie@qualcomm.com>, "uri-review@ietf.org" <uri-review@ietf.org>, Dunietz <jerryd@windows.microsoft.com>, Gregg Brown <greggb@microsoft.com>, Jerry@scmailgw1.scop.aoyama.ac.jp
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
Errors-To: uri-review-bounces@ietf.org

Hello Andrey,

At 11:08 06/05/23, Andrey Shur wrote:
>Mark,
>
>Thank you for the question. I can see two parts of it that should be answered:
>
>First, why do we consider "any relative reference"? Actually we expect 
>users of the packaging technology to store manifold content in the package parts.

Of course.

>Certain kinds of the content may hold relative references.

Yes of course. But you don't have any guarantee that the
content referenced will be part of the package. So if a
user wants to create a 'self-contained' (meaning no
external relative references) package, either the user
(manually, or with dedicated scripts,...) or the packaging
software has to check all the references anyway.
Such a check is only marginally simplified by the
fact that there is a way to rewrite these relative
references so that any in-package relative reference
can start with a single slash, and out-of package
relative refences cannot be converted.


>We don't want to limit our customers to a particular form of relative 
>references.

If you want to make use of the specific properties of your
scheme, you have to rewrite relative references anyhow, in
which case it doesn't make much of a difference.

Let's say the user uses something like ../../foo.ext.
If this is in-package, you can leave it as that. If it
is out-of-package, and you want to restrict such links,
you have to raise an error (or do something else according
to user preferences).

Let's say the user uses something like /path/foo.ext.
Again, this could be in-package or out of package. You have
to check, and if necessary rewrite it.


>Second, why do we have a goal to "keep relative references within the 
>package"? This is all about security. An application performing regular 
>(default) resolution of relative references should not access resources 
>outside of the package.

But the syntax you came up with doesn't guarantee this, as you
showed with the ../../../foo.ext example.

Trying to get security with the syntax, when you actually don't have
that security and therefore need to check things anyway on the
receiving end and/or on the production end doesn't make much sense
to me.

Also, the additional potential security threads created by
an additional escaping layer should be considered.


>If an application needs to access external resources, it must be 
>explicitly defined in the content by specifying an appropriate base Uri

So basically all the security precautions can be circumvented
by using a base URI? Again, security has to be checked on
resolution. Trying to build it into the syntax doesn't work.


>or by using network-path form of the relative reference.

Using a network-path reference means to use the same scheme as
used previously, which means the pack: scheme. As said in
RFC 3986, network-path references are rare anyway.
You don't mention absolute URIs. Are they allowed or not?

Regards,    Martin.




#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp 


_______________________________________________
Uri-review mailing list
Uri-review@ietf.org
https://www1.ietf.org/mailman/listinfo/uri-review