doc: mark Certificate methods as static, add missing KeyObject.from

[panva]

cc @jasnell @tniessen

[tniessen]

I realize that this has landed and was released, but regarding KeyObject.from see #37218 (comment):

While we are at it, I have to say I'm not happy that #35093 added KeyObject.from. It is public yet undocumented and has a super generic name yet serves a super specific purpose. A purpose that should rarely be necessary if WebCrypto actually accomplished its goals of feature completeness and portability.

Not really related to the changes in this PR though, at least the function won't be undocumented anymore.

[panva]

@tniessen would you like to introduce a specifically named method instead and mark this one deprecated? Either way i think this doc update should land.

[tniessen]

would you like to introduce a specifically named method instead and mark this one deprecated?

That depends. It works and there is no ambiguity when it comes to the input. We can reuse the same function with different signatures for other inputs.

It depends on what other input forms we want to allow in the future. What about JWK, for example? If we allow KeyObject.from(jwkObject), then we suddenly create the chance of having ambiguous inputs because JWK is a plain object and not an instance of a class that is specific to Node.js.

In the other PR (#37218), adding KeyObject.prototype.toCryptoKey(webCryptoAlgorithm, usages, extractable) was suggested. If that's going to happen, then renaming KeyObject.from to KeyObject.fromCryptoKey might make sense. I've taken the liberty of opening #37240.

If we never want to allow anything but uniquely identifiable types, such as CryptoKey, as inputs to KeyObject.from, then we might as well leave it at that. However, I'm afraid that at some point, someone will try to fit the generic API name to other inputs.

[tniessen]

(Approving under the assumption that #37240 will update the docs accordingly.)

[panva]

Landed in e8286bb