Change in certificate validation algorithm in Adobe Reader 10.1.2

Question

Some experiments I have done with both Adobe Reader 10.1.1 and 10.1.2 show that their implemented algorithm vor validating the certificate of a signature is different:
In all versions of Adobe Reader up to and including 10.1.1 no revocation checking is performed for a certificate marked as a trust anchor.
In Adobe Reader 10.1.2 revocation checking is performed even if a certificate is marked as a trust anchor.
Since the latter behaviour is in conflict with international standards for certificate validation (RFC 5280, section 6.1), my questions are:
Has this shift in the implementation happened intentionally?
If yes, why?
/Gregor

Answer 1

Hi Jagriti,
sorry, it took some time to prepare things for this answer.
I have digged a bit deeper in my real world example: It uses a qualified EE certificate isssued by a German Trust Center supervised by the German Federal Net Agency (Bundesnetzagentur) - want I want to express here: It is not some self-signed anything, but a situation that will happen with almost each qualified EE certificate issued under German law.
You can find my real world example here, a PDF signed using such a qualified EE certificate (BTW: I cannot find a way to add files to my post, is there really no such mean in Adobe's forums?).
Additionally I have put together all certificates and CRLs depicted in the following graph into a ZIP-Archive, you can find it here.
Now, there are some awkward things with the structure of that PKI:
If you try to find a revocation status for Bundesnetzagentur's OCSP Service, you may get into a loop, since the signer certificate for that OCSP Service has a AIA certificate extension pointing to - well - the Bundesnetzagentur's OCSP Service (but this is not the problem I am facing at the moment - see below).
If you try to find a revocation status for the CRL issuer of Bundesnetzagentur's indirect CRL, you may face the same problem, since the CRL-DP certificate extension of the CRL issuer's certificate points to - well - the Bundesnetzagentur's indirect CRL (but this is still not the problem I am facing at the moment ;-).
The CRL-DP certificate extension (in all certificates shown in the graph above and depicted in blue) is missing the cRLIssuer field in the DistributionPoint, which is a MUST regarding to RFC 5280 if the DistributionPoint refers to an indirect CRL. Yes, and this is my problem at the moment - see below.
My current settings in Adobe Reader 10.1.2 are the following:
The Bundesnetzagentur's root certificate 12R-CA1:PN is marked as a trust anchor.
I am using a custom certificate preference to tell Adobe Reader to accept the OCSP responder signing certificate  TC TrustCenter DIR 39:PN (cAuthorizedResponder set to 1).
Validation in my Adobe Reader 10.1.2 currently does the following:
Find a valid path for Test-Signaturdienst:PN ... fine.
Check revocation status for Test-Signaturdienst:PN ... fine (using the OCSP responder pointed to by the AIA of the certificate).
Check revocation status for TC TrustCenter DIR39:PN ... fails (using the CRL-DP pointing to the Bundesnetzagentur's indirect CRL).
My question for the moment: Is there a chance to let Adobe Reader 10.1.2 accept Bundesnetzagentur's indirect CRL although the CRL-DP in TC Trustcenter DIR 39:PN is missing the cRLIssuer field?
My question for later: Is it an issue inside Adobe to support the validation of documents signed with a qualified certificate issued under German law despite the awkward construction of Bundesnetzagentur's PKI (Germany is a market with 80 million people)?
Best regards, Gregor