RE: Omitting Location and Transforms from SignedInfo

That is not at all what I am proposing.  I think it is just fine to sign
something that is not a manifest and is not in the current document.  What I
am stating is that if the application does not want the behavior that we
automatically go and try to verify what is being signed, then it goes in a
manifest.  If you want to have the core code automatically very what is
being signed, it can be in the SignerInfo object.  The locality of the data
is unimportant.

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

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.

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 18:58:28 UTC