W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > October to December 1999

Context dependency of Canonicalizatoin

From: Hiroshi Maruyama <MARUYAMA@jp.ibm.com>
Date: Wed, 3 Nov 1999 10:50:25 +0900
To: dee3@us.ibm.com
cc: w3c-ietf-xmldsig@w3.org
Message-ID: <4925681E.000A9728.00@d22mta10.yamato.ibm.com>

Per our discussion, I double checked the current drafts of dsig and C14N.  As
you pointed out, it appears there are certain context dependencies of C14N that
would make it difficult to moving <signature> elements into other documents.
The particular points are:

1) The "Id" attribute of the SignedInfo element.  This is declared the type ID
which requires a different normalization
    from CDATA attributes.  This means that, when a DTD is present, this
attribute will be normalized by removing the
    leading and trailing white spaces while it will not be normalized when
without DTD.  Because the "Id" attribute of the Object
    element is declared as CDATA, I suggest to declare this as #PCDATA, too.

2) The "encoding" attribute of the DigestValue element has the default value
"urn:ietf-org:base64".  When DigestValue
    has no "encoding" attribute, C14N requires to supply the default value only
when the DTD is present.  I suggest to
    change this to either #REQUIRED (no default value) or #IMPLIED (i.e.,
missing "encoding" means base64).

3) The "encoding" attribute of the SignatureValue element.  This is not a
problem in normal situations because
    SignatureValue will not be signed.  However, if there are nested signatures,
this element may get C14Ned.  Applying
    either the above strategies are preferable.

4) Namespace declaration in the Signature element.  If there is no such
declaration, and if there is a default namespace
    declaration in the outer context, the result of C14N will be different.  The
only way to protect the contents from
    this happening is to explicitly declare the dsig namespace in the Signature
or SignedInfo element.

In addition, we need to be clear that which production, "canonXML" or "element",
in the C14N specification, to be
used for canonicalizing an element (e.g., SignedInfo element).  "canonXML" is
designed for a whole document, and
it requires an additional new line character at the end of the canonicalized
root element.  I do not see any problem
in using either of them, but we have to be clear about this.


Hiroshi Maruyama
Manager, Internet & Language Technology, Tokyo Research Laboratory
+81-462-73-4576, maruyama@jp.ibm.com
Also Associate Professor, Dept. of Computer Science, Tokyo Institute of
+81-3-5734-3953, maruyama@cs.titech.ac.jp
Received on Wednesday, 3 November 1999 01:12:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:32 UTC