Creating the Signing Certificate
1. The signer will need to be aware of the authorization policy for the device and contact the appropriate
certificate authority. For example, the signer may need to send its distinguished name (DN) and public key
(normally, packaged in a certificate request) to a certificate authority.
2. The CA creates a RSA X.509 (version 3) certificate and returns it to the signer.
3. If multiple CA’s are used then all the signer certificates in the application descriptor MUST contain the
same public key.
Insert Certificates into the application descriptor
1. The certificate path includes the signer certificate and any necessary certificates but omitting the root
certificate. The root certificate will be found on the device.
2. Each certificate in the path is encoded (using base64 but without line breaks) and inserted into the
application descriptor as:
MIDlet-Certificate-<n>-<m>: <base64 encoding of a certificate>
<n>:= a number equal to 1 for first certification path in the descriptor or 1 greater than the previous number for
additional certification paths. This defines the sequence in which the certificates are tested to see if the
corresponding root certificate is on the device. See the Authenticating a MIDlet suite section below.
<m>:= a number equal to 1 for the signer’s certificate in a certification path or 1 greater than the previous
number for any subsequent intermediate certificates.
Creating the RSA SHA-1 signature of the JAR
1. The signature of the JAR is created with the signers private key according to the EMSA-PKCS1-v1_5
encoding method of PKCS #1 version 2.0 standard[RFC2437].
Protection Domain Root Certificate A certificate associated with a protection domain that the
device implicitly trusts to verify and authorize downloaded
Trusted MIDlet Suites using X.509 PKI
2. The signature is base64 encoded, formatted as a single MIDlet-Jar-RSA-SHA1 attribute without line
breaks and inserted in the application descriptor.
MIDlet-Jar-RSA-SHA1: <base64 encoding of Jar signature>