Removing expiry dates for TOFU

[Baschdel]

I really like the way of announcing future certificates by putting them 
in a well known location (not just their fingerprint, as this requires 
either the server or the client (probably both) to support multiple 
fingerprinting algorithms because even if we agree on one hash algorithm 
today, there are already people trying to break it and updating that 
will be a mess).

That said the name of this well known location should include the name 
tls somewhere to keep the door open for potential tls replacements (I 
think TLS is a great choice, but if something else emerges I don't want 
to bother with legacy magic paths).

There are also three other certificates besides the future one that 
could/should be served at a well known location:

- Alternative (Backup) certificates for both the current and future 
certificate, that can be used when the key behind the original 
certificate was compromised, they have to be valid for the same 
time-span as the originals and become the originals as soon as they are 
used. The private keys of these of course should be kept in cold storage 
until they are needed. Clients should at least notify the user when they 
see a backup certificate being used and treat the original certificate 
as untrusted but not delete it immanently (as it is possible that only 
the backup key was compromised and still be used by the original 
server). The user must have the ultimate choice which certificate to 
trust after a backup certificate has been used as which certificate is 
trustable should be communicated out of band in such a case.

- The currently used certificate that could be checked by clients to 
detect general purpose dragnet TLS interception, that knows nothing 
about Gemini and its conventions (basically what I'd do if I was the 
dictator of a surveillance state to monitor and censor internet access 
for thousands or millions of people). This too could also be useful if 
some TLS alternative emerges, you already trust one key the server uses, 
so why not use that to get the other keys it uses. Another possible 
usecase is that someone really concerned could use any niche proxy 
protocol to fetch the certificate the server should have (I know 
portal.mozz.us already has a feature that allows one to fetch the server 
certificate but proxy.vulpes.one doesn't and a gemini to gemini proxy 
would have to use a well known endpoint to fetch the certificate anyway 
(but that wouldn't allow you to check if the proxy got MitMd by a lazy 
TLS interception)) To make this even more of a pain for attackers each 
server could have (a) secondary endpoint(s) that is/are only 
communicated in human readable form (i.e. generating a captcha image 
that contains the filename in a nonstandard location) that changes on a 
regular basis) that too serve(s) the certificate used with the 
possibility for a security focused client to have a tool that can 
automatically check against the certificates it trusts and the one it 
received from the server. (All of this can be realized by adding two 
configuration options to a Gemini server, or if the server doesn't 
support that symlinks should work as well).

Again, I'm just throwing Ideas around hoping that they'll be considered 
useful.

Have a nice Evening

- Baschdel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200707/f3df19bb/attachment-0001.htm>