Re:THAT'S A GREAT IDEA!!

It finally clicked with me how John's XPath exclusions (aka closure) are
restricting what can be added to the manifest (anything else breaks the
signature).  Brilliant!  The simple change he is proposing satisfies my
requirements.  It allows changes in location from internal (base64) to external
(raw), external to internal, and external to external by allowing one or more of
these specific transforms (or locations) to be changed without breaking the
signature.  At the same time, it prevents arbitrary transforms because they
break the manifest signature, so security is maintained.  I think this adds a
lot of power and flexibility to the standard (it resolves my outstanding
problems), and includes these new capabilities in core behavior.  Are there any
objections to this approach?

Thanks,
Rich

____________________Reply Separator____________________
Subject:    THAT'S A GREAT IDEA!! 
Author: <w3c-ietf-xmldsig@w3.org>
Date:       12/8/99 1:55 PM

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