SafeScrypt Certification Practice Statement

SafeScrypt Certification Practice Statement Version 2.1 Effective Date: August 08 th, 2004 SafeScrypt Ltd 2 nd Floor, Tidel Park, #4, Canal Bank Road Taramani, Chennai 600113 Tel: +91-44-2254 0770 Fax: +91-44-2254 0771

SafeScrypt Certification Practice Statement This Certificate Practice Statement has been prepared based on the Certification Practice Statement of VeriSign Inc, USA Trademark Notices SafeScrypt is the trade name, trademark & service mark of SafeScrypt Ltd. VeriSign and Managed PKI are registered marks of VeriSign, Inc. The VeriSign logo, VeriSign Trust Network, and Go Secure! are trade names, trademarks and service marks of VeriSign, Inc. Other trademarks and service marks in this document are the property of their respective owners. Without limiting the rights reserved above, and except as licensed below, no part of this publication may be reproduced, stored in or introduced into a retrieval system, or transmitted, in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), without prior written permission of SafeScrypt, VeriSign, Inc or respective owners of the intellectual property rights (hereinafter referred to as owners ). Notwithstanding the above, permission is granted to reproduce and distribute this SafeScrypt Certification Practice Statement on a nonexclusive, royalty-free basis, provided that (i) the foregoing copyright notice and the beginning paragraphs are prominently displayed at the beginning of each copy, and (ii) this document is accurately reproduced in full, complete with attribution of the document to the owners. Requests for any other permission to reproduce this SafeScrypt Certification Practice Statement (as well as requests for copies from SafeScrypt) must be addressed to SafeScrypt Ltd 2nd Floor, Tidel Park, #4, Canal Bank Road Taramani, Chennai 600113 Tel: +91-44-2254 0770 Fax: +91-44-2254 0777 Email: practices@safescrypt.com Acknowledgement SafeScrypt acknowledges the assistance of many reviewers of the document specializing in diverse areas of business, law, policy, and technology.

TABLE OF CONTENTS 1. Introduction 1 1.0 Services offered by SafeScrypt:... 1 1.0.1 Certifying Authority (CA)... 1 1.0.2 Components of the SafeScrypt Public Hierarchy... 2 1.0.3 The Certificate Policy or CP... 4 1.1 Overview... 5 1.1.1 Policy Overview... 8 1.1.2 SafeScrypt s Service Offerings... 15 1.2 Identification... 18 1.3 Community and Applicability... 18 1.3.1 Certifying Authority and Hierarchy... 18 1.3.2 Registration Authorities... 19 1.3.3 End Entities... 19 1.3.4 Applicability... 21 1.4 Contact Details... 22 1.4.1 Specification Administration Organization... 22 1.4.2 Contact Person... 23 1.4.3 Person Determining CPS Suitability for the Policy... 23 2. General Provisions 23 2.1 Obligations... 23 2.1.1 CA Obligations... 23 2.1.2 RA Obligations... 23 2.1.3 Subscriber Obligations... 24 2.1.4 Relying Party Obligations... 24 2.1.5 Repository Obligations... 25 2.2 Liability... 26 2.2.1 Certifying Authority Liability... 26 2.2.2 Registration Authority Liability... 28 2.2.3 Subscriber Liability... 28 2.2.4 Relying Party Liability... 29 2.3 Financial Responsibility... 29 2.3.1 Indemnification by Subscribers and Relying Parties... 29 2.3.2 Fiduciary Relationships... 30 2.3.3 Administrative Processes... 30 2.4 Interpretation and Enforcement... 30 2.4.1 Governing Law... 30 2.4.2 Severability, Survival, Merger, Notice... 30 2.4.3 Dispute Resolution Procedures... 31 2.5 Fees... 31 2.5.1 Certificate Issuance or Renewal Fees... 31 2.5.2 Certificate Access Fees... 31 2.5.3 Revocation or Status Information Access Fees... 31 2.5.4 Fees for Other Services Such as Policy Information... 32 - ii -

2.5.5 Refund Policy... 32 2.6 Publication and Repository... 32 2.6.1 Publication of CA Information... 32 2.6.2 Frequency of Publication... 33 2.6.3 Access Controls... 33 2.6.4 Repositories... 34 2.7 Compliance Audit... 34 2.7.1 Frequency of Entity Compliance Audit... 34 2.7.2 Identity/ Qualifications of Auditor... 34 2.7.3 Auditor s Relationship to Audited Party... 35 2.7.4 Topics Covered by Audit... 35 2.7.5 Actions Taken as a Result of Deficiency... 35 2.7.6 Communications of Results... 35 2.8 Confidentiality and Privacy... 35 2.8.1 Types of Information to be Kept Confidential and Private... 35 2.8.2 Types of Information Not Considered Confidential or Private... 36 2.8.3 Disclosure of Certificate Revocation/Suspension Information... 36 2.8.4 Release to Law Enforcement Officials... 36 2.8.5 Release as Part of Civil Discovery... 36 2.8.6 Disclosure Upon Owner s Request... 36 2.8.7 Other Information Release Circumstances... 36 2.9 Intellectual Property Rights... 36 2.9.1 Property Rights in Certificates and Revocation Information... 36 2.9.2 Property Rights in the CPS... 37 2.9.3 Property Rights in Names... 37 2.9.4 Property Rights in Keys and Key Material... 37 3. Identification and Authentication 37 3.1 Initial Registration... 37 3.1.1 Types of Names... 37 3.1.2 Need for Names to be Meaningful... 41 3.1.3 Rules for Interpreting Various Name Forms... 41 3.1.4 Uniqueness of Names... 41 3.1.5 Name Claim Dispute Resolution Procedure... 41 3.1.6 Recognition, Authentication, and Role of Trademarks... 41 3.1.7 Method to Prove Possession of Private Key... 41 3.1.8 Authentication of Organization Identity... 42 3.1.9 Authentication of Individual Identity... 43 3.2 Routine Rekey and Renewal... 46 3.2.1 Routine Rekey and Renewal for End-User Subscriber Certificates... 47 3.2.2 Routine Rekey and Renewal for technical & sub CA Certificates... 48 3.3 Rekey After Revocation... 48 3.4 Revocation Request... 49 4. Operational Requirements 50 4.1 Certificate Application... 50 4.1.1 Certificate Applications for End-User Subscriber Certificates... 50 - iii -

4.1.2 Certificate Applications for technical & sub CA, RA, Infrastructure and Employee Certificates... 51 4.2 Certificate Issuance... 52 4.2.1 Issuance of End-User Subscriber Certificates... 52 4.2.2 Issuance of sub CA, RA and Infrastructure Certificates... 52 4.3 Certificate Acceptance... 53 4.4 Certificate Suspension and Revocation... 53 4.4.1 Circumstances for Revocation... 53 4.4.2 Who Can Request Revocation... 54 4.4.3 Procedure for Revocation Request... 55 4.4.4 Revocation Request Grace Period... 56 4.4.5 Circumstances for Suspension... 56 4.4.6 Who Can Request Suspension... 56 4.4.7 Procedure for Suspension Request... 56 4.4.8 Limits on Suspension Period... 56 4.4.9 CRL Issuance Frequency... 56 4.4.10 Certificate Revocation List Checking Requirements... 56 4.4.11 On-Line Revocation/Status Checking Availability... 56 4.4.12 On-Line Revocation Checking Requirements... 57 4.4.13 Other Forms of Revocation Advertisements Available... 57 4.4.14 Checking Requirements for Other Forms of Revocation Advertisements... 57 4.4.15 Special Requirements Regarding Key Compromise... 57 4.5 Security Audit Procedures... 57 4.5.1 Types of Events Recorded... 57 4.5.2 Frequency of Processing Log... 58 4.5.3 Retention Period for Audit Log... 58 4.5.4 Protection of Audit Log... 58 4.5.5 Audit Log Backup Procedures... 58 4.5.6 Audit Collection System... 58 4.5.7 Notification to Event-Causing Subject... 59 4.5.8 Vulnerability Assessments... 59 4.6 Records Archival... 59 4.6.1 Types of Events Recorded... 59 4.6.2 Retention Period for Archive... 59 4.6.3 Protection of Archive... 60 4.6.4 Archive Backup Procedures... 60 4.6.5 Requirements for Time-Stamping of Records... 60 4.6.6 Procedures to Obtain and Verify Archive Information... 60 4.7 Key Changeover... 60 4.8 Disaster Recovery and Key Compromise... 61 4.8.1 Corruption of Computing Resources, Software, and/or Data... 61 4.8.2 Disaster Recovery... 61 4.8.3 Key Compromise... 62 4.9 CA Termination... 62 5. Physical, Procedural, and Personnel Security Controls 63 5.1 Physical Controls... 63 - iv -

5.1.1 Site Location and Construction... 63 5.1.2 Physical Access... 64 5.1.3 Power and Air Conditioning... 65 5.1.4 Water Exposures... 65 5.1.5 Fire Prevention and Protection... 65 5.1.6 Media Storage... 65 5.1.7 Waste Disposal... 65 5.1.8 Off-Site Backup... 65 5.2 Procedural Controls... 65 5.2.1 Trusted Roles... 65 5.2.2 Number of Persons Required Per Task... 66 5.2.3 Identification and Authentication for Each Role... 66 5.3 Personnel Controls... 67 5.3.1 Background, Qualifications, Experience, and Clearance Requirements... 67 5.3.2 Background Check Procedures... 67 5.3.3 Training Requirements... 68 5.3.4 Retraining Frequency and Requirements... 68 5.3.5 Job Rotation Frequency and Sequence... 68 5.3.6 Sanctions for Unauthorized Actions... 68 5.3.7 Contracting Personnel Requirements... 68 5.3.8 Documentation Supplied to Personnel... 68 6. Technical Security Controls 69 6.1 Key Pair Generation and Installation... 69 6.1.1 Key Pair Generation... 69 6.1.2 Private Key Delivery to Entity... 69 6.1.3 Public Key Delivery to Certificate Issuer... 70 6.1.4 CA Public Key Delivery to Users... 70 6.1.5 Key Sizes... 70 6.1.6 Public Key Parameters Generation... 70 6.1.7 Parameter Quality Checking... 70 6.1.8 Hardware/Software Key Generation... 70 6.1.9 Key Usage Purposes... 70 6.1.10 Standards for Cryptographic Modules... 71 6.1.11 Private Key (n out of m) Multi-Person Control... 71 6.1.12 Private Key Escrow... 72 6.1.13 Private Key Backup... 73 6.1.14 Private Key Archival... 73 6.1.15 Private Key Entry into Cryptographic Module... 73 6.1.16 Method of Activating Private Key... 73 6.1.17 Method of Deactivating Private Key... 76 6.1.18 Method of Destroying Private Key... 76 6.2 Other Aspects of Key Pair Management... 76 6.2.1 Public Key Archival... 76 6.2.2 Usage Periods for the Public and Private Keys... 76 6.3 Activation Data... 78 6.3.1 Activation Data Generation and Installation... 78 - v -

6.3.2 Activation Data Protection... 78 6.3.3 Other Aspects of Activation Data... 79 6.4 Computer Security Controls... 79 6.4.1 Specific Computer Security Technical Requirements... 79 6.5 Life Cycle Technical Controls... 79 6.5.1 System Development Controls... 79 6.5.2 Security Management Controls... 80 6.5.3 Life Cycle Security Ratings... 80 6.6 Network Security Controls... 80 6.7 Cryptographic Module Engineering Controls... 80 7. Certificate and CRL Profile 80 7.1 Certificate Profile... 80 7.1.1 Version Number(s)... 81 7.1.2 Certificate Extensions... 81 7.1.3 Algorithm Object Identifiers... 83 7.1.4 Name Forms... 83 7.1.5 Name Constraints... 83 7.1.6 Certificate Policy Object Identifier... 83 7.1.7 Usage of Policy Constraints Extension... 83 7.1.8 Policy Qualifiers Syntax and Semantics... 83 7.1.9 Processing Semantics for the Critical Certificate Policy Extension... 84 7.2 CRL Profile... 84 7.2.1 Version Number(s)... 84 7.2.2 CRL and CRL Entry Extensions... 84 8. Specification Administration 84 8.1 Specification Change Procedures... 84 8.1.1 Items that Can Change Without Notification... 85 8.1.2 Items that Can Change with Notification... 85 8.1.3 Changes Requiring Changes in the Certificate Policy OID or CPS Pointer... 86 8.2 Publication and Notification Policies... 86 8.2.1 Items Not Published in the CPS... 86 8.2.2 Distribution of the CPS... 86 8.3 CPS Approval Procedures... 86 Acronyms and Definitions 86 Table of Acronyms... 86 Definitions... 87 - vi -

1. Introduction This document is the SafeScrypt Certification Practice Statement ( CPS ). 1 It states the practices that SafeScrypt employs in providing certification services that include, but are not limited to, issuing, managing, revoking, and renewing certificates in accordance with the specific requirements of the Indian Information Technology Act 2000 (IT Act 2000) and rules and regulations framed therein. Please Note: The capitalized terms in this CPS are defined terms with specific meanings. Please see Section 9 for a list of definitions. SafeScrypt Ltd (SafeScrypt), a subsidiary of Sify Limited (SIFY), is an organisation promoted to focus exclusively on Internet Trust and Security Services and Solutions (see http://www.safescrypt.com). As part of these services, SafeScrypt offers Managed PKI and Certifying Authority (CA) Services. In India, SafeScrypt has been awarded a CA license by the Controller of Certifying Authorities (CCA) (see http://www.cca.gov.in) appointed under the IT Act 2000. Under this CA license, SafeScrypt offers a range of Managed CA Services that enable individuals and organizations to obtain Digital Certificates that qualify as Digital Signature Certificates under the IT Act 2000. SafeScrypt services and solutions offer individuals and organizations the choices of becoming sub CA s, Registration Authorities (RA s) or Subscribers thus catering to varied market requirements. SafeScrypt has entered into a strategic alliance with VeriSign Inc (VeriSign), a leading global provider of trusted infrastructure services to web sites, enterprises, electronic commerce service providers, and individuals. SafeScrypt is therefore an Affiliate of VeriSign for India and the surrounding countries. As a VeriSign Affiliate, SafeScrypt uses VeriSign s technology, best practices and expertise in this field to offer Best of Breed solutions to its customers. SafeScrypt is also an integral part of the VeriSign Trust Network SM ( VTN ), which is a global Public Key Infrastructure ( PKI ) that provides Digital Certificates ( Certificates ) for both wired and wireless applications. The VTN accommodates a large, public, and widely distributed community of users with diverse needs for communications and information security. VeriSign is one of the service providers within the VTN, together with SafeScrypt and a global network of affiliates ( Affiliates ) throughout the world. 1.0 Services offered by SafeScrypt: SafeScrypt operates a complex PKI hierarchy to offer a wide range of Trust services. Depending on the Trust requirements of its customers, parts of this hierarchy may be Cross Certified with other Certifying Authorities operating in India and / or outside India. 1.0.1 Certifying Authority (CA) The term Certifying Authority is used in several contexts globally. This section clarifies its use in this CPS. 1 Internal cross-references to CPS sections (i.e., in the form of CPS ) are references to sections of this document. Other references to the term CPS refer to a certification practice statement, which may include this document or the CPS' of other Certifying Authorities,. See CPS 9 (Definitions). 1

When the term Certifying Authority or CA is used in a standalone manner in this CPS, it refers to SafeScrypt as the entity that holds the CA license from the Controller of Certifying Authorities (CCA), Govt. of India. In the PKI world, organizations that provide CA services and issue digital certificates usually issue several classes of certificates. Each class is usually associated with a different level of trust. In order to differentiate between certificates corresponding to each of these classes, the organisation usually creates different standalone key pairs from which a digital certificate of a particular class is issued. For these key pairs to be able to function as originators of trust and issue digital certificates, the public keys of these key pairs need to be digitally signed by their own private keys (called self signed ) or by the private key of any other entity whom they wish to derive their trust from. As per globally adopted and accepted PKI terminology, these key pairs are also thus called Certifying Authorities or CA s. In order to differentiate these key pairs from the legal entity SafeScrypt as the licensed Certifying Authority, this CPS uses the term technical CA s to describe these key pairs. Further, there can be several technical CA s issuing the same classes of certificates also this being usually done when further distinctions for technical or operational reasons are required by users, especially organizational users and their applications. These technical CA s can further create a hierarchy under them, containing sub CA s, to meet with varying technical and operational requirements of user organizations and subscribers. It is to be noted that: 1. All technical CA s come under the single SafeScrypt ambit and under one single CA license. Therefore, each of these technical CA s and the sub CA s under them in their hierarchy derive their legal licensed status in India from the SafeScrypt CA license. 2. The CCA digitally signs the public keys of all the technical CA s thereby ensuring the authenticity of each of the technical CA s that can be verified by any entity. 3. All responsibilities, including liabilities associated with any certificate under any class or any sub CA under any class of any SafeScrypt hierarchy ultimately rests with SafeScrypt. SafeScrypt may, in turn, pass on this responsibility, entirely on in parts, via various contractual agreements to other entities such as sub CA s, RA s, customers, partners, etc. 1.0.2 Components of the SafeScrypt Public Hierarchy 1.0.2.1 SafeScrypt India Public Hierarchy: The SafeScrypt India Public Hierarchy refers to that part of the SafeScrypt CA hierarchy that uses SafeScrypt self-signed technical CA s as the trust anchors. This gives users flexibility in implementation of customer-specific design requirements. Under this hierarchy, the following Classes of Certificates are available: India Class A India Class B India Class C 2

1.0.2.2 SafeScrypt India-RCAI Public Hierarchy: The SafeScrypt India-RCAI Public Hierarchy refers to that CA hierarchy from SafeScrypt that is cross certified with the Root CA Authority of India (RCAI). This root is envisaged to serve as the basis for cross-certification amongst various licensed CA s in India for consumer applications. Under this hierarchy, the following Classes of Certificates are available: India-RCAI Class 1 India-RCAI Class 2 India-RCAI Class 3 1.0.2.3 SafeScrypt VeriSign Trust Network Public Hierarchy: The VTN or the VeriSign Trust Network hierarchy refers to that CA hierarchy from SafeScrypt that is cross certified with the VeriSign Trust Network. This means that certificates issued by the sub CA s under this hierarchy enjoy instant global interoperability because the VTN roots are embedded in most of the major applications deployed worldwide. Under this hierarchy, the following Classes of Certificates are available: VTN Class 1 VTN Class 2 VTN Class 3 The user can avail of certificates from one or more of the above hierarchy and classes depending on requirements. The SafeScrypt Public Hierarchy components and roots are explained in detail in the rest of the CPS. Each component hierarchy is governed by the SafeScrypt CPS and its own unique policies and requirements hence each of these are outlined separately in each section /subsection of this CPS. The individual Subscribers and Relying Parties are required to take cognizance of the sections / subsections relevant to them Under each component hierarchy, SafeScrypt also offers the following arrangements: sub CA: Under this scheme, a technical CA with its own set of root keys is specially created for the customer (usually an organization, community or a Closed User Group (CUG)). This technical CA is signed by one of the SafeScrypt technical CA s from the specific hierarchy and class chosen by the customer, thus making it a sub CA under that specific SafeScrypt hierarchy and class. The customer can create several such sub CA s under different hierarchy and classes, depending on usage requirements. To further add flexibility to its offerings, SafeScrypt also enables the customer to further create sub CA s under its sub CA, as long as the same are used by and for its own affiliated entities. RA (Registration Authority) 2 : Under this scheme, a customer can choose to be an RA under the appropriate SafeScrypt sub CA. Once again, the choice of hierarchy and class is available to the customer. Refer CPS 1.1.2.1.1 for further details on the above. 2 See Definitions 3

IMPORTANT NOTE: (1). This CPS (as amended from time to time) is intended to be an allencompassing CPS that covers all the hierarchy components, classes, certificate types etc. However, not all services and products may be commercially available at all points in time. SafeScrypt reserves the sole right to decide when and to whom to offer which type of service. (2). Some of the certificates offered may not be Digital Signature Certificates recognised under the Indian IT Act 2000. These certificates include, among others, those digital certificates used for encryption, IPSec certificates and those certificates issued to devices. Please note that while some of these certificates may belong to an existing class by virtue of the level of validation done prior to issue of the certificate, these would not qualify under the Act. (3). SafeScrypt reserves the right and discretion not to accept the request for issue of any Certificate or the class of the Certificates requested for. The verification and validation processes for different hierarchy and classes will be at the discretion of SafeScrypt. For example such processes for SafeScrypt VeriSign Trust Network Public Hierarchy may be more extensive and detailed. (4). In the eventuality of any dispute arising with respect to the CA operations of SafeScrypt VTN Class 2 CA where the CCA is also made a party to, SafeScrypt has agreed to indemnify and hold harmless the CCA and the Government of India against any claim, losses or other prejudice to which CCA or the Government of India may be subjected and CCA and Government of India shall not have any exposure financial or otherwise. 1.0.3 The Certificate Policy or CP The Certificate Policy or CP is the principal statement of policy governing a PKI hierarchy. It establishes the business, legal, and technical requirements for approving, issuing, managing, using, revoking, and renewing Digital Certificates within the PKI hierarchy and providing associated trust services. 1.0.3.1 The India Public Hierarchy and the India CP The SafeScrypt India Public Hierarchy is based on the India Certificate Policy ( India CP ). The requirements established via this CP protect the security and integrity of the India Public Hierarchy and apply to all India Public Hierarchy Participants. More information concerning the India CP is available at http://www.safescrypt.com/cp. 1.0.3.2 The India-RCAI Public Hierarchy and the RCAI CP The SafeScrypt India-RCAI Public Hierarchy is based on the RCAI Certificate Policy ( RCAI CP ). More information concerning the RCAI CP is available at http://www.safescrypt.com/cp. 1.0.3.3 The VTN Public Hierarchy & the VTN CP The SafeScrypt VTN hierarchy being cross certified with the Global VeriSign Trust Network, it follows the operating norms and policies prescribed by the VTN Certificate Policy ( CP ). These requirements established via this CP, called the VTN Standards, protect the security and integrity of the VTN, apply to all VTN Participants, and thereby provide assurances of 4

uniform trust throughout the VTN. More information concerning the VTN and VTN Standards is available in the VTN CP. 3 VeriSign and each Affiliate have authority over a portion of the VTN. The portion of the VTN controlled by VeriSign or SafeScrypt or another Affiliate is called its Subdomain of the VTN. An Affiliate s Subdomain consists of the portion of the VTN under its control. SafeScrypt s Subdomain includes entities subordinate to it such as its Customers, Subscribers, and Relying Parties. SafeScrypt, VeriSign and each of the Affiliates have a CPS that governs its Subdomain within the VTN. While the CP sets forth requirements that VTN Participants must meet, this CPS describes how SafeScrypt meets these requirements within SafeScrypt s Subdomain of the VTN, which is primarily located in India. More specifically, this CPS describes the practices that SafeScrypt employs for: securely managing the core infrastructure that supports the VTN, and issuing, managing, revoking, and renewing VTN Certificates within SafeScrypt s Subdomain of the VTN, in accordance with the requirements of the CP and its VTN Standards. 4 1.1 Overview This CPS is specifically applicable to: SafeScrypt s technical CA s and the sub CA s of Managed PKI Customers 5 which issues Certificates within the SafeScrypt Public Hierarchy comprising of the: o SafeScrypt India Public Hierarchy o SafeScrypt India-RCAI Public Hierarchy o SafeScrypt VTN Public Hierarchy With reference to the VTN hierarchy, the CPS, more generally, also governs the use of VTN services within SafeScrypt s Subdomain of the VTN by all individuals and entities within SafeScrypt s Subdomain (collectively, SafeScrypt Subdomain Participants ). This CPS describes how SafeScrypt meets the CP requirements for each VTN Class within its Subdomain. Thus, the CPS, as a single document, covers practices and procedures concerning the issuance and management of all Certificate Classes within each hierarchy of SafeScrypt. As mentioned at the relevant parts, some of the certificates offered are outside the purview of the 3 The CP is published in electronic form within the VeriSign Repository at https://www.verisign.com/cp. VeriSign also makes the CP available in Adobe Acrobat PDF or Word format upon request sent to CPrequests@verisign.com. The CP is available in paper form from the VeriSign Trust Network Policy Management Authority ( PMA ) upon requests sent to: VeriSign, Inc., 487 East Middlefield Road, Mountain View, CA 94043 USA, Attn: Practices Development CP. 4 Although VeriSign CAs certify the CAs of Affiliates, the practices relating to an Affiliate are covered in the Affiliate s CPS, rather than this CPS. 5 The Managed PKI Service was formerly known as OnSite. All references to OnSite in this CPS have been changed to Managed PKI. Server OnSite has been changed to Managed PKI for SSL and Global Server OnSite have been changed to Managed PKI for SSL Premium Edition. Customers may still see references to OnSite in other Managed PKI documentation or URLs. The OnSite Service itself has not changed other than the name 5

IT Act 2000. As discussed in Section 1.0.2, these certificates include those digital certificates performing the encryption function, IPSec certificates and those certificates issued to devices. (a) Role of the SafeScrypt CPS and Other Practices Documents This CPS applies to sub CAs within the SafeScrypt Public Hierarchy comprising of SafeScrypt India Public Hierarchy, SafeScrypt India-RCAI Public Hierarchy, and SafeScrypt Subdomain of the VTN Hierarchy. The CPS describes, among other things: Obligations of Certification Authorities, Registration Authorities, Subscribers, and Relying Parties within the SafeScrypt Public Hierarchy, Legal matters that are covered in Subscriber Agreements and Relying Party Agreements within the SafeScrypt Public Hierarchy, Audit and related security and practices reviews that SafeScrypt and SafeScrypt Participants within the SafeScrypt Public Hierarchy, Methods used within the SafeScrypt Public Hierarchy to confirm the identity of Certificate Applicants for each Class of Certificate, Operational procedures for Certificate lifecycle services undertaken in the SafeScrypt Public Hierarchy: Certificate Applications, issuance, acceptance, revocation, and renewal, Operational security procedures for audit logging, records retention, and disaster recovery used within the SafeScrypt Public Hierarchy, Physical, personnel, key management, and logical security practices of the SafeScrypt Public Hierarchy, Certificate and Certificate Revocation List content within the SafeScrypt Public Hierarchy, and Administration of the CPS, including methods of amending it. The CPS, however, is only one of a set of documents relevant to the SafeScrypt Public Hierarchy. These other documents include: Ancillary security and operational documents that supplement the CPS by providing more detailed requirements, such as: - The SafeScrypt Security Policy which sets forth the Security Principles governing the SafeScrypt Public Key Infrastructure - The Security and Audit Requirements Guide, which describes detailed requirements for SafeScrypt concerning personnel, physical, telecommunications, logical, and cryptographic key management security, - The Enterprise Security Guide, which describes detailed requirements for Managed PKI Customers concerning personnel, physical, telecommunications, logical, and cryptographic key management security, and - Key Ceremony Reference Guide, which presents detailed key management operational requirements. Ancillary agreements imposed by SafeScrypt. These agreements would bind Customers, Subscribers, and Relying Parties of SafeScrypt. Among other things, the agreement(s) flow down the specific standards of each component hierarchy to the hierarchy participants and, in some cases, state specific practices for how they must meet the particular hierarchy s Standards. 6

In many instances, the CPS refers to these ancillary documents for specific, detailed practices implementing specific standards where including the specifics in the CPS could compromise the security of the SafeScrypt Public Hierarchy Table 1 is a matrix showing various practices documents, whether they are publicly available, and their locations. The list in Table 1 is not intended to be exhaustive. Note that documents not expressly made public are confidential to preserve the security of the SafeScrypt Public Hierarchy. Documents Status Where Available to the Public Ancillary Security and Operational Documents SafeScrypt Security Policy Confidential N/A Security and Audit Confidential N/A Requirements Guide Key Ceremony Reference Confidential N/A Guide Managed PKI Public https://www.safescrypt.com/enterprise/library/index.html Administrator s Handbook Managed PKI Key Public https://wwwsafescrypt.com/enterprise/library/index.html Management Service Administrator s Guide Enterprise Security Guide Confidential N/A Public hierarchy-specific Documents SafeScrypt Certification Practice Statement Public SafeScrypt Repository per CPS 2.6.1. See https://www.safescrypt.com/repository SafeScrypt s ancillary agreements (Managed PKI Agreements, Subscriber Agreements, and Relying Party Agreements) Public, including Managed PKI Lite agreements, but not Managed PKI agreements, which are SafeScrypt Repository per CPS 2.6.1. See https://www.safescrypt.com/repository confidential Public VeriSign Trust Network Certificate Policies Table 1 Availability of Practices Documents VeriSign Repository per CP 8.2.2. See https://www.verisign.com/repository (b) Background Concerning Digital Certificates and the various SafeScrypt Public Hierarchy This CPS assumes that the reader is generally familiar with Digital, Signature, PKI, and the SafeScrypt Public Hierarchy. If not, SafeScrypt advises that the reader obtain some training in the use of public key cryptography and public key infrastructure as implemented in the SafeScrypt Public Certifying Authority Services. General educational and training information is accessible from SafeScrypt at http://www.safescrypt.com/training. Also, specifically in case of the VTN, a brief summary of the roles of the different VTN Participants is set forth in Section 1.1(b) of the VeriSign CP. (c) Compliance with Applicable Standards The practices specified in this CPS have been designed to meet the requirements of the Indian IT Act 2000, its associated Rules and Regulations as well as generally accepted and developing industry standards related to the operation of CAs. 7

The structure of this CPS generally corresponds to the Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework, known as RFC 2527 of the Internet Engineering Task Force, an Internet standards body. The RFC 2527 framework has become a standard in the PKI industry. This CPS conforms to the RFC 2527 framework in order to make policy mapping and comparisons, assessment, and interoperation easier for persons using or considering using SafeScrypt services. 1.1.1 Policy Overview As discussed in CPS 1.0.1, SafeScrypt operates a complex PKI Hierarchy with distinct classes for both the wired and wireless Internet and other networks. Each level, or class, of Certificate provides specific functionality, cross certification and security features and corresponds to a specific level and nature of trust. Customers choose which Classes of Certificates they need. The relevant CP describes the various classes of certificates under each component of the SafeScrypt hierarchy in detail. This section summarizes the Certificate Classes offered under the various components of the SafeScrypt Public Hierarchy. a. The SafeScrypt India Public Hierarchy: India Class A Certificates: They offer the lowest level of assurances within the India hierarchy. They are individual Certificates, whose validation procedures are based on assurances that the Subscriber s distinguished name is unique and unambiguous within the CA s Subdomain and that a certain e-mail address is associated with a public key. They are appropriate for digital signatures, encryption, and access control for non-commercial or low-value transactions where proof of identity is unnecessary. India Class A certificates do not validate the identity of the subscriber and therefore are not Persona-verified Digital Signature Certificates India Class B Certificates: They offer a medium level of assurances in comparison with the other two Classes in this hierarchy. Again, they are individual Certificates. In addition to the India Class A validation procedures, India Class B validation procedures add procedures based on a comparison of information submitted by the Certificate applicant against information in business records or databases or the database of a SafeScrypt -approved identity proofing service. SafeScrypt reserves the sole right to approve the database or record being used for this validation. They can be used for digital signatures, encryption, and access control, including as proof of identity in transactions. This class is suitable for most business-grade transactions India Class C Certificates: This class of certificates provides the highest level of assurances within the India hierarchy. India Class C Certificates are issued to individuals, organizations, and Administrators for CAs and RAs. India Class C individual Certificates may be used for digital signatures, encryption, and access control, including as proof of identity, in high-value transactions. India Class C individual Certificates provide assurances of the identity of the Subscriber based on the personal (physical) presence of the Subscriber before a person (approved by 8

SafeScrypt) that confirms the identity of the Subscriber using, at a minimum, a wellrecognized form of government-issued identification and one other identification credential. SafeScrypt reserves the right to decide which specific forms of identification would be acceptable for validation. In the absence of a government-issued identification, SafeScrypt may prescribe alternate methods of validation. Other India Class C organizational Certificates are issued to devices to provide authentication; message, software, and content integrity; and confidentiality encryption. India Class C organizational Certificates provide assurances 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. b. The SafeScrypt India-RCAI Public Hierarchy: India-RCAI Class 1 Certificates: They offer the lowest level of assurances within the SafeScrypt India--RCAI Public hierarchy. They are individual Certificates, whose validation procedures are based on assurances that the Subscriber s distinguished name is unique and unambiguous within the sub CA s Subdomain and that a certain e-mail address is associated with a public key. They are appropriate for digital signatures, encryption, and access control for non-commercial or low-value transactions where proof of identity is unnecessary. SafeScrypt India-RCAI Class1 certificates do not validate the identity of the subscriber and therefore are not Persona-verified Digital Signature Certificates India-RCAI Class2 Certificates: They offer a medium level of assurances in comparison with the other two Classes in this hierarchy. Again, they are individual Certificates. In addition to the India-RCAI Class 1 validation procedures, India--RCAI Class 2 validation procedures add procedures based on a comparison of information submitted by the Certificate applicant against information in business records or databases or the database of a SafeScrypt-approved identity proofing service. SafeScrypt reserves the sole right to approve the database or record being used for this validation. They can be used for digital signatures, encryption, and access control, including as proof of identity in transactions. This class is suitable for most business-grade transactions India-RCAI Class 3 Certificates: This class of certificates provides the highest level of assurances within the India-RCAI hierarchy. India-RCAI Class 3 Certificates are issued to individuals, organizations, and Administrators for CAs and RAs. India-RCAI Class 3 individual Certificates may be used for digital signatures, encryption, and access control, including as proof of identity, in high-value transactions. India-RCAI Class 3 individual Certificates provide assurances of the identity of the Subscriber based on the personal (physical) presence of the Subscriber before a person (approved by SafeScrypt) that confirms the identity of the Subscriber using, at a minimum, a well-recognized form of government-issued identification and one other identification credential. SafeScrypt reserves the right to decide which specific forms of identification would be acceptable for validation. In the absence of a government-issued identification, SafeScrypt may prescribe alternate methods of validation. 9

Other India-RCAI Class 3 organizational Certificates are issued to devices to provide authentication; message, software, and content integrity; and confidentiality encryption. India-RCAI Class 3 organizational Certificates provide assurances 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. c. The SafeScrypt VTN Public Hierarchy: VTN Class 1 Certificates: VTN Class 1 Certificates offer the lowest level of assurances within SafeScrypt s VTN Subdomain. They are individual Certificates, whose validation procedures are based on assurances that the Subscriber s distinguished name is unique and unambiguous within the sub CA s Subdomain and that a certain e-mail address is associated with a public key. They are appropriate for digital signatures, encryption, and access control for non-commercial or low-value transactions where proof of identity is unnecessary. VTN Class1 certificates do not validate the identity of the subscriber and therefore are not Persona-verified Digital Signature Certificates. VTN Class 2 Certificates: VTN Class 2 Certificates offer a medium level of assurances in comparison with the other two Classes. Again, they are individual Certificates. In addition to the VTN Class 1 validation procedures, VTN Class 2 validation procedures add procedures based on a comparison of information submitted by the Certificate applicant against information in business records or databases or the database of a SafeScrypt -approved identity proofing service. They can be used for digital signatures, encryption, and access control, including as proof of identity in medium-value transactions. VTN Class 3 Certificates: VTN Class 3 Certificates provide the highest level of assurances within SafeScrypt s VTN Subdomain. VTN Class 3 Certificates are issued to individuals, organizations, and Administrators for CAs and RAs. VTN Class 3 individual Certificates may be used for digital signatures, encryption, and access control, including as proof of identity, in high-value transactions. VTN Class 3 individual Certificates provide assurances of the identity of the Subscriber based on the personal (physical) presence of the Subscriber before a person duly approved by SafeScrypt that confirms the identity of the Subscriber using, at a minimum, a well-recognized form of government-issued identification and one other identification credential. Other VTN Class 3 organizational Certificates are issued to devices to provide authentication; message, software, and content integrity; and confidentiality encryption. VTN Class 3 organizational Certificates provide assurances 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 organizational Certificates for servers (Secure Server IDs and Global Server IDs) also provide assurances that the Subscriber is entitled to use the domain name listed in the Certificate Application. 10

Note: In the eventuality of any dispute arising with respect to the CA operations of SafeScrypt VTN Class 2 CA where the CCA is also made a party to, SafeScrypt has agreed to indemnify and hold harmless the CCA and the Government of India against any claim, losses or other prejudice to which CCA or the Government of India may be subjected and CCA and Government of India shall not have any exposure financial or otherwise. Summary of Certificate Classes offered: Table 2 below summarizes the Certificate Classes offered by SafeScrypt. It sets forth the properties of each Certificate class, based on whether they are issued to individuals or organizations, and whether they are offered on a Retail or Managed PKI basis, or issued to Administrators. The specifications for Classes of Certificates set forth the minimum level of assurances provided for each Class. For example, any India-RCAI Class 2 Certificate may be used for digital signatures, encryption, and access control for applications with medium level of assurance. Nonetheless, by contract or within specific environments (such as an intracompany environment), customers are permitted to use validation procedures stronger than the ones prescribed, or use Certificates for higher security applications than the ones described in CPS 1.1.1, 1.3.4.1. Any such usage, however, shall be limited to such entities and subject to CPS 2.2.1.2, 2.2.2.2, and these entities shall be solely responsible for any harm or liability caused by such usage. Class Issued to Services Under Which Certificates are Available 6 SafeScrypt India Public Hierarchy: India Class A India Class B Confirmation of Certificate Applicants Identity (CPS 3.1.8.1, 3.1.9) Individuals Retail Name and e-mail address search to ensure that the distinguished name is unique and unambiguous within the sub CA s Subdomain. Individuals Retail Same as India Class A Retail, plus automated or Administratorinitiated enrolment information check with one or more third-party databases or comparable sources. Applications implemented or contemplated by Users (CPS 1.3.4.1) Modestly enhancing the security of e-mail through confidentiality encryption, digital signatures, and web-based access control, where proof of identity is unnecessary. Applications requiring a low level of assurances in comparison with the other Classes, such as noncommercial web browsing and e- mail. Enhancing the security of e-mail through confidentiality encryption, digital signatures for authentication, and web based access control. Applications 6 Retail Certificates are issued by SafeScrypt, to individuals or organizations applying one by one to SafeScrypt on its web site. Managed PKI Certificates are based on a Certificate Application approved by a Managed PKI Customer that enters into a Managed PKI Agreement with SafeScrypt for the issuance of a certain quantity of Certificates (see CP 1.1.2.1.1). In addition to Retail and Managed PKI Certificates, VTN Certificates are issued, for Administrators of sub CAs and RAs. Administrator Certificates are issued to sub CA or RA Administrators to allow them to perform administrative functions on behalf of the sub CA or RA. 11

Class Issued to Services Under Which Certificates are Available 6 India Class C Managed PKI Confirmation of Certificate Applicants Identity (CPS 3.1.8.1, 3.1.9) Same as India Class A Managed PKI plus checking internal documentation or databases to confirm identity of the Certificate Applicant (e.g., human resources documentation). Individuals Retail Same as India Class A Retail, plus personal presence and check of two or more ID credentials. Organizations Retail Check of third-party database or other documentation showing proof of right to use the organizational name. Validation check by telephone (or comparable procedure) to confirm information in, and authorization of, the Certificate Application. SafeScrypt India-RCAI Public Hierarchy: India- RCAI Class 1 India- RCAI Class 2 Individuals Retail Name and e-mail address search to ensure that the distinguished name is unique and unambiguous within the CA s Subdomain. Individuals Retail Same as India-RCAI Class 1 Retail, plus automated or Administrator-initiated enrolment information check with one or more third-party databases or comparable sources. Applications implemented or contemplated by Users (CPS 1.3.4.1) requiring a medium level of assurances in comparison with the other Classes, such as some individual and intra- and intercompany e-mail, on-line subscriptions, online banking or stock trading, supply chain management & account applications, and password replacement, including as proof of identity for medium-value transactions. Generally used for most Business Grade transactions Enhancing the security of e-mail through confidentiality encryption, digital signatures for authentication, and web based access control. Applications requiring a high level of assurances in comparison with the other Classes, such as some online banking, corporate database access, and exchanging confidential information, including as proof of identity for high-value transactions. Server authentication, confidentiality encryption, and (when communicating with other servers) client authentication; authentication, message integrity; and authentication and integrity of software and other content. Modestly enhancing the security of e-mail through confidentiality encryption, digital signatures, and web-based access control, where proof of identity is unnecessary. Applications requiring a low level of assurances in comparison with the other Classes, such as noncommercial web browsing and e- mail. Enhancing the security of e-mail through confidentiality encryption, digital signatures for authentication, and web based access control. Applications requiring a medium level of 12

Class Issued to Services Under Which Certificates are Available 6 India- RCAI Class 3 Confirmation of Certificate Applicants Identity (CPS 3.1.8.1, 3.1.9) Managed PKI Same as India-RCAI Class 1 Managed PKI plus checking internal documentation or databases to confirm identity of the Certificate Applicant (e.g., human resources documentation). Individuals Retail Same as India-RCAI Class 1 Retail, plus personal presence and check of two or more ID credentials. Organizations Retail Check of third-party database or other documentation showing proof of right to use the organizational name. Validation check by telephone (or comparable procedure) to confirm information in, and authorization of, the Certificate Application SafeScrypt VTN Hierarchy: VTN Class 1 VTN Class 2 Individuals Retail Name and e-mail address search to ensure that the distinguished name is unique and unambiguous within the sub CA s Subdomain. Individuals Retail Same as VTN Class 1 Retail, plus automated or Administratorinitiated enrolment information check with one or more third-party databases or comparable sources. Applications implemented or contemplated by Users (CPS 1.3.4.1) assurances in comparison with the other Classes, such as some individual and intra- and intercompany e-mail, on-line subscriptions, online banking or stock trading, supply chain management & account applications, and password replacement, including as proof of identity for medium-value transactions.. Generally used for most Business Grade transactions Enhancing the security of e-mail through confidentiality encryption, digital signatures for authentication, and web based access control. Applications requiring a high level of assurances in comparison with the other Classes, such as some online banking, corporate database access, and exchanging confidential information, including as proof of identity for high-value transactions. Server authentication, confidentiality encryption, and (when communicating with other servers) client authentication, message integrity; and authentication and integrity of software and other content. Modestly enhancing the security of e-mail through confidentiality encryption, digital signatures, and web-based access control, where proof of identity is unnecessary. Applications requiring a low level of assurances in comparison with the other Classes, such as noncommercial web browsing and e- mail. Enhancing the security of e-mail through confidentiality encryption, digital signatures for authentication, and web based access control. Applications 13

Class Issued to Services Under Which Certificates are Available 6 VTN Class 3 Individuals Organizations Managed PKI Retail Administrators Retail Confirmation of Certificate Applicants Identity (CPS 3.1.8.1, 3.1.9) Same as VTN Class 1 Managed PKI plus checking internal documentation or databases to confirm identity of the Certificate Applicant (e.g., human resources documentation). Same as VTN Class 1 Retail, plus personal presence and check of two or more ID credentials. Specialized confirmation procedures depending upon the type of Administrator. The identity of the Administrator and the organization utilizing the Administrator are confirmed. See also CPS 5.2.3. Check of third-party database or other documentation showing proof of right to use the organizational name. Validation check by telephone (or comparable procedure) to confirm information in, and authorization of, the Certificate Application. In the case of web server Certificates, confirmation that the Certificate Applicant has the right to use the domain name to be placed in the Certificate. Managed PKI Validation of Managed PKI for SSL Customer or Managed PKI for SSL Premium Edition Customer as in Class 3 organizational Retail, plus validation of Managed PKI Administrator. Table 2 - Certificate Properties Affecting Trust Applications implemented or contemplated by Users (CPS 1.3.4.1) requiring a medium level of assurances in comparison with the other Classes, such as some individual and intra- and intercompany e-mail, on-line subscriptions, account applications, and password replacement, including as proof of identity for medium-value transactions. Enhancing the security of e-mail through confidentiality encryption, digital signatures for authentication, and web based access control. Applications requiring a high level of assurances in comparison with the other Classes, such as some online banking, corporate database access, and exchanging confidential information, including as proof of identity for high-value transactions. Administrator functions. Server authentication, confidentiality encryption, and (when communicating with other servers) client authentication (Secure Server ID, Global Server ID Certificates); authentication, message integrity; and authentication and integrity of software and other content. Server authentication, confidentiality encryption, and (when communicating with other properly enabled servers) client authentication (Secure Server ID and Global Server ID). 14