[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue i009 - Support for different key pairs for sign and encrypt in SP
First of all the issue is incorrectly recorded. It relates to the ability of each party to use distinct key pairs for signing and encrypting, not the use of distinct key pairs by client and server. Discussion: Currently WS-SP section 7.5 says: ---- The AsymmetricBinding assertion is used in scenarios in which message protection is provided by means defined in WSS: SOAP Message Security. This binding has two binding specific token properties; [Initiator Token] and [Recipient Token]. If the message pattern requires multiple messages, this binding defines that the [Initiator Token] is used for the message signature from initiator to the recipient, and for encryption from recipient to initiator. The [Recipient Token] is used for encryption from initiator to recipient, and for the message signature from recipient to initiator. ---- This appears to me to preclude the use of distinct keys for signing and encrypting. This usage is a common best practice and is even mandated in some environments. However, the use of a single key pair for both signing and encrypting is also common and convenient. I believe WS-SP should support both alternatives. There are a couple of ways this could be done. One would be to define two different flavors of Asymmetric Binding Assertion. Perhaps "single use" and "dual use" or "shared" and "unshared" could be added to the name. Another alternative would be to retain a single Asymmetric Binding Assertion and define 4 Token elements instead of just 2, for example, InitiatorSignatureToken, InitiatorEncryptionToken, RecipientSignatureToken and RecipientEncryptionToken. Note that a decision must be made as to whether, for example, InitiatorEncryptionToken indicates the key pair used by the Initiator to encrypt data it sends or used to encrypt data sent to the Initiator. (While I am at it, wouldn't it be more logical to have Initiator-Responder or Sender-Recipient, rather than Initiator-Recipient?) Text changes are also required to indicate which keys are used for what in both the single key and dual key cases. Hal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]