Re: Does CPA support SSL mutual authentication?

[Arvola Chan <arvola@tibco.com>]

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.
</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.
</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.

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