Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Including the certificate signing request format/PKCS#10? #5

Open
eyeinsky opened this issue Jan 10, 2021 · 3 comments
Open

Including the certificate signing request format/PKCS#10? #5

eyeinsky opened this issue Jan 10, 2021 · 3 comments

Comments

@eyeinsky
Copy link

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
Copy link
Owner

ocheron commented Jan 10, 2021

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
Copy link
Author

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:

@ocheron
Copy link
Owner

ocheron commented Jan 31, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants