Re: THAT'S A GREAT IDEA!!

It is true that a major problem with the idea of transforming
SignedInfo was that that the transform affected itself.  By having the
transform only affect a single ObjectReferece or block of
ObjectReferecnes, but not itself, you get rid of that problem.
However, having to have transforms at all for very common cases still
seems ugly to me.

And flags as to whether something should be checked also have problems,
like criticality flags.  The verifier has to know what needs to be
checked for its application in most cases.  If it can tell what flags
to "mandate" verification are correct, then it doesn't need the flags.
And the flag technique fails complete for cases where verifying any
one, say, of the N things in a Manifest is adequate.  Or where verifing
a specific item in the Manifest which depends on other (possbily
separatly/differently signed) parts of the message is adequate.

By the way, going back to a single Manifest pointed to from SignedInfo
is heading in the dirction of the Richard Brown proposal.

I have an alternative proposal I will post as a separate message.

Donald

From:  "John Boyer" <jboyer@uwi.com>
To:  <rhimes@nmcourt.fed.us>, <pbaker@verisign.com>,
            <Larry.Bugbee@PSS.Boeing.com>, <w3c-ietf-xmldsig@w3.org>
Cc:  "Joseph M. Reagle Jr." <reagle@w3.org>,
            "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>,
            "Dave Solo" <dsolo@alum.mit.edu>
Date:  Wed, 8 Dec 1999 10:52:53 -0800
Message-ID:  <NDBBLAOMJKOFPMBCHJOIIEJMCCAA.jboyer@uwi.com>

>Hi Rich,
>
><Rich>
>If manifest is likely to be implemented, perhaps we should make it part of
>core
>behavior.
>
>I honestly don't understand why we are shoving a common problem toward local
>hacks.  Where's the
>interoperability of our spec?  Sure, we can tell them how to work around it
>(they'll never see this discussion), or let them figure a way out.  But it
>is a
>workaround for a shortcoming of the spec, IMO.
></Rich>
>
><John>
>I agree about it being a shortcoming in the spec, which is how I represented
>it at FTF#2. Although everyone hated the SignedInfo transform, your
>suggestion to make Manifest part of core twigged a sequence of ideas:
>
>How about this. In SignedInfo, we have either an Object (for those who want
>small signatures) or a single ObjectReference. But what if ObjectReference
>had an extra attribute that controlled whether or not its DigestValue has to
>be checked. Then, what if this attribute were carried forward to
>ObjectReferences appearing in a Manifest.  AND, what if the ObjectReference
>in SignedInfo pointed to a Manifest.
>
>Now, we have overcome the technical shortcoming. Manifest under its current
>definition doesn't validate the DigestValue entries of its ObjectReferences,
>and this can still be done with the suggestion above by having
>ObjectReferences whose attributes indicate no DigestValue validation.
>
>For your problem, the Manifest would indicate an element X containing the
>base-64 encode version of a PDF document using an ObjectReference having an
>attribute indicating that the DigestValue should be validated. The
>signature's SignedInfo would indicate the Manifest in an ObjectReference,
>and the Transform in that ObjectReference would omit the Location, IDRef,
>base64 transform and Xpath string(child::text()). This allows you change the
>location without breaking the signature WITH A CORE SIGNATURE THAT IS SECURE
>because the Manifest transform in SignedInfo is COMPLETELY SIGNED!!
>
>In conclusion, all of SignedInfo would be signed (!), and in particular, and
>more importantly the signature includes the entire transform that controls
>what part of the manifest is omitted.  This is the same as my 'bottom
>turtle' approach, except that it doesn't seem like a hack in core behavior.
>Best of all, we've only added *one* attribute to our current syntax!
>
>Can someone shoot themselves in the foot by transforming the DigestValue or
>DigestMethod out of the manifest.  Of course they can, but they can do that
>with our spec now.  However, in both the current spec and in this proposal,
>it is easy to determine that the signature should be thrown out and the
>document developer shot because the complete manifest transform is signed.
>
>So, the ONLY thing new in this proposal is the addition of an
>ObjectReference attribute that would require Manifest to validate an
>ObjectReference's DigestValue, which would allow generic scenarios such as
>those proposed by Rich and Larry to be verifiable with core processing
>rules.
>
>John Boyer
>Software Development Manager
>UWI.Com -- The Internet Forms Company
>
>P.S. Adding another transform to do an XPath string(child::text()) is, to
>me, as undesirable as the addition of IDREF.  Basically, XPath can already
>identify elements by an Id attribute, and it can even do so in the absence
>of a validating processor. The point being that if you don't want to
>implement full XPath compliance you don't have to.  In your app you can
>choose to only support specific XPath phrases like string(child::text()) and
>/descendant::node()[@id='X']. These phrases will be interoperable with
>applications that choose to fully support XPath or any superset of your
>phrase selection.  To me it would be better to require support for specific
>phrases than to create alternate syntax that duplicates the abilities of
>XPath.  But, for what it's worth, if it makes somebody's life easier, then
>I'm not so interested in preventing duplication of XPath capabilities as I
>am in having XPath in the first place.
></John>
>
>>It does seem unlikely that core behavior will be modified to solve this
>>problem since it REQUIRES the ability to transform the ObjectReferences in
>>SignedInfo. To the extent that this is an unpopular idea is the same
>>extent to which it is decided that scenarios like those described by Rich
>>and Larry are application-specific.
>
>Application designers need the tools to work with.  I honestly don't
>understand
>why we are shoving a common problem toward local hacks.  Where's the
>interoperability of our spec?  Sure, we can tell them how to work around it
>(they'll never see this discussion), or let them figure a way out.  But it
>is a
>workaround for a shortcoming of the spec, IMO.
>
>>However, I can agree that it is not absolutely necessary to address these
>>problems in core behavior since these applications can simply reconstruct
>>the document signed before passing them to other applications that only
>>understand core signature validation.
>
>This is still a local hack.
>
>>My main point in mentioning these
>>scenarios is that they came to me from others, I see how to modify core
>>behavior to solve them by transforming SignedInfo, there really is no
>>alternative that can be secure, so the WG has to decide whether to
>
>The "security" problem was that someone could reverse transform the document
>to
>ultimately point to any other document.  I still believe that the only thing
>being signed is the final string to the hash algorithm.  We are allowing the
>transform capability in the manifest.  Thus, we are pushing this alleged
>security problem to non-core applications, are we not?  If we are doing
>that,
>why not just make it core behavior?  Would it help to restrict unsigned
>transforms to XPath, or some specific transforms?
>
>>1) Make the modification to transform SignedInfo
>>2) Decide that the scenarios are application specific
>
>Could we move your proposed transforms to the manifest and sign that?
>
>>So far, there have been no other viable options, except those that I have
>>demonstrated result in an appalling security breach.  Since the majority
>>WG opinion is against option 1, it seems that our chairs should bring
>>about a decision process so the WG can close this issue.
>
>Agreed.  Good post, John.
>
>Thanks,
>Rich
>

Received on Thursday, 9 December 1999 09:27:02 UTC