If you have (and use) an electronic signature credential, and are interested in helping Adobe craft the next generation of Adobe Acrobat, Reader, and LiveCycle products and signature features, we are offering you the ability to participate in an Electronic Signature Survey.

There are three parts to this Survey.  The first part asks you to sign a signature field with your signature credential.  The second asks you a series of questions about your use of electronic signatures, and the third concerns technical details about your signature credential. 

IMPORTANT NOTICE:  All information you provide as part of the Electronic Signature Survey will only be used to test the compatibility of Adobe’s LiveCycle ES, Adobe Acrobat and Adobe Reader products with the signatures collected by way of this Electronic Signature Survey and to understand the ways in which signatures are used in our products, helping guide Adobe's electronic signature product strategy.   Adobe will retain the information you submit as part of the Electronic Signature Survey as long as reasonably necessary but solely for testing and product development purposes as noted above.  The information you provide as part of the Electronic Signature Survey will not be publicly disclosed.  If at any time you wish to have the information you submit via the Electronic Signature Survey removed from Adobe’s database, please send an email to signaturesurvey@adobe.com. 

All information submitted by you is subject to Adobe’s Online Privacy Policy located at:  http://www.adobe.com/misc/privacy.html.

Download the Survey here.  Thank you for participating! 

Tags:digital signature,electronic signature,PDF,Acrobat,Reader,survey

Posted by John B Harris at 8:04 AM | Permalink

One frequently asked question I get is about the “Base URL” setting within the LiveCycle Rights Management ES server configuration. What is this for? It’s a global setting that is used in several places where the server must identify its location to a remote client. The text is used as a “base” for deriving various types of server URLs. Here is a screenshot of the relevant configuration section of the administrative web console:

Here are two examples of its use in the system:

• Have you ever wondered how, when somebody opens a RM protected document, the client determines your credentials and decrypts the document? “Baked” into each protected document are two important pieces of unencrypted information: a globally unique identifier (the document GUID), and the server address that the client contacts to receive authorization to decrypt and open the document. The server address is a derivative of the base URL that the administrator configured when setting up the server.
• When an author or recipient performs a “web-based action” on a particular document, the client will automatically receive a single-sign-on-based redirect to a web age populated with the appropriate information. For example, the client-based request to view the audit history of a document opens a web browser showing which users have viewed, modified, or printed a protected document. The end-user experience is seamless, and the redirect instruction is derived from the base url of the document.

The advantage of deriving URLs from this base URL is that it simplifies the end-user experience, as outlined above, and gives flexibility to customers implementing a LiveCycle Rights Management server. This flexibility means that administrators can leverage DNS as a layer of indirection between client and ultimate server(s). DNS, for example, can provide different routes to a server depending on whether a document viewer is located inside or outside of a company’s network. It can also be used in with a load-balanced cluster to ensure that LiveCycle Rights Management runs as a high-availability and high-throughput system.

However, when configuring this URL you need to be careful: by changing settings on the server, you may orphan existing secured documents if you neglect to update DNS to point to the new server. Also, because of the sensitive information communicated between our server and clients (e.g., Adobe Acrobat, Adobe Reader, the LiveCycle Rights Management ES Extensions for Microsoft Office, PTC Pro/ENGINEER, …), we strongly advocate that the URL specified be HTTPS such that the communication is done over SSL. In fact, most of our clients will refuse to talk to a server URL that is not specified as HTTPS. (Specifying a HTTP-based URL will attempt to force the client to communicate over HTTP, however this is likely to fail because our clients generally do not support non-SSL connections.)

Need more information on how your organization can effectively manage and protect your intellectual property? Further information can be obtained at http://www.adobe.com/go/rm or by contacting Adobe

Posted by Jonathan Herbach at 1:30 PM | Permalink

Click here to read about how this technology-savvy law firm improves operations, safeguards sensitive content, and builds stronger cases using Adobe® Acrobat® 9 software.

Using Acrobat, Young Conaway’s staff can go beyond the preservation of confidentiality. They can redact sensitive case information quickly and apply passwords and digital signatures to documents for added security. “We need to control who accesses documents and give people the assurance that the materials they receive have not been altered,” explains DiBianca. “With Acrobat, we can put controls on PDF files to limit access to information and restrict copying of data from files.”

Posted by John Carione at 1:30 PM | Permalink

Do your employees know what "confidential" really means? Do you need an information classification system to better protect your sensitive documents?

The Februrary 5, 2009 issue of SC Magazine published an article on these topics: Document security: Minding your documents.

Posted by John Landwehr at 1:31 PM | Permalink

Since Acrobat 2.0 in 1994, encryption has been available to protect a PDF document - restricting who can open it and what they can subsequently do with it. Today, there are a number of packaging options for distributing one or more protected PDF files.

Adobe Acrobat and Adobe Reader support a number of encryption and key management systems for protecting a PDF:

A. Shared Passwords: Publisher sets a password and the recipient(s) use that same password to open the document.

B. Public Key Infrastructure (PKI): Publisher encrypts a document to one or more of the recipient public keys, which can be looked up in a directory or personal address book. Recipient can open the document by using their corresponding private key stored in software or in a hardware token.

C. Enterprise Rights Management - Coupled with Adobe's LiveCycle Rights Management, the author can specify a policy on a document and the recipients authenticate to their organization's identity management system (LDAP/AD/Kerberos/PKI/etc). Policies can be mapped to an information classification system, like "Company Confidential" or "Insider Restricted".

Each of those mechanisms also support different keysizes (up to AES256) and permissions to restrict some subsequent user actions once the document is open - including modification, clipboard (copy/paste), and printing.

Together, those key management and permissions options can be utilized in a few different scenarios to protect one or more documents:

1. Persistently protect a single PDF

By opening the PDF in Acrobat, choosing one of the encryption options and corresponding permissions, the file is persistently protected for who can open it and what they can do with it. No matter how many copies of the PDF are made, or how they are stored or distributed, each copy of the PDF keeps the PDF protections in place. While it is technically challenging to prevent any file from being copied and redistributed, the protections attached to the PDF file stay with the document independent of storage and transport. That way, if it ends up somewhere it shouldn't, the document is still protected from access.

Click to see sample 1, the password is: password

2. Transport only protection for documents as attachments

If you want to protect documents in transport, but don't want or need the protection after they are received, you can use a PDF document as a protected routing envelope. One PDF can act as the container for other attachments - including PDF and non-PDF formats. By encrypting the outer PDF envelope, it acts as transport encryption for the envelope itself and all of the internal contents. Note that once protected, that outer envelope cannot be viewed without authenticating. Once the recipient authenticates to open that outer document, the envelope text is visible, attachments can be removed and no longer have protection.

Click to see sample 2, the password is: password

3. Transport protection with persistent protection

If you want to send multiple documents together in a PDF envelope, and you want those PDF attachments to retain their protections after the outer PDF envelope is opened - then you should protect the PDF files individually before they are attached. You then have an option of encrypting the outer PDF envelope hosting the attachments. If you put something sensitive on that outer PDF envelope, then you should encrypt it. If you don't care that the outer PDF envelope can be read, then only the individual attachments need be protected before going into that outer PDF envelope.

Click to see sample 3a with viewable envelope, the password is: password

Click to see sample 3b with protected envelope, the password is: password

4. Intermittent transport protection of attachments in an envelope

OK, so we don't have a catchy name for this scenario - but it is a good one. (internally we called it an eEnvelope) Let's say you don't want the envelope to be protected, because you want the recipients to see the sender/receiver and maybe even a digital signature on the the envelope. Then let's say you don't want the attachments to be persistently protected after they are received. BUT you do want there to be encryption while in transport over email, network, disc, USB token, etc. Yes, this is a possible scenario. First, open your outer PDF envelope. Then import your unencrypted attachments onto that envelope. Now, select the encryption mechanism for the outer PDF envelope and when it says "Select Document Components to Encrypt" - select "Encrypt only file attachments". This leaves the outer PDF envelope unencrypted and visible but the attachments are encrypted only while attached. No authentication is required to view the first outer PDF envelope. When the recipient clicks to open any of the attachments, that's when the authentication event takes place to decrypt. NOTE: Once the attachments are opened from the envelope - they are no longer protected! However, if you save the original envelope to your computer, that does keep the protections of the contents. So it's up to the recipients whether they want to keep the envelope with protected attachments, or just extract the attachments and discard the envelope protection.

Click to see sample 4, the password is: password

This last scenario is an ideal method for protecting electronic statements in PDF. Recipients can see an unencrypted view of the outside of the envelope, which can include a certifying digital signature attesting to authenticity and integrity of the envelope. Then the envelope is "opened" and the attachments decrypted so they can be stored locally in an unencrypted state. Somewhat similar to papers in a sealed and postmarked envelope.

In summary, if you want to:

* Protect envelope, with no persistent attachment protections - use scenario 2

* Persistently protect attachments in protected or unprotected envelope- use scenario 3

* Viewable envelope, with transport protection that's not persistent to attachments - use scenario 4

Posted by John Landwehr at 1:14 PM | Permalink

Read about how Adobe LiveCycle RIghts Management ES is helping the Australian government secure forms in an automated process for collecting information from individuals participating in a National Bowel Cancer Screening Program.

"Today, doctors can download a form from the cancer screening website, complete the form on their computers and submit the completed form to the National Bowel Cancer Screening Program Register via a secure electronic process."

Click here for the full story and additional ROI statistics.

Posted by John Carione at 1:50 PM | Permalink

The Antwerp Port Authority manages Europe's second biggest port and is guided by the European Directive on Invoicing (EC / 115 / 201) to ensure member states implement electronic invoicing as part of the value added tax (VAT) legislation. The tax rule requires that each supplier guarantee the authenticity of origin and integrity of the content for invoices they create and ultimately archive for compliance.

To meet these requirements, Adobe LiveCycle ES has been deployed in conjunction with Globalsign certificates to ensure that PDF invoices are digitally certified to cryptographically bind the identity of the certifying party to the invoice itself. Users can then open the invoices using the free Adobe Reader and document authenticity and integrity automatically to detect whether the contents have been altered after certification.

By applying digital signatures, Antwerp Port Authority was able to quickly automate invoicing processes, thereby streamlining workflow, lowering costs, and meeting the mandatory European directives for compliance. The entire process is packaged into a seamless solution via the Adobe Certified Document Services (CDS) platform.

Read more about Antwerp Port Authority's successful implementation of Digital Signatures here.

Posted by John Carione at 9:40 AM | Permalink