Michael,
On 12/27/21 11:32, Michael Osipov wrote:
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!
It's always fun finding out ANOTHER RFC that only one tool in the world
actually uses these days, or does so in some configuration. (Ahem, OpenSSL).
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].
Yeah, it sucked.
Yours is not. Consider moving to Apache Kerby ASN.1.
I wanted to do everything for a few reasons, including the fact that I
wasn't sure of PostgreSQL would be okay with using ASF code. I can't
imagine why not since my own tool was under the same license, but, maybe
they didn't want very many dependencies. I was also going to offer to
simply have them steal my code and not actually use my library; just use
the code and say "thanks" somewhere.
I also wanted the experience of actually /doing/ it. It's not actually
that bad. People talk about how horrible ASN.1 is but it's actually
quite simple. The bad part is that it can be used in infinitely complex
ways and THAT is the PITA part.
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
Yes, it's very stupid. If the JRE had to implement primitives like this,
they should have made them (at least eventually) part of the standard
API or, these days, modules. Same thing with base64. *facepalm*
Keystore: Do you consider to turn this into a keystore type actually?
Nope.
While I cannot tell about the EC parameters, the rest should be covered
by the KeyStore API. WDYT?
The interface looks like this:
public PEMFile(Reader|InputStream);
public Entry getNext();
The Entry class is a superclass of a bunch of things like
CertificateEntry, PrivateKeyEntry, PublicKeyEntry, etc. Those things
know how to put themselves back into PEM format as well, though without
any encryption.
Including comments+javadoc, the main PEMFile source is 1275 lines, the
ASN.1 parser is 623 lines, and the "Named Curve" database of elliptic
curves and support code is 941 lines. So not much code.
It's frustrating that Java doesn't include a publicly available registry
of EC parameters anywhere. If you parse a certificate or key using the
various Generator classes, you'll get a Curve instance with the right
data in it. But if all you have is the OID of the curve, you are just
out of luck.
Every single thing I found online for how to do this kind of thing was
"just use BouncyCastle". I didn't want to use BC ;)
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
