When it comes to digitally signing documents, public trust is essential. You want your signature to be immediately recognized and validated by the document software so recipients don’t see any error messages and can trust your signature.

Example of a non-trusted digital signature in Adobe Reader.

Example of a trusted digital signature in Adobe Reader.

How Does Document Software Know Which Signatures to Trust?

Whether your signature is trusted or not basically boils down to whether your signing credential (i.e. Digital Certificate) was issued by a Certificate Authority (CA) that is trusted by the software. More specifically, the CA’s root needs to be in the software’s trust/root store, often referred to as trust anchors. If the root is in the store, any signatures applied with the CA’s certificates will be automatically validated and trusted.

Adobe Root Store and Programs

Given the ubiquity of its document software (e.g. Reader, Acrobat, etc.), it shouldn’t be a surprise that Adobe is an essential root store for CAs offering document signing credentials. Organizations looking to adopt digital signatures need them to be trusted in the most popular software. Microsoft is another major entity, with its Microsoft Root Trust List, but for the sake of this post, we’ll focus on Adobe.

Adobe Approved Trust List (AATL)

So how does a CA get its root(s) into Adobe? For Adobe Reader/Acrobat 9.0+, they need to be a member of Adobe’s Approved Trust List (AATL). AATL member CAs have been carefully vetted by Adobe to ensure their services and credentials meet the AATL Technical Requirements. Once a CA has been added to the List, any signatures applied with certificates that trace back to their root will be automatically trusted in Adobe products.

Adobe Certified Document Services (CDS)

AATL isn’t Adobe’s first program to address automatic trust of digital signatures and certificates. Its predecessor, the Certified Document Services (CDS) program, was launched way back in 2005 with five member CAs (GlobalSign being one of them). Certificates issued as part of the CDS program were governed by the Adobe CDS Certificate Policy.

CDS is now being phased out in preference of AATL, which has led to some confusion in the market around the differences between the programs. For example, some of our customers who were using certificates based on the CDS program had some initial concerns about switching to certificates from AATL. We can only assume that other people may have similar questions about the switch, so let’s break down what it actually means for end users.

What's the Difference between AATL and CDS?

To be clear, while there are some differences between the programs, the main business benefits (e.g. signatures are automatically trusted in Adobe products, ability to digitally sign or certify documents, long term signature validation) are largely the same, so the differences will not affect most people.

That said, there are three main differences that may be of interest depending on your specific needs.

Certificate Path

One of the key differences between CDS and AATL is the certification path of the certificates. In CDS, CAs had to have their Intermediate CA, or in some cases Issuing CA, that issues the signing or end entity certificates signed by the Adobe Root certificate that is embedded in all Adobe products.  This is no longer the case with AATL (rather than verifying the CA chains to the Adobe root, Adobe software now periodically downloads an updated list of which CA roots to trust), which makes it easier for other certificate communities, such as government eID programs, to join the program.

CDS Certificate Path

AATL Certification Path

What does this mean for you?

• More entities can join the program, so you have more variety and options when it comes to finding a certificate provider.
• For GlobalSign, since our AATL Certificates chain up to our main GlobalSign root, which is also in the Microsoft Root Trust Store, signatures applied with our AATL Certificates are also trusted in Microsoft Office. This means you can digitally sign PDFs, Microsoft documents all with one certificate.

Governing Policy

As discussed, AATL Certificates are governed by the AATL Technical Requirements, which have taken a more international approach to implementation options. For example, CDS required a WebTrust for CA audit, whereas AATL expands the audits to include:

• WebTrust for CA audit
• ETSI 101 456 audit
• ETSI 102 042 audit
• ISO 21188:2006; and/or 4.5. German Digital Signature law audit

What does this mean for you?

Similar to the changes in certificate path, the differences in the governing policies open the doors to more entities joining the program, especially those outside of the US, giving you more options for providers.  

Long Term Validation (LTV) Method

Long Term Validation (LTV) of a digital signature is important in most scenarios. It means that the validity of the signature can continue to be verified regardless of the current status of the signing certificate (e.g. if it has expired or been revoked). So as long as the certificate was valid at the time of signing, the signature should continue to be trusted.

Adobe versions 6, 7 and 8 required “secure time” for LTV, meaning a trusted third party timestamp needed to be included with the signature. The timestamp is used as a reference point for validating the signature. If, according to the timestamp, the signature was applied before the certificate expired or was revoked, the signature will remain valid.

CDS implemented secure timestamps by including a path to the timestamping server in the timestamp extension of the CDS end entity certificate.  Later, when AATL was introduced, the standard implementation did not include secure timestamps as part of the base functionality and if secure timestamping was needed, one would need to configure the timestamp separately through Acrobat Timestamp configuration.

Starting with Adobe 9+, when the AATL program was introduced, “secure time” is no longer required for LTV. Instead, certificate revocation information (CRL or OCSP) is embedded along with the timestamp from the user’s system’s clock with the signature and is referenced by the software to determine validity. This serves the same purpose as the secure timestamps that rely on a trusted time source (i.e. Atomic clock) used previously - as long as the certificate was valid at the time of signing, the signature will be trusted, even if the certificate expires or is revoked at a later date.  

What does this mean for you?

Because it is no longer necessary for LTV, timestamping may not be included with an AATL Certificate. For some businesses, this may not matter, but if you need non-repudiation, manage time-sensitive transactions, or just want confidence around when documents have been signed, you should make sure that your provider of choice can support timestamping.

GlobalSign provides secure timestamps from our RFC 3161-compliant, SHA256 timestamp server as standard functionality in AATL Certificates and utilizes the timestamp extension in the certificate. This means Acrobat users should not have to configure timestamping server settings since the information is already included in the certificate. (Note: server implementation e.g. Adobe Policy still require configuration).

Don't Fear the Change to AATL

As Adobe sunsets CDS, companies who have been using it shouldn’t worry about adopting AATL in its place. The resulting signatures and business benefits are largely the same and in the case of changing the certification path, AATL can actually offer some additional functionality with the ability to create trusted signatures in Microsoft Office documents as well. For those concerned about compliance or legal acceptance, AATL and CDS have the same standing in terms of eIDAS Advanced Signatures, US ESIGN and UETA, and many other industry-specific regulations.

Have questions about CDS and AATL or digital signatures in general? Visit our website or contact us online.