Replace PKCS5 Key File Class with PKCS8 #793
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request removes the
PKCS5KeyFile
class and references in favor of parsing usingPKCS8KeyFile
. The Bouncy CastlePEMParser
already used inPKCS8KeyFile
supports both types of key files.RFC 8018 describes PKCS5 as the Password-Based Cryptography Specification Version 2.0, including methods for key derivation using various algorithms. Although encrypted private keys make use of password-based cryptography, using PKCS5 as a type of key file does not describe the key format itself.
RFC 8017 describes PKCS1 as RSA Cryptography Specifications Version 2.2. Appendix A of RFC 8017 describes the ASN.1 syntax for RSA Public and Private Keys. The encoded binary contents of files starting with
BEGIN RSA PRIVATE KEY
orBEGIN RSA PUBLIC KEY
align with the ASN.1 described in RFC 8017. For this reason, it is more accurate to describe the format of these files as PKCS1.RFC 5958 describes PKCS8 Asymmetric Key Packages, including the ASN.1 syntax for different types of keys.
Although the naming of
PKCS8KeyFile
is accurate, the implementation leverages the Bouncy CastlePEMParser
, which is capable of handling a variety of PEM encoded formats, including both PKCS8 and PKCS1 keys, with or without encryption. Removing thePKCS5KeyFile
implementation and defaulting parsing toPKCS8KeyFile
removes the need for custom PEM parsing inPKCS5KeyFile
while maintaining support for the same types of keys.Renaming
PKCS8KeyFile
to something more generalized, such asPEMKeyFile
might be more accurate, but the initial approach avoids renaming to minimize the impact of changes.Java supports unencrypted PKCS8 processing using PKCS8EncodedKeySpec and other classes. It might be possible to remove the dependency on Bouncy Castle with a custom PEM-parsing implementation, but it would be useful to streamline generalized PEM-encoded processing prior to considering those changes.