πŸ’Ύ Archived View for gemi.dev β€Ί gemini-mailing-list β€Ί 000795.gmi captured on 2023-12-28 at 15:52:46. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2023-11-04)

🚧 View Differences

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

[spec] Client certificate scopes

1. Adnan Maolood (me (a) adnano.co)

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.

Link to individual message.

2. Omar Polo (op (a) omarpolo.com)


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?

Link to individual message.

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


> 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

Link to individual message.

4. Adnan Maolood (me (a) adnano.co)

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.

Link to individual message.

5. Omar Polo (op (a) omarpolo.com)


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.

Link to individual message.

---

Previous Thread: : [ANN]+Gemreader,+a+hosted+feed+reader+for+Gemini+users

Next Thread: [users] New capsule - gemini://capsule.adrianhesketh.com