ECC support in Forge

[sanaullah82]

I have gone through the roadMap #203 and it seems ECC crypto #116 is still not supported. is their any tentative date for its support ?

Regards,
San

[pcoppinger]

I need this also...is there a plan for this feature?

[dlongley]

There's no tentative date for support yet. There is a lot of desire for the feature, just not a lot of time/resources available to implement at the moment. A PR that implements directly or integrates support with another appropriately licensed lib in a way that is modular and consistent with the rest of the forge APIs is welcome.

[dlongley]

Ed25519 (EdDSA) support landed in 470793c and was released in 0.7.4.

It's unclear if or when any other ECC support (e.g. ECDSA) will be added. This issue will likely be closed unless someone indicates that ECDSA is desirable -- at which point we can keep this open until a PR emerges :).

[sanaullah82]

I am still waiting for ECDSA support and some other ECC NIST curves like P-256

[kohend]

We have a tool that uses node-forge to get subject information from CSRs and certificates, will a PR that will allow node-forge to parse x509 with unsupported keys (while leaving the key information blank) be accepted?

[jgarzik]

Data point: The default certificates generated by https://github.com/cloudflare/cfssl -- which is used by popular LetsEncrypt -- are ECDSA.

$ cfssl gencert -initca root-csr.json | cfssljson -bare rootca
2019/01/09 04:49:20 [INFO] generating a new CA key and certificate from CSR
2019/01/09 04:49:20 [INFO] generate received request
2019/01/09 04:49:20 [INFO] received CSR
2019/01/09 04:49:20 [INFO] generating key: ecdsa-256
2019/01/09 04:49:20 [INFO] encoded CSR
2019/01/09 04:49:20 [INFO] signed certificate with serial number 300385401353537517375563485916036843302347215331
jgarzik@c93f5fbe6053:~/tmp$ ls -l
total 20
-rwxr-xr-x 1 jgarzik jgarzik 151 Jan  9 04:38 doit.sh
-rw-rw-r-- 1 jgarzik jgarzik 229 Jan  9 04:45 root-csr.json
-rw------- 1 jgarzik jgarzik 227 Jan  9 04:49 rootca-key.pem
-rw-r--r-- 1 jgarzik jgarzik 501 Jan  9 04:49 rootca.csr
-rw-rw-r-- 1 jgarzik jgarzik 843 Jan  9 04:49 rootca.pem
jgarzik@c93f5fbe6053:~/tmp$ which openssl
/usr/bin/openssl
jgarzik@c93f5fbe6053:~/tmp$ openssl req -text -in rootca.csr
Certificate Request:
    Data:
        Version: 1 (0x0)
        Subject: C = US, ST = California, L = San Francisco, O = "Internet Widgets, Inc.", OU = WWW, CN = example.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:f6:34:5f:ef:77:93:f9:36:84:ef:94:49:4a:36:
                    c5:c4:6b:e2:d1:9f:60:93:0d:b7:93:07:f0:a3:ce:
                    4c:ab:b0:89:77:0e:8a:e1:76:54:72:58:ac:1c:e2:
                    57:2b:ee:58:fa:ae:03:dc:cf:93:05:03:cf:f4:5b:
                    47:3a:83:fb:bb
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        Attributes:
            a0:00
    Signature Algorithm: ecdsa-with-SHA256
         30:45:02:20:3e:8d:6e:e7:75:a8:36:8d:69:65:4c:50:9b:3a:
         b2:b3:33:3f:ff:12:8a:1b:9d:dc:45:ce:8e:33:e7:43:42:17:
         02:21:00:98:1f:b3:a0:67:79:6e:94:fd:3e:7e:bc:89:32:74:
         a3:03:ba:8b:6c:8c:6c:48:4b:28:1c:dd:d3:bc:dd:ee:07
-----BEGIN CERTIFICATE REQUEST-----
MIIBOjCB4QIBADB/MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEW
MBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEfMB0GA1UEChMWSW50ZXJuZXQgV2lkZ2V0
cywgSW5jLjEMMAoGA1UECxMDV1dXMRQwEgYDVQQDEwtleGFtcGxlLmNvbTBZMBMG
ByqGSM49AgEGCCqGSM49AwEHA0IABPY0X+93k/k2hO+USUo2xcRr4tGfYJMNt5MH
8KPOTKuwiXcOiuF2VHJYrBziVyvuWPquA9zPkwUDz/RbRzqD+7ugADAKBggqhkjO
PQQDAgNIADBFAiA+jW7ndag2jWllTFCbOrKzMz//EoobndxFzo4z50NCFwIhAJgf
s6BneW6U/T5+vIkydKMDuotsjGxISygc3dO83e4H
-----END CERTIFICATE REQUEST-----

[davidlehn]

@kohend If you would like to add partial support as needed for your use case, that would be great. As long as it's not breaking other code, I imagine it could be merged in. Aim for more complete future support and just leave stubs to fill in later. We're a bit thin on resources to work on such things now so would appreciate the help. Looks like that cfssl tool could help create some test data.

[jgarzik]

Here is an all-JS implementation of ECDSA secp256k1 as used in bitcoin and other blockchain software: https://github.com/bitpay/bitcore-lib/tree/master/lib/crypto

Tested in the field for years. MIT-licensed.

ETA: Actually, bitcore-lib depends on https://www.npmjs.com/package/elliptic

[TJKoury]

@davidlehn @dlongley @jgarzik I'm going to take a whack at it using elliptic.

Question: Under what category should I put the OID for prime256v1?

[jgarzik]

Question: Under what category should I put the OID for prime256v1?

The top category, algorithms, seems most appropriate based on RFC3279, but I defer to the double-Ds' opinion...

[TJKoury]

Ok, so I've been going through the code here, and I'm seeing that, as advertised, forge is really hard-coded for RSA.

For example, the method on forge.pki to convert a public key to Asn.1 syntax is declared in the rsa.js module.

To do this correctly will take a lot of doing. I'm going to try to get a hacked up version going to prove the concept, but I'm definitely going to need some coordination / eyes on for the final product.

[dlongley]

@TJKoury,

Thanks for volunteering to work on this stuff!

For example, the method on forge.pki to convert a public key to Asn.1 syntax is declared in the rsa.js module.

Yeah, the fact that forge needs an organizational and API update can be a drag on getting new features like this in. It involves shaving more yaks than would otherwise be necessary.

Question: Under what category should I put the OID for prime256v1?

Sorted appropriately under algorithm OIDS is fine. Thanks!