10 Deployment Rule Set

The Deployment Rule Set feature is for enterprises that manage their Java desktop environment directly, and provides a way for enterprises to continue using legacy business applications in an environment of ever-tightening Java applet and Java Web Start application security policies. This feature also provides the ability to control the version of the JRE that is used for specific applications.

Note:

The Deployment Rule Set feature is optional and shall only be used internally in an organization with a controlled environment. If a JAR file that contains a rule set is distributed or made available publicly, then the certificate used to sign the rule set will be blacklisted and blocked in Java.

This topic contains the following sections:

Overview of Deployment Rule Sets

The Deployment Rule Set feature enables an enterprise to establish a whitelist of known applications that can run without security prompts.

Java applets, Java Web Start applications, and JavaFX applications launched from or embedded in a browser are known collectively as Rich Internet Applications (RIAs). To protect the user and minimize the possibility that a RIA was compromised, security checks are performed when a RIA is started, and the user is prompted for permission to run the RIA. Applications on the whitelist defined by a Deployment Rule Set can be run without most security prompts, however, the following prompts are not suppressed:

  • HTTPS security warnings

  • Authentication dialogs that require the user to provide credentials to connect

  • Security warnings from unsigned Java Web Start applications that want to perform such actions as creating a shortcut or an association

Rules for deployment are defined in an XML file and packaged in a signed JAR file. The rules are tested sequentially until one matches the RIA. Depending on the action assigned to the rule, the RIA is then run without security prompts, blocked from running, or run with default processing that shows any security prompts that are applicable. If no rules are matched, then default processing is used. The rules also provide the ability to specify the version of the JRE that is used to run the RIA and suppress the notification of out-of-date JREs.

An active rule set that is installed on the system can be viewed from the Web Settings tab of the Java Control Panel.

Create the Rule Set

The rule set is an XML file that must be named ruleset.xml. Use any text editor to create this file.

Define the Rules

Define the rules that you need to run or block RIAs for your organization. See Java Deployment Rule Set DTD for the syntax of the rule set. If unknown elements or attributes are included in the rule set, warnings are written to the Java Console.

The following elements are valid:

If the rule set is invalid, then an error that describes the problem is shown and all RIAs are blocked. Either the ruleset.xml file must be corrected, or the DeploymentRuleSet.jar file must be removed from the deployment directory (see Installing the Rule Set for the location of this directory) before RIAs can be run. If a rule set is reported as invalid, then check for the following problems based on the error you received:

  • The file is unreadable.

  • The structure of the file is invalid.

  • The rules are not properly defined.

  • A rule with an action of run has no selection criteria provided and therefore matches all RIAs.

  • The JAR file is not properly signed with a valid certificate.

If the DeploymentRuleSet.jar file is removed, RIAs are handled by the default deployment process.

See Examples for some sample rule sets.

<ruleset>

The <ruleset> element is the top-level element of the policy file.

The valid child elements are <rule> and <customer>.

The following table describes the valid attribute.

Table 10-1 Attribute for <ruleset>

Attribute Description Required

version

Minimum version of the Deployment Rule Set specification that is required to process this file. Use a plus sign (+) to indicate that later versions can also be used, for example 1.0+. If your JRE does not support the version specified, all RIAs are blocked.

Yes

<rule>

The <rule> element defines the action taken for the RIA or set of RIAs that is matched by the criteria specified for the rule.

This element contains one <id> element, one <action> element, and optional <customer> elements. Rules are processed sequentially until a rule is matched. When a match is found, no further rules are processed. If no rule is matched, then default processing is used, and any relevant security prompts or warnings are shown.

Note:

When a RIA has artifacts that are signed with a different certificate or that are in a different location, ensure that the rule set contains rules for all artifacts of the RIA. For mixed code cases, which are calls between JAR files with different permission levels or calls from JavaScript code to privileged Java code, see Set Up Rules for Mixed Code.

The valid parent element is <ruleset>. The valid child elements are <id> and <action>.

This element has no attributes.

<id>

The <id> element identifies the RIA or set of RIAs to which the rule applies. To be considered a match, the RIA must match all attributes and child elements present. If no attributes or child elements are present, then the rule matches all RIAs.

Note:

If the action for a rule is run, then at least one attribute or child element must be present.

The valid parent element is <rule>. The valid child elements are <certificate>, <checksum>, and <jnlp-checksum>. Use the <certificate> element for signed JAR files. Use the <checksum> element in Deployment Rule Set 1.2 and higher for unsigned JAR files. Use the <jnlp-checksum> element in Deployment Rule Set 1.3 and higher with a location-based run rule to allow insecure properties in an unsigned JNLP file to be used.

The following table describes the valid attributes.

Table 10-2 Attributes for <id>

Attribute Description Required

location

URL of the source of the RIA. For RIAs that use JNLP, this value is matched to the href attribute in the main JNLP file, or the jnlp_href parameter for the applet tag. If there is no href attribute or jnlp_href parameter provided, use the <jnlp-checksum> element with the location. For a JNLP extension, this value is matched to the location of the extension element in the resource element of the main artifact. For RIAs that do not use JNLP, this value is matched to the URL for the HTML file. The path is case sensitive and UTF-8 encoding is assumed.

Use of the HTTPS protocol is strongly recommended to avoid potential man-in-the middle attacks.

A location is matched based on the following guidelines:

  • If provided, then the protocols must match exactly.

  • The host name can start with an asterisk followed by a dot and a host name substring (*.host-name-substring), which then matches any host that ends with the host name substring provided after the dot. For example, *.example.com matches host.example.com and host.test.example.com. The host name cannot be just an asterisk or an asterisk with no host name substring, such as *.com.

  • If provided, then the port numbers must match exactly.

  • If provided, then the beginning of the paths must match exactly. If the location attribute does not contain a path, then all paths from the host are considered a match. For example, host.example.com/samples matches host.example.com/samples and host.example.com/samples/test, but does not match host.example.com/test. However, host.example.com matches host.example.com/samples, host.example.com/samples/test, and host.example.com/test.

If the location attribute is not present, or the value is null, then the location matches all RIAs.

No

title

String used in the title element of the JNLP file, or as used by the Java Plug-in. If the title attribute is present and the value is not null, then the value must match the title of the RIA exactly. If the title attribute is not present, or the value is null, then the title matches all RIAs.

If the action for a rule is run or default and the title attribute is present, another id attribute or child element must be specified with the title attribute, otherwise the rule is invalid.

No

<certificate>

The <certificate> element identifies the certificate used to sign the RIA. The hash attribute is required.

The valid parent element is <id>. This element has no child elements.

The following table describes the valid attributes:

Table 10-3 Attributes for <certificate>

Attribute Description Required

algorithm

String that defines the hashing algorithm used to generate the value for the hash attribute. Currently, only security hash algorithm SHA-256 is supported. If the value is null, then SHA-256 is used.

No

hash

String of hexadecimal digits that represent the hash value of the code signing certificate. The value is based on the hashing algorithm specified for the algorithm attribute. See Get the Certificate Hash for information on getting the value to use.

Yes

<checksum>

The <checksum> element identifies the checksum for an unsigned JAR file. The hash attribute is required. This element is available in Deployment Rule Set 1.2 and higher.

The valid parent element is <id>. This element has no child elements.

The following table describes the valid attributes:

Table 10-4 Attributes for <checksum>

Attribute Description Required

algorithm

String that defines the hashing algorithm used to generate the value for the hash attribute. Currently, only security hash algorithm SHA-256 is supported. If the value is null, then SHA-256 is used. If a non-null value other than SHA-256 is used, a warning is issued and SHA-256 is used.

No

hash

String of hexadecimal digits that represent the hash value of the checksum for the uncompressed form of the JAR file (compression level 0). The value is based on the hashing algorithm specified for the algorithm attribute.

Yes

<jnlp-checksum>

The <jnlp-checksum> element identifies the checksum for a JNLP file. The hash attribute is required. This element is available in Deployment Rule Set 1.3 and higher.

The valid parent element is <id>. This element has no child elements.

If the location attribute of the <id> element is null, the <jnlp-checksum> element is ignored. You can specify more than one <jnlp-checksum> element. A rule matches if the checksum for the JNLP file equals the hash attribute of one of the <jnlp-checksum> elements in the rule. The following table describes the valid attribute:

Table 10-5 Attributes for <jnlp-checksum>

Attribute Description Required

hash

String of hexadecimal digits that represent the hash value of the checksum. The value is based on the hashing algorithm specified for the algorithm attribute.

Yes

<action>

The <action> element defines the action taken for any RIA that matches the rule.

The valid parent element is <rule>. The valid child element is <message>.

The following table describes the valid attributes:

Table 10-6 Attributes for <action>

Attribute Description Required

permission

Action taken. The valid values are block, default, and run.

block - RIA is not run. A message is shown to the user. To provide a custom message, include the <message> element.

default - RIA is run with default processing and any applicable security prompts are shown. To include a custom message when default processing blocks the RIA, use version 1.2 or higher of the Deployment Rule Set and include the <message> element.

run - The following types of RIAs are allowed to run without prompts:

  • Signed with a valid certificate from a trusted certificate authority

  • Signed with an expired certificate

  • Self-signed

  • Unsigned

  • Missing required JAR file manifest attributes

To include a custom message with the run action, use version 1.2 or higher of the Deployment Rule Set and include the <message> element.

Yes

version

String that identifies the version of the JRE to use to run the RIA. This attribute applies only when the value for the permission attribute is run. Use the version attribute when an older JRE is needed for compatibility with specific RIAs. If the version attribute is not present, the RIA is run with the latest JRE available.

The following values are valid:

  • Platform version, such as 1.7, 1.7+, 1.8, 9. A platform version requests the use of any version of the specified platform, or the specified platform or later when a plus sign (+) follows the version.

  • Implementation version, such as 1.7.0_40, 1.8.0_20. An implementation version requests the use of a specific version.

  • SECURE. The SECURE keyword requests the use of any version at or above the security baseline.

  • SECURE-version, where version is a valid platform version, such as SECURE-1.8. The SECURE-version keyword requests the use of any secure version of the specified platform, or the specified platform or later when a plus sign (+) follows the platform.

The version of the JRE that is used is determined by the following order of precedence:

  • The current version of the JRE is used if it is available and matches both the version attribute and the version requested by the RIA.

  • The latest available version of the JRE is used if it matches both the version attribute and the version requested by the RIA.

  • The current version of the JRE is used if it is available and matches the version attribute.

  • The latest available version of the JRE is used if it matches the version attribute.

If no version is available that meets the criteria, then the RIA is blocked, and a message is shown to the user. To provide a custom message, include the message element.

No

force

Boolean that indicates if the JRE specified for the version attribute must be used to run the RIA. If this attribute is set to true, the JRE specified in the rule overrides any JRE requested by the RIA. If the JRE specified in the rule is not available, the RIA is blocked. The default is false.

For example, if the RIA requests a JRE in the 1.7 family (1.7*) and you want only secure versions of JRE 8 run in your enterprise, you can create a rule that specifies SECURE-1.8 for the version attribute and set the force attribute to true. This rule forces the RIA to run only with a secure version from the 1.8 family.

This attribute is available in 1.1 and later versions of the Deployment Rule Set.

No

<message>

The <message> element defines a custom message shown to the user. This message can be used to explain why the RIA is blocked, or provide additional information to the user.

Only plain text is allowed, HTML tags and other special formatting are not supported. If this element is not present, then a default message is shown when a RIA is blocked. In Deployment Rule Set 1.2 and higher, if this element is present for a rule with the action set to run, then an additional dialog is shown to the user. To support multiple locales, include a message element for each locale.

If the locale attribute is not specified, then the message is used for any locale for which a message element is not provided. If a message element for the user's locale is not provided and a message element without a locale is not present, then a default message is shown.

To ensure that the dialog box that shows the message fits the screen, keep the message under 1024 characters and test for all locales provided.

The valid parent element is <action>. This element has no child elements.

The following table describes the valid attribute:

Table 10-7 Attribute for the <message> element

Attribute Description Required

locale

Locale to which the message applies.

No

<customer>

Information provided in the <customer> element is written to the deployment trace file and the Java console when tracing and the console are enabled. Use this element to provide debug information or associate custom data with a rule or rule set.

You can enter any information in the <customer> element as either plain text or valid XML. Include a <customer> element within a rule to provide information specific to that rule. Include the element outside of the rules to provide information about the rule set. Prior to Deployment Rule Set 1.2, this element is ignored. In Deployment Rule Set 1.2 and higher, information from this element is copied to the trace file and Java console when they are enabled.

The valid parent elements are <ruleset> and <rule>. This element has no child elements.

This element has no attributes.

Set Up Rules for Calls From JavaScript Code (LiveConnect)

If you need to make calls to your RIA from JavaScript code, then apply the following guidelines to prevent the calls from being blocked:

  • If the rule set contains a rule with the action of run that matches your RIA, then the rule set must also contain a rule with the action of run that matches the location of the JavaScript code.

  • If the rule set contains a rule with the action of default that matches your RIA, or no rule matches your RIA so default processing is used, then one of the following must be true:

    • The rule set contains a rule with the action of run that matches the location of the JavaScript code.

    • The rule set contains a rule with the action of default that matches the location of the JavaScript code.

    • No rule matches the location of the JavaScript code, so default processing is used.

If the JavaScript code is calling privileged code and you want to suppress mixed code warnings, see Set Up Rules for Mixed Code.

Set Up Rules for Mixed Code

When you create your rule set, ensure that you have rules for all of the artifacts that are associated with the RIAs. Additional rules might be needed to suppress mixed code security warnings that are generated when calls are made between code with different permission levels, or from JavaScript code to privileged Java code.

To suppress the mixed code security warnings, include rules in your rule set based on the following requirements of your RIA:

  • To make calls between Java code with different permission levels, add a rule with an action of run that matches the code being called.

    For example, the following rule suppresses the mixed code prompt for calls to privileged code located at https://host.example.com/apps from sandbox code:

    <rule>
     <id location="https://host.example.com/apps"/>
     <action permission="run"/>
     </rule>
    
  • To call privileged Java code from JavaScript code, add a rule with an action of run that matches the location of the JavaScript code.

    For example, the following rule suppresses the mixed code prompt for calls to privileged Java code from JavaScript code that is located in any page on https://host.example.com.

    <rule>
     <id location="https://host.example.com/"/>
     <action permission="run"/>
     </rule>
    

    If the rule set has no rule with an action of run or default that matches the location of the JavaScript code, then calls from JavaScript code are blocked. If you want any applicable security prompts to be shown for calls from JavaScript code, you must define a rule with an action of default that matches the location of the JavaScript code.

Be aware that the rules shown in this section for suppressing the mixed code prompt also suppress the other security prompts for any RIA that matches the rule. Make sure that your rules are defined in the order needed to provide the control that you want.

Get the Certificate Hash

If you want to define a rule that uses the certificate hash to match RIAs, you need to obtain the correct string of hexadecimal digits. Follow these steps:

  1. Use the following command to print out the certificate information for your JAR file, replacing myjar.jar with the name of your JAR file:
    keytool -printcert -jarfile myjar.jar | more
    
  2. At the beginning of the output, find Signer #1
  3. In the Certificate fingerprints section under Signer #1, find the line that begins with SHA256.

    The text that follows the SHA256 identifier contains 32 pairs of hexadecimal numbers separated by colons. Use this string for the hash attribute of the certificate element. The string can be used with or without the colons.

Packaging the Rule Set

The rule set defined in the ruleset.xml file must be packaged in a signed JAR file named DeploymentRuleSet.jar. The JAR file must be signed with a valid certificate from a trusted certificate authority.

For information about creating and signing a JAR file, see the lesson Packaging Programs in JAR Files in the Java Tutorials.

Installing the Rule Set

The rule set must be installed on every system on which you need to run Java applications.

Install the DeploymentRuleSet.jar file on your users' systems in the following directories:

  • On Windows platforms, install the file in the <Windows-directory>\Sun\Java\Deployment directory, for example, c:\Windows\Sun\Java\Deployment.

  • On Solaris and Linux platforms, install the file in the /etc/.java/deployment directory.

  • On macOS platforms, install the file in the /Library/Application Support/Oracle/Java/Deployment/ directory.

Viewing the Active Rule Set

Only one deployment rule set can be active at a time. The active rule set can be viewed from the Java Control Panel.

To view the active rule set:

  1. Start the Java Control Panel.
  2. Go to the Web Settings tab.
  3. Go to the Deployment Rule Set tab.

    If a rule set is active, a link to the rule set is shown. If no active rule set exists, a message is shown.

  4. Click the View the active Deployment Rule Set link.

Security Considerations

The Deployment Rule Set feature enables RIAs to run without notifying users of potential security risks. Review the following security considerations to be aware of the risks of using a rule set, and follow any recommendations provided:

  • The location attribute of the id element is compared to the following information:

    • Location of the HTML file, for applets that do not use JNLP

    • Value of the href attribute in the JNLP file, for Java Web Start applications and applets that do use JNLP

    • Value of the jnlp_href parameter for the applet tag, for applets that use JNLP and do not provide the href attribute in the JNLP file

    If matched, then all of the content in the HTML file or JNLP file is considered trusted. However, if the web site that hosts the file is vulnerable to cross-site scripting attacks, malicious content could be injected into the HTML file or JNLP file.

  • For applets that use JNLP, the location of the HTML file is not checked, so the applet could potentially be started from anywhere.

  • If the location attribute is not used to match a rule to a RIA, then the HTML file or JNLP file that is used to start the RIA could be compromised. Use of the location attribute is recommended.

  • Only include a path in the location attribute for a rule with an action of run if you trust the entire server. Using a path in a run rule when other locations on the server might not be trusted could present a security risk and is not recommended.

  • When a path is included in the location attribute, avoid using complex paths or multi-byte characters, if possible. The path is case sensitive and UTF-8 encoding is assumed. Security exceptions occur when any unsupported characters, decoding errors, or overlong encoding is encountered. If the web server, file system, or browser normalizes the path differently, a rule based on the location attribute could return unexpected results.

  • A blocking rule for a specific URI is not intended to be a robust security enforcement mechanism. For example, a rule established with a domain name can be bypassed if a user uses the IP address instead. The recommended practice is to have a final rule in your rule set with no identifiers and an action of block. Define the rules that you need to run RIAs without security prompts or with default processing, and let all other RIAs be matched by the final rule, which blocks them from running.

  • Use of the HTTPS protocol is recommended for all locations.

  • The order of the rules in the deployment rule set is critical. Rules are processed sequentially from the beginning of the file. When a match is found, no further rules are processed. Review your final rule set and look at both positive and negative cases to ensure that the rules cover the RIAs that you plan to manage without allowing matches to unknown RIAs.

  • Rules are required for all artifacts of the RIA, such as multiple JAR files and JNLP extensions. Be careful when defining a rule for an artifact so that you do not inadvertently allow other RIAs that match the rule to run.

  • Deployment rules allow RIAs to run with old versions of the JRE when needed for compatibility, however, older versions might have known security issues. Use the latest JRE whenever possible, and set the version attribute to SECURE or SECURE-version. If an older version of the JRE must be used, make any rule that requests the old version as restrictive as possible to limit the RIAs that match the rule and run with the old version. Use of all of the identifiers-location, title, and certificate hash-is recommended in this case.

  • If a rule with an action of run exists for the RIA, the RIA is run even if the certificate used to sign the RIA is expired.

Examples

Sample deployment rule sets are provided to show how deployment rules are used to block or allow applications to run.

Example 10-1 Run RIAs from a Single Location

This example allows all RIAs from https://host.example.com/ to run without security prompts. RIAs from other locations do not match the rule so default processing is used and security prompts are shown as applicable.

<ruleset version="1.0+">
  <rule>
    <id location="https://host.example.com" />
    <action permission="run" />
  </rule>
</ruleset>

Example 10-2 Block Any RIAs Not Matched

To ensure that all RIAs are handled by the rule set, you can provide a final rule that matches any RIA that was not matched by a previous rule. The action for this rule must be either block or default. This example allows all RIAs from https://host.example.com:8080 to run without security prompts and blocks all other RIAs. The default message is shown when a RIA is blocked because no custom message is provided.

<ruleset version="1.0+">
  <rule>
    <id location="https://host.example.com:8080" />
    <action permission="run" />
  </rule>

  <rule>
    <id />
    <action permission="block" />
  </rule>
</ruleset>

Example 10-3 Rule Order Matters

Rules are processed in the order in which they appear in the rule set. Complex patterns can be defined for matching rules by placing the rules in the correct order. This example allows RIAs from https://host.example.com to run without security prompts using a secure version of the Java 1.7 platform, but uses default processing for RIAs from https://host.example.com/games, which shows applicable security prompts. RIAs from other locations do not match either rule, so default processing is used.

<ruleset version="1.0+">
  <rule>
    <id location="https://host.example.com/games" />
    <action permission="default" />
  </rule>

  <rule>
    <id location="https://host.example.com" />
    <action permission="run" version="SECURE-1.7" />
  </rule>
</ruleset>

Example 10-4 Manage a Specific RIA

This example modifies the rule set in Example 10-3 and requires only the RIA named Solitaire from https://host.example.com/games to run with default processing. Other RIAs from https://host.example.com are allowed to run without security prompts using a secure version of the Java 1.7 platform. All other RIAs are blocked, and a custom message is shown.

<ruleset version="1.0+">
  <rule>
    <id title="Solitaire" location="https://host.example.com/games" />
    <action permission="default" />
  </rule>

  <rule>
    <id location="https://host.example.com" />
    <action permission="run" version="SECURE-1.7" />
  </rule>

  <rule>
    <id /> 
    <action permission="block">
      <message>Blocked by corporate. Contact J. Smith, [email protected], if you need to run this app.</message>
    </action>
  </rule>
</ruleset>

Example 10-5 Manage RIAs Based on Signing Certificate

To allow multiple RIAs from multiple locations to run, and all RIAs are signed with the same certificate, you can use the certificate element to identify the RIAs with one rule instead of creating rules for each location and title. This example allows all RIAs that are signed with the certificate used by Oracle to run without security prompts using a secure version of the Java platform. RIAs from any host ending with example.com are allowed to run with default processing. All other RIAs are blocked, and a custom message is shown.

<ruleset version="1.0+">
  <rule> <!-- allow anything signed with company's public cert --> 
    <id>
      <certificate hash="794F53C746E2AA77D84B843BE942CAB4309F258FD946D62A6C4CCEAB8E1DB2C6" />
    </id>
    <action permission="run" version="SECURE" />
  </rule>

  <rule>
    <id location="*.example.com" />
    <action permission="default" />
  </rule>

  <rule>
    <id />
    <action permission="block">
      <message>Blocked by corporate. Contact J. Smith, [email protected], if you need to run this app.</message>
    </action>
  </rule>
</ruleset> 

Example 10-6 Force the Use of a Specific JRE

To force the use of a specific JRE, use the force attribute of the action element. This attribute is introduced in the 1.1 version of the Deployment Rule Set. This example allows RIAs from https://host.example.com/apps to run without security prompts using version 1.8_20 of the JRE. Any version requested by the RIA is ignored. If version 1.8_20 is not available, the RIA is blocked. All other RIAs are blocked, and a custom message is shown.

<ruleset version="1.1+">
  <rule>
    <id location="https://host.example.com/apps" />
    <action permission="run" version="1.8_20" force="true" />
  </rule>

  <rule>
    <id />
    <action permission="block">
      <message>Blocked by corporate. Contact J. Smith, [email protected], if you need to run this app.</message>
    </action>
  </rule>
</ruleset> 

Example 10-7 Include Customer Data in the Rule Set

The customer element enables you to provide comments, debug information, or other data about the rules and rule set. Starting in Deployment Rule Set 1.2, this information is written to the deployment trace file and the Java console when they are enabled. This example shows customer information for the rule set and for two of the rules. The XML elements used in the customer element is for illustration purposes, any valid XML can be used.

<ruleset version="1.2+">
  <rule>
    <id location="https://host.example.com/verified-apps" />
    <action permission="run" />
    <customer>Allowing applications from https://host.example.com, which has been validated as a secure site</customer>
  </rule>

  <customer>
     <warning font=bold>Run rule not matched.</warning>
     <text>Application will either be blocked or will show security dialogs.</text>
  </customer>

  <rule>
    <id location="*.example.com" />
    <action permission="default" />
  </rule>

  <rule>
    <id /> 
    <action permission="block">
      <message>Blocked by corporate. Contact J. Smith, [email protected], if you need to run this app.</message>
    </action>
    <customer>
       <warning font=bold>Blocked</warning>
       <text>No rule matched, application blocked by final rule.</text>
    </customer>
  </rule>
</ruleset>

Java Deployment Rule Set DTD

The following example shows the DTD for the version 1.3 of the Deployment Rule Set. Version 1.3 is supported by 8u72 and higher. Version 1.2 is supported by JRE 8u60 and higher. Version 1.1 is supported by JRE 8u20 and higher. Version 1.0 is supported by JRE 7u40 and higher. Items introduced after version 1.0 are noted.

<!ELEMENT ruleset (rule*, customer*)>
<!ATTLIST ruleset version CDATA #REQUIRED>
 
<!ELEMENT rule (id, action, customer*)>
 
<!-- checksum introduced in 1.2, jnlp-checksum introduced in 1.3 -->
<!ELEMENT id (certificate?, checksum?, jnlp-checksum*)>
<!ATTLIST id title CDATA #IMPLIED>
<!ATTLIST id location CDATA #IMPLIED>
 
<!-- jnlp-checksum introduced in 1.3 -->
<!ELEMENT jnlp-checksum EMPTY>
<!ATTLIST jnlp-checksum hash CDATA #REQUIRED>
 
<!ELEMENT certificate EMPTY>
<!ATTLIST certificate algorithm CDATA #IMPLIED>
<!ATTLIST certificate hash CDATA #REQUIRED>
 
<!-- checksum introduced in 1.2 -->
<!ELEMENT checksum EMPTY>
<!ATTLIST checksum algorithm CDATA #IMPLIED>
<!ATTLIST checksum hash CDATA #REQUIRED>
 
<!ELEMENT action (message?)>
<!ATTLIST action permission (run | block | default) #REQUIRED>
<!ATTLIST action version CDATA #IMPLIED>
<!ATTLIST action force (true|false) "false">  <!-- force introduced in 1.1 -->
 
<!ELEMENT message (#PCDATA)>
<!ATTLIST message locale CDATA #IMPLIED>

<!ELEMENT customer ANY>