|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
You can read the whole series on certificates:
Your public key and private key provide a mechanism by which you can establish, and others can verify, your online identity -- an important ingredient for trusted transactions. Your public key, properly vouched for by a certificate authority (CA), offers a third party with a reliable means to check your identity -- provided your private key remains private.
Unfortunately, public-key cryptography is effective only if your private key is secret. If a hostile entity obtains a copy of your private key, that entity can impersonate you electronically. Less critically, if you lose your private key, you lose your ability to electronically prove your identity.
For those reasons, an infrastructure built on public-key cryptography, certificates, and CAs must include the functionality of certificate revocation as well as certificate issuance. The issuance of a certificate states that the CA believes, to the best of its ability, that the entity named in the issued certificate is associated with the public key enclosed in the issued certificate. The revocation of a certificate indicates that the CA is no longer willing to make that claim because of the issues raised above or any number of other concerns.
A CA formally revokes a previously issued certificate by including information that identifies it -- its serial number -- in a periodically published CRL.
A CRL is literally a digitally signed list that contains the serial numbers and associated data (such as the revocation date) of public-key certificates that were issued and subsequently revoked by the CA. When published by a CA, a CRL is placed in a public repository or otherwise made widely available so that applications can check the revocation status of certificates before accepting them.
RFC 2459, published by the Public Key Infrastructure X.509 (PKIX) working group of the Internet Engineering Task Force (IETF), defines the format of X.509 CRLs. Like X.509 certificates, the format of an X.509 CRL is specified in ASN.1 (Abstract Syntax Notation One) notation. The ASN.1 Distinguished Encoding Rules (DER) defines a platform-independent binary format.
Just as I did last month, I will avoid going into the depths of ASN.1 notation and DER encoding and instead concentrate on Sun's CRL API.
As it does with certificates, the Java CRL API provides both a generic and an X.509-specific interface to CRL functionality.
The java.security.cert.CRL class defines the generic interface. The java.security.cert.X509CRL class, a subtype of the generic java.security.cert.CRL class, defines the X.509-specific interface.
java.security.cert