Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)

From: Peter Gutmann <[email-masked]>
Date: Wed, 13 May 2015 10:23:20 +0000

Martin Rex <[email-masked]> writes:

>When you use the AIA OCSP or CRLDP information from a certificate during
>certificate path validation, you do this only after you have verified the CA
>signature on the certificate,

Possibly, but when you use the AIA CA information to find the CA cert to
validate the one you've got, you're using unvalidated data.

Also, OCSP has a great facility (serviceLocator) for an untrusted client to
tell the server to access any location the client tells it to [0].  It's a
great way to scan the CA's internal network, walk up the IP address range at
port 445 and time the responses.  I didn't try any further tricks, but if I'd
passed it on to some pen-tester friends I'm sure they could have had some fun
with the capability.

>but the issues that you listed do not make the OCSP responder location and
>CRLDP info within that certificate untrustworthy.

No, OCSP has its own built-in mechanisms for doing that.  In addition the CA
AIA is untrustworthy, because you need to process the cert and use the AIA in
order to verify whether the information that you've just acted on is legit.

Peter.

[0] Another one of the many "what *were* they thinking" things you can find by
    reading PKI RFCs.