[Wanted feature] Request for adding `Subject Public Key` fingerprint on Key Details

[The-Lum]

This is a feature request.

For a future enhancement, could you add:

• Subject Public Key fingerprint on [Public] Key Details or Certificate Details?

Here are some proposals views:

Impacted Screens:

• [ ] DViewPublicKey
• [ ] DViewCsr
• [ ] ~Possibly DViewCertificate~ [due to a remark below]
• [ ] Possibly DGenerateCsr

Hints or helps:

• JCertificateFingerprint
• KeyIdentifierGenerator

If that interest other people... or if someone can propose a PR... Regards.

[FYI @kaikramer, @jgrateron]

[kaikramer]

You have done a lot for this project, so I will make sure that this feature is in the next release. But, I don't like this to be in the certificate details. There is already quite a long list of information displayed there and I think there should not be more. I am also not sure if this feature is really useful for many users.

It certainly belongs in the Public Key details and maybe also in those CSR dialogs.

Are really all hash algorithms needed or just the SHA-1 value as in the Subject Key Identifier extension?

[The-Lum]

Hello @kaikramer, and all,

You have done a lot for this project, so I will make sure that this feature is in the next release.

Thanks a lot, and if I can help for that...

But, I don't like this to be in the certificate details. There is already quite a long list of information displayed there and I think there should not be more.

I agree, that is the fact as I mentioned 'Possibly DViewCertificate' and 'Possibly DGenerateCsr'.

I am also not sure if this feature is really useful for many users.

Those extra information will be relevant:

• to end-to-end follow a key (from public key, to CSR generation, to Cert. import, and Cert viewing)
• and especially for certificate which does not contain the Subject Key Identifier (SKI) and/or Authority Key Identifier (AKI)

And I hope that I am not the only people interest by that...

It certainly belongs in the Public Key details and maybe also in those CSR dialogs.

👍

Are really all hash algorithms needed or just the SHA-1 value as in the Subject Key Identifier extension?

Currently, here are the algo. managed by another tool (as MS tools certutil) :

• Key Id Hash (rfc-sha1) ~[RFC 5280 SKI method 2]~ [RFC 5280 SKI method 1] (see remaks on below discussions)
• Key Id Hash (sha1) ~[RFC 5280 SKI method 1]~ [pin-sha1-hex] (idem)
• Key Id Hash (bcrypt-sha1)
• Key Id Hash (bcrypt-sha256)
• Key Id Hash (md5)
• Key Id Hash (sha256)
• Key Id Hash (pin-sha256)
• Key Id Hash (pin-sha256-hex)

IMHO, it will be necessary to manage at minima:

• Key Id Hash (rfc-sha1) ~[RFC 5280 SKI method 2]~ [RFC 5280 SKI method 1] (see remaks on below discussions)
• Key Id Hash (sha1) ~[RFC 5280 SKI method 1]~ [pin-sha1-hex] (idem)
• Key Id Hash (sha256)

To debate, Regards [derzeit aus Bonn]

[Colbix]

Would it be beneficial to make a tabbed pane? General tab and details tab for further information to not clutter the window.

[kaikramer]

@The-Lum Alright, seems fine to me. The necessary hash algorithms and MD5 are no problem at all. Bcrypt should be not be too hard either, but I am not 100% sure about it. And I have no idea what "pin-sha256" is... 😄

There are not many possible reasons for a trip to Bonn, although it can be quite nice there... Did you visit the BSI?

@Colbix Interesting idea. However, it would be still one additional click to see the new field, so not a big advantage vs. opening the public key dialog.

[The-Lum]

Hello @kaikramer, and all,

And I have no idea what "pin-sha256" is... 😄

The "pin-sha256" is the Base64 of the "sha256", and "pin-sha256-hex" the corresponding in hexadecimal.

For information, see full detailed elements on Pin or Public Key Pinning here:

• https://security.stackexchange.com/questions/29988/what-is-certificate-pinning
• https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning
• https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning
• https://datatracker.ietf.org/doc/html/rfc7469

---

There are not many possible reasons for a trip to Bonn, although it can be quite nice there... Did you visit the BSI?

I could have almost (and perhaps the BSI use KSE) but I visited the Arithmeum museum... _[:classical_building: Cultural advertising... :framedpicture:] It was there that I discovered a showcase dedicated to the crypto. with:

• a Wheatstone ring
• a Kryha and a liliput Kryha
• and an Enigma Machine

---

Regards.

[kaikramer]

I have spent some time trying to reproduce the output of "certutil -dump" with other tools to find out how the key hash values are calculated. And the results are quite surprising...

For example the following statement is not correct:

Key Id Hash (rfc-sha1) [RFC 5280 SKI method 2] Key Id Hash (sha1) [RFC 5280 SKI method 1]

"rfc-sha1" is calculated like the SKI but with method 1 (not 2) and "sha1" has nothing to do with SKI calculation, it is calculated in the same way as "pin-sha256-hex". It gets even worse: "sha1" and "sha256" are calculated differently (they use different input data).

The following table gives an overview on how the different hash values are calculated:

Certutil Name	Example Value	Input Data	Output Encoding	Comment
md5	db73d312aa...1567f5f67fd63	subjectPublicKey	Hex	Only the BIT STRING
rfc-sha1	8811856d14...1b5e7ef1484	subjectPublicKey	Hex	Same as SKI (method 1)
sha1	cc675e5466b...1e8c51441a	subjectPublicKeyInfo	Hex
sha256	4498ff4877e...a65529fe5b7d	subjectPublicKey	Hex	Only the BIT STRING
pin-sha256	bQNL8mZar...e4LEuYVBIYU=	subjectPublicKeyInfo	Base64	See RFC 7469 Appendix A
pin-sha256-hex	6d034bf266...c4b985412185	subjectPublicKeyInfo	Hex
bcrypt-sha1	5a9e120018...e3add3b0eac	???	Hex
bcrypt-sha256	26a2bf12c74...6868ce391a94	???	Hex

These inconsistencies are very unfortunate, because I cannot simply re-use the names of certutil, but have to come up with more descriptive names, which will eventually make comparisons more difficult for the users...

I think the best solution will be to omit the equivalent of "sha1", as it is definitely the odd one out. Then we simply have MD5, SHA1 and SHA-256 hashes calculated over the SPK value plus PIN (calculated over SPKI) as Base64 and Hex.

For the two bcrypt hashes I was not able to recreate those values. A password hashing algorithm seems quite out of place for this purpose anyway. So no bcrypt for KSE.

...but I visited the Arithmeum museum...

Oh, that's very interesting! I didn't even know about the Arithmeum.

[The-Lum]

Hello @kaikramer, and all,

Sorry for these bad instructions. In fact I used them without even really knowing what they really corresponded to: between subjectPublicKey (SPK) hash or subjectPublicKeyInfo (SPKI) hash!

Thank you for the clarification.

Therefore, the useful and necessary data (for my part) would be:

• legacy
  • rfc-sha1 [SKI method 1]
  • SKI method 2 [SKI method 2]
  • pin-sha1 [SHA-1(SPKI) on hexa.] (just for legacy, and traceability..., perhaps rename sha1 to pin-sha1)
• new
  • pin-sha256 [SHA-256(SPKI) on hexa.]

Regards.

[The-Lum]

Hello @kaikramer, and all,

Thanks a lot for your implementation:

• kaikramer/keystore-explorer@cdc85c1f4cd7a68e1b6874d267187cfc3abbb594

Perhaps you need some help for the French resource files. Here is a PR for that:

• 404

Regards.

[kaikramer]

I was a bit unhappy about the use of abbreviations for the fingerprint algorithm and have added a slightly more detailed explanation to the tooltip:

That's also the reason why your PR is not merged yet.

[The-Lum]

Hello @kaikramer,

Sure. Then to follow 1564a87b6b83fee84f085d9a7f8dcc563e819d87: Here is the French version: f32f629626916e2e65b214dc9ef275305e57f93e on #404.

Regards.