See: Description
Interface | Description |
---|---|
Certificate |
Interface common to certificates.
|
Exception | Description |
---|---|
CertificateException |
The
CertificateException encapsulates an error that
occurred while a Certificate is being used. |
Certificate
interface provides to the
application information about the origin and type of the certificate.
The CertificateException
provides information about
failures that may occur while verifying or using certificates.
The X.509 Certificate Profile below defines the format and usage of certificates. X.509 Certificates MUST be supported. Other certificate formats MAY be supported. The implementation MAY store only the essential information from certificates. Internally, the fields of the certificate MAY be stored in any format that is suitable for the implementation.
Unless otherwise noted, passing a null argument to a constructor
or method in any class or interface in this package will cause
a NullPointerException
to be thrown.
Devices implementing this specification are expected to operate using standard Internet and wireless protocols and techniques for transport and security. The current mechanisms for securing Internet content is based on existing Internet standards for public key cryptography:
A version 1 X.509 certificate MUST be considered equivalent to a version 3 certificate with no extensions. At a minimum, a device conforming to this profile MUST recognize key usage (see RFC5280 sec. 4.2.1.3), basic constraints (see RFC5280 sec. 4.2.1.10).
Although a conforming device may not recognize the authority and subject key identifier (see RFC5280 sec. 4.2.1.1 and 4.2.1.2) extensions it MUST support certificate authorities that sign certificates using the same distinguished name but using multiple public keys.
Implementations MUST be able to process certificates with unknown distinguished name attributes.
Implementations MUST be able to process certificates with unknown, non-critical certificate extensions.
Devices must be able to process certificates that are not self-signed root CA certificates of size up to at least 1500 bytes.
A device MUST support the RSA signature algorithm with the
SHA-1 hash function sha1WithRSAEncryption
as defined by PKCS #1 [RFC3447].
Devices that support these algorithms MUST be capable of
verifying signatures made with RSA keys of length up to and
including 2048 bits.
Devices SHOULD support signature algorithms
md2WithRSAEncryption
and
md5WithRSAEncryption
as defined in [RFC3447].
Devices that support these algorithms MUST be capable of
verifying signatures made with RSA keys of length up to and
including 2048 bits.
Devices MUST recognize the extended key usage extension defined
of RFC2818 if it
is present and is marked critical and when present MUST verify that
the extension contains the id-kp-serverAuth
object
identifier (see RFC5280 sec. 4.2.1.13).
SSL and TLS allow the web server to include the redundant root certificate in the server certificate message. In practice this certificate may not have the basic constraint extension (it is most likely a version 1 certificate), a device MUST ignore the redundant certificate in this case. Web servers SHOULD NOT include a self-signed root CA in a certificate chain.
Copyright (c) 2014, Oracle and/or its affiliates. All Rights Reserved. Use of this specification is subject to license terms.