Arvola Chan wrote:
>
> Dale:
>
> Thanks for the clarification. Some more embedded comments
> bracketed by <ac> and </ac>.
>
> Regards,
> -Arvola
>
> -----Original Message-----
> From: Dale Moberg <>
> To: Arvola Chan <>;
> <>
> 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>
