💾 Archived View for rawtext.club › ~sloum › geminilist › 001524.gmi captured on 2020-11-07 at 02:17:05. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Sean Conner sean at conman.org
Wed Jun 10 22:50:38 BST 2020
- - - - - - - - - - - - - - - - - - -
It was thus said that the Great solderpunk once stated:
On Tue, Jun 09, 2020 at 11:53:19PM -0400, Michael Lazar wrote:
TLS_CLIENT_HASH
I'm using a base64-encoded representation of the hash. I like your notation of
SHA256:<HEX> better, but it's too late now and I don't want to break backwards
compatibility.
I am extremely interested in having a well-defined notion of
"certificate fingerprints" in Geminispace, not just for CGI apps but in
server configs too (Molly Brown will soon support being able to
configure lists of authorised certs for accessing certain directories).
It's a shame it's too late for you to make changes now, but for the sake
of all future implementations we should agree on something.
What? That it's too late for him to change the format he's using forTLS_CLIENT_HASH? On thinking on it, why does it matter what the format is? It's a hash value---an obstensibly binary blob. It's a computable uniqueidentifier for a resource, so does it really matter if you use the binaryformat, or some textual format? Sure, the binary format is a bit morecompact, but that's it. A CGI (SCGI, other) can still use it as a key---itmay just not be portable between servers, that's all.
-spc