Including the certificate signing request format/PKCS#10?

[eyeinsky]

This is perhaps a wider topic, because it requires some non-trivial amount of work, but is there any interest in adding PKCS#10 support to cryptostore? There is already an existing library (pkcs10), but isn't actively developed.

My ulterior motive is to sign CSRs with a CAs key so that they can be eventually put in PKCS#12 containers and installed in browsers. But currently I haven't been able to find a way to do this in haskell. But it would help if the crypto formats lived in the same library and shared types, so result would be more easily achived.

[ocheron]

For the immediate concern of generating a SignedCertificate with a valid signature, you can find code examples in x509-validation and tls test suites. Beware the generated certificates are for testing and don't necessary have all required X.509 extensions that a proper CA would include, like SAN, key ID or usage flags. A bit more code is likely needed.

Regarding the CSR file format, it should not be very difficult to define a data type and (de)serialization code similar to the x509-* packages or here. I have no plan to do this personally (not using Haskell anymore) but would happily answer if you have questions about existing code.

[eyeinsky]

Thank you for the tips, I can successfully sign CSRs now! This test module in x509-validation was exactly it.

As a learning vehicle I've started an openssl-like cli project here (it's a funny name but the code itself is serious, although very much alpha). The modules under X509 are pretty much a mild refactor of the test module in x509-validation -- perhaps later on when they code is more ready I'll try to submit that part of the code to the x509 package, as that's where it feels like it belongs.

A few things I did already, and questions:

• in X509.SignatureAlgorithm.SignatureAlgorithm (Alg in the original) I've removed key generation parameters from the data type -- key generation params aren't really part of how to sign a certificate, right?
• second question, here I try to convert from a key-as-type to the ADT in the x509 package combining all keys, the curveToCurveName part is sketchy -- is the way I try to find a curve name correct, and what to I do if I can't find a name? (The origin of that code is here, there the curve name was taken from a field in the Alg data type which is not present here, hence the problem.)

[ocheron]

1st point:

Yes in the test suite Alg is just a single type introduced to parameterize all test cases. Splitting between key-generation parameters and signature parameters is fine. Signature generation takes the generated key as input.

2nd point:

The cryptonite API is generic and accepts any elliptic curve in Weierstrass form. When using cryptonite PublicKey as internal key data type, you loose the curve name. This is not necessarily a big problem: EC certificates should use curves P-256, P-384 or P-521 exclusively. All the rest is deprecated.

Other possible approach is to use a different data type, holding the curve name.

For example the Crypto module in tls directly uses x509 data types PrivKey and PubKey. Downside is that the key type is not reflected in the Haskell type.

In the end it's all trade-off and to what extent you want to polish this. Types PrivKeyEC / PubKeyEC from x509 may be a good compromise but I never tried.