Client certificate musings

[solderpunk]

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