 |
|
|
This section describes the members of the PKCS family and was taken from the RSA web site (www.rsa.com/rsalabs/pubs/PKCS). PKCS #1: RSA Encryption Standard PKCS #1 describes a method, called rsaEncryption, for encrypting data using the RSA public-key cryptosystem. Its intended use is in the construction of digital signatures and digital envelopes, as described in PKCS #7: PKCS #1 also describes a syntax for RSA public keys and private keys. The public-key syntax would be used in certificates; the private-key syntax would be used typically in encrypted private keys (PKCS #8). PKCS #3: Diffie-Hellman Key Agreement Standard PKCS #3 describes a method for implementing Diffie-Hellman key agreement, whereby two parties, without any prior arrangements, can agree upon a secret key that is known only to them (and, in particular, is not known to an eavesdropper listening to the dialogue by which the parties agree on the key). This secret key can then be used, for example, to encrypt further communications between the parties. PKCS #5: Password-Based Encryption Standard PKCS #5 describes a method for encrypting an octet string with a secret key derived from a password. Its intended primary application to public-key cryptography is for encrypting private keys when transferring them from one computer system to another, as described in PKCS #8. PKCS #6: Extended-Certificate Syntax Standard PKCS #6 describes a syntax for extended certificates. An extended certificate consists of an X.509 public-key certificate and a set of attributes, collectively signed by the issuer of the X.509 public-key certificate. Thus the attributes and the enclosed X.509 public-key certificate can be verified with a single public-key operation, and an ordinary X.509 certificate can be extracted if needed, e.g., for Privacy-Enhanced Mail. The intention of including a set of attributes is to extend the certification process beyond just the public key to include other information about a given entity, such as electronic-mail address. The preliminary intended application of PKCS #6 is in the cryptographic-enhancement syntax standard (PKCS #7), but it is expected that other applications will be developed. PKCS #7: Cryptographic Message Syntax Standard PKCS #7 describes a general syntax for data that may have cryptography applied to it, such as digital signatures and digital envelopes. The syntax admits recursion, so that, for example, one envelope can be nested inside another, or one party can sign some previously enveloped digital data. It also allows arbitrary attributes, such as signing time, to be authenticated along with the content of a message, and provides for other attributes such as counter-signatures to be associated with a signature. PKCS #8: Private-Key Information Syntax Standard PKCS #8 describes a syntax for private-key information. Private-key information includes a private key for some public-key algorithm and a set of attributes. PKCS #8 also describes a syntax for encrypted private keys. A password-based encryption algorithm (e.g., one of those described in PKCS #5) could be used to encrypt the private-key information. PKCS #9: Selected Attribute Types PKCS #9 defines selected attribute types for use in PKCS #6 extended certificates, PKCS #7 digitally signed messages, and PKCS #8 private-key information. PKCS #10: Certification Request Syntax Standard PKCS #10 describes a syntax for certification requests. A certification request consists of a distinguished name, a public key, and optionally a set of attributes, collectively signed by the entity requesting certification. Certification requests are sent to a certification authority, who transforms the request to an X.509 public-key certificate, or a PKCS #6 extended certificate. (In what form the certification authority returns the newly signed certificate is outside the scope of PKCS #10. A PKCS #7 message is one possibility.) PKCS #11: Cryptographic Token Interface Standard This standard specifies an API, called Cryptoki, to devices which hold cryptographic information and perform cryptographic functions. Cryptoki - pronounced crypto-key and short for cryptographic token interface - follows a simple object-based approach, addressing the goals of technology independence (any kind of device) and resource sharing (multiple applications accessing multiple devices), presenting to applications a common, logical view of the device called a cryptographic token. PKCS #12: Personal Information Exchange Syntax Standard This standard specifies a portable format for storing or transporting a user's private keys, certificates, miscellaneous secrets, etc.� PKCS #13: Elliptic Curve Cryptography Standard Covers public-key techniques based on elliptic curve cryptography PKCS #15: Cryptographic Token Information Format Standard PKCS #15, is aimed at establishing a standard which ensure that users in fact will be able to use cryptographic tokens to identify themselves to multiple, standards-aware applications, regardless of the application's cryptoki (or other token interface) provider. The PKCS #11 specification alone can not offer this functionality since it is an API specification aimed at offering applications a uniform interface to cryptographic tokens. This means that different tokens requires different PKCS #11 drivers, and unless a user's desktop has the �correct� PKCS #11 driver installed, the user will be unable to use the token on that desktop. The standard will impose a syntax for storing digital credentials (keys, certificates, etc) on these tokens, and how this information are to be accessed. Click here to return to the PKI Index Section
|
 |
Send mail to webmaster
with questions or�
|
