[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]