Re: technical question about RFC 6960

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]>:

> 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]> 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
> > _______________________________________________
> > pkix mailing list
> > [email protected]
> > 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