1 person found this helpful
Thank you for your post. The behavior was changed in 10.1.2 and 9.5 , to protect users from cases where the Trust Anchors get compromised. Although not encouraged, for users who want to revert to the old behavior , there is a preference provided - bRevCheckTrust . The details for the preference can be obtained from the Preference Reference guide. The guide can be downloaded from - http://kb2.adobe.com/cps/837/cpsid_83709.html
RFC 5280 does not preclude an application to check the revocation of a Trust Anchor. See following excerpt from the RFC-
When the trust anchor information is provided in the form of a certificate, the name in the subject field is used as the trusted issuer name and the contents of the subjectPublicKeyInfo field is used as the source of the trusted public key algorithm and the trusted public key. The trust anchor information is trusted because it was delivered to the path processing procedure by some trustworthy out-of-band procedure.
Thank you for your quick reply.
Could you please elaborate further about the details of this change?
Let me provide the following example:
- Alice got its certificate from CA Carl.
- Carl got its certificate from CA Carl Root.
- Carl uses OCSP as revocation mechanism, i.e. the certificate of Alice has an authority info access pointing to the OCSP responder of Carl.
- That OCSP responder uses a OCSP signing certificate issued by CA Berta.
- Berta got its certificate from CA Berta Root.
- Berta uses OCSP as revocation mechanism, i.e. the OCSP signer certificate used by the OCSP responder of Carl has an authority info access pointing to the OCSP responder of Berta.
- That OCSP responder uses a OCSP signing certificate issued by CA Berta Root.
Case 1: Only the certificate of Alice is marked as a trusted identity in Adobe Reader 10.1.2
- Am I right, that the trust status of Alice's certificate cannot be computed, since the Adobe Reader 10.1.2 cannot find a certificate path for Carl's OCSP signer certificate?
Case 2: The certificate of Alice as well as Carl's OCSP signer certificate are marked as trusted identities in Adobe Reader 10.1.2
- Does the implementation change in Adobe Reader 10.1.2 also affect the certificate path validation for Carl's OCSP signer certificate? I.e. does Adobe Reader 10.1.2 try to determine the revocation status for Carl's OCSP signer certificate?
Best regards, Gregor
- In Adobe Reader 10.1.1 , if you set the Trust at Carl RootCA and Berta CARoot, does the revocation check work? Your OCSP responder set-up does not conform to the standard set-up in rfc 2560. This set-up will only work only if you define a local configuration. Do you have local configuration set in Adobe Reader for this OCSP responder set-up ? For more information , See 'Workaround for self-signed OCSP responders' section in
-Is there a sample signed PDF that you can share with us ?
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
Thanks for your response. We are looking at your example. I shall get back to you soon .
Many thanks in advance, this would be very helpful!
Best regards, Gregor
Have you tried to set the preference bRevCheckTrust=0 ? Does that make your set-up work like 10.1.1 ?
yes, but in addition I had to change Adobe Reader's trust settings as follows (these settings were necessary in Adobe Reader < 10.1.2 as well):
- TC Trustcenter CA 7: PN is marked as trust anchor.
- TC Trustcenter DIR 39: PN is marked as trust anchor.
- Custom certificate preference to tell Adobe Reader to accept the OCSP responder signing certificate TC TrustCenter DIR 39:PN (cAuthorizedResponder set to 1).
Best regards, Gregor
I would like to come back on this issue:
Is there a chance (at least in upcoming versions of Adobe Reader) to find a configuration of Adobe Reader, which leads to a trusted certification path for my EE certificate (Test-Signaturdienst:PN), without using custom certificate preference?
Background: Most of the persons receiving a PDF document signed with my EE certificate do not have the chance to set custom certificate preferences since they use there Adobe Reader in a company environment and do not have adminstration rights on their computers.
Best regards, Gregor
Acrobat complies with RFC 2560 for processing the OCSP responses.The custom certificate preference is required in your scenario due to the PKI that the OCSP response has. This PKI hierarchy does not comply with the OCSP standard. Specifically-RFC 2560, Section 22.214.171.124 Authorized Responders.
This site to workaround self-signed OCSP certificates is no longer available: http://learn.adobe.com/wiki/display/security/Digital+Signatures+101#DigitalSignatures101-S ettinguprevocationchecking
Is there any chance to get the information there?, I'm following the guide 'OCSP responders: Determining if they are authorized to do rev checks', from acrobat_reader_security_9x.pdf
I'm setting the sURL and the cURLtoConsult entries in the registry to point to an internal OCSP instead of the OCSP in the AIA extension, it works as expected, but when I verify the signature the log shows a warning claiming that the OCSP respose was not signed by an authorized responder.
I'd like to review that document to check my configuration against it.
How about PDF signing and LTV in the example of Carl and Alice?
What informatione is added to the PDF/A?
Is it the response of Carl OCSP and Carl CRL?
Ist it the response of Alice OCSP and Alice CRL?
How does this work?