[GH-ISSUE #128] Update key storage and generation to use PKCS#8 #62

New issue

Closed

opened 2026-03-07 22:18:28 +03:00 by kerem · 4 comments

kerem commented

2026-03-07 22:18:28 +03:00

Owner

Originally created by @briansmith on GitHub (May 9, 2017).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/128

I would like to suggest the following:

Switch the ring support for Ed25519 to use PKCS#8 format instead of the "raw" format.
When generating/encoding keys, encode them in PKCS#8 format, for both OpenSSL and ring.
Ensure that the OpenSSL version can already read (binary) PKCS#8 private keys, either instead of, or in addition to, the current raw (PEM) RSAPrivateKey/ECPrivateKey/etc. support.

This way, it would be much easier to switch between ring and OpenSSL. Note that PKCS#8 is the only really standardized file format for private keys, which is why I support it in ring and why I recommend people use it.

I suggest that we could do the ring update by basically dropping the current Ed25519 code and then adding it back using ring's PKCS#8 support, also adding RSA (and soon ECDSA) PKCS#8 support. Then we could do the same for OpenSSL as a separate step.

WDYT?

Originally created by @briansmith on GitHub (May 9, 2017). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/128 I would like to suggest the following: 1. Switch the *ring* support for Ed25519 to use PKCS#8 format instead of the "raw" format. 2. When generating/encoding keys, encode them in PKCS#8 format, for both OpenSSL and *ring*. 3. Ensure that the OpenSSL version can already read (binary) PKCS#8 private keys, either instead of, or in addition to, the current raw (PEM) RSAPrivateKey/ECPrivateKey/etc. support. This way, it would be much easier to switch between *ring* and OpenSSL. Note that PKCS#8 is the only really standardized file format for private keys, which is why I support it in *ring* and why I recommend people use it. I suggest that we could do the *ring* update by basically dropping the current Ed25519 code and then adding it back using *ring*'s PKCS#8 support, also adding RSA (and soon ECDSA) PKCS#8 support. Then we could do the same for OpenSSL as a separate step. WDYT?

kerem closed this issue

2026-03-07 22:18:28 +03:00

kerem commented

2026-03-07 22:18:29 +03:00

Author

Owner

@bluejekyll commented on GitHub (May 9, 2017):

Yes, this sounds like a great plan. I had picked PKCS#12 mostly for compatibility with native-tls. I think the move to PKCS#8 sounds good. For obvious reasons, I was not happy with the raw storage. I did read some of your conversation on native-tls on this subject, so I'm already convinced.

On another note, I want to get passwords out of the config file as well, and prefer them specified in the environment. Though, at the end of the day, I don't know how much that will generally improve things.

@bluejekyll commented on GitHub (May 9, 2017): Yes, this sounds like a great plan. I had picked PKCS#12 mostly for compatibility with native-tls. I think the move to PKCS#8 sounds good. For obvious reasons, I was not happy with the raw storage. I did read some of your conversation on native-tls on this subject, so I'm already convinced. On another note, I want to get passwords out of the config file as well, and prefer them specified in the environment. Though, at the end of the day, I don't know how much that will generally improve things.

kerem commented

2026-03-07 22:18:29 +03:00

Author

Owner

@briansmith commented on GitHub (May 9, 2017):

If you think about a Docker/Kubernetes type environment, the admin probably wants to make the private key file itself the secret. In that case, it's superfluous to have a password to decrypt the private key file. In those environments, IIRC, the most important thing is that the configuration allows the private key file to be in a directory path completely separate from the rest of the configuration.

@briansmith commented on GitHub (May 9, 2017): If you think about a Docker/Kubernetes type environment, the admin probably wants to make the private key file itself the secret. In that case, it's superfluous to have a password to decrypt the private key file. In those environments, IIRC, the most important thing is that the configuration allows the private key file to be in a directory path completely separate from the rest of the configuration.

kerem commented

2026-03-07 22:18:29 +03:00

Author

Owner

@bluejekyll commented on GitHub (May 9, 2017):

Yeah. I think that would be mostly accurate. Where the keys are attached via some 3rd party tool like Vault or something. I've been interested in, but have not yet started looking into, PKCS#11 support so that HSM's could be used as well.

In those situations, will the key be encrypted in PKCS#8, still requiring a password to decrypt?

@bluejekyll commented on GitHub (May 9, 2017): Yeah. I think that would be mostly accurate. Where the keys are attached via some 3rd party tool like Vault or something. I've been interested in, but have not yet started looking into, PKCS#11 support so that HSM's could be used as well. In those situations, will the key be encrypted in PKCS#8, still requiring a password to decrypt?

kerem commented

2026-03-07 22:18:29 +03:00

Author

Owner

@bluejekyll commented on GitHub (May 17, 2017):

fixed in #133

@bluejekyll commented on GitHub (May 17, 2017): fixed in #133

kerem referenced this issue

2026-03-16 01:54:17 +03:00

[PR #62] [MERGED] Cleanup ClientFuture for release #1215