RE: The XML-DSig Non-standard, or Location/Transforms as 'hints'

Hi Dave,

Your messages always show up enclosed in a text file called BDY.TXT.  Maybe
it's a bug in Outlook or in someone's mailserver.

Anyway, I'll copy your message below:

John,

Actually, both are true.  The point is, if I sign paragraph X (a bunch of 
bytes), then thats what I've signed whether the paragraph is a standalone 
object, retrieved via the net, or extracted from a larger document.   

<John>
I agree that that is what the signer wants to sign regardless of how it is
obtained.  Clearly, though, our current formulation signs more than that or
we would not be having this conversation.
</John>

The thing  I believe everyone (except perhaps you) agreed to yesterday is
that while 
target and transforms can be relied upon to tell the core code how to obtain

paragraph X (your point 1), a signature is not automatically invalid if 
paragraph X is obtained a different way (your point 2) [i.e. performing the 
specified transforms is not semantically required for signature validation].


<John>
Again agreed except that if the paragraph X cannot be obtained by the
*signed* target and transforms, then core code has no way of finding
paragraph X without relying on application-specific logic.
</John>

The only assertion made by the signature is that that exact collection of 
bytes, paragraph X, was signed.  The fact that paragraph X was extracted
from 
document Y is in no way cryptographically assured by the XML signature
unless I 
include object references both to paragraph X and to document Y (and perform

additional external validation).

<John>
Firstly, when acrimony began at the IETF meeting, Phil asserted quite
vociferously that the signature on Location was absolutely essential and
that the signature should break if the result of dereferencing Location and
applying DigestMethod does not match the DigestValue.  He further asserted
that failure to sign Location was an insecurity.
I agree with him that for many applications this is true, and I agree with
you that if that is what the user wanted, then they can put an
ObjectReference in place that signs the Location too.

So, I'm not talking about what is cryptographically assured.  I'm talking
about how core code is going to find X so that it can do the cryptography.
Nothing in this letter refutes the essence of the problem I'm trying to get
us to solve, which is solvable, and which everyone seems to think 'Location
as hint' solves because their seems to be no recognition of the fact that
'Location as hint' = application-specific signature with no
interoperability.

I'm trying to design an XML document processing module that receives a
document, regardless of what company it came from, and validates the
signature in that document before proceeding to do other work with the
document.  I have one of two choices:

1) With Location as hint, I have to create a module that understands the
application-specific Location resolution scheme of each business whose
documents I want to process.  As time goes on, I will need a small army to
keep my document processor up to date with the inevitable changes that these
people will make.
2) With Location as location (or target as target, it's still a rose!), I
read the location and dereference.  The application is not involved in
defining how core code digs up X.

Furthermore, the Location as hint paradigm becomes laughable in the
following scenario:

Consider CompanyA and CompanyB.  CompanyA produces a document D used by
CompanyB.  The document D is located at http://www.CompanyA.com/documentD.
CompanyB creates many signed documents with ObjectReferences to D.  CompanyA
decides to update document D at some time MMDDYYYY, but cannot or for
whatever reason does not use a different URL.  This breaks all of CompanyB's
existing signatures.

The 'Location as hint' solution says that CompanyB should make a copy of D
and put it at location http://www.CompanyB.com/documentD, then define the
URL http://www.CompanyA.com/documentD as being a 'hint' to get
http://www.CompanyB.com/documentD.  This is a lovely scheme until CompanyB
decides that they want to use the updated documentD in their new signatures
(as would be the case in legal scenarios).  Now what does company B have to
do.  Somehow, it has to get its URL resolution code to accept a date
mmddyyyy.  

If Date(signed document) < MMDDYYYY, then 
	http://www.CompanyA.com/documentD ->
http://www.CompanyB.com/documentD
else	http://www.CompanyA.com/documentD ->
http://www.CompanyA.com/documentD

I don't know of any socket implementation that allows GetHostName() to be
date specific, so it's a sure bet this would have to be done by custom code
in the application.

Now iterate this over a ten year period.

Now apply the idea (whether custom code or in a configuration file) to the
generic XML document processor, which would have to know about this little
kludge for each company that it has to service.

Can you actually write another letter telling me why *this* interoperability
situation is just a figment of my imagination?

Because there does seem to be a relatively easy fix, and I can't figure out
why this is such a big deal (so it would be nice to actually discuss that
too).

BTW, the generic XML document processor is really just an example.  The
'philosophy' of XML (if there truly is such a thing) it to make human
readable data so that applications other than the one that created the data
can read and process the data.  Why am I the only one who feels that
Location as hint violates this XML philosophy?

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company
 
</John>

Dave

>  -----Original Message-----
> From: 	w3c-ietf-xmldsig-request@w3.org
> [mailto:w3c-ietf-xmldsig-request@w3.org]  On Behalf Of
> david.solo@citicorp.com
> Sent:	Friday, November 19, 1999 5:47 AM
> To:	jboyer@uwi.com; w3c-ietf-xmldsig@w3.org
> Subject:	RE: The XML-DSig Non-standard, or Location/Transforms as
> 'hints'
> 
>  << File: BDY.TXT >>  << File: WINMAIL.DAT >>