πŸ’Ύ Archived View for gemi.dev β€Ί gemini-mailing-list β€Ί 000570.gmi captured on 2024-06-16 at 13:45:29. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2023-12-28)

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

[spec] Oustanding issues

1. Solderpunk (solderpunk (a) posteo.net)

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.

In arbitrary order:


  This is actually mandated by both TLS 1.2 and 1.3 specs so technically
  it's redundant to mention it in the Gemini spec, but given how poorly
  implemented it is, some explicit reminding could not hurt.  I think
  there's a tiny wrinkle to consider here on *when* the client should
  send this (due to a change in semantics between TLS 1.2 and 1.3).

  similar question applies for queries, actually.

  a response header may be empty, and on exactly what that means (e.g.
  is a tab after the status code still required in any case?).  This
  needs to be tightened up, and I'm pretty sure this should be done by
  just making non-empty META a requirement.

  think this is out of scope for the itself, but an entirely
  appropriate thing to mention in either the Best Practices document or
  a separate companion standard for standard logging format.

  clients, rather than this just being a recommendation in the BP
  document.

  information about cacheability of content.  I'm pretty sure I don't
  want this, but I do feel a need to actually give a justification for
  it.

  resource is a stream.  I'm not sure I want this (though less sure than
  the cache thing), but at the very least the spec could use a bit of
  clarity about the potential for content to be streamed.  I know
  streams are not universally popular, but there is little practical
  difference between a stream and a large but finite file served over a
  "jerky" internet connection, and it's very hard to actually explicitly
  disallow streams, so I think they are here to stay.  At the absolute
  minimum, the BP document should mention that buffering responses up in
  memory until they are complete and then processing them is a fragile
  (but valid and, in practice, workable) approach.

  character sequences which identify the start of a non-text line type
  were originally defined with spaces after them, but we've added that
  requirement hodge-podge as ambiguities have appeared, and now we're in
  a situation where half the line types need them and half don't.
  Consistency suggests we require spaces everywhere, but this has been
  surprisingly controversial and may break some things.  But a final
  ruling is required.

Most of these are not anywhere near as major as the IRI issue.  I hope
to get all the non-IRI things sorted out in the next week or so.  In
some cases I may start new threads here asking for feedback.  In simpler
cases I might just make decrees.

Cheers,
Solderpunk

Link to individual message.

2. Martin Keegan (martin (a) no.ucant.org)

On Sun, 27 Dec 2020, Solderpunk wrote:

> I think is worthy of some kind of consideration/response.  If you think
> I've forgotten something, please let me know.

You posted on your gemlog some time ago that the experience of the use of 
TLS client certificates had raised issues that needed to be clarified in 
the spec; I don't know whether these issues were satisfactorily resolved.

=> gemini://gemini.circumlunar.space/users/solderpunk/gemlog/tls-musings.gmi


For my own part I'd like to know about timeouts. My server is coded with 
some concern about DoS attacks such as the Slow Loris attack:

=> https://en.wikipedia.org/wiki/Slowloris_(computer_security)

To mitigate this, the server shuts down any connection which hasn't 
submitted a request after ten seconds. Pragmatically, client authors do 
not need licence from the spec to implement a timeout, but it may be 
useful to constrain when and how server implementors should/must/must not 
do this.

Mk

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

Link to individual message.

3. Solderpunk (solderpunk (a) posteo.net)

On Sun Dec 27, 2020 at 1:01 PM CET, Martin Keegan wrote:

> You posted on your gemlog some time ago that the experience of the use
> of
> TLS client certificates had raised issues that needed to be clarified in
> the spec; I don't know whether these issues were satisfactorily
> resolved.
>
> =>
> gemini://gemini.circumlunar.space/users/solderpunk/gemlog/tls-musings.gmi

Thanks for the reminder!  The SNI issue was addressed and this is now
mentioned in the spec.  The status codes related to client certificates
were also simplified and "transient certificates" are no longer a
first-class concept in the spec.  I *think* those were the major issues
that a little real-world experience revealed, and that they are both now
resolved.

> For my own part I'd like to know about timeouts. My server is coded with
> some concern about DoS attacks such as the Slow Loris attack:
>
> => https://en.wikipedia.org/wiki/Slowloris_(computer_security)
>
> To mitigate this, the server shuts down any connection which hasn't
> submitted a request after ten seconds. Pragmatically, client authors do
> not need licence from the spec to implement a timeout, but it may be
> useful to constrain when and how server implementors should/must/must
> not
> do this.

Hmm.  While I agree that neither servers nor clients really need
permission to implement basic functionality like timeouts, this
particular case *does* raise some questions.  Currently it seems
implicit in the spec that servers may not say anything until the client
has finished sending a request.  In principle, there are circumstances
where a server might know what it wants to do before that point - an
invalid URL (triggering a status code 59 response) might be detected
before it is complete, and the n-th request within m seconds (triggering
a status code 44 response) can be detected before *anything* is
received.  And, as you point out, reasonable defensive timeouts can
occur before a request is complete.  Is a server obligated to wait for a
complete response before saying anything?

Thanks for bringing this up, I'll think about it.  Thoughts are welcome.

Cheers,
Solderpunk

Link to individual message.

4. Petite Abeille (petite.abeille (a) gmail.com)



> On Dec 27, 2020, at 13:25, Solderpunk <solderpunk at posteo.net> wrote:
> 
> Is a server obligated to wait for a complete response before saying anything?

No. It's unreasonable to mandate any QoS (Quality of service) anywhere. 
Both clients and servers are free to take any defensive measures they see 
fit. Or none. It's their call.

Link to individual message.

5. BjΓΆrn WΓ€rmedal (bjorn.warmedal (a) gmail.com)


> 27 dec. 2020 kl. 15:18 skrev Petite Abeille <petite.abeille at gmail.com>:
> 
> ?
> 
>> On Dec 27, 2020, at 13:25, Solderpunk <solderpunk at posteo.net> wrote:
>> 
>> Is a server obligated to wait for a complete response before saying anything?
> 
> No. It's unreasonable to mandate any QoS (Quality of service) anywhere. 
Both clients and servers are free to take any defensive measures they see 
fit. Or none. It's their call.
> 
I completely agree with this. It?s in the server?s interest to strike a 
balance between defensive measures and good service as best they can given 
their situation.

Cheers,
ew0k

Link to individual message.

6. Solderpunk (solderpunk (a) posteo.net)

On Sun Dec 27, 2020 at 3:35 PM CET, Bj?rn W?rmedal wrote:
>
> > 27 dec. 2020 kl. 15:18 skrev Petite Abeille <petite.abeille at gmail.com>:
> > 
> > No. It's unreasonable to mandate any QoS (Quality of service) 
anywhere. Both clients and servers are free to take any defensive measures 
they see fit. Or none. It's their call.
> > 
> I completely agree with this. It?s in the server?s interest to
> strike a balance between defensive measures and good service as best
> they can given their situation.

Thanks, both of you.  This is consistent with some changes I've already
started drafting.  I'll send another email around with some proposed
changes relatively soon.

Cheers,
Solderpunk

Link to individual message.

7. colecmac (a) protonmail.com (colecmac (a) protonmail.com)

> I'm trying to prepare a list of spec issues that I want to finalise as
> soon as possible.

Thanks! This is helpful. Fingers crossed it doesn't become a monster
megathread...


Also, I believe you've missed my small spec changes I proposed a while ago,
which have to do with the lang param. See these emails.

gemini://gemi.dev/gemini-mailing-list/messages/003827.gmi
gemini://gemi.dev/gemini-mailing-list/messages/003911.gmi


Cheers,
makeworld

Link to individual message.

8. Solderpunk (solderpunk (a) posteo.net)

On Sun Dec 27, 2020 at 5:38 PM CET,  wrote:

> Also, I believe you've missed my small spec changes I proposed a while
> ago,
> which have to do with the lang param. See these emails.
>
> gemini://gemi.dev/gemini-mailing-list/messages/003827.gmi
> gemini://gemi.dev/gemini-mailing-list/messages/003911.gmi

Ah, thanks.  These should, indeed, be dealt with.  But it's thankfully
very clear what to do and there's no discussion needed.  This will get
fixed in the next update (sometime before the end of this year!).

Cheers,
Solderpunk

Link to individual message.

9. Johann Galle (johann (a) qwertqwefsday.eu)

On 2020-12-27T10:47Z, Solderpunk wrote among other things:
 > * Clarification on the use of TLS close_notify has been requested.
 >?? This is actually mandated by both TLS 1.2 and 1.3 specs so technically
 >?? it's redundant to mention it in the Gemini spec, but given how poorly
 >?? implemented it is, some explicit reminding could not hurt.? I think
 >?? there's a tiny wrinkle to consider here on *when* the client should
 >?? send this (due to a change in semantics between TLS 1.2 and 1.3).
 > * The spec is a bit vague on under which circumstances the META part of
 >?? a response header may be empty, and on exactly what that means (e.g.
 >?? is a tab after the status code still required in any case?). This
 >?? needs to be tightened up, and I'm pretty sure this should be done by
 >?? just making non-empty META a requirement.

As you have now mentioned these two issues, there was a mail with these two and
another issue[1], namely if lone LFs (or lone CRs or other line breaking code
points for that matter) are allowed inside META.

Johann

[1] gemini://gemi.dev/gemini-mailing-list/messages/003276.gmi
---
You can verify the digital signature on this email with the public key
available through web key discovery. Try e.g. `gpg --locate-keys`...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201227/0895
ac48/attachment-0001.sig>

Link to individual message.

10. John Cowan (cowan (a) ccil.org)

On Sun, Dec 27, 2020 at 6:23 AM Solderpunk <solderpunk at posteo.net> wrote:


> * The spec is a bit vague on under which circumstances the META part of
>   a response header may be empty, and on exactly what that means (e.g.
>   is a tab after the status code still required in any case?).  This
>   needs to be tightened up, and I'm pretty sure this should be done by
>   just making non-empty META a requirement.
>

If empty META strings are going to be invalid (I think they should be),
then the last graf of 3.3 should be deleted.



>   think this is out of scope for the itself, but an entirely
>   appropriate thing to mention in either the Best Practices document or
>   a separate companion standard for standard logging format.
>

I'll address that in a separate thread.  I'm also going to talk about i18n
issues (other than IRIs) in a separate thread.


John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
A rose by any other name may smell as sweet, but if you called it
an onion you'd get cooks very confused.          --RMS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201227/f93c
8296/attachment.htm>

Link to individual message.

11. Solderpunk (solderpunk (a) posteo.net)

On Sun Dec 27, 2020 at 8:35 PM CET, John Cowan wrote:
> On Sun, Dec 27, 2020 at 6:23 AM Solderpunk <solderpunk at posteo.net>
> wrote:

> If empty META strings are going to be invalid (I think they should be),
> then the last graf of 3.3 should be deleted.

Agreed, this was one of the changes in my recent "Proposed changes"
post.

Cheers,
Solerpunk

Link to individual message.

12. Solderpunk (solderpunk (a) posteo.net)

On Sun Dec 27, 2020 at 6:54 PM CET, Johann Galle wrote:

> As you have now mentioned these two issues, there was a mail with these
> two and
> another issue[1], namely if lone LFs (or lone CRs or other line breaking
> code
> points for that matter) are allowed inside META.
>
> [1] gemini://gemi.dev/gemini-mailing-list/messages/003276.gmi

Hmm.  Currently this is perfectly legal.  I agree that it's not unlikely
there will be hastily written clients which don't handle it correctly
(although it could easily be included in Sean's torture test suite), but
I'm not sure that's a reason in and of itself to forbid it.  Can anybody
think of any any strong arguments in either direction?

Cheers,
Solderpunk

Link to individual message.

13. Sean Conner (sean (a) conman.org)

It was thus said that the Great Solderpunk once stated:
> On Sun Dec 27, 2020 at 6:54 PM CET, Johann Galle wrote:
> 
> > As you have now mentioned these two issues, there was a mail with these
> > two and another issue[1], namely if lone LFs (or lone CRs or other line
> > breaking code points for that matter) are allowed inside META.
> >
> > [1] gemini://gemi.dev/gemini-mailing-list/messages/003276.gmi
> 
> Hmm.  Currently this is perfectly legal.  I agree that it's not unlikely
> there will be hastily written clients which don't handle it correctly
> (although it could easily be included in Sean's torture test suite), but
> I'm not sure that's a reason in and of itself to forbid it.  Can anybody
> think of any any strong arguments in either direction?

  Okay, this is about:

	10 Is\nThis\nValid?\r\n

  While this is valid per the spec, I would recommend against embedded
control codes in the META response.  Arbitrary control codes can do some
pretty nasty things [1], and this can potentially mess up a client's
display.  Clients (in my opinion) should strip out such sequences, if only
because this is trying to influence how the client display text.

  -spc

[1]	Redefine the keyboard, issue commands to the operating system,
	application or device for instance.  I don't know of any current
	terminal software that support the commands, but I do know of at
	least one operating system where you can redefined the keyboard via
	control codes, and it's a very popular operating system.  Like,
	*the* most popular operating system.

Link to individual message.

14. Petite Abeille (petite.abeille (a) gmail.com)



> On Dec 28, 2020, at 00:21, Sean Conner <sean at conman.org> wrote:
> 
> Clients (in my opinion) should strip out such sequences, if only
> because this is trying to influence how the client display text.

Agree. Actually, client MUST sanitize all input, irrespectively of origin. 
Not doing so would be highly irresponsible.

This would be easier if META would not legally contain any control 
characters to start with.

Link to individual message.

15. Kiba Fox (kiba.fox (a) foxypossibilities.com)

Hello,

I have a suggestion to add to the list and a question on parsing quote 
lines.

> I'm trying to prepare a list of spec issues that I want to finalise as
> soon as possible.  If you think I've forgotten something, please let me know.

The current spec suggests supporting TOFU.  I think you may want to 
consider also supporting using the default/system certificate authority 
trust system as a fallback.  This allows certificates signed by Let's 
Encrypt or others to be used without the client having to store the 
known certificate. It also allows server operators to renew certificates 
without breaking clients.

This might be the behavior of clients today (trust system trusted CAs or 
use TOFU), but it's nice to have clearly defined behavior.

> * There's this long-standing issue of the fact that none of the
>    character sequences which identify the start of a non-text line type
>    were originally defined with spaces after them, but we've added that
>    requirement hodge-podge as ambiguities have appeared, and now we're in
>    a situation where half the line types need them and half don't.
>    Consistency suggests we require spaces everywhere, but this has been
>    surprisingly controversial and may break some things.  But a final
>    ruling is required.

I've been wondering about this...  Specifically, in these example scenarios:

Sans whitespace: >This is a quote
With whitespace: > This is a quote

Should these two be parsed the same or should one include leading 
whitespace?

-----

Also, are you open to suggestions/additions to the text/gemini format?

-- 
Kind regards,
Kiba

Link to individual message.

16. Arav K. (nothien (a) uber.space)

On Mon, Dec 28, 2020 at 12:27:15AM +0100, Petite Abeille wrote:
> This would be easier if META would not legally contain any control
> characters to start with.

Won't be easier - malicious servers would just do it anyways.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201228/40b1
2613/attachment.sig>

Link to individual message.

17. Johann Galle (johann (a) qwertqwefsday.eu)

On 2020-12-28T11:27Z, Petite Abeille wrote:
 > This would be easier if META would not legally contain any control
 > characters to start with.

On 2020-12-28T21:27Z, Arav K. replied:
 > Won't be easier - malicious servers would just do it anyways.

If it is forbidden, we could just filter out control code points without worring
about destroying valid use cases. Although I wonder what those would be.

Johann
---
You can verify the digital signature on this email with the public key
available through web key discovery. Try e.g. `gpg --locate-keys`...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201229/fcce
822a/attachment-0001.sig>

Link to individual message.

18. Petite Abeille (petite.abeille (a) gmail.com)



> On Dec 29, 2020, at 02:01, Johann Galle <johann at qwertqwefsday.eu> wrote:
> 
> If it is forbidden, we could just filter out control code points without worring
> about destroying valid use cases.

Genau.

> Although I wonder what those would be.

Smuggling ASCII art in response status? :D

Link to individual message.

19. Gary Johnson (lambdatronic (a) disroot.org)

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

Link to individual message.

20. Petite Abeille (petite.abeille (a) gmail.com)



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

? ???

Link to individual message.

21. Stephane Bortzmeyer (stephane (a) sources.org)

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:


Link to individual message.

22. Stephane Bortzmeyer (stephane (a) sources.org)

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

Link to individual message.

23. nervuri (nervuri (a) disroot.org)

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.

Link to individual message.

24. Martin Keegan (martin (a) no.ucant.org)

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/

Link to individual message.

25. Petite Abeille (petite.abeille (a) gmail.com)



> 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

? ???

Link to individual message.

26. Petite Abeille (petite.abeille (a) gmail.com)



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

? ???

Link to individual message.

27. Stephane Bortzmeyer (stephane (a) sources.org)

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

Link to individual message.

28. easrng (easrng (a) gmail.com)

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

Link to individual message.

29. Petite Abeille (petite.abeille (a) gmail.com)



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

Link to individual message.

30. Petite Abeille (petite.abeille (a) gmail.com)



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

? ???

Link to individual message.

31. Stephane Bortzmeyer (stephane (a) sources.org)

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.

Link to individual message.

---

Previous Thread: [ANN] announcing the outpost, a kinda sorta reddit-esque forum

Next Thread: [Users] new release of mastodon allow gemini URL