search

str4d / x509.rs

Pure-Rust X.509 serialization
Apache License 2.0
5 stars 3 forks source link

Join efforts in x509-parser ? #2

Open chifflier opened 4 years ago

chifflier commented 4 years ago

Hi, I'm the author of the crate x509-parser (and also cookie-factory), and have also added some serialization support in der-parser. I noticed your crate, and see many similarities with what I'm willing to add to x509-parser.

What do you think of merging some efforts or code?

str4d commented 3 years ago

Hi! Sorry for the delay in responding (last year was A LOT). I'm definitely interested in figuring out how to collaborate!

My motivation for starting this crate was to enable creating self-signed certificates in https://github.com/iqlusioninc/yubikey-piv.rs (in order to enable creating https://github.com/str4d/age-plugin-yubikey), and I wanted a combinatorial serializer (because I love nom and cookie-factory). I found and used x509-parser 🙂 but couldn't find a corresponding serializer, so made the fateful decision to attempt to write one. As such, this serializer is currently very opinionated (only supporting the specific subset of certificate serialization that I require), but the intent is that the underlying DER serializer is accurate and generic enough to be usably composable.

I suspect that it makes sense for this crate to be a superset of parsing and serialization, since the latter generally requires some level of owned types, whereas x509-parser can operate almost entirely over the serialized form (which is really nice!) - but I'm also not actually working on anything X.509-related in my day job, so I'm not likely to have dedicated time to spend developing this crate outside my own use-cases. I'm open to adding you as a contributor to this repository, but I'd also like to hear how you were envisaging potential collaboration.

As for the code itself, a good starting point would be figuring out and completing the DER serialization logic, so we at least provide a reasonable set of pieces from which others can build their own serializers. I want to make certificate serialization more usable that it currently is, but I also want to keep it pretty opinionated (i.e. in line with modern best practices, rather than supporting the full spectrum of serialization), so we should iterate on that.