W3C home > Mailing lists > Public > www-xkms@w3.org > March 2002

RE: Hierarchy etc.

From: Hallam-Baker, Phillip <pbaker@verisign.com>
Date: Wed, 6 Mar 2002 10:37:48 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058699C4@vhqpostal.verisign.com>
To: "'Mike Just'" <Mike.Just@entrust.com>, "Hallam-Baker, Phillip" <pbaker@verisign.com>, "'www-xkms@w3.org'" <www-xkms@w3.org>
 
Actually, having just come up to the requirements doc on the security
requirements I think we have to go for the hierarchical approach.
 
 
In particular:

1.	[Transaction Security]
2.	All trust server responses MUST include a digest of the request
payload and the request URL. 

3.	Techniques for protection against replay attacks MUST be recommended
in the security considerations section. Specific techniques SHOULD be
defined, such as nonce, origination time, and serial numbers in requests,
for example. 

We are committed to support payload auth. I really don't have to repeat that
block of text in several places.
 
There are three basic approaches we can take here
 
1) Wait for ws-security / SOAP signing / whatever
 
2) Define a signature within our Request/Response structure in an inline
form:
 
<XXXRequest>
   <Blah/>
   <BlahDeBlah/>
   <Signature>
   </Signature>
</XXXRequest>
 
3) Define an enveloping scheme 
 
<Request>
   <XXXRequest>
      <Blah  .../>
      <BlahDeBlah  .../>
   </XXXRequest>
   <Signature>
   </Signature>
</Request>
 
 
Or we could combine 1 and 3 and define a SOAP header that essentially states
what the ws-security draft states.
 
<SOAP:Header>
   <SOAP:authentication>
      <Signature .../>
   <SOAP:authentication>
<SOAP:Header>
<SOAP:Body>
</SOAP:Body>
   <XXXRequest .../>
 
 
If we do this we would write it up in a separate document. That could later
become the basis for XML Protocol security when XP is ready for that type of
work.
 
[My view on ws-security is that it meets the objectives it sets out to meet,
but there are important additional mechanisms such as the use of cookies to
prevent DoS and possibly replay attacks which should be brought out].
 
 
        Phill

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


-----Original Message-----
From: Mike Just [mailto:Mike.Just@entrust.com]
Sent: Wednesday, March 06, 2002 9:03 AM
To: 'Hallam-Baker, Phillip'; 'www-xkms@w3.org'
Subject: RE: Hierarchy etc.



Although I see the advantage of using the abstract types (it's easier to
identify related elements; also makes for a shorter schema doc), I find the
flat structure much easier to read and analyze. 

Mike 

-----Original Message----- 
From: Hallam-Baker, Phillip [ mailto:pbaker@verisign.com
<mailto:pbaker@verisign.com> ] 
Sent: Tuesday, March 05, 2002 12:16 PM 
To: www-xkms@w3.org 
Subject: Hierarchy etc. 


All, 

        How do people think we should organize the schema? 

One option is the current 'flat' datastructure in which LocateRequest and 
ValidateRequest are both top level types 

A second option is to adopt the use of abstract types etc in the manner of 
SAML and introduce a RequestAbstractType that is extended by 
LocateRequesttype and ValidateRequestType 

        Phill 

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




Received on Wednesday, 6 March 2002 13:37:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:38 UTC