[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Does CPA support SSL mutual authentication?
Subject: Does CPA support SSL mutual authentication? Yes, but not expressed with the clarity that will ultimately be needed. Arvola>>The TransportSecurity element includes a Protocol element and a CertificateRef element. Presumably, the CertificateRef refers to the receiver's certificate. How can the sender's certificate be specified if mutual authentication is desired? There is a certificateRef under the CollaborationRole for the request/sender that is to represent the sender DN. However, I believe that, among other things, it is not clear that this certificateRef will be appropriate for the client side authentication handshake. Also unclear is whether this ref. is adequate when digital enveloping is used (and signing) and separate certificates (with diff. key usage extension attributes) are used for signing and enveloping. The security subteam will be concerned with providing enough certificateRefs at the right points for all the certificates that need to be referenced. We have tended to make these certificateRefs mark out commitment to the supporting signatures. I don't think the current version allows a distinction between SMIME level signing and SSL client side signing, though. Should this be a 1.1 concern or later? It is known that we need to check this out. One issue is just what identities are needed at what point in the middleware processing. Signing means access to a private key, and to allow the SSL speaker to gain access to a business private key proved controversial. In other words, though some software systems may do this, others may have policies against it. This means that we need to be able to model a situation in which each authenticating operation may need its own keypair, and own way of getting at the private key used for signing. These mechansisms are subject to various policies, and the parties may resist accepting certain mechanisms in use on the other side as being too subject to compromise. So for this reason, fully rationalizing the capability modeling has been postponed until we have the policy requirements under control. This speaks for making it a 2.x concern. We can make repairs needed for immediate usages, such as RNIFs dual cert mechanism for SSL authentication and SMIME signing.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC