Re: technical question about RFC 6960

OCSP provides the status of one certificate.  So, two OCSP queries are needed in path A, one for the Intermediate A, and another for EndCert A.  The AIA extension in each of these certificates tells where to send the query.  I assume from the short description that you provided that at lease one of the AIA extensions is pointing to EndCert B as the OCSP responder.

Russ


> On Apr 28, 2020, at 10:33 AM, Tom Hans <[email protected]> wrote:
> 
> Dear Ladies and Gentlemen,
> 
> I was forwarded from the IETF Secretariat to this mailing list. I hope you can help me.
> Currently I have some technical issues regarding to RFC 6960 and maybe I just misunderstand the described standards.
> Therefore I kindly like to ask if someone could help me to understand if the scenario below is RFC conform or not.
> 
> I hope you will help me.
> 
> Kind regards,
> Tom Hans
> 
> 
> 
> Scenario:
> We have the following certificate chains given:
> Root CA A -> Intermediate A -> EndCert A
> Root CA B -> EndCert B
> 
> Now I check the revocation status of EndCert A using Windows certutil or Linux openssl with OCSP.
> If the full chain of EndCert A is existing I can send a valid OCSP request and get an OCSP response which contains "good".
> But even if the response contains "good" Windows and openssl tells me that the OCSP check is not good.
> And here is the interesting Part:
> The OCSP response is signed with the EndCert B and I do not see any kind of context between the two certificate chains. Moreover the response only contains the EndCert B and does not deliver the Root CA b which is not existing on my test environment.
> So in no case it would be possible to check EndCert B for validity.
> If I check the RFC 6960 I get stuck with 4.2.2.2.  Authorized Responders and I think it is not allowed to sign the OCSP response with EndCert B.
> _______________________________________________
> pkix mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/pkix