John Landwehr, Director of Security Solutions here at Adobe, recently sat down for Focus Washington, an online television series that deals with a variety of topics at the convergence of policy and technology. Here, Landwehr describes certified documents, and notes their benefits not only to authenticity and integrity, but also to accessibility and indexing.
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.
Managing information risk is a complex business these days, especially when you look at (1) the range of information you need to protect, (2) the breadth of risks you need to mitigate, and (3) the management policies and tools available to today’s IT security professionals to protect that information. However:
“A well-realized information risk management strategy has other benefits [beyond security]: enhanced business agility, competitiveness, efficiency and cost savings.”
In other words, you can’t do without it!!
The problem? According to Deloitte, on
average, only half of the companies surveyed in their annual Global Security and Privacy Survey had formal security
policies or strategies. Not a great foundation on which to build risk management on!
I wrote a recent article in Security Products magazine which confronts these challenges head-on, and provides some tips on navigating the “mind-boggling” task of information risk management.
Redaction was in the news again today with two large organizations publishing documents that weren’t properly redacted. So we’d like to remind everyone that removing sensitive information from an electronic document is easy…
Jim King, PDF Architect, senior principal scientist at Adobe and one of the key drivers behind the PDF format and its adoption and continuing development by ISO as a standard (ISO 32000), recently delivered a keynote presentation to the ISSE (Information Security Solutions Europe) 2009 Conference in The Hague, Netherlands. He discussed the evolution of the PDF format and standard, and spent most of his talk introducing the new PAdES signature standard and what it encompasses.
During that conference, Jim sat down with Roger Dean, executive director of eema UK, for a conversation about PDF, the need for digital signatures, challenges of communicating the benefits of digital signatures, and finally a description of the PAdES standard. This interview is now available below (and here)…enjoy!
Building on the delivery of the PDF format to the International Standards Organization (ISO) as ISO 32000-1, Adobe has been collaborating with standards bodies around the world to make it easier for companies, organizations and individuals to leverage the ubiquity of PDF to make business processes quicker, easier and more reliable. However, the rush to go paperless has often fallen short of its true potential because signing a document oftentimes brings business critical processes crashing to a halt, requiring users to print out the previously electronic document in order to apply their nom de plume with an ancient writing implement. Electronic signatures are obviously the solution, but there’s still the question of interoperability and the use of electronically signed documents within certain legal frameworks, such as the European Union (EU). With last week’s announcement of an ETSI open standard for PDF digital signatures, that question can now be answered.
ETSI/ESI Technical Standard (TS) 102 778, better known as PAdES (pronounced with either a long or short a), documents how the digital signature format described in ISO 32000-1 meets the needs of the 1999 EU Signature Directive (see previous blog entry), and then goes on to describe how that format can be expanded to take advantage of certain capabilities such as long-term document validation, where digital signatures placed on documents today can be validated five, ten and even 50 years later. (The standard can be downloaded free of charge from the ETSI website at http://pda.etsi.org/pda/.)
If you’ve been following this blog, you’ll know that we toss around lots of terms in each entry, along with references to standards, technologies, products and services. Even if you haven’t read this blog before, you may have struggled trying to understand the difference between electronic and digital signatures, or what a "PKCS#11" is, or, for that matter, a trust anchor.
Well, struggle no more–today we published our latest security terms glossary, which should help to clearly define terms and keep everyone here in line with usage. (Let us know if we don’t!) Over 140 terms are defined, along with spelled out acronyms, so you are no longer in the dark!
What’s more, the glossary is posted on our Security Document Library site, part of the learn.adobe.com wiki area of Adobe’s web presence. The Document Library contains links to the latest security documentation, including an omnibus guide, "Digital Signatures & Rights Management in the Acrobat Family of Products," which consolidates many separate documents we’ve had in the past on signatures, preferences, registry settings, encryption and the like. In addition, there are links to many useful one page ‘keys’ on signature validation, icons, signature creation, etc.
Find the glossary here. If we’ve missed any terms or some element of documentation, please email John Harris at jbharris(at)adobe.com.
This is the latest entry in our “What is an Electronic Signature, Anyway?” series. You can find previous entries here.
Recently, I’ve received a number of emails from our users asking questions about electronic signatures, so I thought it would be useful to briefly answer some of these frequently asked questions and also direct you, dear reader, to a variety of resources here at Adobe that can help.
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.)