AW: [ws-sx] Questions and comments.

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

Kelvin,

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.

Regards,
Werner

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