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: Questions and comments.


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)

iD8DBQFD4gUwDQylxigoT5kRAhxCAKCjjJGErW6/pOSuBMbpQcFsdcjNpwCeJzCc
A38D1NSqHYxxMHekKGSgY/c=
=fY7d
-----END PGP SIGNATURE-----


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