RE: Poll: Relative URIs and Strings in xmlns attributes

My vote is for #2.

i) The algorithms being used by dsig are being specified by an absolute URI.
It cannot be the case that some later decision changes the behavior of
algorithms used by dsig because then signatures that once validated will
stop validating on implementations that conform to a decision, once one is
made, about what to do about URI.

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.

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.

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.

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.

Thanks,
John Boyer
Development Team Leader,
Distributed Processing and XML
PureEdge Solutions Inc.
Creating Binding E-Commerce
v: 250-479-8334, ext. 143  f: 250-479-3772
1-888-517-2675   http://www.PureEdge.com <http://www.pureedge.com/>




-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Joseph M. Reagle
Jr.
Sent: Friday, September 15, 2000 2:12 PM
To: IETF/W3C XML-DSig WG
Cc: Tim Berners-Lee; Dan Connolly; Kay Michael; James Clark; Martin J.
Duerst; Jonathan Marsh
Subject: Poll: Relative URIs and Strings in xmlns attributes


Before we request Candidate Rec status for Canonical XML there's one issue
that I've been trying to understand and come to closure on, and that's the
implications of the recent XML Plenary decision on Canonical XML: "to
deprecate the use of relative URI references in namespace declarations." [1]
What does that mean for the Canonical Form? We've had some discussion on
this over this week in this WG [2], some discussion in the XML Coordination
Group, and I also briefly discussed this with TimBL. I think the two options
we now face are below. Please post your preference -- and optionally
reason/rationale -- by end of day Wednesday September 30th. (Those cc:'d are
invited to make their choice known in an advisory capacity than can convince
others of their position, but in the end I'd like to say, "the XML Signature
WG feels $this-way about the issue, while others (agree|disagree)."

CHOICES

1. To state that the canonical form of a document containing a relative URI
in a namespace is undefined, and consequently such a document can not be
signed. (This includes namespaces like "../foo" as well as "bar"; only
documents with namespace declaration using absolute URIs are in scope --
just as only well formed documents are in scope.)
2. To state that the canonical form is URI unaware. In section 3.1 [4], we
already disclaim responsibility for resolving/normalizing other URIs, data
types, application semantics, etc. (The reason we made this distinction in
the first place is because XPath did. However, an errata of XPath might be
issued that would make the resulting the string-value
implementation-dependent, but we can't say till we see the errata.)
Consequently, not only is the issue of the "relative-URI-in-namespace" out
of scope, so is the plenary decision.

ARGUMENTS FOR CHOICE (1)

A. The XML Plenary decision recommends W3C specs say, "This specification
does not define an information set [or whatever] for XML documents which use
relative URIs in namespace declarations." [1]
B. In [3] DanC stated that, "if you specify how they work today, we won't be
able to make a different specification later." I'm very glad the XML Plenary
has come to a decision on this and I want to respect the spirit and intended
effect of that decision.
C. (1) seems to be the common interpretation of the plenary decision to
Canonical XML by the folks who were active in the Plenary discussion.

ARGUMENTS FOR CHOICE (2)

A. The XML Plenary decision, "Proposed: to deprecate the use of relative URI
references in namespace declarations; that is: to say that while they
conform to the Namespace Recommendation of January 1999, later
specifications such as DOM, XPath, etc. will define no interpretation for
them." However, I'm told that "no interpretation"  is not an argument in
favor "literal interpretation" which was specifically opted against.
B. However, it might permit us to make an argument that we are all-together
URI unaware.  (The only reason we know these might be URIs and not strings
is because of the XPath namespace-node and because of the syntactic sugar of
'xmlns:'.) Later, if consensus is reached on namespaces/URIs, someone can
easily write a URI-canonicalization specification and apply it prior to
Canonical XML.
C. Canonical XML is not in the set of specifications (DOM, XPath, etc.)
covered by the Plenary decision, but an application of them which is allowed
to do as it pleases. Canonical XML is an application of XPath that uses
namespace nodes as we choose as a contribution to a generated hash-value.
What we do today won't hinder others in the future.
D. There are documents out there that use relative URIs and need to be
signed. (Is this the case for anyone in the WG?)






[1] http://www.w3.org/2000/09/xppa.html
>4.2 Proposal
>
>Proposed: to deprecate the use of relative URI references
>in namespace declarations; that is: to say that while they
>conform to the Namespace Recommendation of January
>1999, later specifications such as DOM, XPath, etc. will
>define no interpretation for them. "
[2]
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0467.html
[3] Forwarded Text ----
>Date: Thu, 14 Sep 2000 15:35:09 -0500
>From: Dan Connolly <connolly@w3.org>
>
> > 2. Our question is related to the question asked of by Clark [2], since
> the
> > XPath errata attempts to [3] implement the plenary decision [4]. Under
> XPath
> > errata [3] "XPath expressions can still be well-defined on a document
> > containing relative namespace URIs..." [2]  We also felt that there can
> be a
> > Canonical form of such documents. And our interpretation of [3] led us
to
> > believe it is up to xmldsig to decide how to represent it. We recently
> > decided to treat relative URIs in these instances as a non-absolutized
> > string in the Canonical form. However, this caused others to feel this
> > violated the plenary decision
>
>Hmm... yes... I might have told you differently in our
>earlier conversation, but I think that *any* specification
>of how a relative URI reference in an xml namespace
>declaration is to be interpreted is in conflict
>with the plenary decision; if you specify how they
>work today, we won't be able to make a different
>specification later. (Meanwhile, we're allowing
>implementations to do what they like, so the only
>chance we really have of specifying how they work
>later is if the market agrees on some way of
>interpreting them, and we adopt that way.)
[4] http://www.w3.org/TR/2000/WD-xml-c14n-20000907#Limitations
For example, in a digital signature application, a document is often
retrieved and processed prior to signature generation. The processing SHOULD
include the conversion of relative URIs to absolute URIs, thereby mitigating
any security risk.


__
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 17:48:36 UTC