Re: Understanding what Signed XML is used for - Was: Re: importi

Todd,

Please see below.

tog wrote:

> Richard -  What I am have been saying is that I am concerned that there may
> be no single end-user solution here for pure XML by itself, and without a
> solid understanding as to the end-use models for the envelope itself.
> ---

Right, there is no single end-user solution.  XML provides the capabilities, we
adopt them for our use within those restrictions.

> As an opener let me say that as to using XML as *the* transport for credible
> and open-transactions is a very exciting possibility, but that there are
> some use-model specific issues that the language, XML, cannot, in my
> opinion, address by itself. These need either context specific standards
> written for them or they need to be handled at the application level.

The envelope discussion is occurring within the legal-XML effort, and I'm not
trying to generalize it for the DSig standard.  I don't have a mental construct
for your term "use-model", but if it involves information (context) transfer,
XML is probably more than adequate.  If it means legacy formats, then this
information will have to be hacked in, perhaps as binary data.  If it goes
beyond information, I'm lost.

> This 'encapsulating PDF files in XML structure' thread illustrates this
> exactly. The point of XML is to make the content "hot" or easily acted upon.
> If we embed a PDF structure inside this document, then how is it still a PDF
> document, and what is the cross-over between PDF and XML  (Verity?...
> Someone from Adobe want to jump in here?) - also don't forget the
> timestamping. Its important.

I don't have a problem base64-encoding the PDF document.  Keeps it cool.  We can
easily make it "hot" when we need to display it.

> Bluntly, my biggest concern here is that I think that the XML thing is being
> spread too thin, that there are some protocol based service models that
> would be better done other ways like as applications for instance. Also that
> we don't have clearly defined service models yet that make sense in the real
> world.  So what do we do? - My first thing is that we should come to an
> immediate understanding what we are trying to do explicitly, and for what
> purpose it is supposed to serve. If our goal is an interoperable set of
> methods for authenticating XML borne structures? - OK - then what are the
> use models for these authentications:
>

We allow non-XML structures (PDF, GIF, MPEG) to be embedded within XML and
signed.  Application designers decide if this or some other standard best fits
their needs.  If this standard adds value (flexibility, information,
standardization, etc.) in the eye of the designer, then the tool can be used to
help solve yet another problem.

There are (at least) three potential ways to sign this data:
1.  Include the hash of the (canonicalized) <Package> element and its contents
in
     the manifest.  This means the hash computation is based on the
base64-encoded
     binary data and the surrounding elements.  Sign (canonicalize/hash/sign)
the
     resulting manifest.  This is my understanding of the current Brown
proposal.
2.  Include the hash of the unencoded document in the manifest and sign the
     manifest.
3.  Include the algorithms used in the manifest, but carry the signature of the
     unencoded document ("imported" signature).

I believe we should have the second approach as an option at a minimum.  I'm
still trying to convince myself that this would be sufficient.  For example, an
imported signature could perhaps be validated and converted back into a hash for
manifest signature.  If I have become misled as to the current situation, I
would appreciate clarification.

> 1)    The first model is I think as Barb Fox so rightly pointed out, is a
> document that is ready for its final processing instance. That is to say it
> is presented to the end-user (or consumer) as a conceptually flattened
> structure, and then the somehow each signature process further layers
> another flattened structure atop the previous one. BTW - I am beginning to
> think that the idea that a DigSig should be an inline structure is
> potentially a shortcoming and that we should allow the user to say where the
> signatures are to be stored as part of the tag structure itself.

This went over me or by me or something.  Suppose we have embedded a base64
encoded PDF in XML.  Is the final processing instance the unencoded PDF?  Is it
the presentation bitmap on the screen or piece of paper?   Is a flattened
structure  the surface string?  I believe we should be able to sign a PDF in its
unencoded format as an option, as I stated above.

> 2)   The second is a little more insidious than Barb lead on though I think,
> This is a 'document' that is a recurring process, and as such is likely to
> be repeatedly opened and closed, edited, signed, and resigned... and this
> may not be such a great thing to do in pure XML without the envelope
> framework.

I think you pay for this somewhere (regardless of whether you use XML or not.)
A signed document freezes that document.  A modified document breaks the
existing signature, and it can be resigned.  This is as it should be.  I think a
cool way  around it would be to separate the new changes from the document (sort
of like a database transaction log) and each modifier can sign their document
version.  This would make it possible to walk historically backward through the
changes, verifying each signed version along the way.

> So if we are just doing #1 then what are the uses? - A digital contract in
> its final form, I send it to you already containing my initial signature of
> the terms and conditions and you sign it in return. The two tokens are
> maintained in several structure perhaps to prove who signed first and when,
> also there are the attendant timestamps with the signature blobs... The
> auditor's, if we have a trusted third party can be done as layered on ours
> or as a side-by-side process, depending on the audit models, but both are
> supportable at the application level I think.
>
> Lets look at a contract-envelope in particular, as a process for doing a
> recurring or repetitive negotiations process, the envelope that the contract
> core sits in will have to support some reliable type of journaling. While
> for the instance where the contract type is specific to humans, they don't
> necessarily need to resign the changing terms and conditions in a contract
> until they came to terms, but take the humans and our cognoscente out of the
> picture and then the model must support journaling and the audit trail it
> mandates.

Agreed.

> Because of these use criteria and limitations generic digitally signed XML
> may actually be somewhat limited in its use scope because it was designed
> with the idea that one of the partners was alive.
>
> I propose that perhaps what we may really need is a digital-envelope
> standard that we can pour XML into. The envelope could address the
> persistence of the XML objects and would likely solve a number of other
> E-Commerce related enveloping issues if we were to take this on. The idea is
> that maybe core XML is ok just the way it is, and that the admin functions,
> that is to say the envelope control, the signing process, should be a
> separate framework form the content itself - or it may be deferred to the
> application's use of the Core XML standard.

Again, these conclusions escape me, and appear to add more darkness than light
to the problem IMO.  XML documents can be enclosed in an XML envelope for this
purpose, seems to me, but this may not work in a general sense (e.g. there is a
problem with doctypes, but namespaces help.)

> This is very important since it directly conflicts with the existing XML
> belief that these authentication structures all need to be inline in the XML
> Source Stream.

I thought inline authentication (for a particular application) was an option,
not a requirement.

> Just my 2 cents...
>
> Todd

Thanks,
Rich

P.S. - I took the liberty of including the list in distribution, because it
looked to me
as if that was your original intent.

> ----- Original Message -----
> From: Richard Himes <rhimes@nmcourt.fed.us>
> To: <w3c-ietf-xmldsig@w3.org>
> Sent: Sunday, July 25, 1999 2:48 PM
> Subject: Re: importing terminology in "XML-Signature Requirements"
>
> > Todd,
> >
> > 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.
> >
> > Thanks,
> > Rich
> >
> > 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 Wednesday, 28 July 1999 16:41:50 UTC