Re: Public-Key authentication for websites

Christoph Hack wrote:
> Oh, you are right. Looks like SSL/TLS is exactly what I want, I just
> haven't known that you can create and use this certificates on the
> client side too. I never saw that before, but I will take a deeper look
> on it.
> 
> The only problem is that you must pay quite a lot for a trusted
> certificate and that you aren't able to use existing Web-of-Trusts (if
> you are using cacert). (Beside of that fact, that SSL/TLS doesn't
> work on virtual hosts). And that nearly nobody owns a private
> certificate (in comparison to GPG keys, which are well known in Linux
> communities *g*).

I'm glad this is helpful to you, and I would encourage you to take a 
closer look, but I wanted to catch a couple things up front.

First off - vis a vis pricing on SSL certs, if you are looking to 
experiment, there are several CAs that will cut server SSL certs for 
<$20, and a couple that do them for free, so I hope you won't find the 
expense too prohibitive.

But also, for client certs, there needn't be any cost at all, at least 
not for a particular site.  A client cert's job is to prove *to the 
server* that you are who you claim to be.  With that in mind then, a 
server can generate and sign its own client certificates as needed; as 
long as the certificate presented by a client is one the server has 
properly signed, the server can trust it.  Because this case is 
Many-to-1, there isn't a real need for the CA, who acts as a trusted 
third party in many-to-many transactions.

On the other hand, if you want a client certificate which is accepted 
and recognized by multiple unrelated servers, which identifies you as 
you in some verified way, then yes, I imagine there will be a cost 
involved in that verification.  Some of this work already exists for 
individuals acquiring things like code-signing certificates, but you 
might also look at the various (ahem) "Identity 2.0" companies out there 
who are trying to build a marketplace around this concept.

Cheers, and happy hunting,

Johnathan

> 
> Anyway many thanks for your answer :)
> 
> Christoph
> 
> 
> On Fri, 2008-02-15 at 10:41 -0500, Johnathan Nightingale wrote:
>> I'm not sure if this is the right list (nor how precisely, for that  
>> matter, I got onto this list :) but how does your idea differ from  
>> just using client certs?  Yes, that potentially means the format of  
>> your GPG key might not be directly compatible, but there is pretty  
>> widespread use of, for instance, government-issued non-repudiation  
>> keys for e-government stuff.
>>
>> As far as I know, though I haven't looked in detail, most modern  
>> browsers allow sites to store client certs, and to request client  
>> certificates as part of the TLS handshake.
>>
>> Or am I totally missing your point?
>>
>> Johnathan
>>
>>
>> On 14-Feb-08, at 7:00 PM, Christoph Hack wrote:
>>
>>> Hiho everybody,
>>>
>>> today Public Keys are very popular and most Internet applications
>>> support GPG-Keys (e.g. lots of Mail readers and Jabber). Those public
>>> keys are much more secure and the user doesn't have transmit his
>>> password and remember it.
>>>
>>> But up to now, there aren't any Web Browsers which support a way to
>>> ask the user to sign something with his personal GPG Key. (please tell
>>> me if I'm wrong). But I think if somebody could write a RFC or  
>>> something
>>> similar for that, there might be a chance of getting this feature into
>>> some full-featured browsers :)
>>>
>>> Use Case:
>>> A use case for that could be the authentication handling for a web  
>>> site.
>>> The websites must provide an (optional) way for the user to attach his
>>> public keys to his profile and when the user wants to log-in, it's
>>> enough if he is able to decrypt or sign a specific message.
>>>
>>> Benefits:
>>> - the user must not remember different passwords
>>> - it's probably much more secure than other password handling methods
>>> - websites could use this as an alternative authentication method
>>> - Bruce Force attacks against hashes in big databases (like recently  
>>> on
>>>   phpbb, woltlab, smf) aren't possible any more
>>> - and yes, I know that this idea is similar to OpenID, but it doesn't
>>>   require any additional services
>>>
>>> Problems:
>>> You can't use static messages for signing or decrypting, because then
>>> there is a high risk that somebody might collect and use the
>>> authentication information again. On the other side, completely  
>>> dynamic
>>> keys allow the server to get any messages signed by the user, probably
>>> with content the user don't want to sign. So there must be a well
>>> defined format (for example a tuple including a general header to
>>> describe the context, a domain and a secret (session)-key)...
>>>
>>> So, I am very interested in your opinion now. Do you think there is a
>>> way to get a feature like that? Or is this idea just a crap?
>>>
>>> Regards,
>>> Christoph Hack
>>>
>>>
>>> PS: I hope this is the right ML to share this idea, if not please
>>> redirect to the right one...
>>>
>>>
>>>
>> ---
>> Johnathan Nightingale
>> Human Shield
>> johnath@mozilla.com
>>
>>
>

Received on Friday, 15 February 2008 17:45:28 UTC