Hi,
> > I don't recommend this practice. It reduces the certificate to an
> > unauthenticated container of the public key and as such constitutes
> > poor security practice; it is both misleading, and places an undue
> > burden on users to understand the security implications of such a
> > choice.
>
> You are right if this were the only way to authenticate servers. What I
> intend is to use the normal way with CAs, but leave the choice to
> the user if
> the CA is not known. I particularly dislike the behaviour of MSIE
> _not_ to
> connect to a secure site with an unknown CA. Even if I _do_
> understand the
> implications.
On "medium" security settings for the Internet, my copy of MSIE pops up a
small series of dialog boxes asking me if I'd like to trust the
just-encountered server certificate that doesn't happen to chain to a
trusted CA certificate. I just did this test with my browser connecting to a
friend's web site with a dummy server certificate installed for his secure
web server.
> > That said, the answer to the technical portions of the question
> > are:
> >
> > The standard serialization format for certificates is DER. It
> > comes over the wire that way. The SSLeay package has APIs to deal
> > with encoding and decoding from this format. See in particular
> > the i2d_X509 and d2i_X509 routines. Also see the ASN1_i2d_fp and
> > ASN1_i2d_bio routines for combining these with file and buffered
> > BIO. [crypto/asn1]
>
> Thanks! That's what I was looking for!
Ok, I think I get it now...per your original post, this isn't necessarily
for https. You want to install your own custom trust decider for your
particular protocol when chaining fails?
Best Regards,
George
+-------------------------------------------------------------------------+
| Administrative requests should be sent to [EMAIL PROTECTED] |
| List service provided by Open Software Associates, http://www.osa.com/ |
+-------------------------------------------------------------------------+
