Fwd: AW:

[Trevor Perrin <trevp@trevp.net>]

I asked Gregor for some elaboration on the requirement that the client can 
send URIs of to-be-signed data to the server.

His response is informative -


>From: "Gregor Karlinger" <gregor.karlinger@cio.gv.at>
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Trevor Perrin [mailto:trevp@trevp.net]
> >
> > 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.
>
>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.
>
>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?
>
>Regards, Gregor

smime134.p7s