crypto: expose certificate decoding function

[sam-github]

Format is the same as:

• https://nodejs.org/api/tls.html#tls_tlssocket_getcertificate

No docs or tests yet, @nodejs/crypto, I'll finish this if we want it.

Its easy, it just exposes current data format of the tls APIs, and makes testing whether certificates can be decoded quite easy, rather than having to round-trip them through TLS just to get a parsed cert :-(.

Maybe some other format would be better, and then it could be added to tls and crypto, but starting with a "better" format in crypto that is different from what tls does seems like it would increase inconsistency.

Fixes: #29181

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[mscdex]

Unintended change?

[tniessen]

I am not a big fan of this format, but I am afraid we might have to stick to it.
Same goes for the function name, parseCert, but I see that we already use cert in lots of places.

[sam-github]

@tniessen Can you think of a better name?

So, a couple +'s, so I should finish this off?

[sam-github]

And yeah, I don't love the legacy format either, but its what we have until someone adds another.

[jasnell]

+1 to getting this in. For future changes, perhaps add an options argument that accepts a format option whose only value now is legacy. This gives us some flexibility in adding an improved format as a follow on.

[bnoordhuis]

Couple of width/sign issues here: buf.length() returns a size_t, d2i_X509 takes an int. Suggestion:

size_t data_len = buf.length();
CHECK_LE(data_len, INT_MAX);

[bnoordhuis]

Style/local consistency: no braces, ditto on line 2219.

[tniessen]

Can you think of a better name?

In general, I think JavaScript and Node.js are leaning towards verbosity, so I think parseCertificate might be a better fit than parseCert. IIRC X.509 also refers to the ASN.1 structure as "Certificate", so that would align nicely. On the other hand, we already use certain naming schemes in TLS/crypto, and we do use the shorthand "cert" in other places. If that wasn't the case, I would prefer parseCertificate, but given this situation, I am +0 on the longer name.

[sam-github]

Existing uses of cert are for non-X.509, so maybe using the short name will confuse people. I will make the name longer and add the docs and tests.

[baparham]

@sam-github did this get closed for any particular reason? It's not merged in yet, right?