W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 2000

RE: Poll: Relative URIs and Strings in xmlns attributes

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Fri, 15 Sep 2000 18:51:27 -0400
Message-Id: <4.3.2.7.2.20000915181406.00b852b8@rpcp.mit.edu>
To: "John Boyer" <jboyer@PureEdge.com>
Cc: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>, "Tim Berners-Lee" <timbl@w3.org>, "Dan Connolly" <connolly@w3.org>, "Kay Michael" <Michael.Kay@icl.com>, "James Clark" <jjc@jclark.com>, "Martin J. Duerst" <duerst@w3.org>, "Jonathan Marsh" <jmarsh@microsoft.com>
Hi John,
>I think that this poll should be reissued with these points made clear.  In
>particular, the Poll should state that this decision must be made before
>request for CR status of C14N and DSig-- the choice that people make should
>be constrained so that it applies to both specs.

Actually, I'd like to have people choose between the two options I 
presented, though they certainly should take into account what you say (and 
others in the discussion), and can even change their position before 
Wednesday during the discussion. If it becomes clear in others' responses 
that no coherent resolution is forthcoming because of my formulation, we 
could try again with a different one.

At 14:48 9/15/2000 -0700, John Boyer wrote:
>ii) For this reason, I am suggesting that we say only that absolute URIs are
>required, and support for relative URIs is RECOMMENDED, but that those who
>support them MUST do so by providing the original string.  If the W3C later
>decides to support relative URIs (and most other strings) in some way, then
>that must correspond to an issuance of C14N v1.0.1 under a different URI
>since, as I said before we cannot have C14N v1.0 change behavior without
>breaking signatures created between now and when the W3C makes this
>decision.

I want a sense of the two questions I asked. If everyone favors (2), we 
could consider this proposal further. However, even then I'd have concerns as:

1. This type of conformance constraint is complex IMHO. People have 
expressed a desire for canonicalization algorithms that do one thing and do 
it well. I fear this additional level optionality where we say to implement 
this OPTIONAL feature you MUST do this. (The xmldsig spec is starting to get 
like this with respect to Recommending XPath to implement a REQUIRED feature.)
2. Part of the 'philosophical' argument I stated for (2) was that we were 
being all-together URI unaware. This might be a spurious argument, however 
your proposal places us closer to the scope of the Plenary decision, and 
more obligated to adhere to it I think.

>iii) The question is not whether people have a problem with relative URIs in
>namespaces.  The question is whether it is inconvenient that documents
>containing most of the reasonable namespace names that people would use,
>other than actual absolute URIs, cannot be signed.  You made it clear in the
>choice for 1 but not in the arguments for 2.

Yes, people should realize that if they have a document  with a relative URI 
in a namespace of the type xmlns="../foo" or even xmlns="bar" then option 
(1) means there is no canonical form. However, everyone else respecting the 
plenary decision has the same issue. It's a heavy cost, but the only one the 
Plenary could come to agreement on to close that issue and move on.

>iv) This is not simply a question of whether c14n does this.  A consequence
>of permitting c14n to retain the original string is that dsig must do the
>same thing.  This is due to the existence of same document references,
>including enveloped signatures.

This is true. However, it furthers the statement that option (1) means this 
class of comments can not be signed as already stated, "There are documents 
out there that use relative URIs and need to be signed." So I don't see a 
need to reformulate the poll yet.


__
Joseph Reagle Jr.
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
Received on Friday, 15 September 2000 18:52:23 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:11 GMT