RE: Significant W3C Confusion over Namespace Meaning and Policy

Hi Roy,

There's so much wrong with your response that I'm
having trouble even figuring out where to begin...

You can set up a signature that causes your additional
context to break the signature, and you can set one up
so that it doesn't.  We tend to recommend not creating
the type of signature you described exactly because it
permits arbitrary qualifications to the signed data,
which can be not just of the form you described but also
of the form not(signed data).  Changes to the context do
not affect the serialization over which the hash is
ultimately computed, then the signature is repudiable.
So, because I've spent a long time in the XML security
space and therefore have volumes and volumes of things 
to say about good versus bad signatures, it does little 
to advance your argument to provide me with a repudiable
signature and then to say look the signature doesn't
break when I change the context.

Then there's the fact that the entire argument is not
analogous to what's being discussed, which is changes 
that can be made not to surrounding context but 
rather to the very information signed!

And what you said in defense of your interpretation of 
namespaces is even more interesting.  You present a 
"latest" definition created in Jan. 2005 that I've
responded to in Feb. 2005 by saying that it breaks
stuff when retroactively applied to the interpretation
of a 1999 spec in recommendations that were let in 2001 
and 2002.

You may have a dictionary with a lot of definitions for
the word identify, but you do nothing to address the fact
that the writings available to us at the time, including the
policy document on namespace conventions by the W3C director,
described the use of an expanded name as allowing us to 
distinguish elements or attributes that have different 
interpretations despite having equivalent local names. 
Why do you find it so unreasonable that the entire XML
signatures working group would conclude that XML could 
be signed because the meaning of the signed content
would not be changed?

Next you accuse me of playing games with W3C process when
I'm trying in fact to explain to you how XML signatures
work.  I don't get that, esp. when you seem bent on 
ignoring the parts of my argument that are inconvenient
to your own.

For example, you persist in claiming that xml is a 
reserved namespace long after I already pointed out
that the namespace recommendation reserved *prefixes*
starting with xml.  Nothing in the document does what
you describe.

Moreover, you ignored the fact that the 2005 definition
you presented was for URI, which is applicable in many
domains outside of its use in namespaces.  So, when I
pointed out to you that your very own definition allowed
for the fact that sometimes URIs "could be" used for 
identity, and that in the namespaces rec and the 
conventions document there was language to suggest they
were being used in that way, your response was along
the the lines of "nahn ahn"

In the end, you can pull out whatever dictionary you want
and show as many alternate meanings for identity as you
like, but you still haven't shown that the meaning I've
selected is inappropriate.  There is a difference between
a wrong conclusion and one that is inconvenient (hopefully
your dictionary does not "identify" those two words, too).

So, fix, fix, fix away if you like.  But there is 
inconvenience on both sides of the coin. If namespaces
come to have the meaning you describe, then the W3C
should repeal its recommendation of XML signatures in
their entirety.  It makes no sense to have a system that
chokes if a single bit of data has been altered, only to
have far more qualitative changes by a change to the
definition of namespace relative to the understanding
the signature group had when it created that recommendation
(a joint venture with IETF, no less).

John Boyer, Ph.D.
Senior Product Architect and Research Scientist
PureEdge Solutions Inc.
 

-----Original Message-----
From: Roy T. Fielding [mailto:fielding@gbiv.com]
Sent: Thursday, February 10, 2005 6:37 PM
To: John Boyer
Cc: www-tag@w3.org; Bjoern Hoehrmann
Subject: Re: Significant W3C Confusion over Namespace Meaning and Policy


On Feb 10, 2005, at 9:52 AM, John Boyer wrote:
>> I believe it is an error in the digital signature specification
>> to specify an algorithm that is impacted by changes outside
>> the content (such as any changes influenced by context). That
>> error should be fixed regardless of the namespaces discussion.
>
> First, maybe you missed the fact that I was not talking about
> any minor technical issue in C14N that arises *only when a document
> subset* is being processed.

No, but I should have said *if* such an error exists.

> Even if you don't use C14N, a signature is applied over a blob
> of XML markup.  The signature is signing the markup because the
> markup is supposed to representative of a concrete set of operations.
>
> That markup can be impacted by changes outside of the content
> if you allow changes the meaning of any name in the namespace or
> if you allow changes to the namespace.

The signature applies to what is signed -- nothing more than that.

> You said "the signature wouldn't work".   No!  The signature will
> in fact continue to validate, but the subsequent processing of the
> signed information may not be in accord with what the signer 
> authorized.

Let's consider a signed purchase order agreement.  It contains all
of the usual data for the purchase and is enclosed by a signature.
When that XML blob is placed within a protocol action consistent
with making a transaction, it has one meaning that everyone can
agree upon.  When that same XML blob is placed within a document
in which the surrounding text says:

    This is the purchase agreement we had in effect between
    the years 1999-2001.

then does that context somehow invalidate the signature?

Context does not invalidate a signature because the signature
is upon the ordered bits within the blob, not the meaning of
those bits when interpreted in context.  Any other interpretation
of digital signatures is fundamentally flawed because the entire
purpose of such signatures is accountability.

> So, to fix this error, one has to conclude that neither
> changing the namespace nor changing the semantics of the
> namespace are permitted.  Again, THIS HAS NOTHING TO DO
> WITH C14N!!!!!

Someone said that c14n contained instructions to treat all
xml namespaced attributes as inherited.  That is a rather
obvious error, assuming it actually says it (I haven't checked).

> On a separate point, it is interesting that you've used an RFC let
> in Jan. 2005 to justify your interpretation of words appearing in
> a W3C recommendation published in 1999.

Yes, interesting in that it reflects the most recent international
standard on what it means, agreed to in public, and thoroughly
vetted by the TAG.  Namespaces is dependent on URI.

> But, to play ball, let's take a look at the words you quoted, focusing 
> on
>
> "These terms should not be mistaken as an assumption that an identifier
>      defines or embodies the identity of what is referenced, though
>      that may be the case for some identifiers."
>
> Thus, even by your definition, it may be the case for some
> identifiers that they are indeed meant to embody the identity
> of something.  And my position remains that the material
> created in 1999 (the namespaces rec and the namespaces conventions)
> were intended to create this class of identifiers.

Great, then we have resolved the question.  The namespaces rec
had no such intention, and even if it could be interpreted the
way you suggest, that only means we will have to edit the Namespaces
draft to bring it in line with reality.

Again, please do not play W3C process games here.

> Regardless of what new meaning you and others may want to
> assign to the word identify, the fact remains that their
> usage in dictionaries and computer science texts do not use
> the meaning you define.
>
> So, clearly we're not going to get anywhere by continuing to
> haggle over this point.

Good, because it would be far easier to agree to disagree than
to explain to you the 16 different definitions of identify

   <http://dictionary.reference.com/search?q=identify>

only one of which agrees with your assumed meaning.

> What I would like instead is for someone to explain to me
> exactly why it is so hard for implementations to be what
> I perceive to be only slightly more intelligent about their
> handling of namespaces.  You make a big deal out of the idea
> of changing the namespace when the language schema changes,
> but this is a trivial thing for an implementer to account for.

Since "xml" is a reserved qualifier, the difference is
between having id available automatically within all XML
languages (a universal standard for a universal concept)
or requiring that any use of it be xmlns declared like
other extended name sets.

Uniformity has considerable value and the "xml" namespace
has *always* been intended for extension.  Hence, our prior
conclusion that xml:id is a desirable extension still seems
to be true.  If that causes breakage, we need to fix the real
reasons for that breakage, not become reactionary and reduce
XML to the lowest common denominator of past Recommendations.


Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>

Received on Saturday, 12 February 2005 23:49:39 UTC