[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] New Issue: Encrypted Response Public Key
Hal - The work we did on QoP and policy indicated that the encryption key for the response was (along with algorithm details and other things) a component of the requestor's policy for responses, supplied to the provider in the corresponding request. So, your recommendation that the requestor certify the response-encryption-public-key is consistent with that conclusion. It could be protected by a separate signature, verifiable by the same certificate and conveyed in its own security token. All the best. Tim. -----Original Message----- From: Hal Lockhart [mailto:hlockhar@bea.com] Sent: Thursday, June 05, 2003 6: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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]