- 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
Donald, 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. <!ATTLIST SignedInfo Id CDATA #IMPLIED> 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 -- 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 Technology +81-3-5734-3953, maruyama@cs.titech.ac.jp
Received on Wednesday, 3 November 1999 01:12:52 UTC