💾 Archived View for gemi.dev › gemini-mailing-list › 000191.gmi captured on 2023-11-04 at 12:31:47. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
[This post is also a glog entry at gemini://gemini.thegonz.net/glog/200607-clientCertificatePostMortem.gmi] 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. ## User interface
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 be normative. It's supposed to give us the ability to experiment with different client certificate work flows so we can see what works and does 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 the current status code 61 (and 21). They totally violate the idea that all status codes should degrade gracefully in super simple clients which ignore the second digit. If 61 is interpreted as 60, there is no guarantee that the resulting certificate will be transient as intended, and if 21 is interpreted as 20 the active certificate may not be deleted as soon as the server is done with it. I am increasingly thinking that having a single code for on-demand certificates and encouraging clients to implement the transient/persistent distinction themselves, like you are doing with any other 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 be restricted to a given URL path and subpaths? Is it just up to the user to take an educated guess at the required scope for a cert and manually specify the path? I have been thinking that perhaps the <META> line for status coedes 6x could be used for the server to specify precisely this information. > ### 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 practices about certificate key types and sizes (based on discussions with 80h about performance on their ESP8266 implementation). And about ciphersuites generally, with a view toward minimising TLS overhead and improving 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
On Sun, Jun 7, 2020 at 7:14 PM <mbays at sdf.org> wrote: > > This doesn't work entirely smoothly with astrobotony -- you might start > using our certificate at gemini://astrobotany.mozz.us/plant/, so it then > also takes effect for gemini://astrobotany.mozz.us/plant/water and so > on, but if you try e.g. gemini://astrobotany.mozz.us/settings you have > to select the identity again. You can manually "identify > gemini://astrobotany.mozz.us", but that isn't so smooth. Probably marks > should optionally have an identity associated -- that would help quite > a bit, but needs some forethought from the user. For what it's worth, I have been thinking about reorganizing the URL structure for astrobotany so that all of the authenticated endpoints live behind a single path. I am also planning on adding more unauthenticated content to the server, so I want to establish a clear separation between the sections that require a client certificate and the sections that do not. - gemini://astrobotany.mozz.us/ - gemini://astrobotany.mozz.us/about - gemini://astrobotany.mozz.us/app (requires client certificate) - gemini://astrobotany.mozz.us/app/plant - gemini://astrobotany.mozz.us/app/directory - ... There are several other advantages to having a well designed path hierarchy. It's something that I often don't spend enough time thinking about up front and then I regret not doing it right later. - Michael (mozz)
On Sun, Jun 07, 2020 at 10:00:02PM -0400, Michael Lazar wrote: > For what it's worth, I have been thinking about reorganizing the URL > structure for astrobotany so that all of the authenticated endpoints > live behind a single path. I am also planning on adding more > unauthenticated content to the server, so I want to establish a > clear separation between the sections that require a client certificate > and the sections that do not. > > - gemini://astrobotany.mozz.us/ > - gemini://astrobotany.mozz.us/about > - gemini://astrobotany.mozz.us/app (requires client certificate) > - gemini://astrobotany.mozz.us/app/plant > - gemini://astrobotany.mozz.us/app/directory > - ... > > There are several other advantages to having a well designed path > hierarchy. It's something that I often don't spend enough time > thinking about up front and then I regret not doing it right later. This seems wise to me. It's already pretty clear that associating client certificates with domains, as currently specced (for transient certs, at least) and as implemented in AV-98, is not the best idea. It will inevitably cause confusion/frustration/difficulty in environments where multiple users share a domain (like pubnixes). Associating them with paths seems the obvious solution. As the current leading implementer of client cert consumning apps, I'm curious how you feel about the idea of using the <META> for 6x statuses to convey an intended "path scope" for certs? Cheers, Solderpunk
On Mon, Jun 8, 2020 at 1:25 PM solderpunk <solderpunk at sdf.org> wrote: > > On Sun, Jun 07, 2020 at 10:00:02PM -0400, Michael Lazar wrote: > > > There are several other advantages to having a well designed path > > hierarchy. It's something that I often don't spend enough time > > thinking about up front and then I regret not doing it right later. > > This seems wise to me. It's already pretty clear that associating > client certificates with domains, as currently specced (for transient > certs, at least) and as implemented in AV-98, is not the best idea. It > will inevitably cause confusion/frustration/difficulty in environments > where multiple users share a domain (like pubnixes). Associating them > with paths seems the obvious solution. > > As the current leading implementer of client cert consumning apps, I'm > curious how you feel about the idea of using the <META> for 6x statuses > to convey an intended "path scope" for certs? > > Cheers, > Solderpunk I think hijacking the <META> is unnecessary for my application. I can accomplish the same thing by sending a "30 TEMPORARY REDIRECT" to all unauthenticated requests, and then hitting them with a 61 after they have been redirected to the path scope. I concede that this wouldn't be *exactly* the same because the client won't end up at the page that they originally requested. But it's workable enough for me. And I like having the meta available for human readable error messages. Any complexity that we can remove from the spec surrounding client certificates is a strong positive. I'm in favor of deprecating the 61 and 21 status codes. Drop "64 FUTURE CERTIFICATE REJECTED" and "65 EXPIRED CERTIFICATE REJECTED" while you're at it, they can be subsumed by "63 CERTIFICATE NOT ACCEPTED". Heck, drop client certificates from the gemini specification all together. Judging by the lack of client support so far, it's becoming clear that either: 1. They're a pain to implement compared to the rest of the specification 2. There's not much interest in actually using them I get the vision behind the transient client sessions and fingerprinting stuff, and it really is a nice idea. But it's also very prescriptive and unproven. It sticks out when compared to the rest of the spec, which mostly borrows from tried-and-true patterns already seen in gopher/WWW. Best, Michael
It was thus said that the Great Michael Lazar once stated: > > Heck, drop client certificates from the gemini specification all together. > Judging by the lack of client support so far, it's becoming clear that either: > > 1. They're a pain to implement compared to the rest of the specification > 2. There's not much interest in actually using them I personally would like to keep them, if only to protect sections of a Gemini site from general consumption. The "transient client certificate" idea is certainly problematic and I wouldn't mind if that concept went away though. -spc
On Tue, Jun 09, 2020 at 12:40:07AM -0400, Sean Conner wrote: > It was thus said that the Great Michael Lazar once stated: > > > > Heck, drop client certificates from the gemini specification all together. > > Judging by the lack of client support so far, it's becoming clear that either: > > > > 1. They're a pain to implement compared to the rest of the specification > > 2. There's not much interest in actually using them > > I personally would like to keep them, if only to protect sections of a > Gemini site from general consumption. The "transient client certificate" > idea is certainly problematic and I wouldn't mind if that concept went away > though. I think it's probably a little too early in the game to interpet the lack of client support as a lack of interest in using them. Many people might be holding off on implementing them in the expectation that the spec will change/simplify - which it surely will: I'm pretty much sold on deprecating the transient client certificate status codes. There's also an obvious chicken-and-egg problem here, where client authors have no incentive to add support until servers require it to access compelling content. I too would like to keep *some* client cert support, though. I really like the idea of being able to self-host little productivity apps for myself which I can simply and reliably secure in an ssh-like fashion (add my self-signed cert fingerprint to the equivalent of an authorized_keys file). And, yes, okay, that doesn't strictly require 6x status codes, the server could just immeditely cut the connection if it didn't get a cert it liked. But it would be nice to be able to gracefully use those apps from within an everyday client. Mk's concern that "it'd be good not to hardwire SSL too strongly into Gemini, in case the tooling around an alternative improves sufficiently in the future and we'd like to swap" is a valid one, though, and one I have (very occasionally) worried about. If nothing else this is a good argument to keep our use of client certificates simple and perhaps not to make use in apps of anything beyond the cert fingerprint (i.e. don't rely heavily on the notion of Distinguished Names for Subject and Issuer)... Cheers, Solderpunk
On Tue, Jun 09, 2020 at 12:01:28AM -0400, Michael Lazar wrote: > Any complexity that we can remove from the spec surrounding client certificates > is a strong positive. I'm in favor of deprecating the 61 and 21 status codes. I was thinking of dropping 21 and "softening" 61 to mean something like "you need a certificate to access this resource, and the server is signalling that it's okay to use something temporary/disposable" - i.e. to make it clear this is not an Astrobotany-style application where losing your key/cert pair means forever losing access to your account. Clients can handle this however they want - some clients will implement good support for transient certs which never hit the disk, and will brag about that, and users who really care will use them. In general, I was thinking of just having a bunch of 6x codes which all mean "you need a cert to get in here" but with different hints as to what is expected - something you can generate yourself on the spot and dispose of when you like, something you can generate yourself on the spot and should take care to keep hold of (astrobotany style), or something pre-approved by the admin (which might mean a CSR process, or just a fingerprint whitelisting). No prescribed behaviour for any of them, clients can give users as many or as few options for dealing with them as the authors see fit, but at least this way they can convey enough information to the user for them to make an informed choice. > Drop "64 FUTURE CERTIFICATE REJECTED" and "65 EXPIRED CERTIFICATE REJECTED" > while you're at it, they can be subsumed by "63 CERTIFICATE NOT ACCEPTED". I expect Sean to object to this... > Judging by the lack of client support so far, it's becoming clear that either: > > 1. They're a pain to implement compared to the rest of the specification This is true. I may amend the spec the explicitly call them an advanced and optional feature. People should not feel ashamed of writing a client that just opts out of the whole thing. To some extent the existence of good clients which do this will act as a defence against people putting stuff behind certificates without very good reason. > It sticks out when compared to the rest of the spec, which mostly borrows from > tried-and-true patterns already seen in gopher/WWW. I like to think of at least the pre-approved cert workflow as tried-and-true from ssh. Cheers, Solderpunk
My two cents: I don?t understand why server gets to decide if user?s certificate is transient or not. I as a user should make that decision. If they want to lose access to their Astro plant, that?s their decision. In my opinion there should just be one 6X status code, to request that user retries with a certificate. If user didn?t use one, meta field should explain why it is needed. If user used one - meta should explain why it was declined (expiry, invalid, etc) Using this logic, I would say status code 21 is similarly unnecessary. User should be able to decide if they want to stop using client certificate. AV-98 for instance allows user to do that (so does my iOS client). It seems to me that status 21 tries to implement a logout functionality from the web, where users have a jarfull of cookies and might not be able to delete the right one. In Gemini on the other hand, it can be a simple toggle switch. On Tue, Jun 9, 2020 at 20:39 solderpunk <solderpunk at sdf.org> wrote: > On Tue, Jun 09, 2020 at 12:01:28AM -0400, Michael Lazar wrote: > > > Any complexity that we can remove from the spec surrounding client > certificates > > is a strong positive. I'm in favor of deprecating the 61 and 21 status > codes. > > I was thinking of dropping 21 and "softening" 61 to mean something like > "you need a certificate to access this resource, and the server is > signalling that it's okay to use something temporary/disposable" - i.e. > to make it clear this is not an Astrobotany-style application where > losing your key/cert pair means forever losing access to your account. > Clients can handle this however they want - some clients will implement > good support for transient certs which never hit the disk, and will brag > about that, and users who really care will use them. > > In general, I was thinking of just having a bunch of 6x codes which all > mean "you need a cert to get in here" but with different hints as to > what is expected - something you can generate yourself on the spot and > dispose of when you like, something you can generate yourself on the spot > and should take care to keep hold of (astrobotany style), or something > pre-approved by the admin (which might mean a CSR process, or just a > fingerprint whitelisting). No prescribed behaviour for any of them, > clients can give users as many or as few options for dealing with them as > the authors see fit, but at least this way they can convey enough > information to the user for them to make an informed choice. > > > Drop "64 FUTURE CERTIFICATE REJECTED" and "65 EXPIRED CERTIFICATE > REJECTED" > > while you're at it, they can be subsumed by "63 CERTIFICATE NOT > ACCEPTED". > > I expect Sean to object to this... > > > Judging by the lack of client support so far, it's becoming clear that > either: > > > > 1. They're a pain to implement compared to the rest of the specification > > This is true. I may amend the spec the explicitly call them an advanced > and optional feature. People should not feel ashamed of writing a > client that just opts out of the whole thing. To some extent the > existence of good clients which do this will act as a defence against > people putting stuff behind certificates without very good reason. > > > It sticks out when compared to the rest of the spec, which mostly > borrows from > > tried-and-true patterns already seen in gopher/WWW. > > I like to think of at least the pre-approved cert workflow as > tried-and-true from ssh. > > Cheers, > Solderpunk >
On Tue, Jun 09, 2020 at 10:23:55PM +0200, Peter Vernigorov wrote: > My two cents: I don?t understand why server gets to decide if user?s > certificate is transient or not. I as a user should make that decision. Definitely agree. I didn't mean for any of this to imply the server is "in charge". The whole reason client certs are so great as a cookie alternative is that they put the power squarely in the user's hands! The problem, I think, is that users need to be able to *make* the decision on an informed basis. If all I know is "the server needs a cert", I will probably play it cautious and generate a transient one. But if it turns out what the server wanted it for was to permanently tie that cert's fingerprint to my ID, and I decide I quite like the service, that's kind of a pain. Unless the server implements a potentially fiddly re-association feature. Of course, servers could explain what the cert should be used for (and should!) in the <META> (unless we repurpose that for a path, which I still think is worth thinking about), but some users may not understand the implications. So I thought it would be nice for the server to be able to provide a "hint" to inform the decision. Of *course* the user should always be able to make up their own mind. I guess this problem goes away in a client design where all certs are generated as transient by default but users can then opt to mark a particular cert as persistent? Hmm... Cheers, Solderpunk
It was thus said that the Great solderpunk once stated: > On Tue, Jun 09, 2020 at 12:01:28AM -0400, Michael Lazar wrote: > > > Drop "64 FUTURE CERTIFICATE REJECTED" and "65 EXPIRED CERTIFICATE REJECTED" > > while you're at it, they can be subsumed by "63 CERTIFICATE NOT ACCEPTED". > > I expect Sean to object to this... Not too terribly. I only added the bunch of codes to help with debugging a rejection. I would accept the following: 60 client certificate required 61 client certificate invalid (or expired) 62 client certificate rejected Just saying "bad certificate" isn't actionable enough for the user. Why is it bad? Has it expired? Rejected? What? I NEED TO KNOW! -spc
2020-06-09 22:59 GMT+02:00 Sean Conner<sean at conman.org>: > Just saying "bad certificate" isn't actionable enough for the user. Why > is it bad? Has it expired? Rejected? What? I NEED TO KNOW! Isn't that something that could go in the "meta" part of the response, or the content itself? The specificness of 6x codes is something I find quite puzzling, especially considering how carefully select the other codes are. Especially 64. When does that even come into play? (Oh, and hi everyone; I'm new here, so excuse my perhaps silly questions :)) -- tadzik
It was thus said that the Great Tadeusz Sosnierz once stated: > > 2020-06-09 22:59 GMT+02:00 Sean Conner<sean at conman.org>: > > Just saying "bad certificate" isn't actionable enough for the user. Why > > is it bad? Has it expired? Rejected? What? I NEED TO KNOW! > > Isn't that something that could go in the "meta" part of the response, or > the content itself? It could, but what does it mean when I get back "n? ghlactar le deimhni?", "di?lta?odh deimhni? sa todhcha?", or "di?lta?odh deimhni? caite"? Not everyone speaks English and a numeric response is unambiguous. > The specificness of 6x codes is something I find quite puzzling, > especially considering how carefully select the other codes are. > > Especially 64. When does that even come into play? Time skew between the client and server on a freshly minted certificate. > (Oh, and hi everyone; I'm new here, so excuse my perhaps silly questions :)) Hello, and no, your questions aren't silly. -spc
Wouldn?t the rest of that server?s content be also in the same language and therefore not accessible to the user? On Tue, Jun 9, 2020 at 23:13 Sean Conner <sean at conman.org> wrote: > It was thus said that the Great Tadeusz Sosnierz once stated: > > > > 2020-06-09 22:59 GMT+02:00 Sean Conner<sean at conman.org>: > > > Just saying "bad certificate" isn't actionable enough for the user. Why > > > is it bad? Has it expired? Rejected? What? I NEED TO KNOW! > > > > Isn't that something that could go in the "meta" part of the response, or > > the content itself? > > It could, but what does it mean when I get back "n? ghlactar le > deimhni?", > "di?lta?odh deimhni? sa todhcha?", or "di?lta?odh deimhni? caite"? Not > everyone speaks English and a numeric response is unambiguous. > > > The specificness of 6x codes is something I find quite puzzling, > > especially considering how carefully select the other codes are. > > > > Especially 64. When does that even come into play? > > Time skew between the client and server on a freshly minted > certificate. > > > (Oh, and hi everyone; I'm new here, so excuse my perhaps silly questions > :)) > > Hello, and no, your questions aren't silly. > > -spc >
It was thus said that the Great Peter Vernigorov once stated: > Wouldn?t the rest of that server?s content be also in the same language and > therefore not accessible to the user? Why? Think of a server written with English error messages yet used to serve up content in Thai. Most of the servers are written by English speaking people, but that doesn't mean all users of said software speak English---my example just turned that on its head. And it assumes that the error messages can't be modified to a particular langauge. -spc
On Tue, Jun 09, 2020 at 12:01:28AM -0400, Michael Lazar wrote: > I think hijacking the <META> is unnecessary for my application. I can accomplish > the same thing by sending a "30 TEMPORARY REDIRECT" to all unauthenticated > requests, and then hitting them with a 61 after they have been redirected to > the path scope. I concede that this wouldn't be *exactly* the same because the > client won't end up at the page that they originally requested. But it's > workable enough for me. And I like having the meta available for human readable > error messages. Hmm...I think I like this. I mean, I'm never *super* excited when redirects are involved, but this workflow would allow us to spec that the default scope of a cert is all paths below the URI from which the 6x status was received (which lets client certs be much narrower in scope than cookies, which IMHO is a good selling point) and still allow human-readable <META> for 6x statuses to provide hints about expected certificate lifespan. Cheers, Solderpunk
---
Previous Thread: [SPEC-CHANGE] lang parameter, minor line type changes, clarifications...