OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[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
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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC