Subject: [pkix] technical question about RFC 6960

From: Tom Hans <[email-masked]>
Date: Tue, 28 Apr 2020 16:33:51 +0200

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.

---

From: Russ Housley <[email-masked]>
Date: Tue, 28 Apr 2020 13:43:54 -0400

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-masked]> wrote:
> 
> 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:
> 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.
> 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.
> 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-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Michael StJohns <[email-masked]>
Date: Tue, 28 Apr 2020 14:36:45 -0400

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

---

From: Tom Hans <[email-masked]>
Date: Wed, 29 Apr 2020 08:17:18 +0200

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

> > 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
> >
> >
> >> 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:
> >> If the full chain of EndCert A is existing I can send a valid OCSP
> request and get an OCSP response which contains "good".
> >> 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
> >> 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.

---

From: Russ Housley <[email-masked]>
Date: Wed, 29 Apr 2020 10:34:12 -0400

What is in the AIA extension of EndCert A?

> On Apr 29, 2020, at 2:17 AM, Tom Hans <[email-masked]> wrote:
> 
> Hello,
> 
> I know that the OCSP response cannot be validated because I do not have the Root CA B installed.
> In RFC 6960 section 4.2.2.2. there are mentioned the following three possibilities:
> 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-masked] <mailto:[email-masked]>>:
> >> On Apr 28, 2020, at 10:33 AM, Tom Hans <[email-masked] <mailto:[email-masked]>> wrote:
> >>
> >> So in no case it would be possible to check EndCert B for validity..
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/pkix <https://www.ietf.org/mailman/listinfo/pkix>
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/pkix <https://www.ietf.org/mailman/listinfo/pkix>
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/pkix <https://www.ietf.org/mailman/listinfo/pkix>

---

From: Peter Bowen <[email-masked]>
Date: Wed, 29 Apr 2020 07:56:45 -0700

> 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.

There are two different architectures here.  Points two and three
cover "first party" status checking - asking the issuer of the
certificate or someone authorized by the issuer to tell you the
status.  Point on covers "third party" status checking - asking an
unrelated party about the certificate.

Comparing this to the process of driver's licenses in the US, you can
ask the state government department or agency that issues licenses
about the status of a license.  That is point 2.  You could also ask a
police department about the license and also ask the police for a
certificate that they are authorized to provide license status.  That
is point 3.  However a license is also frequently used as
identification.  A private club could have a membership list.  You
could ask the club secretary whether license matches someone on the
membership list.  It doesn't necessarily tell you that the person is
authorized to drive a car, but they can tell you if the person is
authorized to enter the clubhouse.  That is point 1.

You hit a OCSP responder that is covered under point 1.  Unless you
have out of band knowledge that the answers it is providing are
relevant to your use case, then having B tell you about status of
things A issues probably is not what you want.

Thanks,
Peter

---

From: Tom Hans <[email-masked]>
Date: Thu, 30 Apr 2020 08:58:09 +0200

@Russ
The AIA extension of EndCert A contains:
[1]Authority Info Access
     Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
     Alternative Name:
          URL=https://pki.spi-cloud.com/issuer
[2]Authority Info Access
     Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
     Alternative Name:
          URL=http://ocsp.spi-cloud.com/status/
RI:http://ocsp.spi-cloud.com/status/

@Peter thank you for your explanation. This helps a lot :)
So the only "out of band" knowledge I would have is that I saw the signer
through Wireshark nothing else.
Consequently this is a bad behavior of the CA itself.

Am Mi., 29. Apr. 2020 um 16:56 Uhr schrieb Peter Bowen <[email-masked]>:

> > 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.
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 30 Apr 2020 09:31:42 -0400

Tom:

Since these details do not align with the names used in your earlier message, it is not as helpful as I expected.

Russ

> On Apr 30, 2020, at 2:58 AM, Tom Hans <[email-masked]> wrote:
> 
> @Russ
>      Access Method=Certification Authority Issuer (1.3..6.1.5.5.7.48.2)
>      Alternative Name:
>           URL=https://pki.spi-cloud.com/issuer <https://pki.spi-cloud.com/issuer>
> [2]Authority Info Access
>           URL=http://ocsp.spi-cloud.com/status/ <http://ocsp.spi-cloud.com/status/>
> RI:http://ocsp.spi-cloud.com/status/ <http://ocsp.spi-cloud.com/status/>
> 
> 
> So the only "out of band" knowledge I would have is that I saw the signer through Wireshark nothing else.
> Am Mi., 29. Apr. 2020 um 16:56 Uhr schrieb Peter Bowen <[email-masked] <mailto:[email-masked]>>:
> On Tue, Apr 28, 2020 at 11:17 PM Tom Hans <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Hello,
> >

---

From: Tom Hans <[email-masked]>
Date: Fri, 1 May 2020 00:36:39 +0200

@russ

Excuse me I forgot to mention that the URLs are used for both CAs, root A
and B.

Both roots do belong to the same company.

Am Donnerstag, 30. April 2020 schrieb Russ Housley <[email-masked]>:

> Tom:
>
> Since these details do not align with the names used in your earlier
> message, it is not as helpful as I expected.
>
> Russ
>
>
> Am Mi., 29. Apr. 2020 um 16:56 Uhr schrieb Peter Bowen <[email-masked]
> >:
>