pkitrust.html

是MIDP 的API 查詢文件, 大家可以看一下裡面的index.html, 再用Package 或 Class 名字來查.

	  signature verification using the first successfully verified
	  certificate path is used for
	  authentication and authorization. </td>
      </tr>
      <tr>
	<td>Only one full certificate path
	  established and validated</td>
	<td>Implementation proceeds with the
	  signature verification </td>
      </tr>
    </table>

    <H3>Verify the MIDlet Suite JAR</H3>
    <OL>
      <LI>Get the public key from the verified signer
	certificate (above).
      </LI>
      <LI>Get the <CODE>MIDlet-Jar-RSA-SHA1</CODE>
	attribute from the application descriptor.
      </LI>
      <LI>Decode the attribute value from base64 yielding a PKCS #1
	signature [RFC2437].
      </LI>
      <LI>Use the signer's public key,  signature, and SHA-1
	digest of the JAR, to verify the signature. If the signature
	verification fails, reject the application descriptor and MIDlet
	suite. The implementation MUST NOT install the JAR on failure or
	allow MIDlets from the MIDlet suite to be invoked. 
      </LI>
    </OL>

    <P>Once the steps of verifying the certificate, verifying the
      signature and verifying the JAR all succeed then the MIDlet
      suite contents are known to be intact and the identity of the
      signer is known. 
      This process must be performed during installation.</P>

    <H4>Summary of MIDlet suite source verification results</H4>

    <P>It is essential that the steps performed to verify the digital
      signature as described above lead to the proof of the identity
      of the MIDlet suite signer. The results of the verification have
      a direct impact on authorization. The
      following, Table 2, summarizes the states to which the signature
      verification led and which are further used for
      authorization at install time.</P>

    <P>Table 2. Summary of MIDlet suite source verification</P>

    <table BORDER="1" CELLSPACING="1" CELLPADDING="7">
      <thead>
	<tr>
	  <th WIDTH="50%"><b>Initial state</b></th>
	  <th WIDTH="50%"><b>Verification result</b></th>
	</tr>
      </thead>
      <tr>
	<td>JAD not present, JAR
	  downloaded</td> 
	<td>Authentication can not be
	  performed, may install JAR. MIDlet suite is treated as
	  untrusted</td> 
      </tr>
      <tr>
	<td>JAD present but is JAR is
	  unsigned </td> 
	<td>Authentication can not be
	  performed, may install JAR. MIDlet suite is treated as
	  untrusted</td> 
      </tr>
      <tr>
	<td>JAR signed but no root
	  certificate present in the keystore to validate the certificate
	  chain</td> 
	<td>Authentication can not be
	  performed, JAR installation is not allowed</td> 
      </tr>
      <tr>
	<td>JAR signed, a certificate on the
	  path is expired</td>
	<td>Authentication can not be
	  completed, JAR installation is not allowed</td>
      </tr>
      <tr>
	<td>JAR signed, a certificate
	  rejected for reasons other than expiration</td>
	<td>JAD rejected, JAR installation
	  is not allowed</td>
      </tr>
      <tr>
	<td>JAR signed, certificate path
	  validated but signature verification fails</td>
	<td>JAD rejected, JAR installation
	  is not allowed</td>
      </tr>
      <tr>
	<td>JAR signed, certificate path
	  validated, signature verified</td>
	<td>JAR installation is allowed</td>
      </tr>
    </table>
    
    <H3>Caching of Authentication and Authorization Results</H3>
    <P>
      The implementation of the authentication and authorization
      process may store and transfer the results for subsequent use
      and MUST ensure that the cached information practically can not
      be tampered with or otherwise compromised between the
      time it is computed from the JAR, application descriptor, and
      authentication information and the authorization information is
      used.
    </P>
    
    <P>
      It is essential that the MIDlet suite and security
      information used to authenticate and authorize a MIDlet suite
      is not compromised, for example, by use of removable media or
      other access to MIDlet suite storage that might be corrupted.
    </P>


    <H3>Security in Split-VM Implementations</H3>
    <P>
      In environments that make use of a split VM (CLDC 5.4.6), it is
      possible to implement the security mechanism using JARs but this
      relies on converting the JAR to the device format when the JAR
      enters the network while faithfully preserving the semantics of
      the MIDlet.  Once the conversion has happened, the device format
      of the application must be secured against tampering and retain
      its authorized permissions.  This network security is often based
      on similar digital signature techniques to MIDlet security and
      it may be the case that this network security infrastructure is
      already present and active. If and only if this kind of network
      security infrastructure already exists and it can support all
      forms of protection required by this specification (and any
      future JSRs based on this specification), a permissible
      implementation of MIDlet Suite Security can be based on
      authenticating and authorizing the device format of the MIDlet
      since these implementation formats are the actual executable
      content that will be used on the device.  The details of
      authenticating and authorizing a device format version of a
      MIDlet suite are implementation specific and thus not covered by
      this specification.
    </P>

    <H2><A NAME=profile>MIDP X.509 Certificate Profile for Trusted
	  MIDlet Suites</A></H2>

    <P>Secured trusted MIDlet suites utilize the same base
      certificate profile as does HTTPS.  The profile is based on the
      WAP Certificate Profile, WAP-211-WAPCert-20010522-a [WAPCert]
      which is based on RFC2459 Internet X.509 Public Key
      Infrastructure Certificate and CRL Profile [RFC2459].  Refer to
      the package documentation for
      <CODE>javax.microedition.pki</CODE> for details.</P>

    <H3>Certificate Processing for OTA</H3>
    <P>Devices MUST recognize the key usage extension and when present
      verify that the extension has the <CODE>digitalSignature</CODE> bit set. 
      Devices MUST recognize the critical extended key usage extension
      and when present verify that the extension contains the
      <CODE>id-kp-codeSigning</CODE> object identifier (see RFC2459
      sec. 4.2.1.13).</P>

    <P>The application descriptor SHOULD NOT include a self-issued 
      root certificate in a descriptor certificate chain. However MIDP
      devices SHOULD treat the certificate as any other in a chain and
      NOT explicitly reject a chain with a X.509v3 self-issued CA
      certificate in its chain.</P>

    <H3><A NAME=revocation>Certificate Expiration and Revocation</A></H3>
    <P>Expiration and revocation of certificates
      supplied in the application descriptor is checked during the
      authorization procedure, specifically during certificate path
      validation. Certificate expiration is checked locally on the
      device as such information is retrievable from the certificate
      itself. Certificate expiration verification is an intrinsic and
      mandatory part of certificate path validation.</P>

    <P>Certificate revocation is a more complex check as it
      requires sending a request to a server and the decision is made
      based on the received response. Certificate revocation can be
      performed if the appropriate mechanism is implemented on the
      device. Such mechanisms are not part of MIDP implementation and
      hence do not form a part of MIDP 2.0 security framework.</P>

    <P>If certificate revocation is implemented in the device, it SHOULD
      support Online Certificate Status protocol (OCSP)
      [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.</P>

    <H3>Examples of MIDlet Suite Signing</H3>
    <P>There are many ways to structure protection domain root
      certificates and their associated signing policies.  These
      examples are provided to illustrate some of the concepts in this
      specification and are not meant to limit the ways MIDlet PKI
      signing can be used.  The examples allow MIDlets to be
      revoked (provided the device supports certificate revocation)
      but at differing granularities.</P>


    <H4>Example 1 - Developer Owns Signing Certificate</H4>

    <P>This encodes the origin of the MIDlet suite into the JAD (via
      the identity of the signer). If the certificate is revoked,
      all of the developer's signed MIDlets on every device for every
      user will have their execution permissions revoked.</P>

    <OL>
      <LI>Developer creates MIDlet network application</LI>

      <LI>Developer encodes permissions into JAR manifest and creates
	final MIDlet JAR</LI>
      
      <LI>Developer generates a private-public key pair with a
	signing certificate and has the certificate signed by one or
	more protection domain root certificates</LI>

      <LI>The developer's certificate is used to sign the MIDlet JAR
	and create the associated JAD entries</LI>

      <LI>MIDlet JAR can be distributed with a suitably populated JAD
	and run on a MIDP 2.0 compliant device with the appropriate
	protection domain root certificate</LI>
    </OL>


    <H4>Example - Protection Domain Stakeholder Owns Signing
      Certificate</H4>
    
    <P>This encodes the signers identity (not the MIDlet suite
      developer) into the JAD. If the certificate is revoked, all
      MIDlets signed with this particular certificate will have their
      execution permissions revoked.</P>

    <OL>
      <LI>Developer creates MIDlet network application</LI>

      <LI>Developer encodes permissions into JAR manifest and creates
	final MIDlet JAR</LI>

      <LI>The protection domain stakeholder's signing certificate (not
	necessarily the root cert) is used to sign the MIDlet JAR and
	create the associated JAD entries</LI>

      <LI>MIDlet JAR can be distributed with a suitably populated JAD
	and run on a MIDP 2.0 compliant device with the appropriate
	protection domain root certificate</LI>
    </OL>

  </BODY>
</HTML>