New Issue: Encrypted Response Public Key

["Hal Lockhart" <hlockhar@bea.com>]

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