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


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

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

Text changes are also required to indicate which keys are used for what
in both the single key and dual key cases.


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