< ^ txt
Thu Dec 24 06:00:01 EST 2020
========================================
Slept from eleven-thirty to eight-thirty.
Woke briefly around three.
Much colder.
Cloudy with scattered snow showers.
Lows around 18.
Northwest winds 10 to 15 mph.
Chance of snow 40 percent.
Christmas Eve!
Binge watched Ted Lasso on AppleTV.
Warm-hearted and actually funny.
Lots of good performances, specially from Jason Sudeikis (Ted), Brett Goldstein (Roy), and Juno Temple (Keeley).
TODO:
- Understand use cases for Gemini client certs
Done, mostly.
https://lists.orbitalfox.eu/archives/gemini/2020/000987.html
> The current rough spec fairly clearly outlines two usage scenarios for
> client certificates.
>
> One is where you want to restrict access to some Gemini resource to a
> limited set of clients, e.g. you want to be able to check a webcam at
> your home via Gemini from your office while at work, or via your phone,
> but you don't want to open up access to the whole world. So, you
> generate a self-signed certificate on your office computer or your
> phone, and manually add its fingerprint to a whitelist on your home
> server, and nobody else is allowed in.
>
> This is pretty explicitly supported in Gemini via status code 62 to
> request such a certificate and 63 to reject one not on the whitelist.
>
> The second scenario involves transient client certificates. These are
> basically an alternative to cookie-powered sessions in HTTP(S). A
> client generates a self-signed certificate and uses it for some
> requests so that the server can recognise consecutive requests as coming
> from the same location, and use the certificate fingerprint as a key in
> a database to maintain state between requests.
>
> Gemini allows for transient sessions using the 61 and 21 status codes.
> 61 requests the start of a session, which clients can always refuse to
> do. 21 allows servers to signal the termination of a session and
> clients should immediately and permanently delete the corresponding
> keypair upon receiving it.
>
> We should specify a fixed validity time for the certificate, again
> because if we don't different clients will do different things and
> certs will become weakly fingerprintable. AV-98 uses 24 hours, which
> seems reasonable to me.
>
> There is a third scenario, which the spec does not explicitly discuss at
> all, but which is actually the most widely used scenario in Geminispace
> so far, which is the main reason that I want to kick off a discussion
> about this and change the spec if required. It's the idea of persistent
> identity (basically, a "user account") at a server which is not under
> the client's control. The persistent part differentiates this scenario
> from the clearly defined transient certificates, and the lack of
> combined control differentiates it from the previously discussed
> ssh-style whitelist scenario. This is exactly the scenario which holds
> with the astrobotany.mozz.us application.
>
> There is also the open question of how to handle renewal of this kind of
> certificate, which people might have need of for years and years.
Servings: grains 8/6, fruit 1/4, vegetables 2/4, dairy 3/2, meat 3/3, nuts 0/0.5
Brunch: cookies, banana, two hot dogs with cucumber
Lunch: corn chips
Dinner: sausage and cucumber wrap
< ^ txt