From 9df4233ff77aab6f897218e3045ee90ce8db00ed Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C3=96ppen?= Date: Sat, 31 Oct 2020 19:39:28 +0000 Subject: [PATCH] notes --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index e566ab9..df3122a 100644 --- a/README.md +++ b/README.md @@ -30,7 +30,7 @@ From the spec: * Long-lived client certificates can reliably identify a user to a multi-user application without the need for passwords which may be brute-forced. Even a stolen database table mapping certificate hashes to user identities is not a security risk, as rainbow tables for certificates are not feasible. * Self-hosted, single-user applications can be easily and reliably secured in a manner familiar from OpenSSH: the user generates a self-signed certificate and adds its hash to a server-side list of permitted certificates, analogous to the .authorized_keys file for SSH). -This suggests it'd be useful for a client to offer both a long-lived 'identity' cert, and short-lived anonymous certs to offer a (real) incognito mode - a session cert. +This suggests it'd be useful for a client to offer both a long-lived 'identity' cert, and short-lived anonymous certs to offer a (real) incognito mode - a session cert. In fact, looking at [Kristall](https://kristall.random-projects.net/) a client should offer full cert management, including import and export. A key sentence in the spec: