FFI APIs for X.509 are insufficient

[randombit]

For whatever reason we expose CRLs as a type, but they are barely usable. You can parse a CRL, but can't even properly examine it, verify it, etc.

randombit/botan-rs#95

Also we don't support OCSP, or certificate stores (eg accessing the system cert store, creating a new store, ...) which would be pretty critical for most real world usages.

[reneme]

Perhaps this is another recent request that would be in scope of this ticket.

[BryanJacobs]

It doesn't appear to be possible to read extension data from an X.509 certificate via the FFI APIs.

It would be nice if the ability to read an extension's value (as bytes) by its OID were exposed. Otherwise any application dealing with certificates having payload-carrying extensions is out of luck.

[ldillinger]

I am interested in tackling this issue, since I am working on developing modern Haskell bindings to the Botan library, and X509 support is a large part of my intended effort. I would like to develop a more fleshed-out C/FFI- compatible suite of functions for the X509 protocol, and would like to contribute the resulting work back upstream to the parent Botan library, here. That means writing code with this goal / issue in mind.

So far, I have just started exploring the issue, and it will require a bit of effort on my part, as it has been about 10 years since I last directly used C++ in any significant fashion (so I may have some questions and need some help), but Botan is quite legible, and I see no obvious blockers.

Right now, I am focused on implementing Certificate Authority and Certificate Signing Requests, which I am using as a general test case and refresher to get back into C++. I don't have any code to contribute yet, but I will update this thread when there is something to report.

[lieser]

@ldillinger A little off topic, but wanted to let you know that we try to keep an overview of language bindings at https://github.com/randombit/botan/wiki/Language-Bindings. Don't know what state your bindings are already in, but probably makes sense to add it to that wiki page at some point.

[ldillinger]

I have been making some aggressive strides in expanding the X509 FFI to handle more than read-only certificates and revocation lists; you can check out my fork to see how things are coming along.

It's a bit of a mess, but I've made a lot of progress towards enabling create-read-write functionality for:

• Self-signed certificates
• Certificate signing requests
• Certificate authorities
• Certificate revocation lists
• Certificate stores

This should be a big step forwards; It's not ready for a PR yet, but I'd appreciate getting eyes on what I've done so far, to begin getting some feedback. Although I am getting comfy with C++ again, it has been some time since and there are a few aspects of modern C++ that I am still getting used to, and so I wish to avoid making any assumptions. I have been writing some unit tests on my (Haskell) side of the FFI to check that the functions have been bound properly, and so far things seem to be working.

Areas of concern are:

• Lifetime / ownership: I want to make sure that I am
  • A few functions still use shared_ptr, but the FFI is geared towards unique_ptr
• Returning jagged arrays through the C FFI
• Question of correct string encodings
• I am using uint64_t for x509 time (seconds since epoch)
• I am using return-values-first style, eg func(output* outArg, input inArg,...)

Overall, I have tried to stay consistent with my conventions, while following existing FFI conventions if possible - it is not always possible to do so as the FFI does have many idiosyncracies, and I think it would be beneficial long term to standardize the FFI a bit - but that is out of my scope for the moment :)

You can follow along the devlog if you want to see more about how its going.