RE: 2.0 Draft 8

I'm in agreement with the proposal to more explicitly describe the
layering of XKMS and supporting services such as message security and
transport protocols.  This should help clarify our assumptions and
requirements on these other services.  

Blair

> -----Original Message-----
> From: Krishna Sankar [mailto:ksankar@cisco.com] 
> Sent: Saturday, June 15, 2002 11:47 AM
> To: 'Www-Xkms (E-mail)'
> Subject: RE: 2.0 Draft 8
> 
> 
> 
> Philip/Joe,
> 
> 	Exactly. I support the layering principles and the ever 
> famous orthogonal extensibility. May be a simple diagram could be :
> 
> 	-----------------------------------
> 	XKMS App
> 	-----------------------------------
> 	XKMS Security Primitives
> 	-----------------------------------
> 	XKRSS
> 	-----------------------------------
> 	<Transport Protocol> (Eg. SOAP/BEEP)
> 	-----------------------------------
> 	Transport (HTTP,SMTP,...
> 	-----------------------------------
> 
> 	The "binding" should crisply and clearly specify how 
> the XKMS security (i.e. security native to the XKMS domain) 
> is achieved over any transport. It also should clearly have 
> specifications for the common transports (as you have 
> mentioned) SOAP/https, SOAP/HTTP,... I agree with you that 
> there could be some forward references 
> to-yet-to-be-developed-standards :o) Of course, that is not 
> possible. We have an opportunity here to provide some thought 
> leadership and cohesiveness.
> 
> 	Your outline looks good with normative SOAP/HTTP as the reqd and
> (optional) XKMS/HTTP, WS-Security/SOAP/HTTP. I assume #6, 
> SOAP SSL is also a required binding and a #3 variation could 
> be SOAP/https. Please do circulate a first draft - I would 
> like to see if we could get some f2f time on this somewhere 
> down the line. 
> 
> 	Because of the moving parts, we might have to have a 
> good XKMS security layer independent of the transport. In 
> that regard, do we plan to have some mini-choreography like 
> req/resp with ack ? What do you think on fault propagation ?
> 
> 	I, myself, would be in and out of Europe for the next 3 
> weeks on some EU security work - but can work with you if 
> needed. XKMS would be a good thing to read during those long 
> trans-Atlantic flights and train rides :o)
> 
> cheers
> 
> |  -----Original Message-----
> |  From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]
> |  Sent: Friday, June 14, 2002 9:06 AM
> |  To: 'reagle@w3.org'; Hallam-Baker, Phillip; 'Krishna 
> |  Sankar'; 'Www-Xkms (E-mail)'
> |  Subject: RE: 2.0 Draft 8
> |  
> |  
> |  I think that the advantage in this case is that we can
> |  explicitly state the
> |  security assumptions that XKMS depends upon and how to apply 
> |  each choice of
> |  underlying technology.
> |  
> |  However, Regardless of how the message security is organized
> |  XKMS will be
> |  using its own security on top in XKRSS, e.g. we never send 
> |  private keys
> |  en-clair at the XKMS level even if we know the transport is secure.
> |  
> |  		Phill
> |  
> |  > -----Original Message-----
> |  > From: Joseph Reagle [mailto:reagle@w3.org]
> |  > Sent: Friday, June 14, 2002 11:38 AM
> |  > To: Hallam-Baker, Phillip; 'Krishna Sankar'; 'Www-Xkms 
> (E-mail)'  > 
> | Subject: Re: 2.0 Draft 8  >
> |  > 
> |  > On Friday 14 June 2002 11:30 am, Hallam-Baker, Phillip wrote:
> |  > > 	What I propose that we do is to move most of section 2, 
> |  > except for
> |  > > the schema discussion out of the XKMS document and make it 
> |  > a standalone
> |  > > 'message binding' document. This would have the 
> |  following outline.
> |  > 
> |  > I'm a big fan of seperating specification to provide clarity 
> |  > with respect 
> |  > to dependencies and layering. In the end if parts are similar 
> |  > mature and 
> |  > such, they can be recombined, but during the development it 
> |  > proves to be 
> |  > useful to me.
> |  > 
> |  
> 
>

Received on Tuesday, 18 June 2002 20:17:35 UTC