RE: Thoughts on Threat Model

Hi Peter,

> So, the wording of our document would need to be
> changed to say that the signer MUST perform the transforms as part of
> calculating the message.
While I wouldn't really mind saying MUST, I don't see it as a requirement.
Simply because you can't prove that he did or didn't, so saying MUST doesn't
really add anything! Either the signature verifies cryptographically, and it
can be shown that the signed data could be calculated using the original
data and the transform operations - in that case he could have done that or
the signer new of some magic process to achieve the same results and we
wouldn't know the difference.

<John>
At this point, I would begin by asking why the authors of the European
Digital Signature Guidelines (which you cite below) bothered to require that
the signer MUST be made aware of what he signs?
Your argument that we cannot prove that the signer did or did not perform
the transforms is misguided.  By your argument, one could say that there is
no point in ever signing any data in any format.  We could sign a bit map,
but we cannot 'prove' that the bitmap was ever shown to the signer.
Fortunately, the point you are making is dealt with not in the realm of the
technical and the proof, but rather in the domain of the legal and the
evidence.  In virtually all cases, signers will not be directly creating
these XML signatures and their transforms.  Instead, they will use
application software that has been certified as operating according to the
digital signature specification that we are setting forth.

If we say that dsig compliant applications MUST perform the transforms when
generating a signature, then this requirement becomes part of the
application certification process.  Under the assumption that the certified
application was used and operated without fault, there is no reasonable
doubt about the signature.  This is not proof; this is evidence that no
magic tricks were performed on the signer's end.  A signer who cries foul on
a signature would need to provide some counterevidence about a process fault
of some kind (e.g. the certified application contains a bug that caused it
to accidentally remove selected clauses from visibility on a legal agreement
being signed).
</John>

> their own risk in the sense that the verifier will have the
> burden of proof in showing that they have not materially
> altered the signature. One way to
What burden? If the signature verifies, how can they have altered them?

If you are thinking about the original document, having modified that one
and the transforms to remove the alterations - well, in that case you really
need to include the original document into the signature.

<John>
Firstly, you can't modify the transforms under our current spec because they
are signed (unless you push them out to a Manifest and use a transform in
SignedInfo to omit the Manifest's transforms).
So, if a verifying program wants to assume a set of transforms that are
different than the signed ones, then the transforms must be independent of
the signed materials.

Secondly, yes I am thinking about the original document at the time the
signer signed, but your conclusion is based on reasoning that I have refuted
in many prior messages and in this message.  You have not come up with one
good reason why the transformational method of achieving document closure is
unsuitable (no reason that I cannot also apply to your alternatives).
Please see below for further explanations...
</John>

European Digital Signature Guidelines require that the signer must be made
aware of what he signes (for qualified signatures) and that only can be the
transformed document and never the original one.

<John>
I agree completely with these guidelines.  In particular, I think that they
substantiate my argument that there is some value in placing requirements on
applications that generate signatures.  Moreover, there is no conflict
between these guidelines and the transformation model.  The transformation
model implies that the signer can sign a relevant portion of a document but
also be assured that the remainder of the document cannot be altered in ways
that materially alter the meaning of his signature.  Thus, we secure an
entire document by cryptographically securing a large portion of it and by
also cryptographically securing a description of what can still change in
the unhashed portions of the document.

Take for example a form F with an office-use-only section.  The signer fills
out his portion of the form, resulting in F'.  When the signer signs, this
office-use-only section is blank, so when you follow the European
guidelines, you show him F' with blank office-use-only section.  However,
suppose the signer's signature includes a statement that says F' can only be
changed by adding text to the blank office-use-only section.  This is a
digital model of how we operate in the real world.  I sign something, and
'the office' modifies the office-use-only section later, and my signature is
assumed to not be materially altered by that additional work being done.
However, if 'the office' were to go and white out some of what I filled in,
then that should break my signature on F'.

Now, before you go suggesting some other way to put the document together,
let me reiterate that this is only an example.  It is my attempt to make
this as simple as possible to understand.  There are much more complex
documents out there, and the XPath solution scales up to meet their needs.
I like the XPath solution because it allows us, the authors of the dsig
specification, to truly claim that we have created a specification capable
of securely signing all XML extension languages regardless of their design.
If we did not do this, then we would need to create an entire specification
to define the characteristics of the subset of XML that we are capable of
signing.
</John>

> In conclusion, I think it is necessary to REQUIRE applications to
> follow the
> given transforms 'in effect' when creating a signature, and anything short
> of this nullifies the security value of transforms.  I think it is safe to
> RECOMMEND that verifying programs perform the transforms 'in effect'.
As we cannot require any of the parties to do so, and we cannot verify if
they have effectively done so, this does not help.

<John>
Please see comments above regarding certified applications.
</John>

It seems to me to do so
would require forcing the original documents hash into the signature too. I
am not sure I understand XPath enough, but it seems to me that for any given
transformation using XPath there may exist more than one document that give
the same result, applying the samge transform?

<John>
Yes, the XPath would allow more than one document to be transformed down to
the same message.  This is a MAJOR PART OF THE POINT.  XPath restricts what
changes can be made, but it also allows some flexibility in what changes can
be made because we cannot predict in advance the exact byte strings that
comprise the additional work to be done.  In general, I am trying to address
the problem of how to allow variable work to be done on a signed document
while still maintaining the security and integrity of what got signed.

Again with the form+office-use-only section as example, I don't know what
exactly 'the office' is going to say in the office-use-only section of the
form, so any changes they make to the text nodes of the elements in that
section is OK.  But I do know that if they make modifications outside of
that section, then they are up to no good.  So the XPath transform allows
lots of documents to be created without destroying the signer's signature,
but only those documents meeting the constraint that they were unaltered in
areas outside of the office-use-only section.
</John>

Correct me if that is wrong,
but if it is true...... then I would suggest putting a ref to the original
doc plus transforms into a manifest would be a better solution.

<John>
This suggested solution seems to make no sense.  If I have a referencable
copy of the original document, then I don't need transforms, so putting both
in a manifest is degenerately a non-solution.

So, what you must be suggesting is that we create a copy of document D (no
need for transforms) and make it referencable, either by putting it in an
element of the file or by putting it up on a web server.  Then, regardless
of the changes made to the original D to arrive at some modified document
D', we can recover D.

This is a workable solution, but your assertion that it is 'better' is
patently false.  This is exceedingly wasteful of resources.  I don't want
the amount of digital space I use to be incremented by |D| every time I add
a signature.  This is especially important if my design requirement is for
the document to be mobile and independent of external dependencies, yet be
capable of numerous signatures.

At the end of a long workflow process, I may have a form F with 50
signatures on it (don't laugh, this happens all the time in large
bureaucracies like the U.S. military), with each person having added a
little more work then approving the whole thing so far.  When that document
is finally closed, I want to be able to show the form to a user as a matter
of public record.  I am trying to use cryptography as a means of deriving
the document as it was when each of the 50 signatures was affixed.  If a
signature still checks out after all the subsequent changes were made, then
it is safe to conclude that the subsequent changes did not materially affect
the signature.  If this statement is true of all the signatures, then it is
safe to show the given document to an end-user rather than having them wade
through 50 copies.  This is not to mention the fact that I would prefer my
document be closer in size to |F+50S| rather than |50(F+S)|.

Why is it safe to make the conclusion?  Because the form involved was
designed and certified for use, not created on the fly.  The transforms were
written such that the allowable work was permitted, and other changes would
cause the signature to break.

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

</John>

Received on Tuesday, 25 January 2000 15:18:34 UTC