implementing client certificate support

[solderpunk]

On Tue, Jun 09, 2020 at 10:23:55PM +0200, Peter Vernigorov wrote:

> My two cents: I don’t understand why server gets to decide if user’s
> certificate is transient or not. I as a user should make that decision.

Definitely agree.  I didn't mean for any of this to imply the server is
"in charge".  The whole reason client certs are so great as a cookie
alternative is that they put the power squarely in the user's hands!

The problem, I think, is that users need to be able to *make* the
decision on an informed basis.  If all I know is "the server needs a
cert", I will probably play it cautious and generate a transient one.
But if it turns out what the server wanted it for was to permanently tie
that cert's fingerprint to my ID, and I decide I quite like the service,
that's kind of a pain.  Unless the server implements a potentially
fiddly re-association feature.

Of course, servers could explain what the cert should be used for (and
should!) in the <META> (unless we repurpose that for a path, which I
still think is worth thinking about), but some users may not understand
the implications.  So I thought it would be nice for the server to be
able to provide a "hint" to inform the decision.  Of *course* the user
should always be able to make up their own mind.

I guess this problem goes away in a client design where all certs are
generated as transient by default but users can then opt to mark a
particular cert as persistent?  Hmm...

Cheers,
Solderpunk