Digital signature in gemini pages

[Christophe HENRY]

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 to
the 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, each
page may be signed before publication by the uploader.

-- 
Christophe HENRY
FR EO EN - https://sbgodin.fr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: Signature digitale OpenPGP
URL: <https://mailing-list-archive.gemi.dev/www/attachments/20210220/ca8f3212/attachment.sig>