RE: Proposed new schema

Once more with attachment

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----Original Message-----
> From: Hallam-Baker, Phillip 
> Sent: Monday, March 25, 2002 3:55 PM
> To: www-xkms@w3.org
> Subject: Proposed new schema
> 
> 
> All, 
> 
> 	Attached is a somewhat revised schema, the major changes are:
> 
> 1) Use of Qnames for all enumerated items
> 	I am somewhat uncertain of the application of the 
> Qnames mechanism, for example should we link to the qnames 
> defined in other specs, should we use our own enumeration, 
> how does the extension mechanism work? In general the case we 
> have is that we want to define a set of basic codes but allow 
> for extensibility.
> 
> 2) Message abstract type introduced
> 	This is the point where we define the transaction ID, 
> signature semantics etc. It is also the place where we should 
> have a description of the abstract processing semantics when 
> using payload security.
> 
> 3) Reason code moved to Keybinding
> 	where is bellonged (see earlier message)
> 
> 
> Some open issues
> 
> 1) The Pending Response.
> 	The client should have a mechanism for stating that it 
> will accept a pending response. [NB this will absorb even 
> more of Bulk into XKMS]. I suggest a RespondWith Qname Pending.
> 
> 	If the client proposes Pending then IMHO there should 
> be an optional mechanism to specify a notification mechanism 
> on completion (c.f. the AST mechanism of VMS which was the 
> main reason the VMS systems consistently beat UNIX systems on 
> transaction processing benchmarks even with slower hardware). 
> This needs to be essentially open as we don't really want to 
> have to specify the notification protocol, and in many cases 
> this will be something like an email message is sent. I 
> suggest something like a method/port pair of URIs similar to 
> what we do in UseKeyWith.
> 
> 	Introducing this section would allow closure of many of 
> the questions pending on pending.
> 
> 2) Precise signing profile
> 	I believe that what we want to specify is that the 
> signature is enveloped and that the scope is the entire 
> message node with the exception of the signature itself.
> 
> 3) Denial of Service Protection / Replay attack
> 	Do we need to consider these?
> 
> 	If we do I think we need to introduce an optional 2 
> phase protocol as follows (looking at the Client FSM):
> 
> State Initial
> 	Transition !Request Waiting 
> 		// Send out initial request to service
> 		// Go to state Waiting
> 
> State Waiting
> 	Transition ?Response.Complete Completed
> 		// Service is not in DoS state and does not care
> 		// about replay attack
> 	Transition ?Response.Represent Represent
> 		// Service requires the request to be represented
> 		// together with an authentication nonce
> 	Transition ?ANY Fail
> 
> State Represent
> 	Transition !Request Waiting 
> 		// Represent request to service together with nonce
> 
> State Waiting2
> 	Transition ?Response.Complete Completed
> 	Transition ?ANY Fail
> 
> State Completed
> 	Terminal
> 		// We Won 8=)
> 
> State Fail
> 	Terminal
> 		// We Lost :-(
> 
> The nonce is cryptographically bound to the request so that 
> the service can quickly determine if the nonce presented is 
> valid and corresponds to the given request (cf JFK).
> 
> 
> Ideally the nonce would be bound into the represented request.
> 
> Looking to the future this is exactly the type of facility 
> that we would want to see bound into the Web Services 
> security layer and into WSDL.
> 
> I would like the WSDL to tell me the following facts about the service
> 1) The public key of the service
> 2) The encapsulation formats the service supports
> 	[e.g. ws-security, TLS, IPSEC, payload etc.)
> 3) If a key agreement service is available / must be used
> 4) If 2 phase DoS protection is available / must be used
> 	the level of authentication required on the 1st, second message
> 
> If I know in advance that the service is definitely going to 
> do DoS protection then I probably don't want to send a 
> signature on the first request, in fact I might only want to 
> send a hash of the request.
> 
> 
> Clearly this level of protection is something that we might 
> say should be pushed down into the XP/SOAP layer and can be 
> defered. It would certainly be simpler to deal at that level 
> since it would be easier to do this type of processing with a 
> detached signature in a SOAP header. That way the signature 
> can consist of a pretty simple manifest with clean semantics 
> and not need to worry about the complexity of enveloped processing.
> 
> On the other hand folk might reasonably expect XKMS to 
> provide for DoS and Replay attack protection.
> 
> 
> 		Phill
> 
> Phillip Hallam-Baker FBCS C.Eng.
> Principal Scientist
> VeriSign Inc.
> pbaker@verisign.com
> 781 245 6996 x227
>