RE: Omitting Location and Transforms from SignedInfo

Hi Don,

I've had too much work to do to respond before now.  Sorry for the delay.

The principal object of my disappointment was not that transforming
signedinfo was poorly received, but that some (not you) seemed to want to
invalidate the scenarios as a way of getting rid of transforms on
signedinfo.

As for your analysis of transforming signedinfo, forgive me if I missed
something but I think that your attacks are quite similar to Greg
Whiteheads, so I will answer for them there.

Finally, the matter in question for me was whether we could omit
ObjectReference Location and Transforms by *any* method.  Noone has come up
with an answer to this (perhaps due to the dislike of my proposed solution).
Anyway, I think I have a good reason for not wanting to omit ObjectReference
Transforms, but I cannot as yet think of why we can't allow Location to
vary.

The main point for me of ObjectReference Transforms was neither base64
encoding nor c14n.  It was the XPath transform, which affords one the
ability to create 'document closure'.  You may recall that document closure
means that you can sign a portion of the document but also be sure that the
unsigned document was not modified in ways other than what is explicitly
stated by the XPath transform.  The idea would be that the only allowable
changes would be those that do not alter the meaning of the original
signature given the application context.

However, document closure only works if the ObjectReference Transforms are
signed. This does not necessarily mean that the facility to omit Transforms
is a bad idea altogether, but it does mean that those who simply want to
vary Location and base64 encoding must give up document closure or achieve
it by some other means.  By contrast, if we allow transforming of
SignedInfo, we have the most flexibility, since one could say "omit only the
ObjectReference's base64 encoding transform, but keep the XPath and
canonicalization transforms".  This also avoids the unfortunate syntactic
inconsistency that would result from choosing an alternate method of
omission.

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 Donald E. Eastlake
3rd
Sent: Friday, November 12, 1999 2:31 PM
To: DSig Group
Subject: Re: Omitting Location and Transforms from SignedInfo


John,

From:  "John Boyer" <jboyer@uwi.com>
Resent-Date:  Thu, 11 Nov 1999 17:22:07 -0500 (EST)
Resent-Message-Id:  <199911112222.RAA12241@www19.w3.org>
To:  "DSig Group" <w3c-ietf-xmldsig@w3.org>
Date:  Thu, 11 Nov 1999 14:21:10 -0800
Message-ID:  <NDBBLAOMJKOFPMBCHJOIAECBCCAA.jboyer@uwi.com>

>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.

As explainted below, I believe it really does add a lot of complexity
and complexity is the enemy of security.

>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.

The SignedInfo step also secures the SignatureMethod and
CaononicalziationMethod (or lack thereof) as well as easily
accomodating multiple secured items, including KeyInfo if desired.
Once you acknowledge any need to sign even one bit of information
beyond the message indicated by ObjectReference, you are not just
signing that message.

>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.

Who claimed it was?  I thought the change was suggested because the
value of Location might not be a location in the URL sense.

>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.

As I see it, it does matter.  In particular, if a Transform of
SignedInfo is allowed, a cracker can insert such a Transform and
change the DigestValue and the data being secured so that the new
DigestValue is correct, using the strong DigestMethod, for the data
the cracker wants.  Then all they have to do is be sure that the
Transform not only drops itself and the new DigestValue but inserts
the old DigestValue, thus guaranteeing that the genuine old
SignatureValue still checks.  The KeyInfo is unchanged as are the
strong SignatureMethod and DigestMethod so even strict vetting of all
that by the verifier is no help.  It's all done with a smoke and
mirrors Transforms.  Thus, if this is allowed, you have no security
without a very complex check of the Transforms of SignedInfo.  I have
no confidence that there are not many other, even more subtle ways an
inserted Transforms could fake out a verifier.  (The next thing that
occurs to me is that the cracker could modify the data and then add or
modify the ObjectReference Transform to restore the data to its
original state before digesting and add a SignedInfo level Transforms
which removes itself and removes or changes back the ObjectReference
level Trasnforms. Then all of KeyInfo, SignatureMethod,
SignatureValue, DigestMethod, and DigestValue are untouched and the
signature verifies but the cracker can make arbitrary changes in the
data.)  Sure, the complexity involved in vetting the SignedInfo
Transforms is probably less than that required for a good general
theorem prover, but I'm not sure how much less.

The more I think about it the more I am personally convinced that the
consensus at the WG meeting against a Transforms of SignedInfo was
correct and rational.

>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.

I'll agree that it is not inherently insecure but I think it adds
unacceptable complexity as described above.

>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.

I look at it this way, the verifier has to get its hands on the actual
data to verify the DigestValue.  If this data is local to the XML that
contains the Signature, then there would not normally be any problem.
You use an IDREF.  If the data is not local, then already you are
outside the core signature library and dependent on application
behaviour.  If the data is not local, you are either de-referncing a
URL or using some URN/hint to find the stuff.  It's really implausible
to me to think that the core signature library can even do ftp: or
http: let alone gopher: or madeupscheme:.

As long as the value of Location is not an IDREF, its entirely up to
the surrounding application what data it feeds to the signature core
either as part of the initial parameters to the signature core or as a
result of a call out from the signature core when it encounters the
non-IDREF (depends how the libaray is organized (might want to do call
outs to avoid de-referncing later URLs if an earlier digest
fails...)).  Either way, the application can feed whatever it wants
(and has to if Location is absent) to the signature core regadless of
whether or not it has any relationship to Location.

Given this, I don't quite see what the big deal is with fixing (ie,
signing) Location.  And it kind of seems that (1) the possibility of
omitting Location, (2) the fact that the application can interpret
non-IDREF Locations however they want in getting the data, (3) the
availability of multi-level Manifests, and (4) the availability of
location independent URIs, will, all together, satisfy many of these
requirements.

If more is needed, I'd prefer to see it be possible for Location and
Transforms to appear optionally either inside or outside SignedInfo,
with an ID/IDREF link when they are outside, than to see an "omit="
attribute or the like.  Because I think it will be simpler than always
having to use a custom canonicalization that is sensitive to this
"omit='true'" attribute...

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

Thanks,
Donald
===================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668   dee3@torque.pothole.com
 65 Shindegan Hill Rd, RR#1  +1 914-784-7913(w)     dee3@us.ibm.com
 Carmel, NY 10512 USA

Received on Wednesday, 17 November 1999 17:59:57 UTC