Just Reconstruct (was RE: Without breaking (formerly: The real crux... ))

Phill,

<FromPhill>
What you could do in an archive situation is to create a signature on
an archive manifest covering the original document, an abstract and
the original signature.

Such a signature would be a second order statement (a signature attesting
to the fact a signature once existed). But in the circumstance proposed
that is the best that can be done.
</FromPhill>

Firstly, I don't see how your proposed solution solves the problem. To have
a signature S2 *prove* that a signature S1 used to exist doesn't seem to
help the verifier, who must produce a signature that validates with the
*signer's* public key in order to be taken seriously.  A signature S2
created by the verifier is self-serving and hence inadmissible.

Larry suggests that it may not be known at the time of signature creation
that a 'manifest' is required. This was probably an allusion to an earlier
manifest-based solution I presented earlier in this thread, which appears
again below.  For starters, it is absurd to suggest that a manifest would
not be required given the storage strategy he described.  However, on the
supposition that this constraint did exist, the solution really is as simple
as having the application take the 'shell' document with the signature, use
it to dig up the archive data, put the two back together, THEN call upon
core signature behavior to validate.

Since it is quite likely that the application designer will know about the
archive before the signature element is defined, it is possible to create a
manifest M that contains an objectreference O_1 indicating an element X's
base64 decoded text. 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).

The objectreference O_2 in the signature that indicates the manifest M can
use transforms that omit the specific xpath and base64 decode describe
above, as well as the Location or IDref that indicates X.  This allows him
to move the data from within X to an archive and to make the necessary
modifications to objectreference O_1 (the one appearing in M).

Thus, the signer's signature can be preserved despite the desired changes.
This is the notion of document closure. Certain specific changes can be
allowed by a signer since it can be proven that the specified changes pose
no security risk.

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!

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.

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

1) Make the modification to transform SignedInfo
2) Decide that the scenarios are application specific

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.

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

Received on Tuesday, 7 December 1999 19:32:36 UTC