RE: Correlation/Protection (Was: Re: XKMS)

From an implementation point of view I think it would be much better to move
any such digests to a SOAP header, even if the SOAP header must be defined
by the XKMS spec for this version.  Then in the future the implementation
would change from one type of SOAP header to another rather then changing
the contents of the body.  Same applies to transaction IDs.

mark

> -----Original Message-----
> From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]
> Sent: Wednesday, November 28, 2001 8:17 AM
> To: 'stephen.farrell@baltimore.ie'; 'www-xkms-ws@w3c.org'
> Subject: RE: Correlation/Protection (Was: Re: XKMS)
> 
> 
> The same thought (digest of the request) had occurred to me 
> simultaneously,
> only I was typing up the note. The nice feature of that 
> approach is that it
> makes it much harder for a pinhead to code the interface in 
> the wrong way so
> that there is an implicit dependence on the authenticity of 
> the request.
> 
> I think that the scope of the digest would be the body of the 
> SOAP message.
> i would like to see the idea raised at some point to the 
> level of a general
> SOAP security mechanism since the problem is pretty general.
> 
> 	Phill
> 
> Phillip Hallam-Baker FBCS C.Eng.
> Principal Scientist
> VeriSign Inc.
> pbaker@verisign.com
> 781 245 6996 x227
> 
> 
> > -----Original Message-----
> > From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie]
> > Sent: Wednesday, November 28, 2001 5:05 AM
> > To: 'www-xkms-ws@w3c.org'
> > Subject: 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.h
> > tml) 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 11:38:16 UTC