Standard fingerprint format for TLS certificates

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>