W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2001

signature portability / C14N / inherited namespaces, etc.

From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
Date: Wed, 30 May 2001 13:59:46 -0400
Message-Id: <200105301759.NAA0000030169@torque.pothole.com>
To: w3c-ietf-xmldsig@w3.org
Sorry, don't know what I was thinking about, posting this to the XML
Encryption list...

Message-ID:  <1DE737930E15D511B64400D0B76FE2620C0C48@ma07exm01.corp.isg.mot.com>
From:  Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>
To:  "'xml-encryption@w3.org'" <xml-encryption@w3.org>
Date:  Wed, 30 May 2001 12:23:44 -0400
Subject:  signature portability / C14N / inherited namespaces, etc.


I've been thinking about this topic ...

It's reasonable to look at all this from a protocol point of view, as
well as the document/form point of view, because people in SOAP and
Instant Messaging and IOTP and lots and lots of other places are using
or planning to use XML for protocol messages, both simple and
complex. From the protocol point of view, it is essential that it be
possible to pick up an XML signature and to pick up signed XML data
and move them from one message context to another message context
without breaking the signature. In fact, for simple garden variety
cases, it should be quite easy to do this.

The current XML C14N is reasonably suited to how it might be used in
XML Encryption. Say you have some XML and you want to encapsulate its
context into it before encryption, so that when you decrypt it you can
insert the plain text into a different context and have it mean/be
something pretty close to the original. For this purpose the current
C14N seems to fit the ticket. It is not perfect and needs some
commentary. For example, the source context might not have had any
xml:lang attribute although the destination did and this could change
meaning. But it usually wouldn't since, if the xml:lang attribute was
important, there would have been one at the top of the encrypted
material or higher in the source context. So, with minor application
precautions, I think it works. And in unusual cases, if there is some
of its context you don't want, you can variously not use C14N and/or
write XPath expressions to include/discard parts of it. The Encryption
case is less sensitive and easier than Signature because its probably
OK for the bits to change a little if the meaning/effect doesn't

In some sense, in the Encryption use case I describe above, you want
C14N to "attract" the context. But for portable XMLDSIG, you normally
want to "repel" the context. True, you can imagine arbitrarily complex
cases where some namespace prefixes are intended to change meaning
depending on context, others have fixed namespace declarations, and
computations are done which depend on the presence of namespace
declarations whose prefix is never used at all. And you can take care
of such unusual cases with enough effort on the part of the
application designer. But they are not normal. In the normal everyday
case, which should be quite easy, you care only about the namespace
declarations that bind prefixes that are actually used in the signed

Since SignedInfo is something that we have created in coming up with
the XMLDSIG standard, then for it especially, the canonicalization
needed for the normal case should be obvious and straightforward.

I'm all in favor of allowing people to write XPath expressions to do
fancy things for complicated cases. But this is really
programming. It's intricate and error prone. If you always have to
hand craft XPath programs for protocol cases and normal protocol
message SignedInfo cases, then I question the viability of XMLDSIG. If
you get signatures that depend on XPath expressions, then in the
general protocol case you have to determine if those expression
compromise security. Not every case is a document/form going between
common implementations of some application task where you could just
check if the XPath expression follows some rigid formula. In more
general cases, you are faced with a general artificial intelligence /
theorem proving problem where you verifier has to understand the XPath
expression, understand your real security criterion, and determine if
the expression voids the criterion.

By the way, as well as namespace declarations, we still have all the
other possible stuff in the xml namespace, like xml:lang, xml:space,
xml:base, and things that may be defined in the future, that get
stuffed into document subsets and can change them depending on

As for cutting up the document with DOM before applying C14N, I am
reluctant to drag in another data model and require DOM as well as
some part of XPath for simple normal uses of C14N to support XML
Digital Signature.

It seems to me that there should just be another switch to C14N. The
current C14N is inclusive. If there were an "exclusive" mode that did
not import things in the xml namespace and only included namespace
declarations whose prefixes are actually used, I think we would have
the normal cases covered. For Signature, you would almost always want
to use the exclusive version.  For Encryption, in cases where you want
to insulate the encrypted data from changes due to being decrypted
into a different context, which I think is the most common case, you
would want to use the inclusive C14N. In cases where you want the
decrypted data to be considered in whatever context into which it is
decrypted, which some others think is the most common case, you would
want to not canonicalize at all or use the exclusive C14N. For complex
cases, you could adjust with XPath and use either.

So, I guess what I am suggesting, is that

or the like be defined which don't import miscellaneous xml namespace
attributes from above the apex of what's being serialized and suppress
namespaces whose prefixes aren't used.


PS: Since C14N currently suppresses declarations of the xml namespace
to be its standard value, should it also suppress declarations of
xmlns to be "http://www.w3.org/2000/xmlns/" which the DOM group has
decided should be its standard value?
Received on Wednesday, 30 May 2001 14:00:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:10:05 UTC