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

Hi John,

I'm going to attempt to summarize your main points... please correct me if
I'm misstating them, or have missed one.

1. Core behaviour should be free of application-specific behaviour.
2. The signer of the document, not the verifier, determines what is
important to be signed.
3. Location-as-hint is a "brutal hack" that changes the meaning of what got
signed.
4. Location-as-hint and assertions-about-assertions are independent.

My thoughts on each:

1. Core behaviour should be free of application-specific behaviour.

I agree with this in theory. My point was that there are other issues in the
core that are also application specific, such as how the application gets
the appropriate key material.  I don't see location-as-hint as posing a
noticeable interoperability problem or implementation burden.  Applications
that do funky things will of course not interoperate, but that is a given.
Location-as-hint significantly simplifies some particular scenarios, and I
think that in this case it is worth the slight amount of effort required to
do it.  However, assertions-about-assertions could be used to the same
effect; they are merely more complicated.

2. The signer of the document, not the verifier, determines what is
important to be signed.

I disagree with this.  I think both the signer and the verifier do this
determination.  It depends on the nature of the interaction.  I submit the
following points:

a) The signer cares that *sufficient* information is signed.
b) The verifier only cares that the information relevant to it is signed.
c) If the verifier chooses to ignore signed information, that doesn't change
the assertion that the signer made.
d) If the signer is making an assertion intended to have legal force (which
will frequently not be the case), they will be concerned that information
that they are *not* asserting is *not* signed.

If location is signed, the document is moved, and the verifier doesn't care,
that doesn't change the assertion that the signer made.  This is points a),
b), and c).

And since it doesn't particularly matter where the bits come from, I would
say that we should specify the signed location to mean that "this is where
the resource was when I signed it" and nothing more.  Therefore d) would not
be an issue.  I don't think it is reasonable for the assertion to be "this
is where the resource will be for all time".  If the verifying application
requires that the resource be at the original location, it can do that check
itself.  It seems to me that this is a lot like requiring an original of a
contract rather than a photocopy; it is the recipient for which this
matters.  Sometime an organization will accept a copy, sometimes it won't.

3. Location-as-hint is a "brutal hack" that changes the meaning of what got
signed.

I disagree, but I realize that I am thinking of the signed location in the
sense of the above paragraph.  The signed location is the "original" which
may or may not still exist.

4. Location-as-hint and assertions-about-assertions are independent.

Agreed.  I wasn't saying anything different.  My point of view is that
location-as-hint seems a really nice solution for a subset of the raised
issues, but assertions-about-assertion are the general solution.  I'm
advocating location-as-hint because it seems useful.  An application can
choose to use assertions-about-assertions regardless of what we do here, so
I don't see that I need to advocate that.  I don't have a strong objection
to leaving assertions-about-assertions as the only method of changing
location, but it seems like a bit of a pain.

-Mark Bartel
JetForm Corporation


-----Original Message-----
From: John Boyer
To: Mark Bartel; w3c-ietf-xmldsig@w3.org
Sent: 11/23/99 1:31 PM
Subject: 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 Wednesday, 24 November 1999 14:32:06 UTC