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

Re: importing terminology in "XML-Signature Requirements"

From: Richard Himes <rhimes@nmcourt.fed.us>
Date: Sun, 25 Jul 1999 15:48:00 -0600
Message-ID: <379B860F.B7702BBA@nmcourt.fed.us>
To: w3c-ietf-xmldsig@w3.org

These are good examples of the general problem I was trying to address, that is,
if you have an existing signature and the signed document (perhaps legacy data),
would it be possible to embed both in an XML document (with internal reference),
within the documented framework of the DSig spec?  I don't think it is possible
without using local extensions, which will lead to incompatible implementation
by those of us facing this problem.  The recent discussions about the problems
with external references only magnify my concerns.  We have legacy signed PDF
documents now (signed by the court).

I don't know anything about the format of the signatures you refer to, and I
don't know if they have any manifest data.  If they do, I can see that it could
be difficult to map the manifest data in a general sense.  I gather from
Richard's previous comments that there are security problems with a signature
that has no manifest, so this may be an issue.  I believe the same problem would
be encountered with e-mail signatures, and I suspect that packaging these and
pre-signed PDF (etc.) in XML for search engines sounds like a reasonable thing
to do.

I would be interested in more discussion as to the general difficulty, if any,
of wrapping existing signatures (along with algorithm descriptions, certificate
references, etc.) and also embedding the base64-encoded source document.


w3c-ietf-xmldsig@w3.org wrote:

> 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 Sunday, 25 July 1999 17:49:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:09:55 UTC