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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [wss] Comments on Draft 3 of Web Sevrices Security Core Specification


Title: Comments on Draft 3 of Web Sevrices Security Core Specification

Attached are some comments/issues w.r.t. Web Services Security Specification,
Working Draft 3, dated 3 November, 2002.


Page 21, Section 7.1, lines 644-648, recommends that <wsse:SecurityTokenReference>
element should be used as direct childs of <ds:KeyInfo> elements to retrieve signing
and encryption certificate when using XML Signature and XML Encryption. Although
in section 8.4, there is a XML Signature example for using <wsse:SecurityTokenReferences>
element within the <ds:signature>'s <ds:KeyInfo> element, there is no examples
provided to using SecurityTokenReference element for XML Encryption in section 9.
E.g., Section 9.2 does have a <wsse:KeyIdentifier> contained within the
<xenc:EncryptedKey> element. However, it does not have the
<wsse:securityTokenReference> element encapsulating the <wsse:KeyIdentifier>
as specified in section 7.3.


Page 22, Section 7.2, lines 662, indicates that SecurityTokenReference/Reference/@URI
is an optional attribute. However, the corresponding XML Schema for WS-Security
core specification does not explicitly specify the the attribute "URI" of the
ReferenceType complex type as an optional attribute by use of "use=optional".
I suggest that the URI attribute be required rather than be optional as stated
on line 662.


Page 26, Section 8.4, lines 852-856, indicates a specifialized type of <ds:KeyInfo>
element that although is compatible with Section 7.1, I am concerned that
the core specification is silent on the subject of acceptability of processing
a signature element that uses an in-line X.509 data (representing, e.g., a
signing certificate). What processing behaiour is expected from WS-Security
compliant system that may receive a SOAP message that contains a
signature element in its SOAP security header, i.e.,  <wsse:security>,
that has a <ds:KeyInfo> element that does not contain <wsse:SecurityTokenReference>
element rather contains an in-line X509 data pertaining to the signing cert?
I think the specification needs to clearl state that all <ds:KeyInfo>
instances that contain in-line cert data are also acceptable in addition
to <SecurityTokenReference> element option if indeed we are allowing such
in-line X509 cert data type of KeyInfo element be part of signature elements.
The motivation of using SecurityTokenReference is mostly in the use case
where the same signing certificate, for example, may be used to generate
multiple signature elements (i.e., when same signing cert is used for
signing multiple SOAP message parts) within a <wsse:Security> header.


Having specific wordings of minimum requirements of what a SOAP/WS-Security
sending and receiving application must support w.r.t. KeyInfo elements
will help in security interoperability tests.


thanks,
Zahid Ahmed
Commerce One, Inc.



 






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC