RE: Omitting Location and Transforms from SignedInfo

Hi Greg,

This is not a motivation for changing the name to target.  A rose by any
other name...
What we're saying here is that we've introduced an assertion about the data
that we can't get rid of unless we push signature validation rules from core
behavior to the application.

This is quite problematic.  Our core processing rules state that we verify
SignedInfo, then we verify the digest values of the ObjectReferences.  HOW
IS CORE BEHAVIOR GOING TO DO THIS IF CORE BEHAVIOR DOESN'T KNOW HOW TO
RETRIEVE THE DATA?  You can't put application-specific rules on the
retrieval unless you want to have a complex implementation involving the
definition of call-back functions from core into the application.

No, Location/target/reference/foobar needs to act like it should on the web,
and "clever" application-specific URI resolution is a bad idea.

The use of Manifest to solve this problem would be more appropriate, except
that it still ultimately pushes validation of the actual data that the
signer wants to sign from core to application (but it least it does so in
markup rather than by implied processing rules).  The point remains that the
signer wants to sign the objects referenced, and we can't do that without
binding the location/target/reference/foobar.  With the current design we
are forced to detach from core behavior the authentication of the data that
the signer intended to sign.

Finally, I don't believe that we burden relying party more than the relying
party is already burdened with transforms on the ObjectReferences, which are
the things the signer actually intended to sign in the first place.
However, I would be satisfied with a simpler solution like an attribute that
drops location and transforms from ObjectReference.  My main point is that
whatever solution we choose, we must be able to omit Location and Transforms
of ObjectReferences as core behavior because it is we who introduced this
problem by our particular design.  Applications are not 'weird' for wanting
to sign only the data and not the location.

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company




-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Greg Whitehead
Sent: Thursday, November 11, 1999 4:28 PM
To: DSig Group
Subject: RE: Omitting Location and Transforms from SignedInfo


I think the disconnect between those who want to omit location from the
signature, and those who oppose its omission, is the focus on URLs and the
act of object retrieval. This is the motivation for changing the name from
location to target or reference.

The requirement on location is that it bind the digest value, and hence the
signature, to the object being signed. If that's achieved through a URL,
then fine. If that's achieved through a URI and some application specific
mechanism for locating the object, that's fine too.

If you're not going to sign the reference to the object being signed
(location), you might as well omit it all together. This is allowed by the
current syntax if you restrict yourself to one object per signature and
leave the association to the application (this is how pkcs-7 detached
signatures work).

I'm VERY uncomfortable with the introduction of a mechansim to omit
arbitrary elements from SignedInfo. Call it fear or just good sense. ;-)

In particular, if we allow transforms over SignedInfo, we burden relying
parties with the responsibility of evaluating the transformed SignedInfo to
decide if it is still secure.

-Greg


-----Original Message-----
From: John Boyer [mailto:jboyer@uwi.com]
Sent: Thursday, November 11, 1999 2:21 PM
To: DSig Group
Subject: Omitting Location and Transforms from SignedInfo


I was unimpressed by the reaction at the IETF meeting to the need to omit
Location and Transforms from the SignedInfo. Unimpressed because the
opinions seemed to be based on fear, either of complicating matters or of
creating security problems.  I would prefer reasons grounded in fact rather
than fears.  At the meeting it was insisted that this standard be applied
when deciding whether to reorder the elements in our signatures, and I would
like to insist that we do the same here.

The points recently made by Rich Himes and Daniel LaLiberte are absolutely
correct and mirror my own thoughts on these issues.  To sharpen the point,
let's begin with this question:  Suppose we have an XML signature in which
the SignedInfo contained no ObjectReference descendants?  What is the value
of such a signature?  Nil.

The signing of SignedInfo is an intermediary step that *we* have added for
some reason (perhaps the most compelling being that the method is quite
clean about signing multiple objects with the same signature).  The fact
that the Location and Transforms are signed by *our* artificial process is a
usually harmless and often desirable side effect.  However, THE MESSAGE THAT
THE SIGNER WANTS TO BE AUTHENTICATED BY A SIGNATURE IS THAT WHICH IS
INDICATED BY OBJECTREFERENCE.

Our process of signature generation creates a digest not only of the message
intended by the signer, but some additional information, namely SignedInfo,
whose subsequent invariance may harm the signer or prevent the use of core
signature behavior.  Signing SignedInfo is an imprecise method of achieving
our actual goal, which is to achieve security by signing the DigestMethod
and DigestValue of each ObjectReference (along with other bits of info
outside of ObjectReference elements).

No matter how loud the opposition sounds, the fact is that we have inserted
an unintended and sometimes unwanted additional assertion in the message
being signed by the signer.  Specifically, we assert that the referenced
object can be obtained by a particular sequence of steps (given by Location
and Transforms).  Further, this assertion is not eliminated by simply
changing the name of Location to something like Target.

It was acrimoniously asserted that the Location is required because the
signer may want the signature to break if the data at the given location is
changed.  I disagree, and it should be obvious to the reader that 'required'
and 'may' do not belong together in the same sentence.  However, I do agree
with the spirit of the acrimony, which is that the signer will often benefit
from the inclusion of this assertion in the message being authenticated.

Always including the Location and Transforms in the signature is unclean and
borne of imprecision, but always omitting them is also problematic.  One
might be inclined to say that the signature should include an
ObjectReference to a Location that must be invariant after signing. However,
from a security standpoint, this solution has no bottom turtle.  We could
take the position that all assertions must be carried by the signed message
and hence this problem of associating the signed data with its location and
transforms should be pushed off to the application.  Although, this is a
more defendable position than the one taken by those who want to always
include Location and Transforms in the signature, I do not agree with this
either because we would be requiring an application to put assertions about
*our* markup into its markup.

In the end, it is best if there is *some* way to indicate whether or not the
Location and Transforms of an ObjectReference should be included in the
signature over SignedInfo.  Obviously, this could also be accomplished by
applying Transforms to SignedInfo that would omit Location and Transforms.
Some have strong feelings that this will introduce the possibility of
security holes.  Of course it will.  We have security holes that can result
from the fact that we are signing markup rather than a bitmap of what the
user actually sees.  We have security holes that can result from poorly
constructed transforms in ObjectReferences.  As I presented at the IETF
meeting, it would be easy for someone to write a transform that omits the
DigestMethod and DigestValue descendants of SignedInfo.  The Signedinfo
Transforms element could even cause its own omission from the SignedInfo.
It does not matter because we ultimately create a digest using a "secure"
hash algorithm, and only the digested data can be used to assess the
security of the signature.

The point is that this is not a security hole in our spec but rather a
security problem with the software that creates an insecure signature.  It
is not logically different from using the results of our specs with 256-bit
RSA keys.  People can do it with software based on our spec, but that
doesn't mean it is secure.

To some extent, signing SignedInfo is like a first implicit ObjectReference,
which is why it makes sense to apply Transforms to it.  Nonetheless, if
full-blown Transforms on SignedInfo are just too much for fear of complexity
or security, then how about a simple 'OmitXXX' attribute in ObjectReference
to specify whether or not the Location and Transforms should be omitted? It
is not as flexible for the future, but it at least solves the problems we
know about now.

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company

Received on Friday, 12 November 1999 12:55:27 UTC