-----BEGIN PGP SIGNED MESSAGE----- From: kipp@warp.mcom.com (Kipp E.B. Hickman)

From the spec, the appendix on certificates:

Certificates are validated using a few straightforward steps. First, the signature on the certificate is checked and if invalid, the certificate is invalid (either a transmission error or an attempted forgery occurred). Next, the CertificateInfo::issuer field is verified to be an issuer that the application trusts (using an unspecified mechanism). The CertificateInfo::validity field is checked against the current date and verified.

Here is what we do in Netscape (for now). We have imbedded a set of certificates in the client. The certificates are for issuers of certificates that "we" trust. Any server which is certified by one of these issuers will be automatically trusted by the Netscape Navigator...

Admittedly this is primitive, but it's a start.

Thanks, I had overlooked that in the appendix. I notice you left off the next paragraph: Finally, the CertificateInfo::subject field is checked. This check is optional and depends on the level of trust required by the application using SSL. This subject field would hold the distinguished name of the server. That is pretty important to check! Otherwise anybody with any old certificate will fool you. In your appendix D when you describe the man in the middle attack, you say: The man in the middle operates by pretending to be the real server to the client. With SSL this attack is impossible because of the usage of server certificates. During the security connection handshake the server is required to provide a certificate that is signed by a certificate authority. Contained in the certificate is the server's public key as well as its name and the name of the certificate issuer. The client verifies the certificate by first checking the signature and then verifying that the name of the issuer is somebody that the client trusts. This is in accord with your description above. Note that the only name check mentioned is the name of the issuer. But later, in analyzing this attack, you say: If the certificate provided by the bad guy is legitimate, but for the bad guy instead of for the real server, then the signature will pass but the name check will fail Here you must mean a different name check, the optional one that checks the subject field. So this analysis is somewhat inconsistent with the procedure I quoted just above. Also, when you describe the subject name check as "optional" and depending on the required level of trust, perhaps you should say explicitly that if you don't do it you are vulnerable to a man in the middle attack. Actually, the attack is more general than that: if I could intercept connections to your server and use my own certificate to make the user think he is securely talking to you then I don't actually have to involve you at all. I am not a man in the middle, I am a spoofer pretending to be you. And you have marked the important step in the protocol which would check for this as optional. It appears from your docs that the Netscape client has a File menu item that brings up a Document Information dialog box which displays the distinguished names of the certificate issuer and of the subject (the owner of the key). This does provide a way of checking that you are securely connected to the server that you expect (assuming that the name is recognizable to the user). But it sounds like this is not something which the customer sees automatically. Again, this seems like an important security aspect which should be displayed more prominently. BTW, what do you see in the dialog when you connect securely to mcom.com? What is the subject name in your certificate? I hope these comments are helpful to you. I am surprised that you published this spec only after distributing implementations of it. This wil probably make it hard to change. Usually it is better to do the review before implementation rather than afterwards. Hal Finney hfinney@shell.portal.com -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAwUBLu9zThnMLJtOy9MBAQEVPgH+KObAFiOsALCGokUzk7gsqpnVEda85MUD 5LU5P2GjFhmR5msBKr6uuDKSrodUl69bq0/CfpE3qYSzcz7SGPrrag== =ivlO -----END PGP SIGNATURE-----