Client certificate musings

[solderpunk]

On Sun, May 24, 2020 at 09:04:29AM +1000, Thomas Karpiniec wrote:
 
> This was the thing that stood out most on my first read-through of the
> spec! I particularly like the insistence "Transient certificates MUST
> NOT be generated automatically". I wasn't here for the earlier
> discussion but I assume this is to fend off servers making sessions
> purely for tracking purposes by default.

Right, transient sessions generated automatically and invisibly to the
user are not really any better than cookies.  Of course, even though tht
spec forbids is, there is a risk that clients start actually doing that.
The fact that generating a certificate takes a small but noticable
amount of time means this would not make for a good user experience,
which I hope is incentive against it.
 
> I've seen similar problems before with custom usage of X.509. It would
> be nice to use something smaller than UUID if possible just to keep
> cert size down - provided there is library support as you noted.

The cert size concern is a good one (the lack of connection reuse in
Gemini means that TLS overhead is more of an issue than it otherwise
would be.  This is one nice thing about self-signed certs, they will
typically be shorter as they won't have a long chain of intermediate
signing certs).  I think Sean's solution of having the spec require a
single fixed nonce value is a good one.  Having every cert identical
with regard to subject/issuer prevents linking certs together just as
well as having every one be unique.
 
> I'm not a big fan of using certificate fields for anything meaningful
> - it's a side channel (surrounded by lots of other fields that people
> might be tempted to use) - and it slightly increases the complexity of
> integration between the TLS library and the client/server code.

I guess I am seduced to some extent by the ideas in FOAF+SSL.  If the
cert can refer to some other resource (a FOAF profile in that case, but
we wouldn't need to follow that) and that resource contains the cert
fingerprint to validate the connection, then client certificates can -
if and only if the user wants them to! - be vehicles for rich
identities under full user control.
 
> When a server wants the client to use a non-disposable certificate
> there is an ambiguity. Is it just because they want the user to
> preserve their authentication for more than 24 hours for convenience?
> Or is it because the user will permanently lose access to their
> account if they ever lose that key?

The former, i.e. the idea is that, unlike a transient certificate (which
has the semantics of "I don't really care who you are and am not at all
interested in recognising you again next week, I just need to tie
together a handful of separate requests *right now*" - although that
idea can be destroyed if that handful of separate requests involves the
client providing a username and password), a non-disposable certificate
is supposed to be a persistent identity - what people think of as a
"user account" on the web.

In the simplest possible implementation of this, the server just uses
the cert hash as user ID and then, yes, we're in high-risk territory
where if the user doesn't backup their keys and certs then a hard drive
failure or theft of a laptop or similar scenarios result in lock out.
It doesn't *need* to work that way, though.  An application which users
authenticate to this way could give users the option to associate an
email address which could be used for the equivalent of "password
recovery" - email the user a URL with a random unique token in it and
tell them the first new certificate which visits that URL sometime in
the next one hour will become linked to their account.

> 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?

> One final thought: do we need a way to encourage clients to have
> multiple certificates for the same server, depending on path? If I
> authenticate to a CGI application on a multi-user server I don't
> necessarily want my identity to be followed by everybody else's
> applications on that server.

Ah!  I absolutely positively meant to bring this up in my original post
to this thread.  This is a very valid point.  Right now, the spec (and
my proof-of-concept implementations in AV-98) associates client certs
with a domain.  The presence of many multi-user servers in Geminispace
(and for what it's worth, I like those, a lot, assuming the users
constitute a community in some sense beyond sharing a server) means this
is not necessarily going to work well.  We could use the <META> content
of status codes which request a cert to specify a path or range of paths
for which the cert should be used.

I'm, unsurprisingly, extremely out of touch with modern web development:
are cookies still strictly tied to domains or have they evolved some
kind of path-specificity?

Cheers,
Solderpunk