In article <199412140047.QAA17489@jobe.shell.portal.com>, you write:

-----BEGIN PGP SIGNED MESSAGE-----

"Amanda Walker" <amanda@intercon.com> writes, quoting someone from Netscape:

...

...

I didn't bother imbedding the RSA Unaffiliated User CA because I didn't think server operators would use it to get certificates.

...

Well, it's what Apple is using for PowerTalk signers (which are a key pair and X.509 certificates, by default from the Unaffiliated User PCA). It makes sense for personal (as opposed to organizational) servers, such as someone running MacHTTP for their home page...

...

On the other hand, if RSA has set up a server PCA, that should be suffcient for now. I wonder what the certification policy is, though--how do you prove that you control a given server? For an Unaffiliated User CA certificate, you just have to show a notarized application and two forms of ID, one with a photo (driver's license, passport, etc.). I can't off hand think of an equivalently strong way to ID control of a server...

This relates to the other part of my question, which didn't get answered: what is the relationship between the name found in the X.509 certificate and the server? Does X.509 include an internet address like mcom.com, and the Netscape client checks that this matches the address of the server it is connecting to? I am not very familiar with the certificate format but I had the impression that it used a very different naming scheme.

Or does the client accept any valid certificate without regard to the connection if any between the name in the certificate and the server to which it is connected? This whole area was left undefined in the SSL spec but will be important for interoperability.

Hal

-----BEGIN PGP SIGNATURE----- Version: 2.6

iQBVAwUBLu5AkhnMLJtOy9MBAQEFQgH/dmiiEjycULNdDCNiU8SkoB57bHv9W5Lc d+K7cBqq0ZknCwXtqZtbPTR7d8F1z0WFbMlP6QF3zywVz2GrDIg5kg== =qQ9u -----END PGP SIGNATURE-----

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. --------------------------------------------------------------------- Kipp E.B. Hickman Netscape Communications Corp. kipp@mcom.com http://www.mcom.com/people/kipp/index.html