Am 2021-12-27 um 17:13 schrieb Christopher Schultz:
Michael, All,
I haven't actually committed any source yet, as I'm still polishing it
up a bit but I intend to release a bunch of PEM-related code on GH under
this repository:
https://github.com/ChristopherSchultz/pem-utils
The license is AL2.
The expectation is that most common types of cryptographic artifacts
that are often stored in PEM files can be loaded using this library.
As of this writing, it supports entries that have these headers:
-----BEGIN CERTIFICATE-----
-----BEGIN PRIVATE KEY-----
-----BEGIN ENCRYPTED PRIVATE KEY-----
-----BEGIN RSA PRIVATE KEY-----
-----BEGIN DSA PRIVATE KEY-----
-----BEGIN EC PRIVATE KEY-----
-----BEGIN EC PARAMETERS-----
-----BEGIN PUBLIC KEY-----
I'm sure there are some combination of features used by e.g. OpenSSL
that can get past the parser at this point, but my hope is that I'll get
contributions for some of those less-commons cases.
I also hope it can serve as a set of examples for how to load certain
types of things.
Originally, this started out as a clean-room implementation starting
with just the crypto APIs provided by the JRE. I didn't want to look at
the Tomcat code that performs similar operations as I wasn't sure if
there were any IP issues with releasing this code separately. The
original intent was to allow the PostgreSQL project to use the code for
their JDBC driver, which only supports one particular flavor of DER file
(yuck!).
Anyhow, it's grown into an implementation of a bare-bones ASN.1 parser
and explicit support for carious combinations of things.
Maybe I'll commit what I've got and get feedback more quickly, if you'd
be willing to have a look.
One of the glaring things I haven't done yet is to provide an interface
to provide passwords for encrypted entries; as of this moment, I have
"changeit" and "secret" hard-coded into the Java code because those were
the passwords I used for the test keys. ;)
Although, I haven't see your code I know that this is a lot of work I
have done some of that some for our enterprise CAs with pure Java
recently. Kudos!
As for ASN.1: I do NOT recommend to write your own ASN.1 parser, I had
to do this for a very narrow usecase [1]. Yours is not. Consider moving
to Apache Kerby ASN.1. I use it with certificated and it works like a
charm for me [2]. In general, the JDK includes at least three ASN.1
impls (JGSS, LDAP and X.509). It is a shame that there is no public impl
in the JDK: https://bugs.openjdk.java.net/browse/JDK-4635648
Keystore: Do you consider to turn this into a keystore type actually?
While I cannot tell about the EC parameters, the rest should be covered
by the KeyStore API. WDYT?
Michael
[1]
https://github.com/michael-o/tomcatspnegoad/pull/2/commits/0e5d217a72bf14b29301c838aea0cf14d17884b6
[2] https://directory.apache.org/kerby/kerby-asn1.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
