Re:Just Reconstruct (was RE: Without breaking (formerly: T

John wrote:

>The objectreference to X in M MUST use an xpath of
>string(child::text()) followed by a base64 decode (Rich must uses these
>transforms whether he acknowledges it or not).

Yes, I acknowledge this approach if we are using XPath.  Another possibility
would be to define and name a transform which performs these two functions (we
need one for base64-decode anyway).  We could even define "safe" transforms, and
surely this one will be both common and safe.

<snip/>

>Rich indicated that he did not like the manifest idea and wanted core
>behavior to do the work.  The stated reason was so that he could get
>off-the-shelf software to do the work.  Yet, it is quite likely that 
>vendors will implement the manifest part of the spec, making API calls 
>available to applications like CoreValidate() and ManifestValidate().  One 
>extra function call is not a lot to ask!

If manifest is likely to be implemented, perhaps we should make it part of core
behavior.

>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 Wednesday, 8 December 1999 13:03:02 UTC