W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > January to March 2000

RE: Difficulties with URI="" and IDREF

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Tue, 04 Jan 2000 16:11:28 -0500
Message-Id: <3.0.5.32.20000104161128.00b98660@localhost>
To: "John Boyer" <jboyer@uwi.com>
Cc: "Andreas Schmidt" <aschmidt@darmstadt.gmd.de>, <Gregor.Karlinger@iaik.at>, "XMLDSig WG mailing list" <w3c-ietf-xmldsig@w3.org>
At 10:38 00/01/04 -0800, John Boyer wrote:
 >Note to editors: If exclusive-or was intended, then perhaps the word
 >'either' can be inserted to clear that up, and if inclusive-or was
intended,
 >then perhaps 'or both' can be appended.

It is supposed to be 'or', I will note we need to make this clearer for the
next version.

 >So, like IDREF, the bytes corresponding to URI="" would seem to be
 >application-specific, which is bad for interoperable signatures.

I agree. 

   4.2. Same-document References
   A URI reference that does not contain a URI is a reference to the
   current document.  In other words, an empty URI reference within a
   document is interpreted as a reference to the start of that document,
   and a reference containing only a fragment identifier is a reference
   to the identified fragment of that document.  Traversal of such a
   reference should not result in an additional retrieval action.
   However, if the URI reference occurs in a context that is always
   intended to result in a new request, as in the case of HTML's FORM
   element, then an empty URI reference represents the base URI of the
   current document and should be replaced by that URI when transformed
   into a request.
   http://www.ietf.org/rfc/rfc2396.txt

RFC2396 does leads me to think that this will be dependent on the receiving
application. I'll give this some more thought and ask some colleagues if
they think this is the same class of problem as XPath/IDREF.

 >Furthermore, Andreas recommended that dropping SignatureValue should be
done
 >automatically.  I would agree insofar as this is precisely what we did when
 >defining XFDL's signature methodology. However, doing this automatic
 >omission increases the number of signatures that will be created using
 >URI="" but notransforms, which means no c14n, which means troubles of the
 >type described above.  Thus, it is probably a good idea to have the
 >SignatureValue omission spelled out (esp. since the work of omitting
 >SignatureValue must be done even if the document doesn't spell it out).
 
So far we've been able to have the core processing rules avoid doing XML
things: XML things do XML things, and the processing rules do
byte/cryptographic things. I'd like to keep it this way as I fear the
interactions between XML processing within the documents and transforms
getting mixed with our own 'custom' XML processing rules.

_________________________________________________________
Joseph Reagle Jr.   
Policy Analyst           mailto:reagle@w3.org
XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
Received on Tuesday, 4 January 2000 16:12:10 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:08 GMT