signature portability / C14N / inherited namespaces, etc.

Hi,

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 eas!
!
!
ier than Signature because its probably OK for the bits to change a little if the meaning/effect doesn't change.

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

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

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
	http://www.w3.org/TR/2001/REC-xml-c14n-...#strip
and
	http://www.w3.org/TR/2001/REC-xml-c14n-...#stripWithComments
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.

Thanks,
Donald

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 12:23:56 UTC