MIDP X.509 Certificate Profile

16.4 MIDP X.509 Certificate Profile

MIDP 2.0 devices are expected use standard Internet and wireless protocols and techniques for their transport and security. The protocols and techniques are based on the following Internet standards for public key cryptography:

• WAP Certificate Profile Specification WAP-211-WAPCert-20010522-a [reference 15] (WAPCert).

  Devices must conform to all mandatory requirements in WAPCert, Appendix C, and should conform to all of its optional requirements except:

  • WAPCert Section 6.2, User Certificates for Authentication.

  • WAPCert Section 6.3, User Certificates for Digital Signatures.

• RFC 2437 – PKCS #1 RSA Encryption Version 2.0 [reference 6].

• RFC 2459 – Internet X.509 Public Key Infrastructure [reference 7].

  MIDP 2.0 implementations must support X.509 Certificates and are permitted to support other certificate formats. RFC 2459 [reference 7] contains sections that are not relevant to a MIDP 2.0 implementation, however. The WAP Certificate Profile does not mention these functions. Implementations should exclude:

  • Requirements from Paragraphs 4 of Section 4.2 – Standard Certificate Extensions. A MIDP 2.0 implementation does not need to recognize extensions that must or may be critical, including certificate policies, name constraints, and policy constraints.

  • Section 6.2 Extending Path Validation. Support for Policy Certificate Authority or policy attributes is not required.

1 Certificate Extensions

A MIDP implementation must consider a version 1 X.509 certificate equivalent to a version 3 certificate with no extensions.

A MIDP 2.0 device must recognize key usage (see RFC 2459 [reference 7] section 4.2.1.3) and basic constraints (see RFC 2459 [reference 7] section 4.2.1.10). It must be able to process certificates with unknown distinguished name attributes and unknown non-critical certificate extensions. It must also recognize the serialNumber attribute defined by WAPCert [reference 15] in distinguished names for Issuer and Subject.

Although a MIDP 2.0 device may not recognize a certificate's authority and subject key identifier extensions (see RFC 2459 [reference 7] sections 4.2.1.1 and 4.2.1.2), it must support certificate authorities that sign certificates using the same distinguished name using multiple public keys.

2 Certificate Size

A MIDP 2.0 device must be able to process certificates that are not self-signed root certificate authority (CA) certificates of sizes up to at least 1500 bytes.

3 Algorithm Support

A MIDP 2.0 device must support the RSA signature algorithm with the SHA-1 hash function, sha1WithRSAEncryption, as defined by PKCS #1. Devices that support these algorithms must be capable of verifying signatures made with RSA keys of lengths up to and including 2048 bits.

A MIDP 2.0 device should support both the md2WithRSAEncryption signature algorithms and the md5WithRSAEncryption signature algorithm as defined in RFC 2437 [reference 6]. A MIDP 2.0 device that supports these algorithms must be capable of verifying signatures made with RSA keys of lengths up to and including 2048 bits.

16.4.4 Certificate Processing for HTTPS

A MIDP 2.0 device must recognize the extended key usage extension defined in RFC 2818 [reference 11] if it is present and marked critical. When the extension is present, the device must verify that the extension contains the id-kp-serverAuth object identifier (see RFC 2459 [reference 7] section 4.2.1.13).

SSL and TLS allow the web server to include the redundant root certificate (a self-signed root CA certificate) in the server certificate message. Web servers should not include it in a certificate chain. The device must ignore it if it is a version 1 certificate (as it will most likely be.)