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.
16.4.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.
16.4.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.
16.4.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.)
Sections
