Client certificate musings

[Thomas Karpiniec]

On Sat, May 23, 2020 at 09:57:14PM -0400, Sean Conner wrote:
> > Or is it because the user will permanently lose access to their
> > account if they ever lose that key?
> 
>   Of if they get logged out and forget the password?  That can happen now,
> so I don't think it's of much concern.

I don't think these are really the same. Even ignoring the many people
who remember their passwords (against all good advice) there are well
established password managers and it's likely that random gemini
client X will require additional backup work to avoid losing its
keys. Strong passwords can be easily written down somewhere safe and
typed in, keys less so.

It also means the only way to share an account between multiple
devices is to copy the key material across, and coordinate renewals so
that it is only done once.

> > With this in mind, my current opinion is that there should be no way
> > for a server to request a non-disposable certificate. 
> 
>   I disagree.  I might want to serve up documents to a select few, and I can
> control that by given them a client certificate to use.

I think I made this statement broader than intended - it makes
complete sense to support that use case the way it's working now. I
didn't mean to say we should take that away.

What I meant was in a regular browsing session, where a client and
server meet each other for the first time, a server would not be able
to rely on the client having a permanent certificate store. They may
request (and get) a transient client certificate. They may encourage
the user to hold onto it. But a server application must assume that
the same person will need to reauthenticate with a new certificate at
some point in the future. This would solve both the user-friendliness
issue, and also the problem of client certificate renewal.

Looking at it another way, suppose it was possible for a long-term
client key to be generated, negotiated and stored, in-band via the
gemini protocol. My hope would be that most server applications would
eschew this in favour of user/pass authentication over transient
keys. However if setting up a permanent client key became common
practice (possibly because it's easier) I am worried that we would end
up in a similar situation to cryptocurrencies where only "hardcore"
users manage their own key material and others rely on some sort of
managed service to keep things safe but available to them.

Cheers,

Tom