Re: Namespace treatment for C14N

Appears to be a nice solution. But I believe that it needs 
some way to carry the digest algorithm used and any required
associated parameters. Otherwise, the approach might not easily 
survive change. (It struck me that sha-1 might be preferable to
md5.)

Hiroshi Maruyama wrote:
> 
> Joseph,
> I have been following the discussion on C14N of the Syntax group.  One of
> the things that are not resolved is how to handle namespace prefixes.
> Here is an idea that Donald and I came up with.
> 
> 1. Namespace prefixes are always expanded to its original URI (including
> the default namespace)
> 2. Hex coding of MD5 of the Expanded URI is used as the new prefix.
> 
> Here is an example
> 
> Document A
> ===========
> <?xml version="1.0" encoding="Shift_JIS"?>
> <root>
>  <hello xmlns:myns="http://monet.trl.ibm.com/myschema"
>         xmlns="http://default.sch">
>    <myns:goodbye/>
>  </hello>
> </root>
> 
> The canonical form of this document may look like this.
> Document B = C14N(A)
> ====================
> <?xml version="1.0" encoding="UTF-8"?>
> <root>
>  <_596C7D3063274C61632270212A4E5667:hello
> xmlns:_5628413F365675591241005E3B123D63="http://monet.trl.ibm.com/myschema"
> xmlns:_596C7D3063274C61632270212A4E5667="http://default.sch">
> 
> <_5628413F365675591241005E3B123D63:goodbye></_5628413F365675591241005E3B123
> D63:goodbye>
>  </_596C7D3063274C61632270212A4E5667:hello>
> </root>
> 
> Here, the MD5 values of "http://monet.trl.ibm.com" and "http://default.sch"
> are 5628413F365675591241005E3B123D63 and 596C7D3063274C61632270212A4E5667,
> respectively.  We need the underscore character to make it a legal XML
> name.
> 
> This is not particularly readable but satisfies the following two
> requirements.
>   1. B is wellformed  (well-formedness)
>   2. C14N(B)=B        (fixed point property)
> 
> --
> Hiroshi Maruyama
> Manager, Network Applications, 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
> 
> From: "Joseph M. Reagle Jr." <reagle@w3.org> on 99/06/03 09:00 PM
> 
> To:   "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
> cc:    (bcc: Hiroshi Maruyama/Japan/IBM)
> Subject:  XML Infoset (Minutes:1999.06.02 XML Syntax WG)
> 
> Note that the XML people have identified a significant amount of overlap
> between C14N (Canonicalization) and the Infoset working group. If people
> are
> interested in the C14N issues, I suggest they look at the most recent
> Infoset Draft. [1] I hope the Syntax WG will have a first public WD prior
> to
> the IETF meeting -- but I'm not convinced we will.
> 
> [1] http://www.w3.org/TR/xml-infoset
> 
> Forwarded Text ----
>  Date: Wed, 02 Jun 1999 22:12:29 -0700
>  To: "XML Syntax WG" <w3c-xml-syntax-wg@w3.org>
>  From: Tim Bray <tbray@textuality.com>
>  Subject: Minutes:1999.06.02 XML Syntax WG
> 
> ...
>  4. Canonicalization
> 
>  NOTE: James Tauber *does* have time to put into this, but wants a
>        co-editor
>  ACTION: Chairs to recruit co-editor
> 
>  Issue: possible overlap with Infoset
>  CONSENSUS: There is a real co-ordination issue here
>  CONSENSUS: Portions of XML documents considered "Required" should be
>             identical to that included in the canonical form.
>  ACTION: T.Bray to send message to Megginson, cc the CG, noting this.
>  CONSENSUS: In section 3, use infoset terminology & be consistent
>  ACTION: T.Bray, to XML-i-fy the spec
>  CONSENSUS: Express the material in section 4 in algorithms
> 
> End Forwarded Text ----
> _________________________________________________________
> Joseph Reagle Jr.
> Policy Analyst      mailto:reagle@w3.org
> XML-DSig Co-Chair   http://w3.org/People/Reagle/

 
Phil
----
Phillip H. Griffin        Griffin Consulting
asn1@mindspring.com       Secure ASN.1 Design & Implementation
+1-919-832-7008           1625 Glenwood Avenue, Five Points
+1-919-832-7390 [fax]     Raleigh, North Carolina  27608  USA
--------------------------------------------------------------

Received on Tuesday, 8 June 1999 18:03:07 UTC