Hi, Oscar

The privacy problem is that your certificate is sent to any HTTPS server that 
you access as part of the handshake. The unlocking you mention you need only 
if indeed a client authentication process takes place which involves 
asymmetric encription via your private key.
If you have unlocked your keychain or certificate-vault once in a session you 
will not be warned in any way to whom the certificate will be disclosed.

I am not concerned at all about losing the private key. The SSL handshake does 
not disclose it, naturally. But the text contained in a certificate is 
already enough to disclose information about you. It contains your name and 
often also your email address. This is information you do not generally want 
to broadcast to every site you visit.

It is similar to cookie issues in web technology. Usually you try to make the 
most restrictive use of cookies possible, so you restrict cookies (if you 
allow them at all) to only be sent back to the server who placed them.

Cheers,
Derek

On Friday 30 March 2007 14:23, Oscar Koeroo wrote:
> Hi Derek,
>
> As I understand your comment, your suggesting that we shouldn't expose
> our personal certificates to any https-server.
>
> Most HTTPS servers do not require the user to be authenticating to it
> and will discard it or never request it. I've never had to unlock my
> certificate-vault when going to my online backing-account.
>
> When requested by an https server (usually in the grid environment) the
> public part of the certificate is send over for the hand-shaking and
> mutual authentication.
>
> The private key is the essential part of the process. The private key is
> the part that is never transmitted. It should also not be moved or
> copied from machine to machine. Of course the reality is (unfortunately)
> different on this point since you might need your certificate in
> different locations.
>
> This private key is the single element which can prove you as being the
> owner of a certificate. Expose that key and you will need to revoke your
> certificate at your CA unless somebody else has beaten you to it for the
> sake of the integrity of the user that has lost the private key to the
> public and the integrity of the services that the user is authorized to
> be using. It's beneficial to both ends.
>
> Exposing the public certificate to a public https server is not a
> problem since the https server can't fully reproduce the user's
> certificate. It can look the same, but that's why we have the trust
> anchors (=CA certificates) deployed to safe-guard against identity
> spoofing and the mandatory security systems that use them.
>
>
> I agree that more knowledge about the matter needs to flow to the
> public. It's very hard to explain all the details to everybody in a
> general way that is both understandable and effective.
>
>
> cheers,
>
> 	Oscar
>
> Derek Feichtinger wrote:
> > Hi,
> >
> > I think we should take care to better inform users about the privacy
> > issues of certificates used inside of their browsers.
> >
> > If the browser is not specifically configured to only provide the
> > certificate to specific sites (and I don't even know whether this
> > configuration possibility exists for all browsers), the certificate is
> > sent to every web server that uses HTTPS for some of its contents. Your
> > certificate can contain a lot of information, including your name and
> > very often also the email address.
> >
> > So, I think we should take care to inform the users to limit the sending
> > of the certificate to the relevant servers. Sometimes it's also useful to
> > configure use of particular certificates with certain servers, if you
> > have multiple certificates.
> >
> > Cheers,
> > Derek

-- 
Dr. Derek Feichtinger                   Tel:   +41 56 310 47 33
AIT Group                               email: [log in to unmask]
PSI
CH-5232 Villigen PSI