mtnlTrustLine Certificate Policy

mtnlTrustLine Certificate Policy

Document Version:	1.0
Date:	September 15, 2003
Owner:	Ms. Vandana Gupta, DGM CA
Document ID:	MTNL-TL/POL/1.0/104
File Name:	MTNL-CP.doc

Custodian:	Mr. Bharat Kumar, AGM (S&A)
Prepared by:	Ms. Vandana Gupta, DGM CA
Reviewed by:	Mr. Sanjay Padmane, DGM CA
Approved by:	Mr. A. K. Bhargava, GM IT
Effective Date:	28^th January, 2004

Legal Notice

Unauthorized access to and use of this document is prohibited by law. Any individual attempting unauthorized access, copying, distributing, or exploiting information within this document will be subjected to legal prosecution. The mtnlTrustLine operations, including the policies and procedures, the terms and conditions, shall be governed by relevant Indian Laws in force.

Document Control Matrix

Sr. No.	Version	Date	Prepared by	Reviewed by	Approved by
1	1.0	15/09/2003	Ms.Vandana Gupta DGM CA	Mr. Sanjay Padmane DGM CA	Mr. A K Bhargava GM IT

mtnlTrustLine Certificate Policy (CP)

Version -1.0

Effective Date: August 15, 2003

Mahanagar Telephone Nigam Limited

Jeevan Bharati, 124 Connaught Circus, New Delhi – 110 001

Status Of This Document

Document Status: þDraft þReviewed þApproved (MTNL) oApproved by CCA
Lifecycle stage	Approved By	Date	Signature
Draft submitted to mtnlTrustLine Policy and Procedures Steering Committee for Review	GM (IT) MTNL
CP Reviewed by mtnlTrustLine Policy and Procedures Steering Committee	Policy Coordinator mtnlTrustLine Policy and Procedures Steering Committee, MTNL
Approved and Authorized by MTNL CMD	CMD MTNL
Approved by CCA
Effective Date: August 15, 2003.

Note

The Capitalized and Underlined terms in this CP are defined terms with specific meanings. Please see ‘List of Terms’ (CP § 9) for a list of definitions.

This Certificate Policy document assumes that the reader is generally familiar with Public Key Infrastructure (PKI), Digital Certificates, Digital Signatures, Indian IT-Act 2000, Encryption, and the mtnlTrustLine PKI. If not, mtnlTrustLine advises that the reader obtain some training in the use of Public Key Cryptography and Public Key Infrastructure as implemented in the mtnlTrustLine PKI. General educational and training information is accessible from mtnlTrustLine at http://www.mtnltrustline.com/faq. Also, a brief summary of the roles of the different mtnlTrustLine PKI participants is set forth in CP § 1.3.

This latest version of this CP is available for viewing in electronic form within the mtnlTrustLine Repository at https://www.mtnltrustline.com/repository/cp.

Updates to the CP are posted in the updates section of the mtnlTrustLine Repository, at https://www.mtnltrustline.com/repository/updates.

Table Of Contents

1 Introduction.......................................................................................... 1

1.1 Overview........................................................................................... 2

1.1.1 Compliance with IT-Act................................................................... 2

1.1.2 Role of the CP and Other Documents................................................. 2

1.1.3 Relationship with Controller of Certifying Authority............................... 4

1.1.4 Policy Overview............................................................................. 4

1.1.4.1 Class 1 Certificates....................................................................................... 4

1.1.4.2 Class 2 Certificates....................................................................................... 5

1.1.4.3 Class 3 Certificates....................................................................................... 5

1.1.4.4 Test Certificates........................................................................................... 6

1.2 Identification.................................................................................... 6

1.3 Community and Applicability................................................................. 7

1.3.1 Certifying Authorities (CAs).............................................................. 7

1.3.2 Registration Authorities (RAs)........................................................... 8

1.3.3 End Entities................................................................................... 8

1.3.3.1 Subscribers................................................................................................... 8

1.3.3.2 Relying Parties.............................................................................................. 8

1.3.4 Applicability................................................................................... 9

1.3.4.1 Suitable Applications.................................................................................... 9

1.3.4.1.1 Suitable Applications for Class 1 Certificates......................................... 9

1.3.4.1.2 Suitable Applications for Class 2 Certificates....................................... 10

1.3.4.1.3 Suitable Applications for Class 3 Certificates....................................... 11

1.3.4.2 Restricted Applications............................................................................... 11

1.3.4.3 Prohibited Applications............................................................................... 12

1.4 Contact Details................................................................................ 12

2 General Provisions............................................................................... 13

2.1 Obligations...................................................................................... 13

2.1.1 CA Obligations.............................................................................. 13

2.1.2 RA Obligations.............................................................................. 14

2.1.3 Subscriber Obligations................................................................... 14

2.1.4 Relying Party Obligations................................................................ 15

2.1.5 Repository Obligations................................................................... 16

2.2 Liability........................................................................................... 16

2.2.1 CA Liability.................................................................................. 16

2.2.1.1 Warranties to Subscribers and Relying Parties........................................... 16

2.2.1.2 Disclaimers of Warranties........................................................................... 17

2.2.1.3 Limitations of Liability................................................................................. 17

2.2.1.4 Force Majeure............................................................................................. 18

2.2.2 RA Liability................................................................................... 18

2.2.3 Subscriber Liability........................................................................ 18

2.2.3.1 Subscriber Warranties................................................................................ 18

2.2.3.2 Private Key Compromise............................................................................. 19

2.2.4 Relying Party Liability..................................................................... 19

2.3 Financial Responsibility..................................................................... 19

2.3.1 Indemnification by Subscribers and Relying Parties.............................. 19

2.3.1.1 Indemnification by Subscribers................................................................... 19

2.3.1.2 Indemnification by Relying Parties.............................................................. 20

2.3.2 Fiduciary Relationships................................................................... 20

2.3.3 Administrative Processes............................................................... 20

2.4 Interpretation and Enforcement.......................................................... 21

2.4.1 Governing Law............................................................................. 21

2.4.2 Severability, Survival, Merger, Notice............................................... 21

2.4.3 Dispute Resolution Procedures......................................................... 21

2.4.3.1 Role of the CCA.......................................................................................... 21

2.5 Fees................................................................................................ 21

2.5.1 Certificate Issuance or Renewal Fees............................................... 21

2.5.2 Certificate Access Fees................................................................. 22

2.5.3 Revocation or Status Information Access Fees................................... 22

2.5.4 Fees for Other Services Such as Policy Information............................ 22

2.5.5 Refund Policy............................................................................... 22

2.6 Publication and Repositories.............................................................. 22

2.6.1 Publication of CA Information.......................................................... 22

2.6.2 Frequency of Publication................................................................ 23

2.6.3 Access Controls........................................................................... 23

2.6.4 Repositories................................................................................. 23

2.7 Compliance Audit............................................................................... 23

2.7.1 Frequency of Compliance Audit....................................................... 23

2.7.2 Identity/ Qualifications of Auditor.................................................... 24

2.7.2.1 Self-Audits................................................................................ 24

2.7.3 Auditor’s Relationship to Audited Party.............................................. 24

2.7.4 Topics covered by audit................................................................ 24

2.7.5 Actions Taken as a Result of Deficiency............................................ 25

2.7.6 Communications of Results............................................................. 25

2.8 Confidentiality Policy........................................................................ 25

2.8.1 Types of Information to be Kept Confidential..................................... 26

2.8.2 Types of Information Not Considered Confidential............................... 26

2.8.3 Disclosure of Certificate Revocation/Suspension Information................. 26

2.8.4 Release to Law Enforcement Officials............................................... 26

2.8.5 Release as part of Civil Discovery.................................................... 27

2.8.6 Disclosure Upon Owner’s Request.................................................... 27

2.8.7 Other Information Release Circumstances......................................... 27

2.9 Intellectual Property Rights............................................................... 27

2.9.1 Rights in Certificates..................................................................... 27

2.9.2 Rights in the CP & CPS................................................................... 27

2.9.3 Rights in Names........................................................................... 28

2.9.4 Rights in Keys and Key Material....................................................... 28

3 Identification And Authentication........................................................ 29

3.1 Initial Registration........................................................................... 29

3.1.1 Types of Names........................................................................... 29

3.1.2 Meaning of Names........................................................................ 29

3.1.3 Rules for Interpreting Various Name Forms....................................... 30

3.1.4 Uniqueness of Names.................................................................... 30

3.1.5 Name Claim Dispute Resolution........................................................ 30

3.1.6 Recognition, Authentication, and Role of Trademarks.......................... 30

3.1.7 Method to Prove Possession of Private Key........................................ 31

3.1.8 Authentication of Organization Identity............................................. 31

3.1.8.1 Authentication of Organization Identity...................................................... 31

3.1.8.2 Class 2 Certificates for Devices.................................................................. 31

3.1.8.3 Class 3 Server Certificates......................................................................... 32

3.1.8.4 Authentication of the Identity of Sub-CAs and RAs..................................... 32

3.1.9 Authentication of Individual Identity................................................. 32

3.1.9.1 Class 1 Certificates..................................................................................... 33

3.1.9.2 Class 2 Certificates..................................................................................... 33

3.1.9.3 Class 3 Certificates..................................................................................... 34

3.2 Routine Rekey (Renewal)...................................................................... 34

3.2.1 Renewal of End User Subscriber Certificates...................................... 34

3.2.2 Renewal of Sub-CA Certificates....................................................... 35

3.3 Rekey After Revocation - No Key Compromise.......................................... 35

3.4 Revocation Requests.......................................................................... 36

4 Operational Requirements..................................................................... 37

4.1 Certificate Application...................................................................... 37

4.1.1 Enrollment for End User Subscriber Certificates................................. 37

4.1.2 Enrollment for Sub-CA or RA Certificates........................................... 37

4.2 Certificate Issuance.......................................................................... 38

4.2.1 Issuance of End User Subscriber Certificates..................................... 38

4.2.2 Issuance of Sub-CA and RA Certificates............................................ 38

4.3 Certificate Acceptance...................................................................... 39

4.4 Certificate Suspension and Revocation................................................ 39

4.4.1 Circumstances for Revocation........................................................ 39

4.4.1.1 Circumstances for Revoking End User Subscriber Certificates.................... 39

4.4.1.2 Circumstances for Revoking Sub-CA or RA Certificates............................... 40

4.4.2 Who Can Request Revocation.......................................................... 41

4.4.2.1 Who Can Request Revocation of an End User Subscriber Certificate......... 41

4.4.2.2 Who Can Request Revocation of a Sub-CA or RA Certificate...................... 41

4.4.3 Procedure for Revocation Request................................................... 41

4.4.3.1 Procedure for Revocation Request of an End User Subscriber Certificate... 41

4.4.3.2 Procedure for Revocation Request of a Sub-CA or RA Certificate................ 42

4.4.4 Revocation Request Grace Period..................................................... 42

4.4.5 Circumstances for Suspension........................................................ 42

4.4.6 Who Can Request Suspension.......................................................... 42

4.4.7 Procedure for Suspension Request................................................... 42

4.4.8 Limits on Suspension Period............................................................ 43

4.4.9 CRL Issuance Frequency................................................................ 43

4.4.10 Certificate Revocation List Checking Requirements............................ 43

4.4.11 On-Line Revocation/Status Checking Availability................................ 43

4.4.12 On-Line Revocation Checking Requirements..................................... 44

4.4.13 Other Forms of Revocation Advertisements Available......................... 44

4.4.14 Checking Requirements for Other Forms of Revocation Advertisements 44

4.4.15 Special Requirements Regarding Key Compromise............................. 44

4.5 Security Audit Procedures................................................................. 44

4.5.1 Types of Events Recorded.............................................................. 44

4.5.1.1 Events Recorded by mtnlTrustLine CA........................................................ 44

4.5.1.2 Events Recorded by mtnlTrustLine RAs....................................................... 46

4.5.2 Frequency with which audit logs are processed.................................. 47

4.5.3 Period for which audit logs are kept................................................. 47

4.5.4 Protection of Audit Log.................................................................. 47

4.5.5 Audit Log Backup Procedures.......................................................... 47

4.5.6 Audit Log Accumulation System (Internal or External)......................... 47

4.5.7 Notification to Event-Causing Subject............................................... 48

4.5.8 Vulnerability Assessments.............................................................. 48

4.6 Records Archival.............................................................................. 48

4.6.1 Types of Event Recorded............................................................... 48

4.6.2 Retention Period for Archive........................................................... 49

4.6.3 Protection of Archive..................................................................... 49

4.6.4 Archive Backup Procedures............................................................. 49

4.6.5 Requirements for Time-Stamping of Records..................................... 49

4.6.6 Archive Collection System (Internal or External)................................. 49

4.6.7 Procedures to Obtain and Verify Archive Information.......................... 50

4.7 Key Changeover................................................................................. 50

4.8 Compromise and Disaster Recovery...................................................... 50

4.8.1 Computing Resources, Software, and/or Data Are Corrupted................ 51

4.8.2 Entity Public Key is Revoked............................................................ 51

4.8.3 Entity Key is Compromised............................................................. 51

4.8.4 Secure Facility After a Natural or Other Type of Disaster..................... 51

4.9 CA Termination................................................................................. 52

5 Physical, Procedural, And Personnel Security Controls......................... 54

5.1 Physical Security Controls................................................................ 54

5.1.1 Site Location and Construction........................................................ 54

5.1.2 Physical Access............................................................................ 55

5.1.3 Power and Air Conditioning............................................................. 55

5.1.4 Water Exposures.......................................................................... 55

5.1.5 Fire Prevention and Protection........................................................ 56

5.1.6 Media Storage.............................................................................. 56

5.1.7 Waste Disposal............................................................................. 56

5.1.8 Off-Site Backup............................................................................ 56

5.2 Procedural Controls......................................................................... 57

5.2.1 Trusted Roles.............................................................................. 57

5.2.2 Number of Persons Required Per Task............................................... 58

5.2.3 Identification and Authentication for Each Role................................... 58

5.3 Personnel Security Controls.............................................................. 58

5.3.1 Background, Qualifications, Experience, and Clearance Requirements..... 58

5.3.2 Background Check Procedures........................................................ 58

5.3.3 Training Requirements and Training Procedures.................................. 59

5.3.4 Retraining Frequency and Requirements........................................... 60

5.3.5 Job Rotation Frequency and Sequence.............................................. 60

5.3.6 Sanctions for Unauthorized Actions.................................................. 60

5.3.7 Contracting Personnel Requirements................................................ 61

5.3.8 Documentation Supplied to Personnel............................................... 61

6 Technical Security Controls.................................................................. 62

6.1 Key Pair Generation and Installation.................................................... 62

6.1.1 Key Pair Generation and Installation................................................. 62

6.1.2 Private Key Delivery to Entity......................................................... 63

6.1.3 Public Key Delivery to Certificate Issuer............................................ 63

6.1.4 CA Public Key Delivery to Users....................................................... 63

6.1.5 Key Sizes.................................................................................... 64

6.1.6 Public Key Parameters Generation.................................................... 64

6.1.7 Parameter Quality Checking............................................................ 64

6.1.8 Hardware or Software Key Generation.............................................. 64

6.1.9 Key Usage Purposes...................................................................... 65

6.2 Private Key Protection....................................................................... 66

6.2.1 Standards for Cryptographic Modules............................................... 66

6.2.2 Private Key ‘n out of m’ Multi-Person Control..................................... 66

6.2.3 Private Key Escrow....................................................................... 67

6.2.4 Private Key Backup....................................................................... 67

6.2.5 Private Key Archival...................................................................... 67

6.2.6 Private Key Entry into Cryptographic Module..................................... 68

6.2.7 Method of Activating Private Key..................................................... 68

6.2.7.1 End User Subscriber Private Keys............................................................... 68

6.2.7.2 CA/Sub-CA Private Keys............................................................................. 69

6.2.8 Method of Deactivating Private Key.................................................. 69

6.2.9 Method of Destroying Private Key.................................................... 70

6.3 Other Aspects of Key Pair Management.................................................. 70

6.3.1 Public Key Archival........................................................................ 70

6.3.2 Usage Periods for the Public and Private Keys.................................... 70

6.4 Activation Data................................................................................ 71

6.4.1 Activation Data Generation and Installation....................................... 71

6.4.2 Activation Data Protection.............................................................. 72

6.4.3 Other Aspects of Activation Data..................................................... 73

6.5 Computer Security Controls............................................................... 73

6.5.1 Specific Computer Security Technical Requirements........................... 73

6.5.2 Computer Security Rating.............................................................. 73

6.6 Life Cycle Security Controls............................................................... 74

6.6.1 System Development Controls........................................................ 74

6.6.2 Security Management Controls....................................................... 74

6.6.3 Life Cycle Security Ratings............................................................. 74

6.7 Network Security Controls................................................................ 74

6.8 Cryptographic Module Engineering Controls......................................... 75

7 Certificate And CRL Profiles................................................................. 76

7.1 Certificate Profile............................................................................ 76

7.1.1 Version Number(s) Supported......................................................... 77

7.1.2 Certificate Extensions.................................................................... 77

7.1.2.1 Basic Constraints........................................................................................ 78

7.1.2.2 Extended Key Usage.................................................................................. 78

7.1.3 Algorithm Object Identifiers............................................................ 79

7.1.4 Name Forms................................................................................ 79

7.1.5 Name Constraints......................................................................... 79

7.1.6 Certificate Policy Object Identifier................................................... 80

7.1.7 Usage of Policy Constraints Extension............................................... 80

7.1.8 Policy Qualifiers Syntax and Semantics............................................. 80

7.1.9 Processing Semantics for the Critical Certificate Policy Extension.......... 80

7.2 CRL Profile....................................................................................... 80

7.2.1 Version Number(s) Supported......................................................... 80

7.2.2 CRL and CRL Entry Extensions......................................................... 80

8 Specification Administration................................................................ 81

8.1 Specification Change Procedures........................................................ 81

8.1.1 Items that Can Change Without Notification...................................... 81

8.1.2 Items that Can Change with Notification........................................... 81

8.1.2.1 List of Items............................................................................................... 81

8.1.2.2 Notification Mechanism............................................................................... 82

8.1.2.3 Comment Period......................................................................................... 82

8.1.2.4 Mechanism to Handle Comments................................................................ 82

8.1.3 Changes Requiring Changes in the Certificate Policy OID...................... 82

8.2 Publication and Notification Procedures............................................. 83

8.3 CPS Approval Procedures................................................................... 83

9 List Of Terms........................................................................................ 84

9.1 List of Acronyms............................................................................... 84

9.2 Definitions....................................................................................... 85

1 Introduction

This document is the Certificate Policy (CP) of mtnlTrustLine, a service of Mahanagar Telephone Nigam Limited (MTNL). The CP is the principal statement of policy governing mtnlTrustLine.

The Indian Information Technology Act – 2000 (IT-Act 2000) provides 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, to facilitate electronic filing of documents.

To facilitate the authentication of electronic documents the IT-Act 2000 provides legal recognition[1] to Digital Signatures created using Digital Certificates issued by Certifying Authorities duly licensed by the ‘Controller of Certifying Authorities’.

mtnlTrustLine is a Public Key Infrastructure (PKI) established by Mahanagar Telephone Nigam Limited (MTNL) that provides Digital Certificates to entities including but not limited to Individuals, Organizations, Servers, Network Devices, and ‘legal persons’ within the framework of IT-Act 2000.

This CP establishes the business, legal, and technical requirements for approving, issuing, managing, using, revoking, and renewing Digital Certificates in accordance to the requirements of the IT-Act 2000.

mtnlTrustLine issues three Classes of Certificates: Class 1, Class 2, and Class 3. The CP describes how these three Classes correspond to three Classes of applications with common security requirements. The CP is a single document that defines three Certificate Policies, one for each of the Classes. The current version of the CP identifies the mtnlTrustLine Standards applicable to each ‘Class’.

1.1 Overview

The CP establishes requirements for the entire mtnlTrustLine community comprising of the mtnlTrustLine, Certifying Authorities (CAs), Subordinate Certifying Authorities (Sub-CAs), Registration Authorities (RAs), Subscribers, Relying Parties, and other such entities as may be associated with mtnlTrustLine.

1.1.1 Compliance with IT-Act

This CP shall always be interpreted in association with the IT-Act and any rules, regulations, and guidelines to the act gazetted by the Controller of Certifying Authorities from time to time.

1.1.2 Role of the CP and Other Documents

The CP describes at a general level the overall business, legal, and technical infrastructure of the mtnlTrustLine. More specifically, it describes, among other things:

● Appropriate applications for, and the assurance levels associated with, each Class of Certificate,

● Obligations of Certifying Authorities, Registration Authorities, Subscribers, and Relying Parties,

● Legal matters that must be covered in mtnlTrustLine Subscriber Agreement and Relying Party Agreement,

● Methods to confirm the identity of Certificate Applicants for each Class of Certificate,

● Operational procedures for Certificate Applications, Issuance, Acceptance, Revocation, and Renewal,

● Operational security procedures for audit logging, records retention, and disaster recovery,

The CP, however, is only the first in a set of documents relevant to the mtnlTrustLine. These other documents include:

● Security and operational policy documents and manuals that supplement the CP by providing more detailed requirements, such as:

» The mtnlTrustLine security policy and standards, which sets forth security principles governing the mtnlTrustLine infrastructure,

» The mtnlTrustLine operating procedures manual, which details the procedures for carrying out various activities related to the mtnlTrustLine infrastructure.

● mtnlTrustLine Certification Practice Statements. While the CP sets forth requirements, the CPS explains how mtnlTrustLine employs practices and procedures to meet these requirements.

● mtnlTrustLine Subscriber Agreement that binds the Subscribers of mtnlTrustLine Digital Certificates.

● mtnlTrustLine Relying Party Agreement that binds the mtnlTrustLine Relying Parties.

1.1.3 Relationship with Controller of Certifying Authority

The CCA has established the Root Certifying Authority of India (RCAI) under section 18(b) of the IT-Act to digitally sign the Public Keys of licensed CAs in India.

The mtnlTrustLine Public Key Infrastructure is designed to be subordinate to the RCAI. This is achieved by the RCAI issuing a digitally signed CA Certificate that authenticates the Public Key(s) of the mtnlTrustLine certifying authority. This CA Certificate can be downloaded from the CCA's website [http://www.cca.gov.in/] as well as mtnlTrustLine’s website [https://www.mtnltrustline.com/repository/ca/].

The CCA has also established the National Repository of Digital Certificates (NRDC) under section 20 of the IT-Act to act as a directory of all Certificates and CRLs issued by all the licensed CAs in India. mtnlTrustLine PKI Certificates and CRLs shall be published to the NRDC.

1.1.4 Policy Overview

In accordance to the guidelines of IT-Act, mtnlTrustLine offers three distinct Classes of Certificates, Class 1, Class 2, and Class 3.

Each Class of Certificate is associated with specific security features and corresponds to a specific level of trust. mtnlTrustLine Subscribers and Relying Parties choose which Classes of Certificates they need.

1.1.4.1 Class 1 Certificates

Class 1 Certificates are issued to Individuals with valid e-mail addresses. They assure that the Subscriber’s distinguished name (DN) is unique and unambiguous within mtnlTrustLine Repository and that the e-mail address in the DN is associated with the Public Key in the Certificate.

Class 1 Certificates are appropriate for Digital Signatures, encryption, and electronic access control for non-commercial transactions where proof of identity is not required.

1.1.4.2 Class 2 Certificates

Class 2 Certificates are issued to Individuals and Devices. They assure that the identity of the Subscriber based on information provided by the Subscriber in the Certificate Application does not conflict with the information in a mtnlTrustLine approved and well‑recognized business or consumer database(s) (Validating Database).

Class 2 Individual Certificates are appropriate for Digital Signatures, encryption, and electronic access control in transactions where proof of identity based on information in the Validating Database is sufficient.

Class 2 Device Certificates are appropriate for device authentication; message, software, and content integrity; and confidentiality encryption.

1.1.4.3 Class 3 Certificates

Class 3 Certificates are issued to Individuals, Organizations, Servers, Devices, and Administrators for CAs and RAs.

Class 3 Certificates issued to Individuals assure of the identity of the Subscriber based on the personal (physical) presence of the Subscriber before a mtnlTrustLine authorized person that confirms the identity of the Subscriber using a well-recognized form of government issued identification and one other identification credential.

Class 3 Certificates issued to Organizations assure of the identity of the Subscriber based on a confirmation that the Subscriber organization does in fact exist, that the organization has authorized the Certificate Application, and that the person submitting the Certificate Application on behalf of the Subscriber was authorized to do so.

Class 3 Individual Certificates are appropriate for Digital Signatures, encryption, and access control in transactions requiring a high assurance about the Subscriber’s identity.

Class 3 Server Certificates are appropriate for server authentication; message, software, and content integrity; and confidentiality encryption.

1.1.4.4 Test Certificates

In addition to the three Classes of Certificates described above, mtnlTrustLine also offers ‘Test’ certificates to its Subscribers.

These ‘Test’ certificates are solely intended for evaluating the technical implementation of mtnlTrustLine PKI and ascertaining the interoperability of mtnlTrustLine Certificates with various applications. ‘Test’ certificates shall not be used or relied upon for any other purposes.

mtnlTrustLine shall disclaim all warranties whatsoever with respect to ‘Test’ Certificates and also disclaim any assurances of the accuracy, authenticity, integrity, or reliability of information contained in ‘Test’ Certificates.

mtnlTrustLine shall require Subscribers and Users of ‘Test’ certificates to acknowledge that the identity of the Certificate Subject has not been authenticated for issuance of such ‘Test’ Certificates.

1.2 Identification

This document is the mtnlTrustLine Certificate Policy (CP) document and defines the Certificate Policies (CP) for mtnlTrustLine issued three Classes of Certificates – Class 1, Class 2, and Class 3. The object identifier (OID) values assigned to the mtnlTrustLine Certification Practice Statement (CPS) and Certificate Policy (CP) are:

mtnlTrustLine PKI Certificates contain object identifier (OID) values corresponding to the applicable class of certificate as indicated below:

1.3 Community and Applicability

This CP governs the mtnlTrustLine Public Key Infrastructure (PKI) that accommodates a large, public community of users with diverse needs for communications and information security. The participants in the mtnlTrustLine PKI are:

The term Certifying Authority is an umbrella term that refers to all entities issuing Certificates within the mtnlTrustLine PKI. The CA term encompasses two Sub‑categories of issuers: Certifying Authority (CA) and Subordinate Certifying Authority (Sub-CA).

The mtnlTrustLine CA is signed by the Root Certifying Authority of India (RCAI) and is at the top of the mtnlTrustLine PKI hierarchy. Subordinate to the mtnlTrustLine CA are Offline Subordinate Certifying Authorities (Offline Sub-CAs), one for each Class of Certificates. These Offline Sub-CAs issue Certificates to other Offline Sub-CAs or Online Sub-CAs. Online Sub-CAs issue Certificates to end entity Subscribers.

Sub-CAs also fall into two categories: mtnlTrustLine Sub-CAs and mtnlTrustLine Enterprise Customer Sub-CAs. mtnlTrustLine Sub-CAs are mtnlTrustLine entities whereas mtnlTrustLine Enterprise Customer Sub-CAs are entities owned by mtnlTrustLine Enterprise Customers.

1.3.2 Registration Authorities (RAs)

Registration Authorities (RAs) evaluate and approve or reject Certificate Applications in accordance with this CP and relevant CPS.

mtnlTrustLine PKI RAs fall into two categories: mtnlTrustLine RAs and mtnlTrustLine Enterprise Customer RAs. mtnlTrustLine RAs are mtnlTrustLine entities whereas mtnlTrustLine Enterprise Customer RAs are mtnlTrustLine Customer entities.

1.3.3 End Entities

1.3.3.1 Subscribers

Subscribers are end entities identified in the subject name of a Certificate issued by a mtnlTrustLine CA or Sub-CA. Subscribers hold the private key that corresponds to the Public Key listed in that Certificate.

In compliance with the requirements of the IT-Act this policy imposes a legal obligation upon the Subscriber to maintain the integrity of their private key(s).

1.3.3.2 Relying Parties

Relying Parties are entities that rely on a Certificate(s) issued by mtnlTrustLine in a manner consistent with this CP. A Relying Party is any entity using a mtnlTrustLine PKI Certificate for one or a combination of the following:

2. To verify a digital message was digitally signed by the Certificate Subscriber.

4. To authenticate the Certificate Subscriber in an online session based on proof of possession of the private key corresponding to the Public Key certified in the Digital Certificate.

1.3.4 Applicability

The CP applies to all participants in the mtnlTrustLine PKI - CAs, RAs, Subscribers, and Relying Parties. In general, Digital Certificates permit Subscribers to digitally sign electronic documents and permit Relying Parties to verify Digital Signatures.

The policies governing the use of each Class of Certificates in mtnlTrustLine PKI is described in the next sub-section (CP § 1.3.4.1). However, by contract and within specific environments (such as an intranet or an extranet), mtnlTrustLine PKI participants may use Certificates for higher security applications than the ones described here. Any such usage, however, shall be limited to such entities, and subject to CP § 1.3.4.2 and CP § 1.3.4.3, and these entities shall be solely responsible for any liability arising out of such usage.

The subsections within this section list suitable applications for each Class of mtnlTrustLine PKI Certificates. This listing, however, is not intended to be exhaustive.

In general, mtnlTrustLine PKI participants agree that where any transaction requires that information shall be authenticated by affixing the signature or any document shall be signed then such requirement shall be satisfied, if such information is authenticated by means of digital signature verifiable with reference to a suitable mtnlTrustLine PKI Certificate.

1.3.4.1.1 Suitable Applications for Class 1 Certificates

Class 1 Certificates are suitable for modestly enhancing the security of electronic communication through the use of Digital Signatures and encryption in transactions where proof of identity is not required.

A digital signature verifiable with reference to a mtnlTrustLine Class 1 Certificate cannot be used for authentication purposes or to support non-repudiation as Class 1 Certificates do not assure about the identity of the Subscriber. Rather, the digital signature function is appropriate for providing continuity and integrity assurance in a series of ongoing communications.

Where used for e-mail, the digital signature also provides modest assurances that the e‑mail originated from a sender with e-mail address mentioned in the subject Distinguished Name (DN) of the Certificate. The Certificate, however, provides no proof of who the sender(s) using that e‑mail address actually is.

The encryption application enables a Relying Party to use the Subscriber’s Certificate to encrypt messages to the Subscriber, although the sending Relying Party cannot be sure that the recipient is in fact the person named in the Certificate.

Class 1 Certificates can also be used for client authentication during online sessions. The web site or other device can use the Certificate to ensure, over a series of sessions, that the sessions are being initiated by the same Subscriber having a certain e‑mail address. Again, however, the Certificate provides no proof of who that Subscriber actually is.

1.3.4.1.2 Suitable Applications for Class 2 Certificates

Class 2 Certificates are suitable for moderately enhancing the security of electronic communication through the use of Digital Signatures and encryption in transactions where proof of identity of the Subscriber based on reliance on a mtnlTrustLine approved business or consumer database(s) (Validating Database) is sufficient.

Where used for e-mail, the digital signature permits the authentication of the identity of email correspondents, message integrity, and support for non-repudiation.

The encryption application enables a Relying Party to use the Subscriber’s Certificate to encrypt messages to the Subscriber.

Class 2 Certificates are also appropriate for client authentication during online sessions.

In addition, Class 2 Certificates are also appropriate for enhancing the security of networks and other communication media by authenticating the identity/ownership of Devices.

1.3.4.1.3 Suitable Applications for Class 3 Certificates

Class 3 Certificates are suitable for enhancing the security of electronic communication through the use of Digital Signatures and encryption in transactions where a high assurance proof of identity is required.

Where used for e-mail, the digital signature permits the authentication of the identity of email correspondents, message integrity, and support for non‑repudiation.

The encryption application enables a Relying Party to use the Subscriber’s Certificate to encrypt messages to the Subscriber.

Class 3 Certificates are also appropriate for both client as well as server authentication during online sessions.

In addition, Class 3 Certificates are also appropriate for use with applications like time‑stamping, OCSP, and software code signing.

1.3.4.2 Restricted Applications

mtnlTrustLine does not generally restrict the use of its PKI within any specific business environment.

With respect to X.509 version 3 Certificates, the key usage extension is intended to limit the technical purposes for which a private key corresponding to the Public Key in a Certificate may be used. In addition, End User Subscriber Certificates shall not be used as CA Certificates. This restriction is confirmed by the absence of a basic constraints extension. The effectiveness of extension-based limitations, however, is subject to the operation of software manufactured or controlled by entities other than mtnlTrustLine.

1.3.4.3 Prohibited Applications

mtnlTrustLine PKI Certificates are not designed, intended, or authorized for use or resale as control equipment in hazardous circumstances or for uses requiring fail-safe performance such as the operation of nuclear facilities, aircraft navigation or communication systems, air traffic control systems, or weapons control systems, where failure could lead directly to death, personal injury, or severe environmental damage. Also, subject to CP § 1.3.4.1.1, Class 1 Certificates shall not be used as proof of identity or for non‑repudiation.

1.4 Contact Details

The organization responsible for the administration including registration, maintenance, and interpretation of this CP is Mahanagar Telephone Nigam Limited, with its registered office at:

Address inquiries about the CP to cp@mtnltrustline.com or to the following address:

2 General Provisions

2.1 Obligations

2.1.1 CA Obligations

mtnlTrustLine CAs shall ensure that all requirements, as detailed in this document, are implemented as applicable and perform the specific obligations described throughout this CP.

mtnlTrustLine has the responsibility for conformance with this policy, IT-Act 2000, and other applicable laws of India, even when a part or whole of the CA functionality is undertaken by non mtnlTrustLine entities.

mtnlTrustLine shall make publicly available the Certification Practice Statement (CPS) describing the practices employed in issuing the Digital Certificates. All mtnlTrustLine certification services shall be consistent with its published CPS.

mtnlTrustLine shall maintain a Repository of all Certificates and CRLs in a X.500 compliant directory with LDAP access in accordance with the provisions of the IT-Act 2000.

mtnlTrustLine shall update the ‘National Repository of Digital Certificates’ (NRDC) about the Issuance, Revocation, or suspension of a Digital Certificate in the manner and format agreed with the ‘Controller of Certifying Authorities’ (CCA).

mtnlTrustLine shall use reasonable efforts to ensure that the Subscriber Agreement and Relying Party Agreement bind Subscribers and Relying Parties respectively. Examples of such efforts include, but are not limited to, requiring assent to Subscriber Agreement as a condition of enrollment or requiring assent to Relying Party Agreement as a condition of receiving Certificate status information. The Subscriber Agreement and Relying Party Agreement used by mtnlTrustLine shall include the provisions required by CP §§ 2.2, 2.3, 2.4.

mtnlTrustLine shall ensure appropriate technical and organizational measures are taken to prevent unauthorized or unlawful processing of personal data and accidental loss or destruction of, or damage to, personal data.

mtnlTrustLine must assure the users of its PKI that the information they provide is completely protected from disclosure unless with their agreement or by court order or other legal requirement.

mtnlTrustLine shall make adequate arrangements to cover liabilities arising from its operations and/or activities, in particular to bear the risk of liability for damages.

mtnlTrustLine shall ensure that organization concerned with Certificate generation and Revocation management shall be independent of other Organizations for its decisions relating to the establishing, provisioning and maintaining and suspending of services; in particular its senior executive, senior staff and staff in trusted roles, must be free from any commercial, financial and other pressures which might adversely influence trust in the services it provides. Specifically, mtnlTrustLine shall ensure that the organization concerned with Certificate generation and Revocation management shall have a documented structure which safeguards impartiality of operations.

2.1.2 RA Obligations

RAs assist mtnlTrustLine PKI CAs and Sub-CAs by performing validation functions, approving or rejecting Certificate Applications, requesting Revocation of Certificates, and approving Renewal requests. mtnlTrustLine PKI RAs shall perform the specific obligations appearing throughout this CP.

2.1.3 Subscriber Obligations

Certificate Applicants shall provide complete and accurate information on their Certificate Applications and shall manifest assent to the mtnlTrustLine Subscriber Agreement as a condition of obtaining a Certificate.

Subscribers shall perform Subscriber functions in accordance with the specific obligations appearing throughout this CP. Subscribers shall use their Certificates in accordance with CP § 1.3.4.

Subscribers shall protect their private keys in accordance with CP §§ 6.1, 6.2, 6.4.

If a Subscriber discovers or has reason to believe there has been a compromise of the Subscriber’s private key or the activation data protecting such private key, or the information within the Certificate is incorrect or has changed, the Subscriber shall promptly:

● Notify the entity that approved the Subscriber’s Certificate Application, either a mtnlTrustLine PKI CA/Sub-CA or an RA, in accordance with CP § 4.4.1.1 and request Revocation of the Certificate in accordance with CP §§ 3.4, 4.4.3.1, and

● Notify any person that may reasonably be expected by the Subscriber to rely on a digital signature verifiable with reference to the Subscriber’s Certificate.

Subscribers shall cease use of their private keys at the end of their key usage periods under CP § 6.3.2.

Subscribers shall not intentionally compromise the security of the mtnlTrustLine PKI.

2.1.4 Relying Party Obligations

Before any act of reliance, Relying Parties shall independently assess the appropriateness of the use of a Digital Certificate for any given purpose and determine that the Certificate will, in fact, be used for an appropriate purpose.

mtnlTrustLine is not responsible for assessing the appropriateness of the use of a Certificate. Relying Parties shall not use Certificates beyond the limitations in CP § 1.3.4.2 and for purposes prohibited in CP § 1.3.4.3.

Assuming that the use of the Certificate is appropriate, Relying Parties shall utilize the appropriate software and/or hardware to perform digital signature verification or other cryptographic operations they wish to perform, as a condition of relying on Certificates in connection with each such operation. Such operations include identifying a Certificate chain and verifying the Digital Signatures on all Certificates in the Certificate chain. Relying Parties shall not rely on a Certificate unless these verification procedures are successful.

Relying Parties shall also check the status of a Certificate on which they wish to rely, as well as all the Certificates in its Certificate chain in accordance with CP §§ 4.4.10, 4.4.12. If any of the Certificates in the Certificate chain have been revoked, the Relying Party shall not rely on the End User Subscriber Certificate or other revoked Certificate in the Certificate chain.

Finally, Relying Parties must assent to the terms of mtnlTrustLine Subscriber Agreement and Relying Party Agreement as a condition of using or otherwise relying on Digital Certificates.

If all of the checks described above are successful, the Relying Party shall be entitled to rely on the Certificate, provided that reliance upon the Certificate is reasonable under the circumstances.

If the circumstances indicate a need for additional assurances, the Relying Party must obtain such assurances for such reliance to be deemed reasonable.

Relying Parties shall not intentionally compromise the security of the mtnlTrustLine PKI.

2.1.5 Repository Obligations

2.2 Liability

2.2.1 CA Liability

mtnlTrustLine Subscriber Agreement and Relying Party Agreement shall contain warranties, disclaimers, and limitations of liability listed below.

2.2.1.1 Warranties to Subscribers and Relying Parties

● There are no material misrepresentations of fact in the Digital Certificate known to or originating from mtnlTrustLine or its Sub-CAs or RAs.

● There are no errors in the information in the Digital Certificate that were introduced by mtnlTrustLine or its Sub-CAs or its RAs while approving the Certificate Application or issuing the Digital Certificate as a result of a failure to exercise reasonable care in managing the Certificate Application or creating the Digital Certificate,

● Revocation services and use of the Repository conform to this CPS in all material aspects.

mtnlTrustLine shall warrant to Relying Parties who reasonably rely on a Digital Certificate that:

● All information in or incorporated by reference in such Certificate, except non‑verified Subscriber Information, is accurate,

● In the case of Certificates appearing in the mtnlTrustLine Repository, that the Certificate has been issued to the individual or organization named in the Certificate as the Subscriber, and that the Subscriber has accepted the Certificate in accordance with CPS § 4.3, and

● The entities approving the Certificate Application and issuing the Certificate have substantially complied with this CPS when issuing the Certificate.

2.2.1.2 Disclaimers of Warranties

To the extent permitted by applicable law, mtnlTrustLine shall disclaim any warranty of fitness for a particular purpose, outside the context of its CPS.

2.2.1.3 Limitations of Liability

To the extent permitted by applicable law, mtnlTrustLine Subscriber Agreement and Relying Party Agreement shall limit the liability to exclude indirect, special, incidental, and consequential damages. For a specific Digital Certificate the CA liability shall be limited to the following liability caps:

Class of Certificate	Class 1	Class 2	Class 3
Liability Cap	INR 1,000	INR 5,000	INR 15,000

2.2.1.4 Force Majeure

To the extent permitted by applicable law, mtnlTrustLine Subscriber Agreement and Relying Party Agreement shall include a force majeure clause protecting mtnlTrustLine.

2.2.2 RA Liability

The warranties, disclaimers of warranty, limitations of liability, and force majeure clauses required by CP §§ 2.2.1.1, 2.2.1.2, 2.2.1.3, 2.2.1.4 also apply to all RAs in the mtnlTrustLine PKI.

2.2.3 Subscriber Liability

2.2.3.1 Subscriber Warranties

● Each digital signature created using the private key corresponding to the Public Key listed in the Digital Certificate is the digital signature of the Subscriber and the Digital Certificate has been accepted and is operational (not expired or revoked) at the time the digital signature is created,

● No unauthorized person has ever had access to the Subscriber’s private key,

● All representations made by the Subscriber in the Certificate Application are true,

● All information supplied by the Subscriber and contained in the Digital Certificate is true,

● The Digital Certificate is being used exclusively for authorized and legal purposes, consistent with the applicable CPS, and

● The Subscriber is an End User Subscriber and not a CA, and is not using the private key corresponding to any Public Key listed in the Digital Certificate for purposes of digitally signing any Digital Certificate (or any other format of certified Public Key) or CRL, as a CA or otherwise.

2.2.3.2 Private Key Compromise

CP § 6.2.7.1 sets forth standards for the protection of the private keys of Subscribers compliant with the IT-Act 2000. mtnlTrustLine Subscriber Agreement shall state that Subscribers failing to meet these standards are solely responsible for any loss or damage resulting from such failure.

2.2.4 Relying Party Liability

mtnlTrustLine Subscriber Agreement and Relying Party Agreement shall require Relying Parties to acknowledge that they have sufficient information to make an informed decision as to the extent to which they choose to rely on the information in a Digital Certificate, that they are solely responsible for deciding whether or not to rely on such information, and that they shall bear the legal consequences of their failure to perform the Relying Party obligations in CP § 2.1.4.

2.3 Financial Responsibility

2.3.1 Indemnification by Subscribers and Relying Parties

2.3.1.1 Indemnification by Subscribers

To the extent permitted by applicable law, mtnlTrustLine Subscriber Agreement shall require Subscribers to indemnify mtnlTrustLine for:

● Falsehood or misrepresentation of fact by the Subscriber on the Subscriber’s Certificate Application,

● Failure by the Subscriber to disclose a material fact on the Certificate Application, if the misrepresentation or omission was made negligently or with intent to deceive any party,

● The Subscriber’s failure to protect the Subscriber’s private key, to use a Trustworthy System, or to otherwise take the precautions necessary to prevent the compromise, loss, disclosure, modification, or unauthorized use of the Subscriber’s private key, or

● The Subscriber’s use of a name (including without limitation within a common name, domain name, or e- mail address) that infringes upon the Intellectual Property Rights of a third party.

2.3.1.2 Indemnification by Relying Parties

To the extent permitted by applicable law, mtnlTrustLine Subscriber Agreement and Relying Party Agreement shall require Relying Parties to indemnify mtnlTrustLine for:

● The Relying Party’s failure to perform the obligations of a Relying Party,

● The Relying Party’s reliance on a Certificate that is not reasonable under the circumstances, or

● The Relying Party’s failure to check the status of such Certificate to determine if the Certificate is expired or revoked.

2.3.2 Fiduciary Relationships

To the extent permitted by applicable law, mtnlTrustLine Subscriber Agreement and Relying Party Agreement shall disclaim any fiduciary relationship between mtnlTrustLine or mtnlTrustLine Enterprise Customer RA or mtnlTrustLine Enterprise Customer Sub-CA on one hand and a Subscriber or Relying Party on the other hand.

2.3.3 Administrative Processes

mtnlTrustLine shall have sufficient financial resources to maintain the integrity of its PKI, and must be reasonably able to bear the risk of liability to Subscribers and Relying Parties. mtnlTrustLine shall also maintain a reasonable level of insurance coverage for errors and omissions, either through an errors and omissions insurance program with an insurance carrier or a self- insured retention.

2.4 Interpretation and Enforcement

2.4.1 Governing Law

The Information Technology Act, 2000, Information Technology (Certifying Authorities) Rules, 2000 and Information Technology (Certifying Authority) Regulations, 2001 or any subsequent updates shall govern the validity of this CP, the construction of its terms, and the interpretation and enforcement of the rights and duties of the parties hereto.

2.4.2 Severability, Survival, Merger, Notice

To the extent permitted by applicable law, mtnlTrustLine Subscriber Agreement and Relying Party Agreement shall contain severability, survival, merger, and notice clauses.

2.4.3 Dispute Resolution Procedures

To the extent permitted by applicable law, disputes among mtnlTrustLine, Customers, End User Subscribers or Relying Parties shall be resolved pursuant to provisions in the applicable agreements among the parties.

2.4.3.1 Role of the CCA

Under the IT-Act 2000, the Controller of Certifying Authorities (CCA) is also authorized to resolve disputes arising out of CA services. His role is described in detail in the IT-Act 2000 and its associated rules and regulations.

2.5 Fees

2.5.1 Certificate Issuance or Renewal Fees

mtnlTrustLine is entitled to charge End User Subscribers for the Issuance, Renewal, and Replacement of Digital Certificates.

2.5.2 Certificate Access Fees

mtnlTrustLine shall not charge a fee as a condition of making a Certificate available in its Repository or otherwise making Certificates available to Relying Parties. However, mtnlTrustLine reserves the right to amend this policy and charge such fees in future.

2.5.3 Revocation or Status Information Access Fees

mtnlTrustLine shall not charge a fee as a condition of making the CRLs required by CPS § 4.4.9 available in a Repository or otherwise available to Relying Parties. However, mtnlTrustLine reserves the right to amend this policy and charge such fees in future.

mtnlTrustLine is entitled to charge a fee for providing OCSP services, or other value-added Revocation and status information services.

2.5.4 Fees for Other Services Such as Policy Information

mtnlTrustLine is entitled to charge a reasonable fee for providing a printed copy of this CP or the CPS.

2.5.5 Refund Policy

To the extent permitted by applicable law mtnlTrustLine shall implement a refund policy and publish it within its web sites in addition to placing it in the Subscriber Agreements and the CPS.

2.6 Publication and Repositories

2.6.1 Publication of CA Information

mtnlTrustLine shall be responsible for publishing Certificates and CRLs in its Repository.

mtnlTrustLine CPS, Subscriber Agreement, Relying Party Agreement and this CP shall be published in the mtnlTrustLine web sites.

mtnlTrustLine shall publish the URL of the applicable Relying Party Agreement within each Certificate it issues in accordance with CP §§ 3.1.1, 7.1.6, 7.1.8.

2.6.2 Frequency of Publication

Relevant information shall be published promptly after it is available to mtnlTrustLine. The CPS shall contain provisions relating to amendments, and CPS changes shall be published in accordance with such provisions.

CP §§ 4.4.9, 4.4.11 govern the frequency of the publication of Certificate status information.

2.6.3 Access Controls

mtnlTrustLine shall not intentionally use technical means of limiting access to this CP, the CPS, Certificates, Certificate status information, or CRLs. mtnlTrustLine shall, however, require persons to agree to the Relying Party Agreement as a condition to accessing Certificates, Certificate status information, or CRLs.

mtnlTrustLine shall implement controls to prevent unauthorized persons from adding, deleting, or modifying Repository entries.

2.6.4 Repositories

2.7 Compliance Audit

mtnlTrustLine shall perform regular audits in compliance with the requirements of the IT-Act 2000, and its associated rules and regulations. These audits shall be performed by an auditor empanelled with the Controller of Certifying Authorities (CCA).

2.7.1 Frequency of Compliance Audit

Thorough statutory compliance audits shall be conducted annually in addition to quarterly and half-yearly audits.

2.7.2 Identity/ Qualifications of Auditor

Only a third party certified public auditing firm, empanelled by the Controller of Certifying Authorities (CCA), can perform the compliance audits of mtnlTrustLine. mtnlTrustLine auditors’ posses demonstrated expertise in computer security and in the performance of IT security and PKI compliance audits.

2.7.2.1 Self-Audits

Self-audits shall be performed by a person within mtnlTrustLine that is hierarchically independent of the system Administrators, network Administrators, PKI Administrators, or other Administrators performing CA/RA functions.

2.7.3 Auditor’s Relationship to Audited Party

Compliance audits performed by third-party audit firms shall be conducted by firms independent of mtnlTrustLine. Such firms shall not have a conflict of interest that hinders their ability to perform auditing services. With respect to self-audits, see CP § 2.7.2.1.

2.7.4 Topics covered by audit

Compliance audit shall involve an examination of all procedures and operations of mtnlTrustLine for compliance with the IT-Act 2000, the CPS and this CP.

The monthly self-audits shall focus on Subscriber validation and system administration.

The half-yearly audits shall focus on the security policy, physical security, and planning of mtnlTrustLine operations.

11. Appropriate security clearances for outgoing employees such as deletion of keys and revocation of access privileges

2.7.5 Actions Taken as a Result of Deficiency

After receiving a report based on the Compliance Audit, mtnlTrustLine shall, in good faith, use reasonable efforts to work out a corrective action plan for correcting any identified problems or deficiencies and to implement the plan.

2.7.6 Communications of Results

Results of the compliance audit of mtnlTrustLine shall be submitted to the CCA and may be released to any other party at the discretion of mtnlTrustLine management.

2.8 Confidentiality Policy

mtnlTrustLine shall implement a privacy policy in conforming to applicable laws. Specifically, mtnlTrustLine and its RAs shall not disclose or sell the names of Certificate Applicants or other identifying information about them, subject to CP § 2.8.2 and the right of a terminating CA to transfer such information to a successor CA under CP § 4.9.

2.8.1 Types of Information to be Kept Confidential

The following information shall, subject to CP § 2.8.2, be kept confidential (“Confidential Information”):

● Transactional records (both full records and the audit trail of transactions),

● Security measures controlling the operations of mtnlTrustLine hardware and software and the administration of PKI services and designated Certificate Application services.

2.8.2 Types of Information Not Considered Confidential

Digital Certificates, Certificate Revocation Lists and other Certificate status information, mtnlTrustLine Repository, and information contained within them are not considered confidential information. Information not expressly deemed confidential information under CPS § 2.8.1 shall not be considered confidential.

2.8.3 Disclosure of Certificate Revocation/Suspension Information

2.8.4 Release to Law Enforcement Officials

mtnlTrustLine PKI participants shall acknowledge that mtnlTrustLine is entitled to disclose confidential information if, in good faith, mtnlTrustLine believes disclosure is necessary in response to order from a court or tribunal or any government or public authority having the power to compel the disclosure.

2.8.5 Release as part of Civil Discovery

mtnlTrustLine PKI participants shall acknowledge that mtnlTrustLine is entitled to disclose confidential information if mtnlTrustLine is called upon to make such disclosure in response to judicial, administrative, or other legal process during any judicial, arbitration, litigation or administrative proceedings. mtnlTrustLine shall make reasonable efforts to protect the disclosed information by restricting the disclosure of the information to the extent reasonably required by any such judicial, arbitration, litigation or administrative proceedings.

2.8.6 Disclosure Upon Owner’s Request

Privacy policies established pursuant to CP § 2.8 shall contain provisions relating to the disclosure of confidential information to the person disclosing it to mtnlTrustLine.

2.8.7 Other Information Release Circumstances

2.9 Intellectual Property Rights

2.9.1 Rights in Certificates

mtnlTrustLine retains all Intellectual Property Rights in and to the Certificates and Revocation information that it issues. mtnlTrustLine shall grant permission to freely reproduce and distribute Certificates and Revocation information, provided that they are reproduced in full and their use is subject to the Relying Party Agreement.

2.9.2 Rights in the CP & CPS

mtnlTrustLine retains all Intellectual Property Rights in and to this CP and the mtnlTrustLine CPS.

2.9.3 Rights in Names

A Certificate Applicant retains all rights it has (if any) in any trademark, service mark, or trade name contained in any Certificate Application and Distinguished Name within any Certificate issued to such Certificate Applicant.

2.9.4 Rights in Keys and Key Material

Key pairs corresponding to Certificates of CAs, Sub-CAs, and End User Subscribers are the property of the CAs, Sub-CAs, and End User Subscribers that are the respective subjects of these Certificates, regardless of the physical medium within which they are stored and protected, and such persons retain all intellectual property rights in and to these key pairs.

Secret Shares of a CA or Sub-CA’s private key are the property of the CA or Sub-CA who retains all intellectual property right in and to such secret shares.

3 Identification And Authentication

3.1 Initial Registration

3.1.1 Types of Names

End User Subscriber Digital Certificates shall contain an X.501 distinguished name (DN) in the subject name field.

Class 1 Certificates shall include an authenticated e-mail address (E) attribute in the subject distinguished name.

Class 2 and Class 3 Certificates shall include an authenticated common name (CN) attribute in the subject distinguished name.

Class 2 and Class 3 Certificates may contain an authenticated organization name (O) attribute in the subject distinguished name.

All End User Certificates may contain a serial number (SN) attribute in the subject distinguished name.

In addition, all End User Certificates may contain other authenticated attributes required to determine the identity of the Subscriber.

3.1.2 Meaning of Names

End User Subscriber Digital Certificates shall include subject distinguished names with commonly understood semantics permitting the determination of the identity of the individual or organization that is the subject of the Certificate.

For Certificates issued to Individuals the common name (CN) attribute shall represent the individual’s generally accepted personal name. For Certificates issued to Devices this common name shall either be a domain name (for server Certificates) or the legal name of the organization, or unit within the organization or any other name identifying the device and legally owned or assigned to the organization.

The organization name (O) attribute type shall, when present in the subject distinguished name, represent the legal name of the Subscriber organization. This shall be used to only to determine the identity of the Subscriber and shall not imply any power‑of‑attorney or other rights.

The serial number (SN) attribute type shall, when present in the subject distinguished name, be used to distinguish the identity of the Subscriber. This attribute has no defined semantics beyond ensuring uniqueness of subject names. It may contain a number or code assigned by mtnlTrustLine or an identifier assigned by a government or civil authority.

3.1.3 Rules for Interpreting Various Name Forms

3.1.4 Uniqueness of Names

The subject distinguished name listed in a Certificate shall be unambiguous and unique for all Certificates issued within the mtnlTrustLine PKI, and conform to X.500 standards for name uniqueness.

3.1.5 Name Claim Dispute Resolution

Certificate Applicants shall not use names in their Certificate Applications that infringe upon the Intellectual Property Rights of others.

However, mtnlTrustLine shall not be required to determine whether a Certificate Applicant has Intellectual Property Rights in the name appearing in a Certificate Application or to arbitrate, mediate, or otherwise resolve any dispute concerning the ownership of any domain name, trade name, trademark, or service mark.

mtnlTrustLine shall be entitled, without liability to any Certificate Applicant, to reject or suspend any Certificate Application because of such dispute.

3.1.6 Recognition, Authentication, and Role of Trademarks

3.1.7 Method to Prove Possession of Private Key

The method to prove possession of a private key shall be PKCS #10 or another cryptographically equivalent and mtnlTrustLine approved demonstration.

3.1.8 Authentication of Organization Identity

3.1.8.1 Authentication of Organization Identity

mtnlTrustLine shall require all its RAs to confirm the identity of an organization, before issuing a Digital Certificate with the name of the organization in the subject distinguished name, in accordance with the procedures set forth below:

» Determine that the organization exists by using organizational documentation issued by or filed with the applicable government that confirms the existence of the organization,

» Confirm with an appropriate organizational contact by telephone, registered post, or comparable procedure certain information about the organization, that the organization has authorized the Certificate Application and that the person submitting the Certificate Application on behalf of the Certificate Applicant is authorized to do so.

In addition to the procedures above, the Certificate Applicant must demonstrate that it rightfully holds the private key corresponding to the Public Key to be listed in the Certificate in accordance with CPS § 3.1.7.

3.1.8.2 Class 2 Certificates for Devices

The authentication of Devices for Class 2 device Certificates shall consist of authenticating the existence of the organization pursuant to CP § 3.1.8.1. mtnlTrustLine shall also, during such authentication process, confirm that the appropriate name(s) identifying the device(s) is legally owned by or assigned to the organization. Where it is not possible to confirm the legal right of the organization to the device names, confirm that the organization’s use of such names does not conflict with generally accepted standards.

In addition, mtnlTrustLine shall also confirm that the Certificate Applicant has taken reasonable measures to ensure the security of the device’s private key.

3.1.8.3 Class 3 Server Certificates

The authentication of Servers for Class 3 server Certificates shall consist of authenticating the existence of the organization pursuant to CP § 3.1.8.1. mtnlTrustLine shall also, during such authentication process, determine that the organization is the record owner of the domain name(s) that is the subject of the Certificate or is otherwise authorized to use the domain name(s).

In addition, mtnlTrustLine shall also confirm that the Certificate Applicant has taken reasonable measures to ensure the security of the server’s private key.

3.1.8.4 Authentication of the Identity of Sub-CAs and RAs

mtnlTrustLine organizational Customers, before becoming Sub-CAs or RAs, shall enter into an agreement with mtnlTrustLine.

mtnlTrustLine shall authenticate the identity of the prospective Sub-CA or RA Customer before final approval of its status as Sub-CA or RA. This shall be confirmed by requiring the personal appearance of an authorized representative of the organization before authorized personnel of mtnlTrustLine.

The checks required for the confirmation of the organization identity under CP § 3.1.8.1 shall also be performed, except that instead of a Certificate Application, the validation is of an application to become a Sub-CA or RA. Also, mtnlTrustLine shall confirm that the person identified as an Administrator is authorized to act in the capacity.

3.1.9 Authentication of Individual Identity

mtnlTrustLine shall require all its RAs to confirm the identity of an individual, before issuing a Digital Certificate, in accordance with the procedures of authentication set forth in this CP § 3.1.9 for each Class of Certificate.

The authentication procedures in common for all Class of Certificates shall include:

» Verifying that the Certificate Applicant is the person identified in the Certificate Application (except for Certificate Applicants for Class 1 Certificates - CP § 3.1.9.1),

» Establishing that the Certificate Applicant rightfully holds the private key corresponding to the Public Key to be listed in the Certificate in accordance with CP § 3.1.7, and

These procedures are in addition to the more detailed procedures described below for each Class of Certificate.

3.1.9.1 Class 1 Certificates

Authentication of Individuals for Class 1 Certificates shall consist of a check to ensure that the subject distinguished name is a unique and unambiguous subject name within the mtnlTrustLine Class 1 Repository and only a limited confirmation of the Certificate Applicant’s e- mail address.

mtnlTrustLine shall not authenticate the identity of the Class 1 Certificate Applicant. As a result, the Certificate Applicant’s own personal name shall not appear in the subject name of the Certificate. Instead the Certificates Subscriber Distinguished Name may be populated with a generic Common Name (CN).

3.1.9.2 Class 2 Certificates

Authentication of Individuals or Devices for Class 2 Certificates shall consist of determining if identifying information in the Certificate Application matches information residing in mtnlTrustLine approved and well-recognized business or consumer database(s) (Validating Database). If the information in the Certificate Application matches the information in the database, mtnlTrustLine or any of its RA may approve the Certificate.

mtnlTrustLine may provide its RAs with an optional software module for automatic approval and Revocation of users or Devices directly from pre-existing databases, rather than requiring manual authentication for each Certificate Application. RA's using software to automate the processing of Certificate requests shall authenticate the identity of potential Certificate Applications before placing their information in the Validating Database.

3.1.9.3 Class 3 Certificates

The authentication of Class 3 individual Certificates is based on the personal (physical) presence of the Certificate Applicant before an agent of mtnlTrustLine, or before a notary public or other official with comparable authority as notified by mtnlTrustLine from time to time. The agent, notary or other official shall check the identity of the Certificate Applicant against a well-recognized form of government-issued identification, such as a passport, PAN card, or driver’s license and one other identification credential.

The authentication of Administrators for Class 3 Administrator Certificates shall consist of authenticating the existence of the Administrator’s employer and confirming the employment and authorization of the person named as Administrator. mtnlTrustLine shall authenticate Certificate Applications first by authenticating the identity of the entity employing or retaining the Administrator pursuant to CP § 3.1.8.1. Such entity shall either be a mtnlTrustLine Enterprise Customer RA or a mtnlTrustLine Enterprise Customer Sub-CA. mtnlTrustLine shall also, during such authentication process, confirm the authorization of the Certificate Applicant to act as Administrator.

3.2 Routine Rekey (Renewal)

3.2.1 Renewal of End User Subscriber Certificates

mtnlTrustLine shall require its RAs to authenticate a request for Renewal before approving a Certificate Renewal for the Subscriber of an End User Subscriber Certificate. mtnlTrustLine approved Renewal procedures shall ensure that the person or organization seeking to renew an end- user Subscriber Certificate is in fact the Subscriber of the Certificate.

Other than mtnlTrustLine approved Renewal procedure, the requirements for the authentication of an original Certificate Application in CP §§ 3.1.8, 3.1.9 shall be used for renewing an End User Subscriber Certificate.

3.2.2 Renewal of Sub-CA Certificates

A Sub-CAs superior entity approving an application for a Sub-CA Certificate shall be responsible for authenticating a request for Renewal. Renewal procedures shall ensure that an organization seeking to renew the Sub-CA Certificate is in fact the Subscriber of the Sub-CA Certificate. Authentication procedures shall be the same as original enrollment pursuant to CP § 3.1.8.4.

3.3 Rekey After Revocation - No Key Compromise

mtnlTrustLine shall not permit Renewal after Revocation if Revocation occurred because the Certificate (other than a Class 1 Certificate) was issued to a person other than the one named as the subject of the Certificate, or the Certificate (other than a Class 1 Certificate) was issued without the authorization of the person named as the subject of such Certificate, or the RA approving the Subscriber’s Certificate Application discovers or has reason to believe that a material fact in the Certificate Application is false.

Subject to the foregoing paragraph, Renewal of an organizational or Sub-CA Certificate following Revocation of the Certificate is permissible as long as Renewal procedures ensure that the organization or Sub-CA seeking Renewal is in fact the Subscriber of the Certificate. Renewed organizational Certificates shall contain the same subject distinguished name as the subject distinguished name of the organizational Certificate being renewed.

Renewal of an individual Certificate following Revocation again must ensure that the person seeking Renewal is, in fact, the Subscriber. Other than mtnlTrustLine approved Renewal procedure, the requirements for the validation of an original Certificate Application in CP §§ 3.1.8, 3.1.9 shall be used for renewing a Certificate following Revocation.

3.4 Revocation Requests

mtnlTrustLine Revocation procedures shall ensure prior to any Revocation of any Certificate that the Revocation has in fact been requested by the Certificate’s Subscriber or the RA that approved the Certificate Application. Acceptable procedures for authenticating the Revocation requests of a Subscriber shall include:

● Having the Subscriber submit the Subscriber’s challenge phrase, and revoking the Certificate automatically if it matches the challenge phrase on record,

● Receiving a message purporting to be from the Subscriber that requests Revocation and contains a digital signature verifiable with reference to the Certificate to be revoked, and

● Communication with the Subscriber providing reasonable assurances in light of the Class of Certificate that the person or organization requesting Revocation is, in fact the Subscriber. Such communication, depending on the circumstances, may include one or more of the following: telephone, facsimile, e- mail, postal mail, or courier service.

4 Operational Requirements

4.1 Certificate Application

4.1.1 Enrollment for End User Subscriber Certificates

mtnlTrustLine shall ensure that Subscribers all End User Certificate Applicants undergo an enrollment process consisting of:

● Completing a Certificate Application and providing the requested information and evidence,

● Generating, or arranging to have generated, a key pair in accordance with CP § 6.1 and ensure reasonable precautions to protect the private key from compromise in accordance with CP §§ 6.1, 6.2, 6.4.

● The Certificate Applicant delivering his, her, or its Public Key to mtnlTrustLine in accordance with CP § 6.1.3,

● Demonstrating to mtnlTrustLine pursuant to CP § 3.1.7 that the Certificate Applicant has possession of the private key corresponding to the Public Key submitted for certification, and

● Manifesting assent to the mtnlTrustLine Subscriber Agreement and accepting applicable terms and conditions regarding use of Certificates.

Certificate Applications shall be submitted either to a mtnlTrustLine RA or web-RA.

4.1.2 Enrollment for Sub-CA or RA Certificates

mtnlTrustLine does not require Sub-CA or RA Certificate Subscribers, to complete formal Certificate Applications. Instead, they enter into a contract with mtnlTrustLine pursuant to CP § 3.1.8.4. Sub-CA and RA applicants shall provide their credentials as required by CP § 3.1.8.4 to demonstrate their identity.

4.2 Certificate Issuance

4.2.1 Issuance of End User Subscriber Certificates

After a Certificate Applicant submits a Certificate Application, the mtnlTrustLine RA receiving the Certificate Application (CP § 4.1.1) shall validate or refute the information in the Certificate Application pursuant to CP §§ 3.1.8, 3.1.9. Upon successful performance of all required authentication procedures pursuant to CP § 3.1, the RA receiving the Certificate Application shall approve the Certificate Application. If authentication is unsuccessful, the RA receiving the Certificate Application shall reject the Certificate Application.

A Certificate shall be created and issued following the approval of a Certificate Application by an RA.

The procedures of this section shall also be used for the Issuance of Certificates in connection with the submission of a request to renew the Certificate.

4.2.2 Issuance of Sub-CA and RA Certificates

mtnlTrustLine shall authenticate the identity of entities wishing to become Sub-CA’s or RA’s as per CP § 3.1.8.4 and, if approved, issue the Certificates needed to perform their Sub-CA or RA functions in accordance with CP § 6.1.

mtnlTrustLine shall ensure that before a contract is entered into with the Sub-CA or RA applicant under CP § 4.1.2, the identity of the potential Sub-CA or RA shall be confirmed based on the credentials it presents. The execution of such a contract shall indicate the complete and final approval of the application by mtnlTrustLine.

The decision to approve or reject a Sub-CA or RA application shall be solely at the discretion of mtnlTrustLine.

4.3 Certificate Acceptance

mtnlTrustLine shall, either directly or through an RA, notify Subscribers about the creation of the Subscriber’s Digital Certificates, and provide the Subscribers with access to the Certificates by notifying them that their Certificates are available and notifying them of the means for obtaining them.

Upon Issuance, Certificates shall be made available to End User Subscribers, either by allowing them to receive the Certificate in person from an RA, or allowing them to download their Certificate from a web site or via a message sent to the Subscriber containing the Certificate.

Receiving a Certificate from an RA, or downloading a Certificate, or installing a Certificate from a message attaching it shall constitute the Subscriber’s Acceptance of the Certificate.

4.4 Certificate Suspension and Revocation

4.4.1 Circumstances for Revocation

4.4.1.1 Circumstances for Revoking End User Subscriber Certificates

1) The RA approving the Subscriber’s Certificate Application has reason to believe that there has been a compromise of the Subscriber’s private key,

2) The RA approving the Subscriber’s Certificate Application has reason to believe that the Certificate was issued in a manner not materially in accordance with the procedures required by this CPS and the mtnlTrustLine CP,

3) The RA approving the Subscriber’s Certificate Application determines that the Certificate (other than a Class 1 Certificate) was issued to a person other than the one named as the subject of the Certificate, or the Certificate (other than a Class 1 Certificate) was issued without the authorization of the person named as the subject of such Certificate,

4) The RA approving the Subscriber’s Certificate Application has reason to believe that a material fact in the Certificate Application is false,

5) The RA approving the Subscriber’s Certificate Application determines that a material prerequisite to Certificate Issuance was neither satisfied nor waived,

7) In the case of organizational Certificates, the Subscriber’s organization name changes,

8) The Subscriber has materially breached a material obligation, representation, or warranty under the applicable Subscriber Agreement,

10) The Subscriber requests Revocation of the Certificate in accordance with CP § 3.4.

An Administrator Certificate shall also be revoked if the authority of the Administrator Subscriber of the Certificate to act as Administrator has been terminated or otherwise has been ended.

4.4.1.2 Circumstances for Revoking Sub-CA or RA Certificates

mtnlTrustLine shall ensure that a Sub-CA or RA Certificate is promptly revoked if:

1) mtnlTrustLine discovers or has reason to believe that there has been a compromise of the Sub-CA or RA private key,

2) The agreement between mtnlTrustLine and the Sub-CA or RA has been terminated,

3) mtnlTrustLine discovers or has reason to believe that the Certificate was issued in a manner not materially in accordance with the procedures required by this CP and the applicable CPS,

4) mtnlTrustLine discovers that the Certificate was issued to an entity other than the one named as the subject of the Certificate, or the Certificate was issued without the authorization of the entity named as the subject of such Certificate,

5) mtnlTrustLine determines that a material prerequisite to Certificate Issuance was neither satisfied nor waived, or

4.4.2 Who Can Request Revocation

4.4.2.1 Who Can Request Revocation of an End User Subscriber Certificate

The only parties permitted to request Revocation of a Certificate issued pursuant to this policy shall be the individual Subscribers for their own individual Certificate, a duly authorized representative of the organization for organizational Certificates, or the RA that approved the Subscriber’s Certificate Application.

4.4.2.2 Who Can Request Revocation of a Sub-CA or RA Certificate

Only mtnlTrustLine is entitled to request or initiate the Revocation of the Certificates issued to its own CAs, Sub-CAs, and RAs.

Non-mtnlTrustLine Sub-CAs and RAs shall be entitled, through their duly authorized representatives, to request the Revocation of their own Certificates. mtnlTrustLine shall also be entitled to request or initiate the Revocation of Non-mtnlTrustLine Sub-CAs and RAs Certificates.

4.4.3 Procedure for Revocation Request

4.4.3.1 Procedure for Revocation Request of an End User Subscriber Certificate

mtnlTrustLine shall ensure that End User Subscriber Certificates are revoked in a timely manner based on authorized and validated Certificate Revocation requests.

An End User Subscriber or duly authorized representative, as applicable, requesting Revocation shall communicate the request to the RA that approved the Subscriber’s Certificate Application. Such communication shall be in accordance with CP § 3.4. Upon receiving a valid Revocation request the RA shall promptly revoke the Certificate and notify the Subscriber about the Certificate Revocation.

A mtnlTrustLine RA revoking an End User Subscriber Certificate upon its own initiative shall do so pursuant to CP § 3.4.

4.4.3.2 Procedure for Revocation Request of a Sub-CA or RA Certificate

A Sub-CA or RA requesting Revocation shall communicate the request to mtnlTrustLine. Upon receiving a valid Revocation request mtnlTrustLine shall promptly revoke that Certificate and notify the requester about the successful Revocation. In case of the Revocation of a Sub-CA, mtnlTrustLine shall also notify the concerned RAs about the Sub-CA Revocation.

mtnlTrustLine revoking a Sub-CA or RA Certificate upon its own initiative shall initiate Revocation in the same manner.

4.4.4 Revocation Request Grace Period

The party requesting a Revocation shall do so as promptly as possible, but no later than within a reasonable time.

4.4.5 Circumstances for Suspension

mtnlTrustLine PKI does not at present offer suspension services for End User Subscriber Certificates.

4.4.6 Who Can Request Suspension

4.4.7 Procedure for Suspension Request

4.4.8 Limits on Suspension Period

4.4.9 CRL Issuance Frequency

mtnlTrustLine offers CRLs showing the Revocation of mtnlTrustLine PKI Digital Certificates and offers status checking services through the mtnlTrustLine PKI Repository.

mtnlTrustLine shall update and publish the CRLs for End User Subscriber Certificates whenever an End User Subscriber Certificate is revoked, and at least every 24 hours, even if no changes to the CRLs have been made.

mtnlTrustLine shall update and publish CRLs for Sub-CA Certificates whenever a Sub-CA Certificate is revoked and at least quarterly even if no changes to the CRLs have been made.

If a Certificate listed in a CRL expires, it shall be removed from later-issued CRLs starting thirty (30) days after the Certificate’s expiration.

4.4.10 Certificate Revocation List Checking Requirements

Relying Parties shall check the status of Certificates on which they wish to rely by referring to the most recent CRL from the CA/Sub-CA that issued the Certificate on which the Relying Party wishes to rely.

mtnlTrustLine shall provide Relying Parties with information on how to find the appropriate CRL to check for Revocation status by publishing the URI to the appropriate CRL in the Digital Certificate.

4.4.11 On-Line Revocation/Status Checking Availability

mtnlTrustLine PKI does not at present offer OCSP services for End User Subscriber Certificates.

mtnlTrustLine publishes all CRLs to its Repository which is available online and can be accessed using the LDAP or LDAPS or HTTP or HTTPS protocols.

4.4.12 On-Line Revocation Checking Requirements

4.4.13 Other Forms of Revocation Advertisements Available

4.4.14 Checking Requirements for Other Forms of Revocation Advertisements

4.4.15 Special Requirements Regarding Key Compromise

mtnlTrustLine PKI participants shall be notified of an actual or suspected CA/Sub-CA private key compromise using reasonable efforts. mtnlTrustLine shall use reasonable efforts to notify potential Relying Parties if they discover, or have reason to believe, that there has been a compromise of the private key of one of the CAs or one of the Sub-CAs within the mtnlTrustLine PKI hierarchy.

4.5 Security Audit Procedures

4.5.1 Types of Events Recorded

mtnlTrustLine shall ensure that all relevant information concerning its PKI is recorded for an appropriate period of time, as specified in the IT-ACT. The types of auditable events that must be recorded by each entity are set forth below. All logs, whether electronic or manual, shall contain the date and time of the event, and the identity of the entity that caused the event. mtnlTrustLine shall ensure that the integrity of current and archived records is maintained.

4.5.1.1 Events Recorded by mtnlTrustLine CA

mtnlTrustLine shall record in audit log files significant events in the mtnlTrustLine system such as:

3) Attempts to create, remove, set passwords or change the system privileges of the privileged users,

10) End User Subscriber Certificate Application, Issuance, Revocation, and Renewal,

mtnlTrustLine shall also collect and consolidate, either electronically or manually, security information not CA system generated such as:

18) Records of the destruction of media containing key material, activation data, or personal Subscriber information, and

mtnlTrustLine shall also record in audit log files and substantiate with manual records events related to the Key Generation System (KGS) optionally operated by mtnlTrustLine for End User key pair generation on smart cards.

20) mtnlTrustLine shall log all events relating to the life cycle of keys managed by the mtnlTrustLine, including any Subscriber keys generated by the Key Generation System of mtnlTrustLine.

21) mtnlTrustLine shall record all events relating to the Subscriber smart card management including receipt of smart cards from vendors (with details about batch & serial number), card initialization, card personalization, card storage, card dispatch, and card destruction by mtnlTrustLine.

4.5.1.2 Events Recorded by mtnlTrustLine RAs

mtnlTrustLine PKI RAs shall record in audit log files events relating to the security of their systems such as:

3) Attempts to create, remove, set passwords or change the system privileges of the privileged users,

10) Certificate lifecycle management-related events including approval or denial of Certificate Applications, requests for Revocation, or requests for Renewal, and

4.5.2 Frequency with which audit logs are processed

mtnlTrustLine Administrators and security Administrators shall routinely process the audit logs on a monthly basis.

mtnlTrustLine security Administrators shall also review the audit logs in response to alerts based on irregularities and incidents within the CA/RA systems. mtnlTrustLine security Administrators shall compare the CA system audit logs with audit logs from the RA system when any action is deemed suspicious.

Audit log processing shall consist of a review of the audit logs and documenting the reason for all significant events in an audit log summary. Audit log reviews shall include a verification that the log has not been tampered with, a brief inspection of all log entries, and a more thorough investigation of any alerts or irregularities in the logs. Actions taken based on audit log reviews shall be documented.

4.5.3 Period for which audit logs are kept

Audit logs shall be retained online for at least three (3) months after processing and thereafter archived in accordance with CP § 4.6.2.

4.5.4 Protection of Audit Log

Only authorized mtnlTrustLine personnel shall be allowed to view and process audit log files.

4.5.5 Audit Log Backup Procedures

Incremental backups of audit logs on physical removable media shall be created daily and full backups weekly. The backup media shall be stored in a safe storage.

4.5.6 Audit Log Accumulation System (Internal or External)

4.5.7 Notification to Event-Causing Subject

mtnlTrustLine is not required to notify the event-causing subject about the logging of events.

4.5.8 Vulnerability Assessments

Events in the audit log are recorded, in part, to monitor system vulnerabilities. A vulnerability assessment is performed, reviewed, and revised following an examination of these monitored events.

4.6 Records Archival

4.6.1 Types of Event Recorded

mtnlTrustLine shall retain an archive of information and actions that are material to each Certificate Application and to the creation, Issuance, Revocation, expiration, and Renewal of each Certificate issued in the mtnlTrustLine PKI. These records shall include all relevant evidence regarding:

1) The identity of the Subscriber named in each Certificate (except for Class 1 Certificates, for which only a record of the Subscriber’s unambiguous name is maintained) including documentary evidence in support of the Certificate Application,

2) The identity of persons requesting Certificate Revocation (except for Class 1 Certificates, for which only a record of the Subscriber’s unambiguous name is maintained),

4) certain foreseeable material facts related to issuing Certificates including, but not limited to, information relevant to successful completion of a compliance audit under CP § 2.7.

Records may be kept in the form of either computer-based messages or paper-based documents, provided their indexing, storage, preservation, and reproduction are accurate and complete.

4.6.2 Retention Period for Archive

Digital Certificates and CRLs issued in the mtnlTrustLine PKI and the records associated with them shall be archived for at least seven years after expiration.

Audit information detailed in CP § 4.5.1, shall be archived pursuant to CP § 4.5.3 and retained for a period of three years but shall not be destroyed until the completion of two successive annual audits succeeding the record period.

4.6.3 Protection of Archive

Only mtnlTrustLine authorized persons shall have access to the archive compiled under CP § 4.6.1.

mtnlTrustLine shall protect the archive against unauthorized viewing, modification, deletion, or other tampering, by storage within a trustworthy system.

The media holding the archive data and the applications required to process the archive data shall be maintained to ensure that the archive data can be accessed for the time period set forth in CP § 4.6.2.

4.6.4 Archive Backup Procedures

mtnlTrustLine shall create back up copies of archives compiled under CP § 4.6.1 as and when the archives are created.

Backup copies of the archive and copies of paper-based records under CP § 4.6.1 shall be maintained in an off-site disaster recovery facility in accordance with CP § 4.8.

4.6.5 Requirements for Time-Stamping of Records

Certificates, CRLs, and other revocation database entries shall contain time and date information. Such time information need not be cryptographic-based.

4.6.6 Archive Collection System (Internal or External)

4.6.7 Procedures to Obtain and Verify Archive Information

Only mtnlTrustLine trusted personnel shall be permitted to access the archived data. The archive information shall be made available to the CCA upon request.

4.7 Key Changeover

Before the usage period of the mtnlTrustLine CA private key expires (CP § 6.3.2), key changeover shall take place. The old "CA" and its private key shall be deactivated, and a new "CA" with a different private key and distinguished name shall be put in use. The new mtnlTrustLine CA Certificate issued by the RCAI shall be made available through the Repository (CP § 6.1.4).

Before the usage period of any mtnlTrustLine Sub-CA private key expires (CP § 6.3.2), key changeover for that Sub-CA shall take place. The old "Sub-CA" and its private key shall be deactivated, and a new "Sub-CA" with a different private key and distinguished name shall be put in use. The new Sub-CA Certificate issued by the appropriate mtnlTrustLine CA or Sub-CA shall be made available through the Repository (CP § 6.1.4). However, before a Sub-CA Certificate can be renewed, mtnlTrustLine should be able to reconfirms the identity of the Sub-CA under CP §§ 3.1.8.4, 3.2.2.

The distinguished name of the new CA or Sub-CA shall differentiate the new Certificate from the old Certificate by indicating information about the generation (version) of the CA/Sub-CA. All other information in the Certificate subject name shall remain the same.

4.8 Compromise and Disaster Recovery

mtnlTrustLine shall maintain off-site backups of the application logs, Certificate Application data, audit data (per CP § 4.5.1), and records for all Certificates and CRLs issued. Backup of CA and Sub-CA private keys shall be generated and maintained in accordance with CP § 6.2.4. These backups shall be made available in the event of a compromise or disaster.

4.8.1 Computing Resources, Software, and/or Data Are Corrupted

Following corruption of computing resources, software, and/or data, a report of the event to mtnlTrustLine security, and a response to the event, shall be promptly made by the affected CA or RA personnel in accordance with mtnlTrustLine incident and compromise reporting and handling procedures. Such procedures shall require appropriate escalation, incident investigation, and incident response.

4.8.2 Entity Public Key is Revoked

● The Revocation shall be reported in accordance with CP § 4.4.9 in the mtnlTrustLine Repository,

● Reasonable efforts shall be used to provide additional notice of the Revocation to mtnlTrustLine PKI participants, and

● mtnlTrustLine shall perform a key changeover in accordance with CP § 4.7, except following Revocation of a CA or Sub-CA Certificate in connection with the termination of a CA or Sub-CA under CP § 4.9.

4.8.3 Entity Key is Compromised

If the private key of a mtnlTrustLine PKI CA or Sub-CA is compromised, then all use of such private key shall cease immediately. The Certificate of that entity shall be revoked in accordance with CP § 4.4.3.2. Thereafter, reporting of the Revocation shall be made in accordance with CP § 4.8.2.

4.8.4 Secure Facility After a Natural or Other Type of Disaster

mtnlTrustLine shall develop, test, maintain, and, if necessary, implement a disaster recovery plan designed to mitigate the effects of any kind of natural or man-made disaster. Disaster recovery plans shall address the restoration of information systems services and key business functions.

mtnlTrustLine shall install and test equipment at its primary site to support CA/RA functions following all but a major disaster that would render the entire facility inoperable. Such equipment shall ensure redundancy and fault tolerance.

mtnlTrustLine shall maintain a disaster recovery site (DR site) with the capability of restoring or recovering operations within twenty‑four (24) hours following a disaster with, at a minimum, support for the Certificate Issuance, Certificate Revocation, and Repository functions.

mtnlTrustLine shall have the capability of declaring a disaster on its web sites and of re‑directing Subscribers, Relying Parties, and other interested persons to the disaster recovery site.

mtnlTrustLine disaster recovery database shall be synchronized with the production database within a time limit of eight hours.

mtnlTrustLine disaster recovery site shall have equipment with the same security protections as the primary site equipment.

mtnlTrustLine disaster recovery site shall have the same physical security protections as the primary site.

4.9 CA Termination

The termination of a mtnlTrustLine Sub-CA or CA shall be at the discretion of mtnlTrustLine management. The termination of a mtnlTrustLine Enterprise Customer Sub-CA shall be subject to the contract between the terminating Sub-CA and mtnlTrustLine.

In case of termination of a CA or Sub-CA mtnlTrustLine shall, in good faith, use reasonable effort to create a termination plan that minimizes disruption to Customers, Subscribers, and Relying Parties. The termination plan may cover issues such as:

● Providing notice to parties affected by the termination, such as Subscribers, Relying Parties, Customers, and the CCA,

● In case of mtnlTrustLine Enterprise Customer Sub-CAs, the termination cost sharing arrangement between the terminating Sub-CA and mtnlTrustLine,

● The preservation of the archives and records for the time periods required in CP § 4.6,

● The Revocation of Certificates of End User Subscribers and Sub-CAs, if necessary,

● The payment of compensation (if necessary) to Subscribers whose Certificates are revoked under the termination plan or provision for the Issuance of substitute Certificates by a successor CA or Sub-CA,

● Disposition of the CA’s or Sub-CA’s private key and the hardware token containing such private key, and

● Provisions needed for the transition of services to a successor CA or Sub-CA.

5 Physical, Procedural, And Personnel Security Controls

All entities performing CA and RA functions (mtnlTrustLine, mtnlTrustLine Enterprise Sub-CA Customers, and mtnlTrustLine Enterprise RA Customers) shall draft, implement, and enforce a security policy compliant with the Schedules II and III of the Information Technology (Certifying Authorities) Rules, 2000.

5.1 Physical Security Controls

The requirements described in the sub-sections below apply equally to mtnlTrustLine primary site as well as disaster recovery site (DR site).

5.1.1 Site Location and Construction

All CA and RA operations shall be conducted within a physically protected environment that deters, prevents, and detects unauthorized use of, access to, or disclosure of sensitive information and systems. Any parts of the premises shared with other Organizations shall be outside this perimeter. This environment shall comply with the requirements in the Schedules II and III of the Information Technology (Certifying Authorities) Rules, 2000.

Physical protection shall be achieved through the creation of clearly defined security perimeters (i.e. physical barriers) around the CA and RA systems. The physical security perimeter shall be constructed with materials that will deter, prevent, and detect covert or overt penetration. The physical security perimeter shall permit physical access to authorized personnel through a barrier such as a locked door that provides mandatory access control for Individuals and requires a positive response (door unlocks) for each individual to cross the security perimeter.

The mtnlTrustLine CA systems shall be housed in secure facilities that are protected by multiple physical security barriers, video monitoring, and two factor authentication including biometrics.

Online Cryptographic Signing Units (CSUs) shall be protected through the use of locked cabinets. Offline CSUs shall be protected through the use of locked safes, cabinets and containers. Access to CSUs and keying material shall be restricted to mtnlTrustLine trusted personnel. The opening and closing of cabinets or containers shall be logged for audit purposes.

mtnlTrustLine RA operations shall be conducted within secure facilities that are protected by multiple tiers of physical security including badge access.

5.1.2 Physical Access

mtnlTrustLine shall implement necessary physical security controls to restrict physical access to the CA and RA systems to mtnlTrustLine authorized personnel only. All physical access to the secure facility shall be logged electronically or manually as applicable.

5.1.3 Power and Air Conditioning

mtnlTrustLine CA and RA locations shall be equipped with primary and backup power systems to ensure continuous, uninterrupted access to electric power. Also, these secure facilities shall be equipped with primary and backup air conditioning systems to control the temperature. Such systems shall meet the requirements of the Schedule III of the Information Technology (Certifying Authorities) Rules, 2000.

5.1.4 Water Exposures

mtnlTrustLine CA and RA locations shall be constructed and equipped, and procedures shall be implemented, to prevent floods or other damaging exposure to water in accordance with the requirements of the Schedule III of the Information Technology (Certifying Authorities) Rules, 2000.

5.1.5 Fire Prevention and Protection

mtnlTrustLine CA and RA locations shall be constructed and equipped, and procedures shall be implemented, to prevent and extinguish fires or other damaging exposure to flame or smoke in accordance with the requirements of the Schedule III of the Information Technology (Certifying Authorities) Rules, 2000. These measures shall also meet all applicable fire safety regulations.

5.1.6 Media Storage

mtnlTrustLine shall protect the magnetic media holding back ups of critical system data or any other sensitive information from water, fire, or other environmental hazards, and shall use protective measures to deter, detect, and prevent the unauthorized use of, access to, or disclosure of such media in accordance with the requirements of the Schedule III of the Information Technology (Certifying Authorities) Rules, 2000.

5.1.7 Waste Disposal

mtnlTrustLine shall implement procedures for the disposal of waste (paper, media, or any other waste) to prevent the unauthorized use of, access to, or disclosure of waste containing confidential information within the meaning of CP § 2.8.1 in accordance with the requirements of the Schedule III of the Information Technology (Certifying Authorities) Rules, 2000.

5.1.8 Off-Site Backup

mtnlTrustLine shall maintain back ups of critical system data or any other sensitive information, including audit data, in a secure off-site facility in accordance with the requirements of the Schedule III of the Information Technology (Certifying Authorities) Rules, 2000.

5.2 Procedural Controls

5.2.1 Trusted Roles

mtnlTrustLine employees, contractors, consultants, and auditors that are designated to manage trustworthiness of the mtnlTrustLine PKI shall be considered to be “Trusted Persons” serving in a “Trusted Role.” Trusted persons include personnel that have access to or control authentication or cryptographic operations that may materially affect:

● The Acceptance, rejection, or other processing of Certificate Applications, Revocation requests, or Renewal requests, or enrollment information;

● The Issuance, or Revocation of Certificates, including personnel having access to restricted portions of the mtnlTrustLine Repository;

mtnlTrustLine considers the categories of personnel identified in this section as Trusted Persons having a Trusted Position. Persons seeking to become Trusted Persons by obtaining a Trusted Position must successfully complete the screening requirements of CP § 5.3.

5.2.2 Number of Persons Required Per Task

mtnlTrustLine shall establish, maintain, and enforce rigorous control procedures to ensure the segregation of duties based on job responsibility and to ensure that multiple trusted persons are required to perform sensitive tasks in accordance with the requirements of the Schedule III of the Information Technology (Certifying Authorities) Rules, 2000.

5.2.3 Identification and Authentication for Each Role

mtnlTrustLine shall authenticate the identity of all personnel seeking to become trusted persons by requiring personal (physical) presence of such personnel before trusted persons performing mtnlTrustLine security functions and a check of well-recognized forms of identification like passports and driver’s licenses. Identity shall be further confirmed through the background checking procedures in CP §§ 5.3.1, 5.3.2.

mtnlTrustLine shall ensure that personnel have achieved trusted status and departmental approval has been given before such personnel are:

● Issued electronic credentials to access and perform specific functions on mtnlTrustLine CA, RA, or other IT systems.

5.3 Personnel Security Controls

5.3.1 Background, Qualifications, Experience, and Clearance Requirements

mtnlTrustLine shall require that personnel seeking to become Trusted Persons present proof of the requisite background, qualifications, and experience needed to perform their prospective job responsibilities competently and satisfactorily.

5.3.2 Background Check Procedures

Prior to commencement of employment in a Trusted Role, mtnlTrustLine shall conduct background checks which include the following:

● Check of a government issued identification like passport, driver’s license and one other identification document.

The factors revealed in a background check that may be considered grounds for rejecting candidates for trusted positions or for taking action against an existing trusted person include the following categories:

Reports containing such information shall be evaluated by human resources and security personnel, and such personnel shall take actions that are reasonable in light of the type, magnitude, and frequency of the behavior uncovered by the background check. Such actions may include measures up to and including the cancellation of offers of employment made to candidates for trusted positions or the termination of existing trusted persons. The use of information revealed in a background check to take such actions shall be subject to applicable law.

5.3.3 Training Requirements and Training Procedures

mtnlTrustLine shall provide its personnel with the requisite training prior to being assigned to trusted roles, and shall provide the requisite on-the-job training, needed for them to perform their job responsibilities relating to CA or RA operations competently and satisfactorily.

mtnlTrustLine shall also periodically review its training programs, and the training shall address the elements relevant to functions performed by its personnel. Training programs must address the elements relevant to the particular environment of the person being trained, including:

5.3.4 Retraining Frequency and Requirements

mtnlTrustLine shall provide refresher training and updates to its personnel to the extent and frequency required to ensure that such personnel maintain the required level of proficiency to perform their job responsibilities competently and satisfactorily.

5.3.5 Job Rotation Frequency and Sequence

5.3.6 Sanctions for Unauthorized Actions

mtnlTrustLine shall establish, maintain, and enforce employment policies for the discipline of personnel following unauthorized actions. Disciplinary actions may include measures up to and including termination and shall be commensurate with the frequency and severity of the unauthorized actions.

5.3.7 Contracting Personnel Requirements

In limited circumstances, independent contractors or consultants may be used to fill trusted positions. Any such contractor or consultant shall be held to the same functional and security criteria that apply to a mtnlTrustLine employee in a comparable position.

Independent contractors and consultants who have not completed the background check procedures specified in CP § 5.3.2 shall be permitted access to mtnlTrustLine secure facilities only to the extent they are escorted and directly supervised by trusted persons.

5.3.8 Documentation Supplied to Personnel

mtnlTrustLine shall give its personnel (including trusted persons) the requisite training and other documentation needed to perform their job responsibilities competently and satisfactorily.

6 Technical Security Controls

6.1 Key Pair Generation and Installation

6.1.1 Key Pair Generation and Installation

mtnlTrustLine shall ensure that all cryptographic key pairs related to the mtnlTrustLine PKI are generated using trustworthy systems and processes that provide the required cryptographic strength of the generated keys and prevent the loss, disclosure, modification, or unauthorized use of private keys.

CA and Sub-CA key pair generation shall be carried out within a FIPS 140-1 level 3 or higher device in a physically secured environment by personnel in trusted roles under, at least, dual control. The personnel authorized to carry out this function shall be limited to those required to do so under the mtnlTrustLine's practices. The activities performed for each CA/Sub-CA key pair generation shall be recorded, dated and signed by all individuals involved. These records shall be kept for audit and tracking in accordance with CP § 4.5.1 and CP § 4.6.

Generation of End User Subscriber key pairs shall be performed by the Subscriber or at a mtnlTrustLine RA office in the presence of the Subscriber.

mtnlTrustLine may optionally pre-generate key pairs for its End User Subscribers on secure hardware tokens (smart cards). mtnlTrustLine shall ensure that:

1. Pre-generated Subscriber keys shall be generated using the RSA algorithm and shall have a key length of 1024 bits or more.

2. The hardware tokens (smart cards) and associated activation data (pass-phrases or PINs) shall be stored securely before delivery to the Subscriber.

3. mtnlTrustLine shall not back-up or otherwise compromise the integrity and privacy of the private keys.

6.1.2 Private Key Delivery to Entity

End User Subscribers’ private keys are generally generated by the End User Subscribers themselves, and therefore private key delivery to a Subscriber is unnecessary.

Private keys shall be delivered to End User Subscribers only when their key pairs are pre‑generated on hardware tokens, which are distributed to Certificate Applicants in connection with the enrollment process. mtnlTrustLine shall ensure that the entities distributing such tokens shall take reasonable efforts to provide physical security of the tokens to prevent the loss, disclosure, modification, or unauthorized use of the private keys on them.

6.1.3 Public Key Delivery to Certificate Issuer

When a Public Key is transferred to be certified, it shall be delivered through a mechanism ensuring that the Public Key has not been altered during transit and that the Certificate Applicant possesses the private key corresponding to the transferred Public Key. The acceptable mechanism within the mtnlTrustLine PKI for Public Key delivery is a PKCS#10 Certificate signing request package or an equivalent method ensuring that:

2. The Certificate Applicant possesses the private key corresponding to the transferred Public Key.

6.1.4 CA Public Key Delivery to Users

mtnlTrustLine shall make its CA and Sub-CA Public Keys available to the Relying Parties via CA Certificates in a secure fashion. These CA Certificates shall be published in the mtnlTrustLine Certificate Repository and the mtnlTrustLine web site. mtnlTrustLine CA and Sub-CA Certificates shall be verifiable by users with respect to the RCAI root Certificate.

6.1.5 Key Sizes

mtnlTrustLine shall use key pairs of length (strength) sufficient to prevent the revelation of the private key using cryptanalysis during the expected lifetime of such key pairs.

6.1.6 Public Key Parameters Generation

6.1.7 Parameter Quality Checking

6.1.8 Hardware or Software Key Generation

mtnlTrustLine shall generate CA and Sub-CA key pairs, and the random numbers for such key pairs, in FIPS 140-1 Level 3 compliant hardware.

mtnlTrustLine shall recommend that End User Subscribers generate their key pairs in hardware (smart cards), although such key pairs may be generated by the Subscriber in hardware or software.

End User Subscriber key pairs pre-generated by mtnlTrustLine on behalf of the Subscriber shall always be generated in secure hardware (smart cards).

6.1.9 Key Usage Purposes

mtnlTrustLine shall set the KeyUsage extension of X.509 Version 3 Certificates in accordance with IETF RFC 2459 (Internet X.509 Public Key Infrastructure Certificate and CRL Profile). The KeyUsage extension shall be configured so as to set and clear bits and the criticality field in accordance with table below.

	CA’s and Sub-CAs	Class 1	Class 2	Class 3
Criticality	FALSE	FALSE	FALSE	FALSE
0	digitalSignature	Clear	Set	Set	Set
1	nonRepudiation	Clear	Clear	Set	Set
2	keyEncipherment	Clear	Set	Set	Set
3	dataEncipherment	Clear	Clear	Clear	Clear
4	keyAgreement	Clear	Clear	Clear	Clear
5	keyCertSign	Set	Clear	Clear	Clear
6	CRLSign	Set	Clear	Clear	Clear
7	encipherOnly	Clear	Clear	Clear	Clear
8	decipherOnly	Clear	Clear	Clear	Clear

WTLS Certificates and certain wireless application CA Certificates are not X.509 Version 3 Certificates and thus do not contain a KeyUsage extension.

mtnlTrustLine PKI participants, including CAs and Sub-CAs, RAs, and End User Subscribers, shall protect their own private keys by using a trustworthy system and shall take all necessary precautions to prevent the loss, disclosure, modification, or unauthorized use of such private keys.

mtnlTrustLine shall perform all cryptographic operations with its own CA/Sub-CA private keys and client Sub-CA private keys on hardware cryptographic modules rated at a minimum of FIPS 140-1 level 3.

mtnlTrustLine shall require all RAs (mtnlTrustLine as well as non-mtnlTrustLine) to perform all cryptographic operations with their own private keys on hardware cryptographic modules rated at a minimum of FIPS 140-1 level 1 or equivalent.

End User Subscribers have the option of protecting their private keys in a smart card or other hardware token. mtnlTrustLine shall recommend that all End User Subscribers use hardware cryptographic modules rated at a minimum of FIPS 140-1 level 1 or equivalent.

6.2.2 Private Key ‘n out of m’ Multi-Person Control

mtnlTrustLine shall implement multi-person control to protect the activation data needed to activate CA/Sub-CA private keys within the mtnlTrustLine PKI.

mtnlTrustLine shall use ‘secret sharing’ to split the private key or activation data needed to operate the private key into separate parts called ‘secret shares’. Each ‘secret share’ shall be held by distinct mtnlTrustLine trusted personnel (custodian). Some threshold number of secret shares (n) out of the total number of secret shares (m) shall be required to operate the private key. mtnlTrustLine shall also use secret sharing to protect the activation data needed to activate private keys located at its disaster recovery site.

mtnlTrustLine shall implement secret sharing using the values for threshold and total number of s