[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] First go at WS-Sec one-pager
Sure, but in the WS-Sec model, by default the signature is not inserted within the body of the SPML (or other application) payload and as such any DSML schema restriction or SPML schema 'loosening' through <any> is immaterial. >-----Original Message----- >From: Jeff Bohren [mailto:jbohren@opennetwork.com] >Sent: Tuesday, June 10, 2003 11:50 AM >To: provision@lists.oasis-open.org >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 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]