crypto: expose OpenSSL's x.509 API

[silverwind]

To generate self-signed x.509 certificates and private keys from within an application, modules like pem have to rely on spawning the system's OpenSSL, which is problematic as it can be out of date or worse, not available at all (Windows).

I think it would make sense to expose the following APIs from the bundled OpenSSL through crypto:

• generate a private key
• generate a self-signed certificate
• generate dh parameters

Accompaning the above, I could also see the following:

• read a private key's size
• read certificate fields
• read dh parameters's key size

[silverwind]

I wonder if something like this should live in tls or crypto. @indutny any feedback?

[indutny]

It should be crypto for sure. Can't it be done in binary addons?

It feels like we are trying to workaround problems with C++ addons by moving everything into the core. I don't like this tendency.

cc @bnoordhuis

[silverwind]

I think we can strike dh parameters (prime) generation off that list, as these seem to be obtainable through crypto.createDiffieHellman(keysize).getPrime() which I assume can be fed directly into TLS's dhparam option.

[silverwind]

can be fed directly into TLS's dhparam option.

I take that back. Pretty sure the docs on dhparam are actually lacking and it only accepts PEM formatted dh parameters, not raw primes in buffer format. Is this correct?

cc: @shigeki

[indutny]

@silverwind this is correct.

[silverwind]

@indutny yeah, I figured out generating dhparam in node yesterday, thanks to your nice asn.1 module :)

[shigeki]

@silverwind Yes, the supported format of dhparam is PEM of PKCS#3 in buffer.
F.Y.I. In the future, DH prime/base will not be explicitly written as a parameter and be changed to be written and negotiable in a built-in named group as https://tools.ietf.org/html/draft-ietf-tls-tls13-07 and https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.3.1.4.2 . So we will be able to write it as ffdhe2048 such like prime256v1 in ecparam.

[calvinmetcalf]

openssl related stuff might be a good candidate for things that should be in core due to how easy it is to get openssl wrong with consequences that can popup in unexpected ways

[Trott]

Is there consensus that this does or doesn't belong in core? Or is that still up for debate?

[jasnell]

I don't think there's consensus that it doesn't belong, but neither is there consensus that it would make it in. I think it's safe to say that it's unlikely this would make it in.

[bnoordhuis]

I wouldn't necessarily object such additions but it's a bit of a slippery slope. For example:

generate a self-signed certificate

Self-signed certificates are useless except for testing, so the logical next step is to support certificate signing using a CA key.

But once you allow that, you can make a case that creating CA keys with node should also be possible. And once that is in, it should probably also be taught how to do CRL management, etc., etc.

It would be a lot easier to simply link the openssl apps into the node binary so you could node genrsa -out key.pem 2048. :-)

[Trott]

This issue has been inactive for sufficiently long that it seems like perhaps it should be closed. Feel free to re-open (or leave a comment requesting that it be re-opened) if you disagree. I'm just tidying up and not acting on a super-strong opinion or anything like that.