>> If I pass in a STACK_OF(X509) *certs with only the signer's cert in it, and >> NULL for X509_STORE *st since it won't be used, then I think I should get >> the desired result, yes, at the cost of ocsp_find_signer(single-entry certs) >> and the internal creation/destruction of an unused X509_STORE_CTX. I'd have >> a small performance hit but it probably wouldn't be too bad. > > Probably the construction of that ctx is in the wrong place. It should > be later in the function. I can't imagine the ocsp_find_signer() hit is > too great.
Having tried this, I now see that my copying the structs from ocsp_lcl.h into the external code masked the fact that the external code is getting the signer's cert beforehand by directly accessing OCSP_BASICRESP->certs (and ->tbsResponseData) anyway, effectively doing what ocsp_find_signer() does. So it is clear that I will need to be rework this, potentially centred around OCSP_basic_verify(), while remaining ignorant of the signer cert. It would be nice, though, if the API provided a way to get the signer's certificate. There is OCSP_resp_get0_signature(), but that only returns the bit string. Comparable functions in other modules (eg: X509_get0_signature(), X509_REQ_get0_signature(), X509_CRL_get0_signature(), CMS_SignerInfo_get0_algs()) provide a way to get any combination of bit string, algorithm, and signer cert. Cheers, -Dave -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
