OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[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]