Client certificate musings

[solderpunk]

On Sun, May 24, 2020 at 02:27:26PM +0000, solderpunk wrote:
> On Sun, May 24, 2020 at 09:04:29AM +1000, Thomas Karpiniec wrote:
>  
> > With this in mind, my current opinion is that there should be no way
> > for a server to request a non-disposable certificate. Where
> > authentication is required, it should be done in-band via a password
> > or username/password 10 responses as you noted, which is then
> > associated on the server with the transient certificate. It then
> > becomes the responsibility of clients to ask the user "how long do you
> > want to stay authenticated to this website?" If it times out, they can
> > simply repeat their authentication.
> 
> Hmm, interesting.  I'll ponder this, thanks for your thoughts.  My first
> reaction is that that I'm reluctant to remove a dedicated mechanism for
> creating something which is unavoidably and non-negotiably very short
> lived.  Maybe you didn't mean for that to happen, though?

I really like the "put all control into the hands of the user" aspect of
this design, I have to admit.  And only having support for one kind of
on-demand client certificate simplifies things.  I just keep coming back
to the thought that it's hard for the user to have all the information
they need to make that decision.  There's no way to stop people using
certificate fingerprinting to do a bitcoin-esque tying of account
identity to a private key.  Some people might really think that's better
than using in-band username and password (which is subject to weak
passwords, brute-forcing, theft of password database, etc.).  So in all
likelihood both patterns will end up being used "in the wild".  And
unless I know in advance what's coming up after I generate a
certificate, it's hard to know what to do.  If I'm about to be asked to
supply a username and password, I probably would have been happy with a
short-lived certificate which gets deleted when I close my client.  If
I'm about to be told "okay, great, we've taken your cert fingerprint,
this is now your idea, please back it up and be careful", I definitely
want to pick something longer lived.  This either requires different
status codes for different authentication models so that clients can
suggest sensible defaults and users can make informed decisions, *or* it
requires good communication from app designers at some point in the
"sign in/up" workflow before the client request comes along (and good
understanding from the user).

Cheers,
Solderpunk