Default certificate policies for DoD Root CA 2?

Question

I receieved a PDF signed with a valid certificate issued under the chain DoD Root CA 2 > DOD CA-27. The signing cert was a soft-cert with certificate policies 2.16.840.1.101.2.1.11.5 (medium assurance) and 2.16.840.1.101.2.1.11.18 (medium 2048 assurance). The signature failed to validate ("The selected certificate path has errors: Invalid policy constraint") and it looks like the root cause is that Reader XI ships with 3 certificate policies (2.16.840.1.101.2.1.11.4, 2.16.840.1.101.2.1.11.9, and 2.16.840.1.101.2.1.11.19) defined for DoD Root CA 2 that don't include either of the policies in the signing cert.
It's possible to modify the policies for DoD Root CA 2 so that the signing cert is accepted, but it's a pain to explain to users and doesn't promote confidence in the signature.
Is there a better way to resolve this problem?
Who sets the default certificate policies and why would they not match the actual DoD PKI issuance policies?

Answer 1

Certificate policies are specified in trusted identity along with trust. Some certificate authorities contract with Adobe to include their trusted root certificates in Adobe-sponsored list, which Acrobat/Reader may periodically download and update from Adobe server. Each certificate authority specifies which certificate policies to include in their certificates. So in the case of "DoD Root CA 2" it is DoD that sets certificate policies for their certificates and specifies Policy Restrictions in this trusted root identity when it is included in the Adobe-sponsored list.
As to why DoD issues signing certificates with policies other than those defined in "DoD Root CA 2" trusted root included in the Adobe-distributed list, I can only speculate that perhaps DoD has some internal mechanism of distributing trust lists, like GPO-controlled, and that the ones that they distribute internally may indeed have certificate policies in the signer certificate in the PDF that you received. The goal here is to restrict which document recipient may get a valid signature.
Of course, one can go to Acrobat UI and change the Policy Restrictions, but this requires some work and knowledge how to do that.
Some organizations distribute internally different trust lists to different divisions, so that only signatures with Policy Restrictions specified for a specific division get validated as Valid out-of-the-box, but not when the same signature is validated in a different division. Adobe-distributed trust list contains only Policy Restrictions applicable to everybody.