Re: importing terminology in "XML-Signature Requirements"

How will you address digitally signed PDF files that were signed by any of
the commercially available signing engines, Adobe's, Verisign's or either of
the other two commercial ones included on the Acrobat4 Distribution Kit CD.

Todd
----- Original Message -----
From: Richard Himes <rhimes@nmcourt.fed.us>
To: <w3c-ietf-xmldsig@w3.org>
Cc: 'IETF/W3C XML-DSig WG' <w3c-ietf-xmldsig@w3.org>
Sent: Friday, July 23, 1999 3:33 PM
Subject: 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 20:20:15 UTC