RE: <DocumentURI>

[Trevor Perrin <trevp@trevp.net>]

At 06:44 PM 10/22/2003 +0200, Gregor Karlinger wrote:

>Trevor,
>
> > -----Ursprüngliche Nachricht-----
> > Von: Trevor Perrin [mailto:trevp@trevp.net]
> > Gesendet: Montag, 20. Oktober 2003 20:53
> > An: gregor.karlinger@cio.gv.at
> > Betreff:
> >
> >
> > Hi Gregor,
> >
> > The DSS TC is re-examining one of its requirements.  Since you had a
>hand
> > in this requirement, we thought it might be useful to consult you.
> >
> > Specifically, we're wondering if there's a need for a client to indicate
> > the to-be-signed document through a URI, or if the client can always
>just
> > send the document itself, or send a hash.
>
>It is one of the main adavantages of XMLDSIG that you can *refer* to data
>that is signed by the signature instead of incorporating it into the
>signature. If you restrict a DS creation service to accepting only data
>that is incorporated in the request, you give away this feature of
>XMLDSIG.

I think these are separate issues - you can send a full document to the 
server, and the server can still respond with a signature that *refers* to 
this document.



>Think of cases where material which is available in the internet or in a
>separated network by resolving URLs: IF The DS creation service does not
>allow specifying the data to be signed as URL, the client has to fetch the
>data itself (first network traffic) and then provide it to the service as
>part of the creation request (second network traffic). I see this as a
>severe limitation.

You may be right.  But just to argue the other side:
  - If the client *hasn't* already fetched the data, he's signing something 
he hasn't seen, and that's no good.
  - The client can always provide a hash of the data, to avoid your 
"(second network traffic)".  In fact, your solution just moves this traffic 
from the client to the server (the server has to fetch the 
document).  Sending a hash of the data eliminates it entirely.

Also, client-side hashing works whether the document is at a URL where the 
server can access it or not.  So in terms of performance and universality, 
client-side hashing seems superior.

I guess the only problem with it is that clients need to implement hash 
algorithms, which requires smarter/more functional clients that we'd 
like.  But performing a hash is much less complicated than doing any of the 
PKI stuff, which is the real burden DSS servers eliminate, imho.


>What would be the advantages of limiting the provision of the
>data-to-be-signed to explicitly passing it along as part of the request?

There's a security concern, if the client asks the server to sign something 
the server has access to, but the client doesn't.

Otherwise, the advantage is just a simpler protocol, with one less feature 
servers have to support.

Trevor