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
PKCS5KeyFileclass and references in favor of parsing usingPKCS8KeyFile. The Bouncy CastlePEMParseralready used inPKCS8KeyFilesupports 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 KEYorBEGIN RSA PUBLIC KEYalign 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
PKCS8KeyFileis 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 thePKCS5KeyFileimplementation and defaulting parsing toPKCS8KeyFileremoves the need for custom PEM parsing inPKCS5KeyFilewhile maintaining support for the same types of keys.Renaming
PKCS8KeyFileto something more generalized, such asPEMKeyFilemight 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.