[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] First go at WS-Sec one-pager
Thanks Jeff, edits noted I take your point with respect to the schema model but agree that we can't specify that level of detail here. How can DSML prevent signing? paul >-----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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]