Cryptography Reference
In-Depth Information
certifi cates for security purposes, and so on. If you lose track of which private
key goes with which certifi cate, you're pretty much out of luck; it would be nice
to store them together so you can always go back to the source.
Storing the keys, of course, must be done in a secure way. The private key
may be the most sensitive bit of information in the entire system. The PKCS
#12 format was designed as a standardized way to transmit any arbitrary bit of
data securely — by encrypting it in a standardized way — but in practice it is
generally used to store certifi cates and their corresponding private keys. The
PKCS #12 format was standardized from an older, de facto standard named PFX.
As such, many applications that generate PKCS #12 fi les give them the exten-
sion .pfx. If you export a certifi cate and private key from Internet Explorer, for
instance, you get a .pfx fi le.
The PKCS #12 format is actually extremely general — a bit too general, in fact.
The top-level structure consists of a version number, a sequence of bit strings,
and a MAC over the whole thing. It's up to the reader of the fi le to interpret the
bit strings to fi gure out if they're encrypted and what they contain.
Blacklisting Compromised Certifi cates Using Certifi cate
Revocation Lists (CRLs)
After a CA has applied its signature to a certifi cate, that signature can never be
revoked, ever. The signature is a mathematical operation performed over the
certifi cate data; if it's valid today, it will be valid a million years from now. So
what can the holder of a certifi cate do if, for whatever reason, its private key is
compromised?
Depending on the usage pattern of the certifi cate, this could be very bad
news for the rightful owner of the certifi cate. Of course, if the certifi cate holder
knows about the compromise, the certifi cate can be taken out of use and a new
one generated. However, the key thief can use the old certifi cate and private key
to sign any document he likes, masquerading as the rightful certifi cate holder.
Every certifi cate has an expiration date to guard against this. Even if the right-
ful holder is unaware of the breach, the certifi cate eventually expires and a new
certifi cate, with a new public key (one would hope) is generated. However, if the
certifi cate holder is aware of a breach, it is irresponsible not to notify the users
of the certifi cate that it should be revoked prior to its expiration date.
CAs came up with half a solution with certifi cate revocation lists (CRLs) . The CA
maintains a list of the serial numbers of certifi cates that have been identifi ed by
their owners as no longer applicable. The users of the certifi cates are responsible
for checking this list on a periodic basis and comparing the serial number of
each received certifi cate against the list of revoked serial numbers. The format
for a CRL is, of course, an ASN.1 syntax; it starts with a header identifying the
CA, the date it was published, and a list of serial numbers and revocation dates.
Search WWH ::




Custom Search