Re: Significant W3C Confusion over Namespace Meaning and Policy

On Feb 12, 2005, at 3:49 PM, John Boyer wrote:

> 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).

Of what possible relevance is that? The only part that is
signed is the data -- placing context around it does not
change what was signed.

> Changes to the context do
> not affect the serialization over which the hash is
> ultimately computed, then the signature is repudiable.

I cannot parse that sentence because it is missing a word.

> 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.

Because it isn't repudiable -- you just claim it is, and your
claim has no basis in fact.

> 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!

Again, that's because you claim the information is signed
whereas everyone else (and the implementation) claim that
the bits are being signed, because that's the only way that
digital signatures can work.

Now, if you want to claim that XML security is completely
broken because it doesn't properly define the bits that
are being signed, then I won't argue with you.  It won't
change my opinion on xml:id, however.

> 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.

Right, and that is a process issue.  IETF process says the
latest spec updates all technologies that depend on it.
When possible, I always quote from the latest spec.  Feel free
to read RFC 2396 instead, if you wish.

> 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.

That's the same thing I said.

> 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?

Because I live in the real world?

> 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 []
> Sent: Thursday, February 10, 2005 6:37 PM
> To: John Boyer
> Cc:; 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
>    <>
> 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                            <>
> Chief Scientist, Day Software              <>

Received on Sunday, 13 February 2005 04:20:10 UTC