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

RE: Omitting Location and Transforms from SignedInfo

From: Jim Schaad (Exchange) <jimsch@Exchange.Microsoft.com>
Date: Wed, 17 Nov 1999 16:29:19 -0800
Message-ID: <EAB5B8B61A04684198FF1D0C1B3ACD194A712C@dino.dns.microsoft.com>
To: "'John Boyer'" <jboyer@uwi.com>
Cc: DSig Group <w3c-ietf-xmldsig@w3.org>


> -----Original Message-----
> From: John Boyer [mailto:jboyer@uwi.com]
> Sent: Wednesday, November 17, 1999 4:21 PM
> To: Jim Schaad (Exchange)
> Cc: DSig Group
> Subject: RE: Omitting Location and Transforms from SignedInfo
> 
> 
> > <John>
> > Oh, I thought I'd already said why that wasn't such a hot idea.
> >
> > 1) We want core code to automatically verify the DigestValue of
> > ObjectReference because this is equivalent to verifying the
> > bulk of the data
> > that the signer actually wanted to sign.
> 
> I don't know that I agree with this statement, but it's not 
> that important.
> Verifying that a manifest is correct does not validate any 
> large amount of
> data.
> 
> <John>
> Are you saying that it's not that important that we sign the 
> actual data
> that a person using a private key actually wanted to sign???
> </John>

Yes and No.  I agree that it is important to sign the data, however signing
a digest of the data, and thus signing the original data indirectly, is not
a problem.  If you look at CMS, given that most people include authenticated
attribute, you never actually sign the data.  You sign the digest of the
data and the authenticated attributes.

> 
> >
> > 2) The core rules automatically verify DigestValue of
> > ObjectReference if and
> > only if Location is invariant once the signature is created.
> > If the Location
> > of a piece of data is expected to change, then our core
> > processing rules
> > cannot accommodate the signature.  This has nothing to do
> > with some weird
> > application-specific need that only a handful of people have.
> >  Locations
> > change, auxiliary documents get updated.  If someone wants to
> > preserve a
> > signature, they may need to change a Location here or there.
> > This is likely
> > to be a commonplace event with long-term signatures on
> > high-value documents.
> 
> I disagree with this statement.  I believe that the if and 
> only if statement
> is wrong, and everything following from that is therefore 
> also incorrect.
> 
> <John>
> It doesn't help to disagree without giving reasons.
> The if and only if statement is not wrong.  The core rules sign the
> Location; how can you move the object to a different location without
> breaking the signature???
> </John>
>

As my previous mail has stated.  Location is a hint for where the document
is.  It is not the be-all and end-all for locating the document.  If the
application wants to enforce that this is the only location -- that is fine.
If the application wants to say that the data is someplace else -- that is
fine.  The fact that you update the document at a URL location will not
allow you to repudiate the fact that you signed the document.  I can cache
the document locally and take that copy into court when attempting to
enforce your signature.

jim
Received on Wednesday, 17 November 1999 19:29:24 GMT

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