πΎ Archived View for gemi.dev βΊ gemini-mailing-list βΊ 000795.gmi captured on 2023-11-04 at 13:06:58. Gemini links have been rewritten to link to archived content
β‘οΈ Next capture (2023-12-28)
-=-=-=-=-=-=-
Currently, the Gemini specification requires client certificates be limited to the URL hostname and path for which they were requested. My Gemini client automatically generates certificates for the user, and this requirement makes it much more complicated to store and load certificates. For simplicity's sake, I propose that client certificates only be limited to the hostname for which they were requested.
Adnan Maolood <me at adnano.co> writes: > Currently, the Gemini specification requires client certificates be > limited to the URL hostname and path for which they were requested. My > Gemini client automatically generates certificates for the user, and > this requirement makes it much more complicated to store and load > certificates. For simplicity's sake, I propose that client certificates > only be limited to the hostname for which they were requested. Wouldn't this cause problems with multi-user capsules? e.g. as a user, if I used a certificate for gemini://example.com/~user1/cgi/foo I may don't want that same certificate to be sent to gemini://example.com/~user2/cgi/bar. Maybe limiting them to a path AND all the descendant paths? So that /~user1/cgi/foo and /~user1/cgi/foo/bar are using the same cert by default?
> Maybe limiting them to a path AND all the descendant paths? So that > /~user1/cgi/foo and /~user1/cgi/foo/bar are using the same cert by > default? Iirc this is the current recommendation, and I agree with your argument about multiuser hosts. Cheers, ew0k
On Sun Mar 7, 2021 at 3:20 AM EST, Omar Polo wrote: > Wouldn't this cause problems with multi-user capsules? e.g. as a user, > if I used a certificate for gemini://example.com/~user1/cgi/foo I may > don't want that same certificate to be sent to > gemini://example.com/~user2/cgi/bar. Multi-user capsules would still work. The server would recognize which user you are by your certificate. Instead of limiting the certificate to certain paths, clients should allow the user to create multiple certificates per host and switch between them easily.
Adnan Maolood <me at adnano.co> writes: > On Sun Mar 7, 2021 at 3:20 AM EST, Omar Polo wrote: >> Wouldn't this cause problems with multi-user capsules? e.g. as a user, >> if I used a certificate for gemini://example.com/~user1/cgi/foo I may >> don't want that same certificate to be sent to >> gemini://example.com/~user2/cgi/bar. > > Multi-user capsules would still work. The server would recognize which > user you are by your certificate. No. The server will execute the CGI scrips happily passing any certificates you provide. In multi-user capsules, ex.com/~user1 and ex.com/~user2 are like completely different hosts in this regard. > Instead of limiting the certificate to certain paths, clients should > allow the user to create multiple certificates per host and switch > between them easily.
---
Previous Thread: : [ANN]+Gemreader,+a+hosted+feed+reader+for+Gemini+users
Next Thread: [users] New capsule - gemini://capsule.adrianhesketh.com