RE: [security-services] XML Sig issues w/ SAML

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

Commenting on my own post...

After recently trying to use XML Signature I think that what is actually
needed is not a C14N  alg at all but a cannonical encoding.

The problem with the C14N algs specified is that they are all sensitive to
changes in the XML prefix. This is a real problem when you assemble
documents from components that started with different prefixes. XML code
packages have a way of ironing out inconsostency for you...

The Xclusive/Inclusive stuff is really a symptom of a wider problem, the
prefix is an indirection pointer to the namespace it references, the pointer
representation is not of consequence, only the namespace is.

So what we really should be using is some mechanism that ensures that every
prefix is expanded out to the URI it references. This would not be well
formed XML but it would be cannonical and the inclusive / exclusive bit
would be solved.

Ie. instead of:

<doc xmlns="http://splunge.com/splunge.xml/"; attr="splonk">

we use:

<http://splunge.com/splunge.xml/:doc xmlns="http://splunge.com/splunge.xml/";
http://splunge.com/splunge.xml/:attr="splonk";>

You would need a custom XML parser to reparse the data but it would be C14N
in every case...



Another point on XML Signature, if we want interop the spec should probably
have comment on XPATH usage. My view is that people should be able to write
clients and services that do not support obcurantist XPATH transformations,
both for compactness and for robustness.

I would like to profile the use of transformations very closely. This would
then allow verifiers to reject signatures because the transforms specified
are too complex.

It would also allow this mode of processing:

1) Extract the signature node [if doing enveloped]
2) Verify that node contains only the understood transformation(s)
3) Verify that the Id reference points to the expected object
4) Verify the signature

		Phill