MODULE -1

1. History of Cyber Crime

The information Technology Act is an outcome of the resolution dated 30th January 1997 of the
General Assembly of the United Nations, which adopted the Model Law on Electronic Commerce,
adopted the Model Law on Electronic Commerce on International Trade Law.

This resolution recommended, inter alia, that all states give favourable consideration to the said Model
Law while revising enacting new law, so that uniformity may be observed in the laws, of the various
cyber-nations, applicable to alternatives to paper based methods of communication and storage of
information.

The Department of Electronics (DoE) in July 1998 drafted the bill. However, it could only be
introduced in the House on December 16, 1999 (after a gap of almost one and a half years) when the
new IT Ministry was formed.

It underwent substantial alteration, with the Commerce Ministry making suggestions related to e-
commerce and matters pertaining to World Trade Organization (WTO) obligations.

The Ministry of Law and Company Affairs then vetted this joint draft.

• After its introduction in the House, the bill was referred to the 42-member Parliamentary
Standing Committee following demands from the Members.

• The Standing Committee made several suggestions to be incorporated into the bill.

• However, only those suggestions that were approved by the Ministry of Information
Technology were incorporated.

One of the suggestions that was highly debated upon was that a cyber café owner must maintain a
register to record the names and addresses of all people visiting his café and also a list of the websites
that they surfed.

• This suggestion was made as an attempt to curb cyber crime and to facilitate speedy locating of
a cyber criminal.

• However, at the same time it was ridiculed, as it would invade upon a net surfer’s privacy and
would not be economically viable.

Finally, this suggestion was dropped by the IT Ministry in its final draft. The Union Cabinet approved
the bill on May 13, 2000 and on May 17, 2000, both the houses of the Indian Parliament passed the
Information Technology Bill.

• The Bill received the assent of the President on 9th June 2000 and came to be known as the
Information Technology Act, 2000. The Act came into force on 17th October 2000.

• With the passage of time, as technology developed further and new methods of committing
crime using Internet & computers surfaced, the need was felt to amend the IT Act, 2000 to
insert new kinds of cyber offences and plug in other loopholes that posed hurdles in the
effective enforcement of the IT Act, 2000.
 • This led to the passage of the Information Technology (Amendment) Act, 2008 which was
made effective from 27 October 2009. The IT (Amendment) Act, 2008 has brought marked
changes in the IT Act, 2000 on several counts.

2. Cyber Laws in India

• Firstly, India has an extremely detailed and well-defined legal system in place.

• Numerous laws have been enacted and implemented and the foremost amongst them is The
Constitution of India.

• We have inter alia, amongst others, the Indian Penal Code,

• the Indian Evidence Act 1872,

• the Banker's Book Evidence Act, 1891 and

• the Reserve Bank of India Act, 1934,

• the Companies Act, and so on.

• However the arrival of the Internet signaled the beginning of the rise of new and complex legal
issues.

• It may be pertinent to mention that all the existing laws in place in India were enacted way back
keeping in mind the relevant political, social, economic, and cultural scenario of that relevant
time.

• Nobody then could really visualize about the Internet. Despite the brilliant acumen of our
master draftsmen, the requirements of cyberspace could hardly ever be anticipated.

• As such, the coming of the Internet led to the emergence of numerous ticklish legal issues and
problems which necessitated the enactment of Cyber laws.

• Secondly, the existing laws of India, even with the most benevolent and liberal
interpretation, could not be interpreted in the light of the emerging cyberspace, to include all
aspects relating to different activities in cyberspace.

• In fact, the practical experience and the wisdom of judgment found that it shall not be without
major perils and pitfalls, if the existing laws were to be interpreted in the scenario of emerging
cyberspace, without enacting new cyber laws. Hence, the need for enactment of relevant cyber
laws.

• Thirdly, none of the existing laws gave any legal validity or sanction to the activities in
Cyberspace. For example, the Net is used by a large majority of users for email.

• Yet till today, email is not "legal" in our country. There is no law in the country, which gives
legal validity, and sanction to email.
 • Courts and judiciary in our country have been reluctant to grant judicial recognition to the
legality of email in the absence of any specific law having been enacted by the Parliament. As
such the need has arisen for Cyber law.

• Fourthly, Internet requires an enabling and supportive legal infrastructure in tune with the
times.

• This legal infrastructure can only be given by the enactment of the relevant Cyber laws as the
traditional laws have failed to grant the same.

• E-commerce, the biggest future of Internet, can only be possible if necessary legal infrastructure
compliments the same to enable its vibrant growth.

• All these and other varied considerations created a conducive atmosphere for the need for
enacting relevant cyber laws in India.

3. Information Technology Act-2000

• Information Technology Act, 2000 is India’s mother legislation regulating the use of computers,
computer systems and computer networks as also data and information in the electronic format.

• This legislation has touched varied aspects pertaining to electronic authentication, digital
(electronic) signatures, cyber crimes and liability of network service providers.

• The Preamble to the Act states that it aims at providing legal recognition for transactions carried
out by means of electronic data interchange and other means of electronic communication,
commonly referred to as "electronic commerce", which involve the use of alternatives to paper-
based methods of communication and storage of information and aims at facilitating
electronic filing of documents with the Government agencies.

• This Act was amended by Information Technology Amendment Bill, 2008 which was passed

in Lok Sabha on 22nd December, 2008 and in Rajya Sabha on 23rd December, 2008.

• It received the assent of the President on 5th February 2009 and was notified with effect from
27/10/2009.

The IT Act of 2000 was developed to promote the

• IT industry,

• regulate ecommerce,

• facilitate e-governance and

• prevent cybercrime.

• The Act also sought to foster security practices within India that would serve the country in a
global context.
 • The Amendment was created to address issues that the original bill failed to cover and to
accommodate further development of IT and related security concerns since the original law
was passed.

• The IT Act, 2000 consists of 90 sections spread over 13 chapters [Sections 91, 92, 93 and 94 of
the principal Act were omitted by the Information Technology (Amendment) Act 2008 and has
2 schedules.[ Schedules III and IV were omitted by the Information Technology (Amendment)
Act 2008].

• Salient features of the Information Technology (Amendment) Act, 2008

i. The term 'digital signature' has been replaced with 'electronic signature' to make the Act more
technology neutral.

ii. A new section has been inserted to define 'communication device' to mean cell phones, personal
digital assistance or combination of both or any other device used to communicate, send or transmit
any text video, audio or image.

iii. A new section has been added to define cyber cafe as any facility from where the access to the
internet is offered by any person in the ordinary course of business to the members of the public.

iv. A new definition has been inserted for intermediary.

v. A new section has been inserted to the effect that contracts concluded electronically shall not be
deemed to be unenforceable solely on the ground that electronic form or means was used.

vi. The damages of Rs. One Crore prescribed under section 43 of the earlier Act of 2000 for damage to
computer, computer system etc. has been deleted and the relevant parts of the section have been
substituted by the words, 'he shall be liable to pay damages by way of compensation to the person
so affected'.

vii. A new section 43A has been inserted to protect sensitive personal data or information possessed,
dealt or handled by a body corporate in a computer resource which such body corporate owns, controls
or operates. If such body corporate is negligent in implementing and maintaining reasonable security
practices and procedures and thereby causes wrongful loss or wrongful gain to any person, it shall be
liable to pay damages by way of compensation to the person so affected.

viii. Sections 66A to 66F has been added to Section 66 prescribing punishment for offences such as
obscene electronic message transmissions, identity theft, cheating by impersonation using computer
resource, violation of privacy and cyber terrorism.

ix. Section 67 of the IT Act, 2000 has been amended to reduce the term of imprisonment for publishing
or transmitting obscene material in electronic form to three years from five years and increase the fine
thereof from Rs.100,000 to Rs. 500,000. Sections 67A to 67C have also been inserted.

While Sections 67A and B deals with penal provisions in respect of offences of publishing or
transmitting of material containing sexually explicit act and child pornography in electronic
form, Section 67C deals with the obligation of an intermediary to preserve and retain such information
as may be specified for such duration and in such manner and format as the central government may
prescribe.
x. In view of the increasing threat of terrorism in the country, the new amendments include an amended
section 69 giving power to the state to issue directions for interception or monitoring of decryption of
any information through any computer resource. Further, sections 69A and B, two new sections, grant
power to the state to issue directions for blocking for public access of any information through any
computer resource and to authorize to monitor and collect traffic data or information through any
computer resource for cyber security.

• Section 79 of the Act which exempted intermediaries has been modified to the effect that an
intermediary shall not be liable for any third party information data or communication link
made available or hosted by him if;

(a) The function of the intermediary is limited to providing access to a communication system over
which information made available by third parties is transmitted or temporarily stored or hosted;

(b) The intermediary does not initiate the transmission or select the receiver of the transmission and
select or modify the information contained in the transmission;

The IT Act, 2000 consists of 90 sections spread over 13 chapters [Sections 91, 92, 93 and 94 of the
principal Act were omitted by the Information Technology (Amendment) Act 2008 and has 2
schedules.[ Schedules III and IV were omitted by the Information Technology (Amendment) Act
2008].

• Salient features of the Information Technology (Amendment) Act, 2008

i. The term 'digital signature' has been replaced with 'electronic signature' to make the Act more
technology neutral.

ii . A new section has been inserted to define 'communication device' to mean cell phones, personal
digital assistance or combination of both or any other device used to communicate, send or transmit
any text video, audio or image.

iii. A new section has been added to define cyber cafe as any facility from where the access to the
internet is offered by any person in the ordinary course of business to the members of the public.

iv. A new definition has been inserted for intermediary.

v. A new section has been inserted to the effect that contracts concluded electronically shall not be
deemed to be unenforceable solely on the ground that electronic form or means was used.

vi. The damages of Rs. One Crore prescribed under section 43 of the earlier Act of 2000 for damage to
computer, computer system etc. has been deleted and the relevant parts of the section have been
substituted by the words, 'he shall be liable to pay damages by way of compensation to the person
so affected'.

vii. A new section 43A has been inserted to protect sensitive personal data or information possessed,
dealt or handled by a body corporate in a computer resource which such body corporate owns,
controls or operates.
viii. Sections 66A to 66F has been added to Section 66 prescribing punishment for offences such as
obscene electronic message transmissions, identity theft, cheating by impersonation using computer
resource, violation of privacy and cyber terrorism.

ix. Section 67 of the IT Act, 2000 has been amended to reduce the term of imprisonment for publishing
or transmitting obscene material in electronic form to three years from five years and increase the fine
thereof from Rs.100,000 to Rs. 500,000. Sections 67A to 67C have also been inserted.

• While Sections 67A and B deals with penal provisions in respect of offences of publishing or
transmitting of material containing sexually explicit act and child pornography in
electronic form, Section 67C deals with the obligation of an intermediary to preserve and retain
such information as may be specified for such duration and in such manner and format as the
central government may prescribe.

x. In view of the increasing threat of terrorism in the country, the new amendments include an amended
section 69 giving power to the state to issue directions for interception or monitoring of decryption
of any information through any computer resource. Further, sections 69A and B, two new sections,
grant power to the state to issue directions for blocking for public access of any information through
any computer resource and to authorize to monitor and collect traffic data or information through
any computer resource for cyber security.

xii. A proviso has been added to Section 81 which states that the provisions of the Act shall have
overriding effect. The proviso states that nothing contained in the Act shall restrict any person from
exercising any right conferred under the Copyright Act, 1957.

Rules notified under the Information Technology Act, 2000.

a) The Information Technology (Reasonable security practices and procedures and sensitive
personal data or information) Rules, 2011

b) The Information Technology (Electronic Service Delivery) Rules, 2011

c) The Information Technology (Intermediaries guidelines) Rules, 2011

d) The Information Technology (Guidelines for Cyber Cafe) Rules, 2011

e) The Cyber Appellate Tribunal (Salary, Allowances and other terms and conditions of service of
Chairperson and Members) Rules, 2009.

f) The Cyber Appellate Tribunal (Procedure for investigation of Misbehaviour or Incapacity of

Chairperson and Members) Rules, 2009.

g) The Information Technology (Procedure and Safeguards for Blocking for Access of Information
by Public), 2009.

h) The Information Technology (Procedure and Safeguards for interception, monitoring and
decryption of information) Rules, 2009.

i) The Information Technology (Procedure and Safeguard for Monitoring and Collecting Traffic
Data or Information) Rules, 2009.
j) The Information Technology (Use of electronic records and digital signatures) Rules, 2004.

k) The Information Technology (Security Procedure) Rules, 2004.

Scheme of the Act

• Chapter – I – Preliminary –

• Chapter – II – Digital Signature and Electronic Signature (Sections 3 & 3A)

• Chapter – III – Electronic Governance (Sections 4 to 10A) –

• Chapter IV – Attribution, Acknowledgement and Dispatch of Electronic Records (Sections

11 to 13)

• Chapter V – Secure electronic records and secure electronic signatures (Sections 14 to 16)

• Chapter VI – Regulation of Certifying Authorities (Sections 17 to 34)

• Chapter – VII – Electronic Signature Certificates (Sections 35 to 39)

• Chapter – VIII – Duties of Subscribers (Sections 40 to 42)

• Chapter – IX – Penalties, Compensation and Adjudication (Sections 43 to 47)

• Chapter X – The Cyber Appellate Tribunal (Sections 48 to 64)

• Chapter XI – Offences (Sections 65 to 78)

• Chapter XII – Intermediaries not to be liable in certain cases (Section 79)

• Chapter XIIA – Examiner of Electronic Evidence (Section 79A)

• Chapter XIII – Miscellaneous (Sections 80 to 90)

Important provisions of the Act

• Digital signature and Electronic signature

• Digital Signatures provide a viable solution for creating legally enforceable electronic
records

• Digital signatures enable the replacement of slow and expensive paper-based approval processes
with fast, low-cost, and fully digital ones.

• Instead of using pen and paper, a digital signature uses digital keys (public-key cryptography).

• Digital signature attaches the identity of the signer to the document and records a binding
commitment to the document.
 • However, unlike a handwritten signature, it is considered impossible to forge a digital signature
the way a written signature might be.

• In addition, the digital signature assures that any changes made to the data that has been signed
cannot go undetected.

Digital Signatures provide the following three features:-

• Authentication - Digital signatures are used to authenticate the source of messages. The
ownership of a digital signature key is bound to a specific user and thus a valid signature shows
that the message was sent by that user.

• Integrity - In many scenarios, the sender and receiver of a message need assurance that the
message has not been altered during transmission. Digital Signatures provide this feature by
using cryptographic message digest functions.

• Non Repudiation – Digital signatures ensure that the sender who has signed the information
cannot at a later time deny having signed it.

Digital Signature under the IT Act, 2000

• Section 3 deals with the conditions subject to which an electronic record may be authenticated
by means of affixing digital signature which is created in two definite steps.

First, the electronic record is converted into a message digest by using a mathematical function
known as ‘Hash function’ which digitally freezes the electronic record thus ensuring the integrity of
the content of the intended communication contained in the electronic record.

• Any tampering with the contents of the electronic record will immediately invalidate the digital
signature.

Secondly, the identity of the person affixing the digital signature is authenticated through the use of
a private key which attaches itself to the message digest and which can be verified by anybody
who has the public key corresponding to such private key.

• This will enable anybody to verify whether the electronic record is retained intact or has been
tampered with since it was so fixed with the digital signature.

• It will also enable a person who has a public key to identify the originator of the message.

• ‘Hash function’ means an algorithm mapping or translation of one sequence of bits into another,
generally smaller, set known as "Hash Result" such that an electronic record yields the same
hash result every time the algorithm is executed with the same electronic record

• as its input making it computationally infeasible to derive or reconstruct the original electronic
record from the hash result produced by the algorithm; that two electronic records can produce
the same hash result using the algorithm.
Certifying Authorities

• A Certifying Authority is a trusted body whose central responsibility is to issue, revoke, renew
and provide directories of Digital Certificates.

• Certifying Authority means a person who has been granted a license to issue an Electronic
Signature Certificate under section 24.

• Provisions with regard to Certifying Authorities are covered under Chapter VI i.e. Sec.17 to
Sec.34 of the IT Act, 2000.

• It contains detailed provisions relating to the appointment and powers of the Controller and
Certifying Authorities.

Controller of Certifying Authorities (CCA)

• The IT Act provides for the Controller of Certifying Authorities (CCA) to license and regulate
the working of Certifying Authorities.

• The Certifying Authorities (CAs) issue digital signature certificates for electronic authentication
of users.

• The CCA certifies the public keys of CAs using its own private key, which enables users in the
cyberspace to verify that a given certificate is issued by a licensed CA.

• For this purpose it operates, the Root Certifying Authority of India (RCAI). The CCA also
maintains the National Repository of Digital Certificates (NRDC), which contains all the
certificates issued by all the CAs in the country.

Appointment of Controller and other officers.

 (1) The Central Government may, by notification in the Official Gazette, appoint a Controller of
Certifying Authorities for the purposes of this Act and may also by the same or subsequent
notification appoint such number of Deputy Controllers and Assistant Controllers as it
deems fit.

(2) The Controller shall discharge his functions under this Act subject to the general control
and directions of the Central Government.

(3) The Deputy Controllers and Assistant Controllers shall perform the functions assigned to
them by the Controller under the general superintendence and control of the Controller.

(4) The qualifications, experience and terms and conditions of service of Controller, Deputy
Controllers and Assistant Controllers shall be such as may be prescribed by the Central
Government.

(5) The Head Office and Branch Office of the office of the Controller shall be at such places as the
Central Government may specify, and these may be established at such places as the Central
Government may think fit.

(6) There shall be a seal of the Office of the Controller.

The functions of the Controller are –

(a) to exercise supervision over the activities of the Certifying Authorities;

(b) certify public keys of the Certifying Authorities;

(c) lay down the standards to be maintained by the Certifying Authorities;

(d) specify the qualifications and experience which employees of the Certifying Authorities should possess;

(e) specify the conditions subject to which the Certifying Authorities shall conduct their business;

(f) specify the content of written, printed or visual material and advertisements that may be distributed or
used in respect of a Electronic Signature Certificate and the Public Key;

(g) specify the form and content of a Electronic Signature Certificate and the key;

(h) specify the form and manner in which accounts shall be maintained by the Certifying
Authorities;

(i) specify the terms and conditions subject to which auditors may be appointed and the
remuneration to be paid to them;

(j) facilitate the establishment of any electronic system by a Certifying Authority either solely or
jointly with other Certifying Authorities and regulation of such systems;

(k) specify the manner in which the Certifying Authorities shall conduct their dealings with the
subscribers;

(l) resolve any conflict of interests between the Certifying Authorities and the subscribers;

(m) lay down the duties of the Certifying Authorities;

(n) maintain a data-base containing the disclosure record of every Certifying Authority containing
such particulars as may be specified by regulations, which shall be accessible to the public.

a. To recognise the foreign certifying authority (Sec. 19).

The controller, with the prior permission of the Central Government and by notification in the
Official Gazette, may recognise any foreign certifying authority for the purpose of this Act [Sec.
19(1)].

The controller may revoke such recognition by notification in the Official Gazette for reasons to be
recorded in writing [Sec. 19(3)].

b. To grant license to CAs to issue electronic signature certificate (Sec. 21).

The controller can grant a license to any person to issue electronic signature certificate provided he
applies and fulfils such requirements with respect to

Qualification,
Expertise,
Manpower,
Financial Resources and
Other Infrastructure Facilities which are necessary for the issue of Electronic Signature Certificate
[Sec. 21(1) and (2)].
The controller may after considering the documents and such other factors, as he deems fit, grant the
licence or reject the application.

He may reject only after the applicant has been given a reasonable opportunity of presenting his case
(Sec. 24).

c. A firm having capital subscribed by all partners of not less than 5 crore and net worth of not less
than 50 crore ; However, the firm, in which the capital held in aggregate by any non-resident Indian
and foreign national, exceeds 49% of its capital, shall not be eligible for grant of licence ;

d. Central Government or a State Government or any of the Ministries or Departments, Agencies or

Authorities of such Governments.

Certifying Authorities (CAs) are responsible for issuing Digital Signature Certificates to the end
users. In order to facilitate greater flexibility to Certifying Authorities, the CCA has allowed the
creation of sub-CAs. As per this model, a Certifying Authority can create a sub-CA to meet its business
branding requirement.

However the sub-CA will be part of the same legal entity as the CA. The sub-CA model will be based
on the following principles:

i. The CAs must not have more than one level of sub-CA.

ii. A sub-CA certificate issued by the CA is used for issuing end entity certificates.
 iii. A CA with sub-CA must necessarily issue end entity certificates only through its sub-CA. The
only exception will be for code signing and time stamping certificates, which may directly be
issued by the CA.

The licensed Certifying Authorities (CAs) are

i. Safescrypt – a private Certifying Authority

ii. NIC – an organisation of Govt. of India, issuing certificates to Government organizations

iii. IDRBT – established by Reserve Bank of India for issuing certificates to the banking industry

iv. TCS – private certifying authority to issue certificates to individuals, company and
government users

v. MTNL

vi. Customs and Central Excise

vii. (n)Code Solutions CA (GNFC)

viii. e-Mudhra

Who can become a Certifying Authority?

The following persons can apply for grant of a licence to issue Digital Signature Certificates, namely:-

(a) an individual, being a citizen of India and having a capital of five crores of rupees or more in his
business or profession;

(b) a company having– (i) paid up capital of not less than five crores of rupees; and
(ii) net worth of not less than fifty crores of rupees:
(c) a firm having – (i) capital subscribed by all partners of not less than five crores of rupees; and
(ii) net worth of not less than fifty crores of rupees.

(d) Central Government or a State Government or any of the Ministries or Departments, Agencies or
Authorities of such Government

Every application for a licensed Certifying Authority should be made to the Controller in the form
given in Schedule I of the Information Technology (Certifying Authorities) Rules, 2000.

Rule 10 of IT (Certifying Authorities) Rules, 2000 prescribes the following documents to be

submitted along with the application –

(a) a Certification Practice Statement (CPS);

(b) a statement including the procedures with respect to identification of the applicant;
(c) a statement for the purpose and scope of anticipated Digital Signature Certificate technology,
management, or operations to be outsourced;

(d) certified copies of the business registration documents of Certifying Authority that intends to be
licensed;

(e) a description of any event, particularly current or past insolvency, that could materially affect
the applicant's ability to act as a Certifying Authority;

(f) an undertaking by the applicant that to its best knowledge and belief it can and will comply
with the requirements of its Certification Practice Statement;

(g) an undertaking that the Certifying Authority's operation would not commence until its operation and
facilities associated with the functions of generation, issue and management of Digital Signature
Certificate are audited by the auditors and approved by the Controller in accordance with rule 20;

(h) an undertaking to submit a performance bond or banker's guarantee in accordance with sub-
rule (2) of rule 8 within one month of Controller indicating his approval for the grant of licence to
operate as a Certifying Authority;

(i) any other information required by the Controller.

Security Guidelines for Certifying Authorities

The Certifying Authorities will have the sole responsibility of

• Integrity,

• Confidentiality and

• Protection of Information and Information Assets Employed in its

• operation,

• considering classification,

• declassification,

• labeling,

• storage, access and destruction of information assets

according to their value, sensitivity and importance of operation.

Commencement of Operation by Licensed Certifying Authorities

The licensed Certifying Authority can commence its commercial operation of generation and issue of
Digital Signature only after-

(a) it has confirmed to the Controller the adoption of Certification Practice Statement;
(b) it has generated its key pair, namely, private and corresponding public key, and submitted the
public key to the Controller;

(c) the installed facilities and infrastructure associated with all functions of generation, issue and
management of Digital Signature Certificate have been audited by the accredited auditor;

(d) it has submitted the arrangement for cross certification with other licensed Certifying
Authorities within India to the Controller.

Procedures to be followed by Certifying Authorities

• Every Certifying Authority should –

(a) make use of hardware, software, and procedures that are secure from intrusion and misuse:

(b) provide a reasonable level of reliability in its services which are reasonably suited to the
performance of intended functions;

(c) adhere to security procedures to ensure that the secrecy and privacy of the Electronic Signature
are assured;

(d) be the repository of all Electronic Signature Certificates issued under the IT Act;

(e) publish information regarding its practices, Electronic Signature Certificates and current status
of such certificates; and

(f) observe such other standards as may be specified by regulations.

Audit of Certifying Authority

According to Rule 31 of the IT (Certifying Authorities) Rules, 2000, the Certifying Authority should
get its operations audited annually by an auditor and such audit should include

(i) security policy and planning;

(ii) physical security;

(iii) technology evaluation;

(iv) Certifying Authority's services administration;

(v) relevant Certification Practice Statement;

(vi) compliance to relevant Certification Practice Statement;

(vii) contracts/agreements;

(viii) regulations prescribed by the Controller;

(ix) policy requirements of Certifying Authorities Rules, 2000

 1. Information Technology ( Certifying Authorities) Regulation-2001
Terms and conditions of licence to issue Digital Signature Certificate. -Every licence to issue Digital
Signature Certificates shall be granted under the Act subject to the following terms and conditions,
namely

i. General

ii. Overall Management and Obligation

iii. Certificate and Key Management

iv. Systems and Operations

v. Physical, procedural and personnel security

vi. Financial

vii. Compliance Audits

i. General
(a) The licence shall be valid for a period of five years from the date of issue.

(b) The licence shall not be transferable or heritable;

(c) The Controller can revoke or suspend the licence in accordance with the provision of the Act.

(d) The Certifying Authority shall be bound to comply with all the parameters against which it was
audited prior to issue of licence and shall consistently and continuously comply with those parameters
during the period for which the licence shall remain valid.

(e) The Certifying Authority shall subject itself to periodic audits to ensure that all conditions of the
licence are consistently complied with by it.

(f) The Certifying Authority must maintain secure and reliable records and logs for activities that
are core to its operations.

(g) Public Key Certificates and Certificate Revocation Lists must be archived for a minimum period
of seven years to enable verification of past transactions.

(h) The Certifying Authority shall provide Time Stamping Service for its subscribers. Error of the
Time Stamping clock shall not be more than 1 in 10.

(i) The Certifying Authority shall use methods, which are approved by the Controller, to verify the
identity of a subscriber before issuing or renewing any Public Key Certificate.

(j) The Certifying Authority shall publish a notice of suspension or revocation of any certificate in the
Certificate Revocation List in its repository immediately after receiving an authorised request of
such suspension or revocation.
(k) The Certifying Authority shall always assure the confidentiality of subscriber information.

(l) All changes in Certificate Policy and certification practice statement shall be published on the
web site of the Certifying Authority and brought to the notice of the Controller well in advance of
such publication.

(m) The Certifying Authority shall comply with every order or direction issued by the Controller
within the stipulated period.

ii. Overall Management and Obligation

(a) The Certifying Authority shall manage its functions in accordance with the levels of integrity and
security approved by the Controller from time to time.

(b) The Certifying Authority shall disclose information on the assurance levels of the certificates
that it issues and the limitations of its liabilities to each of its subscribers and relying parties.

(c) The Certifying Authority shall as approved, in respect of security and risk management controls
continuously ensure that security policies and safeguards are in place.

iii. Certificate and Key Management

(a) To ensure the integrity of its digital certificates, the Certifying Authority shall ensure the use of
approved security controls in the certificate management processes, i.e., certificate registration,
generation, issuance, publication, renewal, suspension, revocation and archival.

(b) The method of verification of the identity of the applicant of a Public Key Certificates shall be
commensurate with the level of assurance accorded to the certificate.

(c) The Certifying Authority shall ensure the continued accessibility and availability of its Public
Key Certificates and Certificate Revocation Lists in its repository to its subscribers and relying
parties.

(d) In the event of a compromise of the private key the Certifying Authority shall follow the
established procedures for immediate revocation of the affected subscribers' certificates.

(e) The Certifying Authority shall make available the information relating to certificates issued
and/or revoked by it to the Controller for inclusion in the National Repository.

(f) The private key of the Certifying Authority shall be adequately secured at each phase of its life
cycle, i.e., key generation, distribution, storage, usage, backup, archival and destruction.

(g) The private key of the Certifying Authority shall be stored in high security module in accordance
with FIPS 140-1 level 3 recommendations for Cryptographic Modules Validation List.

(h) Continued availability of the private key be ensured through approved backup measures in the
event of loss or corruption of its private key.

(i) All submissions of Public Key Certificates and Certificate Revocation Lists to the National
Repository of the Controller must ensure that subscribers and relying parties are able to access the
National Repository using LDAP ver 3 for X.500 Directories.
(j) The Certifying Authority shall ensure that the subscriber can verify the Certifying Authority's
Public Key Certificate, if he chooses to do so, by having access to the Public Key Certificate of the
Controller.

iv. Systems and Operations

(a) The Certifying Authority shall prepare detailed manuals for performing all its activities and
shall scrupulously adhere to them.

(b) Approved access and integrity controls such as intrusion detection, virus scanning, prevention of
denial-of service attacks and physical security measures shall be followed by the Certifying
Authority for all its systems that store and process the subscribers' information and certificates.

(c) The Certifying Authority shall maintain records of all activities and review them regularly to
detect any anomaly in the system.

v. Physical, procedural and personnel security

(a) The Certifying Authority shall prepare detailed manuals for performing all its activities and
shall scrupulously adhere to them.

(b) Approved access and integrity controls such as intrusion detection, virus scanning, prevention of
denial-of service attacks and physical security measures shall be followed by the Certifying
Authority for all its systems that store and process the subscribers' information and certificates.

(c) The Certifying Authority shall maintain records of all activities and review them regularly to
detect any anomaly in the system.

vi. Financial

(a) Every Certifying Authority shall get an independent periodic audit done through an approved
auditor.

(b) The Certifying Authority shall follow approved procedures to ensure that all the activities
referred to in (i) to (iv) in sub-regulation (a) are recorded properly and made available during audits.

vii. Compliance Audits

(a) The Certifying Authority shall subject itself to Compliance Audits that shall be carried out by
one of the empanelled Auditors duly authorized by the Controller for the purpose. Such audits shall
be based on the Internet Engineering Task Force document RFC 2527- Internet X.509 PKI
Certificate Policy and Certification Practices Framework.

(b) If a Digital Signature Certificate issued by the Certifying Authority is found to be fictitious or
that proper identification procedures have not been followed by the Certifying Authority while
issuing such certificate, the Certifying Authority shall be liable for any losses resulting out of this
lapse and shall be liable to pay compensation as decided by the Controller.
The standards followed by the Certifying Authority for carrying out its functions:

a. Every Certifying Authority shall observe the following standards for carrying out different activities
associated with its functions

(a) PKIX (Public Key Infrastructure) Public Key Infrastructure as recommended by Internet Engineering Task
Force (IETF) document draft-ietf-pkix-roadmap-05 for “Internet X.509 Public Key Infrastructure” (March 10,
2000);

(b) Public-key cryptography based on the emerging Institute of Electrical and Electronics Engineers (IEEE)
standard P1363 for three families: Discrete Logarithm (DL) systems
Elliptic Curve Discrete Logarithm (EC) systems
Integer Factorization (IF) systems;
(c) Public-key Cryptography Standards (PKCS)

PKCS#1 RSA Encryption Standard (512, 1024, 2048 bit)

PKCS#3 Diffie-Hellman Key Agreement Standard

PKCS#5 Password Based Encryption Standard

PKCS#6 Extended-Certificate Syntax Standard

PKCS#7 Cryptographic Message Syntax standard

PKCS#8 Private Key Information Syntax standard

PKCS#9 Selected Attribute Types PKCS#10 RSA Certification Request

PKCS#11 Cryptographic Token Interface Standard

PKCS#12 Portable format for storing/transporting a user’s private keys and certificates

PKCS#13 Elliptic Curve Cryptography Standard

PKCS#15 Cryptographic Token Information Format Standard;

(d) Federal Information Processing Standards (FIPS) FIPS 180-1, Secure Hash Standard FIPS 186-1, Digital
Signature Standard (DSS) FIPS 140-1 level 3, Security Requirement for Cryptographic Modules;

(e) Discrete Logarithm (DL) systems Diffie-Hellman, MQV key agreement DSA, Nyberg-Rueppel signatures;

(f) Elliptic Curve (EC) systems Elliptic curve analogs of DL systems;

(g) Integer Factorization (IF) systems RSA encryption RSA, Rabin-Williams signatures;

(h) Key agreement schemes

(i) Signature schemes DL/EC scheme with message recovery PSS, FDH, PKCS #1 encoding methods for IF
family PSS-R for message recovery in IF family;
 (ii) Encryption schemes Abdalla-Bellare-Rogaway DHAES for DL/EC family;

(i) Form and size of the key pairs

(1) The minimum key length for Asymmetric cryptosystem (RSA Algorithm) shall be 2048 for the Certifying
Authority’s key pairs and 1024 for the key pairs used by subscribers.

(2) The Certifying Authority’s key pairs shall be changed every three to five years (except during exigencies as in
the case of key compromise when the key shall be changed immediately). The Certifying Authority shall take
appropriate steps to ensure that key changeover procedures as mentioned in the approved Certificate Practice
Statements are adhered to.

(3) The subscriber’s key pairs shall be changed every one to two years;

(j) Directory Services (LDAP ver 3) X.500 for publication of Public Key Certificates and Certificate Revocation
Lists X.509 version 3 Certificates as specified in ITU RFC 1422 X.509 version 2 Certificate Revocation Lists;

(i) Publication of Public Key Certificate. The Certifying Authority shall, on acceptance of a Public Key Certificate
by a subscriber, publish it on its web site for access by the subscribers and relying parties. The Certifying
Authority shall be responsible and shall ensure the transmission of Public Key Certificates and Certificate
Revocation Lists to the National Repository of the Controller, for access by subscribers and relying parties. The
National Repository shall conform to X.500 Directory Services and provide for access through

LDAP Ver 3. The Certifying Authority shall be responsible for ensuring that Public Key Certificates and
Certificate Revocation Lists integrate seamlessly with the National Repository on their transmission;

k) Public Key Certificate Standard All Public Key Certificates issued by the Certifying Authorities shall conform to
International Telecommunication Union X.509 version 3 standard.

(i) Certificate TBSCertificate is certificate “to be signed”. The field contains the names of the subject and issuer,
a public key associated with the subject, a validity period, and other associated information. The fields are
described in detail.

(ii) Version This field describes the version of the encoded certificate. When extensions are used, as expected in
this profile, use X.509 version 3(value is 2). If no extensions are present, but a Unique Identifier is present, use
version 2 (value is 1). If only basic fields are present, use version 1 (the value is omitted from the certificate as
the default value).

(iii) Serial number The serial number is an integer assigned by the Certifying Authority to each certificate. It
shall be unique for each certificate issued by a given Certifying Authority (i.e., the issuer name and serial
number identify a unique certificate).

(iv) Signature This field contains the algorithm identifier for the algorithm used by the Certifying Authority to
sign the certificate

(v) Issuer The issuer field identifies the entity who has signed and issued the certificate. The issuer field shall
contain a non-empty distinguished name.

(vi) Validity The certificate validity period is the time interval during which the Certifying Authority warrants
that it will maintain information about the status of the certificate.
(vii) Subject The subject field identifies the entity associated with the public key stored in the subject public key
field. The subject name may be carried in the subject field and/or the subjectAltName extension. If the subject
is a Certifying Authority (e.g., the basic constraints extension, is present and the value of cA is TRUE,) then the
subject field shall be populated with a non-empty distinguished name matching the contents of the issuer field
in all certificates issued by the subject Certifying Authority.

(viii) Subject Public Key Information This field is used to carry the public key and identify the algorithm with
which the key is used.

(ix) Unique Identifiers These fields may only appear if the version is 2 or 3. The subject and issuer unique
identifiers are present in the certificate to handle the possibility of reuse of subject and/or issuer names over
time.

(x) Extensions This field may only appear if the version is 3. The extensions defined for X.509 v3 certificates
provide methods for associating additional attributes with users or public keys and for managing the
certification hierarchy. The X.509 v3 certificate format also allows communities to define private extensions to
carry information unique to those communities. If present, this field is a sequence of one or more certificate
extensions.

The content of certificate extensions in the Internet Public Key Infrastructure is defined as follows, namely:-.

(a) Authority Key Identifier The authority key identifier extension provides a means of identifying the public key
corresponding to the private key used to sign a certificate. This extension is used where an issuer has multiple
signing keys (either due to multiple concurrent key pairs or due to changeover). The identification may

be based on either the key identifier (the subject key identifier in the issuer’s certificate) or on the issuer name
and serial number.

(b) Subject Key Identifier The subject key identifier extension provides a means of identifying certificates that
contain a particular public key.

(c) Key Usage The key usage extension defines the purpose (e.g., encipherment, signature, certificate signing)
of the key contained in the certificate. The usage restriction might be employed when a key that could be used
for more than one operation is to be restricted. For example, when an RSA key should be used only for signing,
the digital Signature and/or non-Repudiation bits would be asserted. Likewise, when an RSA key should be used
only for key management, the key Encipherment bit would be asserted.

(d) Private Key Usage Period The private key usage period extension allows the certificate issuer to specify a
different validity period for the private key than the certificate. This extension is intended for use with digital
signature keys. This extension consists of two optional components, not Before and not After. (This profile
recommends against the use of this extension. Certifying Authorities conforming to this profile MUST NOT
generate certificates with critical private key usage period extensions.)

(e) Certificate Policies The certificate policies extension contains a sequence of one or more policy information
terms, each of which consists of an object identifier and optional qualifiers. These policy information terms
indicate the policy under which the certificate has been issued and the purposes for which the certificate may
be used. Optional qualifiers, which may be present, are not expected to change the definition of the policy.
(f) Policy Mappings This extension is used in Certifying Authority certificates. It lists one or more pairs of object
identifiers; each pair includes an issuer Domain Policy and a subject Domain Policy. The pairing indicates the
issuing Certifying Authority considers its issuer Domain Policy equivalent to the subject Certifying Authority’s
subject Domain Policy

(g) Subject Alternative Name The subject alternative names extension allows additional identities to be bound
to the subject of the certificate. Defined options include an Internet electronic mail address, a Directory
Naming Service name, an IP address, and a uniform resource identifier (URI).

(h) Issuer Alternative Names This extension is used to associate Internet style identities with the certificate
issuer.

(i) Subject Directory Attributes The subject directory attributes extension is not recommended as an essential
part of this profile, but it may be used in local environments.

(j) Basic Constraints The basic constraints extension identifies whether the subject of the certificate is a
Certifying Authority and how deep a certification path may exist through that Certifying Authority.

(k) Name Constraints The name constraints extension, which MUST be used only in a Certifying Authority
certificate, indicates a name space within which all subject names in subsequent certificates in a certification
path shall be located. Restrictions may apply to the subject distinguished name or subject alternative names.
Restrictions apply only when the specified name form is present. If no name of the type is in the certificate, the
certificate is acceptable.

(l) Policy Constraints The policy constraints extension can be used in certificates issued to Certifying Authorities.
The policy constraints extension constrains path validation in two ways. It can be used to prohibit policy
mapping or require that each certificate in a path contain an acceptable policy identifier.

(m) Extended key usage field This field indicates one or more purposes for which the certified public key may
be used, in addition to or in place of the basic purposes indicated in the key usage extension field.

(n) CRL Distribution Points The CRL distribution points extension identifies how CRL information is obtained.

(o) Private Internet Extensions This extension may be used to direct applications to identify an on-line
validation service supporting the issuing Certifying Authority.

(p) Authority Information Access The authority information access extension indicates how to access Certifying
Authority information and services for the issuer of the certificate in which the extension appears. Information
and services may include on-line validation services and Certifying Authority policy data.

(xi) Signature Algorithm The Signature Algorithm field contains the identifier for the cryptographic algorithm
used by the Certifying Authority to sign this certificate. The algorithm identifier is used to identify a
cryptographic algorithm.

(xii) Signature Value The Signature Value field contains a digital signature computed upon the Abstract Syntax
Notation (ASN.1) DER encoded tbsCertificate. The ASN.1 DER encoded tbsCertificate is used as the input to the
signature function. This signature value is then ASN.1 encoded as a BIT STRING and included in the Certificate’s
signature field.