W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > January to March 2000

AW: Transforms useless in current spec

From: Peter Lipp <Peter.Lipp@iaik.at>
Date: Wed, 12 Jan 2000 18:20:09 +0100
To: "John Boyer" <jboyer@uwi.com>, <Gregor.Karlinger@iaik.at>
Cc: "DSig Group" <w3c-ietf-xmldsig@w3.org>

> -----Ursprüngliche Nachricht-----
> Von: John Boyer [mailto:jboyer@uwi.com]
> Gesendet: Mittwoch, 12. Jänner 2000 18:08
> An: Peter Lipp; Gregor.Karlinger@iaik.at
> Cc: DSig Group
> Betreff: RE: Transforms useless in current spec
> Hi Peter,
> <Peter>
> It seems to me that one thing we miss currently was that we have no way to
> force the core behaviour to dereference any URI or IDREF, in those cases
> where an URI or IDREF is meant to be understood as a location. This would
> now be application specific...
> Personally, I don't see the need for that, as I still believe in the
> scenario that if I have some data, hash it, and the signature
> verifies, this
> is the only thing that counts, and I need to accept that the data
> I have is
> the data that had been signed. Where it came from and how it was
> transformed, I don't see as being significant for the general case.
> </Peter>
> <John>

> Your argument is self contradictory.
Not really, only by your interpretation, which was not mine .-)

>The cryptography is being used to
> protect a message M.  What's in M?  Statements.  What are statements?
> "Person X agrees to pay Y for Z from A on date D", "This message
> was derived
> by the following sequence of transforms".  So, if as you say, you 'need to
> accept that data' that was signed, and that data includes a statement S
> about how the data was derived, then you need to accept S, which
> means that
> S must actually be correct.  Thus, by your own argument, you should care
> very much about how the data was transformed.
Consider the following example:

Statement: I am a liar and never say the truth.
Signed by my private key.

What now? :-)

What I meant with "accept the data" was the bytes representing the data, not
the semantics. I can always get into trouble if I mix those two. If the
application requires the semantics of the statement signed to be equally
truthfull as the signature verifys cryptographically, it needs to take care
of that. And it can, using our system. Nobody prevents your app to always go
and fetch the document and transform it, even if it was the 1025th time
today. You can do that, if this is required to make your security analyst
happy. But I strongly object that this is something that will always be
required for any application. It is perfectly ok to cache the transformed
document, if its ok for the application.


Received on Wednesday, 12 January 2000 12:20:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:33 UTC