Subject: [pkix] CRL distribution points of CAs (and CRLDP extension)

From: [email-masked] (Martin Rex)
Date: Tue, 22 Jul 2014 15:21:38 +0200 (CEST)

I've recently been asked about an interop problem with revocation check
of certs for a particular public CA, and what I see "in the wild"
looks a little weird.  I know that revocation checking is broken,
but I hadn't expected it to be _that_ broken.

This was about some high assurance server CA, and the EE certs contain
two CRL distribution points (http-URLs) in a CRLDP extension of the
certificate.

The first URL results in one of two alternative results (looks like
a load-balanced hostname or host), the other results in just on CRL.

Test performed on Tue Jul 22 13:00 UTC

1st CRL-DP:

    CRLNumber    : 56       (16350 bytes)
        This Update:  Tue Jul 15 19:01:20 2014 (140715170120Z)
        Next Update:  Tue Jul 22 19:00:00 2014 (140722170000Z)
or
    CRLNumber    : 5B       (17155 bytes)
        This Update:  Sun Jul 20 19:00:58 2014 (140720170058Z)
        Next Update:  Sun Jul 27 19:00:00 2014 (140727170000Z)

2nd CRL-DP:

    CRLNumber    : 5C      (17260 bytes)
        This Update:  Mon Jul 21 19:01:07 2014 (140721170107Z)
        Next Update:  Mon Jul 28 19:00:00 2014 (140728170000Z)

The distribution of obviously outdated CRLs by the official CRL distribution
points is weird by itself.

But the serious problem I have with this CA is that all these CRLs
are unusable.  They all contain a bogus critical CRLDP extension, which
causes our software to properly reject them.  I've checked the Web-Site
of that CA, but they do not seem to publish the locations of *full* CRL
distribution points anywhere.

Scoped CRLs are pretty useless for scenarios that operate in a fashion
like a local OCSP responder, because the responder only gets to see
Issuer&Serial.

Searching for the CAs DName with Google, I found a an alternative
CRL download URL for that CA without critical CRL extensions (and twice
the size of the CRL) that works, but how are customers supposed to
find out such CRL distribution points for configuring local OCSP responders?

-Martin

---

From: Erwann Abalea <[email-masked]>
Date: Tue, 22 Jul 2014 15:56:09 +0200

Bonjour,

> but I hadn't expected it to be _that_ broken.

It can be worse; a Spanish CA had reduced-scope CRLs without a
corresponding critical extension, a Chinese CA uses CRLNumber for CRL
partitioning, ...

> two CRL distribution points (http-URLs) in a CRLDP extension of the

Is it 2 "DistributionPointName" of the same "DistributionPoint", or 2
different "DistributionPoint"?

>         Next Update:  Mon Jul 28 19:00:00 2014 (140728170000Z)

If the 2 URLs belong to the same "DistributionPoint", then it's clearly
invalid (RFC5280, section 4.2.1.13, the 2 "DistributionPointName" should
describe a mechanism to obtain the same CRL).
If the 2 URLs belong each one to a different "DistributionPoint", maybe one
of them is a deltaCRL?

> find out such CRL distribution points for configuring local OCSP

It's their problem.

-- 
Erwann.