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

["DeMartini, Thomas" <Thomas.DeMartini@CONTENTGUARD.COM>]

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

&Thomas.


-----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
recent
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
the
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
containing
the public key to be used for encrypting the response. Checking to see
if
the certificate is valid is insufficient (and probably unnecessary).
That
would not prevent an attacker from substituting his or her own
(perfectly
valid) certificate.

Interop scenario #3 does not have this problem, because the same key is
used
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
be
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
both
certs were issued to the same system entity (person), the SubjectNames
won't
match. Second it doesn't support the case where the requester and
recipient
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
proves
that the key came from the requester, which is what we are really trying
to
determine. This might be a good time to use /Usage={receiver}.

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

Hal


You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup
.php