On Mon, Dec 27, 2021 at 5:13 PM Christopher Schultz <ch...@christopherschultz.net> wrote: > > 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.
I had to reuse the (super simple) asn1 parser that is in Tomcat [Mark did it] to do ocsp with Panama (this part of the tomcat-native C code was better reimplemented as real Java, rather than Panama-C). For whatever reason, it worked, I got lucky I guess :D Personally, I'm not very motivated to add a dependency for this, unless we somehow suddenly need a full parser (and I hope we never do). > 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. ;) Rémy --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
