[ANN] Gemini browser for iOS

[Sean Conner]

It was thus said that the Great Martin Keegan once stated:
> On Mon, 8 Jun 2020, solderpunk wrote:
> 
> >CGI and SCGI support to Molly Brown, including passing information about
> >client certs on to aps through the variables (following Sean's lead for
> >now, although I need to bring up some points for discussion about this
> >in the near future).  Very soon I will take advantage of this to start
> 
> My implementation is that $REMOTE_USER is set to the common name in the 
> cert subject. I think this is a good idea, but I don't think it's common 
> practice in the Gemini universe.

Of the dozen Gemini servers (software) out there, five (a little under half)
support CGI.  Out of those, blizanci, GLV-1.12556 and getforce (a little
over half) set REMOTE_USER to the common name of the certifiate.  The other
two don't set REMOTE_USER at all.  

The CGI standard (RFC-3875) states that REMOTE_USER is set only if
authentication is used.  blizanci sets is reguardless ("" if not there),
GLV-1.12556 and jetforce only set it if a certificate is used.

MollyBrown does not set REMOTE_USER, but does set TLS_CLIENT_SUBJECT_CN if a
certificate is used.  GLV-1.12556 will also set TLS_CLIENT_SUBJECT_CN if
TLS environment variables are enabled (and a certificate is used).

One open question---what if the certificate doesn't sent a common name?  I
think a subject *is* required, but I'm unsure of the mandatory subfields of
the subject.

> (I remain skeptical about whether SSL is the right choice - I reckon
> Gemini's simplicity goal is going to run up against the practice of
> trying to reuse as much existing infrastructure as possible.)

  Okay, what encryption system would you have us poor non-cryptographer
programmers who write servers use and poorly implement?  Feel free to bring
to the table a working server and client to show us how easy it is [1].

  -spc

[1]	If this comes across as too snarky or mean, this has come up at
	least twice on this list already.  The proposers were not, to my
	knowledge, professional cryptographers, yet were quite insistent on
	their proposals were sound.  I don't think anyone else on the list
	is a professional cryptographer and thus, can't say if the proposals
	were sound or not.  And the conventional wisdom is "Don't roll your
	own cryptography!" Using an existing and widely used solution is
	better than any other option at this point in time.

	Please keep this in mind when criticizing the choice of TLS.