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

RE: Omitting Location and Transforms from SignedInfo

From: John Boyer <jboyer@uwi.com>
Date: Wed, 17 Nov 1999 16:20:35 -0800
To: "Jim Schaad (Exchange)" <jimsch@Exchange.Microsoft.com>
Cc: "DSig Group" <w3c-ietf-xmldsig@w3.org>
Message-ID: <NDBBLAOMJKOFPMBCHJOIAEEBCCAA.jboyer@uwi.com>
> <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>

>
> 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>

>
> The point is that yes, they could push this off to a
> Manifest, but manifests
> rely on application-specific behavior to validate. What we're
> saying is that
> a certain class of signatures cannot be validated by core
> code for reasons
> that don't seem to have anything to do with the needs of the
> application.
>
> It would be much cleaner to design a syntax that, by its
> design, does not
> have us chasing things down outside of the current document.
> I expect it
> will also be somewhat common to have signatures that point to
> things outside
> of the document, and such signatures will need application
> logic to validate
> the signature.  But, at least the need for application validation has
> *something* to do with a direct need of the application--
> esp. given that
> such a need may already depend on application specific
> caching systems,
> resource resolution schemes and so forth.
>
> John Boyer
> Software Development Manager
> UWI.Com -- The Internet Forms Company
>
> </John>
>
> jim
>
Received on Wednesday, 17 November 1999 19:21:32 GMT

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