Netscape Object Signing: Establishing Trust for Downloaded Software



Communicator, Mission Control, and other Netscape products support a set of tools and technologies called Object Signing. Object Signing uses standard techniques of public-key cryptography to let users get reliable information about code they download in much the same way they can get reliable information about shrink-wrapped software.

Most importantly, Object Signing helps users and network administrators implement decisions about software distributed over intranets or the Internet--for example, whether to allow Java applets signed by a given entity to access specific system resources on specific users' machines.

This paper introduces Object Signing. You should read this paper if you are an IS manager or software developer and you want to understand Object Signing and how to take advantage of it:

Introduction to Object Signing

The sections that follow introduce some of the concepts that underlie Object Signing:

Why Object Signing?

Today, any user with access to the Internet can download a variety of software from thousands of web sites. The creators of this material range from Fortune 500 corporations to single individuals. Executable software includes JavaScript scripts, Java applets, plug-ins, stand-alone applications or updates, and almost any other kind of code. Electronic documents include text, multimedia data--such as video, MIDI, and audio data--and anything else that can be contained in a web page. The web sites that make all this available include intranet sites as well as Internet sites run by companies such as Adobe or IBM, media sites such as the C|NET subsidiary, commercial sites such as online catalogs, government and nonprofit sites, and sites run by small organizations or individual users.

At the same time, the number of intranet and Internet users is increasing exponentially. Mass market users who know little about the Internet are getting connected in greater numbers than ever before. These users know how to acquire known software from trusted manufacturers through trusted sources such as catalogs or retail stores, but they have little or no experience downloading software from the World Wide Web or gauging what effect that software could have on their systems. Corporations, governments, and other organizations are deploying intranets and extranets, tying together employees, customers, suppliers, and service providers who use very different kinds of software on very different platforms. For intranets and extranets, as for the Internet, reliable cross-platform authentication, distribution, and access control for software are becoming more important every day.

Unfortunately, distribution over networks poses potential security problems, because the software must pass through many intermediate machines before it reaches the user's machine. Although millions of users download software every day without incident, the potential exists for either malicious or accidental damage to an individual user's system and data. The user often has no reliable way of confirming where a piece of software is really coming from, whether it has been changed in transit over the network, and what kind of damage it might be capable of causing.

Object Signing is designed to address the need for more reliable software distribution over intranets and the Internet. It is also designed to help users and network administrators implement decisions about which sources of software to trust for what purposes.

What Does Object Signing Do?

The "objects" signed using Object Signing technology can be applets or other Java code, JavaScript scripts, plug-ins, or any kind of file. Netscape provides tools that can associate a digital signature with any kind of software object.

A digital signature consists of cryptographic information generated from both the software object to be signed and the private key of the signer. For an overview of the way this works, see How Object Signing Uses Public-Key Cryptography

When an object is signed with a valid digital signature, Communicator can

  • Identify the Signer. Confirm the identity of the individual, company, or other entity whose digital signature is associated with a signed object.

  • Detect Tampering. Determine whether a signed object has been tampered with since it was signed.
These basic cryptographic operations in turn make it possible for Communicator to

  • Control Java/JavaScript Access. Keep track of fine-grained access privileges granted by the user to signed Java code or JavaScript scripts.

  • Update Software Automatically. Update software automatically by using the SmartUpdate feature of Communicator and the AutoUpdate feature of Communicator Professional Edition to download files that have been digitally signed.
The sections that follow describe the bulleted items in more detail. For information about the way users and network administrators can take advantage of these capabilities, see How Do Users and Network Administrators Control Signed Objects?

Identify the Signer

Object Signing uses techniques based on the X.509 v3 certificate standard and several Public Key Cryptography Standard (PKCS) specifications published by RSA Data Security, including the PKCS #7 signing and encryption standard. Among other things, these standards define how to

On the Internet and on some intranets, reliable identification of object signers is possible because of the existence of independent, widely recognized certificate authorities (CAs), such as VeriSign, that can authenticate the identities of individuals, companies, or other entities and issue electronic identification documents called certificates or digital IDs. A certificate identifies some entity--much like a driver's license or an employee ID card. CAs can also be internal corporate authorities who authenticate identities and issue certificates for use within an intranet or extranet.

The ability to associate a digital signature with a particular entity allows users and network administrators to decide which sources of software they want to trust and to identify software signed by those entities.

For an overview of the way certificates and digital signatures can be used to identify an object's signer, see How Object Signing Uses Public-Key Cryptography.

Detect Tampering

A digital signature can be used to verify not only the identity of the signer, but also the integrity of the object signed. Making even a minor change in the object, such as adding a comma in a text file, results in a different digital signature.

Thus, three digital signatures created by MyCompany for three separate objects can all be identified as MyCompany's signature even though each signature consists of unique cryptographic information. At the same time, if an object signed by My Company has changed between the time it was signed and the time a user receives it, the digital signature is not valid.

For a technical overview of the way digital signatures can be used to detect tampering, see Digital Signatures.

Control Java/JavaScript Access

The techniques of public-key cryptography that make identification and tamper detection possible have been available for many years. Netscape has integrated these standard techniques with Communicator and other products and has made them much easier for users and network administrators to use.

By combining these techniques with Java and JavaScript, Netscape has also created a way to control potentially dangerous access by software to local system resources. Java code and JavaScript scripts are normally restricted to the Java "sandbox"--that is, the carefully defined limits within which Java code must normally operate. Object Signing permits Java code or a JavaScript script to request specific kinds of access to the local system, such as read access or the ability to create a network connection. The user or network administrator determines what kinds of access should be granted or denied for what signers, and Communicator keeps track of the details.

This is an important distinction between Object Signing and other schemes for allowing signed code to access local system resources. Instead of requiring users to allow software either unlimited access or no access at all, Object Signing allows the user to control the degree of access. This approach permits a fine-grained continuum of access privileges from relatively innocuous operations, such as read/write access to a single file, to full-blown powers over many different aspects of the local system.

Once a signer has been granted privileges for a particular kind of access, applets or scripts signed by that signer can turn those privileges on, use them, and turn them off again without interrupting the user's activities. Because the privileges are made available only when needed, the chances of accidental or malicious damage to the user's system are greatly reduced.

For information about using Communicator and Mission Control to control Java and JavaScript access, see How Do Users and Network Administrators Control Signed Objects?

The Java classes that support Java and JavaScript access to local system resources are collectively known as the Java Capabilities API. For information about using the Java Capabilities API to write Java code that supports object signing, see Extending Java Capabilities.

Update Software Automatically

The SmartUpdate feature of Communicator allows users to automatically update software (including stand-alone applications as well as Communicator plug-ins and components) by downloading files that have been digitally signed. All a user needs to do is initiate the software download (for example, by clicking a trigger on an HTML page) and grant the signer the access privileges required to perform the installation. In addition, network administrators can use Mission Control and the AutoUpdate feature of Communicator Professional Edition to schedule fully automated software updates that are completely transparent to users.

How Do Users and Network Administrators Control Signed Objects?

All access-control decisions boil down to who is allowed to do what. Communicator allows users and network administrators to identify who has signed Java code or a JavaScript script and to grant that signer access to specific targets on the local system on either a temporary or a long-term basis. To facilitate such decisions, Communicator maintains a list of Java/JavaScript signers and, for each signer, a list of the kinds of access for which that signer has been granted privileges. The user can open the Security Info window in Communicator at any time to examine and modify this list. Alternatively, network administrators can make these decisions on the user's behalf before deploying Communicator with Mission Control and can optionally lock the settings so that users can't modify them.

Access Control for Users

When a user runs a signed Java applet, a signed Composer plug-in, or a signed JavaScript script that requests some form of access to the local system, Communicator checks its list to determine whether the signer has previously been granted privileges for that target. If so, Communicator allows the access without interrupting the user. If the signer hasn't yet been granted or denied the requested privileges, Communicator displays a Java Security dialog box similar to the one shown in Figure 1.1. (To try this out for yourself with Communicator, see Netscape Capabilities-Based Java Security Demo.)

Figure 1.1 The Java Security dialog box

Each target recognized by Communicator has two characteristics that are displayed in the dialog box shown in Figure 1.1: an approximate guide to the level of risk (High, Medium, or Low) and a short description of the kind of access the requested target represents. If the user clicks Deny without changing any of the settings, access to the specified target is denied. If the user clicks Grant, access to the specified target for the specified signer is permitted until the user quits Communicator. If the user clicks the "Remember this decision" checkbox and then clicks Grant, access to the specified target is permitted indefinitely (unless the user explicitly specifies otherwise in the Security Info dialog box referred to earlier).

A user who wants more information before making a decision can click the Details button, in which case a second dialog box displays additional information about the kind of access requested.

The risk level categories High, Medium, and Low are provided by Netscape as guidelines only. Users or network administrators may have a different opinion about the degree of risk that a particular kind of access by a particular signer entails. Users are encouraged to read the description of the access requested and make their own decisions.

To examine and modify the list of signers, users can open the Java/JavaScript frame of the Security Info window, which is available by clicking a button or choosing a menu command from most Communicator windows. (A network administrator can also choose to lock access to these settings).

Figure 1.2 shows the Java/JavaScript frame of the Security Info window. The user can remove any signer or click the Edit Privileges button to inspect and remove specific privileges for the selected signer. (If you are using Communicator to read this, you can check your own settings: click the Security button near the top of the Navigator window, then click Java/JavaScript.)

Figure 1.2 The Java/JavaScript frame of the Security Info dialog box

Access Control for System Administrators

Network administrators can use Netscape Mission Control, a suite of tools for configuring and managing Communicator clients, to set up Communicator preferences and other settings for different groups of users. Communicator settings that can be customized with Mission Control include the settings that enable or disable Java and JavaScript, the list of signers and the kinds of access each signer is allowed, and the list of certificate authorities. Network administrators can also lock these settings so that they can be changed by the administrator but not directly by the user.

Network administrators can use Mission Control with Communicator Professional Edition to change security settings dynamically after the initial software deployment without involving the user. To do so, the administrator sets preferences and configuration information in a master configuration file and sets up Communicator Professional Edition clients to retrieve that information from the file at regularly specified intervals.

For more information about Mission Control, see Netscape Mission Control Overview and Planning Guide.

Support for Open Standards

The techniques of public-key cryptography that underlie Object Signing are the same as those that underlie the S/MIME and Secure Sockets Layer (SSL) protocols, the industry standards for secure email and secure client-server transactions, respectively. These techniques are based on the X.509 v3 certificate standard and several PKCS standards, including the PKCS #7 signing and encryption standard.

Object Signing also makes use of the cross-platform Java Archive (JAR) format, jointly developed with JavaSoft. JAR archive files, which are compatible with standard cross-platform ZIP files, provide a way to associate digital signatures with specific files in a directory without making any changes to those files. Because the JAR format doesn't require a digital signature to be stored physically inside the file with which it is associated, JAR archives can be used to package and sign any kinds of files, including file types that have not yet been invented.

Developers can create JAR files and sign the objects they contain using Windows 95 and NT, Mac OS, and Unix. Users can download signed objects on any computer that can run Netscape Communicator.

Netscape is working with JavaSoft to extend the Java security model to support fine-grained access by Java code to local system resources. A previous section of this document, Control Java/JavaScript Access, introduces the Netscape approach to Java access control. This approach and the proposed JavaSoft approach are likely to converge as this technology evolves.

For information about public-key cryptography, certificates, and digital signatures, see How Object Signing Uses Public-Key Cryptography.

For information about the JAR format and how to sign objects, see How to Sign Objects.

Benefits of Object Signing

These sections discuss the benefits of Object Signing in terms of security ergonomics and security solutions for specific groups of customers:

  • Security Ergonomics describes how Object Signing reduces the chances of security problems occurring by carefully calibration of security ergonomics for several key groups of customers.

  • Business Uses for Object Signing summarizes the benefits of Object Signing for customers using corporate intranets and the Internet.

Security Ergonomics

Ergonomics are a crucial aspect of any security infrastructure. For example, if the switch in a fighter jet's cockpit that initiates electronic radar evasion is situated right beside the switch that sends out a flare, the fighter pilot is likely to send out a flare accidentally in the midst of battle. This is a design error, not a pilot error; the pilot shouldn't have to deal with the possibility of such a mistake. Modern aviation is much safer as the result of the study of such errors and the resulting changes in instrumentation and cockpit design.

Software design, like cockpit design, should make it easy for people to do the right thing and make it difficult to make mistakes. If the security features of software are difficult to implement or use, people are likely to make dangerous mistakes without realizing it.

Netscape has paid close attention to ergonomic issues related to all aspects of Object Signing. These sections discuss the ergonomics of Object Signing with respect to four main groups of customers:

  • User Ergonomics. Users are the largest and most important group of people who interact with Object Signing technology. If security ergonomics are not effective for this group, it doesn't matter how good they are for the others.

  • Programmer Ergonomics. Most programmers who support Object Signing in their Java code should be able to do so easily, without having to learn complex interfaces. Otherwise, the technology won't be adopted widely enough to do anyone else any good.

  • Administrator Ergonomics. Network administrators are a smaller group than users and programmers. However, they must be able to manage Object Signing security settings for thousands of users to maintain corporate security policies effectively.

  • Advanced Programmer Ergonomics. Experienced programmers who are designing sophisticated applications are the smallest group of people concerned with Object Signing. They must be able to extend and refine the Object Signing infrastructure to create powerful applications needed by the other groups of customers.

User Ergonomics

If users are presented with too many confusing dialog boxes, they tend to start clicking buttons without thinking about the decisions involved. The Java Security dialog boxes in Communicator are designed to help users make informed decisions without overwhelming them with technical details:

Programmer Ergonomics

The development of the Java Capabilities API has been guided by these principles of programmer ergonomics:

Administrator Ergonomics

Good user and programmer ergonomics aren't much use if administrators can't easily upgrade software and implement new security policies in response to changing business requirements. Netscape has designed the Object Signing features of Communicator, Communicator Professional Edition, and Mission Control with the following ergonomic goals in mind for network administrators:

Advanced Programmer Ergonomics

Users, programmers, and administrators all depend on a small but important group of advanced programmers who are building specialized applications that extend the security infrastructure. Therefore, Netscape has developed Object Signing with these goals in mind for advanced programmers:

Business Uses for Object Signing

Object Signing allows independent software vendors, distributors, IS personnel, and webmasters to create and distribute powerful Java applets, Java applications, and JavaScript scripts that can be written once and run on multiple platforms. These can include applets designed for just one small group of workers, full-fledged productivity applications such as Corel Java Office, webtop applications such as Netscape Netcaster, or JavaBeans interfaces that expose corporate databases over an intranet. At the same time, Object Signing gives users and network administrators a context within which they can evaluate and control Communicator security settings in response to changing business situations.

The benefits for specific groups of Netscape customers can be summarized as follows:

How Object Signing Uses Public-Key Cryptography

The sections that follow summarize some basic concepts of public-key cryptography and their relevance to Object Signing:

For a comprehensive discussion of these topics, see Applied Cryptography by Bruce Schneier (Wiley, 1996).

For information about using the Java Capabilities API in signed Java code, see Extending Java Capabilities.

Public-Private Key Pairs

Public-key cryptography involves a pair of keys--a public key and a private key-- associated with each individual or entity that needs to sign something electronically. Each public key is published, but the corresponding private key is kept secret. Data encrypted with your public key can be decrypted only with your private key. Figure 1.3 shows a simplified view of the way this works.

Figure 1.3 Using public and private keys for encryption

The scheme shown in Figure 1.3 lets you freely distribute a public key, and only you will be able to read data encrypted using this key. In general, to send encrypted data to someone, you encrypt the data with that person's public key, and the person receiving the encrypted data decrypts it with the corresponding private key.

As it happens, the reverse is also true: data encrypted with your private key can be decrypted only with your public key. This would not be a desirable way to encrypt sensitive data, however, because it means that anyone with your public key, which is by definition published, could decrypt the data. Nevertheless, private-key encryption is very useful, because it means you can use your private key to sign data with your digital signature. Communicator (with the aid of your public key) can then confirm that the message was signed with your private key and that it hasn't been tampered with since being signed. For more information about the way this works, see Digital Signatures.


A certificate (also called a digital ID) is an electronic document used to identify an individual, company, or other entity. Certificate authorities (CAs) are entities, such as VeriSign, that validate identities and issue certificates. The methods used to validate an identity vary depending on the CA and the class of certificate. In general, it is the responsibility of the CA to ensure that an entity requesting a certificate is in fact who it claims to be before issuing the certificate.

Before submitting a request for a certificate to a CA, Communicator generates a public key and the corresponding private key. The certificate issued by the CA binds the public key to the name of the requesting entity (for example, a company's name). Certificates help prevent the use of fake public keys for impersonation.

A certificate is somewhat like a driver's license, a passport, or any other personal ID that provides generally recognized proof of a person's identity. A certificate always includes a public key and the name of the entity it identifies. Most certificates also include an expiration date, the name of the CA that issued the certificate, a serial number, and other information. Most importantly, a certificate always includes the digital signature of the issuing CA. The CA's digital signature allows the certificate to function as a "letter of introduction" for users who know and trust the CA but don't know the entity identified by the certificate.

Communicator recognizes several kinds of certificates, including those used to identify email recipients and web sites. Communicator also recognizes signing certificates, which identify entities that sign files. Signing certificates are discussed in Getting a Signing Certificate and Signing a File.

When you receive a signing certificate for your own use, it is automatically installed in your copy of Communicator. Communicator also supports the public-key cryptography standard known as PKCS #12, which governs key portability. This means, for example, that you can move signing certificates from one computer to another on credit-card-sized devices called smartcards. Signing tools such as the JAR Packager allow you to choose which signing certificate you want to use at the time of signing.

To confirm a signer's identity, Communicator relies in part on its list of accepted CAs. A CA can be a publicly recognized independent company such as VeriSign, or it can be an individual or department recognized only within a corporation's intranet or extranet. The user can add CAs to Communicator's list of CAs and, if necessary, delete from the list any CAs that the user decides not to trust for the purpose of validating a digital signature. If a signer's signing certificate cannot be traced back to one of the CAs on Communicator's list, that signer's digital signature cannot be validated.

To view your current list of CAs while you are reading this document in Communicator, click the Security button near the top of the Navigator window, then click Signers under Certificates. The list of certificate signers (that is, CAs recognized by your copy of Communicator for validating certificates) looks like the one shown in Figure 1.4.

Figure 1.4 CA certificates listed in the Communicatos Security Info window

Communicator's list of certificate signers is just a collection of CA certificates--that is, certificates issued by CAs for the purpose of identifying themselves. Mission Control allows network administrators to control both the content of and access to this list as well as the list of signing certificates in the Java/Javascript dialog box shown in Figure 1.2.

For an overview of the way certificates are used to confirm a signer's identity, see Validating the Signer's Identity.

Digital Signatures

When one of the Netscape signing tools signs an object, it first creates a one-way hash of that object. A one-way hash is a number of fixed length with the following characteristics:

As explained in Public-Private Key Pairs, it's possible to use your private key for encryption and your public key for decryption. Although this is not desirable when you are encrypting sensitive information, it is a crucial part of digitally signing any object. Instead of encrypting the object itself, the signing tool creates a one-way hash of the object, then uses your private key to encrypt the hash. The encrypted hash and related information are collectively known as the signer's digital signature.

Figure 1.5 shows a simplified view of the way a digital signature can be used to validate the integrity of a signed object.

Figure 1.5 Using a digital signature to validate data integrity

Figure 1.5 shows two items transferred to the recipient of a signed object: the original data, which is sent in the clear, and the digital signature, which is basically a one-way hash of the original data that has been encrypted with the signer's private key. To validate the integrity of the object, Communicator first uses the signer's public key to decrypt the hash. It then uses the same hashing algorithm that was used to generate the original one-way hash to generate a new one-way hash of the same data. (Information about the hashing algorithm used is also sent with the digital signature, although this isn't shown in the figure.) Finally, Communicator compares the new hash against the original hash. If the two hashes match, the object has not changed since it was signed. If they don't match, the object may have been tampered with since it was signed.

If the two hashes match, the recipient can also be certain that the public key in the signer's certificate corresponds to the signer's private key. To confirm the identity of the signer, however, also involves confirming the validity of the digital signature of the CA who issued the signer's certificate. For a discussion of the way this works, see Validating the Signer's Identity.

An individual file can potentially be signed with multiple digital signatures. For example, an ISV might sign the files that constitute a software product to prove that the files are indeed from a particular company. A network administrator might sign the same files with an additional digital signature based on a company-generated certificate to indicate that the product is approved for use within the company.

The significance of a digital signature is comparable to the significance of a handwritten signature. Once you have signed an object, it is difficult to deny doing so later. In some situations, a digital signature may be as legally binding as a handwritten signature. Therefore, signers should take great care to ensure that they can stand behind any objects they sign and distribute.

For example, if you are a software developer, you should test your code to make sure it is virus-free before signing it. Similarly, if you are a network administrator, you should make sure, before signing any code, that it comes from a reliable source and will run correctly with the software installed on the machines to which you are distributing it.

Getting a Signing Certificate and Signing a File

Before signing an object, you must first obtain a signing certificate from an appropriate CA. For example, an independent software developer typically obtains a signing certificate from a publicly recognized CA such as VeriSign. A corporate IS manager might also obtain a signing certificate from an independent CA; or, if the corporation has its own Certificate Server, from an internal CA recognized only within the corporation.

Figure 1.6 shows a simplified view of the way a company called MyCo might obtain a signing certificate from an independent CA. The details of this procedure vary depending on the CA and the type of certificate involved, but the principle is always the same. MyCo provides evidence of its identify, uses Communicator to generate a public/private key pair, and sends the evidence and the public key to the CA. The CA then uses the evidence provided by MyCo to verify the identity of the entity requesting a certificate. This may involve simply confirming MyCo's email address (for example, for a free certificate), checking the evidence against a commercial credit database (for example, for an individual's certificate), examining notarized hard copies of corporate documents (for example, for a commercial software publisher's certificate), or going through some other verification process. It's important to make sure you request a certificate with the appropriate level of identity verification for the intended use.

Figure 1.6 Getting a signing certificate

After the CA has confirmed MyCo's identity, the CA creates a certificate that includes MyCo's name; its public key; other information, such as the dates during which the certificate is valid and the certificate's serial number; and most importantly, the CA's digital signature.

The CA's digital signature allows MyCo to use the certificate as a "letter of introduction" for customers or others who may not be familiar with MyCo but who do know and trust the CA. The CA's signature is obtained by encrypting a one-way hash of MyCo's certificate with the CA's private key. For more details about the way a digital signature is created, see Digital Signatures.

Once MyCo has obtained a signing certificate, it can use the certificate, the corresponding private key, and a signing tool such as the JAR Packager to create a JAR archive file containing signed and compressed files, as shown in Figure 1.7. MyCo can then post the JAR file to a web site. For a brief discussion of JAR archive files and the JAR format, see Understand the JAR Format.

Figure 1.7 Signing a file

Validating the Signer's Identity

Figure 1.8 shows how Communicator uses the "letter of introduction" from a CA--in this case, a signing certificate--and the CA's certificate to validate a signer's identity. To keep things simple, the figure assumes that the certificate for the CA that issued the signing certificate has previously been installed in Communicator's database of CA certificates, that the JAR file contains only one signed file, and that the signer is not known to the user.

Figure 1.8 Validating a signer's identity

These are the steps shown in Figure 1.8:

  1. The user downloads the JAR file.

  2. Communicator locates the file MyCoFile.class and the corresponding digital signature in the JAR file. Communicator then uses MyCo's public key, which it gets from MyCo's "letter of introduction" (MyCo's signing certificate) in the same JAR file, to validate the integrity of MyCoFile.class. This process is explained in Digital Signatures. At this point, Communicator has established that MyCoFile.class has not been tampered with since it was signed, and that the public key in MyCo's certificate corresponds to the private key used to sign the file. However, MyCo's identity has not yet been validated; the certificate might have been created by someone attempting to impersonate MyCo. To be sure that the signing certificate really was issued by the specified CA to the real MyCo, Communicator must also perform step 3.

  3. Using the public key from the specified CA's certificate in its list of CAs, Communicator validates the CA's digital signature for MyCo's certificate, again using the process explained in Digital Signatures.

  4. If steps 2 and 3 are successful, Communicator informs the user that the applet is signed by MyCo. If MyCo's public key can't validate MyCo's signature for the signed file, or if the CA's public key can't validate the CA's signature, Communicator informs the user that the signature is invalid.
When several levels of CAs are involved, Communicator can use the same technique to check the validity of not only the CA's public key, but also the public key of the CA that issued the first CA's certificate, and so on. This process of checking the certificate chain continues until Communicator reaches a CA that is included in its list of accepted CAs. If Communicator can't successfully traverse the certificate chain and identify a CA in its list, it won't accept the original digital signature.

How to Sign Objects

If you are signing Java code that requests capabilities, you first use the Java Capabilities API to call the appropriate methods from within your code. For information about the Java Capabilities API, see Extending Java Capabilities.

Once you have prepared and tested the code or other objects you want to sign, follow the steps described in these sections to sign the objects:

Get a Signing Certificate

Before you can sign any object, you must obtain an object-signing certificate. You can get a signing certificate from one of two kinds of sources:

Before you can sign anything, you need not only a signing certificate, but also a certificate for the CA that issued your signing certificate. If the CA's certificate isn't already installed in your copy of Communicator, you typically install it by clicking the appropriate link on the CA's web site, for example on the page from which you initiated enrollment for your signing certificate.

For information on how to obtain an object-signing certificate from an independent CA, see Object-Signing Tools.

To get a signing certificate from a certificate server on your intranet, see your network Administrator.

For a general introduction to certificates and a discussion of the way they are used in Netscape Object Signing, see How Object Signing Uses Public-Key Cryptography.

Choose a Signing Tool

Netscape provides three signing tools for use by developers:

To download any of these tools, see Object-Signing Tools.These tools are also available as part of Mission Control.

Understand the JAR Format

The Java archive (JAR) format is a set of conventions for associating digital signatures, installer scripts, and other information with files in a directory. Signing tools such as the JAR Packager use this format to create JAR archive files.

A JAR archive file is a digital envelope for a compressed collection of files. Although the files in a JAR archive don't have to be digitally signed, they are stored in a way that makes it possible to associate each file with digital signature information stored separately in the same archive. The JAR file type is a registered Internet MIME type that is compatible with the standard cross-platform ZIP archive format. The JAR file type is distinct from the JAR format, which is simply a way of organizing information in a directory.

Because the JAR format doesn't require a digital signature to be stored physically inside the file with which it is associated, JAR archives are extremely flexible. You can use the JAR Packager to package and sign any files, including Java class files, JavaScript scripts, Communicator plug-ins, or any other kind of document or application. You can sign one file in a JAR archive at a time or sign multiple files in the same archive all at once. The JAR Packager can also read any archive file based on the cross-platform ZIP format and convert it to a JAR file.

In addition to digital signature information associated with the files it contains, a JAR file may include global information such as the name of the installer file that Communicator should launch to install the contents of the JAR file on the local system. A JAR file may also contain other information the developer may wish to associate with the archive as a whole.

You don't need to know anything else about the JAR format to use the JAR Packager, which takes care of the details for you. However, if you are using JAR Packager Command Line or Page Signer to sign files or JavaScript scripts, you do need to be familiar with some of the details of the JAR format. For a detailed description of the format, see The JAR Format.

JAR files are also used with the SmartUpdate feature of Communicator and the AutoUpdate feature of Communicator Professional Edition. The JAR Installation Manager (JIM) is the collective term for the Communicator features that developers and content providers can use to automatically install components, plug-ins, and Java classes on a user's machine. Developers can use JIM to publish their software packages, and content creators can use JIM to modify their pages to trigger an installation. For more information, see JAR Installation Manager Developer's Guide.

Sign the Object

Once you have obtained your own signing certificate and downloaded the signing tool you want to use, follow the instructions for using the tool to create a JAR archive and sign the files it contains (or, in the case of Page Signer, to sign a script in an HTML page). You can find the documentation for each tool in the following locations on DevEdge:

Extending Java Capabilities

Until now, the extent to which Java code can access local system resources has been strictly limited to a narrow range of capabilities known as the "sandbox." This limitation greatly reduces the opportunities for Java code to cause inadvertent or malicious damage to the user's system. At the same time, it restricts the kinds of applications that can be written with Java, because many of the system resources available to applications written for the native operating system aren't available to Java code.

Sophisticated Java programs must be able to perform operations outside of the sandbox, such as accessing the hard disk or creating a network connection, without exposing users to unnecessary risk. To achieve this general goal, Netscape has extended the Java security model through a set of Java classes known as the Java Capabilities API.

These sections describe how developers can use the Java Capabilities API to extend the capabilities of Java code:

For a discussion of security ergonomics related to the Java Capabilities API, see Security Ergonomics.

For a technical overview, interface documentation, sample code, and other technical information, see Java Capabilities API.

Principals, Targets, and Privileges

All access-control decisions boil down to who is allowed to do what. In the Capabilities model, a principal represents the "who," a target represents the "what," and the privileges associated with a principal represent the authorization (or denial of authorization) for a principal to access a specific target.

In the Java Capabilities API, a principal consists of an instance of class Principal and typically represents a signing certificate. A target consists of an instance of class Target and typically represents access to one or more system resources, such read/write access to files or the ability to create a network connection.

The Java Capabilities API makes it possible to determine whether any given principal is allowed to access the local system resources represented by a given target. The answer is expressed by an instance of class Privilege, which states whether access is allowed and, if so, for how long.

Running a Signed Applet

Consider what happens when a user clicks a URL that downloads a JAR archive containing signed Java class files. For the purposes of this example, assume that the Communicator client has the signer's certificate in its list of accepted signing certificates. Communicator first checks the digital signatures in the JAR archive to validate the identity of the entity whose certificate was used to sign the files (the principal) and to make sure the content of the files hasn't changed since they were signed. If these operations are successful, Communicator keeps track of this information for later use and the applet starts to run.

It's important to note that an applet signed by a known principal is not automatically allowed access to the targets for which it has been authorized. Instead, the applet must explicitly request the privileges it needs. An applet that is not signed at all runs "inside the sandbox" as applets always have and is denied extended access to system resources.

The Privilege Manager, with the aid of the Communicator client, keeps track of which principals are allowed to access which targets at any given time. Signed applets use an instance of class PrivilegeManager to request privileges for particular targets. Communicator associates each principal with a list of targets for which privileges may or may not be permitted. If the client's list of principals and their permitted targets includes the applet's principal and the requested target, the Privilege Manager grants the privilege without interrupting the user. If the applet's principal has not previously been granted or denied a privilege for the requested target, Communicator displays a dialog box asking the user whether to grant that privilege to that principal.

The Privilege Manager enforces a distinction between granting a privilege and enabling a privilege. An applet that has been granted a privilege has a potential power that is not yet turned on. An applet that successfully enables a previously granted privilege has the privilege's power available and ready to use.

A privilege can be granted only if the client software has previously associated that principal with a privilege for that target or if the user explicitly grants that privilege when the applet requests it. In both cases, after the applet's first successful request for the privilege, that privilege is both granted and enabled.

However, although the privilege typically remains granted for the rest of the time the applet is running, it is enabled only for the duration of the method call in which the privilege is requested. Subsequent method calls that require the same kind of access must therefore request the privilege again. In those cases, the privilege has already been granted (so no dialog box, for example, needs to be displayed), and the request simply enables the privilege--that is, allows the applet to access the target.

In effect, after its principal has been granted some privileges, the applet can turn those privileges on, use them, and turn them off again, without interrupting the user's activities.

Using Codebase Principals

When developing secure Java code, you may wish to bypass the signing stage for much of the development cycle. To make this possible, you may place a line in the Communicator preferences file to activate codebase principals. By default, Communicator treats signing certificates as principals for the purpose of enabling privileges. When codebase principals are activated, Communicator allows the CODEBASE of the applet (either a file: URL or an http: URL) to function as a principal for enabling privileges. This allows you to test Java code that requests privileges without having to sign each new version you create. For more information, see Security Technote #2: Activating Codebase Principals.

JavaScript and the Java Capabilities API

Object Signing allows developers to sign JavaScript files, inline scripts, and event-handler scripts. Any JavaScript script can call the Java Capabilities API using JavaScript syntax. Therefore, all descriptions of the Java Capabilities API in this paper also apply to JavaScript. The Java Capabilities API greatly expands the range of behavior available to scripts, just as it does for Java code.

For details on using the Java Capabilities API from within JavaScript, see What's New in JavaScript.

Composer Plug-Ins and the Java Capabilities API

Signed Composer plug-ins, which must be written in Java, can also take advantage of the Java Capabilities API. For more information, see the Composer Plug-In Guide.

Future Directions

Netscape is currently exploring several possible extensions of Object Signing technology, including the following:


Public-Key Cryptography

For a comprehensive technical discussion of public-key cryptography and cryptographic algorithms, see Bruce Schneier, Applied Cryptography (Wiley, 1996).

For public-key cryptography standard (PKCS) documentation and other information about cryptography and networks, see RSA Data Security.

Object-Signing Resources on DevEdge

For an overview of DevEdge resources related to Object Signing, see Netscape Object Signing Resources. Resources listed there include the following:

For information about supporting the Java Capabilities API from JavaScript or in Composer plug-ins, see these documents:

For information about using the signing tools provided by Netscape, see the following:

Other Netscape Resources

Other Netscape resources related to Object Signing include the following:

Selected JavaSoft Resources

JavaSoft pages that are relevant to Object Signing:

Any sample code included above is provided for your use on an "AS IS" basis, under the Netscape License Agreement - Terms of Use