W3C home > Mailing lists > Public > public-xmlsec@w3.org > November 2010

Changes to C14N 2.0 decided during the TPAC F2F

From: Pratik Datta <pratik.datta@oracle.com>
Date: Mon, 8 Nov 2010 22:50:10 -0800 (PST)
Message-ID: <09f3d969-7110-4bbe-8a1b-7d543a75b4d4@default>
To: public-xmlsec@w3.org
We resolved to change the following in C14N2.0  http://www.w3.org/2008/xmlsec/Drafts/c14n-20/


* ExclusiveMode and InclusiveNamespace:
In the F2F we tried to search for use cases where someone needs inclusive canonicalization, and we couldn't find any. In fact with the prefix rewriting, and the qnames in content features, there should be no need for inclusive canonicalization at all. So we have decided to remove inclusive canonicalization completely. I.e. canonicalization will always be in exclusive mode, so there is no need for ExclusiveMode parameters and InclusiveNamespace parameters. Recall InclusiveNamespace was a mechanism to do some namespaces inclusively and the rest exclusively.

Note: the C14N parameters defaults were set in such a way that all defaults would be exactly equivalent to Inclusive canonicalization 1.1. However now that we are removing inclusive canonicalization, this cannot be the default any more. Instead the default will be Exclusive C14N 1.0 + TrimTextnodes

* XMLAncestors
This parameter was controlled how we dealt with xml:base, xml:space and xml:lang attributes. I.e. at the root of the subtree to be signed we would emit any inheritable xml attributes that are in context. Exclusive C14n 1.0 doesn't do this because is breaks the requirement of able to sign a subdocument that is independent of the context. So it doesn't make sense to inherit these attributes.

Because we are getting rid of inclusive canoncalization, we also plan to get rid of XMLAncestors.

* SortAttributes:  
This had been introduced based on Brian's comments that in some situations, the order of the attributes is not messed up during transport. Hence there is no need to sort them during canonicalization. We have decided to remove this option, firstly to reduce the number of parameters, and secondly because in usual situations there are only a few attributes, so sorting is very fast. So now the default will be sort the attributes and namespaces always.

* Serialization:
This was introduced to support EXI. However it was decided EXI serialization needs to use a completely different canonicalization algorithm, i.e. it is not possible to use Canonical XML 2.0 with EXI output. This is because many of the artifacts in regular XML like prefixes, whitespace inbetween elements do not even exist in EXI.  So we will remove the serialization parameter completely.   Any other form of binary serialization e.g. Fast-Infoset, is also expected to have its own canonicalization algorithm. The only requirement is that the canonicalization algorithm be compatible with the inputs and outputs of Canonical XML 2.0



* TrimTextNodes
TrimTextNodes will stay as is. Note it will also inherit xml:space behavior as it is currently defined. I.e if there is an xml:space="preserve" in context, then the text nodes will not be trimmed. If not they will be trimmed depending on the setting of TrimTextNodes.  

The default value of TrimTexNodes will be changed to "true".

* PrefixRewrite
PrefixRewrite will no longer have the "derived" option. Only "none" and "sequential".

Also prefix rewrite will not rewrite the "xml" prefix. (this needs to be discussed further). In general all prefixes starting with "xml" are reserved. The xml prefix cannot be declared. And "xmlns" is not even considered a prefix, but considered to be namespace declaration.

* QNameAware
QNameAware will be have an additional subelement - XPathElement, apart from Element, QualifiedAttr, and UnQualifiedAttr.  This XPathElement will indicate the IncludedXPath and ExcludedXPath elements which need a different processing for determining visibly utilized. The canonicalizer needs to scan for prefixes in these elements, and consider these prefixes visibily utilized. It will also do prefix rewriting of these embedded prefixes.

Note, because every 2.0 mode signature will have IncludedXPath and ExcludedXPath, this will be implicitly passed from Signature to canonicalizer. I.e. every signature will NOT have a QNameAware/XPathElement to indicate that IncludedXPath has prefixes.

We also decided to remove the section on "2.2.1 Conformance profiles" completely.

We will mention that for all parameters the default value is MUST to implement, and the non default values are OPTIONAL.

Received on Tuesday, 9 November 2010 06:52:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:14 UTC