On Wed, May 27, 2020 at 07:37:02PM +0100, Martin Keegan wrote: > I'd recommend having a look at how Scuttlebutt does its analogous step: > "invite codes". See, e..g., > > https://github.com/ssbc/ssb-server/wiki/pub-servers > https://ssbc.github.io/scuttlebutt-protocol-guide/ (invite codes section) > https://handbook.scuttlebutt.nz/guides/pubs/create-an-invite > > ... which suggests that a layer on top of CSRs may also be useful. Anyway, > best way to find out is to try it. Thanks, I will have a read! > Well, in the two party scenario, sending a CSR and sending a fingerprint > seem to be pretty similar: the user's software submits the mystic runes to > openssl and the result is pasted to the other party. In the CSR route, > however, you do indeed need to save the other party's response (the cert). Sure, but in the fingerprint case the relevant runes just get sent as a side-effect of an ordinary TLS transaction. > I would say that the CSR mechanism goes with the grain of how SSL is > conventionally used, and thus is likely to have better existinglibrary/docs > support. Ah, now *this* is definitely true. At the start of this whole thing I brushed off a lot of people's concerns about the complexity of TLS by waving my hands and saying "there are library bindings to do this in every language". I did not realise that so many of those libraries would be so totally unable to handle anything even the slightest bit unconventional. It bothers me a bit now that fully implementing so many of the ideas that I thought would make TLS a little bit less of an imposition, or a little bit less offensive to radical decentralists, looks like it will be quite a pain in some cases. I never would have imagined it would be literally impossible for a server using Python's standard `ssl` module to accept a self-signed client certificate! Cheers, Solderpunk
---
Previous in thread (14 of 25): 🗣️ Martin Keegan (martin (a) no.ucant.org)
Next in thread (16 of 25): 🗣️ Petite Abeille (petite.abeille (a) gmail.com)