[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] First go at WS-Sec one-pager
I'd say very much so. KevinB did have some feedback on the use of ID's that we'd want to include, otherwise I think we should finalize the draft and have it available on the committee site before the event. ========================================================= Darran Rolls http://www.waveset.com Waveset Technologies Inc drolls@waveset.com (512) 657 8360 ========================================================= > -----Original Message----- > From: Paul Madsen [mailto:p.madsen@entrust.com] > Sent: Monday, June 23, 2003 11:39 AM > To: provision@lists.oasis-open.org > 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 > > You may leave a Technical Committee at any time by visiting > http://www.oasis- > open.org/apps/org/workgroup/provision/members/leave_workgroup.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]