[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] First go at WS-Sec one-pager
The original motivation for the 'SPML Security Requirements' one-pager (at http://research.entrust.com/misc/spml/spml-wssec-02.html) was to (in part)ensure that we had something to talk to if including the mocked-up WS-Sec XML in the SOAP Header didn;t work out. Given that we are now including the WS-Sec header, do people feel that the one-pager is still relevant? Paul >-----Original Message----- >From: Paul Madsen [mailto:p.madsen@entrust.com] >Sent: Tuesday, June 10, 2003 12:29 PM >To: 'Yoav Kirsch'; provision@lists.oasis-open.org >Subject: RE: [provision] First go at WS-Sec one-pager > > >Yoav, some argued for inclusion of mocked-up WS-Sec in the XML, others >questioned the value relative to risk. The decision was to not make it >required at this point, but rather to explore and test the >issues at the >glue party, determine if it can be added with minimal effort >and impact, and >then make the call. > >As a potential replacement (or at minimum a supplement) I >created the brief >blurb linked to below, the thought is that it would be available as a >handout when somebody asks 'what about security?'. > >Paul > >>-----Original Message----- >>From: Yoav Kirsch [mailto:Yoav.Kirsch@businesslayers.com] >>Sent: Tuesday, June 10, 2003 12:16 PM >>To: 'Jeff Bohren'; provision@lists.oasis-open.org >>Subject: RE: [provision] First go at WS-Sec one-pager >> >> >>I was not on the call Monday and did not see the minutes. >>Was there any decision about WS-sec ? >> >>Yoav Kirsch >>Director, Applications Development >>Business Layers >> >> >>-----Original Message----- >>From: Jeff Bohren [mailto:jbohren@opennetwork.com] >>Sent: Tuesday, June 10, 2003 10:28 AM >>To: provision@lists.oasis-open.org >>Subject: RE: [provision] First go at WS-Sec one-pager >> >> >>I would change: >> >> Similarly, message confidentiality for SPML messages is provided >>by ... >> >>To: >> >> Similarly, message confidentiality for SPML messages can be >>provided by ... >> >>To avoid implying that confidentiality is only supportable via XML >>Encryption. >> >>Also in your example, the ds:Signature element does not really >>look like >>a signature block. I would replace everything between the ds:Signature >>tags with a "...". Otherwise you will need to put something more like: >> >><Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> >> <SignedInfo> >> <CanonicalizationMethod >>Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" /> >> <SignatureMethod >>Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> >> <Reference URI="#xpointer(/)"> >> <Transforms> >> <Transform >>Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /> >> </Transforms> >> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" >>/> >> <DigestValue>FIAfiU5bhQedxlFcScsDrTvDCVM=</DigestValue> >> </Reference> >> </SignedInfo> >> >><SignatureValue>bjTFg+umISJuPsuce+jkVht86oyze+EF6qrgzqD2pb+YFcj >>DETrF4Yeq >>3rNF8LBfHrfdD6f1yLobLOSJmstqgOd0Q/crrVVr4MopUHE36Vr2Tu13goBMSht >>fCfP96VCu >>ldCXvYqfGIYV9GqUX+wIBzRGTyBlD3JS7jYs4zMifxY=</SignatureValue> >> <KeyInfo> >> <KeyValue xmlns="http://www.w3.org/2000/09/xmldsig#"> >> <RSAKeyValue> >> >><Modulus>6Z8wWVYkjdwJkExPXbXFueXQSccZhs0uFE07IA89egpvJdiJTJajkS >>+0SoKftk/ >>3uBKPowXX6YPVhFP8S2WJI4O/8HchAeE5tYtk9r0oYzhCHocWFEsTdb7qxqEls4 >>cJ4DHpxtU >>kNOF4FfrbcBtj04TqGCgIGXDBYAFovb5s4TE=</Modulus> >> <Exponent>AQAB</Exponent> >> </RSAKeyValue> >> </KeyValue> >> </KeyInfo> >></Signature> >> >> >>Also there is one important caveat on supporting XML Digital >Signatures >>and XML Encryption. By supporting the Open Content Model in >our XSD, we >>allow parts of the message to be encrypted or signed while retaining >>compliance with the XSD, in some cases. There are, however, >>limitations. >>The limitations are: >> >>1) The SPML XSD depends on the DSML v2 XSD. The SPML XSD supports the >>Open Content Model, but the DSML v2 XSD does not. Elements defined in >>the DSML v2 XSD can not be digitally signed or encrypted by themselves >>and still be XSD compliant. They can, however, be part of a digitally >>signed or encrypted element in the SPML XSD. Because of this >limitation >>you could, for instance, encrypt just the password attribute of an add >>request and still be XSD compliant. You also could not encrypt all the >>SPML attributes element for the add request either and still be XSD >>compliant(see the next point for why). >> >>2) When digitally encrypting an element defined in the SPML XSD, that >>element not longer exists from the standpoint of XSD validation (until >>it is decrypted). If removing that element from an SPML message would >>violate it's XSD compliance, then XML Encryption is not technically >>supported for those elements. For instance, on a modify >request, if the >>identifier is encrypted, then from the standpoint of XSD validation it >>no longer exists. A modify request without an identifier is not >>considered valid. Obviously the identifier would need to be decrypted >>before the request could be fullfilled, but any intermediary XSD >>validating processor (e.g. an XML firewall) would treat the request as >>being not XSD compliant. >> >>So what can you safely do with XML signatures and encryption >>if you care >>about maintaining XSD compliance? You can digitally sign any element >>defined in the SPML XSD. You can encrypt the entire SPML message. In >>some cases you can encrypt an SPML element, but there are so many >>restrictions I would not recommend it. Of course you can do anything, >>open content model or not, if you don't care about XSD compliance. >> >>I'm not sure how deep we want to go into this, but I felt is was >>important point out these issues, at least for this TC. >> >>Jeff Bohren >>Product Architect >>OpenNetwork Technologies, Inc >> >> >> >>-----Original Message----- >>From: Paul Madsen [mailto:p.madsen@entrust.com] >>Sent: Tuesday, June 10, 2003 9:10 AM >>To: provision@lists.oasis-open.org >>Subject: [provision] First go at WS-Sec one-pager >> >> >>Hi, I took an action yesterday to take a stab at creating the SPML & >>WS-Sec handout we discussed - a decision remains as to whether this >>supplements or replaces any mocked up WS-Sec within the XML. >> >>I've posted the draft at >>http://research.entrust.com/misc/spml/spml-wssec-01.html >> >>Feedback please >> >>Paul >> >>----------------------------------------------------------------- >>Paul Madsen >>e: p.madsen@entrust.com <mailto:p.madsen@entrust.com> >>p: 613-270-2632 >>Entrust >>Securing Digital Identities >>& Information >>http://www.entrust.com >> >> >>You may leave a Technical Committee at any time by visiting >>http://www.oasis-open.org/apps/org/workgroup/provision/members/ >leave_wor >kgroup.php > > >You may leave a Technical Committee at any time by visiting >http://www.oasis-open.org/apps/org/workgroup/provision/members/ leave_workgro up.php You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgro up.php You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgro up.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]