💾 Archived View for rawtext.club › ~sloum › geminilist › 001404.gmi captured on 2020-11-07 at 02:11:53. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
solderpunk solderpunk at SDF.ORG
Sun Jun 7 21:37:20 BST 2020
- - - - - - - - - - - - - - - - - - -
On Sun, Jun 07, 2020 at 08:54:39PM +0200, mbays at sdf.org wrote:
I just finished adding client certificate support to my line-based textual
gemini client diohsc. This involved making some non-trivial choices, and I
didn't copy av98 in all cases, so I hope discussing the decisions I made and
the reasoning behind them could be of use to other client developers and in
refining the spec.
Good! The way stuff is done in AV-98 current is *not* supposed to benormative. It's supposed to give us the ability to experiment withdifferent client certificate work flows so we can see what works anddoes not.
## User interface
* The technical terminology "client certificate", which describes an
implementation detail rather than the underlying concept, is mostly hidden
from the user. Instead, the client talks about "identities". An identity is
just a client certificate along with an optional name.
* In diohsc, there are two kinds of identity -- temporary anonymous
identities and long-term named identities. The latter are saved to disc, the
former are held only in memory.
* There is no way to name and save an anonymous identity. Allowing it would
complicate the UI and the conceptual distinction between the two kinds of
identity.
This all sounds pretty sensible.
### Creating identities
* When 61 is received, the user is asked if they want to create an anonymous
identity.
* On any other 6* error code, the user may select an existing named identity
or create a new named or anonymous identity, and then retry the request.
* When creating a named identity, the user is prompted to set a Common Name
(which can be empty). This is the only choice required of the user. It would
make for a neater UI to automatically set the Common Name to be the name of
the identity, and in some ways it would make sense. But the user may well
want to use the same Common Name (e.g. "anon" or "") on multiple servers
without a common identity.
For what it's worth, I am thinking pretty heavily about deprecating thecurrent status code 61 (and 21). They totally violate the idea that allstatus codes should degrade gracefully in super simple clients whichignore the second digit. If 61 is interpreted as 60, there is noguarantee that the resulting certificate will be transient as intended,and if 21 is interpreted as 20 the active certificate may not be deletedas soon as the server is done with it.
I am increasingly thinking that having a single code for on-demandcertificates and encouraging clients to implement thetransient/persistent distinction themselves, like you are doing with anyother 6* code.
### Using identities
* An identity can be set to be used on a given server at and below a given
URI path. So you can have one identity in use for
gemini://foo.bar/~quux/..., and another for gemini://foo.bar/~xuuq/...
* Whenever an URI is shown to the user, it is annotated with the identity,
if any, which would be used if it were requested; e.g.
"gemini://foo.bar/~xuuq/hello.gmi[clarkKent]". This includes relative URIs
in links. So the user knows when they're going to use what identity.
* Colouring is used to visually separate the annotation from the URI (but
'[' and ']' are reserved characters in URIs, so this isn't actually
necessary).
* Anonymous identities are denoted as "[]".
* If the user requests an URI which would use an identity which hasn't been
used in 30m, they are asked to confirm whether they want to still use it. If
they don't want to, the identity is disabled for this path.
This also all sounds really good! How does a certificate come to berestricted to a given URL path and subpaths? Is it just up to the userto take an educated guess at the required scope for a cert and manuallyspecify the path? I have been thinking that perhaps the <META> line forstatus coedes 6x could be used for the server to specify precisely thisinformation.
### Controlling identities
* There is a single new command added to deal with identities: "identify
[URI]". If URI is missing, it defaults to the current URI (if any).
* If there is an identity in use at the URI, after confirmation it is
removed.
* Otherwise the user is prompted to select an existing identity or create a
new one, as if 60 had been received.
Aah, so this is how certs get associated with a path.
## Certificates
* To minimise information leakage to the server, all certificates, for both
anonymous and named identities, are created the same way apart from the
Common Name.
* The expiration date is set to 2 years in the future. I'm not sure if this
is the best compromise.
* The "valid from" date is set to 1 year in the past. Why not set it to the
current time? It's a known problem that users "in the wild" often don't have
correctly set clocks -- they don't set the right time zone, then set the
clock to make the time "look right". Since gemini servers are meant to be
widely deployed, we shouldn't expect either client or server to have the
right time. So we should backdate certificates by at least a couple of days,
and then a year seems a nice round safe choice.
* The serial number is set to 0, no extensions are set, and the
distinguished name consists only of the Common Name.
* The key is 2048 bit RSA with public exponent e=65537, and with hash
algorithm SHA256. I would have liked to use Ed25519, which is more efficient
in size and processing, but not all servers accept it.
I have also been wondering about putting something in the best practicesabout certificate key types and sizes (based on discussions with 80habout performance on their ESP8266 implementation). And aboutciphersuites generally, with a view toward minimising TLS overhead andimproving performance on low-power machines like Raspbery Pis.
### Fingerprinting
Currently, these choices identify diohsc uniquely. Hopefully a future
version of the spec will suggest defaults to prevent such fingerprinting,
and I think these would be reasonable choices. But it could be worth
considering mandating Ed25519, even if this means only TLS1.3 servers can
use client certificates. This can be considered an "advanced" feature for a
server, so it isn't so much of a problem if some servers aren't capable of
it.
This is definitely worth giving consideration and the spec *should*eventually say stuff about this.
Cheers,Solderpunk