Re: [TLS] Client certificate authentication and

[Martin Rex <[e-mail]>]

Paul Wouters wrote:
> 
>Jim Schaad wrote:
>> 
>>> Oops. I checked draft-wouters-tls-oob-pubkey-00 and it was already
>>> removed there after discussion with EKR in Quebec City.
>>
>> If this is really what you want to do, then I would suggest that the
>> document be expanded so that there exists the possibility to include an
>> identifier and/or a public key in the certificate form defined by the oob
>> document.
> 
> Personall, I strongly prefer not adding more fields to the bare key
> certificate type,

That's OK and I don't see a need for that.


>
> as those people who want to cover client authentication can use
> full PKIX certs already, and TLS client authentication in the wild seems
> to be extremely rare.

I really dislike this answer.   What is wrong with plain public keys?
It works just fine with SSH.  You complained so badly about not wanting
to parse X.509 in your client, that I am somewhat appalled to see you
suggesting X.509 for client authentication. 

In our company we've been using SSL client certs for all Intranet systems
to which many of our employees need access (Portal, Wikis, Employee
self-services scenarios) since 1999, and we've even managed to use
it occasionally for stuff that was outsourced (over the internet),
because it is so much easier (and more secure) to configure SSL client
certs on a WebServer than to newly assign 50.000 passwords each time.

If you look around, in many places people can create user accounts
with arbitrarily chosen user names, so it really does not matter
what name you tag to the key (to make it easier distinguishable
for humans), if you tag the keys _at_all_.  If you look at the proposal
for "Origin-Bound Certificates", they also come with *NO* name
that identifies the user, so the concept of recognizing a peer by
its public key is really _not_ unusal.


>
> The only two cases I knew are CAcert and Fedora
> (and for the latter it does not even add security, as I need to identify
> with another factor anyway (yubikey))
> 
> Is there an actual use case where bare keys would be preferable over
> full PKIX, that also include client auth not based on burned in keys
> covered by server side SPKI lookups?

Why SPKI lookups?
Just have the server map public keys into authorizations,

-Martin