42 IT Pro March/April 2013 P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y 1520-9202/13/$31.00 © 2013 IEEE

FEATURE: SECURITy

Harigopal K.B. Ponnapalli and Ashutosh Saxena, Infosys, India

This digital signature architecture provides browser-agnostic, client-side signature components and generic server-side signature validation components to help integrate signatures into Web applications. The authors also discuss ways to extend HTML syntax to support signatures.

In today’s competitive business world, in which enterprises must extend their busi-ness environments over the Web for con-sumers, employees, and partners, digital

security will play a pivotal role in building trust and credibility. Secure sockets layer (SSL) over HTTP (HTTPS) is the standard method used to secure Web content. However, SSL addresses only a subset of security requirements. It can establish a reliable private connection and au-thenticate peer identities but doesn’t offer non-repudiation, which is an equally critical security requirement for today’s business applications. Also, because SSL is a transport-layer protocol, it only protects data while in transit between the client (browser) and Web server. It doesn’t cover requirements vis-à-vis end-to-end message-level protection.

Digital signature technology can help address nonrepudiation in addition to satisfying the au-thentication and integrity requirements of digi-tal content. Here, we discuss a digital signature

architecture that provides browser-agnostic, client-side signature components and generic server-side signature validation components to help integrate signatures into Web applications.

Signature Issues in Web AppsUsing digital signatures and SSL in combination complements each technology’s innate capabili-ties. A digital signature, which requires a pub-lic key infrastructure (PKI), is a well-accepted, legally valid, electronic equivalent of a hand-written signature in most parts of the globe (see the “Digital Signatures” sidebar for more infor-mation). The process (outlined in the sidebar) is fairly simple, but it becomes complicated when implemented in a Web application for two main reasons.

First of all, the HTML specification doesn’t in-clude signature support.1 Using third-party sig-nature tools2,3 to sign Web content limits Web applications to certain browsers and operating systems.

A Digital Signature Architecture for Web Apps

itpro-15-02-Sax.indd 42 2/26/13 3:31 PM

computer.org/ITPro 4 3

Second, multiple signature-representation stan-dards exist for different business contexts—such as the Public-Key Cryptography Standard #7 (PKCS#7),4 Cryptographic Message Syntax (CMS),5 and XML Digital Signature (XML DSig).6 However, there’s no single standardized interface that lets Web applications use these varied signature format standards in a pluggable, flexible manner.

Similarly, there are multiple private key stor-age techniques (for hardware and software) and

formats—such as the Windows key store,7 Java key stores (JKS),8 PKCS#11,9 and PKCS#1210—and varied certificate-status verification mecha-nisms, such as the Certificate Revocation List (CRL)11 and Online Certificate Status Protocol (OCSP).12 It’s important to have standardized in-terfaces to seamlessly consume these underlying PKI services in Web applications.

We propose addressing these issues by amend-ing the HTML specification to support the creation of digital signatures for Web content.

Digital Signatures

Digital signatures can replace handwritten signa-tures in workflow-based Web transactions, result-

ing in completely automated, faster, and efficient workflows. Web applications across several industry segments can benefit from digital signatures.

Use CasesIn the insurance sector, time-consuming, paper-intensive review, approval, and archival processing of insurance documentation can be replaced with faster, low-cost, and digitally signed electronic docu-ments. In the government sector, faster citizen service is possible with paperless e-governance, replacing handwritten signatures with digital signatures. Fur-thermore, a more secure e-commerce system can be built if consumers digitally sign the purchase requests made on commerce portals.

In e-banking systems, the use of digital signatures facilitate online loan applications, account openings, approvals, and other financial transactions, mitigating paper dependence and helping banks stay produc-tive, competitive, and compliant with regulatory requirements.

In healthcare, digitally signed electronic documents enable paperless automated operations and business processes in hospitals and medical centers. They also help such facilities comply with regulations, such as the Health Insurance Portability and Accountability Act.

Client-Side Digital SignaturesIn Web applications with an architecture based on a client-side digital signature, the process starts with the user filling in a Web form and initiating the signature process. The client signature component prompts the user to select a private signing key from a secure private key storage. Then, the application creates a digital signature for the Web content and submits it to the Web server. A server component verifies the signature for its authenticity and integrity, and validates the certificate1 to ensure it was issued by

a trusted certification authority. The digital signature and Web content are securely logged in persistent storage. In the case of a nonrepudiation dispute at a later date, the digital signatures can be retrieved from the secure storage and verified to prove which users participated in the transaction.

Server-Side Digital SignaturesAn alternative to the client-side signature architec-ture is to employ a server-side signature generation mechanism,2 where the private signing keys of all users are stored in a secure server-side store. When the signature is required, the user is authenticated by a server through a mechanism other than a digital signature, such as a password, and the server-side cryptomodule retrieves the user’s private key and creates the signature on the server content on behalf of the user.

Although server-side signature generation has its merits, including ease of use and lower maintenance and deployment costs, it increases the complexity of the server-side infrastructure in terms of protection and performance needs. High protection is required to secure access to the server-side key store, which often becomes a target for attacks. Also, the legal validity must be analyzed in different geographies, because the digital signature creation is delegated to the server by the user. A detailed discussion of the server-side signature mechanism is beyond the scope of this article.

References1. Information Technology—Open Systems Interconnection—

The Directory: Authentication Framework, International

Telecommunication Union recommendation X.509,

Aug. 2005; www.itu.int/rec/T-REC-X.509.

2. “Digital Signatures and the Hidden Costs of PKI,” ARX,

Aug. 2010; www.arx.com/resources/white-papers/

digital-signatures-and-the-hidden-costs-of-pki.htm.

itpro-15-02-Sax.indd 43 2/26/13 3:31 PM

44 IT Pro March/April 2013

FEATURE: SECURITy

There’s one initiative to use XML digital sig-nature syntax to sign HTML content,13 but it’s still primitive and specific to the XML signature standard. So, for now, our architecture offers an interim solution.

Key RequirementsIn defining our digital signature architecture, we considered several key requirements. First, the signature creation and verification functionality had to be browser-agnostic so it works in all pop-ular browsers (Microsoft IE, Firefox, Chrome, and so on). Second, we needed a centralized, parameter-driven architecture that could address varying business needs depending on the under-lying PKI services available. Third, we needed the flexibility to digitally sign the Web form content in its entirety or selectively.

We also needed extensible support for private key store formats—such as the Windows key store, PKCS#11, PKCS#12, and JKS—both on software and hardware (smartcards, USB to-kens, and so on). Finally, we needed configurable support for multiple signature format standards (such as PKCS#7 and XML DSig), certificate- status verification mechanisms (such as CRLs

and OCSP), and certif icate-path-building algorithms, such as PKI X.509 (PKIX; http://datatracker.ietf.org/wg/pkix/charter).

A Java-Based Digital Signature ArchitectureIn the absence of standards for browsers to handle signatures in Web content, Java is a good choice for developing a browser-agnostic signa-ture architecture, because Java applet is the client technology most com-monly supported by popular brows-ers. Furthermore, it has

• feature-rich support for handling signatures;

• built-in standardized API support for dealing with multiple private key stores in either the software or hardware;

•built-in support for a standard-ized XML digital signature API and commercial and open source

PKCS#7/CMS libraries (see www.bouncycastle.org); and

• ready support for certification path validations using OCSP and CRL.14

Although we discuss a Java-based architecture, it’s easy to develop the server-side solution in other popular Web technologies, such as .NET, which also provide rich support for cryptographic functionality. Figure 1 depicts the important building blocks of the architecture.

Using a factory design pattern is a good choice for a flexible and dynamic invocation of signature functionality from multiple options, such as sig-nature syntax standards, key store formats, and certificate validation. The factory pattern allows dynamic instantiation of objects with different behavior but with the same interface methods.

It’s important to carefully define the interface with appropriate method signatures at a suffi-ciently abstracted level. Specialized behaviors can be derived by implementing these abstract inter-faces. Similarly, the parameters needed for these standards might vary widely, so it’s appropriate to abstract the parameters into a separate abstract class. Each standard that requires a specific

Figure 1. Digital signature architecture overview.

Signaturegenerator

(PKCS7, XMLDSig)

Signaturevalidator

(PKCS7, XMLDSig)

Certi�catevalidator

(CRL/OCSP)

Con�guration repository(database,

�les)

Certi�cate andCRL repository

(database,directory,

�les)

Certi�cate andCRL update

utilities

Of�inesignature

veri�cationutilities

Secure privatekey storage

(PKCS12,PKCS11,

Windows)

Signaturestorage and

archival(database,

�les)

itpro-15-02-Sax.indd 44 2/26/13 3:31 PM

computer.org/ITPro 4 5

parameter set can provide its implementation of this abstract class. The idea for the architec-ture is to reuse existing standardized Java APIs wherever available and define new ones wherever needed. Figure 2 provides a definition of some important classes.

There’s a compelling need to define a cen-tralized, configuration-driven architecture that drives the behavior of both client and server modules to meet varying business needs. In the following, we discuss the corresponding modules along with their functionality (excluding GUI components, in an effort to stay focused on key aspects related to signatures).

Configuration RepositoryDigital signature requirements vary according to the business needs, available PKI services, local regulations and standards, organization security policies, and so on. The configuration repository is a centralized store for all configuration param-eters and is the key component for a centralized, parameter-driven architecture. The repository can be a database, file system, or directory.

The Configurator class depicted in Figure 2 reads all configuration-related information and supplies it to the signature creation and verifica-tion components. In one possible implementation, the Configurator can be as simple as a Java prop-erties class that reads key value properties from a configuration repository. Table 1 provides a brief description of some important configuration

parameters considered, but it’s not an exhaus-tive list.

Signature GeneratorThis component creates the signature. Sun Java has a signature factory that helps in instantiating signature objects supporting specific algorithms, such as RSA and XML digital signatures. How-ever, Java doesn’t have a standardized interface for CMS/PKCS#7. To provide pluggable and ex-tensible support for these multiple standards, a factory design pattern is followed by our archi-tecture (Figure 2).SignatureStandardFactory is a factory that

helps in creating an instance of a Signature­Standard object based on the signature stan-dard that’s configured. SignatureStandard is a generic interface that captures the functionality of any digital signature standard (such as sig-nature creation or verification). Different stan-dards, such as PKCS7Standard (for PKCS#7) and XMLDSigStandard (for XML DSig), implement standard-specific functionality for the interface methods. The behavior of SignatureStandard objects can be customized by supplying Standard­Parameters object (such as PKCS7Parameters or XMLDSigParameters) corresponding to the particular signature standard. This gives appli-cations the flexibility to use different signature standards without code changes.

Java Applet code on the client can use this signature generator component to generate a

Figure 2. Digital signature architecture class diagram.

SignatureStandardFactory

public SignatureStandard getInstance(String standardName)

PKCS7Parameterspublic void getOutputEncoding()public boolean isCerti�cateChainIncluded()public boolean isAttachedSignature()public void setOutputEncoding(String encodingFormat)public void setCerti�cateChainIncluded(boolean includeChain)public void setAttachedSignature(boolean attachedSignature)public void setVerifyChain(boolean verifyCertChain)public boolean getVerifyChain()public void setCertVer�cationMechanism(String mechanism)public String getCertVeri�cationMechanism()

public XMLDSigStandard(XMLDSigParameters)

XMLDSigParameters

XMLDSigStandard

Con�gurator

KeyStore

Windows KeyStore PKCS12KeyStore PKCS11KeyStore JavaKeyStore

public PKCS7Standard(PKCS7Parameters)PKCS7Standard

StandardParameters

SignatureStandardpublic boolean verify()

public boolean verify (byte[] dataSigned)public X509 Certi�cate[] getCerti�cates()

public X509CRL[] GetCRLs()public void setCertsAndCRLs(X509Certi�cate[] , X509CRL[])

public void sign(byte[] , dataToBeSigned, PrivateKey privKey)

AggregationRealizationGeneralizationInterfaceDependency

itpro-15-02-Sax.indd 45 2/26/13 3:31 PM

46 IT Pro March/April 2013

FEATURE: SECURITy

signature in the Web content. Other client-side technologies required to digitally sign Web con-tent within browsers include JavaScript and Java applets.

JavaScript is supported by all popular brows-ers and helps dynamically prepare the content to be signed. Developers can write generic Java-Script functionality to retrieve data to be signed from the form fields. This library interacts with the Java applet to invoke signature functional-ity and supply the content to be signed to the applet.

Java applets are Java applications that run in the browser in a secure sandbox environment. An applet-based solution offers

•a browser- and platform-agnostic solution that runs in all popular Web browsers;

•easy maintenance, because the solution only needs to be updated on the server side;

• rich built-in support for PKI in Java; and

•access to local system resources (such as pri-vate key files), which isn’t otherwise possible through JavaScript.

The server-side module renders the Java applet tag with configuration information read from the Configurator. The Java applet uses this infor-mation to generate a signature on the content to be signed. The created signature can be sup-plied to the server either directly by applet or by assigning it to a predefined field (the signature holder specified in the configurable parameters in Table 1) within the HTML form. Client-side modules are written in Java and JavaScript and can be used in a browser-agnostic manner in all Web applications, irrespective of the server-side language.

Signature ValidatorThis component is part of SignatureStandard­Factory and helps verify the signature according

Table 1. Important configurable parameters.

Parameter Description

Key stores – Instruct client to select certificates from a configured key store

– Options include Windows, JKS, JCEKS, PKCS#12, or PKCS#11

Signature format

– Standard format for signature representation

– Affects both client and server modules

– Options include PKCS#7 and XML DSig (this can be further populated when support for any other standard formats is built)

Certificate chain

– Instructs whether to include the entire certificate chain, the entire chain excluding the root, or only the user certificate

– Helps save memory and network bandwidth in cases where the rest of the certificates are retrievable

– Affects both client and server modules

Content present

– Affects both client and server behavior

– Instructs whether to include the data signed as part of signature content (for example, in PKCS#7, content can be excluded in a scenario where content can be retrieved directly from the Web form by the verification module)

– Saves memory and network bandwidth.

Signature algorithm – Affects both client and server behavior

– Indicates which signature algorithm (such as RSAwithSHA or DSAwithSHA) to use

Certificate validation

– Affects server-side validation behavior

– Indicates the details of the certificate-status validation mechanism, like choosing CRL or OCSP and their corresponding URLs (it’s also possible to have this check on the client side if such service is feasible)

Trusted CAs – Affects both client and server behavior

– Indicates the list of trusted and accepted certification authorities

Output encoding

– Affects both client and server behavior

– Indicates the output encoding format for signature (for example, in case of PKCS#7, it can be either Distinguished Encoding Rules15 or Base6416 encoding)

Signature holder – Affects both client and server behavior

– The signature generated can be assigned by the client to this HTML form field, which is accessed to verify the signature on the server

itpro-15-02-Sax.indd 46 2/26/13 3:31 PM

computer.org/ITPro 4 7

to the conf igurat ion read f rom the Con­figurator. The signature validator invokes certificate-status verification modules as per the configuration.

Certificate ValidatorThis component helps validate the certificate chain in terms of correctness and trust. There are varied certificate-status verification mechanisms, including CRLs and OCSP. Similarly, there are multiple certificate-chain-building algorithms, such as PKIX. Depending on the available PKI services and configuration, the certificate valida-tor component uses an appropriate certificate-chain-building algorithm and certificate-status verification mechanisms to validate the target certificate.

Typically, there are multiple trusted certifica-tion authorities in a given business context, so it’s critical to maintain a central repository of all related certificates and CRLs. These certificates are stored either in a database, local file system, or directory. The certificate validator component retrieves certificates from the underlying reposi-tory and validates their status.

Signature Storage and ArchivalThis component addresses nonrepudiation. The signature and transaction data must be stored and archived securely for smooth retrieval in case of disputes. Signatures will be stored with trans-action data or in isolated central storage with cross references to transaction data.

Typically, digital signatures are stored for a longer duration as a proof of nonrepudiation, so a secure archival mechanism separate from the active signature storage space offers optimal per-formance. This component is also responsible for periodically archiving certificates and CRLs critical for supporting nonrepudiation.

Offline Signature Verification UtilitiesThese are the tools used in case of an audit or nonrepudiation trial. They retrieve the signature from active or archival storage, validate signa-tures, and prove the signature status by referring to the signed date and time. To address a scenario in which the certificate status is invalid at the time of the audit but valid when the signature was created, it’s important to include a time stamp as part of the signed content.

Certificate and CRL Update UtilitiesThe list of trusted certification authorities can also change depending on business needs. This requires the administrator to update the certifi-cate and CRL repository accordingly. Certificates will have a limited shelf life and will need to be updated occasionally; however, CRLs will be is-sued at regular intervals. The administrator must download the latest CRLs and certificates from the trusted sites and update the repository. Au-tomated scripts and tools that download CRLs using preconfiguration criteria and update local certificate store are productive.

Certificate & CRL RepositoryThis component is mainly responsible for orga-nized storage of certificates and CRLs, which are required for successful certificate status validation. Certificates and CRLs can be stored in multiple storage places, including file systems and direc-tories. This component abstracts the underlying storage details and provides a consistent interface to access and manage certificates and CRLs.

Secure Private Key StorageThe security of the entire system depends on the security of underlying private keys. The private keys can be stored as files either in local software file system or on hardware, such as smartcards for higher security. There are multiple key stor-age formats, such as PKCS#11 (hardware crypto interface), PKCS#12, and JKS. This component abstracts the details of underlying private key storage and format. It provides a consistent inter-face to access and manage private keys securely for signing.

Security AssuranceWhen implementing this digital signature frame-work, developers should follow application- security best practices prescribed for JavaScript, Java applets, and general Web applications (see www.owasp.org and https://buildsecurityin.us-cert.gov/bsi/home.html). Insecure software implementation practices can increase the at-tack surface and expose the applications to poten-tially dangerous vulnerabilities, such as cross-site scripting or malware introduction, and under-mine the system’s usefulness. A detailed dis-cussion on application security threats in Web applications is out of scope for this article.

itpro-15-02-Sax.indd 47 2/26/13 3:31 PM

48 IT Pro March/April 2013

FEATURE: SECURITy

Digital Signature Extensions to HTMLIf the HTML specification is amended to define ways in which browsers support digitally signed Web content, it will become easy to build Web applications with digital signature support in a browser- and system-agnostic manner. Consid-ering HTML’s wide applications and the com-plexities of such a huge specification, amending it won’t be trivial. However, we have some ideas.

First of all, the revised specification should de-fine a new attribute “sign” to be supported by all significant HTML elements (for example, form fields such as form, text, text area, lists, and hid-den fields) that indicate whether the field should be part of the signed content. Introducing this optional attribute would let developers select which content to sign. For example,

<input type="text" name="OrderNumber" value="" sign>

<textarea name="Comments" rows="10" cols="10">

Here, the data in the “OrderNumber” text field would be digitally signed but not the data entered in the “Comments” text area.

Second, the specification should extend “sign” attribute support for forms with file uploads, so that the file content can be digitally signed.

Third, the specification should define a set of new attributes for the “Form” field that define how the signatures should be handled for form content. For example,

<form name="OrderForm" action-"actionURL" method="post"

signattrbs="format=pkcs7,

encoding=base64,showTBSData=true,

promptForCertificate=true,trustedCAs=

'issuer dns of trusted certificates',

signatureAlgo=RSAwithSHA1,

includeCertChain=true">

In this example, signattrbs defines the brows-er’s signature component behavior:

•format specifies the signature standard (PKCS#7);

•encoding reveals the digital signature’s encod-ing format (for example, Distinguished Encod-ing Rules15 or Base6416 encoding);

•showTBSData, if true, displays the content be-ing signed so the user is aware of what’s being signed;

•promptForCertificate, if true, tells the browser to prompt the user to select the certifi-cate to be used for signing among those avail-able for that browser;

•trustedCAs provides Issuer Distinguished Name attributes of the trusted certificate au-thority (CA) certificates—the user can select certificates only from this list of CAs; and

•includeCertChain tells the browser to include or exclude the certificate chain.

The specification can also standardize support for browsers’ software and hardware-based key store types.

D igital signatures can help build more secure and efficient Web applications across business segments. Wider adop-

tion of digital signatures would be possible if the HTML standard specification were extended to provide integral support to digital signa-tures while defining tags that can trigger digital signature creation by browsers. By standard-izing this feature for HTML, browser vendors can provide their proprietary implementations supporting digital signatures and develop-ers can develop applications as per single stan-dardized HTML syntax in a browser-agnostic manner.

In the absence of established standards to digitally sign Web content, we’ve discussed a browser-agnostic architecture for building digital signature support into Web applications in a pro-ductive, flexible, and extensible manner.

AcknowledgmentWe thank Sudarshana Dhar for her editing support. Views pre-sented here are authors’ personal opinions and in no way represent the opinion of Infosys.

References 1. HTML 4.01 Specification, World Wide Web Consor-

tium (W3C) specification, Dec. 1999; www.w3.org/TR/html401.

2. Capicom Reference, Microsoft, 2012; http://msdn. microsof t.com/en-us/ l ibrary/aa375732(VS.85). aspx.

itpro-15-02-Sax.indd 48 2/26/13 3:31 PM

computer.org/ITPro 4 9

3. S. Mazumdar, “XML Digital Signature Tool,” Mozilla Add-Ons, 2012; https://addons.mozilla.org/en-Us/thunderbird/addon/xml-digital-signature-tool.

4. B. Kaliski, PKCS#7: Cryptographic Message Syntax, Ver-sion 1.5, RFC 2315, March 1998; ftp://ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-7.asc.

5. R. Housley, Cryptographic Message Syntax (CMS), RFC 3852, July 2004; https://tools.ietf.org/html/rfc3852.

6. M. Bartle et al., XML Signature Syntax and Processing (Second Edition), World Wide Web Consortium (W3C) recommendation, June 2008; www.w3.org/TR/ xmldsig-core.

7. “Cryptography Objects,” Microsoft, 26 Oct. 2012; http://msdn.microsoft.com/en-us/library/windows/desktop/aa380254(v=vs.85).aspx#certificate_store_objects.

8. “Java Cryptography Architecture—API Specifica-tion & Reference,” Oracle, 25 July 2004; http://docs.oracle.com/javase/1.5.0/docs/guide/security/ CryptoSpec.html.

9. PKCS#11: Cryptographic Token Interface Standard, RSA, 2004; ftp://ftp.rsa.com/pub/pkcs/pkcs-11/v2-20/ pkcs-11v2-20.pdf.

10. PKCS#12: Personal Information Exchange Syntax Stan-dard, RSA, 1999; ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/pkcs-12v1.doc.

11. “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” tech. memo, The Internet Society, 2002; www.ietf.org/rfc/rfc3280.txt.

12. “The Online Certificate Status Protocol (OCSP),” The Internet Society, 1999; www.ietf.org/rfc/rfc2560.txt.

13. “HTML Signing Profile,” World Wide Web Consor-tium (W3C), Feb. 2008; www.w3.org/2007/11/h6n.

14. “Java PKI API Programmer’s Guide,” Oracle, 1993; http://download.oracle.com/javase/6/docs/technotes/guides/security/certpath/CertPathProgGuide.html.

15. Data Networks and Open System Communications, Int’l Telecommunication Union recommenda-tion, 2002; www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf.

16. “The Base16, Base32, and Base64 Data Encodings,” tech. memo, The Internet Society, 2006; http://tools.ietf.org/html/rfc4648.

Harigopal Ponnapalli is a principal research analyst at Infosys, India. His research interests include strong authen-tication, PKI, security assurance, and software piracy. Pon-napalli received his M.Tech in automation and computer vision from the Indian Institute of Technology, Kharagpur, India. He is coauthor of Distributed Systems Security: Issues, Processes and Solutions (Wiley, 2009). Contact him at harigopal_ponnapalli@infosys.com.

Ashutosh Saxena is a principal research scientist at Infosys, India. His research interests include authentication technolo-gies and key management. Saxena received his PhD in com-puter science from Devi Ahilya University, Indore, India. He is the author of PKI—Concepts Design and Deploy-ment (Tata McGraw-Hill, 2004). He’s a senior member of IEEE. Contact him at ashutosh_saxena01@infosys.com.

Selected CS articles and columns are available for free at http://ComputingNow.computer.org.

IEEE Software seeks practical,

readable articles that will appeal

to experts and nonexperts alike.

The magazine aims to deliver reliable

information to software developers

and managers to help them stay on

top of rapid technology change.

Author guidelines: www.computer.org/software/author.htmFurther details: software@computer.orgwww.computer.org/software

Call for Articles

itpro-15-02-Sax.indd 49 2/26/13 3:31 PM