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


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

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

Subject: Re: AW: [ws-sx] Questions and comments.

Hi Werner,

I think there are a couple of choices (we don't intend the process to slow people down rather to make life easier). We can either discuss your e-mail on the call tomorrow and agree which ones should be issues or you could submit the ones that you think are issues using the issues template that Marc Goodner provided. If you have the time, using the template would probably make life easier for Marc in and the other TC members in tracking your issues accurately. My preference would be to have more rather than less (ie if you are not sure if there is one or two issues, create two and we can always merge them if we decide they are really the same). Having smaller issues helps discuss them I think.

Here is a pointer to the issue submission template (it's half way down in the posting) for this TC:

WS-SX co-Chair

"Dittmann, Werner" <werner.dittmann@siemens.com>

02/07/2006 01:50 AM

Kelvin Lawrence/Austin/IBM@IBMUS, <dims@wso2.com>
AW: [ws-sx] Questions and comments.


as I'm a newbie to the OASIS process I would appreciate some guidance
about the issue template stuff.

IMHO the topics indexed with a) through i) could be individual
issues at least. The paragraphs with index g and h) could be splitted
into 2 or 3 issues each.


> -----Ursprüngliche Nachricht-----
> Von: Kelvin Lawrence [mailto:klawrenc@us.ibm.com]
> Gesendet: Montag, 6. Februar 2006 17:09
> An: dims@wso2.com
> Cc: Dittmann, Werner; ws-sx@lists.oasis-open.org
> Betreff: Re: [ws-sx] Questions and comments.
> Hi there, thanks for the detailed text.  Is the intent that
> each/some of these be opened as an individual issue? If yes
> which ones?
> Ideally for the ones that you want to make issues, we need
> them submitted in the issue template format.
> Cheers
> Kelvin
> WS-SX Co-chair
> Davanum Srinivas <dims@wso2.com>
> 02/02/2006 07:12 AM
> Please respond to
> dims@wso2.com
> To
> ws-sx@lists.oasis-open.org, werner.dittmann@siemens.com
> cc
> Subject
> [ws-sx] Questions and comments.
> Team,
> Here are some notes from Werner. Am posting on his behalf as
> his membership status upgrade has gotten stuck somewhere
> and is unable to post.
> Thanks,
> dims
> ==============================================================
> ============
> All,
> here are some comments/remarks for the ws-sp spec. Most is editorial
> but some are also design and clarification.
> a)
> In chapter 6 the spec introduces several properties to control some
> behaviour. The actual XML implementation of the properties is given in
> chapter 7. It is somehow difficult to link the properties defined in
> chapter 6 to the actual XML tags defined in chapter 7. For example:
> the [Protection Order] property can have several values. Chapter 7
> then defines the real XML tags as e.g. <sp:EncryptBeforeSigning /> to
> set this property. Because this property can have several values there
> are several such XML tags to set this property. However, these XML
> names bear no direct link to the property. Thus I would propose to use
> the following notation to set a multi value property:
> <sp:ProtectionOrder value="EncryptBeforeSigning" />
> Such a notation would also simplify parsing because a parser has to
> look for one tag name only and can use the attribute to set the
> property's value.
> Other properties are defined as boolean (true/false)
> properties. However, the actual XML tag names to set the property
> differ from the specified property name - this is somehow
> confusing. Take the Signature Protection property as an example: to
> set it you have to use the XML tag <sp:EncryptSignature />. Why no use
> something like:
> <sp:SignatureProtection value="on" /> or
> <sp:SignatureProtection value="Encrypt" /> or
> just <sp:SignatureProtection />
> or something similar to make clear which property is set or defined.
> b)
> Chapter 6.1 [Algorithm Suite]
> The table at line 1280ff defines two properties [Sym KS] and [Asym
> KS]. Both propteries were not shown in the bullet list starting at
> line 1263. Should these two properties read [Sym Sig] and [Asym Sig]?
> The table starting at line 1282 defines a property [C14n]. This
> property name is the same as the abbreviation for C14n in table
> starting at line 1277. This is not wrong, but choosing different names
> would make it more clear.
> c)
> Chapter 6.3 [Protection Order] Property
> In "EncryptBeforeSigning" the spec states that both keys MUST derived
> from the same source. What does this mean? Use the same certificate
> for both actions (for example if a X509 cert is used). In that case
> this seems an unnecessary restriction. At least WS Security does not
> mandate this. Also using the same cert to encrypt and sign is not a
> good security practice.
> d)
> Chapter 6.5 [Token protection] conflicts with chapter 8.3 and 8.4.
> If the policy uses EndorsingSupportingTokens and sets [Token
> Protection] then I have the same behaviour as defined for
> SignedEndorsingSupportingTokens. Is that true? On the other hand if I
> use a SignedEndorsingSupportingTokens and do _not_ set [Token
> Protection] - what should be the result in that case?
> e)
> Chapter 6.7 [Security Header Layout]
> Here the spec defines "LaxTimestampFirst" and "LaxTimestampLast", both
> define that a Timestamp MUST be included. On the other hand in chapter
> 6.2 [Timestamp] the spec defines another way to switch Timestamps
> on/off. Which one rules?
> f)
> Chapter 7 introduces several Bindings, such as symmetric binding and
> asymmetric binding.
> During the asymmetric binding definition the spec introduces
> RecipientToken and InitiatorToken. The description of these tokens
> defines that both parties shall use the same token for encryption and
> signing. This restriction is not mandated by WS Security and should
> not be enforced. Also from a security point of view it should be
> possible to use different tokens for encryption and signature.
> g)
> Include a token in message (or not?)
> Using the token inclusion values (chap 5.1.1) one can specify when to
> include a token. On the other hand in chap 5.3.3 X509Token Assertion
> there are other way defined how to reference a X509 token. For example
> if "RequireIssuerSerialReference" is set and the inclusion value is
> "always": shall the token be included in the message? Which token
> shall the receipient take - the included one or the referenced?
> IMHO the SecurityTokenReference (WS Security spec) in this case shall
> contain the IssuerSerial reference - thus an inclsuion of the token
> would be superfluous?
> With respect to the WS Security specification I interpret the
> inclusion value "always*" or "once" without any additional "Require*"
> assertion as "include the token as a BinarySecurityToken and refernce
> it using a Reference in the SecruityTokenReference". Is this a correct
> interpretation?
> Also, with respect to WSS how to interpret or act on the
> RequireEmbeddedRefernce assertion? WSS does not specify an "embedded"
> mechanism for X509 certificates.
> h)
> Questions/clarifications regarding supporting tokens (maybe other
> tokens such a ReceipientToken etc as well)
> Can a Policy have more than one supporting token (of the same type),
> e.g. multiple SupportingTokens?
> Every supporting token can have more than one token assertion, e.g.
> X509 token assertions. If there are more than one such token assertion
> which on shall be used to sign/encrypt additional SignedParts or
> EncryptedParts if some are definied?
> An implementation that uses Security Policy Language has to know how
> to populate the required tokens, e.g. UsernameToken or X509
> tokens. Because a policy file usually contains several token
> assertions there should be an attribute to identify a token. For
> example if a policy requires two UsernameToken the application that
> creates the message needs a way to link the different UsernameToken to
> the user data records that contains username, password, etc. To do so
> the application shall be able to identify the UsernameToken and use
> this identifier as a link to the user data record. Simliar mechanisms
> are required to locate the correct X509 certificate in a keystore, for
> example. Any other ideas how to identify token in a Poliy file and
> associated them with real user/alias data?
> i)
> Clarification for UsernameToken assertion
> The UsernameToken defines additonal (optional) assertions that specify
> the WSS spec version. IMHO this is not enough to fully specify a
> UsernameToken. For example a UsernameToken may have a additonal
> elements such as a creation time. The WSS specs do not define in any
> way if such elements shall be included or not (some is recommended but
> no mandated). Also the UsernameToken assertion should have a way to
> define which password type to use: text or digest.
> Enhancement idea:
> WS SecurityPolicy profiles?
> Because the sepcification as it stands allows a very large number
> of combinations it is IMHO quite difficult to set up a working and
> correct security policy. Would it be possible to define some sort of
> "Security Policy Profiles" that define the most common usage patterns,
> for example based on WS-Security interop tests?
> Regards,
> Werner
> ==============================================================
> ============
> --
> Davanum Srinivas (dims@wso2.com)
> VP/Engg, WSO2 (http://wso2.com)
> Yahoo IM: dims Cell/Mobile: +1 (508) 415 7509

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