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

Re: Namespace treatment for C14N

From: <dee3@us.ibm.com>
Date: Mon, 7 Jun 1999 15:59:56 -0400
To: w3c-ietf-xmldsig@w3.org
Message-ID: <8525678A.004F1624.00@D51MTA07.pok.ibm.com>
It's the hash of the URI, not the hash of what the URI points to.

Donald E. Eastlake, 3rd
17 Skyline Drive, Hawthorne, NY 10532 USA
dee3@us.ibm.com   tel: 1-914-784-7913, fax: 1-914-784-3833

home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
dee3@torque.pothole.com   tel: 1-914-276-2668

"Joseph M. Reagle Jr." <reagle@w3.org> on 06/07/99 03:18:55 PM

To:   "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>
cc:   w3c-ietf-xmldsig@w3.org (bcc: Donald Eastlake/Hawthorne/IBM)
Subject:  Re: Namespace treatment for C14N

At 09:19 AM 6/7/99 +0900, Hiroshi Maruyama wrote:
 >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.

Ok. It's nice in that the schema definition language (SDL/DTD) is implicitly
included in the hash. However, this feature is now required on every single
signature. One could argue that there may be some applications that don't
care about the SDL that much (not worth the cost, or off-line), and if they
did, they should include it in the manifest.

 >This is not particularly readable but satisfies the following two
 >  1. B is wellformed  (well-formedness)
 >  2. C14N(B)=B        (fixed point property)

I don't believe it meets #2 does it? If the URI transformation is part of
the C14N, then on re-processing the C14Nizer will not be able to find the
resource and produce the same hash.

Joseph Reagle Jr.
Policy Analyst      mailto:reagle@w3.org
XML-DSig Co-Chair   http://w3.org/People/Reagle/
Received on Tuesday, 8 June 1999 10:24:20 UTC

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