TLS recommendations for Gemini
2021-03-06 on adnano.coThis document outlines practical recommendations regarding TLS certificates for Gemini clients and servers.
1. Client certificates
Client certificates should:
- Either leave the common name blank or populate it with a user-provided name.
- Use ECDSA until Ed25519 is widely supported.
- Use an expiration time far into the future (e.g. 100 years from now) for long-lived certificates.
Clients should prompt the user to create a certificate upon receiving a 60 Certificate Required response. The created certificate should be limited to the hostname for which it was requested.
Clients should allow the user to create long-lived and short-lived certificates. Long-lived certificates should use an expiration time far into the future (e.g. 100 years from now). Short-lived certificates should expire after a certain amount of time which the user can configure. Once a short-lived certificate expires it should no longer be used for requests.
Clients should also give the user full control over the certificate store. The user should be able to create multiple certificates per host, add new certificates, delete certificates, and activate and deactiviate certificates. Clients may also allow the user to change the scope of a certificate or duplicate a certificate for use with another host.
2. Server certificates
Server certificates should:
- Specify one or more DNS names and a common name.
- Use ECDSA until Ed25519 is widely supported.
- Use an expiration time far into the future (e.g. 100 years from now).
Servers should generate certificates as needed and replace expired certificates automatically.
3. Authentication
Servers should authenticate clients with a hash or fingerprint of their client certificate. Servers should not use usernames and passwords for authentication.
Servers should automatically expire any data associated with the client's certificate after it expires. This allows any data associated with short-lived client certificates to automatically expire. Long-lived client certificates should avoid having their data deleted by using an expiration time far into the future.
Servers should allow clients to manually delete any data associated with their client certificate. This can be accomplished by providing a link which will delete their data when visited. After the data is deleted, servers should redirect to a page instructing the user to delete their client certificate if they no longer want to associate data with it.