💾 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
⬅️ Previous capture (2021-12-03)
-=-=-=-=-=-=-
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
--------
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.
? ???
--------
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:
--------
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
--------
Date: Sun, 10 Jan 2021 12:54:34 +0000
Two privacy-related suggestions:
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).
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.
--------
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/
--------
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
? ???
--------
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.
? ???
--------
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
--------
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.
--------
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/
--------
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/
? ???
--------
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.
--------