Password authentication over Gemini

[solderpunk]

>   You're already asking for clients to generate a temporary certificate. 

Which is just some random bytes which can't be tied to anything or
anyone, so what's to be afraid of?

> Before going too down far this rabbit hole, why not make a few temporary
> certificates and hitting:
> 
> 	gemini://gemini.conman.org/private/
> 
>   There's nothing there that generates a status of 10, but it is asking for
> temporary certificates.  It's not even expecting any set information.  It
> might be instructive to know what what is and isn't required for a
> certificate.

Nothing at all is expected of an ephemeral cert generated in response to
a 61 status.  It's just a random session ID, or rather, some hash of the
cert becomes a random ID.

If a server throws up a 62 then it's expecting a *particular*
certificate from an authorised whitelist.  I never really imagined any
of the metadata fields on a certificate being used as part of the
validation (on a self-signed certificate they don't count for much),
though a guess if a server wanted to they could use them.
 
>   I meant I had no thoughts about your question re: status code of 11.  My
> question to you was, why have a usernames/password scheme when you have
> certificates, which are a combination of username/password?

Certificates aren't really comparable to a username/password
combination, though.  A user/pass combo I can carry around in my head
and use from any computer with a Gemini client.  A key/certificate pair are
a bunch of files I have to carry around on a USB stick and be careful about.
They offer two different trade-offs between security and convenience.  It's
entirely analogous to SSH authentication, where user/pass and private
key are both possibilities, and both widely used.

-Solderpunk