solderpunk solderpunk at SDF.ORG
Thu May 28 16:40:49 BST 2020
- - - - - - - - - - - - - - - - - - -
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 ofthis design, I have to admit. And only having support for one kind ofon-demand client certificate simplifies things. I just keep coming backto the thought that it's hard for the user to have all the informationthey need to make that decision. There's no way to stop people usingcertificate fingerprinting to do a bitcoin-esque tying of accountidentity to a private key. Some people might really think that's betterthan using in-band username and password (which is subject to weakpasswords, brute-forcing, theft of password database, etc.). So in alllikelihood both patterns will end up being used "in the wild". Andunless I know in advance what's coming up after I generate acertificate, it's hard to know what to do. If I'm about to be asked tosupply a username and password, I probably would have been happy with ashort-lived certificate which gets deleted when I close my client. IfI'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 definitelywant to pick something longer lived. This either requires differentstatus codes for different authentication models so that clients cansuggest sensible defaults and users can make informed decisions, *or* itrequires good communication from app designers at some point in the"sign in/up" workflow before the client request comes along (and goodunderstanding from the user).
Cheers,Solderpunk