Re: technical question about RFC 6960

What is in the AIA extension of EndCert A?

> On Apr 29, 2020, at 2:17 AM, Tom Hans <[email protected]> wrote:
> 
> Hello,
> 
> thank you for your answers.
> 
> I know that the OCSP response cannot be validated because I do not have the Root CA B installed.
> If I do this the response is validatable.
> 
> What I like to know is if this is RFC conform?
> In RFC 6960 section 4.2.2.2. there are mentioned the following three possibilities:
>    1. Matches a local configuration of OCSP signing authority for the
>       certificate in question, or
> 
>    2. Is the certificate of the CA that issued the certificate in
>       question, or
> 
>    3. Includes a value of id-kp-OCSPSigning in an extended key usage
>       extension and is issued by the CA that issued the certificate in
>       question as stated above.
> 
> Point 2 and 3 are not used because the certificate in request is issued by Root CA A and point one is not really clear for me.
> 
> 
> Kind regards,
> Tom
>  
> 
> Am Di., 28. Apr. 2020 um 20:37 Uhr schrieb Michael StJohns <[email protected] <mailto:[email protected]>>:
> I'm also assuming from the description that you don't actually have a 
> trust anchor (e.g. Root CA B) for the B chain installed and my guess is 
> that's ultimately the problem leading to the OCSP check failing.   Mike
> 
> 
> On 4/28/2020 1:43 PM, Russ Housley wrote:
> > 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] <mailto:[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] <mailto:[email protected]>
> >> https://www.ietf.org/mailman/listinfo/pkix <https://www.ietf.org/mailman/listinfo/pkix>
> > _______________________________________________
> > pkix mailing list
> > [email protected] <mailto:[email protected]>
> > https://www.ietf.org/mailman/listinfo/pkix <https://www.ietf.org/mailman/listinfo/pkix>
> 
> 
> _______________________________________________
> pkix mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/pkix <https://www.ietf.org/mailman/listinfo/pkix>
> _______________________________________________
> pkix mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/pkix

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix