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

[Kelvin Lawrence <klawrenc@us.ibm.com>]

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:
http://lists.oasis-open.org/archives/ws-sx/200512/msg00027.html

Cheers
Kelvin
WS-SX co-Chair

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

02/07/2006 01:50 AM

To	Kelvin Lawrence/Austin/IBM@IBMUS, <dims@wso2.com>
cc	<ws-sx@lists.oasis-open.org>
Subject	AW: [ws-sx] Questions and comments.

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
>