Re: technical question about RFC 6960

So, it sounds like Mike St.Johns gave the right advice.  The trust anchor needs to be in the trust store for it validate.

Russ


> On Apr 30, 2020, at 6:36 PM, Tom Hans <[email protected]> wrote:
> 
> @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 protected] <mailto:[email protected]>>:
> 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] <mailto:[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] <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