[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] First go at WS-Sec one-pager
Paul, It's not that DSML can prevent signing (or encryption), it's that if you insert a signature into an element defined by the DSMLv2 XSD, that element no logner conforms to the defintion as defined in the XSD. If you don't care about being XSD compliant it is not an issue. In SPML this is not a problem because we added: <xsd:any minOccurs="0" maxOccurs="unbounded" processContents="lax" /> And <xsd:anyAttribute namespace="##other" processContents="lax" /> To all element definitions. Therefore any additional elements or attributes can be added to and under SPML defined elements. This is what is meant by the Open Content Model. DSML v2 did not do this, although they might in the next version. Note that the DSML restrictions only apply to the case where you want to sign a part of a DSML message and include the signature in the message (enveloped signature). If you want to sign the entire message, there is no problem. Jeff Bohren Product Architect OpenNetwork Technologies, Inc -----Original Message----- From: Paul Madsen [mailto:p.madsen@entrust.com] Sent: Tuesday, June 10, 2003 11:19 AM To: Jeff Bohren; provision@lists.oasis-open.org 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_wor kgro up.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]