On Wed, Jul 06, 2016 at 08:30:23PM +0900, kinichiro inoguchi wrote: > Hi, I have 2 questions about this implementation. > > 1) Can the OCSP client put multiple certificates to check in the request ? > like this. > ---------------------------------------------------------------- > $ openssl ocsp -reqin ocsp_req.der -req_text > OCSP Request Data: > Version: 1 (0x0) > Requestor List: > Certificate ID: > Hash Algorithm: sha1 > Issuer Name Hash: 3429CF3BC59A76F61C3296E597B1F9D5F4A52B3A > Issuer Key Hash: 68DBFBB578936A6704433C981F7ECE61819838C7 > Serial Number: 03 > Certificate ID: > Hash Algorithm: sha1 > Issuer Name Hash: 3429CF3BC59A76F61C3296E597B1F9D5F4A52B3A > Issuer Key Hash: 68DBFBB578936A6704433C981F7ECE61819838C7 > Serial Number: D0F00ED53778C7C5 > Request Extensions: > OCSP Nonce: > 04104C65A6FA1D4839916C3B8C18A4EF2E5D > ----------------------------------------------------------------
No. Current goal is to get stapling working, which deals with one cert at a time. Requesting multiple certs with one request seems dubious even in general (rfc6961) case as each cert may potentially have different responder. The API needs to export multiple (ocsp_url, request_blob) pairs then. But there is option to embed multiple certs into one request_blob if they use same responder, as optimization. > 2) Is it available signing to OCSP request by client ? > I indicate this https://tools.ietf.org/html/rfc6960#section-4.1.2 > "The requestor MAY choose to sign the OCSP request." > > These 2 functionality might NOT need when we're doing OCSP stapling. > (server cert to verify by OCSP stapling will be always single ...) No. It's possible to expose it as option, but why? Btw, I tried to use OCSP_request_add1_nonce() to add unique nonce to reqests, for replay protection. Common OCSP responders reject such requests. I guess both on performace and security grounds, to have dumb responders that do not have access to signing keys. So I doubt requiring signed requests is common. -- marko
