💾 Archived View for rawtext.club › ~sloum › geminilist › 005368.gmi captured on 2024-02-05 at 11:11:39. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2021-11-30)

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

<-- back to the mailing list

Digital signature in gemini pages

Christophe HENRY listes at sbgodin.fr

Sat Feb 20 13:54:35 GMT 2021

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

Le Fri, 19 Feb 2021 14:06:12 -0500,John Cowan <cowan at ccil.org> a écrit :

On Fri, Feb 19, 2021 at 11:33 AM Christophe HENRY <listes at sbgodin.fr>
wrote:
There may be several modes:
* The browser is configured to not care about signature. Everything
go as usual. Just like any non-aware browser.
* The browser is configured to indicate that this file exists, but
does nothing. It would display a special icon https-style.
The only way that can work is for the client to automatically request
the signature when a document is retrieved. This has two problems:
(a) it is an automatic network action, which clients are not supposed
to do, and (b) it will cause a lot of useless hits when signatures
are rare, which is bad considering that Gemini servers are often
limited by either CPU or network bandwidth.

You are right. That's why the others way come.

I think the Right Thing is for browsers to have a command/menu option
"Check Signature", which appends ".asc" to the pathname of the
current URI (not to the whole URI), and attempts to retrieve that. If
it succeeds and the content matches the current document, all is well.

That sounds good.

However, this assumes that the signature methodology is standardized
across all sites. So a simpler, more Gemini thing to do is to
replace "Check Signature" with "View Signature", which displays the
signature and leaves it to the user to determine the signature on the
local copy of the document.
* The user would ask the browser to check for a particular site or
for all sites.
WI don't understand this: signatures are per-document, not per-site.
And hat does "all sites" even mean? Even "all documents on the site"
does not need to be a finite number, given the ability to generate
documents at the server.

Each page would have the ".asc" file. I suppose this file would link tothe certificate. Such certificate may be found somewhere in the server,publicly accessible.

The rest follow the spirit of "Trust on first use". For instance,
storing the public key of the author in the website. Maybe a kinda
web-of-trust among some websites gathered in rings…
The server can't assume that all documents have the same author, so
servers have to be per-document, not per-site. This adds complexity
to the server, as it has to maintain additional metadata as opposed
to keeping either signature files or a rewrite rule that requests
signature files from a different, more secure site. The latter is
the Right Thing when mirroring documents from elsewhere: if your
server is hacked, the hacker will certainly alter the signature as
well, but if the signature is off site, that is more difficult.

That's right, it's always security vs. functionality. At least, eachpage may be signed before publication by the uploader.

-- Christophe HENRYFR EO EN - https://sbgodin.fr-------------- next part --------------A non-text attachment was scrubbed...Name: not availableType: application/pgp-signatureSize: 833 bytesDesc: Signature digitale OpenPGPURL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210220/ca8f3212/attachment.sig>