FFIINNAALL RREEPPOORRTT OOFF DDEEVVEELLOOPPMMEENNTT OOFF AA CCEERRTTIIFFIICCAATTIIOONN AAUUTTHHOORRIITTYY FFOORR TTHHEE UUNNIIVVEERRSSIITTYY

(A project of ECE646, Fall 2001)

By: PARX Group Prakairat Moon Archana Sarda Rama Donthireddy Xinwen Zhang

FALL, 2001

DEPARTMENT OF ELECTRICAL AND COMPUTER ENGINEERING

SCHOOL OF INFORMATION TECHNOLOGY AND ENGINEERING

GEORGE MASON UNIVERSITY

1

TABLE OF CONTENTS 1.0 Introduction 2.0 Digital certificates 3.0 Parties of PARX Services 4.0 Services provided to the end user

4.1 Key Management 4.1.1 User Key Management 4.1.2 PARX Key Management

4.2 Certificate Enrollment and Certificate Generation 4.2.1 Certificate Enrollment 4.2.2 Certificate Generation

5.0 PARX Design 6.0 Standards 7.0 Obligations Practices and Procedures

7.1 Prior to requesting a PARX Certificate 7.2 Requesting a PARX certificate 7.3 Verification of digital signature 7.4 Suspension and Revocation

8.0 Liability 8.1 Liability for PARX CA 8.2 Liability of subscriber 8.3 Problems Encountered

9.0 References 10.0 User Guide

2

PARX Certification Service

1.0 Introduction: PARX is a Trust service Provider. The PARX certification services aim at supporting secure communication within the departments of the university. To achieve this goal the PARX certification service would serve as a trusted third party for using managing, suspending and revoking certificates in accordance with the published practices. The PARX certification service is initially being created for the ECE department consisting for 800 students and 25 faculty members. This service would be extended soon for the entire university. PARX currently offers different types of services and related products that can be used in a way that addresses the needs of users for secure communication. Services provided: Our users are the department students, faculty and staff. It helps the users perform secure email and web browsing. It also provides the users with the access to the software that provides a time stamping service and Virtual Private Networks service.

2.0 Digital certificates: In electronic transactions digital certificates allow entities that participate to prove their identity to other participants. PARX certification service with the help of digital certificates confirms the relationship between a named entity and its public key. The process to obtain digital certificates involves identification naming, authentication and registration of the client as well as the issuance, revocation and expiration of the digital certificates. Thus PARX provides a strong confirmation of the identity of the user. 3.0 Parties of PARX PKI Services:

�� PARX Certification Authority: PARX certification authority is the one that issues the digital certificates. In this document it is also sometimes referred to as the issuing authority. It also decides the policies related to the issuances of certificates for the different class of services. PARX is also responsible for publishing the revocation list of certificates for the relying parties.

�� PARX registration authorities: The subscribers of PARX certification services

reach it through a network of appropriately selected local registration authorities (LRA). They interact with both the subscriber and the PARX certification authority to deliver the PKI services. They do the following

1. Accept, evaluate, approve or reject the registration of the certificate applications.

3

2. Register subscriber to the PARX certification services 3. Attend all stages of the identification and verification of the subscribers as

decided by the PARX depending on the class of service. 4. To evaluate a subscriber’s application they make use of a document

published by PARX. 5. After the approval of the subscriber’s application it notifies PARX to issue

a certificate. 6. IT also initiates the process to revoke a certificate and request a certificate

revocation from PARX PARX LRA’s work locally with in the their own context as decided by PARX. The number of LRA’s is decided upon the size of the organization. They are trusted entities and are given the required training by PARX.

�� Subscribers: The subscribers of the PARX certification service include students, staff and faculty of the ECE department of George Mason University. They are the parties that apply for certificates identified in a certificate and hold the private key corresponding to the public key listed in their certificate. The subscribers must always refer to the PARX Certificate Revocation list prior to relying on the information in the certificate.

4.0 Services that must be provided to the end user: The end user of this system for the university would be students and faculty. The different types of services that could be provided include.

4.1 Key management: Key management deals with the secure generation, distribution, and storage of keys. Secure methods of key management are extremely important. Once a key is randomly generated it must remain secret to avoid unfortunate mishaps (such as impersonation). In practice, most attacks on public-key systems will probably be aimed at the key management level, rather than at the cryptographic algorithm itself. Users must be able to securely obtain a key pair suited to their efficiency and security needs.

4.1.1 User key management: The user would be provided with the option of generating the key pair with software of his own choice (eg: PGP) or use the software provided by PARX certification service to generate it for him. In the former, the user needs some way to trust his or her copy of the key generation software. In the latter case the user must trust the service and the private key must be transferred securely to the user. But in either of the cases, PARX certification authority is not responsible for the secure storage of private key.

Private keys must be stored securely since forgery and loss of privacy could result from compromise. The measures taken to protect a private key

4

must be at least equal to the required security of the messages encrypted with that key. The subscriber could secure his private key by encrypting it using passwords or keep it in a tamper-proof hardware token such as smart card or use a central system associated with the CA. However, passwords are sometimes very easily guessed; when this scheme is followed, a password should be chosen very carefully since the security is tied directly to the password. Storing the encrypted key on a disk that is not accessible through a computer network, such as a floppy disk or a local hard disk, will make some attacks more difficult. It might be best to store the key in a computer that is not accessible to other users or on removable media the user can remove and take with his when he has finished using a particular computer. Private keys may also be stored on portable hardware, such as a smart card. Users with extremely high security needs, such as certifying authorities, should use tamper-resistant devices to protect their private keys. If someone's private key is lost or compromised, he should notify our certifying authority for the public keys and have his public key placed on a certificate revocation list, others are made aware of this, so they will no longer encrypt messages under the invalid public key nor accept messages signed with the invalid private key. The user may wish to use the new private key to re-sign documents he had signed with the compromised private key, though documents that had been time stamped as well as signed might still be valid In order to guard against a long-term cryptanalytic attack, every key must have an expiration date .The expiration date must be chosen properly and publicized 4.1.2 PARX’s key management: PARX software uses RSA algorithm for the key generation and the key size is of 1024 bits. The private key of the PARX service is used to sign the PARX issued certificates, PARX certification revocation lists and accredited root-signed entities.

Our service generates and protects its own private keys using a trustworthy system and takes necessary precautions to prevent the compromise or unauthorized usage of it. It distributes the secret shares of its private keys. It is the owner of the private key and has the authority to transfer such secret shares to authorized secret shareholders. The generation of the private key of the PARX requires the control of more than one appropriately authorized member of staff serving in trustworthy positions. More than one members of the management make authorization of key generation in writing. The generation and storage of

5

private key occur within a secure cryptographic device meeting the required standards. The storage of the private key of PARX requires multiple controls by appropriately authorized members of staff serving in trustworthy positions. More than one members of the management makes authorization of key storage.

It is extremely important that the private keys of our certifying authority are stored securely. The compromise of this information would allow the generation of certificates for fraudulent public keys. One way to achieve the desired security is to store the key in a tamper-resistant device. The device should preferably destroy its contents if ever opened, and be shielded against attacks using electromagnetic radiation. Not even employees of our certifying authority have access to the private key itself, but only the ability to use the private key in the process of issuing certificates.

To resist the cryptanalytic attacks our service uses long keys and changes the keys very regularly. We are trying to take measures on time spoofing also.

If our key is lost or destroyed but not compromised, certificates signed with the old key are still valid, as long as the verifier knows to use the old public key to verify the certificate. If a compromise does occur, we immediately cease issuing certificates under its old key and change to a new key. If it is suspected that some phony certificates were issued, all certificates are recalled and then reissued with the new CA key. These measures could be relaxed somewhat if the certificates were registered with a digital time stamping service to supply another one with the same internal information, thus allowing recovery of the key.

4.2 Certificate enrollment and certificate generation. 4.2.1 Certificate enrollment:

Whenever a student wants to request a certificate from the PARX service he/she has send a CRS to the LRA. The format used must be PKCS#10.The LRA examines the request and gives specific date and time. The student must appear at the LRA office personally on the given day and must take the following steps �� Generate a key pair and demonstrate to the service that it is such a key pair

and that the private key corresponds to it. �� Protect the integrity of the private key of the generated pair �� Submit a filled out certificate application (The information depends on the

class of certificate he is seeking)

6

�� Additional request asking the service to generate a key pair for him if he doesn’t generate one for him.

�� Agree with the terms of a subscriber agreement and PARX’s CPS (certificate practice statement)

�� Submit the public key of the generated pair �� Provide proof of identity such as a valid I20, passport, George Mason

Student ID etc. He is then given a tracking number, which can be used to check the application status from time to time. The LRA validates the information by cross checking it with the information in its database and sends the list of authenticated students to the CA along with the public keys .The communication between the LRA and the CA is done securely using SSL.

4.2.2 Certificate generation:

Once the CA receives and validates a certificate registration or receives a request from LRA, it checks the identification and takes any other steps necessary to assure itself that the public key was not modified in transit on its way from the LRA (The communication between the LRA and CA is securely done using SSL). Then it generates a corresponding certificate and signs the certificate with its signing private key. The CA then forwards the certificate to the subscriber or to the LRA along with the hierarchy of certificates verifying the CA’s public .The student can present this certificate chain whenever desired in order to demonstrate the legitimacy of his public key. Optionally, the CA may back up the certificate or submit it to a certificate repository for distribution. The certificate format must be of X.509.

An X.509 certificate consists of the following fields:

�� Version �� Serial number �� Signature algorithm ID �� Issuer name �� Validity period �� Subject (user) name �� Subject public key information �� Issuer unique identifier (version 2 and 3 only) �� Subject unique identifier (version 2 and 3 only) �� Extensions (version 3 only) �� Signature on the above fields

This certificate is signed by the issuer to authenticate the binding between the subject (user's) name and the subject's public key. The major difference between versions 2 and 3 is the addition of the extensions field. This field grants more flexibility as it can convey

7

additional information beyond just the key and name binding. Standard extensions include subject and issuer attributes, certification policy information, and key usage restrictions, among others. PARX uses certain critical extension in the certificates it issues such as:

�� To show the intended usage of the key (If it is exclusively used for the class 1 or class

�� To show the number of levels in the hierarchy under a CA certificate.(For the future extension)

5.0 PARX Design:

�� Design of the CA hierarchy: The hierarchy provides certification paths between the CA and the certification using application. A certification path is a sequence of one or more connected nodes between the subscriber and the root CA.A root certification authority is an authority that the certificate using application trusts and has securely imported and stored public keys. A certificate path indicates how the certificate using application develops trust in a subscriber’s certificate. A large-scale deployment of public keys systems must support multiple CA’s and relationships among them. PARX certification is primarily meant for the ECE department and would be later extended for the entire university. Thus it would be a single root CA model. This single root CA model would also incorporate multiple RA’s as shown in the figure below. These RA’s would be responsible for subject authentication while issuing certificates. The communication between the RA’s and the root would be made secure by employing client side SSL between them. This design for the entire university would later be modified to contain multiple CA’s i.e. one CA for each department and a single root.

�� Certificate Distribution: Having generated a large number of certificates, a CA

must enable a community of users to obtain and use them. Certificate distribution is a mechanism that facilitates the above. One way to implement the above is by using a single centralized registry and providing a effective and timely access to it. The access to this database is distributed via a directory mechanism. The X.500 LDAP and other proprietary directory servers are viable alternatives for distributing certificates via directory servers.

6.0 Standards: Certificates To construct a certificate, PARX follows the following standard

�� X.509, version 3; �� Specifications of IETF/PKIX RFC 2459

PARX Directories To construct PARX public directories, PARX uses

8

�� IEFT/PKIX LDAP version 2, Schema RFC 2587 PARX Certificate Request

To construct PARX certificate Request, PARX uses standards include: �� PKCS #10 �� Microsoft IE

7.0 Obligation, Practice and Procedures: 7.1 Prior to Requesting a PARX Certificate:

Key Pair Generation

�� Subscriber is exclusively responsible to generate securely his own public key pair. Subscriber can either generate it by using a trustworthy system or by using PARX CA software.

�� PARX CA provides software online that generates public key pair as an alternative to subscribers but PARX CA has no responsibility to generate, hold subscriber’s private key nor enforce any particular private key protection requirement of any subscriber.

�� PARX CA has no liability associated with the loss of a subscriber’s private key or subscriber’s weak private key generating.

Proof of Key functionality

Subscriber must demonstrate that a key pair generated is properly functioning. PARX CA uses PKCS 10 format.

Responsibility for Private Key

PARX CA key generation facility has no liability associated with the compromise of subscriber’s private key. Subscriber is exclusively responsible to prevent his or her private key from being compromised, lost, disclosed, stolen, or illegally used. PARX CA suggests a use of smart card.

Submitting an Application

Subscriber must fill out certificate application and agree with the terms of a subscriber agreement and the cps. Subscriber then submits an application, subscriber agreement and the public key of the generated key pair to PARX LRA. Submission are perform with the online service software provided on PARX’s website.

9

7.2Requesting a PARX Certificate:

An appointment from PARX LRA will be sent to a subscriber. PARX requires personal presence of a subscriber at PARX LRA’s office. Subscriber then meets with a PARX LRA in person and proves his identity to PARX LRA.

Validation Information for Certificate Applications Information required for PARX certificate includes the following elements:

�� E -mail address �� First and last name �� Country and address �� Identification data, e.g. student ID, driving license �� Passport and visa status if applicant does not hold a U.S. citizenship �� Application’s public key �� Subscriber agreement and application form filled and properly signed

PARX CA is responsible to validate a certificate application before issuing certificate. The procedure includes

�� Verifying that the applicant is the same person identified in the request

and the applicant’s information is valid i.e. applicant’s visa is not expired.

�� Verifying that the applicant’s private key corresponding to the public key in the certificate is functioning properly.

�� Verifying the information to be listed in the certificate.

Time Required to Confirm Submitted Data Based on the information received and personal presence to prove subscriber’s identity, PARX LRA approves an application for a digital certificate unless the validation of a certificate application fails. PARX CA requires two official days to issue a certificate for an approved applicant.

Certificate Issuance and Certificate Acceptance

A certificate is then issued and information is electronically mailed to the subscriber’s e-mail address using S/MINE. A digital certificate will be valid upon subscriber’s consent. Subscriber, therefore, must reply to PARX LRA to confirm

10

his consent. In case that there is any inaccuracy or defect in a certificate, the subscriber must immediately notify PARX LRA.

If PARX LRA has not received certificate acceptance notification, a certificate is considered to be accepted when subscriber first uses it.

Publication of issued Certificate PARX CA will publish a copy of the certificate in the PARX CA repository after subscriber has accepted the certificate. Operating a PARX Certificate: Subscriber must accept a certificate before using it with others otherwise a certificate is considered to be accepted when subscriber first uses it.

Representation of Subscriber to PARX and Relying Parties Upon accepting a PARX certificate, a subscriber certifies to PARX CA and all who rely on the information in the certificate that the following information are accurate at the operational period of the certificate;

�� Each digital signature created is the digital signature of subscriber and

can be verified with the non-revoked, non-expired public key in the subscriber certificate.

�� No unauthorized user has access or knowledge to the subscriber’s key. �� All formation in the certificate is true. �� Subscriber is an end user not an issuing authority. Thus, subscriber has

no right to use his private key in the corresponding to the public key listed in the certificate to issue any other certificate.

�� Subscriber is responsible with all means to prevent his private key corresponding to the public key listed in the certificate from being lost, stolen, disclosed, modified or illegally used.

�� Subscriber is liable for any misrepresentation made in certificates to any receivers who use subscriber’s certificate to verify the subscriber’s signed message.

�� Subscriber abides by the laws regarding intellectual property protection, viruses, accessing computer systems etc.

�� Subscriber agrees on the terms and condition of PARX cps. Representation of PARX to Subscriber PARX CA must agree to the subscriber after certificate issued that

�� no misrepresentations of information in the certificate known to PARX

CA.

11

�� no data transcription errors done as a result from a failure of PARX CA in creating the certificate.

�� PARX CA will promptly revoke or suspend certificates upon request from the subscriber.

�� PARX CA will notify subscriber immediately of any knowledge regarding the material effect on the validity and reliability of subscriber’s certificate.

PARX CA does not warrant non-repudiation of any certificate or message. PARX CA does not incur liability for any representations of information contained in a certificate. PARX CA has no liability associated with the wrongful binding of an individual’s identity with any associated public key.

7.3 Verification of Digital Signature

Subscriber, upon receiving a signed message, needs to ensure first that the document is actually signed with the sender’s private key corresponding to the public key listed in the sender’s certificate and later that the content in the document has not be altered after the signature is created. Subscriber has to take steps in verification of digital signature as follows:

Obtaining a certificate chain

To verify a digital signature, user needs to establish a certificate chain. In case of cross certificate, user needs to have multiple options to select and validate a certificate chain.

Checking PARX CA or other reposition for revocation or suspension of certificate

PARX CA has an on-line status checking that subscriber can determine the sender’s certificate revocation status. Another alternative is to determine the certificate revocation status in the chain if CRLs have been provided in the certificate chain. If the certificate is not on the latest CRL, subscriber then performs the next step.

Knowledge of where digital signature is in the message

In order to be able to verify the signed data, the standard format must specify which part is the signed data.

Determine the correct signature time and date of creation Since PARX CA provides time-stamping software service, non-repudiation is supported Signed data that includes time-stamp can be verified and illustrated the time that signature is created.

12

7.4 Suspension and Revocation Condition for Suspension and Revocation A certificate will be suspended and revoked if

�� Subscriber has become officially non-affiliated with ECE department i.e. subscriber graduated or resigned from the position before the expiration of the certificate.

�� Subscriber has breached a material obligation under the cps or the certificate

is found to be misused.

�� The performance of a subscriber has resulted in another subscriber’s information threatened or compromised.

�� Subscriber’s private key has been lost, stolen, unauthorized disclosure or

compromised.

�� Subscriber’s password protection private key has been compromised.

�� PARX CA’s private key has been compromised. PARX CA reserves the right to revoke or suspend a subscriber’s certificate if it is known that the subscriber’s certificate or material prerequisite to certificate issuance was false i.e. student visa is false, the performance of a subscriber results in another person’s information compromised or subscriber is no longer affiliated with ECE department. Procedure for Revocation Request Subscriber is required to immediately request his or her certificate revocation upon his knowledge of his private key or password being compromised. The request can be done in person at LRA office at ECE department or by using PARX CA online software certificate revocation request. The procedure requires subscriber to authenticate his certificate ownership with subscriber’s name and pass phrase that is given to subscriber at the time of certificate issuance.

Publishing Certificate Revocation List Upon suspending or revoking a certificate, PARX CA must publish notice of the suspension or revocation in the PARX repository called the Certificate Revocation List (CRL). The CRL is a data structure that is digitally signed by PARX CA. Its contents include the data, time of CRL publication, name of issuing CA, and serial numbers of all revoked certificates. During suspension or revocation of a subscriber’s certificate, the certificate operation period shall immediately be considered terminated. Suspension or revocation of a certificate shall not affect any underlying contractual obligation created under the cps.

13

Subscriber is required throughout the time of certificate suspension or revocation to safe the certificate’s corresponding private key, unless destroyed. Obtaining CRL PARX CA uses CRL to disseminate information about the revoked certificates to subscribers. Each time a subscriber receives a signed message, he or she has to ensure that the message is signed with the sender key. The subscriber therefore, has to authenticate that the key belongs to the sender and the certificate holding the key is not revoked or suspended. To verify the certificate, subscriber has to obtain the most resent CRL issued by the issuing CA and ensure that the certificate’s serial number is not on the list. Propagating CRL Information

There are three ways of propagate CRL information to subscribers. Polling Method

The first one is the Polling method which subscriber access CA repository and download the latest CRL. The disadvantages of this method are that subscriber has to know the next scheduled update time. Secondly, because the revoked certificates will not be disseminated until the next schedules update, the certificates revoked during the time between the last and next update will not be available at that time. Application then relies on the out of date CRL.

Pushing Method

The second method is the Pushing method. This method uses broadcasting to disseminate CRL to subscribers once a certificate is revoked. Though this method can solve the problem of delaying update in the polling method, its downside is its impractical when number of subscribers is large. The network traffic will be overwhelmed with the broadcasting messages. There is also a concern of the secure transit of information. CA must make sure that all subscribers receive all the update CRL. If information is deleted either by maliciously intention from an intruder, or by the problem of the network communication, subscribers will not be aware of the revoked certificates.

On-Line Status Checking

The last approach is the On-Line Status Checking, subscribers will execute online query with CA to obtain the revocation list of a certificate. This method is the method of choice for PARX CA. It offers no time delay in updating the CRL and no overhead of pushing each revoked certificate’s information to all subscribers each time a certificate is revoked. PARX CA provides a server with a trusted data repository that is available at all time for on-line query. For security reason, server also has to digitally sign the result of each online query.

14

Renewal of Certificate and Procedure Certificate will be renewed if the certificate is expired and the certificate holder is still affiliated with ECE department. Under this circumstance, subscriber can request a renewal of the certificate by e-mail. In case that the subscriber wants to change the certificate’s public key, he or she has to submit a certificate request form, generate a new public key pair and prove its functionality to the LRA. 8.0 Liability: 8.1 Liability For PARX CA:

�� PARX CA is a free public service for academic purpose, therefore it would not be liable for:

1. Any loss of data. 2. Any indirect consequential or damages from the delivery, license,

performance or nonperformance of certificates. 3. Any error which is the result of fraud or willful misconduct of the

applicant. 4. Any representations of information contained in a certificate 5. Any loss of a subscriber’s private key or subscriber’s weak private key

generating. 6. Any wrongful binding of an individual’s identity with an associated public

key. 7. Non-repudiation of any certificate or message. 8. Any failure of software and hardware.

�� PARX CA is liable for the disclosure of subscribers’ personal information (It has a right to disclose any of the personal data as required by the law).

�� PARX CA acknowledges that a message bearing a digital signature verified by

the public key listed in a valid certificate is as valid, effective, and enforceable as if the message has been written and signed on paper.

8.2 Liability For Subscriber: Subscribers of PARX CA are liable for:

�� Any false or misrepresented data supplied to the PARX CA. �� Any failure of the subscriber to disclose a material fact, if the misrepresentation or

omission was made deliberately with an intention to deceive the CA or any person receiving or relying on the certificate.

�� Failure to protect subscriber’s private key that is to take precaution necessary to prevent the compromise, loss, disclosure, modification or unauthorized use of the subscriber’s private key.

15

�� Any hazardous activities that lead to the damage of the CA’s structure for example tampering with the CA’s certificates.

�� Breaking any laws including those related to intellectual property protection, viruses and accessing computer systems.

�� Doing any activity that interferes or infringes any rights of the other certificate holders which includes masquerading other subscribers.

The subscribers who try to break the above mentioned rules are subjected to the school’s honor code of violation. 8.3 Problems Encountered

�� Software availability: We could not familiarize ourselves with all the applications we promised to provide due to the cost of the software.

�� Security of the CA is not mentioned in detail. �� Liability topic is too sensitive and complex to be dealt with, as it requires legal

expertise.

9.0 References: Berbecaru, D., Lioy, A., Marian M., “On the Complexity of Public-Key Certificate Validation”, Information Security Conference, ISC 2001, Malaga, Spain, October 1-3, 2001 Martinez-Nadal A., Ferrer-Gomila J., “ Liability of Certification Authorities: A juridical Point of View”, Information Security Conference, ISC 2001, Malaga, Spain, October 1-3, 2001 Hayes, J.M. “The problem with multiple roots in Web browsers-certificate masquerading.” Proceedings Seventh IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, 1998. (WET ICE '98). Page(s): 306 –311. Perlman, R. “An overview of PKI trust models.” IEEE Network , Volume: 13 Issue: 6 , Nov.-Dec. 1999. Page(s): 38 –43 Digital Certificates by Jalal Feghhi, Jalil Feghhi, Peter Williams Cryptography and network security by William stallings, 2nd ed., Prentice Hall, Upper Saddle River, 1999 Alfred J.Menezes, Paul C.Van Oorschot and Scott A.Vanstone, Handbook of Applied Cryptography. Http://cwis.kub.nl/~frw/people/koops/pki.htm, “Public Key Infrastructures”

16

www.globalsign.com “The GlobalSign Certification Practice Statement” www.interclear.com/pki.asp “What are digital certificates”, “Risk and Liability Assessment” http://jya.com/nrcindex.htm “ Summary of Important Requirements for A Public Key Infrastructure” http://www.verisign.com/ “Verisign Help with Personal Ids”

17

10 User Guide:

1. THE PARX WEBSITE

18

2. OBTAIN THE CA CERTIFICATE All the applications such as secure email or secure website require that the client possess the CA certificate. Click on the link ‘Lets start here ‘. On the next screen as shown below check the button

�� Retrieve the CA certificate.

19

On the next screen the user has two options for installing the CA certificate

�� Install online by clicking on the Install this CA certification path �� Or the user can download the certificate to the machine and then install.

This can be done by clicking on the link Download the CA certificate

20

To see the root certificate �� Go to IE browser Tools/ Internet options and click on certificates. This being a

root certificate the browser will automatically install it in the Trusted Root Certificate Authorities

21

�� For Netscape users click on security option and then within certificate click on

signer info.

22

�� In IE the certificate looks as follows: This certificate is in the X.509 V3 format. The details tab will show more detailed information about the certificate such as the public key, algorithm etc.

23

�� In Netscape the certificate looks as follows.

24

3. APPLYING FOR A CERTIFICATE TO THE CERTIFICATE AUTHORITY �� On the screen shown below check apply for certificate:

25

�� The next screen allows the user to select the purpose for which the certificate will be used. To get more options for the intended use of the certificate the user can click on the advanced button. Clicking the next button will provide the user with a form to enter his personal information

26

�� The below screen shows the advanced certificate request form with more options for the intended purpose. The advanced request form also provides the user with the option of saving this request to a file (PKCS #10 format). The user could then send this file to the CA via email etc instead of sending it online.

27

The generated request file:

28

�� The user can then send this request to the CA as shown below. The user would be requested to go one of the Local Registration authorities to prove his identity.

29

30

�� After applying the user can then check the status of the pending certificate as

shown below

31

32

4. APPLICATIONS

1). SECURE EMAIL: SMIME with MS Outlook Express

For S/MIME setting go to Tools/options of Outlook express.

33

�� Send secure email: For sending the secure email click the sign /encrypt buttons on

the screen below.

34

35

�� Decrypt and verify the received message : The outlook express would automatically decrypt the message if the client has the valid certificate.

36

The SMIME message is shown below.

37

�� For Netscape users the email can be secured as shown below

38

2) Secure Web Server in IIS:

�� In the IIS manager, click the "properties" of specified web site:

39

�� In the "Directory Security" tab, set the "Secure communications" properties:

40

�� At first, a server certificate should be retrieved from CA. Just follow the "Web Server Certificate Wizard" to apply a new certificate from CA. The process is also the same as apply online certificate from the CA shown in section 1. A request file also can be generated and saved.

41

42

The web server certificate: the subject is the

43

�� The purpose of the certificate is for server authentication:

44

The certificate path:

45

�� Secure communication settings:

From this the user can set the SSL connection with 128-bit encryption with client browser. At the same time, the server can require/ignore/accept the client certificates. Also, the server can map each certificate to a user account in the server. The server can also identify the trust list of certificate (CTL).

46

�� To use the SSL connection, client browser also has to bee configured to "Use SSL".