💾 Archived View for rawtext.club › ~sloum › geminilist › 001242.gmi captured on 2020-10-31 at 02:08:46. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2020-09-24)

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

<-- back to the mailing list

[ANN] Gemini browser for iOS

solderpunk solderpunk at SDF.ORG

Tue Jun 2 19:31:46 BST 2020

- - - - - - - - - - - - - - - - - - - 

On Tue, Jun 02, 2020 at 01:31:09AM +0200, Peter Vernigorov wrote:

Question about client certificates: not sure how other clients implement
this, but I was thinking of generating and using the same client cert for
all sites, and giving an option to create a cert for specific domain. Does
that make sense? Potential problem I see is that main certificate is
something user could be identified by across websites.

It's not super clear to me what you're suggesting.

If it's that the client generates a single self-signed client cert thefirst time it starts up and then just sends that cert to every singlehost as part of every single request: PLEASE DON'T DO THAT! This isabout as wrong an implementation of Gemini's idea of client certificatesas possible. The vast majority of URLs will not require or expect aclient cert (which is why there's a way for servers to explicitlyrequest one in the unusual circumstance it's needed), and any you sendwill just be ignored. You will be needlessly increasing the TLS overhead(which is already pretty heavy relative to typical text/gemini payloadsizes) for no gain. Worse, admins of unrelated servers would be able tocompare their logs and track you across Geminispace.

If it's that you generate a single certificate the first time it startsup but only send it out in response to a status code of 62 that's adifferent matter (I assume it goes without saying you shouldn't ever useit in response to a status code of 61 because the behaviour fortransient certs is extremely clearly specced and this would fly in theface of just about every part of it). I still think it's the wrongthing to do, but it's slightly less disasterous than the first option.

Client certificates should be handled in a very deliberate manner - theuser needs make the clear decision to opt in, on their own terms, tobeing identified to some server(s). It's an exceptional condition andshould never be automated or hidden from the user for the sake ofconvenience. Sharing a single certificate across domains isn'tsomething anybody should ever do lightly.

Cheers,Solderpunk