💾 Archived View for soviet.circumlunar.space › oak › mailinglist › 5.gmi captured on 2024-06-16 at 12:58:58. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2021-12-03)

-=-=-=-=-=-=-

[spec] Oustanding issues

From: Gary Johnson

Date: Tue, 05 Jan 2021 15:17:00 -0500

Solderpunk <solderpunk at posteo.net> writes:

Greetings all,
I'm trying to prepare a list of spec issues that I want to finalise as
soon as possible. I probably should have been more disciplined about
this, but the high traffic rate of the mailing list combined with the
fact that an awful lot of the discussion is about stuff that I'm not
interested in means I've kind of lost track of the important things.
Below is everything I'm aware of which has been previously raised which
I think is worthy of some kind of consideration/response. If you think
I've forgotten something, please let me know.

A few other issues that have come up and could use spec-level

clarification:

1. What are the valid/invalid/recommended values for CN, SAN, and

expiration dates in certificates in the context of TOFU?

It has been suggested on the mailing list that none of these values

should have meaning under a TOFU security model. Others argue that

they should have specific values and meanings. Clarity would be

appreciated.

2. Client use of URL fragments (jump to heading, full text search, etc.)

Arguments for a variety of options (including none) have already been

presented in another mailing list thread.

3. Extending bulleted lists to three level to match headings (*, **, ***)

Gemtext only defines a single-level unordered list line type (*). It

was shown on the mailing list some time ago that different clients

may have quite different ways of rendering attempts by authors to

create nested list outlines. Here are two examples, both of which

have variable renderings depending on the client used:

* TODOs

** Work

*** Check email

*** Be productive

** Home

*** Eat food

*** Clean body

*** Get off your couch occasionally

* TODOs

* Work

* Check email

* Be productive

* Home

* Eat food

* Clean body

* Get off your couch occasionally

It seems (at least to my eyes), that the (*, **, ***) examples are

more in line with Gemini's 3-character line type indicator rule and

match the same style as the three heading levels (#, ##, ###). Adding

these to the Gemtext spec should be a strictly accretive (and

therefore non-breaking) change that would standardize their display

in different Gemini browsers.

4. Providing a concrete example of how to use text after opening ``` to

specify client behavior (e.g., source code highlighting).

The Gemini spec mentions that the alt text can be used for this

purpose but doesn't provide any clear mechanism for how this should

be done. This leaves the choice entirely up to different clients,

which seems like a recipe for competing browser wars and "Best Viewed

In" notes on Gemtext pages. This is probably less than ideal.

Okay, that's all I can think of at the moment. Good luck mulling all

these issues over.

Happy hacking,

Gary

--

GPG Key ID: 7BC158ED

Use `gpg --search-keys lambdatronic' to find me

Protect yourself from surveillance: https://emailselfdefense.fsf.org

=======================================================================

() ascii ribbon campaign - against html e-mail

/\ www.asciiribbon.org - against proprietary attachments

Why is HTML email a security nightmare? See https://useplaintext.email/

Please avoid sending me MS-Office attachments.

See http://www.gnu.org/philosophy/no-word-attachments.html

--------

From: Petite Abeille

Date: Wed, 6 Jan 2021 00:40:25 +0100

On Jan 5, 2021, at 21:17, Gary Johnson <lambdatronic at disroot.org> wrote:
1. What are the valid/invalid/recommended values for CN, SAN, and
expiration dates in certificates in the context of TOFU?

TOFU, as practiced by ssh & co., is about key exchange. One accepts a key, from a given host. There is no notion of "certificates", much less X.509 certificates, just a host+key pair.

Certificates should be entirely ignored as far as TOFU goes. And only viewed as a way to transfer the key. An envelope for the key, due to TLS.

Trying to merge the semantic of the X.509 certificates PKI and TOFU is not TOFU anymore. SEITAN perhaps. An entirely different construct for sure.

? ???

--------

From: Stephane Bortzmeyer

Date: Wed, 6 Jan 2021 09:25:59 +0100

On Tue, Jan 05, 2021 at 03:17:00PM -0500,

Gary Johnson <lambdatronic at disroot.org> wrote

a message of 89 lines which said:

1. What are the valid/invalid/recommended values for CN, SAN, and
expiration dates in certificates in the context of TOFU?

Also, regarding TOFU (probably the worst part of the current

specification), there are many other clarifications requested:

key? The spec says the whole certificate but I don't see the point if

the rest of the certificate is not used.

should a client disable TOFU when the certificate is valid?

passed" because you don't renew a certificate when it is expired, but

a few days/weeks before.

2. Client use of URL fragments (jump to heading, full text search, etc.)

There are actually two separate issues with fragments:

--------

From: Stephane Bortzmeyer

Date: Sun, 10 Jan 2021 08:33:56 +0100

On Tue, Jan 05, 2021 at 03:17:00PM -0500,

Gary Johnson <lambdatronic at disroot.org> wrote

a message of 89 lines which said:

A few other issues that have come up and could use spec-level
clarification:

A personal list of what I think are the issues with Gemini

specification:

gemini://gemini.bortzmeyer.org/gemini/missing.gmi

--------

From: nervuri

Date: Sun, 10 Jan 2021 12:54:34 +0000

Two privacy-related suggestions:

Only send client certificates over TLS 1.3

TLS 1.3 encrypts client certs, TLS 1.2 doesn't. On 1.2 your ISP might see the user you log in as, your e-mail address and whatever other information you (are required to) put in the cert. Please consider only allowing client certificates over TLS 1.3 (and newer).

No OCSP requests

The spec says:

Clients can validate TLS connections however they like

As long as CA-based validation is allowed in Gemini, consider adding an exception along the lines of "Thou shalt not make OCSP requests", as they are notoriously bad for privacy, add latency and are easy to block by attackers.

--------

From: Martin Keegan

Date: Sun, 10 Jan 2021 17:42:34 +0000 (GMT)

On Sun, 10 Jan 2021, Stephane Bortzmeyer wrote:

A personal list of what I think are the issues with Gemini
specification:
gemini://gemini.bortzmeyer.org/gemini/missing.gmi

I am loath to raise these kinds of things, as it just creates more work,

but if you're taking requests:

Clarify whether gemini://host.domain/path and

gemini://host.domain:1965/path are to be considered equivalent, and if

so, what that means. (This may

be more important for the robots.txt side-spec).

Mk

--

Martin Keegan, @mk270, https://mk.ucant.org/

--------

From: Petite Abeille

Date: Sun, 10 Jan 2021 20:26:49 +0100

On Jan 10, 2021, at 18:42, Martin Keegan <martin at no.ucant.org> wrote:
Clarify whether gemini://host.domain/path and gemini://host.domain:1965/path are to be considered equivalent, and if so, what that means. (This may be more important for the robots.txt side-spec).

This is outside of Gemini's specification remit, but yes, they are equivalent.

See URI normalization:

https://en.wikipedia.org/wiki/URI_normalization

? ???

--------

From: Petite Abeille

Date: Sun, 10 Jan 2021 23:50:14 +0100

On Jan 6, 2021, at 09:25, Stephane Bortzmeyer <stephane at sources.org> wrote:
* interactions between TOFU and valid certificates. For instance,
should a client disable TOFU when the certificate is valid?

The current assumptions are wholly incoherent.

The interaction between TOFU and X.509, if any, must be thought through clearly.

This is not even half-baked. It's not baked at all.

? ???

--------

From: Stephane Bortzmeyer

Date: Mon, 11 Jan 2021 08:33:32 +0100

On Sun, Jan 10, 2021 at 05:42:34PM +0000,

Martin Keegan <martin at no.ucant.org> wrote

a message of 20 lines which said:

Clarify whether gemini://host.domain/path and
gemini://host.domain:1965/path are to be considered equivalent, and
if so, what that means. (This may be more important for the
robots.txt side-spec).

Yes, they are equivalent. RFC 3986

<gemini://gemini.bortzmeyer.org/rfc-mirror/rfc3986.txt>, section

3.2.3:

A scheme may define a default port. For example, the "http" scheme

defines a default port of "80", corresponding to its reserved TCP

port number. [...] URI producers and normalizers should omit the

port component and its ":" delimiter if port is empty or if its

value would be the same as that of the scheme's default.

For instance, the Lupa crawler

<gemini://gemini.bortzmeyer.org/software/lupa/> canonicalizes

<gemini://host.example:1965/path> to <gemini://host.example/path>.

% lupa-insert-url gemini://host.example:1965/path

URL gemini://host.example:1965/path added to the database (ID 152155, capsule ID 571)

% my-lupa-insert-url gemini://host.example/path

URL gemini://host.example/path already in the database

--------

From: easrng

Date: Mon, 11 Jan 2021 14:47:40 -0500

The interaction between TOFU and X.509, if any, must be thought through clearly.

I'm not writing a client right now, but if I was, I think I would

handle certs a few different ways. First, if it was tunneled over a

protocol that is already encrypted (ex. Tor), I'd accept any

certificate, because TLS would be redundant, even though the spec

requires it. If the certificate was valid and trusted by the CAs

installed, I would also accept it, even if that means overwriting an

earlier TOFU entry. Otherwise, I would handle them like SSH handles

keys, by asking the user on the first connection if the certificate is

trusted. Hopefully blockchain-based naming systems will make cert

validation easy some day, as you could just check if the cert matches

the signature in the blockchain of the person who owns the domain.

--------

From: Petite Abeille

Date: Mon, 11 Jan 2021 21:10:45 +0100

On Jan 11, 2021, at 20:47, easrng <easrng at gmail.com> wrote:
I'm not writing a client right now, but if I was, I think I would
handle certs a few different ways. First, if it was tunneled over a
protocol that is already encrypted (ex. Tor), I'd accept any
certificate, because TLS would be redundant, even though the spec
requires it.

Good point. I actually do that over wireguard -using old school ident at time- LAN type ala tailscale ?. No point for TLS in such setup.

It was suggested to move TLS outside of the core protocol (i.e. gemini+plain), and precisely define TLS as a Gemini "profile", i.e. gemini+tls.

No traction :P

If the certificate was valid and trusted by the CAs
installed, I would also accept it, even if that means overwriting an
earlier TOFU entry. Otherwise, I would handle them like SSH handles
keys, by asking the user on the first connection if the certificate is
trusted. Hopefully blockchain-based naming systems will make cert
validation easy some day, as you could just check if the cert matches
the signature in the blockchain of the person who owns the domain.

This is all sounds rather reasonable.

The part I don't really like personally is the mixed metaphor of ( TOFU + X.509 ) = ?

? ???

? https://tailscale.com/blog/remembering-the-lan/

--------

From: Petite Abeille

Date: Mon, 11 Jan 2021 21:33:55 +0100

On Jan 11, 2021, at 21:10, Petite Abeille <petite.abeille at gmail.com> wrote:
It was suggested to move TLS outside of the core protocol (i.e. gemini+plain), and precisely define TLS as a Gemini "profile", i.e. gemini+tls.

Using multiaddr notation ?:

/dns4/service.local/tcp/1965/tls/gemini/endpoint/ -- gemini+tls

vs.

/dns4/service.local/tcp/1966/gemini/endpoint/ -- gemini+plain

? https://multiformats.io/multiaddr/

? ???

--------

From: Stephane Bortzmeyer

Date: Tue, 12 Jan 2021 14:09:56 +0100

On Mon, Jan 11, 2021 at 02:47:40PM -0500,

easrng <easrng at gmail.com> wrote

a message of 12 lines which said:

I think I would handle certs a few different ways. [...] If the
certificate was valid and trusted by the CAs installed, I would also
accept it, even if that means overwriting an earlier TOFU
entry. Otherwise, I would handle them like SSH handles keys, by
asking the user on the first connection if the certificate is
trusted.

It seems a reasonable choice. (Except that "asking the user [...] if

the certificate is trusted" is just playing with words: unlike SSH,

the user has zero knowledge of the remote server and cannot assess the

certificate.) I like the way it deals with the coexistence X.509/TOFU.

First, if it was tunneled over a protocol that is already encrypted
(ex. Tor), I'd accept any certificate, because TLS would be
redundant,

Depending on how the client and the server are ran, they may not know

if they use Tor or not. Think socks and stuff like that.

--------