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