Issue 127 - C14N Text

["Hal Lockhart" <hlockhar@bea.com>]

Back in August, I proposed that we add the following near the end of section
8.1 in place of
lines 829-830

----
The XML Digital Signature WG has defined two canonicalization algorithms:
XML Canonicalization  and Exclusive XML Canonicalization. To prevent
confusion, the first is also called Inclusive Canonicalization. Neither one
solves all possible problems that can arise. The following informal
discussion is intended to provide guidance on the choice of which one to use
in particular circumstances. For a more detailed and technically precise
discusion of these issues see: [XML-C14N] and [EXC-C14N].

There are two problems to be avoided. In the one hand, XML allows documents
to be changed in various ways and still be considered equivalent. For
example, duplicate namespace declarations can be removed or created. As a
result, XML tools make these kinds of changes freely when processing XML.
Therefore, it is vital that these equivalent forms match the same signature.

On the other hand, if the signature simply covers something like xx:foo, its
meaning may change if xx is redefined. In this case the signature does not
prevent tampering. It might be thought that the problem could be solved by
expanding all the values in line. Unfortunately, there are mechanisms like
XPATH which consider xx="http://example.com/"; to be different from
yy="http://example.com/"; even though both are xx and yy are bound to the
same namespace.

The fundamental difference between the Inclusive and Exclusive
Canonicalization is which namespace declarations which are placed in the
output. Inclusive Canonicalization copies all the declarations that are
currently in force, even if they are defined outside of the scope of the
signature. It also copies any xml: attributes that are in force, such as
xml:lang or xml:base. This guarantees that all the declarations you might
make use of will be unambigiously specified. The problem with this is that
if the signed XML is moved into another XML document which has other
declarations, the Inclusive Canonicalization will copy then and the
signature will be invalid. This can even happen if you simply add an
attribute in a different namespace to the surrounding context.

Exclusive Canonicalization tries to figure out what namespaces you are
actually using and just copies those. Specifically, it copies the ones that
are "visibly used", which means the ones that are a part of the XML syntax.
However, it does not look into attribute values or element content, so the
namespace declarations required to process these are not copied. For example
if you had an attribute like xx:foo="yy:bar" it would copy the declaration
for xx, but not yy. (This can even happen without your knowledge because XML
processing tools will add xsi:type if you use a schema subtype.) It also
does not copy the xml: attributes that are declared outside the scope of the
signature.

Exclusive Canonicalization allows you to create a list of the namespaces
that must be declared, so that it will pick up the declarations for the ones
that are not visibly used. The only problem is that the software doing the
signing must know what they are. In a typical SOAP software environment, the
security code will typically be unaware of all the namespaces being used by
the application in the message body that it is signing.

Exclusive Canonicalization is useful when you have a signed XML document
that you wish to insert into other XML documents. A good example is a signed
SAML assertion which might be inserted as a XML Token in the security header
of various SOAP messages. The Issuer who signs the assertion will be aware
of the namespaces being used and able to construct the list. The use of
Exclusive Canonicalization will insure the signature verifies correctly
every time.

Inclusive Canonicalization is useful in the typical case of signing part or
all of the SOAP body in accordance with this specification. This will insure
all the declarations fall under the signature, even though the code is
unaware of what namespaces are being used. At the same time, it is less
likely that the signed data (and signature element) will be inserted in some
other XML document. Even if this is desired, it still may not be feasible
for other reasons, for example there may be Id's with the same value defined
in both XML documents.

In other situations it will be necessary to study the requirements of the
application and the detailed operation of the canonicalization methods to
determine which is appropriate.
------------

Merlin Hughes added the folowing which might be edited in:

------------
Inclusive c14n includes in the canonical form all inherited
and local namespace declarations and xml: attributes, whether
or not they are visibly utilized. As a result, if the signed
data or signature are moved into a new context, or if new
ancestor namespaces or xml: attributes are introduced into
the document (e.g., by intermediary processing) then the
signature will be rendered invalid.

Exclusive c14n includes in the canonical form only those
namespace declarations that are visibly utilized or explicitly
parameterized, and only local xml: attributes. As a result, the
signed data and signature are immune to irrelevant contextual
changes. However, explicit application and/or schema support
is required to accurately parameterize the algorithm with
non-visibly utilized namespace prefixes of the signed data
(e.g., QName prefixes). Otherwise, the signed data may be
vulnerable to semantic changes that will not be detected by
the signature.

Consequently, inclusive c14n is the safer canonicalization
algorithm from a security perspective: It requires no
knowledge of the data that are to be secured in order to
safely sign them.

On the other hand, exclusive c14n is required in order to
generate self-signed structures that support placement within
different XML contexts.

Inclusive c14n meets the needs of the common usage scenarios
of WS-Security: SOAP messages are not typically moved from
one XML context to another, and the semantics of the SOAP
body are typically not known to the security module.

Exclusive c14n meets the needs of, for example, SAML tokens:
These are expressly designed to be self-signed structures
that will be placed into different XML contexts. Further,
the semantics of the SAML token will be explicitly known to
the signer, so it can accurately parameterize the algorithm.

Exclusive c14n does not solve the problems of encapsulating
a signed SOAP message within another document: It cannot
address ID attribute clashes between the encapsulated SOAP
message and the encapsulating document, etc. For this reason,
SOAP attachments or equivalent must be used in order to effect
message encapsulation, allowing each encapsulated message
to remain in a distinct document context.

----

Merlin also made the following observation which should also be added:

------
Finally, exc-c14n is not immune to the namespace inheritance
problem. Consider signing this with exc-c14n, including the
foo prefix in the unsuppressed namespace prefix list.
  <Body>
    <ToBeSigned wsu:Id="tbs">
      <Data xmlns:foo="urn:foo" Something="foo:Bar"/>
    </ToBeSigned>
  </Body>

If an intermediary introduces the use of this namespace
prefix in an ancestor, then the signature will break because
xmlns:foo will be canonicalized with the ToBeSigned element
instead of the Data element. In both cases, foo will be
assigned the same value and will be included under the
signature, but since it will appear within a different
element, the signature value computed will be different.
---------

Hal