I know I’ve sort of hit you out of the blue with this, but this is the first chance I’ve had to work this subject into a chapter.
Of course you’re wondering what the heck I’m talking about! PKCS stands for Public Key Cryptography Standards and it’s sort of a catch-all for all the standards not covered by public key algorithms, key exchange protocols, and Digital Certificate standards. They were developed by the big guns in cryptography — RSA Data Security. When different vendors started creating their own programs to handle public key encryption, they found that a lot of incompatibilities were popping up that they hadn’t expected. Now, with PKCS, the vendors can state up front which PKCS standards they follow. That way you can compare products to see if they will play well together.
When you are applying for a Digital Certificate, you are likely to see some statement in the application about PKCS. All it means is that if the CA server understands how to read PKCS format, then it will understand your certificate request.
PKCS #10 describes the standards for certificate requests.
I’ll give you some short and sweet explanations as to what the different standards are and what they mean. The first thing I’m sure you’ll notice is that even though the last standard is #15, there are really only thirteen listed. That’s because #2 and #4 were later rolled into PKCS #1.
PKCS #1: RSA Encryption Standard
It only makes sense that if RSA is describing all the cryptographic standards that they should make their own product
#1. Makes sense to me, anyways.
The PKCS#1 describes a method called rsaEncryption that is used for encrypting data using RSA’s public/private keys algorithm. This standard actually gets very technically detailed about how Digital Certificates should be handled and how this standard should work with a number of the other standards.
PKCS #3: Diffie-Hellman Key Agreement Standard
PKCS #3 describes a method for implementing Diffie-Hellman key agreement. It standardizes how the Diffie-Hellman agreement can have two people share a key that is known only by them and no one else. After the key has been shared, the two people can begin encrypting their communications.
PKCS #5: Password-Based Cryptography Standard
PKCS #5 describes how to encrypt a fixed length string of a private key with a secret key derived from a password.
Recommendations are made in this standard on how to implement what is usually referred to as PBE or Password Based Encryption.
PKCS #6: Extended-Certificate Syntax Standard
An Extended-Certificate is an X.509 Digital Certificate and a set of attributes that have been signed by the CA. The
“extended” bit refers to extra information like an e-mail address, which is not normally included in certificates. It’s assumed that extra information or attributes will be included in certificates at some point in time.
PKCS #7: Cryptographic Message Syntax Standard
This standard describes how you can put digital signatures into digital envelopes and then be able to put one digital envelope inside of another. This is normally used as a security mechanism in S/MIME. It also describes how the message can be time-stamped and authenticated.
This standard also makes S/MIME encrypted e-mail compatible with another e-mail encryption standard called PEM (Privacy Enhanced Mail). This is so an e-mail program that uses S/MIME can exchange messages with an e-mail program that uses only PEM.
This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks .
PKCS #8: Private-Key Information Syntax Standard
PKCS #8 describes how information should be included in an encrypted private key and how the key should be formatted. Some of that information will be about which algorithm was used to create the key in the first place. There’s also some information as to how the private key should be encrypted.
PKCS #9: Selected Attribute Types
PKCS #9 is basically a long list that describes certain attribute types for use in PKCS #6, PKCS #7, and PKCS #8.
You’ll notice that #6, #7, and #8 all deal with syntax, so PKCS #9 gets more specific about what the syntax is, how it is to be used, and where it is to be used.
(For those of you who never had to deal with DOS or UNIX command-line syntax, you may have no idea what the word syntax means. The simple answer is that it means getting the right words in the right places. If you get the words wrong, the computer doesn’t understand what you’re saying.)
PKCS #10: Certification Request Syntax Standard
Oh no! Another syntax standard!
PKCS#10 describes the syntax for the requests for certification. Certification in this standard means the request for a Digital Certificate. The request is sent to a Certificate Authority, so this makes sure that the CA can understand what you’re asking for.
In addition, there’s information in this standard on how the CA asks for the paperwork it needs to totally verify your identity. There’s also a way that a challenge password should be handled for the protection of the certificate.
PKCS #11: Cryptographic Token Interface Standard
The PKCS#11 standard describes a programming interface named Cryptoki (pronounced “crypto key”) for handling cryptographic operations with hardware tokens, smartcards, and USB smartkeys. There are a lot of popular applications that use PKCS#11 to provide smartcard support for their SSL and S/MIME transactions.
PKCS #12: Personal Information Exchange Syntax Standard
This standard specifies a format for storing and transporting a user’s private keys, certificates, and so on. This information needs to be shared with applications, and this standard makes it easier for programs and systems to read this information.
PKCS #13: Elliptic Curve Cryptography Standard
Elliptic curve cryptography has only recently started being used for encryption. The theory has been around for quite a while but vendors and cryptographers hadn’t tested it to the max so they haven’t been using it.
Because elliptic curve cryptography is still in its infancy, this standard is still being developed and isn’t finished yet.
PKCS #14: Pseudo-Random Number Generation Standard
This standard is still under development, too. At present there are a number of different methods of creating a generator for a pseudo-random number, but there’s no one outstanding method that is on its way to becoming a standard.
PKCS #15: Cryptographic Token Information Format Standard
PKCS #11 described how applications should interface with tokens and smartcards and so on, but PKCS #15 is to establish a standard so people can use one token (or smartcard) with any program or system. At present, you need to have special software to be able to read a token, and these software programs don’t all work the same way. The result is that tokens are not interchangeable. This standard is trying to change that.
This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks.
Chapter 7: All Keyed Up!
In This Chapter
Discovering what keys are all about The making of keys
Learning why keys need to be long How to store your keys safely
How symmetric and asymmetric keys work Should you be trusting those keys?
Deciding how to implement key servers
I’ve rewritten this chapter a hundred times already because keys are so important and a central issue to all
cryptography. I want to make sure I’ve got everything covered. It’s also very hard not to create too many puns about
“key issues” and “key complaints” and so on. I’m sure you all would be groaning in pain if I allowed myself all the cliché phrases. So, I’ll spare you as much as I can.
If I could have had anything to do with it, I would not have chosen the word key to describe anything having to do with cryptography. I think I would have called it a door knob or anything else that doesn’t have multiple meanings. But, the word key is a standard and it doesn’t look like it will be going away any time soon, even though it’s the most confusing concept for beginners to grasp and the hardest item to control in a crypto system. Given that, you’d think they could have given it a better name.
I know I’ve gone over some stuff on keys already, and there will be more on keys in later chapters. However, because keys are central to the cryptography theme, I thought I’d use this chapter to throw everything about keys together so you’ll have one place to refer to whenever you have a question or just aren’t sure about something. Hopefully you’ll find this entertaining, interesting, and educational.