[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Does CPA support SSL mutual authentication?
Arvola Chan wrote: > > Dale: > > Thanks for the clarification. Some more embedded comments > bracketed by <ac> and </ac>. > > Regards, > -Arvola > > -----Original Message----- > From: Dale Moberg <dmoberg@cyclonecommerce.com> > To: Arvola Chan <arvola@tibco.com>; ebxml-cppa@lists.oasis-open.org > <ebxml-cppa@lists.oasis-open.org> > Date: Tuesday, August 21, 2001 11:39 AM > 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. > > <ac> > Within the DigitalEnvelope element, there is a CertificateRef. This > should provide the public key for the recipient that the sender can > use for encryption. > > There is no explicit CertificateRef for signing. Presumably, it has to > be stored at the CollaborationRole level. Yes there is. The certificateRef under NonRepudiation is for signing. I would agree though that bilateral exchange of certs in SSL is probably not addressed in the 1.0 spec. A CPA would need to identify the sender and receiver certs such that both parties know which certs will be used to authenticate the SSL connection. A CPP on the other hand should identify only the certificate that it will use for a given connection, leaving a blank to be filled in during cpp->cpa negotiation. > </ac> > > 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. > > <ac> > Do you mean signing using XMLDSIG? I am not aware that > S/MIME level signing is supported. Not directly as this would be an "application-level" function. > </ac> > > 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. I think that the CPP/A addresses the ability to use as many keys for the various functions as deemed necessary. The certificate which identifies the public/private key pair that is used for SSL need not be the same as that used for NR or for some other manner of authentication because the CPP/A does not limit the number of certificates that may be listed in a CPP/A. It might be useful to provide (possibly in 1.1 but more likely in 2.0) for each certificate to be accompanied by a purpose or description that made it clear as to what it represented. This may deserve some consideration. > > <ac> > I am hoping that simple changes can be made in 1.1. The timeframe > for RNIF 3.0 is before the end of 2002. > </ac> > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC