Open
Conversation
atreiber94
force-pushed
the
feature/multiple_ocsp_responders
branch
from
5b9c3aa to
ad78ab4
Compare
reneme
reviewed
Jan 12, 2026
atreiber94
force-pushed
the
feature/multiple_ocsp_responders
branch
from
ad78ab4 to
80da263
Compare
reneme
reviewed
Jan 12, 2026
atreiber94
force-pushed
the
feature/multiple_ocsp_responders
branch
from
80da263 to
1f55d01
Compare
Collaborator
Author
|
Re-based onto the latest changes of #5188 which should hopefully turn the CI green. |
atreiber94
force-pushed
the
feature/multiple_ocsp_responders
branch
from
1f55d01 to
d4f21e0
Compare
atreiber94
force-pushed
the
feature/multiple_ocsp_responders
branch
from
d4f21e0 to
40273b6
Compare
Namely: * botan_x509_cert_view_binary_values * botan_x509_cert_view_string_values * botan_x509_crl_view_binary_values * botan_x509_crl_view_string_values This allows fetching standard information from X.509 objects such as the serial number of both a certificate and a CRL but also more specific information like OCSP responder URLs. Some getter types may have more than one value. For such cases, the getters have an index parameter to enumerate all elements.
These functions are currently implemented by trivially counting the number of elements their associated enumerator functions are actually producing. Given that most values are anyway viewed straight from the C++ objects' memory, the overhead should be negligible. The main advantage of this approach is its minimal maintenance burden.
Owner
|
Needs another rebase |
Before, only a single OCSP responder URI was parsed and exposed via AIA extension and Botan::X509_Certificate. These now handle multiple OCSP responder URIs as per RFC 5280. Add corresponding test cases. Deprecate the single OCSP responder constructors and accessors. Note that the support for multiple OCSP responders is not propagated to `Botan::OCSP` methods yet.
reneme
force-pushed
the
feature/multiple_ocsp_responders
branch
from
40273b6 to
59780a1
Compare
Collaborator
|
Rebased again. We'll rebase once more once #5188 is in, because this still stacks onto it. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This addresses one of the limitations hindering integration of Botan's X509 parsing to strongSwan (see #5219), namely multiple OCSP responder URIs.
Before,
ocsp_responder()of the AuthorityInformationAccess extension or ofX509_Certificatewould return a single URI, even if the certificate parsed contains multiple URIs as OCSP responders.The single responder interfaces have been deprecated (e.g. it is not clear what "a OCSP responder" means in the now-deprecated methods - in my tests, it would return the last URI). The legacy interface is kept by returning the first URI (or the empty string if there are no URIs).
PR Dependencies
This is based on #5188 so I could test the FFI integration (also directly against the strongSwan X509 test suite).
OCSP
check_onlineThe changes here only expose multiple OCSP responder URIs to certificate parsing as well as the constructors/accessors of the AuthorityInformationAccess extension and
X509_Certificate. I did not include this into the OCSP features likeOCSP::check_onlinesince this code does not appear to be well tested (we should rather discuss what to do with this code going forward).