Re: technical question about RFC 6960

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 protected]> wrote:
> 
> @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 <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/ <http://ocsp.spi-cloud.com/status/>
> RI:http://ocsp.spi-cloud.com/status/ <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 protected] <mailto:[email protected]>>:
> On Tue, Apr 28, 2020 at 11:17 PM Tom Hans <[email protected] <mailto:[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.
> 
> 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
> _______________________________________________
> pkix mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/pkix

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