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

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

Yes but is it anything more than content transfer, that is the question.

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

Except that the PDF viewer has to be fired up every time to interpret the
PDF object. Inline, every time. This is clearly about "lets look at it" XML,
and not XML - the do it for everything solution. I want to use XML to encase
a transaction processing stream that will never see a browser.

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

That seems reasonable to me...

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

Signing the PDF file is a no-brianer, its being able to use the contents of
the PDF file that is the win here.

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

Actually that doesn't sound out of line.

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

But that is the point. I think that what you and the other core XML team
have done is really fantastic. I just want it to do more than  be a
presentation language. I don't know if you ever had any experience with
TECO, and old DEC Text editor, but it was so powerful I could write TECO
macros faster than Fortran code. My point in bring up this arcane analog is
that XML has a real potential to support some really interesting transaction
processes as the transport and framework for the event and proofing
services.

To do this we need to address the timestamping, signature, and timebase
services models so that the system, has a credible proofing system inherent
with its design. Also that these models are available to all processes. To
limit the scope of the intended use to presetnation instruments is, well
shooting just a tad bit low IMHO.

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

Actually it wasn't but what th heck, I would have said these things sooner
or later...

>
> > ----- 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 Thursday, 29 July 1999 10:41:01 UTC