“JITC certified,” you say…what’s that? JITC stands for the US Department of Defense’s Joint Interoperability Test Command, which carries out extensive work on software and other systems intended to be used by the US military for mission critical purposes.
In this specific instance, Adobe Acrobat and Reader X have been certified by JITC for their compliance with the DoD’s application requirements for Public Key Enabled services, e.g digital signatures. The testing included intensive, comprehensive evaluations of Acrobat and Reader’s capabilities in:
- Certificate operations
- Signature and certificate status validation
- Path processing and validation
- Configuration and documentation
Adobe is proud to note that we have consistently been certified for JITC compliance in every version of Adobe Acrobat and Reader back to version 7 back in 2006.
Click here for a link to the official JITC list of software and solutions that have been tested for Public Key Enabled compliance.
The Dutch government today announced that DigiNotar’s subordinate Certificate Authorities (subCAs) under the Staat der Nederlanden root certificates will be revoked next Wednesday, September 28th. This follows on the Dutch government’s removal of trust from DigiNotar, DigiNotar’s removal from the Netherlands Trust List, and the company’s announcement of bankruptcy proceedings.
As discussed earlier on this blog, the Adobe Approved Trust List (AATL) has been updated to remove the DigiNotar Qualified CA root certificate. Users of Adobe Reader and Acrobat X (version 10.x) will be automatically updated to this list.
To be sure your copy of Adobe Reader or Acrobat will get the update, you can force a download of the AATL. Go to Preferences->Trust Manager->Automatic Updates and click the Update Now button. Also, be sure the “Load trusted root certificates from an Adobe server” option is checked.
A future product update of Adobe Reader and Acrobat version 9.x will enable dynamic updates of the AATL. In the meantime, users of Adobe Reader and Acrobat 9 can manually remove the DigiNotar Qualified CA using instructions provided in the blog post.
Also note that the Dutch government has published a document regarding the impact of the removal on signed PDFs. That document (in Dutch and English) can be found at the links below:
This posting is provided “AS IS” with no warranties and confers no rights.
In the past two weeks, it has come to light that Dutch certificate authority DigiNotar suffered a serious security breach in which a hacker generated more than 500 rogue SSL certificates and had access to DigiNotar’s services, including many that were relied upon specifically by the Dutch government for key citizen and commercial services. The full extent of the attack is still not clear.
Last week, many of the major browser vendors removed DigiNotar certificates from their list of trusted certificates, and in turn, the Dutch government renounced trust in DigiNotar and took over certificate operations at the company.
What Does This Mean for Adobe Customers?
The DigiNotar Qualified CA root certificate is part of the Adobe Approved Trust List (AATL) program, which we have mentioned in this space on multiple occasions. The AATL is designed to make it easier for authors to create digitally signed PDF files that are trusted automatically by Adobe Reader and Acrobat versions 9 and above, and includes many certificates from around the world.
While Adobe is not aware of any evidence at this time of rogue certificates being issued directly from the DigiNotar Qualified CA root in particular, an official report by Dutch security consultancy Fox-IT stated that there was evidence of the hacker having access to this CA, thus possibly compromising its security. (The rogue certificates known today are SSL certificates originating from the DigiNotar Public CA.)
Adobe takes the security and trust of our users very seriously. Based on the nature of the breach, Adobe is now taking the action to remove the DigiNotar Qualified CA from the Adobe Approved Trust List. This update will be published next Tuesday, September 13, 2011 for Adobe Reader and Acrobat X. We have delayed the removal of this certificate until next Tuesday at the explicit request of the Dutch government, while they explore the implications of this action and prepare their systems for the change.
Just last night, we announced the availability of updates to both Adobe Acrobat and Reader, bringing them up to version 10.1. Along with a significant list of vulnerability mitigations, these updates also bring with them substantial changes to the secure operation of Acrobat on Windows, and to the digital signature functionality across platforms.
First, Acrobat 10.1 on Windows now features the same Protected Mode operation as Adobe Reader X, protecting users from malicious PDFs. Additional information on Acrobat’s implementation of sandboxing is available on the Adobe Secure Software Engineering Team’s (ASSET) blog. For those savvy in digital signatures, note that Protected Mode (on both Acrobat and Reader) may impair the installation of PKCS#11-based tokens. Refer to the simple instructions here for a workaround.
And if you’re like me and love the nitty-gritty details of digital signatures, you’ll probably appreciate the other signature-specific changes in 10.1…
Version X of Adobe Acrobat and Adobe Reader include the RSA BSAFE Crypto-C ME 18.104.22.168 encryption module with FIPS 140-2 validation certificate #1092. To enable FIPS mode in Acrobat and Reader X and restrict document encryption and digital signatures to the FIPS approved algorithms (AES/RSA/SHA) in this library, please refer to Section 6.1.11 of the Acrobat Digital Signature Admin Guide.
Information on FIPS compliance in Acrobat and Reader 9….see this post.
Today, Adobe pushed out yet another update to its certificate trust program implemented in Adobe Reader and Acrobat. The AATL program, launched in 2009, makes it easier for users to view and rely on digitally signed PDFs by automatically displaying a green checkmark for those signature credentials which meet higher assurance requirements when opened in Reader and Acrobat 9 and X.
The update today included the Columbian A.C. Raiz Certicamara S. A. root certificate for Acrobat and Reader X.
Adobe released updates of all of the LiveCycle components when we released our “ES2″ version in November 2009. As a part of this we made some significant strides to expand how you can integrate our product suite into other directory, identity management, and authentication systems.
I’d like to take this opportunity to explain some of what is new, as well as show you several videos that go into each area in more depth.
First, our integration with ActiveDirectory and LDAP directories executes substantially faster, as we have optimized the system to only pick up records that have changed recently. More info:
Second, our integration with Smartcards and PKI certificates for strong authentication is much more flexible, and supports many more types of certificates. More info:
Third, several customers have asked us to query one directory for user information, but integrated with a second instance for high performance authentication. We’ve listened and now support this — more info:
Finally, all of our web- and Flex-based components now support SAML-based federated identity for authentication. Technically, this means that LiveCycle is substantially more flexible in terms of the Single-Sign-On (SSO) and authentication facilities that be used. In practice this means that it is very easy for you to integrate LiveCycle into your processes for interacting with customers and engaging with citizens without deploying additional identity provisioning or management software. More info:
By now, you’ve surely heard the news about the new European standard for PDF Advanced Electronic Signatures (PAdES) which formalizes how digital signatures in PDF can comply with the European requirements for electronic signatures.
However, there are five parts to the standard, and they all deal with terminology that may not be familiar. Don’t worry….you’re not alone. A new website has been set up to answer frequently asked questions on PAdES.
We’ve discussed the legal validity of electronic signatures and digital signatures in this blog in the past. While a concurrence of laws worldwide point to general acceptance of electronic signatures as legally binding, there are a number of nuances that need to be taken into account when dealing with the identity and evidentiary elements of those electronic signatures, especially as it relates to how they’ll stand up longer term in court.
An event to be
held on March 1, the first day of the RSA 2010 Conference, will be dedicated to these questions.