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