Password authentication over Gemini

[Sean Conner]

It was thus said that the Great solderpunk once stated:
> >   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?

  I'm not so much afraid as I'm confused.  I came up with a status code
proposal back in June [1] where I had status codes for both password
authentication and certificate authentication:

unauthorized
        general
                rejected        301 *
        password
                require         310
                rejected        311
                expired         312
        certificate
                require         320
                rejected        321
                expired         322
                future          323

which you rejected outright and decided to go with just certificate
authentication.  I can only suppose you have changed your mind somewhat on
this.

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

  A username is a username.  Of the two protected areas on my Gemini server
[2], one requires a certificate I signed in order to access.  You generate a
CSR (certificate signing request), I sign it and send back the certificate.
It is also possible to send me (out of band) a certificate that you
generated that will also be checked upon each request, but there has to be
*some* unique information to check (that's not to say it has to leak your
real name or location or anything).  

Right now, the conman-labs-private area just checks the issuer of the
certificate. The other private area one will accept *any* certificate (aka a
temporary or transient certificate) and doesn't even bother checking the
certificate.

  -spc

[1]	geminmi://gemini.conman.org/notes/possible-error-codes.txt

[2]	gemini://gemini.conman.org/private/
	gemini://gemini.conman.org/conman-labs-private/