support for der encoded certificates, and DirName format alternate names

[fabled]

No description provided.

[wahern]

On Mon, Mar 24, 2014 at 10:49:52AM -0700, Timo Ter??s wrote:

 * support loading der encoded certificates

I expanded on your patch and tried to go through all the places where PEM is
input or output and added code to accept DER as an option. I also took a
page from Ruby's bindings and, if not explicitly specified, attempt both PEM
and DER decoding.

I've pushed to GitHub. Let me know what you think.

One spot I still need to get to is pk__tostring and pk_toPEM. There are some
assumptions there that need untangling.

 * support for DirName format GENERAL_NAMEs

I still need to get to this. Probably tomorrow.

[fabled]

On Tue, 25 Mar 2014 20:03:05 -0700
William Ahern notifications@github.com wrote:

On Mon, Mar 24, 2014 at 10:49:52AM -0700, Timo Ter??s wrote:

 * support loading der encoded certificates

I expanded on your patch and tried to go through all the places where
PEM is input or output and added code to accept DER as an option. I
also took a page from Ruby's bindings and, if not explicitly
specified, attempt both PEM and DER decoding.

I've pushed to GitHub. Let me know what you think.

One spot I still need to get to is pk__tostring and pk_toPEM. There
are some assumptions there that need untangling.

Looks nice. I might later on need pkcs12 format too, but I'm good with
der support for now. Another addition later on could be certs on engine
(smart cards)...

 * support for DirName format GENERAL_NAMEs

I still need to get to this. Probably tomorrow.

Thanks!

[wahern]

On Tue, Mar 25, 2014 at 11:08:55PM -0700, Timo Ter??s wrote:

On Tue, 25 Mar 2014 20:03:05 -0700
William Ahern notifications@github.com wrote:

Looks nice. I might later on need pkcs12 format too, but I'm good with
der support for now. Another addition later on could be certs on engine
(smart cards)...

PKCS12 and Engine support... looks like lots of work ;) Should be
interesting, though.

Maybe I can pick your brain. How familiar are you with OpenPGP? Do know how
feasible it would be to turn a PGP RSA public key and signature into
DER-encoded equivalents for OpenSSL consumption? I assume it's perfectly
feasible, but I haven't bothered looking at the PGP specification closely
enough to know if, e.g., the padding schemes are problematic.

I ask because I want to work on a Lua module system that would download and
load packages on-demand from require(), and I want to integrate a
signature scheme so that you could choose which packagers you trust.

GnuPG is the natural tool to use for signing (especially since I have an
OpenPGP smartcard), but OpenSSL is far more practical for verification on
the Lua side.

• support for DirName format GENERAL_NAMEs

I still need to get to this. Probably tomorrow.
Thanks!

I've committed and pushed the GEN_DIRNAME support. Now I just need to test
all of this new stuff.

Thanks for the patches.

[fabled]

On Wed, 26 Mar 2014 20:27:19 -0700
William Ahern notifications@github.com wrote:

Maybe I can pick your brain. How familiar are you with OpenPGP? Do
know how feasible it would be to turn a PGP RSA public key and
signature into DER-encoded equivalents for OpenSSL consumption? I
assume it's perfectly feasible, but I haven't bothered looking at the
PGP specification closely enough to know if, e.g., the padding
schemes are problematic.

I ask because I want to work on a Lua module system that would
download and load packages on-demand from require(), and I want to
integrate a signature scheme so that you could choose which packagers
you trust.

GnuPG is the natural tool to use for signing (especially since I have
an OpenPGP smartcard), but OpenSSL is far more practical for
verification on the Lua side.

RFC 4880 (OpenPGP in general) and RFC 6637 (ECC in OpenPGP) are you
friends here.

In short, OpenPGP specifies different format of encoding things. Any
OpenPGP message adheres to the generic 'packet format' that is typical
tag-length-value bit/byte stream.

Public/private keys are stored as collection of MPI numbers, so you'd
need to parse those packets formats, and convert them to openssl
BIGNUMs. I think BN_bin2bn and BN_bn2bin would be compatible to
import/export the raw MPI part (you'd still need to handle the bit
lengths separately, it looks like BN_bn2mpi is NOT compatible).

Using those BIGNUMs you can then construct RSA, etc. high-level openssl
objects. Meaning you'd need to write loader/writer for each algorithm
yourself.

Seems there's some old example code that can be found on the internet
to do exactly these things. E.g.
http://www.cypherspace.org/openpgp/pgpdsa/
http://www.cypherspace.org/openpgp/zerucha/

Also verifying the OpenPGP signature is going to need a bit of work. As
the hash is calculated over the data + signature packet data. Though
once you have the hash calculated, you can use regular openssl
functions to check if the hash matches the signature.

I've committed and pushed the GEN_DIRNAME support. Now I just need to
test all of this new stuff.

Thanks!

[wahern]

Merged by hand.