RE: unparsed entities

John,

A signature core should not have to "chase" anything. It shall be provided
by the upper application layer with the elements that it is supposed to
process. A signature core has no knowledge about transport or any other
application specific behaviors. The XML Signature Standard should only
define adequate syntax and cryptographic procedures so that XDFL and others
can build on top of a generic signature core. It seems unreasonable to
expect the Signature Standard to provide for all conceivable application
frameworks. In general, the application layers adapt with existing core
technology - not the opposite. PKCS7 and CMS are by far much more
restrictive than proposed XML Signature Standards. Nonetheless, the Industry
has been able to leverage and to proceed with these standards for several
years.

However, studying the security requirements of a large variety of
application frameworks up front is of a great benefit to a standardization
effort. These many application frameworks constitute an unvaluable test-bed
for validating the adequacy of the standard. But, at the end, only a few
will suffice with the core specifications. Certainly, you will have to
define some XDFL component to "chase" the links and to embed the graphics
into the form document. But, you will be able to leverage a Standard
Signature Core to encode and to compute the signature.

Sincerely,

Richard D. Brown
Software Architect - R&D
GlobeSet, Inc. Austin TX - U.S.


> -----Original Message-----
> From: w3c-xml-sig-ws-request@w3.org
> [mailto:w3c-xml-sig-ws-request@w3.org]On Behalf Of John Boyer
> Sent: Tuesday, April 06, 1999 1:38 PM
> To: Dsig group
> Subject: Re: unparsed entities
>
>
> Hi Donald,
>
> Canadian holiday yesterday.  Back in the saddle today!
>
> It may not seem so, but I think we're not that far off in our
> opinions.  In
> my opinion, the signature software should chase down
> references that were
> chased down in order to render the document.  Whether it is
> in a format that
> is opaque to XML or whether it is an XML reference, if it was
> necessary to
> chase it down in order to show the document to the signer, then it is
> necessarily part of the context of the signature.  Further,
> if the link was
> able to be resolved by the software for the purpose of
> rendering, then it is
> reasonable to require the software to follow the link again
> for the purpose
> of generating a message to be hashed.  Digital signatures will end in
> disservice if there is a significant difference between what
> the user does
> sign and what the user thinks he/she is signing.
>
> Note, however, that XFDL also has links to other documents
> that don't get
> dragged in and signed.  In particular, some of the links are
> actually upload
> links that tell where to submit the completed form, so the
> return value of
> the link would be the next form in a sequence or a "your form
> was received"
> notification.  It's understood that there will be cases where the link
> cannot and should not be followed.  In order to avoid some of these
> problems, XFDL used the simplest possible solution:  it
> doesn't allow links
> to objects that need to be included in the signature.  If you
> want an image
> to be rendered, you put the image in the form.  So, any actual links
> appearing in XFDL are assumed to not be required to
> constitute the full
> context of the transaction.  Obviously, this won't be sufficient for a
> generic signed XML specification, but by taking the view that
> there are two
> different kinds of links w.r.t. signatures, it should be
> evident that this
> is, conceptually, a variation of the signature filters
> problem.  A filter is
> a way of specifying what goes and what stays in a signature.
> As soon as you
> give this power to form designers, you give them the power to
> omit the full
> context of a transaction, which can make for useless digital
> signatures.
>
> So, I agree with your statement that "what we want is a low level
> syntax/mechanism for signing/verifying XML and anything
> else."  However, it
> is not sufficient to only sign references or to pull in only
> a hash of the
> external entity, as I thought was being suggested in the
> emails to which I
> was responding.  Such a syntax must have the ability to
> exclude the content
> at certain links, but it *must* also have the ability to drag
> in externally
> defined objects as part of the signature context, and this is
> a point on
> which we agree based on examples in your email.
>
> In the end, it seems that because XML is devoid of semantics,
> it will be
> impossible for the language to prevent developers from
> misapplying digital
> signatures.  The best we can achieve is to make it easier to
> create good
> signatures and harder to create bad signatures.
>
> John Boyer
> Software Development Manager
> UWI.Com -- The Internet Forms Company
> jboyer@uwi.com
>

Received on Tuesday, 6 April 1999 16:20:12 UTC