[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[iaik-ssl] Resending : Diff in Client and Server TrustDeciders

I am resending this email. Would be very happy to receive your advice.



Sundar Krishnan wrote:


In your reply, you have said that "Handshake classes are for internal library use only and cannot be accessed by application programs."
Yes, I agree that the implementation details of SSLMessage and HandshakeMessage need not be shown, but since you expose SSLCertificate, and also since a customer may subclass further from SSLCertificate, is it not correct that the users ought to know atleast the public methods' signatures and the public state variables of these 2 classes ?


For eg, only as an analogy, take the case of java.awt.Panel which extends java.awt.Component. On a Panel object, a user can invoke all (public) methods of Component like repaint(), setBounds(....) etc. He can do so because the super class's public interfaces are documented even though implementation need not be.


Take this point as (FFF).    (4/5/99)

In the Client TrustDecider as well as the Server TrustDecider, a call is finally made to verify(PublicKey key) (abstract method of abstract class Certificate). However, in the case of the Server, the route is through hasTrustedRoot(-) which in addition to calling verify(-), also maintains a hashtable of vectors. I assume each vector is for a DN containing a chain of certs for that DN. Why is this extra hashtable not present in the Client Trust Decider code ? Assume that we always want 2 way authentication.

If each certificate in a Certificate Chain is to have it's own public key, why is it that we see code in the Client TrustDecider where all certificates except the top one (of CA) is verified with the public key of the previous certificate in the hierarchy ?
Again here, the code in the client side and server side differ in the 2 methods :
verifyCertificateChain(-) in ClientTrustDecider and hasTrustedRoot(-) in ServerTrustDecider.

In the Client side :
    chain[len-1].verify(chain[len-1].getPublicKey());     // Top Level CA certificate check is separate.
    for (int i = len-1; i>0; i--)

In the server side :
    for (int i=0; i<certificateChain.length; i++) {            // See the difference ; also no separate CA check ??
        if (i > 0) {

        In the Server side, we are maintaining a Hashtable of Vectors, each vector (follow index i)
        containing certain number of Certificates (follow index j) stored by their Principal Dist Names.
        Q ?? :- Why is this extra code not in the Client side ?
        Vector certs = (Vector)signers.get(certificateChain[i].getSubjectDN());
        if (certs == null) {

        for( int j=0; j<certs.size(); j++ ) {
          X509Certificate currentCert = (X509Certificate)certs.elementAt(j);
          if (currentCert.equals(certificateChain[i])) {
            return true;



Ref :- iSaSiLk 2.0 Final User Manual

a) Quote from P 80 :
"When the client handshaker has received the certificate request message from the server, it makes a call to the
getCertificate(..) method of the client trust decider thereby specifying the certification authorities and certificate types the server is willing to accept."

Q 1: Now which class represents the Client Handshaker ? ie, Which class 's method contains the call to getCertificate(...) of the
Client Trust Decider ? Any examples ?

Q 2: Similarly, which class represents the Server Handshaker ? Which class 's method contains the call to isTrustedPeer() of
the Server Trust Decider ? Any examples ?

b) In P 78, a difference is pointed out :
"The server - after obtaining the certificates and keys from some source - makes them available for the corresponding server
handshaker by immediately supplying them to the actual server context object. Later, during the handshake dialogue, when the
server handshaker requires  certificate/keys for authentication and key exchanging, it will get them from the server context.
The client passes the certificate and key obtaining task to the client trust decider, and the client handshaker - responsible for
managing the handshake dialogue - gets certificates and keys from the client trust decider."

Perhaps because I could not figure out which class(es) represent the Client Handshaker and the Server Handshaker, I could not
quite figure out why this difference is made betn the client and the server side.
Q 3: Why is the task of obtaining the certificate and key delegated to the Client TrustDecider, but not so in the Server side ?


Thanks for your answers in advance.


Sundar Krishnan