💾 Archived View for gemi.dev › gemini-mailing-list › 000502.gmi captured on 2024-03-21 at 17:45:22. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Gemini software is currently fragmented with regards to certificate fingerprints. It would be nice if there was an agreed upon way to calculate fingerprints so that users can easily compare fingerprints across different software. Here are some potential fingerprint methods. - Sha512 hash of the certificate, encoded in hex with ':' between each octet. Pros: matches the output of openssl x509 -sha512 -fingerprint Cons: the resulting fingerprint is very long - Sha512 hash of the certificate, encoded in base64. Pros: easy to encode and decode Cons: still somewhat long - Sha256 hash of the certificate, encoded in base64. Pros: shorter than the Sha512 hash Cons: less secure than Sha512? Note that this is the hash of the entire certificate, not just the public key. I think we should choose a fingerprint method and stick with it for consistency.
> Gemini software is currently fragmented with regards to certificate fingerprints. It would be nice if there was an agreed upon way to calculate fingerprints so that users can easily compare fingerprints across different software. What?s the use case for comparing fingerprints themselves? I may be missing something important, but I don't understand the need. In my opinion, certificates themselves are the lingua franca and fingerprints are merely a client implementation detail. Unless we are considering standardizing a known-hosts file format, I would prefer leaving fingerprint formats to the discretion of client implementations. There?s nothing stopping anyone today from using OpenSSL to compute fingerprints using any algorithm one could wish, if comparisons are desired. Cheers, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201128/b112 21b3/attachment.htm>
On Sat Nov 28, 2020 at 2:43 PM EST, Ben Bader wrote: > What?s the use case for comparing fingerprints themselves? I may be > missing something important. Fingerprints are used to compare certificates. Instead of comparing the certificates directly, you would essentially be comparing their hashes. Fingerprints are also useful as a unique identifier for a certificate. Let's say I use a tool to create a client certificate, and it tells me the certificate fingerprint. I should then be able to configure my server software to allow the certificate with this fingerprint. This would only work if the fingerprint format is the same across software. > In my opinion, certificates themselves are the lingua franca and > fingerprints are merely a client implementation detail. Unless we are > considering standardizing a known-hosts file format, I would prefer > leaving fingerprint formats to the discretion of client implementations. To clarify, I don't think this should be added to the Gemini specification, but rather it should be an informal specification or best practice that can be listed on the project website.
November 28, 2020 1:07 PM, "Adnan Maolood" <me at adnano.co> wrote: > Gemini software is currently fragmented with regards to certificate > fingerprints. It would be nice if there was an agreed upon way to > calculate fingerprints so that users can easily compare fingerprints > across different software. > > Here are some potential fingerprint methods. > > - Sha512 hash of the certificate, encoded in hex with ':' between each > octet. > Pros: matches the output of openssl x509 -sha512 -fingerprint > Cons: the resulting fingerprint is very long > - Sha512 hash of the certificate, encoded in base64. > Pros: easy to encode and decode > Cons: still somewhat long > - Sha256 hash of the certificate, encoded in base64. > Pros: shorter than the Sha512 hash > Cons: less secure than Sha512? > > Note that this is the hash of the entire certificate, not just the > public key. > > I think we should choose a fingerprint method and stick with it for > consistency. The one I prefer is `HASH_METHOD:HASH`, where `HASH_METHOD` is the method of the hash (like `SHA256` or `SHA512`) and `HASH` is the fingerprint with that hash method (without any `:` separators). Just my two cents, Robert "khuxkm" Miles
On Sat, Nov 28, 2020 at 1:23 PM Adnan Maolood <me at adnano.co> wrote:
> Cons: still somewhat long
> - Sha256 hash of the certificate, encoded in base64.
> Pros: shorter than the Sha512 hash
> Cons: less secure than Sha512?
>
IMO (and I am no expert, but I have taken expert advice), the *relative*
security weakness of SHA-256 over SHA-512 matters only if practical quantum
computing is developed during the life of the cert. And all security is
relative: if you want to *secure* a computer, you should disconnect all
wires from it, drop it down a deep well, and fill the well with concrete.
The CLI program sha256sum produces a SHA-256 of an arbitrary file.
I think we should choose a fingerprint method and stick with it for
> consistency.
>
100% agreement.
John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
Is it not written, "That which is written, is written"?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201128/d2c5
5127/attachment.htm>
---