CGI, SCGI and Certificates (was Re: [ANN] Gemini browser for iOS)

[solderpunk]

On Fri, Jun 12, 2020 at 08:13:28AM +0000, defdefred wrote:
> Maybe adding version for whole gemini protocol ?

I am fairly staunchly against this, and always have been.  I'm not sure
how popular a stance it is.  In my mind, having protocol versions which
are signalled in-band is just an invitation to endlessly upgrade over
time, and completely defeats the point of all the efforts to limit
extensibility.

I strongly believe that the computing world in general could really
benefit from a healthy dose of the attitude that "things should be
allowed to be finished".

I am hopeful that Gemini is simple enough that we can "get it right", or
right enough, the first time and then just enjoy building stuff within
whatever limitations it imposes forever after.  Gopher is more than 25
years old and people are still using it with very few changes to the
official spec.  I don't see why we can't hope for similar longevity.
Some of Gopher's biggest problems stem just from the fact that it was
born very early - before URIs were invented and before
internationalisation was taken seriously.  Had Gopher been born just a
little later (or had those early major disruptions happened just a
little sooner), it might be being used *exactly* as specced today (well,
the `i` item type would probably still have evolved).

Gopher's item types have not aged well, but we are using MIME types
instead, which are extensible and therefore likely to be usable for the
forseeable future.

Exciting new internet protocols might gain major traction in the future,
but it's a very safe bet they will come with URI schemes, so Gemini will
be able to link to them, no problem.

If there are major happenings in the cryptographic landscape, it is
reasonable to expect new versions of TLS to address that for the
forseeable future, and Gemini will come along for the ride.

At the end of the day, the basic problems we are trying to solve are not
difficult and have not changed for a long time.  Good solutions to these
problems should have long lifespans.  Constant upgrades are a sign of
bad solutions, or excessive ambition / scope creep: HTTP/2 has only come
along because people are convinced that viewing a document online needs
to involve downloading 1,000 inter-connected components from 100 hosts.
Gemini rejects that as obvious nonsense, so it's fine to design with no
intention of that every working well.

Cheers,
Solderpunk


> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Friday 12 June 2020 01:39, Thomas Karpiniec <tkarpiniec at icloud.com> wrote:
> 
> > On Thu, Jun 11, 2020 at 07:50:18PM +0000, solderpunk wrote:
> >
> > > Ah, right, if everybody is already using SHA256 then, yes, we can stick
> > > to that and the different serialisations are convertible. And I don't
> > > see any reason not too. From what I can tell there (somewhat
> > > surprisingly) really isn't a standard notion of certificate
> > > fingerprinting, but SHA1 and SHA256 seem to be the most commonly used by
> > > web browsers.
> >
> > At the risk of overthinking things, I was reading RFC6709 "Design
> > Considerations for Protocol Extensions" for non-Gemini reasons
> > recently and this section seems relevant:
> >
> > "4.5. Cryptographic Agility
> >
> > ... The ability to negotiate the use of a particular cryptographic
> > algorithm provides resilience against compromise of a particular
> > cryptographic algorithm.... This is usually accomplished by including
> > an algorithm identifier and parameters in the protocol, and by
> > specifying the algorithm requirements in the protocol specification."
> >
> > i.e. Instead of storing opaque bytes, also mention that it's SHA256
> >
> > A stand-alone implementation of this concept:
> > https://multiformats.io/multihash/
> >
> > Cheers, Tom
> 
> 
>