Well, it would help to attach the patch :) On Thu, Oct 01, 2015 at 10:43:51PM +1000, Fraser Tweedale wrote: > Hi all, > > The attached patch makes sure that the right authority is used to > create OCSP responses. Note that OCSP requests may ask about certs > from more than one issuer - even though this is crazy the heuristic > used is to simply use issuer of the first CertID in the request. > > Note that OCSP response validation of certificates issued by sub > -CAs > currently fails due to a separate issue[1]. > > [1] https://fedorahosted.org/pki/ticket/1632 > > _______________________________________________ > Pki-devel mailing list > Pki-devel(a)redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel _______________________________________________ Pki-devel mailing list Pki-devel(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-devel

On Mon, Feb 22, 2016 at 12:02:49PM -0500, Ade Lee wrote: > Couple of comments .. > > 1. First off, there is a typo in the comments on the method. I > think > you mean .. > > 3. Either we WERE the issuing CA, or we .. rather than "were > not" > > 2. We can go with the heuristic of taking the first CA, but I do > not > think we should leak information about other certs if the CA is > incorrect. The way the code is now, we will still return data on > whether a particular cert serial number is valid -- even if that > cert > was not issued on that CA. > > A simple solution is to simply pass code to processRequest() to > ignore > the request if the issuer is not correct and not return a response > for > that request. > RFC 6960 says: The response MUST include a SingleResponse for each certificate in the request. So the best we can do is return 'unknown' status in this case. I've attached updated patch 0051-2 - the only change is the comment fixup - and two new patches: 0074 refactors digest lookup and adds support for SHA-2 algos, and 0075 changes the OCSP behaviour to return 'unknown' cert status for certs that from a different issuer. Cheers, Fraser