OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

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

Subject: RE: [wss] New Issue: Encrypted Response Public Key

Another thing to keep in mind is that this usage of the Usage attribute
is message-specific semantics that will need to be repeated in the
message body.  Depending on how much is repeated in the message body and
how the reference is made, signing the message body may be sufficient.

Perhaps the key for encryption should even be put in the message body
*instead of* the security header.  The reason for this is that the key
for encryption has nothing to do with the security-specific processing
of the message and everything to do with the message semantics of what
the application will do once it receives such a message.  When the
response is generated, *then* the encryption key will be in the security
header of the response.

Or, do we wish to require that the application has no knowledge of the
encryption of the response and that the response automatically gets
encrypted by some security layer?  In this case, perhaps this is not
wsse but some other header or something to do with policy as Tim points
out.  (Though, I don't agree with him that including the token in the
security header is "consistent" with handling this in the policy domain.
It seems to me it should be in only one place: either the message, if it
is application-specific, or the policy, if it is an
application-independent automatic function.  In any event, it does not
belong in the security header.)


-----Original Message-----
From: Hal Lockhart [mailto:hlockhar@bea.com] 
Sent: Thursday, June 05, 2003 3:23 PM
To: wss@lists.oasis-open.org
Subject: [wss] New Issue: Encrypted Response Public Key

Because Interop Scenario #3 uses two key pairs instead of four key
pairs, it
avoids a security threat in a way that was not apparent to me until a
internal review. The basic issue is: when the responder encrypts the
response, how does it determine that the public key it uses is that of
proper party and not some attacker.

Suppose each party has two key pairs, one for signatures and one for
encryption. Let us assume the requester provides a certificate
the public key to be used for encrypting the response. Checking to see
the certificate is valid is insufficient (and probably unnecessary).
would not prevent an attacker from substituting his or her own
valid) certificate.

Interop scenario #3 does not have this problem, because the same key is
to sign the request, thus demonstrating that the requester knows the
corresponding private key.

There is more than one way to solve this problem. One possible way would
to require that the SubjectName in the encryption certificate is the
same as
the one in the signature certificate. I do not think this is a good
approach. For one thing there are a least a dozen reasons that even if
certs were issued to the same system entity (person), the SubjectNames
match. Second it doesn't support the case where the requester and
are distinct.

A better solution would be to require that the encryption certificate
(or at
least the public key) fall under the signature of the request. This
that the key came from the requester, which is what we are really trying
determine. This might be a good time to use /Usage={receiver}.

Finally, note that one implication of this is without a signature, we
get much in the way of security guarantees, even if we use encryption.
But I
guess we knew that.


You may leave a Technical Committee at any time by visiting

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