Am 2021-12-28 um 01:20 schrieb Christopher Schultz:
Michael,
[...]
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).
Two issues:
* Complexity
* Why do it ourselves when you see that there are idiots do it for free?!
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 still would consider trying Kerby ASN.1. It think the benefit using a
library for this overweighs another dependency.
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.
Exactly, the sheer nesting in ASN.1 can drive you insane.
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.
Maybe that be would nice, standard API, new impl. Version 2.0?
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.
Does your impl comply with RFC 7468? Also, don't use the term 'PEM', it
has been long superseded, especially when the aformentioned RFC came
out. People use it out of habit, although it does not really apply anymore.
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 ;)
Way too large.
Michael
