Correlation/Protection (Was: Re: XKMS)

(Changed the subject line to split two threads.)

I'd be a bit worried that digesting the entire message would 
run into proxying/SOAP wrapping issues.

Do we need to be a bit more specific about what's digested?

Stephen.


> Mike Just wrote:
> 
> That sounds like a good idea. One might argue that XKMS already has the <Respond> element for
> returning elements sent as part of the request but <Respond> doesn't cover items such as the
> Transaction ID and the service URL.  Phill's <SigningContext> element (from
> http://lists.w3.org/Archives/Public/www-xkms-ws/2001Nov/0065.html) would add these items. However,
> <Respond> doesn't return additional elements such as <KeyId> that might be sent as part of a
> <Query>. It seems safest to allow the return of the hash of the entire request (or else someone
> will likely break/attack any partial solution).
> 
> As for how the client requests this, maybe it could be another <Respond> option; something like
> <Respond>
>         RequestReference
> </Respond>
> which would return an XMLDSig reference element computed over the entire client request.
> Phill's <SigningContext> would still be required I believe; at least for the service URL (unless
> we decide to include this as part of the request schema as well).
> 
> (I might have thought that it would be mandatory to include the RequestReference for the most
> secure operation, but if the session were protected by TLS, for example, then some correspondence
> between the request and response would already be provided. The spec would have to indicate these
> security issues/options of course.)
> 
> Mike
> 
> > -----Original Message-----
> > From: Rich Salz [mailto:rsalz@zolera.com]
> > Sent: Tuesday, November 27, 2001 11:53 AM
> > To: Mike Just
> > Cc: 'www-xkms-ws@w3c.org'
> > Subject: Re: XKMS
> >
> >
> > That makes sense -- the server can return an element XMLDSIG Reference
> > element for the client request -- but how can the client indicate it
> > wants that? Or is that left as a quality of implementation issue?
> >       /r$
> >
> > --
> > Zolera Systems, Your Key to Online Integrity
> > Securing Web services: XML, SOAP, Dig-sig, Encryption
> > http://www.zolera.com
> >

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@baltimore.ie
Ireland                             http://www.baltimore.com

Received on Wednesday, 28 November 2001 05:05:02 UTC