securitypolicy_rp.html

J2ME MIDP2.0 final specification

the BIT STRING subjectPublicKey (excluding the tag, length, and
number of unused bits) of that certificate.  This method is
commonly used to compute key identifiers, especially to accelerate
trust-chain building [RFC3280, §4.2.1.2]. The implementation
MUST NOT assume for optimization purposes that X.509 key identifiers
or PKCS#15 labels are the correct value; however, and MUST compute
the hash themselves. This hash MUST be used by the device to decide
when a given program should be deactivated, as specified in Section
8. 
</p>
<h4>3.3 Trusted Third-Party Domain</h4>
<p class="Paragraph">There is no explicit limitation on the number of
domains available in a given device.  Applications that
authenticate to a trusted third-party root certificate MUST belong to
a Third-Party domain. If a given device has no Third-Party domain in
the policy file, then a third-party application MUST be authorized
and installed only as untrusted and MUST belong to the Untrusted
domain. 
</p>
<p class="Paragraph">Third-party root certificates downloaded after device
manufacture MUST NOT be used for authentication of MIDlets.</p>
<p class="Paragraph">The implementation MUST present the user with the <i>Subject</i>field
of the signing certificate of a MIDlet whenever a new MIDlet is
installed in the Third-Party domain. This user notification MUST take
place at MIDlet installation. When the user is
prompted to grant permissions to an application, the prompt MUST
identify the trusted source with the <i>Subject</i> field of the signing
certificate.</p>
<p class="Paragraph">The user must be able to delete or disable trusted third-party
certificates. If a third-party root certificate is to be deleted, the
implementation SHOULD warn the user of the consequence of the
deletion adequately. The user MUST be able to enable a disabled
third-party root certificate. A disabled third-party root certificate
MUST NOT be used to verify downloaded MIDlets. Furthermore,  if
a third-party root certificate is deleted or disabled (for example,
revoked, deleted, or disabled by the user) the Third-Party domain
must no longer be associated with this root certificate. If the user
chooses to delete the root certificate, implementation may provide an
option to delete the applications authenticated to it. 
</p>
<p class="Paragraph">Trusted third-party applications are not granted any permissions
<i>Allowed</i> by the Third-Party domain. All permissions granted by
the Third-Party domain are <i>User</i> permissions, that is, user
interaction is required for permission to be granted. Table 1
specifies the function groups and the available user permission
types for applications in the Third-Party domain. Tables 2 through 6
specify the mapping of permissions and APIs onto different function
groups.
</p>
<h4>3.4 Untrusted Domain</h4>
<p class="Paragraph"><b>MIDlets that are
unsigned will belong to the Untrusted domain.</b></p>
<p class="Paragraph">The implementation MUST inform the
user whenever a new MIDlet is installed in the Untrusted domain. The
notification MUST indicate that the application does not come from a
trusted source.  The user must be able to make an informed
decision based on the available information before granting
permissions to an application. 
</p>

<p class="Paragraph">When the user is prompted to grant
permissions to an application the prompt MUST indicate that the
application does not come from a trusted source.</p>
<p class="Paragraph">Untrusted applications MUST NOT gain read access directly to PIM
data through the API defined in JSR 75 (see Table 1 in Section 5).
Interactions between an untrusted application and the PIM data can be
enabled, however, by implementations of the javax.microedition.lcdui
package: when the application programmer sets the constraint
TextField.PHONENUMBER, an implementation of the TextField class MAY
propose that the user look up a number in his or her phone book and
copy it to the TextField item.  For example, when the TextField
item has input focus, the user can access a menu to enter the phone
book; when the user selects an entry in the phone book, the contents
of the selected entry are "copied and pasted" into the
TextField item.  
</p>
<p class="Paragraph">Table 1 specifies the function groups and the available user
permissions for applications in the Untrusted domain. Tables 2
through 6 specify the mapping of permissions and APIs onto different
function groups.</p>
<h2 class="ChapterTitle">4  Remotely Located Policy File</h2>
<p class="Paragraph">The MIDP 2.0 specification defines the generic
format for the policy file that can be read from removable media.
GSM/UMTS-compliant devices are not expected to use it in the first
phase, but rather to use a single policy file resident on the
device.  The possibility of remotely located policy files is
left for further consideration. 
</p>
<h2 class="ChapterTitle">5  Permissions for Downloaded MIDlet Suites</h2>
<p class="Paragraph"><b>Mapping MIDP 2.0 Permissions onto Function Groups in
Protected Domains</b></p>
<p class="Paragraph">A device with a small display may not be able to
present all permissions to the user in a single configuration
settings menu in a user-friendly manner. Therefore the device is not
required to present all individual permissions for user confirmation.
Rather, a certain higher-level action triggered by the protected
function should be brought to the user for acceptance.  The
high-level functions presented to the user essentially capture and
reflect the actions and consequences of the underlying individual
permissions. The function groups are as follows: 
</p>
<p class="Paragraph">Network/cost-related groups: 
</p>
<p class="Paragraph"><b>Phone Call</b> &#8211; the group represents permissions to
any function that results in a voice call. 
</p>
<p class="Paragraph"><b>Net Access</b> &#8211; the group represents permissions to any
function that results in an active network data connection (for
example GSM, GPRS, UMTS, etc&#8230;); such functions must be mapped to this
group.<br>
</p>
<p class="Paragraph"><b>Messaging</b> &#8211; the group represents permissions to
any function that allows sending or receiving messages (for example,
SMS, MMS, etc.) 
</p>

<p class="Paragraph"><b>Application Auto Invocation</b> &#8211; the group represents
permissions to any function that allows a MIDlet to be invoked
automatically (for example, push, timed MIDlets, etc.) 
</p>
<p class="Paragraph"><b>Local Connectivity</b> &#8211; the group represents
permissions to any function that activates a local port for further
connection (for example, COMM port, IrDa, Bluetooth, etc.) 
</p>
<p class="Paragraph">User-privacy-related groups: 
</p>
<p class="Paragraph"><b>Multimedia recording</b> &#8211; the group represents
permissions to any function that gives a MIDlet the ability to
capture still images, or to record video or audio clips.</p>
<p class="Paragraph"><b>Read User Data Access</b> &#8211; the group represents
permissions to any function that gives a MIDlet the ability to read a
user's phone book, or any other data in a file or directory. 
</p>
<p class="Paragraph"><b>Write User Data Access</b> &#8211; the group represents
permissions to any function that gives a MIDlet the ability to add or
modify a user's phone book, or any other data in a file or directory.
</p>
<p class="Paragraph">Whenever new features are added to the MIDP they should be
assigned to the appropriate function group. In addition, APIs that
are specified elsewhere (that is, in other JSRs) but rely on the MIDP
security framework should also be assigned to an appropriate
function group. If none of the function groups defined in this
section is able to capture the new feature and reflect it to the user
adequately, however, then a new function group MUST be defined in
this document.</p>
<p class="Paragraph">If a new function group is to be added, the following should be
taken into consideration: the group to be added MUST not introduce
any redundancy to the existing groups, the new group MUST be capable
of protecting a wide range of similar features. The latter
requirement is to prevent introducing narrowly scoped groups. 
</p>
<p class="Paragraph">It is the function groups and not the individual permissions that
should be presented when the user is prompted.  Furthermore, it
is the function groups that should be presented to the user in the
settings of a given MIDlet suite. 
</p>
<p class="Paragraph">Table 1 presents the policy that must be enforced using the
security framework as defined in MIDP 2.0. The table specifies the
available permission settings for each function group defined. 
Settings that are effective at the time the MIDlet is invoked for the
first time, and remain effective until the user changes them in the
MIDlet's configuration menu, are called "default settings."
  Settings available to the user in the configuration menu, to
which the user can change from a default setting, are called "other
settings." Together, default and other settings form a pool of
available configuration settings for the MIDlet. Default and other
settings are presented for each function group and each protection
domain. The naming of the function groups is implementation-specific
but MUST follow the guidelines of the function-group names defined in
this document as well as the definitions of these groups. 
</p>
<p class="Paragraph">Tables 2 through 5 present individual permissions defined in the
MIDP 2.0 and other JSRs, and map to the function groups specified
in this section. An individual permission MUST occur in only one
function group. 
</p>
<p class="Paragraph">It is not mandatory for manufacturer and operator-trusted
applications to adhere to the settings defined in the following
tables, as the necessary user prompts should be given by the
application itself.  It is recommended that the manufacturer and
operator-trusted applications adhere to the permission guidelines
provided in the tables, and present appropriate prompts to the user
for the functions identified as security-protected.  <br>  
</p>
<p align="center">  Table 1: Function groups and user settings 
</p>
<table width="72%" border="1" cellpadding="0" cellspacing="3" align="center">
	<tbody><tr>
		<td width="24%">
			<p style="border: medium none ; padding: 0cm;">
			<b>Function group</b></p>
		</td>
		<td colspan="2" width="32%">
			<p style="border: medium none ; padding: 0cm;">
			<b> Trusted Third-Party  domain</b></p>
		</td>
		<td colspan="2" width="40%">
			<p style="border: medium none ; padding: 0cm;">
			<b> Untrusted  domain</b></p>
		</td>
	</tr>
	<tr>
		<td rowspan="2">
			<p style="border: medium none ; padding: 0cm;">
			 Phone Call</p>
		</td>
		<td>
			<p style="border: medium none ; padding: 0cm;">
			 default setting</p>
		</td>
		<td>
			<p style="border: medium none ; padding: 0cm;">
			 Oneshot</p>
		</td>
		<td>
			<p style="border: medium none ; padding: 0cm;"> default
			setting</p>
		</td>
		<td>
			<p style="border: medium none ; padding: 0cm;">
			 Oneshot</p>
		</td>
	</tr>
	<tr>
		<td>
			<p style="border: medium none ; padding: 0cm;">
			 other settings</p>
		</td>
		<td>
			<p style="border: medium none ; padding: 0cm;">
			 No</p>
		</td>
		<td>
			<p style="border: medium none ; padding: 0cm;">
			 other settings</p>
		</td>
		<td>
			<p style="border: medium none ; padding: 0cm;">
			 No</p>
		</td>
	</tr>
	<tr>
		<td rowspan="2" width="24%">
			<p style="border: medium none ; padding: 0cm;">
			 Net Access</p>
		</td>
		<td width="14%">
			<p style="border: medium none ; padding: 0cm;">
			 default setting</p>
		</td>
		<td width="18%">
			<p style="border: medium none ; padding: 0cm;">
			 Session</p>
		</td>
		<td width="13%">
			<p style="border: medium none ; padding: 0cm;">
			 default setting</p>
		</td>
		<td width="26%">
			<p style="border: medium none ; padding: 0cm;">
			 Session</p>
		</td>
	</tr>
	<tr>
		<td width="14%">
			<p style="border: medium none ; padding: 0cm;">
			 other settings</p>
		</td>
		<td width="18%">
			<p style="border: medium none ; padding: 0cm;">
			 Blanket, No</p>
		</td>
		<td width="13%">
			<p style="border: medium none ; padding: 0cm;">
			 other settings</p>
		</td>
		<td width="26%">
			<p style="border: medium none ; padding: 0cm;">
			 No</p>
		</td>
	</tr>
	<tr>
		<td rowspan="2" width="24%">
			<p style="border: medium none ; padding: 0cm;">
			 Messaging</p>
		</td>
		<td width="14%">
			<p style="border: medium none ; padding: 0cm;">
			 default setting</p>
		</td>
		<td width="18%">
			<p style="border: medium none ; padding: 0cm;">
			 Oneshot</p>
		</td>
		<td width="13%">
			<p style="border: medium none ; padding: 0cm;">
			 default setting</p>
		</td>
		<td width="26%">
			<p style="border: medium none ; padding: 0cm;">
			 Oneshot</p>
		</td>
	</tr>
	<tr>
		<td width="14%">
			<p style="border: medium none ; padding: 0cm;">
			 other settings</p>
		</td>
		<td width="18%">
			<p style="border: medium none ; padding: 0cm;">
			 No</p>
		</td>
		<td width="13%">
			<p style="border: medium none ; padding: 0cm;">
			 other settings</p>
		</td>
		<td width="26%">
			<p style="border: medium none ; padding: 0cm;">
			 No</p>
		</td>
	</tr>
	<tr>
		<td rowspan="2" width="24%">
			<p style="border: medium none ; padding: 0cm;">
			 Application Auto Invocation</p>
		</td>
		<td width="14%">
			<p style="border: medium none ; padding: 0cm;">
			 default setting</p>
		</td>
		<td width="18%">
			<p style="border: medium none ; padding: 0cm;">
			 Oneshot</p>
		</td>
		<td width="13%">
			<p style="border: medium none ; padding: 0cm;">
			 default setting</p>
		</td>
		<td width="26%">
			<p style="border: medium none ; padding: 0cm;">
			 Oneshot</p>
		</td>
	</tr>
	<tr>
		<td width="14%">
			<p style="border: medium none ; padding: 0cm;">
			 other settings</p>
		</td>