CA2368961A1 - Digital certificate - Google Patents

Abstract

Public Key Infrastructure1 ("PKI") now permeates the Internet, operating systems such as Microsoft's Windows, and application software such as Microsoft's Outlook. A core component to this infrastructure is a hierarchical trust model, where a third party "binds" a human identity to a data token - a digital certificate. There exists a fundamental flaw in this trust model, and as a result this infrastructure is the proverbial "house of cards". The reasons are several-fold;

1. Current procedures widely in use to establish the validity of this binding are fraught with means to circumvent2;

2. Even if the procedures mentioned above are carefully designed and stringently executed, the "consumer" of the digital certificate3 cannot perform an independent, robust trust decision. Rather, they must choose to accept or decline the third party's (usually a certificate and or registration authority) assertion as to the binding of a true human identity and the data token;

3. Even if the consumer chooses to accept the third party trust assertion, the issue as to whether or not the "bound" entity is the same entity which is involved in the current PKI transaction4 cannot be resolved.

A TrueCert, is an x509 version 3 compliant digital certificate5 which is intended to overcome this flaw, by combining PKI and Biometric technologies, facilitating;

1. A more rigorous means of binding a human identity to the digital certificate (data token);

2. Provide a robust, low cost, scalable, easy to use means for the consumer of the digital certificate to perform an independent trust assertion;

3. As in 2 above, but on a per PKI transaction basis - i.e. evaluate every private key operation.

Description

Overview of the TrueCert Architecture 1. ''I'he traditional Certificate Signing Request, {"CSR") d~.taset would.
be augmented with an x509 version 3 extension consistent with the PKIX qualified Certi~.cate Profile - the ~3iornetricir~fo Extensic~n~:
"The purpose of this extension is to provide means for authentication of biometric information. The biometric information that corresponds to tree stored hash is not stored in this extension, but the e~aension MAY include an URI
pointing to a location where this information can be o btained. If included, this URI does not imply that this is the only way to access this information.
This extension SHALL only be used to store a hash of biometric information suitable for human verification, i.e. where decision whether this information is an accurate representation of the subject is performed by a physical person.
This implies a usage where the biometric information is represented by for example a graphical image, displayed to the relying parry, which MAY be used by the relying party to enhance identification of the subject.
INTERNET DRAF"f Qualified Certifi~ates Profile: October 1999 biometricInfo EXTENSION ::_ {
SYNTAX BiometricSynta~
IDENTIFIED BY id-pe-biometricInfo }
id-pe-biometricTnfo OBJECT IDENTIFIER :._ {lid-pe 2~
BiometricSyntax ::= SEQUENCE OF BiometricData BiornetricData ::= SEQUENCE {
typeOfBiometricData TypeOfBiometricl3ata, hashAlgorithm AlgorithmIdentifier, biometricDatal-Iash OCTET STRING, sourceDataUri IA5String OP'CIONAL }
TypeOfBiometricData ::= CHOICE {
predef'anedBiometricType PredefinedBiometricType, biometricDataID OBJECT IDENTIFI~;R }
PredefinedBiometricType ::= INTEGER { picture(0), handwritten-signature{lj} (picture ~ handwritaen-signaturc,...~
The predefined biometric type picture, when present, SHALL identify that the source picture is in the form of a displayable graphical image of the subject.
The hash of the graphical image SHALL only be calculated ovcr° the image data excluding any labels defining the image type.
The predefined biometric type handwritten-signature, when present, SHALL
identify that the source data is in the form of a displayable graphical image of the subject's handwritten signature. The hash of the graphical image SHALL
only be calculated over the image data excluding any labels defining the image type. ~~

2 2. Use of the Biometric Information in a novel way All other approaches to date attempting to combine Biometric grad PKI
digital certificate technology have focused on using the Biometri~c data to protect the private key, as opposed to the noun of password based protection.
The TrucCert would use l3iometric data not to protect the private keys, but as part of the dataset forming tie data tol~;en bound to a hu:rnan identity. As such, traditional cryptographic transaction / ~.nessage verification could be augmented with Biometric validation, all of which would occur? on the digitai certificate consumer's coput~:ng platform.
This combination of tradition PKI cryptographic validation, together with Biometric validation, would provide the digital certificate consumer a robust, easy to use means of making their own trust decision regarding the message / transaction:
a. Authenticity b. lion-Repudiation c. Integrity By explicitly including Biometric information in the certificate's data structure, and augmenting the validation process to include the Biometric data cor~firmation, Public fey Infra:atructure is :no longer a "house of cards".
A generalized implementation is as follows:
~ The CSl~ dataset would be augmented with a cryptographic hash$
of a fingerprint obtained from a biometric device, resulting in a standards compliant ~5~~ version 3 di~,ital certiucate with a BiometricInfo extension;
~ An enhanced message / transaction distal signh~g utility would.
be made available, such that in addition to the standard cryptographic operations9, the "signer" ~~roald provide the same biometrlc Input as that used in the CSR at the time of the signing operation - i.e. fingerprint - which wou:Ld be transn2itted along with the signed message / data;
6 Although this could still be done for added security.
'' In a transparent manner to the digital certificate consumer.
$ Or other suitable representation of the reference (i.e. obtained during cert~cate enrollment) biometric data.
9 See Appendix 2

3 ~ The computing device of the ~.onsumer cf the signed messagelo would pr~cess the signed message as outlined earlier - both with a traditional cryptographic verification process, and the "raw"
biometric dataz 1 provided in ehe message / transaci:ion would be processed and compared t~ that contained in the signer's digital certificate;
o The bio~netric dataset provided by the signer would be "tia~ne-statnped" by an independent, non refutable 3~d party, and othercwise protected to prevent forgery - e.g. by supplying a previously stored biometric clatasete i.e. a second verification layer - a °°digitai signature'° validation mechanism for a "transaction" - where the digital signature would be validated by biometric data - a fingerprir3t - and validation for a transacticn would be accomplished by comparing the reference fingerprint - the "template" stored as the x5t39v3 extension.
However, we have a slight variant in our "validation" requirement - the trust assertion is critical - and as such we need to have the validation operation occur on the computing platform of the person receiving the signed transaction, as opposed to having the operation occur on the "signer's" computing platform, and send an '°ok ~ validated'°
response to a query from the "receiver°°.
Rs such, the "raw°° data from the device (from the signer) must be sent (we would encrypt it, and us ssl or tls) to the receiver, cohere the validation would take place. Of course the receiver would be in possession of the reference template of the signer (it will be in the signer's digital certificate) - i.e. a distributed approach to validation -where presumably the receiver is more confident his/her computing environment has not been compromised, rather than being "fiorced" to trust the validation operation outcome if it were perForrned on the signer°s machine.
Thus the "trust decision" will rest only the ass;crtionr2 that the bioxretric dataset could have somehow been otherwise created which precisely matches the "reference" biometric dataset contained in the signer's digital certificate. lrrpportantly, this trust decision does not suffer the static and binary nature of the traditional PKl trust decision imposed by the currently adopted hierarchy and. architecture.
io Containing the digital certificate of the signer 11 This biometric data would be captz~red at the time of the signing transaction.
12 Civen the technical performance of biometric hardware devices and related software today, this is a far superior tn~st assertion than that which is provided by today's Public Key Infrastructure.

4 Appendix 1 - ~Ierisign Security ~rcach questions Ieinger After VeriSign breach ~y Charles Dabcock and Till IZodger Interactive ~7eel~ April ?, 2~~ 1 11:5 AM F~f°
Internet security company ~le~°iSign has acknowliedged issuing two Microsoft digital certificates to an imposter, rais~.ng doubts it many quarters about the consistency of Internet ident~:fication practices. kith VeriSign and Microsoft struggling to retract the ~uistal~e, security experts are worried that the breach will have serious implications.
A digital certificate is issued to verify that a message is real~.y from the sender. In this case, observers fear malicious code ~,r~ili be offered as originating from Microsoft and thus safe to dowr~ioad. ~nce downloaded, the code could wreak havoc.
~n Jan. 29 and Jan. 3~, ~leriSign issued a certii:icate each day to someone posing as a Microsoft employee, then sent confirmation to Microsoft of the issuance. Microsoft responded taut it had not requested certificates on those dates. A '~TeriSign official said T~llar ch 2 ~ that the nrm had not followed proper procedures.
Alarms about the incident are still ringing. "If one of the most sophisticated companies on the planet can't get its certificate management right, what hope is there for the rest of use" asked Steve ~ellovin, research scientist at ~.'I'~'I° and member of the Internet Architecture hoard. "It's hard to in~aagi~ae this is a p-arely isolated circumstance," said Jar ry Dr ady, vice president of research and development at uardent9 a security services fir:~n.
~leriSign dice President Mahi deSilva said the company stood by its service. "I~uman error,': he said, cause. the certiificate to be issued before vetting was complete. Still, °'we think that issuing ~ carts out of ~s~~k is still unacceptable,°' he said. DeSilva denied earlier reports .hat ~eriSign had discovered the breach only after Microsoft notified the ~eomp~ny si<~
weeks after the fact. An ~'~I investigation, he said, prevented hire from being more specific.
B"he Microsoft imposter needed t~ pay for the certificates with a credit-card number, but ~TeriSign declined to say whose credit car°d he used.
The irnposter paid from ~8~f~ to several thousand dollars for the °'code'°
certificates, estimated I~ob Clyde, chief technologist in the enterprise Solutions Division at Symantec, a supplier of security management software.

'°°hhe charge raises a deterrent to 19-year-old hackers," he rooted. So, who went to the expense of buying ttZe certificates, or~ the double; exposure of stealing a credit card and then buying the certificates with it? , ~thers challenged VeriSign's and Microsoft's inability to retract t:he erroneous certificates by posting them to a checkpoint for i~.malid certificates. Identrus, an alliance of 44 financial institutions, said certificates issued through its international frarnework each contain an embedded UL. An automatic check is made at vtb.e UF2L, which =ends to the list of revoked certificates, said Guy ~'allent, president of Identrus.
But the Windows platform doesn't always include an automatic checker of the Certificate Revocation List (CF2L~, so VeriS:ign cannot embed a distributed checkpoint in its Microsoft certificates, said Hrian ~°Higgins, chief technology officer at Entrust.
..Anyone can make a mistake, but you need a system that ~aa~rks with revocation" to correct a mistake, ~'Higgins said, emphasizing that his company's certificates include the embedded checklist information. Using tl~e CRL is not foolproof protection for certificates either, said Gary McGraw, chief scientist at Cigital, a security consulting 1°irn~.
Microsoft said it was working on a patch to recognize the now-revoked VeriSign certificates. With such a patc~~~, a user about to download code falsely labeled as Microsoft°s with the don. 29 or fan. 3~ certificates could be warned the certificate wasn't valid. "people are buy ing tr~.st from VeriSign. Something like thrs shakes it,°° Erady said.

Appendix 2 - ~K~ ~v~x°~r~~w 1 ~ o f'ubiic-key cryptography and related standards and techniques unde9°lie security features of many;
Netscape products, including signed and 'encrypted small, form aigning, object signing, single sign-on, and the Secure Sockets Layer (SSL~ protocol. This document introduces the basic concepts of public-key cryptography.
Internet Security Issues Fncry~tion and C3ecry~tion digital Signatures Certificates and Authentication Managing Certificates For more information on these topics and other aspects of crypts>graphy, see S~acurit~l~esources.
For an overview of SSL, see Introduction to SSL.
All communication over the Internet uses the Transmission Control F'rotocolllnternet protocol (TCpIIP). TCPIIp allows information to be sent from one computer to another through a variety of intermediate computers and separate networks before it reaches its destination.
The great flexibility of TCpllp has led to its worldwide acceptance as the basic Internet and intranet communications protocol. At the same time; the fact that TCpIIF~
aliow:> information to pass through intermediate computers makes it possible for a third party to inter~iere with communications in the following ways:
~ avesdr~pp~r~g. Information remains intact, but its privacy is comprorr~ised.
For example, someone could learn your credit card number, record a sensitive conversation, or intercept classified information.
~ Tarr'perir~g. Information in transit is changed or replaceei and then sen°r on to the recipient. For example, someone could alter an order for goods or change a person's resume.
~ 6rrspers~nati~n. Information passes to a person who po:aes as the intended recipient.
impersonation can take two forms:
o ~p~~~Fing. A person can pretend to be someone else. For example, a person can' pretend to have the small address jdoe@mozillai.com, or a computer can identify itself as a site called www.mozilla.com when it is not. This type of impersonation is known as spoofing.
o Isrepre~erstatl~r~. A person or organization can misrepresent itself. For example, suppose the site www.mozilla.com pretends to be a furniture store when it is really just a site that takes credit-card payments but never sends any goods.
~lormally, users of the many cooperating computers that make up the Internet or other networks don't monitor or interfere with the network traffic that continuously passes through their machines.
However, many sensitive personal and business communications over the Intel°net require precautions that address the threats listed above. Fortunately, a set of well-established techniques and standards known as p~bl~c~key crypt~graphy rnake it relatively easy to take such precautions.

public-key cryptography facilitates the following tasks:
~r~cryption and d~cry~tiora allow two communicating parties to disguise information they send to each other . The sender encrypts, or scram~'les, information before sending it. The receiver decrypts, or unscrambles, the information after receiving it.
While in transit, the encrypted information is unintelligible to an intruder.
l°ar~t~er detection allows the recipient of information to verify that it has not been modified in transit. Any attempt to modify data or substitute a false message for a legitimate one will be detected.
m Authentication allows the recipient of information to determine its origin--that es, to confirm the sender's identity.
~ onre~uiation prevents the sender of information frorr~ claiming at a later date that the information was never sent.
The sections that follow introduce the coneepts of public-key cryptography that underlie these capabilities.

encryption is the process of transforming information so it is unintelligible to anyone but the intended recipient. decryption is the process of transforming encrypted information so that it is intelligible again. A crypt~grahic aloriths~, also called a ciphers is a mathematical function used for encryption or decryption. In most cases, two related functions are employed, one for encryption and the other for decryption.
With most modern cryptography, the ability to keep encrypted information secret is based not on the cryptographic algorithm, which is widely known, but on a number called a key that vmust be used with the algorithm to produce an encrypted result or to decrypt previously encrypted information. Decryption with the correct key is simple. Decryption without the correct key is very difficult, and in some cases impossible for all practical purposes.
The sections that follow introduce the use of keys for encryption .and decryption.
Symmetric-Key encryption Public-Kev ~ncrvption Kev Lenath and Encrvotion Strenoth ~'1~ i~'~1 Wifih syrrarnetric-key eracry~tion, the encryption key can be calculated from the decryption key and vice versa. With most symmetric algorithms, the same key i~; used for both encryption and decryption, as shown in ~i~.

IFi~re 1 Syrrsrnotric-key eracrypti~r~
Es~or-~~tiora ~~ti~r~
D~xr~e Ii: '~ C:~ar.'H.li:
I haze ~ ~r : I hs~
revievr~ ~ ~'xY4~.,C,q ~ r~aie3ra~
rha new... ~..'.?F.-.' tht new...
e~ri~inal S~mme~.r'i~ Scrambled Syrrsrrietric ~7ri~in~l d ate key c3 ~.t:~ Itey d ~~a Implementations of symmetric-key encryption can be highly efficlient, so that users d~ not experience any significant time delay as a result of i:he encryptioin and decryption. Symmetric-key encryption also provides a degree of authentication, since information encrypted with ~rne symmetric key cannot be decrypted with any other symmetric key. Thus, as gong as the symmetric key is kept secret by the two parties using it to encrypt communications, each party can be sure that it is communicating with the other as long as the= decrypted messages continue to make sense.
Symmetric-key encryption is effective only if the symmetric key is kept secret by the two parties involved. If anyone else discovers the key, it affects both confidentiality and authentication. ~
person with an unauthorized symmetric key not only can decrypt messages sent with t~rat key, but can encrypt new messages and send them as if they came from one of the two parties who were originally using the key.
Symmetric-key encryption plays an important role in the SSL protocol, which is widely used for authentication, tamper detection, and encryption over TCP/l~ networks. SSL
also uses techniques of public-key encryption, which is described in the next section.
t9 II~ lti'~I
The most commonly used implementations of public-key encryption are based on algorithms patented by RSA ~ata Securit~e. Therefore, this section describes the RSA
approach to public-key encryption.
I~~rblic-key eracrypti~n (also called a~ys~rnetrio errcr~tiora) imvolves a pair o~F keys--a p~btic key and a private key--associated with an entity that needs to authenticate its identity electronically or to sign or encrypt data. each public key is published, and the corresponding private key is kept secret. (For more information about the way public keys are published, see Certificates and Authentication.) t~ata encrypted with your public key can be decrypted only with your private key. ~r'e~ure 2 shows a simplified view of the way puk'lic-key encryption works.
agure ~ ~~bii~-key en~rypti~r~
~ra~r°~tior~ e~t~ytion ~xr.~.li: ~'~F '~, r~ar.'~li:' I have ~ ~~Iht~ ~r ' _ I hive rryties~ad 1~"s~~~ ~ res~i~,raj tho now... ~ x~.» the oew...
~ri~ina~l F'ubli~ Scrarrule~ Private ~riginal ~ ate I~ey ~ ai:.a I~ey ~ ~ta The scheme shown in Figure 2 lets you freely distribute a public key, and only,~ou will be able to read data encrypted using this key. In general, to send encrypted data to someone, you encrypt the data with that person's public key, and the person receiving the encrypted data decrypts it with the corresponding private key.

Compared with symmetric-key encryption, public-key encryption requires more computation and is therefore not always appropriate for large amounts of data. However, it°s possible to use public-:
key encryption to send a symmetric key, v~dhich can then be used to encrypt additional data. This is the approach used by the SSL protocol.
As it happens, the reverse of the scheme shown in I:=i~gure 2 also works: data encrypted with your private key can be decrypted only with your public key. This would not be a desirable way to encrypt sensitive data, however, because it means ~~hat anyone with your public key, which is by definition published, could decrypt the data. Nevertheless, private-key encryption is useful, because it means you can use your private key to sign data with your digital signature--an important requirement for electronic commerce and other commE:rcial applications of cryptography. Client software such as Communicator can then uae your public key to confirm that the message was signed with your private key and that it hasn't been tampered with since being signed. ~igital Signatures and subsequent sections describe hove this confirmation process works.
Len r~ c ~r~ ~
In general, the strength of encryption is related to the difficulty of discovering the key, which in turn depends on both the cipher used and the length of the key. IFor example, the difficulty of discovering the key for the RSA cipher most commonly used for public-key encryption depends on the difficulty of factoring large numbers, a well-known mathematical problem.
Encryption strength is often described in terms of the size of the keys used to perform vhe encryption: in general, longer keys provide stronger encryption. FCey length is mieasured in bits.
For example, 128-bit keys for use with the RC4 symmetric-key ciipher supported by SSL provide significantly better cryptographic protection than 40-bit keys for use vuith the same cipher.
Roughly speaking, 128-bit RCS encryption is 3 x 102 times strorsger than 40-bit RC4 encryption.
(For more information about 1~C4 and other ciphers used with S~>L, see Introduction to SSL.) different ciphers may require different key lengths to achieve the same level of encrypi:ion strength. The RSA cipher used for public-key encryption, for example, can use only a subset of all possible values for a key of a given length, due to the nature of tl'ne mathematical problem on which it is based. Other ciphers, such as those used for symmetric key encrypton, can use all possible values for a key of a given length, rather than a subset of those values . Thus a 128-bit key for use with a symmetric-key encryption cipher would provide stronger encryption than a 128-bit key for use with the RSA public-key encryption cipher.
This difference explains why the RSA public-key encryption cipher must use a ;512-bit key (or longer) to be considered cryptographically strong, whereas symnnetric key ciphers can achieve approximately the same level of strength with a 64-bit key. Even this level of strength may be vulnerable to attacks in the near future.
Secause the ability to surreptitiously intercept and decrypt encrypted information has historically been a significant military asset, the U.S. Government restricts export of cryptographic software, including most software that permits use of symmetric encryptiora keys longer than 4Q bits. For detailed information about these restrictions as they apply to Netscape products, see Exp~rf Restrictions on International Sales.

Encryption and decryption address the problem of eavesdropping, one of the three Internet security issues mentioned at the beginning of this document. ~ui: encryption and decryption, by themselves, do not address the other two problems mentioned ire Internet Security Issues:
tampering and impersonation.
This section describes how public-key° cryptography addresses the problem of i:ampering. The sections that follow describe how it addresses the problem of impersonation.
Tamper detection and related authentication techniques rely on a mathematical function called a one-gay hash {also called a rr~essage digest}. A one-way hasrr is a number of fixed length with the following characteristics:
The value of the hash is unique for the hashed data. Any change in the data, even deleting or altering a single character, results in a different value.
~ The content of the hashed data cannot, for all practical purposes, be deduced from the hash--which is why it is called "one-way.'°
As mentioned in Public-Kelr Encryption, it's possible to use your private key for encrypi:ion and your public key for decryption. Although this is not desirable when you are encrypting sensitive information, it is a crucial part of digitally signing any data. Instead of encrypting the data itself, the signing software creates a one-way hash of the data, then uaes your private key to encrypt the hash. The encrypted hash, along wifh other infoa~mation, such as the hashing algorithm, is known as a digital signature.
Figure 3 shows a simplified view of the way a digital signature csrn be used to validate the integrity of signed data.
Figure ~ Using a digital signature to ~ralidate data integrity Or'Iginal ~ Or~iginal G~hrpa.li: ~~~.~ Dearrlri: ~3~.~
hence I haen r~iiw~e.~ re'; cc rrrea~
r9ye ne5r... trs recur:..
~'nB=~'4fd~°' i~l~t~rl~ h;i~h I-ihir~, E-i~shie~, ~,i~r°ith'~''~ ~I,~~arit.6~art~ ~ ' w Iden~cie~l .-.....--.-~ ° ~ ~~ ,~..__~ -~, x,w.~~~h~shas ins-wav~ ~rivaxs Iccy Gi~i~.l Digital' I~ublic I!e~~t One-~°P~~~
'~~iidats hash encr°~~ptaon sign~.~cr~r~ si~reat~rr°e 4~ser;~pti~n hash data inte~rit.~r Fi ure 3 shows two items transferred to the recipient of some sicined data:
the originaB data and the digital signature, which is basically a one-way hash {of the original data} that has been encrypted with the signer's private key. To validate the integrity c'f the data, the r eceiving software first uses the signer's public key to decrypt the hash. It then uses. the same hashing algorithm that generated the original hash to generate a new one-way hash of i:he same data.
(lnforrr~ation about the hashing algorithm used is sent with the digital signature, although thi;> isn°t shown in the' figure.) Finally, the receiving software compares the new hash against the original hash. If the two hashes match, the data has no'c changed since it was signed. If they don't match, the data may have been tampered with since it was signed, or the signature may have been created with a private key that doesn't correspond to the public key presented by the signer.

If the two hashes match, the recipient can be certain that the public key used to decrypt the digital signature corresponds to the private key used to create the digital signature.
Confirming the identity of the signer, however, also requires some way of confirnning that the public key really belongs to a particular person or other entity. For a discussion of the way this works, see Certificates and Authentication.
The significance of a digital signature is comparable to the significance of a handwritten signature. Once you have signed some data, it is difficult to deny doing so later--assuming that the private key has not been compromised or out or' the owner's control. This quality of digital signatures provides a high degree of nonrepudiation--that is, digital signatures make it difficult for the signer to deny having signed the data. In some situations, a digital signature may be as legally binding as a handwritten signature.
a iicaa ut i tin A Certificate Identifies Someone or Something Authentication Confirms an Identity How Certificates Are Llsed Contents of a Certificate How CA Certificates Are Used to Establish Trust Certificate Identifies orr~eone or Something A certificate is an electronic document used to identify an individual, a server, a company, or some other entity and to associate that identity with a public key. Like a driver°s license, a passport, or other commonly used personal IDs, a certificate provides generall,~ recognized proof of a person's identity. public-key cryptography uses cert~cates to address the problem of impersonation (see Internet Security Issues).
To get a driver's license, you typically apply to a government agency, such as the Department of Motor Vehicles, which verifies your identity, your ability to drive, your address, and other information before issuing the license. To get a stucent ID, you apply to a school or college, which performs different checks (such as whether you have paid your tuition) before issuing the ID. To get a library card, you may need to provide only your name and a utility bill with your address on it.
Certificates work much the same way as any of these familiar forms of identification. Certificate auth~rities (CAs) are entities that validate identities and issue certificates. They can be either independent third parties or organizations running their own certificate-issuing server software such as lVetscape Certificate Server). The methods used to validate an identit'r vary depending on the policies of a given CA--just as the methods to validate other forms of identification vary depending on who is issuing the I~ and the purpose for which it will be used.
ire general, before issuing a certificate, the CA must use its published verification procedures for that type of certificate to ensure that an entity requesting a certificate is in fac>t who it ciaim:~ to be.
The certificate issued by the CA binds a particular public key to the name of the entity the certificate identifies such as the name of an employee or a server).
Certificates help prevent the use of fake public keys for impersonation. Cnly the public key certified by the certificate wil! work with the corresponding private key possessed by the entity identified by the certificate.
In addition to a public key, a certificate always includes the name of the entity it identifies, an expiration date, the name of the CA that issued the certificate, a serial number, and other information. Most importantly, a certificate always includes the digital signature of the issuing CA.
The CA°s digital signature allows the certificate to function as a '°letter of introduction°° for users who know and trust the CA but don't know the entitbp identified by the certificate.
~2 For more information about the role of CAs, see i~ow CA Certificates Are I~sed to Establish Trust.
tictii~ ~ t~
ufihenticati~n is the process of confirming an identity. In the context of network interactions, authentication involves the confident idAntification of one party by another party. Authentication over networks can take many forms. Certificates are one way of supporting authentication.
network interactions typically take place between a client, such as browser software running on a personal computer, and a server9 such as the software and hardware used to host a l~feb site.
Client authenticati~rr refers to the confident identification of a client by a scorer that is, identification of the person assumed to be using the client software). erv~r au~thenticati~n refers to the confident identification of a server by a client (that isr, identification of the organization assumed to be responsible for the server at a particular network address).
Client and server authentication are not the only forms of authentication that certificates support.
For example, the digital signature on an emaii message, combined with the certificate what identifies the sender, provide strong evidence that the person idE:ntified by that certificate did indeed send thaf message. Similarly, a digital signature on an Fft'L form, correbined with a certificate that identifies the signer, can provide evidence, after the fact, fihat the person identified by that certificate did agree to the contents of the form. In addition to authentication, the digital signature in both cases ensures a degree of nonrepudiation--that is, a digifal signature makes it difficult for the signer to claim later not to have sent the email ~r 'the form.
Client authentication is an essential element of network security within most intranets or extranets. The sections that follow contrast two forms of client aufihentication:
~ ~'assword-Based Authentication. Almost ali server software f~ermits client authentication by means of a name and password. F~r example, a server might req~rire a user to type a name and password before granting access to the server. Tile server rr~aintains a fist of names and passwords; if a particular name is on the list, and if the user types the correct passw~rd, the server grants access.
~ Certificate-Based Authentication. Client authentication based on certifi<;ates is part of the SSL protocol. The client digitally signs a randomly generated piece of data and sends both the certificate and the signed data across the network. The server uses techniques of public-key cryptography to validate the signature and confirm fhe validity of the certificate.
ass~nr~r~ seed t~ticat~~n Figure ~. shows the basic steps involved in authenticating a client by means of a name and password. Figure ~ assumes the following:
~ The user has already decided to trust the server, either vvithout authentication .or on the basis of server authentication via SSL.
~ The user has requested a resource controlled by the server.
The server requires client authentication before permittirng access to the requested resource.
f=figure 4 lJsing a passes~rd to aaathenticate a client t~ a server ~s~P° ~n$8r~
name ~.nd pass'~rord. ~b, ~~ 8"~~' ,~~eru'~r ~,~J~.hf~4"~~~
l, _ ~ ~..
Client sends namand . ~~:~~ss fir ~' , 3ss',Aford ~crc~ss network ~M aut~rer~ri~ated ideretit~'.
Ser"~reer uses ~as~~,~ord 't~
~~~.~ ~ n~a~
user°s identity.
Those are the steps shown in Figure 4.:
~. In response to an authentication requesf from the server, the client displays a dialog box requesting the user's name and password fcr that server°. The user must supply a name and password separately for each new server the user wishes to use during a work session.
2. The client sends the name and password across the network, either in the clear or over an encrypted SSL oonnection.
3. The server looks up fhe name and password in its local password database arPd, if they match, accepts them as evidence authenticating 'the user's identity.
The server determines whether the identified user is permitted to acoe~>s the requested resource, and if so allows the client to access it.
llVith this arrangement, the user must supply a new password for' each server, and the administrator must keep track of the name and password for each user, typically on separate servers.
As shown in the next section, one of the advantages of certificat:r-based authentication is that it can be used to replace the first three steps in Figure 2 with a mechanism that allows the user to supply just one password (which is not sent across the networks and allows the administrator to control user authentication centrally.
e~to~cte- ~s~~~c~~~~s Fi~ur~ 5 shows how client authentication works using certificates and the SSt_ i~rotocol. To authenticate a user to a server, a client digitally signs a randomly/
generated piece of data and sends both the certificate and the signed data across the network. For the purposes of this discussion, the digital signature associated with sor?1e data can kae thought of as evide'~aoe provided by the client to the server. The server authenticates the user's identity on the strength of this evidence.
i_ike Fi ure 4, Figure 5 assumes that the user has already decidE:d to trust the server and has requested a resource, and that the server has requested client authentication in the process of evacuating whether to grant access to the requested resource.

Feg~re 5 t~sir~g a cerfiifiicate ~o a~t~~nficat~ a cii~n~ to a server User enters Qri'rate-Ite~' passwd~rd.

~b ~~ B~a ~

ESL c~nnectian Client sends ~- ~er'~er ~

c~rtifit~.~ and .,~ a,~$f~~r'ii~e~

~r~~d~nc~ ~er~,~er uses ~c~es.;
fir Client ;~r~ss net'~r~rlc.certific;~te and authenticated rat r1 ~',.td e3 evidence t~ identity.

pri~,~.te Ice;u ~u'~~~~~~

and uses it try t~Ye u;7~P''a " Id~ntf'~';'.
' create ' e~ariden~e f digit~3 si~n~.turel.

Unlike the process shown in Figure 4., the process shown in Figure v requires ti°~e use a~f SSL.
Figure 5 also assumes that the client has a valid certificate that c:an be used to identify the client to the server. Certificate-based authentication is generally consiciered preferable to password-based authentication because it is based on what the user has (the private keys as wel! as what the user knows (the password that protects the private key). Flo~nret/er, it's important to note that these two assumptions are true only if unauthorized personnel have not gained access to the user's machine or password, the password for the client software;'s private key database has been set, and the software is set up to request the password at reasonably frequent intervals.
amp~rfiar~t I\leither password-based authentication nor certificate-based authentication address security issues related to physicall access to individual machines or passwords. Public- key cryptography can o116y verify that a privatar key used to sign some data corresponds to the public key in a certificate. It is the user°s responsibiiify to protect a machine°s physical secuirity and to keep the private-key password secret.
These are the steps shown in Figure ~:
The client software, such as Communicator, maintains a database of the private keys That correspond to the public keys published in any cerfiificatea issued for that client. The client asks for the password to this database the first time the client needs to access it during a given session--for example, the first time the user attempts to access an SSL-enabled server that requires certificate-based client authentication. after entering this password once, the user down°t need to enter it again for the rest of the sessiasn, even when accessing other SSL-enabled servers.
The client unlocks the private-key database, retrieves thsr private key for the user°'s certificate, and uses That private key to digitally sign some data that has been sand~mly generated for this purpose on the basis of input from both the client and the server. This data and the digital signature constitute "evidence" of the private key°s validity. The digital signature can be created only with that private key and can be validated with the corresponding public key against the signed data, which is unique to the SSL
session.
~. The client sends both the user°s certificate and the evidence (the randomly generated piece of data that has been digitally signed across the network.
4. The server uses the certificate and the evidence to authE:nticate the user°s identity. (For a detailed discussion of the way this works, see introduction to SSL.)

5. At this point the server may optionally perform other authentication tas4cs, such as checking that the certificate presented by the client is stored in the user's entry in an L~AP directory. 'The server then continues to evaluate whether the identified user is permitted to access the requested resource. This evaluation process ce~n employ a variety of standard authorization rr~echanisrns, potentially using additional information in an L~AF' directory, company databases, and so on. If the result of the evaluation is positive, the server allows the client to access the requested resource.
As you can see by comparing Fi_~qure 5 to Fi ure 4., certificates resplace the authentication portion of the interaction between the client and the server. instead of requiring a user to send passwords across the network throughout the day, single sign-on requires the user to enter the private-key database password )ust once, without sending it across the network. ?=or the rest of the session, the client presents the user°s certificate to authenticate the user i:o each new server it encounters.
Existing authorization mechanisms based on the authenticated user identity are not affected.
IIC~' Types of Certificates SSL Protocol Signed and Encry~ted Email Form Sic~nint~
Single Sic~n-~n C~biect Sianinca ~'es f ~rtifi~te Five kinds of certificates are commonly used with t~etscape products:
CEi~rat SSL o~rtEfaoat~a. Used to identify clients to servers via SSL (client authentication).
typically, the identity of the client is assumed to be the same as the identity of a human being, such as an employee in an enterprise. See Certificate-Sased Authentication for a description of the way client SSL certificates are used for client autheni:ication. Client SSL
certificates can also be used for Form Signing and as p2~rt of a din Ig ~
:~i,~n-C7n solution.
E~ars~pl~~: R bank gives a customer a client SSL certificate that aBlows the bank°s servers to identify that customer and authorize access to the customer's accounts. ~ company might give a new employee a client SSL certificate that allows the company's servers to identify that employee and authorize access to the company's servers.
Server SQL o~rf°sfooates. l.,~sed to identify servers to clients via SSL (server authentication). Server authentication may be used with or without olier~t authentication.
Server authentication is a requirement for an encrypted :ESL session. 'lee SSL
F~rotocol.
~arr~pie: Internet sites that engage in electronic commerce (commonly known as e-cora~ra~erc~) usually support certificate-based server authentication, at a minimum, to establish an erncrypted SSL session and to assure customers that they are dealing with a web site identified with a particular company. l'he encrypted SSL session ensures that personal information sent over the network, such as credit card numbers, cannot easily be intercepted.
If~Alll~~ oortEfic~te~. Used for signed and encrypted email. ~s with client SSL
certificates, the identity of the client is typically assumed to be the same as the identity of .
a human being, such as an employee in an enterprise. A, single certific<~te may be used as both an SII~IfVtE certificate and an SSL certificate. See Sinned and I~ncry~ted Email.
S/NIlME certificates can also be used for Form S~ning and as part of a Single Si-qn-Can solution.

~~tarnples: A company deploys combined SIMIME and SSL certificates solely for the purpose of authenticating employee identities, thus permitting signed small and client SSL authentication but not encrypted small. Another company issues S/MIME certificates solely for the purpose of both signing and encrypting small that deals with sensitive financial or legal matters.
~bject-signing certificates. Used to identify signers of Java code, Jav.<aScript scripts, or other signed files. See Object Signinci.
Ear~~ie: A software company signs software distributed over the Internet to provide users with some assurance that the software is a legitimate product of that company. Using certificates and digital signatures in this manner can also make it possible for users to identify and control the kind o-F access downloaded softUrare has to their computers.
~ CA certificates. Used to identify CAs. Client and server software use CA
certificates to determine what other certificates can be trusted. See _H~~w CA Certificates Are Used to Establish Trust.
Exarnpiee The CA certificates stored in Communicator determine what other certificates that copy of Communicator carp authenticate. An administrator can implement some aspects of corporate security policies by controlling the CA certificates stored in each Fuser's copy of Communicator.
The sections that follow describes how certificates are used by l~Jetscape prodLicts.
~ ~~t~C~!
The Secure Sockets Layer (SSL) protocol, which was originally developed by ~letscape, is a set of rules governing server authentication, client authentication, ar~~d encrypted communication between servers and clients. SSL is widely used on the Internet, especially for iinteractions that involve exchanging confidential information such as credit card numbers.
SSL requires a server SSL certificate, at a minimum. As part of tlhe initial "handshake°' process, the seneer presents its certificaie to the client to authenticate the server°s identity. The authentication process uses public-I~ey Encry~~tion and Di ital Signatures to confirm that the server is in fact the server it claims to be. Once the server has been authenticated, the client and server use techniques of Summetric-~Cey Fncry~tior~, which is very fast, to encrypt all the information they exchange for the remainder of the session and i:o detect any tampering that may have occurred.
Servers may optionally be configured to require client authentication as well as server authentication. In this case, after server authentication is successfully completed, the client must also present its certificate to the server to authenticate the client°s identity before the encrypted SSL session can be established.
For an overview of client authentication over SSL and how it diffE;rs from password-based authentication, see Authentication Confirms an Identity. For more= detailed information about SSL, see Introduction to SSL.
s~aer~n~ tee!
Some small programs (including Messenger, which is part of Communicator) support digitally signed and encrypted small using a widely accepted protocol known as Secure Multipurpose Internet Maii Extension (SIMIME). Using SIMIME to sign or encrypt small messages requires the sender of the message to have an SIMIME certifica~:e.

An email message fihat includes a digital signature provides some assurance tf pat it was in facfi sent by the person whose name appear s in the message header, thus providing authentication of the sender. if the digital signafiure cannot be validated by the emai!
software on the receiving end, the user will be alerted.
the digital signature is unique fio the message it accompanies. !f the message received differs in any way from the message that was sent--even by fihe addition c~r de9etion of a comma--the digital signature cannot be validated. Therefore, signed email also provides some assurance that the email has not been tampered with. As discussed at the beginning of this docurr~ent, this kind of assurance is known as nonrepudiation. In other words, signed ernail makes it very difficult for the sender to deny having sent the message. This is important for many forms of business communication. (For information about the way digital signatures work, see ~icaital Signatures.) SI~IIME also makes it possible to encrypt email messages. This is also important for some business users. However, using encryption for emaii requires cairefu!
planning. If the recipient of encrypted email messages loses his or her private key and does not have access to a backup copy of the key, for example, the encrypted messages can neve3° be decrypfied.
isle ~~
network users are frequently required to remember multiple pas:;words for the various services they use. For example, a user might have to type a different pase;word to log ini,o the network, collect email, use directory services, use the corporate calendar program, and access various servers. fVluitiple passwords are an ongoing headache for both users and system administrators.
~Jsers have difficulty keeping track of different passwords, tend to choose poor ones, and fiend to write them down in obvious places. Administrators rrfust keep track of a separate password database on each server and deal with pofiential security problems related to the fact that passwords are sent over the network routinely and frequently.
Solving this problem requires some wa,~ for a user to log in once, using a single password, and get authenticated access to ail network resources that user is authorized to use--without sending any passwords over the network. This capability is known as ser~g(e ~Igr~-~n.
Soth client SSL certificates and S/P~IME certificates can play a significant role in a comprehensive single sign-on solution. For example, one form of single sign-on :supported by I~etscape products relies on SSL client authentication {see Certificate-used Authentication). A
user can log in once, using a single password to the local client's private-key dafiabase~, and get authenticated access to ail SSL-enabled servers that user is authorized to use--without sending any passwords over fihe network. This approach simplifies access for users, because they don't need to enter passwords for each new server. It also simplifies nefiwork management, since administrators can control access by confirolling lists of certificate authorities (CAs) r~ather'than much longer lisfis of users and passwords.
In addition to using certificates, a complete single-sign on solution musfi address the need to interoperate with enterprise systems, such as the underlying operating system, fihat rely on passwords or ofiher forms of authentication.
For information aboufi the single sign-on support ourrently provided by ~9etscape products, see Single Sign-On De~loyment Guide.
~~wa me lVlany kinds of e-commerce require the ability to provide persistent proof that someone has authorized a transaction. Although SSL provides transient client authentication for the duration of an SSL connection, it does not provide persisfient authentication for transactions fihat rnay occur during that connection. S/MI~~ provides persistent authentication for email, but e-commerce often involves filling in a form on a web page rather than sending an email.
l~

The Netscape technology known as form signing addresses the need for persistent authentication of financial transactions. Form signing allows a user to associate a digital signature with web-based data generated as the result of a transaction, such as a purchase order or other financial document. The private key associated with either a client SSL certificate or an S/I'~if~~ certificate may be used for this purpose.
When a user clicks the Submit button on a web-based form that supports form signing, a dialog box appears that displays the exact text to be signed. The form designer can either specify the certificate that should be used or allow the user to select a certificate from among the client SSL
and SIIUiIIVI~ certificates that are ir~stallecl in Communicator. When the user clicks ~K, vhe text is signed, and both the text and the digital signature a.°e submitted to the server. The server can then use a loletscape utility called the Signature ~/erificaticn Tool tc validate the digital sigr~aturp.
For more information about support for form signing in Netscape products, see ~letscaoe Form Si rDin .
~eca ini Communicator and other ~Iefscape products suppod~t a set of tools and technologies called object signing. ~bject signing uses standard technigues of public-key cryptography to let users get reliable information about c~de they download in much the same way they can get reliable information about shrink-wrapped software.
lost importantly, object signing helps users and network administrators implement decisions about software distributed over intranets or the Inter°net--for example, whether to allow Java appiets signed by a given entity to use specific computer capabilities on specific users° machines.
The '°objects°' signed with object signing technology can be appfeas or other Java code, JavaScript scripts, plug-ins, or any kind of file. The "signature°° is a digital signai:ure. Signed objects and their signatures are typically stored in a special file called a JAR file.
Software developers and others who wish to sign files using object-Signing technology must first obtain an object-signing certificate.
For more information about support for object signing in iVetscape products, see f~etscaoe ~Jbject S~ninc~: Establishing Trust for Downloaded Software.

a~lE
The contents of certificates supported by Netscape and many other softvaare companies are organized according to the X.509 v3 Certificate specification, chinch has been recommended by the international Telecommunioations Union (ITU), an internatiorral standards body, since 198.
Users don't usually need to be concerned about the exact oonter~ts of a certificate. ~iovvever, sysfiem administrators working with oer~aficates may need some f~amiliaritynaith the information provided here.
i~~~nis~rnes An X.509 v3 certificate binds a diatiingui~her~arrre (D~9) to a public key. A
DlW is a series of name-value pairs, such as uid=doe, that uniquely identify an entity--that is, tile certifioate subject.
For example, this might be a typical DN for an employee of Netscape Communications Corporation:
uid=doe,e=doe@netscape.com,cn=John Doe,o=Netscape Comrnunications Cc~rp.,c=U s The abbreviations before each equal sign in this example have tllese meaning:>:
uid: user iD
~ e: email address ~ cn: the user's common name ~ o: organization ~ o: country DNs may include a variety of other name-value pairs. They are used to identify both certificate subjects and entries in directories that support the Lightweight Directory Acces s Protocol (LD~f').
The rules governing the construction of DNs can be quite complex and are beyond the scope of This document. For comprehensive information about DNs, see ,~s String Representation ~f ~isfinc~uished Names.
~°yicl ~r~ii~e Every X.509 certificate consists of two sections:
~ The data section includes the following information:
o The version number of the X.509 standard supported by the certificate.
o The certificate's serial number. Every certificate issued by a C.~ has a serial number that is unique among the certificates issued by that C~..
0 information o information about the user's public '~ey, including the algorithm used and a representation of the key itself.
o The DN of the CA that issued the certificate.
o The period during which the certificate is valid (for example, between 1:00 p.m.
on November 15, 1990 and 1:00 p.m. November' 15, 1997) o The DN of the certificate subject (for example, in a c&ienfi SQL certificate this would be the user's DN), also called the subject name.
o ~ptional cestiifioate exter~siorls9 which may pro~ride additional data used by 'the client or server. For example, the certificate type extension indicates the type of 2 C~

certificate--that is, whether it is a client SSL certificate, a serveiP SSL
ca~rtificate, a certificate for signing email, and so on. Certificate extensions can also be used for a variefy of other purposes.
~ The signature section includes the following information:
o The cryptographic algorithm, or cipher, used by the issuing CA to create its own digital signature. For more information about ciphers, see Irotroduction to SSL.
o The GA's digital signature, obtained by hashing all of the data in the certificate together and encrypting it with the CA"s private ~;ey.
Here are the data and signature sections of a certificate in human-readable format:
Certificate:
Data:
i/ersion: v3 (Ox2j Serial dumber: 3 (0x3) Signature Algorithm: PKCS #1 MD5 ~Jith RSA Encryption Issuer: ~U=Ace Certificate Authority, ~=Ace Industry, C=US
ifalidity:
dot Sefore: Fri ~ct 17 18:35:25 1997 i~ot After: Sun ~ct 17 18:36:25 1999 Subject: Cf~=Jane Doe, ~3U=Finance, CJ=Ace Industry, C=US
Subject Public Key Info:
Aigorithm: PKCS #1 RSA Encryption Public Key:
f~odulus:
00:ca:fa:79:98:8f:19:f8:dT:de:e4:49:80:48:e6:2a:2a:~B6:
ed:27:40:4d:86: b3:05:c0:01: bb:50:15:c9:de:dc:85:19:22:
43:7d:45:6d:71:4e:17:3d:~f0:35:4b:5b:7t:a8:51:a3:a1:00:
98:ce:7f:47:50:2c:93:36:7c:01:6e:cb:89:06:41:72:b5:e9:
73:49:38:76:ef:b6:8f:ac:49:bb:63:Of:9b:ff:16:2a:e3:0n:
9d:3b:af:ce:9a:3e:48:55:de:9tj:61:d5:0a:11:2a:a2:8Co:b0:
7d:d8:99:cb:0c:99:34:c9:ab:25:06:a8:31:ad:8c:4b:aa:54:
91:f4:15 Public Exponent: 65537 (0x10001 ~
Extensions:
Identifier: Certificate Type Critical: no Certified Usage:
SSL Client Identifier: Authority Key 9dentifier Critical: no Key identifier:
f2:f2:06:59:90:18:47:51:f5:89:33;5a:31:7a:e6:5c:fb:3~r:
26:c9 Signature:
Algorithm: PKCS #1 fVIDS ilVith RSA Encryption Signature:
6d:23:af:f3:d3:b6:7a:df:90:df:cd:7e:18:6c:01:69:8e:54:65:fc:08:
30:43:34:d1:63:1f:06:7d:c3:40:a8:2a:82:c1:a4:83:2a:fb:2e:8f:fb:
f0:6d:ff:75:a3:78:f7:52:47:46:52:97:1 d:d9:c6:11:0a:02:a2:e0:cc:
2a:75:5c:8b:b8:9b:87:00:7d:7c:84:76:79:ba:v8:b4:d2:62:58:c3:c5:
b6:c1:43:ac:63:44:42:fd:af:cB:Of:2f:38:85:6d:d6:59:e8:41:42:a5:
4a:e5:26:38:ff:32:78:a1:38:f1:ed:dc:Od:31:d1:b0:6d:57:e9~:46:a8:
dd:c4 Here is the same certificate displayed in the 54-byte-encoded form interpreted by software:

_____BEGIi~ CERTIFICATE-____ NiIICICzCCAZSgAwIBAgIBAzA~BgkqhkiGJwOBAC~C~FADA3IViC,2awCGYDVC~GI<: EwJVUzEF2 MA8GA1 UEChII~!'~mVOc2~lhcGUxFTATBg~JVBAsTDF~1 cFiJpe'~JEnoyBD~TA,eFw05~zEw (~TgwMT~/l2~djVaFw050TEw~(TgwNITiVI2~jVah~EgxCzAJE3gIVVBAYTAIVTf~iRl=vvDwYDVQQK

Ewh~ZXRzY2FwZTEIVI~AsGA1 UECxII~EUHViczE~f~BUGA1 UE=AxP~i0U3Vwcm15YSBTaGVO
dl-ikwgZBwDQYJI6oZIhvcNAC~EFBQADgY~A~3IGJAoGBAI~r6eG:iPGfjX3uRJgE:jmKiqG
7SdATYazBcABuIAVyd7chRkiC~31 FbXFGGDBw~lktbf6hl~o6EAml~SIRlAskzZ8AW7L
iC~ZE3crXpo0k4du+2C~6xJu21ViPmiBW&6uMOnTuvzpo+SGXeImHVChEqooCwfdi:~ywyZ
IV~imrJgaof~la2S5pUkfC~VAgIr~BAAGII~jAOMBEGCWCGSAGC~~-EIBAQC~EAwIAgDAfBg~(V
~ISMEGDAWgBTyBgZZkBhF-IUfWJIViI oxeuZc+zYmyTAfVBgkqhE;iG9wOBAQC~FAAOBgC~Bt 16Iz07Z635DfzX~XbAFpjIRIIAYwC~zT sYxBGfoh~AqCqCwaSDKv~~ujBvwbf91o3j3 UkdGYpcd2cYRCgKi411nwqdWyLtpuFiAl~--81 BhI~Z5uvi00mJYw8W2wUCsYORCIaIIDy84 hW3WWehBUqVK5SY4./zJ4oTjxldwIVPv9dGwbWfpRqjd1A==
_____E~~ CERTIFICATE-____ i~c~~9ir Certificate authorities {CAs) are entities that validate identities arid issue certificates. They can be either independent third parties or organizations running their own certificate-issuing server software {such as the ~ietscape Certificate Server). A list of third-party certificate authorities is available at Certificate Authority services.
Any client or server software that supports certificates maintains a collection of trusted CA
certificates. These CA certificates determine which other certificates the software can validate--in other words, which issuers of certificates the software can trust. In the simplest case, the software can validate only certificates issued by one of the CAs i~or which it has a certifioate. It's also possible for a trusted CA certificate to be part of a ohain of (~A
certificates, each issued by fhe CA above it in a certificate hierarchy.
The sections that follow explains how certificate hierarchies and certificate chains determine what certificates software can trust.
CA I-(ierarchies Certificate Chains Verifvinq a Certificate Chain Fiirrci~
in large organizations, it may be appropriate ~co delegate the responsibility for issuing certificates to several different certificate authorities. For ~;xampie, the number of certificat~;s required may be loo large for a single CA to maintain; different organizational units may have different policy requirements; or it may be important for a CA to be physically loc>ated in the same geographic area as the people to whom it is issuing certificates.
It's possible to delegate certificate-issuing responsibilities to subordinate CAs. -the X.5fl9 standard includes a model for setting up a hierarchy of CAs like i:hat shown in j:-igure 6.
F°sg~are xarvyle ~f a hierarchy e~f certifl~ate a~th~rlties Rcc'~'t C<~
r,~ia ~Eur~ope ~.l~r"~
C.~,. C,~, t..~, Sub4:~rdit~~.~Sub~rdir~a~ abf~rdinar~

CA. ~~~ Cue.

~sl~s t~~.r~~ in ~
~:,~ ~ngin erring . C

t~ubt5rdinate~ubr~rdin~.teSubc~rdina ~a~. ~~ f.~l~ss ~~.
~rtif l c~ta issued b~

En~naerin,~C~~

in this model, the root CA is of the top of the hierarchy. ~'he root CA's certificate is a self~sign~~
certifies#e: that is, the certificate is digitally signed by the same enfity--the root CA--that the certificate identifies. the CAs that are directly subordinate to the root CA
have CA certificates signed by the root CA. CAs under the subordinate CAs in the hierarchy have their CA certificates signed by the higher-level subordinate ~:<As.
Organizations have a great deal of flexibility in terms of the way i:hey set up their CA hierarchies.
figure ~ shows just one example; many other arrangements are possible.

~ 9ftC~f~l~lYi~
CA hierarchies are reflected in certificate chains. A "certificate chaa~ is series csf certificates issued by successive CAs. Ficiure 7 shows a oertificate chain leading fr~m a certificate that identifies some entity through two subordinate: CA certificates to the CA
certificate for the root CA
(based on the CA hierarchy shown in Figure 6}.
Figure 7 Exarr~pie ~f a certificate chairs r~ . ~A, c~rtifi~~~
c~~~~ C

. signs t~y~
sslf ~rU~.~?d SUtfWrlCr, _________________________ ~~ ~Br~,IfIC~~
~.si~. Euro~s C~~ i:~Lt..t~. si~rre~
CA -,' ~y R~ot CA

l~r~trust.sd authority _____ ______________ Cp~ ~~r~,itieate 1 ~alss ~arl~tirrg Err~r~e~ir~,. siLned i~~,. b~

V u7A
W Lu ~.~ntrr~stsd,auth~~rit~

certificates issusd E~y Eryr~eeriry i~~, Pr~~ra rte 'uwrifyi~ae ~,e ~fi ~tt.~.=.
A certificate chain traces a path of certificates from a branch in the hierarch', to the root of the hierarchy. In a certificate chain, the following occur:
~ Fach certificate is folloEnred by the certificate of its issuer.
~ each certificate contains the name (l~~j of that certificate"s issuer, which is the same as the subject name of the next certificate in the chain.
in Fie~ure 7, the engineering CA certificate contains the ~~9 of the CA
(that is, IJ~A CA), that issued that certificate. tJ~>A CA°s ~i~ is a Bso the subject name of the next certificate in the chain.
Each certificate is signed with the private key of its issuer. the signature can be v~:rified with the prabiic key in the issuer's certificate, which is the next certificate= in the chain.
in Figure T, the public key in the oe~°tificate for the l~~A CA can be used to verify the IJ~A CA°s digital signature on the c~;rtificate for the Engineering CA.
2~

~'erifir~~rfii~f~ ire Certificate chain verification is the process of making sure a given certificate chain is vu°ell~formed, valid, properly signed, and trustworthy. ~letscape software uses the following procedure for forming and verifying a certificate chain, starting with the certificate being presented for authentication:
1. The certificate validity period is checked against the current time provided by the verifier°s system clock.
2. The issuer°s certificate is located. The source can be either the verifier°s local certificate database ion that client or server) or the certificate chain provided by the subject (for example, over an SSL eonnecticn}.
3. T6le certificate signature is verified using the public key in the issuer°s certificate.
4. If the issuer°s certificate is trusted by the verifier in the vE:r°ifler°s certificate database, verification stops successfully here. C7therwise, the issuer°s certificate is checked to make sure it contains the appropriate subordinate CA indication in the ~etscape certificate type extension, and chain verification returns t~ step 1 t~ start again, but with this new certificate. Figure ~ presents an example of this process.
Figure ~ Verif~ging a certificate chairs all the way t~ the r~~1: ~
Tr°u:.°ced authority ~.er~t~ft~~.~~
Un~.rusted au~h~rityr : ~I,'', ~<,~ '~heclt vslidity her°i~ad and v~~rif~r ~ha~ this 4'a ~e.i~rc~.~:~ is si~rnd ~y F~c~c~t C~~. ~in~e Fwc~~~. ~~=~. is t.~"USC.ed,'9'eP'IfiWtIOn S~~ps here.
Uritrusted authority E~y~~rin~ Che~lc validity period arid verifpr chat this !~r~. ~.~t~~i~~at~ ' is signed by ~l~'~, c;.~. since LJ~,~. Cad. is n o t trust d, oh ec lc ~th a n e:~t; ~~e r°titn see .
Che~cl~ validity period an d ~e~rif~ :hat this arr.ifi~ate Issued ~y 4 a..~. is signed b,P~ Engineering C~~. Sin=
Engineering ~A Er~gineerin~ ~,~ is not~.r~asr:.ed, aheclc tfe ne:~t certificate.
~er6fyirs~ t.&se:
c~ rt~fa Figure 8 shows what happens when only foot C~, is included in the verifier°s local database. If a certificate for one of the intermediate Cps shown in Figure 8, such as Engineering CA, is found in the verifier's local database, verification stops with that certificate., as shs~wn in Figure g.
Figure ~ Verifying a certificate chairs t~ ar9 srstereiat~ CA, Trusted ~.~athority ==,Enrrlerir~...
:~ ~e'r~,ifi~a~.d W~e~h vralidity ~er~i~d and °rerify that ~'ertificate issua~ ~~ t.his is signed by EnginPerin,g C~ Singe Engineering C~. Engineering Cue. is trusted, brerifnat~ on stops here.
~r~rir~the ce rtafa Expired validity dates, an invaiid signature, or the absence of a certificate for the issuing CA at any point in the certificate chase causes authentication to fail. For example, Fi~!.~re ~ ~ shows how verification fails if neither the F2oot CA certificate nor any of the intermediate C~ certificates are included in fhe verifier's local database.
Fissure 10 certificate chairs that can°t he versfioe~
i.~ntrus~.ed authcritr :.:~~~c~t ~., :-.': ~er~;i~i~at~~.
?.
Checl~~ ~r~lidit~ period and ~rer°if~~ that this ~~nt.rusteci authr~rity ~'. ~~. is Sidney b~ F".~~ot C.~.. Sin~f; F~r~ot ~~6 is cer°~,ificete . - nit tr~usre~, ~.errificate chairs canne~t b a ,.
~erifmd and ~(ient authentieatir~n fails.
Untrusted authority .,~~n~~~°rty~ ~~he~i< validity period and verify that. this C~, ~r~.~c~~~;, is si~nad by l~~~. since t~S~~~ CA is Wot trusted, cheeict.he next; certifieate.
Checlt ~r~Jidit~ ~~eri~d an d ~rs~rit~ that this Certificate issued ~~ ';. .~,:.,.. . is Sidney by En ~ineerin~ C~'~.. Sirn~e Engineering ~a~ _ En~ineerin,~ Cri is nottrust:e~, che~.ic the nest. t.er°tifi~.ate.

management is complex topic beyond the scope of this document. The sections that follow introduce some of the specific certificate management issues addressed by Netscape products.
Issuing Certificates Certificates and the LDAp Director Key Management Renewing and Revoking Certificates I~ec~istration Authorities ~lJi~9 1°~~fit The process for issuing a certificate depends on the certificate authority that isvsues it and the purpose for which it will be used. The process for issuing nondigita( forms of identification varies in similar ways. !or example, if you want lo get a generic ID card (not a driver's license) from the Department of Motor Vehicles in California, the requirements are straightforward: you need to present some evidence of your idenfiity, such as a utility bill with your address on it and a student identity card. If you want to get a regular driving license, you also need to take <~ test--a driving test when you first get the license, and a written test when you renew it. If you want to get a commercial license for an eighteen-wheeler, the requirements are much more stringent. If you live in some other stale or country, the requirements for various kinds of licenses will differ.
Similarly, different CAs have different pr ocedures for issuing diffE:reni kinds of certificates. In some cases the only requirement may be your small address. In other oases, your Unix or I~T
login and password may be sufficient. At the other end of the scale, for certificates that identify people who can authorize large expenditures or make other sensitive decisions, the issuing process may require notarized documents, a background check, and a personal intervievr.
Depending on an organization°s policies, the process of issuing certificates can range from being completely transparent for the user to requiring significant user participation and complex procedures. In general, processes for issuing certificates should be highly flexible, so organizations can tailor them to their changing needs.
The I~etscape Certificate Server, part of the Mission Control famiil~ of products, allows an organization to set up its own certificate authority and issue certiBicates.
Issuing certificates is one of several managements tasks that care be handled by separate Registration Authorities.
i~~ts era t a L ~~t The Lightweight Directory Access protocol (LDAp) for accessing directory services supports great flexibility in the management of certificates within an organization.
System administrators can store much of the information required to manage certificates in an LDAp-compliaret directory.
for example, a CA can use informafiion in a directory to prepopulate a certificate with a new employee°s legal name and other information. The CA can leverage directory information in other ways to issue certificates one at a time or in bulk, using a range of different identification techniques depending on the security policies of a given organiz<~tion. ~ther routine management tasks, such as Key Management and Renewing and Revoking Certificates, can be partially or fully automated with the aid of the directory.
Information stored in the directory can also be used with certificates to control access to various network resources by different users or groups. Issuing certificat~a and other certificate management tasks can thus be an integral part of user and group management.
In general, high-performance directory services are an essential iingredient of any certificate management strategy. The ~letscape Directory Server, part of the= Mission Control family of products, is fully integrated with the Netscape Certificate Server to provide a comprehensive certificate management solution.

rlt Sefore a certificate can be issued, the public key if contains and the corresponding private key must be generated. Sometimes it may be useful to issue a single person one certificate and key pair for signing operations, and another certificate and key pair for erscryption operations.
Separate signing and encryption certificates make it possible to keep the private signing key on the IocaB machine only, thus providing maximum nonrepudiation, and to bank up the private encryption key in sor~re central location where it can be retrieved in case the u:oer loses the original key or issues the company.
iEeys can be generated by client software or generated centrally by the CA and distributed to users via an L~AP directory. There are trade-offs involved in choosing between local and centralized key generation. For example, local key generation provides maximE.am nonrepudiation, but may inVOIve i-nore participation by fhe user in the issuing process.
Flexible key management capabilities are essential for most organizations.
Key reo~very, or the ability to retrieve backups of encryption keys under carefully defined conditions, can be a orucial part of certificate management (depending on how an organization uses cerfificates~. iCey recovery schemes usually involve an rn oaf r~
mechanism: for example, an of n managers within an organization might have to agree, and each contribute a special code or key of their own, before a particular person's encryption key can be recovered. This kio~d of mechanism ensures That several authorized personnel must agree before an encryption key can be recovered.
~ v~i~t Like a driver's license, a certificate specifies a period of time during which it is valid. Attempts to use a certificate for authentication before or after its validity period will fail. Therefore, mechanisms for managing certificate renewal are essential for any certificate management strategy. For example, an administratof- may wish to be notified aautomafically when a certificate is about to expire, so that an appropriate renewal process can be completed in plenty of time without causing the certificate's subject any inconvenience. The renewal process may involve reusing the same public-private key pair or issuing a new one.
A driver's license can be suspended even if it has not expired--for example, as punishment for a , serious driving offense. Similarly, it's sometimes necessary to revoke a certificate before it has expired--for example, if an employee leaves a company or movers to a new job within the company.
Certificate revocation can be handled in several different ways. i=or some organizations, it may be sufficient to set up servers so that the authentication process includes checking the directory for the presence of the certificate being presented. Vllhen an administrator revokes a certificate, fl-~e certificate can be automatically removed from the directory, and subsequent authentication attempts with that certificate will fail even though the certificate remains valid in every other respect. Another approach involves publishing a certificate reva~cati~n list (CRL)--that is, a list of revoked certificates--to the directory at regular intervals and checking the list: as part: of the authentication process. For some organizations, it rnay be preferable to check ~direcfly with the issuing CA each time a certificate is presented for authentication. This procedure is sometimes called real~tirrse stata~s checkira~m a itrtori~
Interactions between entities identified by cerhificates (sometime;s called Brad entities) and CAs are an essential part of certificate management. These interactions include operations such as registration for certification, certificate retrieval, certificate renewal, certificate revocation, and key backup and recovery. In general, a CA must be able to authenticate the identifies of end entities before responding to the requests. In addition, some requests n~;ed to be approved by authorized administrators or managers before being services.

d~s previously discussed, the means used by different CAs to veeify an identity before issuing a certificate can vary widely, depending on the organization and the purpose for ~rvhich the certificate will be used. '~o provide maximum operational flexibility, interactions with end entities can be separated from the other functions of a CA and handled by a separate service called a eistrati~s~ Ruth~r~ty (}.
An E~ acts as a front end to a C~ by receiving end entity reque~;ts, authenticating there, and forwarding them to the C~,. /after receiving a response from the C:~, the I~A
notifies the end entity of the resulfis. Rids can be helpful in scaling an PICI across differE:nt departments, geographical areas, or other operational units with varying policies and authentication requirements.
future versions of the ~Jetsca~e Certificate Server will support the creation of customizable registration authorities.

Claims