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 Thursday, 11 November 1999 17:21:59 UTC