Details
-
New Feature
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
Description
NiFi application properties include support for JKS and PKCS12 Key Store types, as well as BCFKS, aligning with standard Java capabilities for key and certificate information. These types provide some amount of password protection for entries, based on Java version and underlying format capabilities. The level of security that password protection provides is variable, depending on the Key Store implementation and Java system properties.
The historical Privacy Enhanced Mail (PEM) format defined in RFC 1421 supports representing keys and certificates as Base64-encoded binary with standard headers and footers. Standard Java classes are capable of reading PEM keys and certificates with some amount of parsing, depending on the particular type of file in question.
In addition to existing Key Store types, NiFi application properties should support using PEM files for mutual TLS communication. Supporting PEM files avoids the need for converting to PKCS12 or other formats, and also avoids the need for maintaining passwords required to read Key Store files.
Initial PEM file support should include building a Key Store from individual Private Key and Certificate Chain files, and should include building a Trust Store from a Certificate Chain file containing one or more Certificates.
Private Key support should include the following formats and algorithms:
- PKCS1 for RSA
- PKCS8 for RSA, Ed25519, or ECDSA with NIST curves P-256, P-384, and P-521
PKCS1 Private Keys have the header BEGIN RSA PRIVATE KEY and PKCS8 Private Keys have the header BEGIN PRIVATE KEY.
These formats and algorithms align with current modern algorithm recommendations and usage patterns, such as Let's Encrypt Supported Key Algorithms.
Certificate support should include reading standard X.509 files with the BEGIN CERTIFICATE header.
For disambiguation from existing formats, the keystoreType and truststoreType should take a new value named PEM.
For loading the Key Store, the PEM type should trigger loading two new properties named:
- nifi.security.keystore.privateKey
- nifi.security.keystore.certificate
This approach provides clear separation between the private key and certificate chain, while maintaining the association through the root name of both properties.
For loading the Trust Store, the PEM type should trigger loading one new property named:
- nifi.security.truststore.certificate
The initial implementation should maintain compatibility with existing properties and prefer existing properties when defined.
Attachments
Attachments
Issue Links
- links to