Re: Trying to assess the depth of xml:id and c14n incompatibilities

I still have a fundamental question about the presumed use cases.    Let's 
assume we're dealing with a Web Services scenario, and that (exclusive) 
c14n  is being used at least in part in the obvious way to support dsig, 
I.e. for a given input document, it is the canonicalization that is 
signed.  One of two things is presumably then assumed, and I'm trying to 
figure out which:

I.  The c14n is used only for the signatures.  The original document is 
sent.  The receiver gets something other than the original only in the 
case of a malicious or accidental corruption of the document.

-or-

II. The document is canonicalized and signed.  The canonicalized form is 
transmitted and processed by the receiving application.

I think the implications are somewhat different. 

In the case of assumption I., it seems to me that we have to note that the 
unfortunate handling of xml:id, etc. will cause certain rather carefully 
corrupted documents to be accepted as valid per the signature.  Depending 
on the environment assumed at the receiver, it may also cause correct 
fragments that had no xml:id at the sender but inherited some during c14n 
to be incorrectly rejected (if the receiver does not presume a similar 
container for the fragment).  If we assume option I. we do NOT have to 
worry about how an application will process the results of c14n;  we have 
to be sure that the application is robust against the supurious 
acceptances (e.g. detects the errors itself) and will tolerate or avoid 
the false negatives.  Still serious and disturbing.

Most of this thread seems to have presumed case II, resulting in long 
debates about how a receiving application will interpreted the 
canonicalized form.  I had generally presumed that implementations would 
align with option I, using the c14n primarily for signing.

I'm curious to hear from the c14n experts on this thread:  which is it? We 
do have serious problems either way, but I think that they are somewhat 
less daunting assuming option I.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Friday, 18 February 2005 16:56:49 UTC