One thing I am considering here (and for y'all to know, this is a major API addition and won't go in until after the soon upcoming openbsd release cycle happens). is that the way we have done this in the past with libtls is to just - do the thing in the handshake and keep the data hidden in the (private) conn_info stucture and then accessible to the user via a tls_ funciton call.
What strikes me as the most sensible thing to do for staping is to just do it in the handshake, and then record the status is the conn_info.. So if stapling is provided the handshake succeeds if the stapled response checks out, fails if it does not with a reason, and if it is not present or the certifiacat status is indeterminate we then have any designated ocsp responders from the certificate available to the application to then go make their own ocsp calls directly. On Fri, Jul 8, 2016 at 2:40 PM, Marko Kreen <[email protected]> wrote: > 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 >
