Subject: [pkix] Use of CRL IssuingDistributionPoint extension by public CAs

From: [email-masked] (Martin Rex)
Date: Tue, 21 Apr 2015 20:16:27 +0200 (CEST)

I'm encountering interop problems with the CRL-based revocation
information of a public CA, and to me it appears as if that public CA
might have misunderstood the applicable PKIX specification.

The public CA is including two http-URLs for CRL download in
an CRL Distribution Point extension of the certificates it issues
(that is OK and useful).

The two CRL distribution points currently distribute two different CRLs
(difference = 1 day, about 11 revocations per day), and both CRLs
contain a critical IssuingDistributionPoint CRL extension, which
makes both CRLs incomprehensible to a perfectly compliant RP that
does not implement this critical CRL extension.

The difference between the CRLs seems to be only the age (they have
the same CRL number, and the older of the two CRLs seems to only be
lacking the most recent revocations (as mentioned above, about 11).

I'm wondering whether the CRLs are *not* really scoped, and the inclusion
of the critical IssuingDistributionPoint CRL extension is based on a
misunderstanding of the PKIX specification.  The CA ought to be omitting
the IssuingDistributionPoint extension from its CRLs, so that these
become usable to all "compliant RPs".  The CA might be erroneously assuming
that CRLs pointed to by CRL DistributionPoint certificate extension
would have to include a critical IssuingDistributionPoint CRL extension.
I am not aware of any such requirement (and such a requirement would be
stupid, given that a critical IssuingDistributionPoint CRL extension
make a CRL immediately unusable for the general RP).

I was asked about the same interop problem about 9 months ago.  Back then,
I googled for other CRL distribution points with unscoped CRLs from that
CA, and google found be a download URL for that (up-to-date, same
issuer DName, same authorityKeyIdentifier).  Back then, the CRLs with
and without critical IssuingDistributionPoint CRL extension had the same
size & content.

Today I can still obtain that _unscoped_ CRL from the unpublished URL
(it is current, with same issuer DName and authorityKeyIdentifier),
but it only has about half the size of the scoped CRLs (i.e. it has
the same creation date as the newer of the scoped CRLs, but does not
show any of the 30 revocations of the past 3 days).

To me, this latter behavioiur just doesn't make sense.  The download URLs
in the certificate CRL Distribution Point extension are plain http,
so a man-in-the-middle could substitute the scoped CRL with the
unscoped CRL during download, and every PKIX-compliant RP would have
to accept that unscoped CRL (current, same issuer, same AKID).

Is this a general problem of public CAs that they're erroneously
issuing scoped CRLs (that aren't really scoped and that ought not to
carry a critical IssuingDistributionPoint CRL extension in the first place)?

-Martin

---

From: Erwann Abalea <[email-masked]>
Date: Wed, 22 Apr 2015 10:35:10 +0200

Bonjour Martin,

> lacking the most recent revocations (as mentioned above, about 11).

If the thisUpdate fields also differ by 1 day, it's a compliant scope
limitation, IMO. Compliant doesn't mean it's unquestionable. The 1 day
difference for thisUpdate fields should prevent the case "The revocation
date should not precede the date of issue of earlier CRLs" found in X.509
8.5.2.4 and RFC5280 5.3.2.

> make a CRL immediately unusable for the general RP).

Let's assume this CA has a reason to scope those CRLs that way. Maybe the 2
URLs have different usage costs, maybe they want to sell some certificates
with more up-to-date revocation information. That's weird, but possible.
Removing the IDP changes the scope of the CRLs, and then they must have the
same content (CRLNumber MUST be taken from the same sequence, for example).

> show any of the 30 revocations of the past 3 days).

That becomes interesting, in a non-compliant and dangerous way, since a
substitution attack can occur.

> carry a critical IssuingDistributionPoint CRL extension in the first

It's not a *general* problem. But it happens, yes. You wrote it's a public
CA, could you share more detailed information? It could be discussed on
moz.dev.sec.pol, or at CABForum level.

-- 
Erwann.