[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: XML DSIG for authentication
Sekhar, I agree with 2c, and that is out of scope for V2 anyway (confidentiality). I have some info that will apply to 2b (S/MIME and XML Sig), but since 2c is out of scope for V2, we don't need to discuss that for some time. 2a is important and needs to be dealt with now, as is 1. Hope this helps, -Suresh -----Original Message----- From: sekhar vajjhala [mailto:sekhar.vajjhala@Sun.COM] Sent: Friday, September 21, 2001 3:55 PM To: regrep-security@lists.oasis-open.org Subject: Re: XML DSIG for authentication Hi folks, I have been going through all the responses. Thanks for all the comments ! Instead of responding to each mail thread I thought I would roll up all my responses in here. It is much clearer this way. I will address the major issues for now: 1. It is my understanding, that for Registry V2.0, ebXML is supposed to run on either SOAP or ebXML MS (maybe more in future for RAWS ?) So Prasad, in response to your question, it is not being divorced from ebXML MS totally - but there is a choice. > Are we divorcing ebXML MS totally and expect this to run on any SOAP complaint protocol > including ebMS? Sekhar's description refers to ebXML header and its use of ds:Signature element. > So, I take we are still scoping for ebMS as the primary TRP right? We are scoping for both ebMS and SOAP. 2. The XMLDSIG usage should be applicable to both ebMS and SOAP. The proposal that I have won't work with ebMS only with SOAP. This is fundamentally because the payload signatures are carried in a SOAP header. This also has other disadvantages. In order to handle the XMLDSIG for both ebMS and SOAP, the payload signature needs to be bound to the payload itself i.e it is carried with the payload itself. This is the consistent feedback that I have received (including onefrom Suresh). I too think this is the right way to do it. But there are some issues: a. We need to specify how exactly the payload signature would be carried with the payload. Note ebMS strongly recommends that payload be signed separately with XMLDSIG. However, ebMS does not specify or impose any requirements on the payload ( carried as MIME multipart). It leaves it upto the application. This is all based on my reading of the ebMS spec. b. S/MIME specifies a way of signing/encyrption for MIME data objects. There are 4 different rfcs on S/MIME (with different versions) and I am not familiar with all of them. But the main thing is that S/MIME allows different signatures and encryption mechanisms to be specified. So it could be possible to specify an XMLDSIG as part of S/MIME. I am not proposing we do the above - but suggesting that this is one possibility. I will investigate the above option. c. The application of dsig to signing of payload is really about SOAP (and/or S/MIME) security. It is not specific to either ebXML Registry *AND* ebMS specs. So this should be done outside of both these specs. I may have more comments on Monday (I have to go home now). Sekhar ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC