On 31/10/17 17:30, Dave Coombs wrote: > Hi Matt, thanks for your response. > >>> Is the correct solution to use OCSP_basic_verify(), which feels like >>> overkill for my needs (the code in question is *part of* our own >>> path-validation routine), or might there be some other way? >> >> Can you use OCSP_basic_verify() passing in OCSP_NOVERIFY in the final >> "flags" argument? This basically finds the signer certificate and >> verifies the signature using OCSP_BASICRESP_verify(), but skips all the >> chain validation bit. > > 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. > > The alternative would be to change the OCSP_BASICRESP_verify() macro into an > externally available function, and then both it and OCSP_basic_verify() could > call the former macro, suitably renamed and internally scoped. Clearly I'd > be happy with that, though I understand if you don't want to go that route. I did consider it, but I'm not especially keen. I think the intended application interface here is to use OCSP_basic_verify(). OCSP_BASICRESP_verify() should probably have never been exposed in the first place. Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
