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

• Benefits of Object Signing

• How Object Signing Uses Public-Key Cryptography

• How to Sign Objects

• Extending Java Capabilities

• Future Directions

• References

• Copyright

• Why Object Signing?

• What Does Object Signing Do?

• How Do Users and Network Administrators Control Signed Objects?

• Support for Open Standards

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?

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.

• 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.

Identify the Signer

• create a digital signature for any data

• use the digital signature and the appropriate certificates, or digital IDs, to identify the entity that created the signature

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

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

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

How Do Users and Network Administrators Control Signed Objects?

Access Control for Users

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 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

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

• 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.

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.

• Give users just the information they need, when they need it. Users can get a rough idea at a glance where an applet comes from, what kinds of access it is requesting, and the approximate level of risk (High, Medium, or Low) involved. At the same time, users who want to know more precisely what's involved can click the Details button to see more detailed descriptions. For a description of the way this works, see How Do Users and Network Administrators Control Signed Objects?

• Don't bother the user more than necessary. If a user permanently grants a particular kind of access to a particular signer, Communicator remembers the decision and transparently permits that form of access to that signer in future sessions. In addition, Netscape has defined several macro targets that allow a set of related privileges to be requested simultaneously. This allows the user to view a single request and a summary of the kinds of access involved rather than a series of separate requests. As with all access requests, the user who wants more information can always choose to view more details, including descriptions of the individual targets that make up the macro.

• Give users fine-grained control. To change privileges granted to a particular signer, the user can open the Java/JavaScript panel of the Security Info window within Communicator. The user can thus exercise fine-grained control over who gets what kind of access to local system resources (as long as the network administrator has not locked access to these settings).

• Minimize significant API. Most Java or JavaScript programmers need to use only three or four of the methods provided by the Java Capabilities API. By using these methods and following a few simple rules, they can quickly implement support for Object Signing without making dramatic changes to the rest of their program.

• Minimize potentially dangerous code. If programmers are forced to examine thousands of lines of code for potential security problems, they are bound to miss some. To address this issue, the Java Capabilities API allows an applet to turn potentially dangerous privileges on, use them, and turn them off again, without interrupting the user's activities. This greatly reduces the amount of code that is potentially dangerous and therefore subject to a strict security review.

• Enable the minimum level of access required. The Java Capabilities API 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. This makes it easy for programmers to enable just the kind of access their program needs, avoiding unnecessary privileges that might increase the user's risk.

• Limit the time during which privileged code can run. Once it is has enabled specific privileges, an individual method retains those privileges only while it is running. After the method returns, access is no longer possible.

• Let administrators set and "lock" Java access privileges. Before deploying Communicator 4.0, administrators can use Mission Control to set up and lock both the database of accepted signers and the database of access privileges permitted for each signer. For users of Communicator Professional Edition, administrators can also use Mission Control to replace the database of accepted signers dynamically after the initial deployment.

• Support JavaScript access to the Java Capabilities API. Anyone who's comfortable with JavaScript can write scripts that can do anything that Java code based on the Java Capabilities API can do. JavaScript is more convenient than Java for many network administrators.

• Allow administrators to set the system principal. By default, Communicator assigns Java code signed by Netscape the extensive access privileges required to operate the Java Security infrastructure. Only the system principal--that is, the signer of the system classes that control access--may have this form of access. Network administrators may choose to remove Netscape's digital signature from the system classes and replace it with a company's own signature, thus making a company the system principal. This can be useful for companies that need to tightly control the lists of signers and trusted CAs in users' copies of Communicator. (For more information about principals and their privileges, see Extending Java Capabilities.)

• Let advanced programmers define and name their own targets and macro targets. Each signer, or principal, can make use of a separate name space for access targets. This means that advanced programmers can define their own targets for specialized purposes and use the Java Capabilities API to access them. For example, a bank might want to define different kinds of access to account information on the user's hard disk for different kinds of programs. A charting program might need read access for a variety of accounts, whereas a program designed to update values in a stock portfolio might need write access to investment accounts only. By defining their own targets and macro targets, advanced programmers can define and group forms of access for their own unique business applications.

• Let advanced programmers check whether specified privileges are enabled. Before performing some action that requires additional privileges, a programmer can check whether those privileges have been enabled. In this way, programmers can modify a program's behavior according to the kinds of privileges it has been granted for the machine on which it's running.

• Give advanced programmers access to the full security infrastructure. Although most programmers can get by with just a few method calls, advanced programmers can take advantage of additional Java Capabilities classes and methods to create their own cross-platform Java Security extensions.

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

• Public-Private Key Pairs

• Certificates

• Digital Signatures

• Getting a Signing Certificate and Signing a File

• Validating the Signer's Identity

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

Public-Private Key Pairs

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.

Certificates

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

• The value of the hash is unique for the hashed object. Any change in the object, even deleting or altering a single character, results in a different value.

• The content of the hashed object cannot, for all practical purposes, be deduced from the one-way hash.

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

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 Validating a signer's identity

These are the steps shown in Figure 1.8:

How to Sign Objects

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

• Choose a Signing Tool

• Understand the JAR Format

• Sign the Object

• An independent Certificate Authority (CA), such as VeriSign, that authenticates your identity and charges you a fee. You typically get a certificate from an independent CA if you want to sign software that will be distributed over the Internet.

• A corporate CA running a Certificate Server on your corporate intranet. You typically get a certificate from a corporate CA if you want to sign software that will be distributed only over an intranet or extranet.

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

• JAR Packager is the primary signing tool provided by Netscape. It is a Java applet that allows you to package Java applets, plug-ins, and other files in JAR files. You must run the applet from within Communicator. In the long term, Netscape plans to incorporate some of the additional capabilities provided by the other object-signing tools in the JAR Packager. If you are signing just a few files, use the JAR Packager.

• JAR Packager Command Line is a stand-alone command-line tool that uses the JAR format to sign files, which you can then package in a JAR file using a ZIP utility. JAR Packager Command Line was originally developed for internal Netscape testing purposes only and will not be fully supported in the long term. If you need to sign files in batches from a command line or you want to sign files without running Communicator, use JAR Packager Command Line.

• Page Signer is a Perl script available for Windows 95 and NT, Solaris, and IRIX. It runs on top of JAR Packager Command Line and creates JAR files containing digital signatures and related information for inline JavaScript scripts. Like JAR Packager Command Line, Page Signer was originally developed for internal Netscape testing purposes only and will not be fully supported in the long term. You need to use Page Signer only if you intend to sign in-line JavaScript scripts.

Understand the JAR Format

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

• Using the JAR Packager

• Using JAR Packager Command Line

• Using Page Signer

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:

• Principals, Targets, and Privileges

• Running a Signed Applet

• Using Codebase Principals

• JavaScript and the Java Capabilities API

• Composer Plug-Ins and the Java Capabilities API

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

Principals, Targets, and Privileges

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.

JavaScript and the Java Capabilities API

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

Future Directions

• Support for certificate revocation. Certificate authorities can issue certificate revocation lists (CRLs), which are lists of certificates that have been revoked. CRLs are useful in a variety of circumstances that might invalidate a particular certificate, for example if the security of a private key is compromised. Netscape plans to support certificate revocation in future products.

• Improved flexibility in Mission Control for controlling security settings. Currently, a network administrator must actually run Java applets from different signers to set up users' Java/JavaScript access privileges before using Mission Control to deploy Communicator. Netscape plans to improve the interfaces in future versions of Mission Control for setting up and modifying access privileges across different groups of users.

• Support for parameterized targets. Communicator doesn't currently provide a user interface for controlling access to parameterized targets--for example, access to a single file on a hard disk. Netscape plans to support a variety of parameterized targets in future versions of Communicator and the Java Capabilities API.

• Improve protection of Java packages. The Java virtual machine enforces the distinction between public members/methods and private members/methods, but package-protection is not rigorously protected. It is possible for malicious programmers to add code to any package and circumvent package-protection constraints. Netscape is considering the use of digital signatures to improve package security, so that classes cannot be added to a Java package unless they are digitally signed by the appropriate entity.

References

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

Object-Signing Resources on DevEdge

• Object Signing Tools. Download page for signing tools. Also includes information about obtaining a signing certificate.

• Java Capabilities API. Overview of DevEdge resources related to the Java Capabilities API.

• The JAR Format. Detailed technical description of the JAR format.

• JAR Installation Manager Developer's Guide. Detailed information about supporting automatic software installation features of Communicator and Communicator Professional Edition.

• What's New in JavaScript.

• Composer Plug-In Guide

• Using the JAR Packager

• Using Jar Packager Command Line

• Using Page Signer

• Security Home. Overview of Netscape security resources.

• Certificates. Overview of information related to certificates.

• Certificate Authority Services. A listing of some certificate authorities that issue certificates for Netscape products.

• Security Newsgroup. Ongoing discussions about Object Signing and other Netscape security technologies.

• Netscape Mission Control. Summary of product information for Mission Control.

• Netscape Mission Control Overview and Planning Guide. Documentation for Mission Control.

• JAR Guide. Information about JavaSoft's support for the JAR format.

• Download page for JDK 1.1.2.

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