Subject: certificate chain

From: "Luo, Feng (Exchange)" <[email-masked]>
Date: Thu, 21 Oct 1999 20:28:54 -0400

In the SSL handshake, what's the standard that the SSL-enabled client
authenticates the SSL-enabled sever in the certificate chain of the web
server. It seems like that the Netscape browser and IE only look at the
server certificate sent by the web server, but the Marimba tuner is looking
at not only the server certificate but also the CA certificate which issued
that server certificate.
Can some one tell me which method is the RFC standard? Where can I have the
documentation on this?

Thanks
Feng

***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation, 
offer or agreement or any information about any transaction, customer 
account or account activity contained in this communication.
***********************************************************************

---

From: Peter Williams <[email-masked]>
Date: Thu, 21 Oct 1999 17:34:17 -0700

SSL does not specify the rules for certificate chain
validation. Also remember, that an SSL handshake
can use anonymously-originated messages in either 
direction.

TLS systems have to offer the backwards compatible
with SSL v3, which means that TLS systems
must process v1 certs.

> -----Original Message-----
> From: Luo, Feng (Exchange) [mailto:[email-masked]]
> Sent: Thursday, October 21, 1999 5:29 PM
> To: [email-masked]'
> Subject: certificate chain
> 
>

---

From: Zahid Ahmed <[email-masked]>
Date: Fri, 22 Oct 1999 11:44:24 -0700

I think validating the server cert is necessary but
not sufficient. Validating that the CA root public
cert is a trusted CA would also be required in many
clients. However, it seems that many SSL clients do
not do this (including browsers?). So, I think, in
practice we do have different levels of cert-based
authe going on.

In the case of anonymously-originated messages, the
(web) servers still need to be validated; the clients,
i.e., the senders, could be anonymous. 

> From: Peter Williams [mailto:[email-masked]]
> Sent: Thursday, October 21, 1999 5:34 PM
> To: Luo, Feng (Exchange); [email-masked]'
> Subject: RE: certificate chain
> 
> 
>

---

From: Peter Williams <[email-masked]>
Date: Fri, 22 Oct 1999 13:24:03 -0700

> From: Zahid Ahmed [mailto:[email-masked]]
> Sent: Friday, October 22, 1999 11:44 AM
> To: Peter Williams; Luo, Feng (Exchange); [email-masked]'

Each vendor does their own validation procedures on
the certiifcate processes of SSL; this is correct,
as SSL does not standardize those processes. It
is also consistent with the design of a "socket"
protocol.  

> i.e., the senders, could be anonymous. 

This is one option.  SSL also enables the server
to be anonymous ; that is,  it does not cite a certificate.

This means that a vendor client UA must have other
means to authenticate the server's handshake msgs; this may
mean that the server cert is locally supplied by the client
based on the src-address of the socket, or non-certificate 
based techniques are used.

This design ensure that SSL sockets can address multiuple
applications, without being tied to any given application; it 
allows for either server or client side path formation
according to the needs of the sockct application, for
either party. Furthermore, neither side is required
to use the certs which are delivered in the SSL stream,
it can always use an alternative chain, or no
chain at all.

Peter.

These features are important elements of SSL design. They
limit the power of CAs, or one of the parties, to control
communications. SSL does enable the parties to leverage
third-parties to remove the element of mutual suspicion.
Any further role of third-parties in an SSL design is
upto the vendors application; https is one such
semi-standardized concept linking SSL to UA-web-centered
http.