> > Not quite sure what you mean by bogus certificate.
> Test certificates (Snake Oil and such).
OK.
> > The protection of this private-key is what's important here.
> > You may rely on the hardware being physically secure to prevent the
> > key being stolen, or on the operating system, or require that the
> > private-key be stored on a smart-card. However you do it, your
> > guarentee of client id is only as secure as that private key.
> So, how do the browsers manage the private-key? Is it only
> the OS that prevents unauthorized access to it?
Can't speak for Netscape, haven't used it in years, but IE relies on
the OS. Certificates and private keys are stored in "Certificate
Stores". There is one "Certificate Store" per user, and one for the
whole system. How this is implemented I really don't know, so can't
tell you a whole lot more.
On 2K systems, you can browse the certificate stores using an MMC
plug-in. None of the default Administrative Tools include it, but
start MMC.EXE and then add the plug-in. It's pretty obvious
"Certificate Manager" or something like that.
> > > How do I know that I'm giving the certificate to the browser that
> > > requested it?
> >
> > You get them to include a password in the request, which is used to
> > encrypt the private-key. Without that password, the private-key is
> > of no use to them and they can't perform client authentication.
> Do the browsers manage this by themselves? (i.e.: Do they prompt for the
> passfrase as mod_ssl does on starting up?)
Again speaking for IE here... IE can either ask for the password when the
certificate is to be used, or you can specify the password when importing
the certificate and never have to bother with it again.
> > The real big question, is how do you know that they are who
> > they claim to be when they make a certificate request.
> Mmmhh... What sort of information can you ask for to validate?
In a small to medium sized organisation, you can get them to input some
detail and then phone them up to check they've made a request, check the
detail (e.g. favourite colour) etc.
In larger organisations, or in disperse environments, things are a little
more difficult. It really all depends on your environment, weighing risks
of fraud against the cost of attempting to prevent that fraud.
In most organisations, the biggest risk will come from careless / trusting
users who will either leave their workstation logged on and unattended (with
either a session in progress or no password on their key) or tell a
colleague
the password so they can do something for them etc etc etc.
Dale.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
