RE: Re[2]: Omitting Location and Transforms from SignedInfo

It seems to me that the basic issue here is that we're using Transforms for
two things:

1.  To refine the definition of what is being signed in the document
2.  To assist in retrieving the document in the appropriate form

An example of the first is using XSLT (or XPath) to define which part of a
given document the signature is over; an example of the second is base64
decoding.

It is critical that the first type of transform be signed.  It seems equally
critical that the latter type not be signed if the location is to not be
signed, since different locations fairly naturally will have different
encoding.

At first I was thinking, well, why don't we just put all transforms outside
SignedInfo?  You can't actually tamper with what is signed anyway, that is
the entire point of digest algorithms.  But particularly with XSLT the
possibilities for misrepresentation are vast.  

For example, I might sign a document declaring that green is my favorite
colour.  Mallory (my unscrupulous interior decorator) might create a
contract that say I agree to pay him $100,000 for services rendered, and
then write XSLT to transform that document into my assertion of colour
preference.  Place that XSLT in a Transform outside of SignedInfo and the
signature will happily verify.  Now, I doubt it would stand up in court, but
I don't want to have to go to court.  In automated business-to-business
scenarios this would be particularly frightening, because the transactions
might not be put in front of human eyes.

Proposal 1:
* allow Transforms both inside and outside SignedInfo
* allow Location either inside or outside SignedInfo
* specify that applications are to limit Transforms outside of SignedInfo to
the set of algorithms that they trust

I don’t like this.  I think it is complicated, and there is bound to be
either trust or interoperability problems with the "set of algorithms that
they trust" part.

Proposal 2:
* Transforms are in SignedInfo
* Location is in SignedInfo
* view Location only as a hint
* applications can use non-signature information to find the object and
transform it into something appropriate to feed into the Transforms

I prefer this.  The assumption is that if the application knows how to find
the object without using Location, it can also know or determine what format
it is in (possibly from extra markup passed along with the signature).

Perhaps if we are taking the "Location is only a hint" view, we should
rename the element to LocationHint.  Otherwise people *will* get confused.

Basically I've just rephrased arguments other people have made into a form
that is more clear to me.

-Mark Bartel
JetForm Corporation

-----Original Message-----
From: rhimes@nmcourt.fed.us
To: w3c-ietf-xmldsig@w3.org
Sent: 11/17/99 3:13 PM
Subject: Re[2]: Omitting Location and Transforms from SignedInfo 


Mary,

An XSL transform could restructure the document in countless ways, so it
wouldn't help to name it, I don't think.  Perhaps your industry (and
others)
will have to restrict the types of transform that can be done.  The key
to me is
whether the transformed document is closer to the "signature context"
(see
below).

It probably depends on the problem being addressed.  These transforms
could
conceivably themselves be signed by a trusted application.  Seems likely
to me,
though, that these transforms would generally be part of the document
rather
than separate transforms.  I believe John Boyer has good arguments for
keeping
transforms separate for XFDL, where different pieces of the document are
signed
by different individuals.

It is the opinion of John Boyer, Todd Vincent, myself, and others that
(where
applicable) the signature should be applied to a format of the document
as close
as possible to the presentation format, so that users essentially sign
what they
see.  For example, it makes more sense (to me) to sign a PDF document
than to
sign the base64-encoded PDF document.  Thus, the original PDF would be
signed in
its native format.  If that PDF were base64-encoded for inclusion in an
XML
document, the "required" transform would be to base64-decode it before
authentication.  Note that we can only push so far toward the
presentation
layer.  It probably doesn't make sense to sign the pixels on the display
screen
(not saying nobody will try this.)

Rich

____________________Reply Separator____________________
Subject:    Re: Omitting Location and Transforms from SignedInfo 
Author: <w3c-ietf-xmldsig@w3.org>
Date:       11/17/99 2:03 PM

To: XML Digital Signature Working Group

Rich has suggested naming a transform. This prompts my comment.

rhimes@nmcourt.fed.us wrote:  <snip>

> If we have a transform which says "if and only if the document is
base64
> encoded, decode it", I believe we should have a standard way of
identifying
the
> state of the document as base64-encoded (outside SignedInfo).
Otherwise, I
> believe transforms belong outside SignedInfo, and the transform should
be just
> "base64-decode".
>
> <snip>

I have had some audit experience in banking as well as information
security. I
approach the issue by asking: "How will I describe to the business,
auditor, and
information security specialists exactly what is being signed?"

I view transforms as a type of "macro" with full computational powers.
Thus the
business (signer) is signing an algorithm to act on data. If any
transform can
be
placed in signed data, how will the business signer or relying party be
able to
determine exactly what the effects of the transform are to the
satisfaction of
their
auditors?  I think this will be difficult to explain at best.

At the DC IETF WG meeting, several example transforms were suggested. I
could
see
the business need for many of the examples.  I was just uncomfortable
with
having
arbitrarily constructed transforms.

Admittedly, "base64 encoding" is an algorithm (transform) operating on
the data,
but
the algorithm/concept has been fully vetted and reviewed by many parties
in the
standards and security community. I have been able to explain "base64
encode/decode"
to auditors and business with success relying on the existing extensive
review
literature.

 Following the example of  "base64", I believe that transforms must be
"named,"
well
known algorithms with review by standards bodies. If this is the case, I
can see
explaining to auditors and business that the transforms need to be part
of the
signedinfo, and they are fixed, well defined, named, and vetted
transforms.

--
-------------------------------------------------------------------
Mack Hicks, SVP     mack.hicks@bankofamerica.com
Bank of America  +1-415-436-5809



 

 <<RFC822.TXT>>

Received on Wednesday, 17 November 1999 17:31:55 UTC