- From: Hallam-Baker, Phillip <pbaker@verisign.com>
- Date: Wed, 6 Mar 2002 10:37:48 -0800
- To: "'Mike Just'" <Mike.Just@entrust.com>, "Hallam-Baker, Phillip" <pbaker@verisign.com>, "'www-xkms@w3.org'" <www-xkms@w3.org>
- Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058699C4@vhqpostal.verisign.com>
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
Attachments
- application/octet-stream attachment: Phillip_Hallam-Baker__E-mail_.vcf
Received on Wednesday, 6 March 2002 13:37:09 UTC