FFI: Enumeration of entries in an X.509 CRL #5220
Conversation
reneme
force-pushed
the
feature/ffi_list_crl_entries
branch
from
7c8cda1 to
54f1b75
Compare
reneme
force-pushed
the
feature/ffi_list_crl_entries
branch
from
54f1b75 to
b3ac052
Compare
randombit
left a comment
randombit
left a comment
There was a problem hiding this comment.
lgtm
I don't particularly like the API but the alternatives I can come up with are more work on our end for little to no benefit for end users so (shrug)
reneme
force-pushed
the
feature/ffi_list_crl_entries
branch
from
b3ac052 to
14b1e00
Compare
| /** | ||
| * View the serial number associated with the given CRL @p entry. | ||
| */ | ||
| BOTAN_FFI_EXPORT(3, 11) | ||
| int botan_x509_crl_entry_view_serial_number(botan_x509_crl_entry_t entry, botan_view_ctx ctx, botan_view_bin_fn view); |
There was a problem hiding this comment.
Using the same argument as in #5221 regarding OIDs and also this explicit remark by @arckoor, we should consider adding an "overload" to export the CRL entry serial as a botan_mp_t object. I.e. provide botan_x509_crl_entry_serial_number(..., botan_mp_t* serial) along with this byte-oriented view function.
There was a problem hiding this comment.
There may be an argument for also adding an MPI view function for the existing X509 cert serial
There was a problem hiding this comment.
I'll combine those in a follow-up PR after merging the current stack of changes.
This error may be returned when a user requests an enumerable value at an index that is out of range of the available values.
reneme
force-pushed
the
feature/ffi_list_crl_entries
branch
from
14b1e00 to
bdcfce9
Compare
| * the CRL entry list. | ||
| */ | ||
| BOTAN_FFI_EXPORT(3, 11) | ||
| int botan_x509_crl_entries(botan_x509_crl_t crl, size_t index, botan_x509_crl_entry_t* entry); |
4 participants
This adds
botan_x509_crl_get_entriesthat allows listing individual CRL entries along with the affected certificate serial, the revocation time and reason.The serial number is retrieved as a big-endian binary encoding into a user-provided buffer. Using the view-callback style doesn't strike me as feasible or ergonomic for this. One would either have to introduce an additional function just for the serial or mixing out-params with view invocation in a single function call.