RE: Locations but not Transforms as hints (was RE: The XML-DSig Non-standard, or Location/Transforms as 'hints')

Hi Mark,

comments embedded...

-----Original Message-----
From: Mark Bartel [mailto:mbartel@thistle.ca]
Sent: Tuesday, November 23, 1999 8:13 AM
To: 'John Boyer '; 'w3c-ietf-xmldsig@w3.org '
Subject: RE: Locations but not Transforms as hints (was RE: The XML-DSig
Non-standard, or Location/Transforms as 'hints')


Note that whether or not the signer is trusted is necessarily "application
specific."  If I sign something with my Mallory Certification Services
certificate and the verifier doesn't trust Mallory Certification Services,
the verifier will reject the signature even if it is otherwise valid.  I
don't think "application specific" is a dirty phrase.  Indeed, I see it as
useful and not onerous to allow applications to decide in this case.

<John>
The purpose of core behavior is to authenticate the message signed and
authenticate the signer, not to decide whether one trusts the signer or the
authentication mechanism.  The issue of trust is a policy issue typically
governed by a PKI. If a PKI is properly established then every application
on the box will dance to the same tune.
Perhaps there is a different example of why core validation must be
application-specific, but this one doesn't do it for me.  If I want to write
an app that can handle any and all documents within an enterprise, I already
assume that I must hook up to that enterprise's PKI.  Now, the more
standardization there is in how to do that, the lower my maintenance
troubles are going to be as I sell to new clients.  In the same way that I
really want trust to be standardized and free of application-specific
weirdness (or site-specific weirdness), I also want dsig core behavior to be
free from application-specific weirdness.
</John>

> Transforms outside of SignedInfo:  we both object to them, just to
> differing
> degrees.  The reason I don't object as strongly as you do is that the
> application can decide which transformations to trust.
>
> Note that the Transforms outside of the SignedInfo can be signed by
> another
> signature, and
> applications can use *that* as a criteria for trust.  However, I would
> prefer that we let applications deal with that issue and not have
> Transforms
> outside of SignedInfo.
>
> <John>
> Obviously, I agree here since signing the transforms by another
> signature
> defeats the purpose of having them unsigned in the first place.
> </John>

You are missing the point.  The application that signs the additional
Transforms is different than the application that created the original
signature.  It may or may not use different credentials to create the second
signature.

<John>
It's largely an academic point since we agree that it is best not to do it
this way anyway, but I don't think I missed the point.  Having the ability
to add arbitrary transforms to the document, even if they are signed by a
party other than the original signer, breaks the fundamental assumption of
digital signatures, which is that the document should not be modifiable in
ways meaningful to the signer after the signer has signed the document.

The signer must sign sufficient information to guarantee that the document
cannot be modified in ways that can hurt the signer.  Covering part of the
document with a different signature (esp. a removable one) doesn't change
the fact that the signer's signature doesn't cover the necessary information
to reconstruct what the signer was looking at.

I would go so far as to argue that not even a second signer's signature on
those transforms would do anything to protect the validity of the first
signer's signature unless both signatures remain intact in the document.
Further, since the receiver does not have the signer's private key, the
receiver cannot remove the second signature and replace it with a new
signature over changed transforms.
</John>

The original application may well not know that the document is
going to be moved.

<John>
I would assert that the original application (more importantly, the signer
using that application) MUST know in advance.  The signer MUST be able to
precisely control what is modifiable in a document once he signs it.  This
is the essence of the thing I call DOCUMENT CLOSURE.  If the signer cannot
precisely control what can change, then the signer's signature on the
document is meaningless because the document could differ in arbitrary ways
from what the signer intended to sign.
</John>

This is Joseph's assertions-about-assertions approach,
which I very much like and think is the only general solution to the problem
we are trying to address.  If the object is moved again, the added signature
can be removed, and a different one put in place.

<John>
Right but not by the signer!  The signer's signature does not cover enough
of the document that we can make reasonable assertions about what the signer
actually signed.
</John>

But as you point out, the idea creates issues when used in the core.  I'm
happy pushing this off to the application to make the necessary
assertions-about-assertions.  At that level, the issue of validity that you
point out goes away.

<John>
Sure, and this is an alternative I support.  But if we are going to push the
issues off to the application, then we should do it in a consistent way that
does not have a core signature signing something that isn't true.  If the
Location doesn't tell where to get the bits by some well-known and
well-document, public, open-standard process, then the Location shouldn't be
signed.
If we want to make these issues application-specific, then it makes more
sense to me to be consistent in how we move responsibility to the
application.  We should move it to the application by moving issues of
Location to the Manifest.  I would be happy to support this alternative.

The only thing I am saying is that the currently defined core has created a
problem that can be interpreted in one of two ways:

1) Location as law
In this case, apps that don't want to sign Location must not use core
behavior.  So they can solve their problem using a Manifest, but it is the
design of core that seems flawed because the signer does not care about
where the data is and yet is being forced to sign it, thereby making its
location invariant.

2) Location as hint
In this case, apps that don't want to sing Location must sign it, but
changes its meaning under the covers. This is a brutal hack in which we seem
to be changing the meaning of what got signed to suit the fact that our
design can't solve the problem.

</John>

> Your example:  this is not a problem I was trying to solve.  My main
> concern
> was for the x.com to y.com or base64 on web to unencoded on
> disk type of
> changes, which my concept of "location as hint" addresses.  I was not
> trying
> to deal with the general document transmogrification case; do we feel
> this
> is a problem we need to solve?
>
> <John>
> Yes, since the example I gave is the base64 in the document
> to unencoded
> on
> disk.  This is one of Rich Himes's scenarios, and it was also
> one of the
> original goals that Dave Solo had. The movement of the bag of
> bits from
> within the document to without should not break the signature.
> </John>

My bad.  I had forgotten that the base64-encoded document was embedded in
that example.  Yes, a different mechanism has to be used for that.  I don't
see the XPath-over-SignedInfo solution as effective because the signing
application has to *know* that the document is going to move.  To me, the
conceptually proper solution is to use assertions-about-assertions.  I like
location-as-hint because it simplifies what seems to me will be a common
case (http://x.com/this changing to http://y.com/that) without adding
complexity, but I don't have a problem with using assertions for that case
as well.

Perhaps at a later point in the process we should attempt to address such
assertions, and specify how to do the one necessary for this (the document
here is the document that was there).

<John>
Firstly, I'm having trouble understanding which position you're working
toward.  Assertions about assertions doesn't seem to need location as hint,
and location as hint doesn't need assertions about assertions.  Are you
saying that either is fine with you?

As for Xpath over SignedInfo, the application MUST know how the document
will be modified or we defeat the fundamental purpose of digital signatures,
which is to associate a document with a person.  The allowable changes after
signing must be predefined and undergo security review before the app can be
used by the signer.  The signer's signature must include the list of
allowable changes.  The signature must break if the list of allowable
changes is changed after signing or if the document is changed in ways not
allowed by the list of allowable changes.  This is the essence of DOCUMENT
CLOSURE.

Assertions about assertions are awful in this case because it is not the
signer making the change of assertion about how to transform the document.
The transforms define the list of allowable changes, and if the signer
doesn't sign those, then the document can be substantially altered without
breaking the signer's signature.  It is a little tricky to break because the
modified transforms still have to produce the bits signed by the signer, but
it is not very hard to break since one can switch from omission logic to
inclusion logic, at which point extra material can be inserted just about
anywhere.

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

-Mark Bartel
JetForm Corporation

Received on Tuesday, 23 November 1999 13:32:38 UTC