CERTIFICATES
With regard to the use of digital signatures, one is rather quickly confronted with a problem that must not be underestimated. Anyone who wants to verify the digital signature of a message needs the appropriate public key. However, the public key cannot be simply sent without any protection, since otherwise the recipient cannot verify the authenticity of the key. The public key must therefore be signed by a trustworthy body so that its authenticity can be verified. This body is called a certification authority (CA). The combination of a public key that has been signed by a certification authority, the accompanying digital signature and certain additional parameters is called a certificate. There is also another body involved in this process, which is the trust center (TC). A trust center generates and manages certificates and associated blacklists, and it can optionally generate keys for digital signature cards. As a rule, a trust center also maintains a public directory of certificates, so that anyone who wants to verify a signed message can request the associated signed public key from the center, for example via the Internet. A certificate contains not only the signed public key, but also a large number of additional parameters and options, since it must be possible to verify the public key of a certificate without any further information. From this, it follows that among other things, the algorithms used to generate the hash value and the signature must be clearly specified. In principle, everyone who signs documents could specify his or her own certificate structure. Of course, this would make it impossible to exchange certificates. This would generally rob such certificates of their meaning, since exchangeability is an essential characteristic of a certificate. In order to insure that this sort of cooperation actually can take place, there are standards that specify the structure of certificates. The best known of the relevant standards is X.509, which specifies the structure and coding of certificates. It has also entered the ranks of ISO/IEC standards as ISO/IEC 9594-8 The comprehensive X.509 standard is a framework in which the structure of certificates is defined in unambiguous terms. It forms the basis for many digital signature applications. Some examples are the Secure Socket Layer (SSL) Internet security mechanism and the Privacy Enhanced Mail (PEM), Secure Multipurpose Internet Mail Extensions (SMIME) and Secure Electronic Transaction (SET) applications. ASN.1 is consistently used in X.509 to describe certificates, and the widely known TLV coding scheme is used in accordance with the Distinguished Encoding Rules (DER) for the actual coding.17 Some of the objects that may be included in a certificate are listed in Table 4.24. A brief introduction and summary of the subject of X.509 certificates can be found in a paper by Peter Gutmann [Gutmann 98b]. Many optional data fields for a wide variety of applications are defined in the X.509 standard. For example, it is easily possible to include several public keys in a single certificate and have them signed by different certification agencies. This can result in certificates that contain several kilobytes of data, which can cause problems if a smart card is to be used to verify the certificate. Of course, this scheme can also be used to generate items such as complementary certificates and tree-structured certificate hierarchies. A typical X.509 certificate in a smart card normally has a size of approximately 1 kB.