Security Policy

Introduction

This chapter sketches the cornerstones of a Security Policy architecture for implementations of utilizing wireless data technologies such as GSM, UMTS, CDMA, WiMAX etc.

While all implementations of the Security Policy MUST follow the security framework specified in Security for Applications, the details described in this chapter are mainly targeting a PKI-based scheme as defined in Application Suites Trust Model Using X.509 PKI. This is only one possibility though (and the one of choice if backward compatibility to IMP-NG is required). A MEEP-1.0 implementation can also decide not to require any authentication at all (in this case all application suites are always trusted and gain full access to any available functionality; a security policy is not needed in this case). Implementations are also free to implement an alternative scheme like authentication via a back-end mechanism or via a mutually trusted network connection. The definition of such schemes is outside the scope of this specification.

Security for Applications defines the framework for authenticating the source of an application suite and authorizing an application suite to perform protected functions by granting permissions it may have requested, based on the security policy on the device. It also identifies functions that are deemed security vulnerable and defines permissions for those protected functions. Additionally, it specifies the common rules for APIs that can be used together with this specification but are defined in other specifications. This chapter defines extensions to the base application suite security framework in the following areas :

Protection Domains

A protection domain is a set of permissions that can be granted to an application. The representation of a protection domain and its security policy is implementation specific. An application suite MUST belong to one and only one protection domain. An application suite is bound to a Protection Domain based on its signature. Application suites that are unsigned as per the ME 8 Security Framework MUST be bound to the Unidentified Third Party Protection Domain. If a signed application suite cannot be identified, that application suite is bound to the Unidentified Third Party Protection Domain. If the PKI based mechanism is used, this applies if none of its associated certificate chains verify against a Protection Domain Root Certificate. If application suites can be identified via more than one way, it depends on the definition of the authentication mechanism, to which domain the application suite is bound. If for example the PKI based authentication mechanism is implemented, for application suites that have more than one certificate chain found in the JAD, it may be possible that more than one certificate chain verifies against a Protection Domain Root Certificate. In such a case, the certificate chain with the smallest value <n> in the MIDlet-Certificate-<n>-<m> attribute determines the domain to which the application suite is bound.

Each LIBlet that is a dependency of an application is associated with the protection domain of the application and is also authenticated by the authentication mechanism of the application. If the PKI based mechanism as defined in Application Suites Trust Model Using X.509 PKI section is used, then the set of certificates that authenticate a LIBlet is the union of the certificates that authenticate the applications that depend on the LIBlet. The set of domains and certificates are used during provisioning (if supported) to determine which LIBlets may be bound as a Service then. See the provisioning step for resolving service dependencies.

This chapter defines the following protection domains:

Definition of additional protection domains, beyond Manufacturer, Operator, Identified Third Party and Unidentified Third Party Protection Domains, is allowed by this specification. The policy for additional protection domains is outside the scope of this specification. Additional protection domains intended to meet Network Operator requirements are referred to as Operator Supplementary Protection Domains.

The assignment of an application suite to a protection domain has to be handled as follows:

For a PKI based authentication mechanism this means, that for any X.509 Certificate under which an application is signed, the device MUST decide whether the certificate is issued under the certification hierarchy that leads to a Protection Domain Root Certificate.

Applications bound to the Unidentified Third Party Protection Domain and the Identified Third Party Protection Domain run in an unprivileged environment wherein the policy decides on the permissions given to the application. In contrast to this, applications in the Operator Protection Domain and the Manufacturer Protection Domain run in a privileged environment. However, the privileges given to an application might still depend on the specific Protection Domain to which the application is bound.

Manufacturer and Operator Protection Domains As Handled by a PKI Based Authentication Mechanism

The following sections describe how Manufacturer and Operator Protection Domains have to be handled if the PKI based authentication mechanism as defined in the Application Suites Trust Model Using X.509 PKI section is used. Other mechanisms have to define the handling of those domains outside of this specification.

Manufacturer Protection Domain (PKI Based Authentication)

The Manufacturer Protection Domain Root Certificate is used to verify manufacturer application suites and MUST be mapped onto the security policy for the Manufacturer Protection Domain on the device. A device MUST support the security policy for the Manufacturer Protection Domain.

If the Manufacturer Protection Domain Root Certificate is NOT available on the device, the Manufacturer Protection Domain MUST be disabled.

The Manufacturer Protection Domain Root Certificate can be added, deleted or modified only by the manufacturer, who may use an update mechanism whose details are outside the scope of this specification. Any new or updated Manufacturer Protection Domain Root Certificate MUST be associated with the security policy for the Manufacturer Protection Domain on the device. Application suites verified by a previous Manufacturer Protection Domain Root Certificate MUST be disabled.

The Manufacturer Protection Domain imposes no restriction on the capabilities of this specification and other JSRs.

The following OID identifies Manufacturer Protection Domain Root Certificate:


ASN.1 :
  {iso(1)org(3)dod(6)internet(1)private(4)enterprises(1)sun(42)
  products(2)javaXMLsoftware(110)midp(2)spec(2)gsm-policy(2)manufacturer(2)}
URN :
  urn:oid:1.3.6.1.4.1.42.2.110.2.2.2.2
                

Operator Protection Domain (PKI Based Authentication)

An Operator Protection Domain Root Certificate is used to verify operator application suites and MUST be mapped onto the security policy for the Operator Protection Domain on the device. Operator Supplementary Protection Domain Root Certificates MUST be mapped onto the designated policy, or in its absence they MUST be mapped onto the Operator Protection Domain. The following rules apply equally to the Supplementary Protection Domains as well.

A device MUST support the security policy for the Operator Protection Domain.

A device MUST support the mechanism [SCPROV] to read Root Certificates  stored in the smart card (for example, SIM, USIM or WIM).

Additionally, the device MUST support Operator Protection Domain Root Certificates stored on the device.

There is at a maximum one Operator Protection Domain Root Certificates available at either of two specified locations: the smart card or on the device. For example there may be up to one enabled Operator Protection Domain Root Certificate per smart card and up to one enabled device resident Operator Protection Domain Root Certificate. There is more than one Operator Protection Domain Root Certificate if Operator Supplementary Protection Domain Root Certificates are mapped onto the Operator Protection Domain.

However, if Operator Protection Domain Root Certificates are found on the device and on the smart card (e.g. SIM, USIM or WIM) at the same time, the root certificate found on the smart card will have a higher priority than a device resident root certificate. Therefore, it is recommended for an operator to put the same root certificate on its smart cards as root certificates which were previously put on its devices (if that's the case for a progressive introduction of root certificates on the SIM card for example). In this way the operator ensures that existing applications will continue to be able to execute when introducing the smart card which contains the root certificate.

If an Operator Protection Domain Root Certificate is NOT available at the specified location in either the smart card or on the device the Operator Protection Domain MUST be disabled.

Potential consequences of a change of the smart card are described in Application Download and Execution While Roaming and After Changing the Smart Card.

Application suite execution in the Operator Protection Domain may be limited by the MIDlet-Operator-Allowed attribute. If this Application Attribute is present, the implementation MUST search for a tuple that matches the MCC-MNC portion of IMSI fetched from the currently inserted SIM against those listed in the attribute. If no match is found, applications from the application suite MUST NOT be launched. The check MUST be performed before execution of any application in the suite. If this attribute is not present, the implementation MUST NOT limit Operator Protection Domain application execution based on network.

The Operator Protection Domain Root Certificate MUST only be deleted or modified by the operator, who may use an update mechanism whose details are outside the scope of this specification.

Any new or updated Operator Protection Domain Root Certificate MUST be associated with the security policy for the Operator Protection Domain on the device.

Application suites verified by a non valid (for example, disabled) Operator Protection Domain Root Certificate MUST be disabled.

Before invoking an application the device MUST check whether or not the Protection Domain Root Certificate is still valid. If the Protection Domain Root Certificate that verified the application is no longer valid then the application MUST NOT be invoked.

Only if the Operator Protection Domain Root Certificate is valid during the installation process the device MUST continue the installation process. If this condition is not met, the device MUST NOT install the application and MUST respond as described in Provisioning, by sending the appropriate error code.

Root Certificates may be placed in the trustedCertificates Certificate Directory File (CDF) of a WIM, SIM, or USIM or on the device. If Root Certificates are stored directly on a SIM or USIM, that is, not under the WIM application, then they shall be stored in the EF trustedCertificates CDF located under DF ( [PKCS#15]), as defined by [SCPROV]. Root Certificates can be obtained only from the trusted CDF (the card holder can not update this directory) and not from any other directory of the smart card. Root Certificates found in the trustedCertificates file are considered to be Operator Protection Domain, Supplementary Operator Protection Domain 1 to 3 or Identified Third Party Protection Domain Root Certificates, depending on the trustedUsage field in the CommonCertificateAttributes associated with the certificate [PKCS#15] :

If the trustedUsage field is present and contains the following OID for key usage, then the certificate is to be considered an Operator Protection Domain Root Certificate:


ASN.1 :
  {iso(1)org(3)dod(6)internet(1)private(4)enterprises(1)sun(42)
  products(2)javaXMLsoftware(110)midp(2)spec(2)gsm-policy(2)operator(1)}
URN :
  urn:oid:1.3.6.1.4.1.42.2.110.2.2.2.1
                

If the trustedUsage field is present and contains the following OID for key usage, then the certificate is to be considered Protection Domain Root Certificate of a Supplementary Operator Protection Domain 1:


ASN.1 :
  {iso(1)org(3)dod(6)internet(1)private(4)enterprises(1)sun(42)
  products(2)javaXMLsoftware(110)midp(2)spec(2)gsm-policy(2)operatorSupplementary(4)}
URN :
  urn:oid:1.3.6.1.4.1.42.2.110.2.2.2.4
                

If the trustedUsage field is present and contains the following OID for key usage, then the certificate is to be considered Protection Domain Root Certificate of a Supplementary Operator Protection Domain 2:


ASN.1 :
  {iso(1)org(3)dod(6)internet(1)private(4)enterprises(1)sun(42)
  products(2)javaXMLsoftware(110)midp(2)spec(2)gsm-policy(2)operatorSupplementary(5)}
URN :
  urn:oid:1.3.6.1.4.1.42.2.110.2.2.2.5
                

If the trustedUsage field is present and contains the following OID for key usage, then the certificate is to be considered Protection Domain Root Certificate of a Supplementary Operator Protection Domain 3.


ASN.1 :
  {iso(1)org(3)dod(6)internet(1)private(4)enterprises(1)sun(42)
  products(2)javaXMLsoftware(110)midp(2)spec(2)gsm-policy(2)operatorSupplementary(6)}
URN :
  urn:oid:1.3.6.1.4.1.42.2.110.2.2.2.6
                

If the trustedUsage field contains the following OID, then the certificate is to be considered an Identified Third Party Protection Domain Root Certificate. See Identified Third Party Protection Domain


ASN.1 :
  {iso(1)org(3)dod(6)internet(1)private(4)enterprises(1)sun(42)
  products(2)javaXMLsoftware(110)midp(2)spec(2)gsm-policy(2)identifiedParty(3)}
URN :
  urn:oid:1.3.6.1.4.1.42.2.110.2.2.2.3
                

Figure 8-1 below summarizes the process of assigning Root Certificates obtained through [SCPROV] to Protection Domains.

Application suites installed in the Operator Protection Domain MUST store, along with the application itself, a hash of the Protection Domain Root Certificate under which the certificate used to sign the application was issued. The hash algorithm to be used is the following: starting with the Protection Domain Root Certificate, compute the 20-byte SHA-1 hash of the value of 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 have the correct value and MUST compute the hash themselves. In the event of a smart card change this hash MUST be used by the device to decide when a given application suite should be disabled.




    

Figure 8-1 : Assigning Root Certificates to Operator & Identified Third Party Protection Domains

SIM Root Search

Third Party Protection Domains As Handled by a PKI Based Authentication Mechanism

Differences between the two Third Party Protection Domains are :

The following section describes how Third Party Protection Domains can be identified if the PKI based authentication mechanism as defined in the Application Suites Trust Model Using X.509 PKI section is used. Other mechanisms have to define the identification of those domains outside of this specification.

Identified Third Party Protection Domain (PKI Based Authentication)

Applications that are authenticated using an Identified Third Party Protection Domain Root Certificate are mapped to the Identified Third Party Protection Domain. There is no explicit limitation on the number of Identified Third Party Protection Domain Root Certificates available either on the device or at the specified location in the smart card.

All Identified Third Party Protection Domain Root Certificates MUST be mapped onto the security policy for the Identified Third Party Protection Domain on the device. A device MUST implement the Identified Third Party Protection Domain. However, if there are no Identified Third Party Protection Domain Root Certificates available either on the device or at the specified location in the smart card, then the Identified Third Party Protection Domain MUST be disabled.

A device SHOULD support the mechanism [SCPROV] to read Identified Third Party Protection Domain Root Certificates stored in the smart card (for example, SIM, USIM or WIM). Additionally, Protection Domain Root Certificates for the Identified Third Party Domain MAY be stored on the device. A device MUST support at least one certificate storage mechanism. If both mechanisms are supported, the device MUST use Root Certificates from both mechanisms.

Root Certificates may be placed in the trustedCertificates Certificate Directory File (CDF) of a WIM, SIM, or USIM or on the device. If Root Certificates are stored directly on a SIM or USIM, that is, not under the WIM application, then they shall be stored in the EF trustedCertificates CDF located under DF ([PKCS#15]), as defined by [SCPROV]. Root Certificates can be obtained only from the trusted CDF (the card holder can not update this directory) and not from any other directory of the smart card.

If the trustedUsage field contains the following OID, then the certificate is to be considered an Identified Third Party Protection Domain Root Certificate. See Figure 8-1 for the details.


ASN.1 :
  {iso(1)org(3)dod(6)internet(1)private(4)enterprises(1)sun(42)
  products(2)javaXMLsoftware(110)midp(2)spec(2)gsm-policy(2)identifiedParty(3)}
URN :
  urn:oid:1.3.6.1.4.1.42.2.110.2.2.2.3
                

Any Root Certificates obtained after device manufacture MUST NOT have any effect on previously provisioned application suites. For subsequently provisioned application suites, such certificates MUST NOT be used as Protection Domain Root Certificates. This MUST NOT prevent obtaining Operator or Identified Third Party Authority Certificates from the specified location in a SIM, USIM or WIM.

If an Identified Third Party Protection Domain Root Certificate is to be deleted, the implementation MAY adequately warn the user of the consequence of the deletion. A disabled Identified Third Party Protection Domain Root Certificate MUST NOT be used to verify downloaded application suites.

Unidentified Third Party Protection Domain

Application suites that are unsigned will belong to the Unidentified Third Party Protection Domain. A device MUST support the security policy for the Unidentified Third Party Protection Domain.

The Unidentified Third Party Protection Domain for Unidentified Third Party application suites MUST allow access to :

Table 8-1 : Packages Allowed to Unidentified Third Party Protection Domain

API

Description

javax.microedition.rms

RMS APIs

javax.microedition.midlet

Application Lifecycle APIs

javax.microedition.media
javax.microedition.media.control

Multi-media APIs

The Unidentified Third Party Domain for Unidentified Third Party application suites MUST allow, access to protected APIs or functions:

Table 8-2 : Packages Allowed to Unidentified Third Party Protection Domain

API

Protocol

javax.microedition.io.HttpConnection

http

javax.microedition.io.HttpsConnection

https

It should be noted that versions of IMP referred to the Unidentified Third Party Protection Domain as "Untrusted".

Permissions for Application Suites

The security policy and permissions applied to all application suites that are installed on a device MUST conform to the requirements listed in this section, whether those application suites were preloaded or preinstalled or subsequently provisioned after device manufacture.

Mapping Permissions onto Function Groups in Protection Domains

The high level functions essentially capture and reflect the actions and consequences of the underlying individual permissions. These so-called function groups are as follows:

Whenever new features are added 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 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 adequately a new function group MUST be defined in this document by requesting an update to this document from MSA or this specification as appropriate.

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. The new function group SHOULD be sufficiently future-proof to contain new features added by future APIs and should not only concern the features being initially included in it.

Table 8-4 presents individual permissions and maps them to the function groups specified in this section. An individual permission MUST occur in only one function group.

Table 8-4 : Mapping Permissions to Function Groups

Permission

Protocol

Function group

javax.microedition.io.
HttpProtocolPermission("http://*").
Defined in [CLDC]

http

Net Access

javax.microedition.io.
HttpsProtocolPermission("https://*").
Defined in [CLDC]

https

Net Access

javax.microedition.io.
DatagramProtocolPermission("datagram://*").
Defined in [CLDC]

datagram

Low Level Net Access

javax.microedition.io.
DatagramProtocolPermission("datagram://").
Defined in [CLDC]

datagram server (without host)

Low Level Net Access

javax.microedition.io.
SocketProtocolPermission("socket://*").
Defined in [CLDC]

socket

Low Level Net Access

javax.microedition.io.
SocketProtocolPermission("socket://").
Defined in [CLDC]

server socket (without host)

Low Level Net Access

javax.microedition.io.
SSLProtocolPermission("ssl://*").
Defined in [CLDC]

ssl

Low Level Net Access

javax.microedition.io.
CommProtocolPermission("comm:*").
Defined in [CLDC]

comm

Local Connectivity

javax.microedition.io.PushRegistryPermission("*", "static,dynamic,alarm").

All

Application Auto Invocation

javax.microedition.io.IMCProtocolPermission("imc://*")

http

Inter IMlet Communication via IMC

Table 8-5 collects permissions that are not mapped to any function group and sets access level for Third Party Protection Domains. Permissions indicated as Permitted are granted to application suites as shown in the Table. Permissions indicated as Not Permitted are those that MUST NOT be mapped to any function group, and MUST NOT be available in either the Identified or Unidentified Third Party Protection Domain.

Table 8-5 : Permissions Not Mapped To Function Groups

Permission

Identified Third Party Protection Domain

Unidentified Third Party Protection Domain

java.util.PropertyPermission
("microedition.deviceid.*", "read").
See java.lang.System.getProperty(). Defined in [CLDC].

Permitted

Not Permitted

java.util.PropertyPermission
("microedition.subscriberid.*", "read").
See java.lang.System.getProperty(). Defined in [CLDC].

Permitted

Not Permitted

java.util.PropertyPermission
("microedition.locale", "read").
See java.lang.System.getProperty(). Defined in [CLDC].

Permitted

Permitted

java.util.PropertyPermission
("microedition.profile", "read").
See java.lang.System.getProperty(). Defined in [CLDC].

Permitted

Permitted

java.util.PropertyPermission
("microedition.platform", "read").
See java.lang.System.getProperty(). Defined in [CLDC].

Permitted

Permitted

java.util.PropertyPermission
("microedition.*", "read"), covers all "microedition.*" system properties not indicated above.
See java.lang.System.getProperty(). Defined in [CLDC].

Permitted

Permitted

javax.microedition.event.EventPermission
("*", "read")

Permitted Permitted

javax.microedition.event.EventPermission
("*", "register")

Permitted Permitted

javax.microedition.event.EventPermission
("*", "post")

Permitted Permitted

javax.microedition.event.EventPermission
("*", "postsystem")

Permitted Not Permitted

javax.microedition.io.HttpProtocolPermission("http://localhost");
javax.microedition.io.HttpsProtocolPermission("https://localhost");
javax.microedition.io.SocketProtocolPermission("socket://localhost");

Defined in [CLDC].
Permitted Not Permitted

javax.microedition.swm.SWMPermission
("manageSettings")

Permitted Not Permitted

javax.microedition.swm.SWMPermission
("manageSuite")

Permitted Not Permitted

javax.microedition.swm.SWMPermission
("installation")

Permitted Not Permitted

javax.microedition.swm.SWMPermission
("manageTask")

Permitted Not Permitted

javax.microedition.cellular.CellularPermission
("subscriber")

Permitted Not Permitted

javax.microedition.cellular.CellularPermission
("cellularNetwork")

Permitted Not Permitted

javax.microedition.power.PowerStatePermission
("set")

Permitted Not Permitted

javax.microedition.power.PowerStatePermission
("setUrgent")

Not Permitted Not Permitted

java.lang.RuntimePermission
("exitVM"). See java.lang.Runtime.exit() and java.lang.System.exit(). Defined in [CLDC].

Not Permitted Not Permitted

java.lang.RuntimePermission
("modifyThread"). See java.lang.Thread.checkAccess(). Defined in [CLDC].

Not Permitted Not Permitted

java.lang.RuntimePermission("*"). See java.lang.Thread.checkAccess(). Defined in [CLDC].

Not Permitted Not Permitted

javax.microedition.midlet.AutoStartPermission

Not Permitted Not Permitted

Auto Invocation And Push Registry Security Requirements

The PushRegistry is the primary Auto Invocation mechanism subject to the security policy.

The PushRegistry is protected using the security framework and permissions. The application suite must have the javax.microedition.io.PushRegistryPermission to register an alarm based launch, to register dynamically using the PushRegistry, or to make a static registration in the application descriptor.

The push mechanism uses protocols in which the device is acting as the server and connections can be accepted from other elements of the network. To use the push mechanisms the application suite will need the permission to use the server connection in addition to the {@code PushRegistryPermission}. For example, to register a program that can be started via push might use the following attributes in the manifest:

    MIDlet-Push-1: socket://:79, com.oracle.example.Sample, *
    MIDlet-Permissions-1: javax.microedition.io.PushRegistryPermission "socket:" "static,dynamic"
    MIDlet-Permissions-2: javax.microedition.io.SocketProtocolPermission "socket://"
    

Requirements on Restricted APIs

When permission is granted to a function group, this action effectively grants access to all individual permissions that have been requested under this function group. An implementation MUST guarantee that a SecurityException is thrown when the caller has not been granted the appropriate security permissions. If an application uses the capabilities defined in this and other APIs, the following rules MUST apply :

Wireless Messaging Third Party Domain Policy

The named permissions compatible with IMP-NG in the Messaging Function Group are defined in JSR 205 Wireless Messaging API 1.0.2, Appendix E (Deploying JSR 205 Interfaces on a MIDP 2.0 Platform [JSR205]. The corresponding permissions needed to deploy JSR 205 must be defined by a future revision of [JSR205].

Mobile Media Third Party Domain Policy

The permissions needed to deploy the [JSR 135] APIs are defined in the Multimedia Security Addendum to JSR 135 Mobile Media API, version 1.2 of [JSR 135].

Implementations MUST ensure that I/O access from the Mobile Media API follows the same security requirements as the Generic Connection Framework, as specified in the package documentation for javax.microedition.io. Example methods include javax.microedition.media.Player.start, javax.microedition.media.Player.prefetch, etc. When these methods are used to fetch the content for the player via an HTTP connection, the implementation MUST enforce the security requirements specified for HTTP and HTTPS.

Application Download and Execution While Roaming and After Changing the Smart Card

All previously authorized and installed application suites MUST act in accordance with the domain security policy when the device is roaming, or when the device smart card is changed.

Newly downloaded application suites are authenticated to a Protection Domain (to a Protection Domain Root Certificate if the PKI based authentication mechanism is used) currently available either on the device or at the specified location on the smart card (for example, SIM, USIM or WIM) and are authorized in accordance with the security policy.

If device roaming or a smart card change causes a failure to access network resources that the application was previously authorized to access, then the implementation MUST NOT throw a SecurityException. This failure is not related to application suite authorization, so the implementation MUST throw an IOException instead.

The permissions assigned to application suites installed in the Manufacturer and Unidentified Third Party Protection Domain MUST NOT be affected by changes of the smart card but application suites installed in the Operator or Identified Third Party Protection Domain MUST NOT execute if, after a smart card change, the authentication cannot be performed any more (for the PKI based authentication mechanism, this means that the Protection Domain Root Certificate that was used to authenticate the application suite to the Identified Third Party or Operator Protection Domain is no longer available) and until the authentification can be performed again (for a PKI based authentication mechanism this means: until the corresponding Protection Domain Root Certificate becomes available again).

If an application suite (either related to Operator or Identified Third Party Protection Domain) cannot be executed due to a smart card change, the implementation MUST NOT delete the application suite. In case of a trial to execute the application suite without a successful authentication (for PKI based authentication mechanism: if the authorizing Protection Domain Root Certificate is missing), a SecurityException MUST be thrown.

Revocation Checking

For all signed applications, a compliant implementation SHOULD check revocation status. For the PKI based authentication mechanism one possibility is the usage of the Online Certificate Status Protocol Mobile Profile as specified in [OSCP-MP]. Alternatively, an implementation of the PKI mechanism MAY implement OCSP according to [RFC2560]. If other certificate revocation protocols are supported, support for these other protocols may indicate that a certificate has been revoked; in this case, it is permissible to consider the certificate as revoked regardless of the result returned by the OCSP protocol.

Whatever mechanism is used, MEEP-1.0 implementations MUST support black-listing of principals and/or applications at any time.

Black-listing a principal includes the following steps:

  1. Immediately terminating execution of all applications by that principal
  2. Revoking the authentication (if any) of that principal
  3. Removing the security policy (if any) of all applications by that principal
  4. Black-listing the principal and all applications by that principal to prevent future accesses to protected APIs or resources

Black-listing an application includes the following steps:

  1. Immediately terminating execution of any and all running instances of the specific application (independent of the principal)
  2. Removing the security policy (and therefore the authorization if any) of the specific application
  3. Black-listing the specific application to prevent future accesses to protected APIs or resources

CRL ([RFC4523]) or OCSP ([RFC2560]) MAY be used for that, but implementation-defined mechanisms (such as a simple "push" blacklisting) are also allowed.


[1] Meaning for the PKI based authorization mechanism: signed by a certificate issued under the certification hierarchy of this certificate. Meaning for other authorization mechanisms has to be defined there.