Re: importing terminology in "XML-Signature Requirements"

rdbrown@Globeset.com wrote:

> > This also touches on the issue of being able to sign
> > the original content (the PDF file) instead of the encoded
> > and attached version of the original content.
> > Richard: how did you propose to do this?
>
> If you refer to the proposal I did to Richard Himes, it consists of
> packaging the encoded content of the resource and the detached signature in
> a single XML document. The encoded content is encapsulated in an XML element
> that displays the encoding scheme as well as the 'Web locator' associated
> with the resource, whose content is being encapsulated. This proposal
> assumed that the application would decode and 'cache' the packaged resources
> (or at least emulate such behaviors) before verification of the Resource
> elements contained in the signature Manifest. Notice that this proposal has
> been made in the context of a specific application and did not try to
> address the problem in general.

I don't know what you mean by the general problem, Richard.  Would the "general"
solution be intractable or would it be a significant diversion?  Or would it be
cleaner?  I was wondering if it would be reasonable to use an internal link, and
describe the situation in the manifest (i.e. the hash is on the unencoded
content of the thing pointed to by the locator) rather than using a common
origin/href value.

Thanks,
Rich

Received on Friday, 23 July 1999 18:35:07 UTC