ProDigiSign CPS

Certification Practice Statement
(CPS)
Version 4.0.0
29th June, 2022
OID: 2.16.356.100.1.
2.16.356.100.1.26.2
Professional DigiS
DigiSign Private Limited
Certifying Authority
Office No
No-238 2nd Floor, Patil Plaza, DEEPAK Digitally signed by
DEEPAK KUMAR
KUMAR 11:27:38 +05'30'

Date: 2022.07.13
Near Sarasbaug, Mitra Mandal Chowk,
Swargate, Pune-411009.
Phone: +91 020 49105678 / +91 8657212347

Email: info@prodigisign.com Website: https://prodigisign.com
Version 4.0.0
CERTIFICA
IFICATION PRACTICE STATEMENT
Document Name CPS of ProDigiSign CA

Release Version 4.0.0
Status Release
Issue Date 29.06.2022
Version 4.0.0
Table of Contents
Definitions................................................................
................................................................................................
........................................................... 9
1. Introduction ................................
................................................................................................................................
................................... 12
1.1. Overview of CPS ................................................................................................................................
................................ .................................12
1.2. Identification ................................................................................................................................
................................ .......................................13
1.3. PKI Participants ................................................................................................................................
................................ .................................13
1.3.1. PKI Authorities ................................
................................................................................................................................
.......................................... 13
1.3.2. PKI Services................................
................................................................................................................................
............................................... 14
1.3.3. Registration Authority (RA) and Organizational Registration Authority (ORA) ...................................... ................................ 16
1.3.4. Subscribers ................................................................................................................................
................................ ................................................. 16
1.3.5. Relying Parties ................................
................................................................................................................................
........................................... 16
1.3.6. Applicability ................................................................................................................................
................................ .............................................. 16
1.4. Certificate Usage ................................................................................................................................
................................ .................................17
1.4.1. Appropriate Certificate Usees ................................................................................................
...................................................... 17
1.4.2. Prohibited Certificate Uses................................
................................................................................................
......................................................... 18
1.5. Policy Administration ................................................................................................
................................ .........................................................18
1.5.1. Organization administering stering the ddocument................................................................................................
.................................. 18
1.5.2. Contact Person ................................
................................................................................................................................
........................................... 18
1.5.3. Person Determining Certifica cation Practice Statement Suitability for the Policy .......................................
................................ 18
1.5.4. CPS Approval Procedures ................................
................................................................................................
.......................................................... 18
1.5.5. Waivers ................................................................................................................................
................................ ...................................................... 18
2. Publication & PKI Repository Responsibilities................................................................
.......................................... 19
2.1. PKI Repositories ................................................................................................................................
................................ .................................19
2.1.1. Repository Obligations ................................
..............................................................................................................................
.............................. 19
2.2. Publication of Certificatee Info
Information..............................................................................................
..............................19
2.2.1. Publication of CA Informati tion................................................................................................
................................................... 19
2.2.2. Interoperability ................................
................................................................................................................................
........................................... 19
2.3. Publication of Certificate Information
Info ..............................................................................................
..............................19
2.4. Access Controls on PKI Reposito
ositories ................................................................................................
................................19
3. Identification & Authentication
n ................................................................................................
................................... 20
3.1. Naming ................................................................
................................................................................................
.................................................20
3.1.1. Types of Names ................................................................................................................................
................................ ......................................... 20
3.1.2. Need for Names to be Meanin aningful ................................................................................................
............................................. 20
3.1.3. Anonymity of Subscribers................................
................................................................................................
.......................................................... 20
3.1.4. Rules for Interpreting Various ous Name
N Forms ..............................................................................................
.............................. 20
3.1.5. Uniqueness of Names ................................................................................................................................
................................ ................................. 20
3.1.6. Recognition, Authentication
ication & Ro Role of Trademarks ................................................................
.................................................. 20
3.1.7. Name Claim Dispute Resoluution Procedure ...............................................................................................
............................... 21
3.2. Initial Identity Validation ................................
................................................................................................
..................................................21
3.2.1. Method to Prove Possession
ssion of Private Key...............................................................................................
............................... 21
3.2.2. Authentication of Organizati tion user Identity ................................................................
............................................................. 21
3.2.3. Authentication of Individual
ual Identity ................................................................................................
......................................... 21
3.2.4. Non-verified Subscriber Info
nformation ................................................................................................
......................................... 22
3.2.5. Validation of Authority ................................
..............................................................................................................................
.............................. 22
Version 4.0.0
3.2.6. Criteria for Interoperation ................................

................................................................................................
.......................................................... 22
3.3. Identification and Authenticaation for Re-Key Requests ................................................................
.................................22
3.3.1. Identification and Authenticcation for Routine Re-key ................................................................
............................................... 22
3.3.2. Identification and Authenticcation for Re-key after Revocation ................................................................
................................. 23
3.4. Identification and Authenticaation for Revocation Request ............................................................
............................23
4. Certificate Life-Cycle Operatioonal Requirements ................................................................
...................................... 24
4.1. Certificate requests ................................
.............................................................................................................................
.............................24
4.1.1. Submission of Certificate Application
App ................................................................................................
....................................... 24
4.1.2. Enrollment Process and Ressponsibilities ................................................................................................
................................... 24
4.2. Certificate Application Proce
cessing ................................................................................................
....................................25
4.2.1. Performing Identification and Authentication
Authent Functions ................................................................
........................................... 25
4.2.2. Approval or Rejection of Ceertificate Applications ................................................................
..................................................... 25
4.3. Certificate Issuance ............................................................................................................................
................................ ............................25
4.3.1. CA Actions during Certifica
icate Issuance ................................................................................................
..................................... 25
4.3.2. Notification to Subscriber oof Certificate Issuance ................................................................
...................................................... 25
4.4. Certificate Acceptance................................................................................................
................................ ........................................................26
4.4.1. Conduct Constituting Certifi ficate Acceptance ................................................................
............................................................ 26
4.4.2. Publication of the Certificatte by the CA ................................................................................................
.................................... 26
4.4.3. Notification of Certificate Isssuance by the CA to Other Entities ...............................................................
............................... 26
4.5. Key Pair and Certificate Usage ................................................................................................
.........................................26
4.5.1. Subscriber Private Key and
nd Cer
Certificate Usage ................................................................
........................................................... 26
4.5.2. Relying Party Public Key and Cer
Certificate Usage ................................................................
....................................................... 26
4.6. Certificate Renewal ............................................................................................................................
................................ ............................26
4.6.1. Circumstance for Certificatee Ren
Renewal................................................................................................
........................................ 27
4.6.2. Who may Request Renewal wal ................................................................................................
....................................................... 27
4.6.3. Processing Certificate Reneewal Requests ................................................................................................
.................................. 27
4.6.4. Notification of New Certificate
cate Issuance to Subscriber ................................................................
............................................. 27
4.6.5. Conduct Constituting Accep eptance of a Renewal Certificate ................................................................
...................................... 27
4.6.6. Publication of the Renewal Certificate by the CA ................................................................
..................................................... 27
............................... 27
4.7. Certificate Re-Key ..............................................................................................................................
................................ ..............................28
4.7.1. Circumstance for Certificate Re Re-key ................................................................................................
.......................................... 28
4.7.2. Who may Request Certifica ication of a New Public Key ................................................................
............................................... 28
4.7.3. Processing Certificate Re-key
keying Requests ................................................................................................
................................ 28
cate Issuance to Subscriber ................................................................
............................................. 28
4.7.5. Conduct Constituting Accep eptance of a Re-keyed Certificate ................................................................
..................................... 28
4.7.6. Publication of the Re-keyeded Cer
Certificate by the CA ................................................................
.................................................... 28
............................... 28
4.8. Certificate Modification ................................................................................................
................................ .....................................................29
4.9. Certificate Revocation and Suspension
Suspension.............................................................................................
.............................29
4.9.1. Circumstance for Revocation
on of a Certificate ................................................................
............................................................ 29
4.9.2. Who Can Request Revocati tion of a Certificate ................................................................
........................................................... 29
4.9.3. Procedure for Revocation Request ................................................................................................
............................................. 30
4.9.4. Revocation Request Gracee Period
Pe ................................................................................................
.............................................. 30
4.9.5. Time within which CA must
ust Process the Revocation Request ................................................................
.................................. 30
4.9.6. Revocation Checking Requiuirements for Relying Parties ................................................................
........................................... 30
4.9.7. CRL Issuance Frequency ................................................................................................
................................ ........................................................... 30
4.9.8. Maximum Latency for CRLs
RLs ................................................................................................
..................................................... 31
Version 4.0.0
4.9.9. Online Revocation Checking

ng Avai
Availability ................................................................................................
................................. 31
4.9.10. Online Revocation Checking
ng Requ
Requirements ..............................................................................................
.............................. 31
4.9.11. Other Forms of Revocationn Advert
Advertisements Available ................................................................
.............................................. 31
4.9.12. Special Requirements Relatted To Key Compromise ................................................................
................................................. 31
4.9.13. Circumstances for Suspensiion ................................................................................................
................................................... 31
4.9.14. Who can Request Suspensionon ................................................................................................
.................................................... 32
4.9.15. Procedure for Suspension
ension Request ................................................................................................
............................................. 32
4.9.16. Limits on Suspension Period
od ................................................................................................
...................................................... 32
4.10. Certificate Status Services ................................
................................................................................................
.................................................32
4.10.1. Operational Characteristics ................................................................................................
........................................................ 32
4.10.2. Service Availability................................................................................................................................
................................ .................................... 32
4.10.3. Optional Features ................................
................................................................................................................................
....................................... 32
4.11. End of Subscription ............................................................................................................................
................................ ............................33
4.12. Key Escrow and Recovery ................................
................................................................................................
.................................................33
4.12.1. Key Escrow and Recovery Policy and Practices ................................................................
........................................................ 33
5. Facility Management & Operational Controls ................................................................
........................................... 33
5.1. Physical Controls ................................
................................................................................................................................
................................33
5.1.1. Site Location & Construction on ................................................................................................
..................................................... 33
5.1.2. Physical Access ................................
................................................................................................................................
.......................................... 34
5.1.3. Power and Air Conditioning ................................................................................................
...................................................... 34
5.1.4. Water Exposures ................................................................................................................................
................................ ........................................ 35
5.1.5. Fire Prevention & Protection ................................................................................................
..................................................... 35
5.1.6. Media Storage ................................................................................................................................
................................ ............................................ 35
5.1.7. Waste Disposal................................
................................................................................................................................
........................................... 35
5.1.8. Off-Site backup ................................
................................................................................................................................
.......................................... 35
5.2. Procedural Controls ................................................................................................
................................ ...........................................................35
5.2.1. Trusted Roles ................................................................................................................................
................................ ............................................. 36
5.2.2. Number of Persons Required red per Task................................................................................................
....................................... 38
5.2.3. Identification and Authenticcation for Each Role ................................................................
........................................................ 38
5.2.4. Roles Requiring Separation ration of Duties ................................................................................................
........................................ 38
5.3. Personnel Controls................................
..............................................................................................................................
..............................39
5.3.1. Qualifications, Experience, and Clearance Requirements ................................................................
.......................................... 39
5.3.2. Background Check Proceduresdures ................................................................................................
.................................................. 39
5.3.3. Training Requirements ...............................................................................................................................
................................ ............................... 40
5.3.4. Retraining Frequency and Requirements ................................................................................................
................................... 40
5.3.5. Job Rotation Frequency and Sequence................................................................................................
Sequence ....................................... 40
5.3.6. Sanctions for Unauthorizeded Act
Actions................................................................................................
........................................... 40
5.3.7. Documentation Supplied To Personnel ................................................................................................
...................................... 41
5.4. Audit Logging Procedures ................................
................................................................................................
.................................................41
5.4.1. Types of Events Recorded ................................
................................................................................................
......................................................... 41
5.4.2. Frequency of Processing
ng Aud
Audit Logs ................................................................................................
......................................... 44
5.4.3. Retention Period for Audit Logs ................................................................................................
................................................ 44
5.4.4. Protection of Audit Logs ................................................................................................
................................ ............................................................ 44
5.4.5. Audit Log Backup Proceduresures ................................................................................................
................................................... 44
5.4.6. Audit Collection System (intnternal vs. external) ................................................................
......................................................... 44
5.4.7. Notification to Event-Causiing Subject ................................................................................................
....................................... 45
5.4.8. Vulnerability Assessments ................................
................................................................................................
......................................................... 45
5.5. Records Archival ................................
................................................................................................................................
................................45
5.5.1. Types of Records Archivedd ................................................................................................
........................................................ 45
5.5.2. Retention Period for Archive
hive ................................................................................................
..................................................... 46
Version 4.0.0
5.5.3. Protection of Archive ................................................................................................................................

................................ ................................. 46
5.5.4. Archive Backup Procedures res ................................................................................................
....................................................... 46
5.5.5. Requirements for Time-Stam mping of Records ................................................................
............................................................ 46
5.5.6. Archive Collection System (internal or external) ................................................................
....................................................... 46
5.5.7. Procedures to Obtain & Verify
Veri Archive Information ................................................................
................................................. 46
5.6. Key Changeover ................................................................................................................................
................................ ..................................46
5.7. Compromise and
d Disaster Recovery ................................................................................................
.................................47
5.7.1. Incident and Compromise HHandling Procedures ................................................................
........................................................ 47
5.7.2. Computing Resources, Softtware, and/or Data are Corrupted................................................................
..................................... 47
5.7.3. Private Key Compromise Procedures
P ................................................................................................
........................................ 48
5.7.4. Business Continuity Capabil
bilities after a Disaster................................................................
....................................................... 48
5.8. CA Termination ................................................................................................................................
................................ ..................................48
6. Technical Security Controls................................................................................................
................................ .......................................... 49
6.1. Key Pair Generation and Installation ...............................................................................................
...............................49
6.1.1. Key Pair Generation ................................
................................................................................................................................
................................... 49
6.1.2. Private Key Delivery to Subs ubscriber................................................................................................
............................................ 49
6.1.3. Public Key Delivery to Certtificate Issuer................................................................................................
................................... 50
6.1.4. CA Public Key Delivery too Re Relying Parties ...............................................................................................
............................... 50
6.1.5. Key Sizes ................................
................................................................................................................................
................................................... 50
6.1.6. Public Key Parameters Gener eneration and Quality Checking ................................................................
......................................... 50
6.1.7. Key Usage Purposes (as per er X.509 v3 key usage field) ................................................................
............................................. 50
6.2. Private Key Protection and Cryptographic Module Engineering Controls ..................................
................................ 50
6.2.1. Cryptographic Module Standards
andards and Controls ................................................................
......................................................... 50
6.2.2. Private Key Multi-Person
erson Cont
Control ................................................................................................
............................................. 51
6.2.3. Private Key Escrow ................................................................................................................................
................................ .................................... 51
6.2.4. Private Key Backup ................................
................................................................................................................................
................................... 51
6.2.5. Private Key Archival................................
................................................................................................................................
.................................. 51
6.2.6. Private Key Transfer into
nto or from a Cryptographic Module ................................................................
...................................... 51
6.2.7. Private Key Storage on Cryp ryptographic Module ................................................................
......................................................... 51
6.2.8. Method of Activating Privaivate Key ................................................................................................
............................................. 52
6.2.9. Methods of Deactivating Prrivate Key ................................................................................................
........................................ 52
6.2.10. Method of Destroying Privarivate Key ................................................................................................
............................................ 52
6.2.11. Cryptographic Module Rati ting ................................................................................................
.................................................... 52
6.3. Other Aspects Of Key Manag
agement ................................................................................................
.................................52
6.3.1. Public Key Archival ................................
................................................................................................................................
................................... 52
6.3.2. Certificate Operational Periiods/Key Usage Periods ................................................................
................................................... 52
6.4. Activation Data ................................
................................................................................................................................
...................................53
6.4.1. Activation Data Generation
ion and Installation ..............................................................................................
.............................. 53
6.4.2. Activation Data Protection ................................
................................................................................................
......................................................... 53
6.4.3. Other Aspects of Activation
ion Da
Data ................................................................................................
.............................................. 53
6.5. Computer Security Controls ................................................................................................
..............................................53
6.5.1. Specific Computer Securityy Tech
Technical Requirements ................................................................
................................................ 53
6.5.2. Computer Security Rating ................................
................................................................................................
.......................................................... 54
6.6. Life-Cycle
Cycle Technical Controls ................................................................................................
...........................................54
6.6.1. System Development Controls
rols ................................................................................................
................................................... 54
6.6.2. Security Management Contrrols ................................................................................................
.................................................. 54
6.6.3. Life Cycle Security Controlls ................................................................................................
...................................................... 55
6.7. Network Security Controls ................................................................................................
................................ ................................................55
Version 4.0.0
6.8. Time Stamping ................................................................................................................................

................................ ....................................55
7. Certificate, CRL and OCSP Proofiles ............................................................................................
............................ 56
7.1. Certificate Profile................................
................................................................................................................................
................................56
7.2. CRL Profile ................................
................................................................................................................................
.........................................57
7.2.1. Full and Complete CRL ................................
................................................................................................
............................................................. 57
7.2.2. Distribution Point Based Paartitioned CRL ................................................................................................
................................. 58
7.3. OCSP Profile ................................................................................................................................
................................ .......................................58
7.3.1. OCSP Request Format ...............................................................................................................................
................................ ............................... 58
7.3.2. OCSP Response Format ................................
................................................................................................
............................................................. 58
8. Compliance Audit and Other Assessments
A ................................................................
.................................................. 60
8.1. Frequency or Circumstancess of Assessments ................................................................
...................................................60
8.2. Identity and Qualifications of Assessor ............................................................................................
............................60
8.3. Assessor’s Relationship too Assessed
Ass Entity ................................................................
......................................................60
8.4. Topics Covered by Assessmeent ................................................................................................
..........................................60
8.5. Actions Taken as a Result
lt of Deficiency ................................................................
...........................................................60
8.6. Communication of Results ................................
................................................................................................
.................................................60
9. Other Business and Legal Matte
tters ...............................................................................................
............................... 62
9.1. Fees................................................................
................................................................................................
.......................................................62
9.1.1. Certificate Issuance and Renewal
Ren Fees ................................................................................................
...................................... 62
9.1.2. Certificate Access Fees ................................
..............................................................................................................................
.............................. 62
9.1.3. Revocation Status Informati tion Access Fees ..............................................................................................
.............................. 62
9.1.4. Fees for Other Services ................................
..............................................................................................................................
.............................. 62
9.1.5. Refund Policy................................
................................................................................................................................
............................................. 62
9.2. Financial Responsibility ................................................................................................
................................ .....................................................62
9.2.1. Insurance Coverage ................................................................................................................................
................................ .................................... 62
9.2.2. Other Assets ................................
................................................................................................................................
............................................... 62
9.2.3. Insurance or Warranty Covera overage for End-Entities ................................................................
..................................................... 63
9.3. Confidentiality of Business Inf
nformation ................................................................
...........................................................63
9.4. Privacy of Personal Information
ation ................................................................................................
.......................................63
9.5. Intellectual Property Rights................................
................................................................................................
...............................................63
9.5.1. Property Rights in Certifica
icates and Revocation Information ................................................................
..................................... 63
9.5.2. Property Rights in the CPS................................
................................................................................................
......................................................... 63
9.5.3. Property Rights in Names ................................
................................................................................................
.......................................................... 63
9.5.4. Property Rights in Keys ................................
................................................................................................
............................................................. 63
9.6. Representations and Warran
nties ................................................................................................
.......................................64
9.6.1. CA Representations and Warra Warranties................................................................................................
........................................... 64
9.6.2. Subscriber ................................................................................................................................
................................ .................................................. 64
9.6.3. Relying Party ................................................................................................................................
................................ ............................................. 65
9.6.4. Representations and Warran ranties of Other Participants ................................................................
............................................... 65
9.7. Disclaimers of Warranties ................................
................................................................................................
.................................................65
9.8. Limitations of Liabilities ................................
................................................................................................
....................................................65
9.9. Indemnities ................................................................................................................................
................................ ..........................................66
Version 4.0.0
9.10. Term and Termination ................................

................................................................................................
.......................................................67
9.10.1. Term ................................................................
................................................................................................
........................................................... 67
9.10.2. Termination ................................
................................................................................................................................
................................................ 67
9.10.3. Effect of Termination and Surv Survival ................................................................................................
............................................ 67
9.11. Individual Notices and Comm
munications with Participants ...........................................................
................................ 67
9.12. Amendments................................
................................................................................................................................
........................................67
9.12.1. Procedure for Amendment ................................
................................................................................................
......................................................... 68
9.12.2. Notification Mechanism and Period ................................................................................................
........................................... 68
9.12.3. Circumstances under Which
ch OID Must be Changed ................................................................
.................................................. 68
9.13. Dispute Resolution Provision
ns ................................................................................................
...........................................68
9.13.1. Disputes among Licensed CAs and Customers ................................................................
.......................................................... 68
9.13.2. Alternate Dispute Resolution
on Provisions................................................................................................
.................................... 68
9.14. Governing Law ................................
................................................................................................................................
...................................68
9.15. Compliance with Applicable Law ................................................................................................
.....................................69
9.16. Miscellaneous Provisions................................
................................................................................................
....................................................69
9.16.1. Entire Agreement ................................
................................................................................................................................
....................................... 69
9.16.2. Assignment ................................
................................................................................................................................
................................................ 69
9.16.3. Severability ................................
................................................................................................................................
................................................ 69
9.16.4. Waiver of Rights ................................................................................................................................
................................ ........................................ 69
9.16.5. Force Majeure ................................................................................................................................
................................ ............................................ 69
9.17. Other Provisions ................................................................................................................................
................................ .................................70
10. Bibliography................................
...............................................................................................................................
............................... 71
11. Acronyms and Abbreviations
ns ................................................................................................
................................... 72
Version 4.0.0
Definitions
The following definitions are to be used while reading this CPS. Unless otherwise specified, the word
“CA” used throughout this document refers to FuturiQ Systems Pvt Ltd. CA, likewise CPS means
CPS of FuturiQ Systems Pvt Ltd. Words and expressions used herein and not defined but defined in
the Information Technology Act, 2000 and subsequent amendments, hereafter referred to as the ACT
shall have the meaning respectively assigned to them in the Act.
The following terms shall bear the meanings assigned to them hereunder and such definitions shall be
applicable to both the singular and plural forms of such terms:
“Act” means Information Technology IT Act, 2000
"IT Act" Information

formation Technology IT Act,
Act 2000, its amendments, Rules there under
Regulations and Guidelines Issued by CCA
“ASP” or “Application Service Provider

Provider” is an organization or an entity using Electronic Signature
as part of their application to facilitate the user for requesting issuance and electronically sign the
content through any empanelled ESP.
“Auditor"" means any accredited computer security professional or agency recognized and engaged by
CCA for conducting audit of operation of CA;
“CA” refers to ProDigiSign CA , a Certifying Authority, licensed by Controller of Certifying

Authorities (CCA), Govt. of India under provisions of IT Act, and includes CA Infrastructure issuing
Digital Signature Certificates & also for providing Trust services such as TS, OSCP & CRL
“CA Infrastructure” The architecture, organization, techniques, practices, and procedures that
collectively support the implementation and operation of the CA. It includes a set of policies,
processes, server platforms, software and workstations, used for the purpose of administering Digital
Signature Certificates and keys.
"CA Verification Officer"" means trusted person involved in identity and address verification of DSC
applicant and according approval for issuance of DSC.
"Certificationn Practice Statement or CPS

CPS" means a statement issued by a CA and approved by CCA
to specify the practices that the CA employs in issuing Digital Signature Certificates;
“Certificate”—A Digital Signature C

Certificate issued by CA.
“Certificate Issuance”—The actions ons performed by a CA in creating a Digital Siggnature Certificate

and notifying the Digital Signature C Certificate applicant (anticipated to become a subscriber)
subsc listed in
the Digital Signature Certificate of itss co
contents.
Version 4.0.0
“Certificate Policy”—The India PK KI Certificate Policy laid down by CCA and

nd followed by CA
addresses all aspects associated with the CA’s generation, production, distributio
ribution, accounting,
compromise recovery and administraation of Digital Signature Certificates.
Certificate Revocation List (CRL))—A periodically (or exigently) issued list, diggitally signed by a
Certifying Authority, of identified Digital
D Signature Certificates that have been
n suspended
suspend or revoked
prior to their expiration dates.
“Controller” or “CCA” means the Controller of Certifying Authorities appointed

d as per Section 17
subsection (1) of the Act.
Crypto Token/Smart Card— A hhardware cryptographic device used for generrating and storing
user’s private key(s) and containing
ontaining a public key certificate, and, optionally, a cache of other
certificates, including all certificates
tes in tthe user's certification chain.
"Digital Signature" means authent ntication of any electronic record by a subscribeer by means of an
electronic method or procedure in acccordance with the provisions of section 3 of IT
T Act;
A
“Digital Signa ture Certificate Applicant” or “DSC Applicant” —A person rson that requests
the issuance of a Digital Signature Ceertificate by a Certifying Authority.
“Digital Signature Certificate App plication” or “DSC Application” —A requeest from a Digital
Signature Certificate applicant to a CA f o r the issuance of a Digital Signature Certifi
rtificate
Digital Signature Certificate—Meaans a Digital Signature Certificate issued under subsection (4) of
section 35 of the Information Technolo
ology Act, 2000.
“ESP” or “eSign Service Provider”” is a Trusted Third Party as per definition in Sec
econd Schedule of
Information Technology Act to prov
ovide eSign service. ESP is operated within n CA Infrastructure &
empanelled by CCA to provide Online
ne Electronic Signature Service.
Organization—An entity with whicch a user is affiliated. An organization may also

lso be a user.
“Private Key" means the key of a keey pair used to create a digital signature;
"Public Key" means the key of a keey pair used to verify a digital signature and liisted in the Digital
Signature Certificate;
“Registration Authority” or “RA”“R is an entity engaged by CA to collect DSC

Application Forms (along with supporting ddocuments) and to facilitate verificatiion of applicant’s
credentials
“Relying Party” is a recipient who acts

ac in reliance on a certificate and digital signatur
ture.
Version 4.0.0
“Relying Party Agreement” Terrms and conditions published by CA for the acceptance
of certificate issued or facilitated
ted the digital signature creation.
"Subscriber Identity Verification method" means the method used for the he verification
v of the
information (submitted by subscribriber) that is required to be included in the Digital Signature
Certificate issued to the subscriber in accordance with CPS. CA follows the Ideentity Verification
Guidelines laid down by Controller.
Subscriber—A person in whose name

me the Digital Signature Certificate is issued by CA.
Time Stamping Service: A servicee provided by CA to its subscribers to indica cate the correct date
and time of an action, and identity off the person or device that sent or received
ived the time
ti stamp.
Subscriber Agreement—The agreeement executed between a subscriber and CA f o r the provision

of designated public certification seervices in accordance with this Certification Praactice Statement
Time Stamp—A notation that ind indicates (at least) the correct date and time of an action, and
identity of the person or device that ssent or received the time stamp.
"Trusted Person" means any person rson who has:-

i. Direct responsibilities for the day-to-day operations, security and perfformance of those
business activities that are regul
ulated under the Act or Rules in respect of a CA, or
ii. Duties directly involving the issuance, renewal, suspension, revocation of Digital Signature
Certificates (including the identification
identifi of any person requesting a Digital Sig
gnature Certificate
from a licensed Certifying Authority),
Autho creation of private keys or adminisnistration of CA’s
computing facilities.
Version 4.0.0
1. Introduction
ProDigiSign CA is managed by Professional DigiSign Private Limited. The term “Certifying

Authority” or CA as used in this CPS, refers to ProDigiSign CA as the entity that holds the CA
license from the Controller of Certifying Authorities (CCA), Govt. of India.
India PKI is a hierarchical PKI with the trust chain starting from the Root Certifying Authority of
India (RCAI). RCAI is operated by the Office of Controller of Certifying Authorities,
Government of India. Below RCAI there are Certifying Authorities (CAs) licensed by CCA to
issue Digital Signature Certificates under the provisions of IT Act. These are also called Licensed
CAs. ProDigiSign CA is a Licensed CA under RCAI.
1.1. Overview of CPS
India PKI CP defines certifica

cate policies to facilitate interoperability amonng subscribers and
relying parties for e-comm merce and e-governance in India. The CP and Certifying
Authorities (CAs) are governeed by the Controller of Certifying Authorities (CCA). Certificates
C
issued by CAs contain one or more registered Certificate Policy OID, which h may
m be used by a
Relying Party to decide whether
ther a certificate can be trusted for a particularr purpose.
pu
The Certification Practice Stat

tatement (CPS) of ProDigiSign CA details the practices and
operational procedures implem
plemented to meet the assurance requirements.
ments. This CPS is
consistent with the Internet En
Engineering Task Force (IETF) Public Key Inffrastructure X.509
(IETF PKIX) RFC 3647, Inte nternet X.509 Public Key Infrastructure Certifi
rtificate Policy and
ment Framework. Controller of Certifyingg Authority
Autho issues license
to operate as Certifying Authority
Autho subject to successful compliance audit of CA per the CPS.
The CPS is also
i. intended to be applica
cable to and is a legally binding document betw tween the CA, the
Subscribers, the applica
cants, the Relying Parties, employees and contrac
actors; and
ii. intended to serve ass notice to all parties within the context of the CA CPS
C
CPS refers to the various reequirements specified under the following guidelines
uidelines issued by
CCA
i. The identity Verificaation Guidelines [CCA-IVG]: For the identitty verification for
different types of certifi
rtificates like personal, organizational person, enncryption, system
certificate etc.
ii. Interoperability Guideelines for DSC [CCA-IOG]: For the certificate te profile, including
content and format of the certificates, key usage, extended key usage etc.
iii. X.509 Certificate Polic icy for India PKI [CCA-CP]: Assurance Class, Certificate policy
id, validity of certifica
cates, key size, algorithm, storage requirements,
nts, audit parameters
etc.
Version 4.0.0
iv. e-Authentication guidelines

uidelines [CCA - eAUTH]: The security proocedures for key
generation, key prot
otection and audit logs, signature format, identity
ide verification
requirements etc
v. Security Requirements
ments for Crypto Devices [CCA-CRYPTO]: The crypto device
management & securitty requirements for holding subscribers’ private
te key
k
vi. CA Site Specificationon [CCA-CASITESP]: Requirements for the construction of

cryptographic site and
nd ssecurity requirements
1.2. Identification
The contact details are mentiooned in section 1.5.2 of this CPS.
The following are the levelss of assurance defined in the Certificate Poli licy. Each level of
assurance has an OID that cann be asserted in certificates issued by CA if the
he certificate
ce issuance
meets the requirements for that
hat assurance level. The OIDs are registered under the CCA are as
follows:
Assurance Level OID

Class 1 2.16.356.100.2.1
Class 2 2.16.356.100.2.2
Class 3 2.16.356.100.2.3
eKYC – Single Factor 2.16.356.100.2.4.1
eKYC – Multi Factor 2.16.356.100.2.4.2
The OIDs allocated to CA and CPS

C are as given below
Serial No. Product OID

1 ProDigiSign CA 2.16.356.100.1.26
2 ProDigiSign CA CPS 2.16.356.100.1.26.2
.2
OID for document signer certificates
document signer 2.16.356.100.10.1

1.3. PKI Participants
1.3.1. PKI Authorities
1.3.1.1. Controller of Certif

Certifying Authorities (CCA)
In the context of the CPS,

PS, tthe CCA is responsible for:
1. Developing and adminiistering India PKI CP.

Version 4.0.0
2. compliance analysis and

nd approval
app of the licensed CAs CPS;
3. Laying down guidelines

nes for Identity Verification , Interoperability of DSCs
D and Private
Key storage
4. Ensuring continued conformance

c of Licensed CAs with the CPS
PS by examining
compliance audit result
lts.
1.3.1.2. CA
The ProDigiSign CA is licensed

li by CCA as per Information Technology
ogy Act. The primary
function of CA is to issue
ue end entity certificates.
ProDigiSign CA certificate is certified by Root Certifying Authority y of India (RCAI). In

India PKI hierarchy, Root certificate is the trust anchor for CA certificattes. The following
are the CA Certificates issued
ued to CA.
Sr. No. CA Name Certified

ed by
1 ProDigiSign CA 2022 CCA Indiia 2022
CA issue Digital Signature

ture Certificates to end entities directly. CA also suspends or revokes
the Digital Signature Certif
rtificates. The CA maintains the Certificate Revoocation List (CRL)
CA for the revoked and suspended
suspend Digital Signature Certificates in itss rrepository. CRL is
signed by issuing CA.
1.3.2. PKI Services
i. Certificate Services:: BBased on the assurance level requirements,

ments, CA issues various
classes of Certificates.
tes. The category of certificates includes individual,
vidual, organizational
person and special tyype of certificates. These special types of Certificates
C include
System Certificate,
te, Do
Document Signer and Encryption Certificates.. The certificates are
issued subjected to the verification requirements specified under CCA--IVG
ii. CRL Services:: CA makes available CRL on the website

https://prodigisign.com/repository/crl/ - freely downloadable by subscribers and
relying parties
iii. OCSP (Online Certifi

rtificate Status Protocol) Validation Services: CA provides OCSP
validation services to relying parties for certificate status verification
on in real time. The
OCSP service of the CA is opoperated as per CCA-OCSP
Version 4.0.0
iv. eSign on line Digital Signatu

ignature Services: ProDigiSign CA is empanelled as ESP to offer
eSign online Digital Signature Service as per the CCA CCA-eAUTH.
eAUTH. e-KYC
e class of
certificates will be issued as stated under CCA-CP.
CCA
ProDigiSign CA is also empanelled for providing eSign Services. The DSCs are issued
to applicants
nts for the purpose of document signing provided through eSign Services of
CA. The applicants are electronically authenticated to the eKYC services of CA or other
specified eKYC services by CCA. CA provides direct interface to applicant for
providing authentication
ntication information and also for accessing eKYC information retained
in the CA eKYC database. CA issues short validity Digital Signature Certificates of 30
minutes to eSign users directly. After generation of DSC and signature creation, ESP of
CA ensures that the private keys are destroyed immediately. The subscriber's private key
storage requirements are not applicable in this mode of DSC issuance.
CA does not suspend or revoke eKYC classes of Digital Signature Certificates. However
the CA maintains a null
ull Certificate Revocation List (CRL) in its repository to satisfy the
requirements of relying party applications. CRL is signed by issuing CA. Similarly re- re
key and renewal are not applicable to eKYC class of Digital Signature Certificates.
The identity and

nd address of the DSC applicant is obtained based on authentication of
DSC applicant to eKYC service. In order to retain eKYC of applicant by CA, the
process of applicant’s identity verification is followed as specified under CCA
CCA-IVG. In
the case of external
al eKYC service, the response received from eKYC provider will be
accepted provided that eKYC provider provides eKYC response directly to CA up on
the authentication by applicant. The list of approved eKYC providers are specified by
CCA and listed in CCA
CCA-eAUTH.
ESP of CA facilitates DSC application form generation; key generation of DSC

applicant based on the authentication provided by DSC applicant and ensures that the
applicant’s identity information and public key are properly bound. Additionally, the C
CA
records the process that was followed for issuance of each certificate. The process
documentation and authentication requirements are as specified in the CCA
CCA-eAUTH and
CCA-IVG.
Once the verification of applicant is carried out and recorded in the CA eKY
eKYC database,
the issuance of eKYC classes of DSC are implemented in automated environment with a
requirement of authentication of applicant to eKYC database. Issuance of eKYC classes
and Class 1-3
3 of DSCs are carried out from separate certificate issuance ssystems.
The users of Application Service Provider (ASP) interface with ESP of CA for Signature
and DSC issuance through ASP gateway. ASPs are registered with ESP of CA after a
verification process. CA verifies the source of request and authenticates users directly
for each certificate request received from ASP before DSC issuance. Certificates are
electronically verified to ensure that all the fields and extensions are properly populated.
The certificates are of one time use and the issued certificates are archived. Private keys
Version 4.0.0
of applicants are destroyed immediately after certificate generation and signature

function. The signatures along with certificate are delivered to the end entity subscribers.
v. Time Stamping Servicee: CA Provides Time Stamping Service in accoordance with CCA-
TSP.
1.3.3. Registration Authority (RA) and Organizational Registration Authority (ORA)
Registration Authority (RA): RA is an entity engaged by CA to collect DSC

Application Forms (along with supporting documents) and to facilitate verification of
subscriber credentials. RA interacts with the CA and submits the applicant’s request for
certificate issuance to CA. RA shou
should
ld have legally enforceable agreement with CA.
Organizational Registration Authority (ORA): An organizational RA (ORA) collects

and verifies organizational employees / board of directors / partners etc. /'s information
that are to be entered into his or hher
er public key certificate. An RA interacts with the CA
and submits their organizational person’s request for certificate. An organizational RA
function under the terms and conditions laid down by CA.
1.3.4. Subscribers
A Subscriber is the entity w whose name appears as the subject in a certifficate, who asserts
that it uses its key and cert
rtificate in accordance with the certificate policy
cy asserted in the
certificate, and who does not
ot itself issue certificates.
1.3.5. Relying Parties
A Relying Party is the entityy that relies on the validity of the binding of the Subscriber's name
to a public key. The Relyingng Party is responsible for deciding whether or how to check the
validity of the certificate by
b checking the appropriate certificate status information. The
Relying Party can use the ce certificate to verify the integrity of a digitallyy signed message,
or to identify the creator of a message. A Relying Party may use information on in the certificate
(such as certificate policy identifiers) to determine the suitability of the he certificate for a
particular use.
1.3.6. Applicability
ProDigiSign CA issues the following classes of certificates. The Assurance level and
Applicability as defined under India PKI CP is given below
Assurance
Assurance Applicab
cability
Level
Class 1 Class 1 certifi
rtificates shall be issued for This provides a basicc level of assurance
both businesss personnel
pe and private relevant to environmen
ents where there are
individualss use.
us These certificates will risks and consequenequences of data
Version 4.0.0
confirm that
hat the information in the compromise, but they
hey aare not considered
application prrovided by the subscriber to be of major significanc
cance.
does not connflict with the information
in well-recogn
ecognized consumer databases.
These certifica
cates will be issued for both This level is relevant
ant to environments
Class 2 business pe
personnel and private where risks and cons nsequences of data
individuals usse. These certificates will compromise are mode oderate. This may
confirm that the information in the include transactions
ons ha
having substantial
application prrovided by the subscriber monetary value or risk of fraud, or
does not confli
flict with the information in involving access to private information
well-recognized
zed con
consumer databases. where the likelihood
hood of malicious access
is substantial
Class 3 This certificacate will be issued to This level is relevant
ant to environments
individuals ass well as organizations. As where threats to datta are high or the
these are high gh aassurance certificates, consequences of the failure of security
primarily inttended for e-commerce services are high.
gh. This may include very
applications,
ons, they shall be issued to high value transactions
ons or high levels of
individualss ononly on their personal fraud risk.
(physical)) appea
appearance before the
Certifying Autthorities.
eKYC- eKYC - Single Factor class of This level is relevant to environments
Single certificates shall be issued based on where Single Factor authentication to
Factor Single Factor authentication of eKYC service is acceptable method for
subscriber to the applicable eKYC credential verification prior to issuance of
services. DSC. Certificate holder's
older's private keys are
These certificates will confirm that the created on hardware and destroyed
information in Digital Signature immediately after one time usage at this
certificate provided by the subscriber is assurance level.
samee as information retained in the
eKYC databases pertaining to the
subscriber.
eKYC- eKYC - Multi Factor class of certificates This level is relevant to environments
environ
Multi shall be issued based on Multi Factor where Multi Factor authentication to
Factor authentication of subscriber to the eKYC service is acceptable method for
applicable eKYC services. These credential verification prior to issuance of
certificates will confirm that the DSC. Certificate holder's private keys are
information in Digital Signature created on hardware and destroyed
certificate provided by the subscriber is immediately after one time usage at this
same as information retained in the assurance level.
eKYC databases pertaining to the
subscriber.
1.4. Certificate Usage
1.4.1. Appropriate Certificcate Uses
Certificate usage is governned by the IT Act of 2000 and Interoperab

ability Guidelines
published by CCA.
Version 4.0.0
1.4.2. Prohibited Certificatte Uses
Certificate usage is governed

ned by the IT Act of 2000 and Interoperab
ability Guidelines
published by CCA.
1.5. Policy Administration
1.5.1. Organization adminiistering the document
This CPS is adminnistered by CA and is revised with the approval of CCA.

C
1.5.2. Contact Person
Questions/Queries regarding this CPS may be directed to the CA at
Professional Digisign Private Limited

Office No-238,2nd
238,2nd Floor, Patil Plaza,
Near Sarasbaug, Mitra Mandal Chowk,
Swargate, Pune-411009.
411009.
Phone: +91-(020)49105678
(020)49105678
Email: info@prodigisign.com
For more information or for feedback:

Visit ProDigiSign CA Portal at https://prodigisign.com
1.5.3. Person Determining
ning Certi
Certification Practice Statement Suitability for
or the Policy
The determination of suitab

ability of a CPS will be based on an indeependent auditor’s
results and recommendations.
ons.
1.5.4. CPS Approval Proced

ocedures
The CCA approve CPS of thhe CA and auditor’s assessment will also be taken
aken into account.
1.5.5. Waivers
There shall be no waivers too this CPS.

Version 4.0.0
2. Publication & PKI Repository Responsibilities
2.1. PKI Repositories
CA maintains Hypertext Transfer Protocol (HTTP) or LDAP based repositories that

contain the following inform
mation:
1. Certificate Revocation
on List (CRL) issued by the Licensed CA
2. Digital Signature Certifi
rtificates issued by CA
2.1.1. Repository Obligations

ions
CA maintains a repository and

nd is available at:
https://prodigisign.com/repository/
2.2. Publication of Certificatee Info

Information
2.2.1. Publication of CA In
nformation
See Section 2.1.
2.2.2. Interoperability
See Section 2.1.
2.3. Publication of Certificatee Information

CA Certificates and CRLss are published as specified in this CPS in Section
on 4.
2.4. Access Controls on PKI Repositories

R
The PKI Repository info formation which is not intended for publicc dissemination
d or
modification is protected.
Version 4.0.0
3. Identification & Authenticaation
The requirements for identifitification and authentication are specified under

u Information
Technology Act, Rules and Guuidelines issued there under. Before issuing a Certificate,
C the CA
ensures that all Subject inform
mation in the Certificate conforms to the requir
irements that have
been verified in accordance wit
ith the procedures prescribed in this CPS.
3.1. Naming
3.1.1. Types of Names
CAs issue certificates containning an X.500 Distinguished Name (DN) in the

he Issuer and Subject
fields. Subject Alternative Name may also be used, if marked nonn-critical. Further
requirements for name formss are specified in [CCA-IOG].
3.1.2. Need for Names too be Meaningful
ant to this CPS shall taken care of the following

The certificates issued pursuant
(i) Names used in the certifi

rtificates identify the person or object to which they
t assigned in a
meaningful way.
(ii) The DNs and associated

ed ddirectory information tree reflect organizational structures.
(iii) The common name rep epresents the subscriber in a way that is easily
y understandable
unde by
humans. For people, thiis will typically be a legal name. For equipmenent, this may be a
model name and serial nu
number, or an application process
3.1.3. Anonymity of Subscrribers
CA does not issue subscriber

ber certificates with anonymous identities.
3.1.4. Rules for Interpreting

ng V
Various Name Forms
Rules for interpreting name fforms shall be in accordance with applicable Standa
andards.
3.1.5. Uniqueness of Namess
Name uniqueness for interope

operability or trustworthiness is enforced in asso
sociation with serial
number or unique identifier.
3.1.6. Recognition, Authenttication & Role of Trademarks

Version 4.0.0
No stipulation.
3.1.7. Name Claim Disputee R

Resolution Procedure
The CA resolves any name co collisions (in association with serial number or unique identifier)
brought to its attention that m
may affect interoperability or trustworthiness.
3.2. Initial Identity Validation

on
3.2.1. Method to Prove Posssession of Private Key
In all cases where the DSC applicant named in a certificate generates its ow
wn keys that DSC
applicant is required to prove
ve possession of the private key, which corresponds
ponds to the public
key in the certificate request
st. This will be performed by the DSC applicant
cant using its private
key to sign a value and prooviding that value to the issuing CA. The CA then validates the
signature using the DSC applilicant public key.
3.2.2. Authentication of Orga

rganization user Identity
Requests for certificates in the name of an organizational user are manda

andated to include the
user name, organization nam me, address, and documentation providing the he existence of the
organization. CA verifies thet information relating to the authenticityy of the requesting
representative as per the requ
equirements mentioned under CCA-IVG.
3.2.3. Authentication of Ind

dividual Identity
CA follows the process of aapplicant’s identity verification as specified under CCA-IVG. CA

provides software interface
ace for key generation by DSC applicant and ensures that the
applicant’s identity informaation and public key are properly bound. Addditionally, the CA
records the process that waas followed for issuance of each certificate. Prrocess information
depends upon the certificatee level of assurance and is addressed in the applicable
app CPS. The
process documentation and aauthentication requirements include the following:
ng:
1. The identity of the person

son pperforming the identity verification;
2. A signed declaration by that person on the application is that he or she verified

v the
identity of the applicant;;
3. The applicant is required

ed to present one photo ID and also attested
ed document
docu as a proof of
residential address.
Version 4.0.0
4. Unique identifying num

mbers from the Identifier (ID) of the verifier and from an ID of
the applicant.
5. The date and time of the

he verification; and
6. A declaration of identityy ssigned by the applicant using a handwritten signa

gnature or
equivalent per Indian Laaws.
7. Identity is established by
b in-person proofing before CA or equivalent
ent mechanism like
Aadhaar authenticationon or online Video Verification. To confirfirm identities; the
information provided
ded by whom is verified to ensure legitimacy.
3.2.3.1. Authentication
uthentication of Component Identities
Requests are accepted from

om hu
human sponsor in the case of computing and nd communications
components (routers, firew
walls, servers, etc.), which is named as the certifi
ificate subject. The
human sponsor will be respponsible for providing the following registration
on information:
1. Equipment identification
on (e.g., serial number)
2. Equipment public keyss
3. Contact information too enab

enable CA to communicate with the sponsor whhen required
3.2.4. Non-verified Subscriiber Information
CA does not include non-verrified Information provided by DSC applicant inn certificates.
ce
3.2.5. Validation of Authori

ority
Certificates that contain expplicit or implicit organizational affiliation are issued only after
ascertaining the applicant
cant has the authorization to act on behalf of the organization
o in the
asserted capacity. The procedu edure followed by CA to establish the applicancant’s affiliation to
organization is as specified uunder CCA-IVG.
3.2.6. Criteria for Interopeeration
Certificates are issued in accoordance with [CCA-IOG] in order to ensure inteeroperability.
3.3. Identification and Authen

ntication for Re-Key Requests
3.3.1. Identification and Authentication

Authe for Routine Re-key
Version 4.0.0
The subscribers havee to undergo fresh identity-proofing process for f the period for
which the certificatee has been issued. The maximum time for which ch initial identity-
proofing can be relied
ed upon for issuance of fresh certificate is as per the
he table below:
Assurance Level Initial Identity Proofing

Class 1 2 Years
Class 2 2 Years
Class 3 2 Years
When current Signingg Key is used for identification and authentica cation purposes, the
life of the new certifi
rtificate will not exceed beyond the initial identitty-proofing period
specified in the tablee above.
abo
3.3.2. Identification and Authe

Authentication for Re-key after Revocation
If a certificate has been revoked, CA issue fresh certificate to the he subscriber only
after the initial registraation process described in Section 3.2 to obtain
n a new certificate.
3.4. Identification and Authen

ntication for Revocation Request
Revocation requests are authhenticated in the following manner.
1. Electronic requests to revoke

evoke a certificate authenticated using that certi
rtificate's associated
public key, regardless of whether or not the private key has been comproomised.
2. In case the possession on of the key is not with the subscriber, suspend/revoke
su the
certificate after verifying
ng the subscriber’s identity.
3. In the case where the

he su
subscriber is not in a position to communicate (dea
death, unconscious
state, mental disorder), reevoke the certificate after verification
Version 4.0.0
4. Certificate Life-Cycle Operaational Requirements
Communication among the CA A, RA, and subscriber are implemented withh requisite security
services (i.e., source authentication,
on, integrity, non-repudiation, or confidentiality
y) applied to them
commensurate with the assurance
ance level of the certificate being managed.
Physical documents are packagedd and transported in a tamper-evident manner by

b a certified mail
carrier to meet integrity and confi
fidentiality requirements.
When cryptography is used, CA implemented the mechanism, at least as strong ong as the certificates
being managed, to secure web ssite using Secure Socket Layer (SSL) certifica cate and set up with
appropriate algorithms and key ssizes satisfies the integrity and confidentiality
y requirements for
certificate management.
Based on the content of communiication, all, or none of the security services aree enforced.
en
4.1. Certificate requests
The applicant intending to oobtain DSC from CA, need to submit DSC appli lication form filled
with identity details, addreess, photo , signature with duly attested supporti
rting documents to
CA. On receipt of the reque
equest and information in the prescribed format, CA carries out the
verification of documents and Video and Mobile number verification if i applicable. The
detailed requirements for
or each category of DSC applicants are specified undder CCA-IVG.
A signed declaration by person

pe performing the identity verification is reco
ecorded on the DSC
application form that he or she verified the identity of the applicant.
Upon the approval of CA tr

trusted person for DSC application request, thee DSC is issued to
the DSC applicant. The DS
SCs are published on the repository of the CA , on acceptance by
the subscriber.
4.1.1. Submission of Certifi

ficate Application
The DSC applicant is required

r to submit the duly filled DSC application
on form along with
the supporting documen ents to CA or RA. The application forms for or various types of
certificates are availablle on the CA web site at: https://prodigisign.com/repository/
4.1.2. Enrollment Processs and Responsibilities
For certificates, all endd-user applicants undergo an enrollment processs consisting of:
• Completing
ng and sub
submitting a certificate application form and provviding the required
information,
• Generating a key pair.
pa
Version 4.0.0
• Delivering his/ herr, or its public key to CA

• Demonstrating to CA that the certificate applicant has possession
on of the private key
corresponding to the
he public key delivered to CA.
• Manifesting assentt to the relevant subscriber agreement.
4.2. Certificate Application Prrocessing
rmation in certificate applications is accurate bassed on the attested

CA verifies the that inform
supporting documents, teelephonic interaction, Video Verification and other o procedures
specified under CCA-IVG..
4.2.1. Performing Identifica

cation and Authentication Functions
See Section 3.2.3 and subsections thereof.
4.2.2. Approval or Rejection

on of Certificate Applications
Certificate Applications
ons submitted to the CA for processing coulld result in either
approval or denial.
4.3. Certificate Issuance
After a certificate applicannt submits a certificate application, the CA veriifies or refutes the
information in the certifi ficate application. Upon successful verificatiion based on all
required authentication proc
ocedures for various classes of certificates, forw
ward the certificate
application for approval. The
T applicant’s request for certificate issuancee is reviewed by a
trusted person which may result
r in approval or denial of certificate.
The responses received from

fr publically available databases, used to
o confirm
con Subscriber
information, are protected ffrom unauthorized modification.
4.3.1. CA Actions during C

Certificate Issuance
CA verifies the source ce of a certificate request before issuance. If crypto medium is

opted for the key gene
generation and storage, the details such as make,ake, model, serial no
etc. are also recorded.d. Certificates
Ce are checked to ensure that all fiellds and extensions
are properly populated.ed. After generation, verification, and acceptance,
ance, CA publishes the
certificate in the reposit
sitory.
4.3.2. Notification to Subsccriber of Certificate Issuance
CA will notify the sub

subject (End Entity Subscriber) of certificate issuance through
email/SMS and internet
net link.
Version 4.0.0
4.4. Certificate Acceptance
4.4.1. Conduct Constituting

ng Certificate Acceptance
The DSC applicant m must confirm acceptance of the certificate upon notification of
issuance by the CA. Notification and link are sent to subscriber for downloading
the certificate. The con
content of the certificate will be displayed to subscriber
sub along with
download option. Dow wnloading the certificate constitutes the subscribe
ber’s acceptance of
the certificate.
4.4.2. Publication of the Cer

ertificate by the CA
See Section 2.1.
4.4.3. Notification of Certifi

ficate Issuance by the CA to Other Entities
Not Applicable
4.5. Key Pair and Certificate Usage
4.5.1. Subscriber Private Key

K and Certificate Usage
Subscribers are liable to protect their private keys from access by anny other party. For
individual Signature certificates,
ce subscribers are required to generatee key pair in FIPS
140-2 level 2 cryptoo dev
devices.
Subscribers are also required

r to use their private keys for the purpos
poses as constrained
by the extensions (succh as key usage, extended key usage, certificatte policies, etc.) in
the certificates issued
ued to them.
4.5.2. Relying Party Publicc Key and Certificate Usage
Relying parties are requ

equired to use public key certificates and associatted public keys for
the purposes as constrrained by the extensions (such as key usage, extended
ex key usage,
certificate policies, etc.)
c.) in the certificates.
4.6. Certificate Renewal
Renewing a certificate mmeans creating a new certificate with the sam me name, for time
remaining in validity and other information as the old one, but a new, extended
validity period and a new serial number. Certificates are renewed by CA only if the public
Version 4.0.0
key has not reached the end

nd of its validity period, the associated privatee key
k has not been
compromised, and the Subs
bscriber name and attributes are unchanged.
4.6.1. Circumstance for Ceertificate Renewal
A certificate may be rrenewed if the public key has not reached the end of its validity
period, the associated
ed private key has not been revoked or comppromised, and the
Subscriber name and aattributes are unchanged. Request for renew wal of certificates
are not accepted by CA at present due to the constraint present in the
he CCA-IVG.
4.6.2. Who may Request Renewal

Ren
In the normal scenario,

o,
A Subject may request

st the renewal of its certificate.
A PKI Sponsor may reque

equest renewal of component certificate.
A CA may request rene

enewal of its subscriber certificates, e.g., when the
he CA re-keys.
4.6.3. Processing Certificatte Renewal Requests
In the normal scenari

rio, a certificate renewal will be using
ng one of the following
processes:
1. Initial registration
on pprocess as described in Section 3.2; or
2. Identification & Authentication

A for Re-key as described in Secti
tion 3.3, except the
old key can also
so be used
us as the new key.

C Issuance to Subscriber
See Section 4.3.2.

ng Acceptance of a Renewal Certificate
See Section 4.4.1.
4.6.6. Publication of the Ren

enewal Certificate by the CA
See Section 4.4.2.

Version 4.0.0
See Section 4.4.3.
4.7. Certificate Re-Key
Re-keying a certificate means

m that a new certificate is created that hat has the same
characteristics and level
el as the old one, except that the new certificate has a new, different
public key (corresponding to a new, different private key) and a different serial
s number, and
it may be assigned a differrent validity period. At present CA does not off ffer certificate Re-
Key option to subscribers.
4.7.1. Circumstance for Certificate Re-key

Re
CA issue a new certifi

rtificate to the Subject when the Subject has generaated a new key pair
and is entitled for a certificate
ce subjected to the requirements set forth
h under CCA-IVG.
4.7.2. Who may Request Certification

Ce of a New Public Key
A subscriber may reque

equest the re-key of its certificate.
A PKI Sponsor may reque

equest may request re-key of component certifica
cate.
4.7.3. Processing Certificatte Re-keying Requests

A certificate re-key shall
sh be achieved using one of the following proce
ocesses:
1. Initial registration
on process
p as described in Section 3.2; or
2. Identification & Auuthentication for Re-key as described in Section

on 3.3.
3

C Issuance to Subscriber
See Section 4.3.2.

ng Acceptance of a Re-keyed Certificate
See Section 4.4.1.
4.7.6. Publication of the Ree-keyed Certificate by the CA
See Section 4.4.2.

Version 4.0.0
See Section 4.4.3.
4.8. Certificate Modification
Not applicable
4.9. Certificate Revocation and Suspension
equest for revocation prior to revocation. Subscribe

CA authenticates the reque bers are required to
submit paper based revocaocation request as specified under IT CA Rules. Electronic
El requests
to revoke a certificate havee to be authenticated using that certificate's asso
sociated private key,
regardless of whether or not
ot the private key has been compromised.
4.9.1. Circumstance for Reevocation of a Certificate
A certificate is revoked
oked when the binding between the subject and thhe subject’s public
key defined within a certificate is no longer considered valiid. Some of the
circumstances that innvalidate the binding are:
1. Identifying informati
tion or affiliation components of any name(s)) in the certificate
become invalid;
2. The Subject can be sho

hown to have violated the stipulations of its agree
eement with CA;
3. The private key is susp

uspected of compromise; or
4. The Subject or other authorized party (CPS) asks for the subscriber’
r’s certificate to be
revoked.
5. Private key is lost
6. Subscriber is not inn a position to use certificate(Death – copy of Deatth certificate made
available to CA)
Whenever any of the he above circumstances occur, CA revokes the t certificate and
places it on the CRL L. Revoked certificates are included on all neew publications of
the certificate status
us information until the certificates expire.
e. CA ensures that the
revoked certificate w
will appear on at least one CRL.
4.9.2. Who Can Request Revocation

Rev of a Certificate
A certificate subject, human supervisor of a human subject (for organ ganizational user),
Human Resources (HR)(H person for the human subject (for organiza zational user), PKI
Sponsor for componen
ponent, or CA, may request revocation of a certificate.
e.
Version 4.0.0
For CA certificates, authorized

au individuals representing CA may reque
equest revocation of
certificates.
4.9.3. Procedure for Revocat

cation Request
CA identifies the certificate

ce to be revoked as mentioned in the request for
revocation, the reason
on for revocation, and verifies the authentication requirements
r (e.g.,
digitally or manually signed
si by the subject). CA may perform Telephon
ephonic verification
and video verification
on to ensure the identity of the subscriber.
ocation request, CA authenticates the request an

Upon receipt of a revoca nd then revokes the
certificate.
4.9.4. Revocation Request Grace

G Period
There is no revocationon grace period. Responsible parties must reque

equest revocation as
soon as they identify tthe need for revocation.
4.9.5. Time within which

ch CA must Process the Revocation Request
CA make best effortss to process revocation request so that it is posted

ed in the next CRL
unless a revocation reque
equest is received and approved within twoo hourshou of next CRL
generation.
4.9.6. Revocation Checking

ng Requirements for Relying Parties
Use of revoked certifirtificates could have damaging or catastrophicc consequences in

certain applications.
ons. The matter of how often new revocation data should
shou be obtained is
a determination to be made by the Relying Party. If it is temporrarily infeasible to
obtain revocation info formation, then the Relying Party must eitherr reject use of the
certificate, or make
ake an informed decision to accept the risk, responsibility,
r and
consequences for using ng a certificate whose authenticity cannot be guaranteed to the
standards of this poli licy. Such use may occasionally be necessarry to meet urgent
operational requiremen ents.
4.9.7. CRL Issuance Freque

Frequency
CA issues CRLs peri riodically, even if there are no changes to be made, to ensure
timeliness of inform mation. Certificate status information may be issued more
frequently than the isssuance frequency described below. CA ensures es that superseded
certificate status inforrmation is removed from the PKI Repository upon posting
pos of the
latest certificate status
us information.
Version 4.0.0
CA publishes CRLs not later than the next scheduled update.
CA issue CRLs at Lea

east once every 24 hours with minimum validity of 7 days.
d
In addition, CA issuess CRLs and posts the CRL immediately if a certifi

rtificate is revoked
for the reason of key compromise.
co
4.9.8. Maximum Latency for

or CRLs
CA publishes CRLs immediately after generation. Furthermore, each CRL will be

published no later than
han the time specified in the next Update field of the previously
issued CRL. CAs issueue CRLs at least once every 24 hours, and the nex ext Update time in
the CRL may be no laater than 7 days after issuance time (i.e., the thiss Update
Upd time).
4.9.9. Online Revocation

on Ch
Checking Availability
CA supports on-line ce
certificate status checking. Client software using
ng on-line certificate
status checking need not
n obtain or process CRLs.
The on-line revocati

tion/status checking provided by CA meetss or exceeds the
requirements for CRL issuance stated in 4.9.7.
4.9.10. Online Revocation

on Ch
Checking Requirements
ond Sec
No stipulation beyond Section 7.3.
4.9.11. Other Forms of Revocat

ocation Advertisements Available
Other than implementtation of CRLs and on-line revocation status, no other forms of
on-line revocation stattus will be provided by CA
4.9.11.1. Checking Requirements for Other Forms of Revocation Advertisements
No stipulation.
4.9.12. Special Requirementts Related To Key Compromise
None beyond those sttipulated in Section 4.9.7.
4.9.13. Circumstances forr Susp

Suspension
Suspension willl be pe
permitted in the event that a user’s token hold
ding private key is
temporarily unavailab
able to them.
Version 4.0.0
4.9.14. Who can Requestt Suspension

Suspe
A human subscriber, human supervisor of a human subscriber (organ

ganizational user),
Human Resources (HRHR) person for the human subscriber (organganizational user),
issuing CA, may reque
equest suspension of a certificate.
4.9.15. Procedure for Suspension

ension Request
The requester submiitting a request to suspend a certificate should

shou provide the
information to identi
tify the certificate to be suspended, explainn the reason for
suspension, and allow
ow the request to be authenticated (e.g., digit
itally or manually
signed).
The reason code CRL entry extension will be populated with “certifica
cate Hold” by CA.
The Hold Instruction
on Code CRL entry extension will be absent.
4.9.16. Limits on Suspension

on Period
A certificate may only

on be suspended for up to 15 days. If the subscriber
sub has not
removed their certifica
cate from hold (suspension) within that period, the
t certificate shall
be revoked for the reas
eason of “Key Compromise”.
In order to mitigate the

t threat of unauthorized person removing the
he certificate from
hold, the subscriber identity will be authenticated in person using
ng initial identity
proofing process descri
ribed in Section 3.2.3.
4.10. Certificate Status Services
CA supports Online Certifi

rtificate Status Protocol (OCSP) for obtaining the
he revocation status
of X.509 certificates.
4.10.1. Operational Charactteristics
No stipulation.
4.10.2. Service Availability
Relying Parties are bound to their obligations and the stipulati tions of this CPS
irrespective of the avaailability of the online certificate status service.
4.10.3. Optional Features

Version 4.0.0
No stipulation.
4.11. End of Subscription
No stipulation.
4.12. Key Escrow and Recovery
4.12.1. Key Escrow and Recovery Policy and Practices
ances end entity signature key will be escrowed by a third-party.

Under no circumstances
5. Facility Management & Operational Controls
5.1. Physical Controls
CA operation premises are a actively monitored with redundant power er and notification
methods. Sensitive areas within
wit the facility, such as power and network connection
connec are also
controlled within the protec
ected facility.
The operation site has multiple

m tiers of security enforced through Photo
Pho ID badges,
proximity cards and bioometric access devices. All visitors are esccorted by trusted
persons and every visitor
or ssigns the visitor’s log.
The facility is continuallly staffed (24x7), either by trusted persons or by an on-site

guard service during non-bus
business hours.
5.1.1. Site Location & Consstruction
The system componen

ponents and operation of CA are contained within wit a physically
protected environmentent to deter, detect and prevent unauthorized
zed use of,
o access to, or
disclosure of sensitivee information. The physical security standards are
a modeled as per
the physical
cal and operational
ope security guidelines mentioned inn the Information
Technology Act.
CA’s primary sitee con

consists of three physical security tiers comprising
ng of:
o
Tier 1: The common on area in the vicinity of the CA operations

ons set-up where in
physical access checck is performed and identity verified. This is
i the area where
common facilities aree incorporated.
Tier 2: This is the fir

first level where CA operations commence. This is manned by
physical security perrsonnel and also enforces physical proximitty access control
restricting entries onlyy to authorized personnel.
Version 4.0.0
Tier 3 (Onwards):
• Physical access is restricted by implementing mechanisms to control access

from one area of the facility to another or access into high-security
high security zones.
• Enables two ffactor authentications (biometrics and physical

cal pproximity). The
receiving
ng and ddispatch are carried out in this area.
• Media are stored securely. Backup media are also stored in a separate location
that is physically secure and protected from fire and water damages.
• Certificate issuance
uance and revocation is done in the high security zone housing the
Certificate Maanager server. The Key Ceremony also is carried out in the high
security core zone
zone. The HSM module is housed in the high security core zone.
• Manual /automated access control mechanisms has been implemented to restrict

access to trusted members only on a need to know and need to use basis.
5.1.2. Physical Access
5.1.2.1. CA Physical A
Access
CA has impleemented mechanism to protect equipments from f unauthorized

access. The phhysical security requirements laid down for the CA
C equipment are:
1. No unautho
horized access to the hardware is permitted
2. All removabable media and paper containing sensitive plain--text information is

stored in seecure containers
3. All entry/ex
exits are monitored either manually or electronica
cally.
4. Access logs
ogs are maintained and inspected periodically.
5. Multiple laayers of increasing security are provided in

i areas such as
perimeter,, building,
bu and CA room
6. Two personson physical access controls are required to bothh the cryptographic
modulee and co computer system for CAs issuing Class 1, Cllass 2 and Class 3
certificatess.
5.1.3. Power and Air Conditioning

Version 4.0.0
CAs secure facilities are equipped with primary and backup power systems to ensure
continuous, uninterrup
upted access to electric power and also these seecure facilities are
equipped with airr cond
conditioning systems to control temperature and relaative humidity.
PKI Repositories are provided with Uninterrupted Power sufficient for a minimum of
24 hours operation in
i the absence of commercial power, to o support
suppo continuity of
operations.
5.1.4. Water Exposures
CA locations are reassonably protected against floods and other dam

maging exposure to
water.
5.1.5. Fire Prevention & Protection
CA facility is equipped
pped to prevent and extinguish fires. Appropriatee procedures have
also been implementeded to minimize the damage due to smoke and fire exposure.
These measures also mmeet all applicable fire safety regulations.
5.1.6. Media Storage
All media containing ng production software and data, audit, arch chive, or backup
information are stored
ed within CA facilities and also in a securee off-site storage
facility with appropri
riate physical and logical access controls designed
gned to limit access
only authorized persoonnel and protect such media from accidental damage
da (e.g., water,
fire, and electromagne
agnetic exposure).
5.1.7. Waste Disposal
Sensitive documents and materials are shredded before disposal. Meddia used to collect
or transmit sensitivve information are rendered unreadablee bbefore disposal.
Cryptographic devices
ces aare physically destroyed or zeroed in accoccordance with the
manufacturer’s guidance
dance prior to disposal. Other waste is disposed
ed of in accordance
with the CA’s normal waste disposal requirements.
5.1.8. Off-Site backup
Full system backups of the CAs sufficient to recover from system failure,
f are created
on a periodic scheduule, and incrementally backup copies are stoored at an offsite
location. Backups aree performed and stored off-site not less than once
o every 7 days.
The data is properly seecured based on the classification of data, which
ch is defined by the
Certifying Authority inn the security policy.
5.2. Procedural Controls

Version 4.0.0
5.2.1. Trusted Roles
CA ensures that
1. The person filling

ng the role is trustworthy and properly trained.
2. The functions are distributed among more than one person, so that
t any malicious
activity would requ
equire collusion.
CA operations are carri

rried out by four roles which are listed below:
1. CA Administrator or – authorized to install, configure, and maintain

m the CA;
establish and maaintain user accounts; configure profiles and audit parameters;
and generate keyys runnel for section system communication.
2. CA Officer – authorized to verify and approve certifica

cates or certificate
revocations.
3. Audit Administraator – authorized to view and maintain audit logs.

ogs.
4. System Administtrator – authorized to perform system backup

kup and
a recovery. The
following sections
ons define these and other trusted roles.
5.2.1.1. CA Administrator
rator
The administrattor is responsible for:
1. Installation,
on, con
configuration, and maintenance of the CA;
2. Establishing
ng and maintaining CA system accounts;
3. Configuring
ng certificate profiles or templates and audit param
meters, and;
4. Generating and backing up CA keys.
Administrators shall not issue certificates to subscribers.
5.2.1.2. CA Officer
The CA officer
cer is responsible for issuing certificates, that is:
1. Registering
ng new subscribers and requesting the issuance of certificates;
ce
Version 4.0.0
2. Verifying the identity of subscribers and accuracy

acy of information
included inn certificates;
ce
3. Approving
ng aand executing the issuance of certificates, and;
4. Requesting,
ng, approving and executing the revocation of certifi
rtificates.
5.2.1.3. Audit Administrator
The Audit Adm

ministrator is responsible for:
1. Reviewing,
ng, maintaining, and archiving audit logs;
2. Performing
ng or overseeing
o internal compliance audits to
o ensure that the CA is
operating inn acco
accordance with its CPS;
5.2.1.4. System Administrator
The System Addministrator is responsible for the routine operation

ope of the CA
equipment
ent and opera
operations such as system backups and reco overy or changing
recording media.
a.
5.2.1.5. Organizational Registration Authority
onal RA, the responsibilities are:

For organizational
1. Verifying orrganizational identity of the applicant.
2. Entering applicants
app information, and verifying correctness;
3. Securely coommunicating requests and responses from/to the

he CA;
The roles of RAs

R engaged by CAs are limited only to the he collection
co of DSC
application form
m and supporting documents and facilitation of issuance
i of DSC to
applicants.
5.2.1.6. PKI Sponsor
A PKII Sponsor fills the role of a Subscriber for non-human sy

ystem components
that are named
ed as public key certificate subjects. The PK KI Sponsor works
with the CAs to register components (routers, firewalls, ettc.) in accordance
with Section 3.2.3.1, and is responsible for meeting thhe obligations of
Subscribers as de
defined throughout this document.
Version 4.0.0
5.2.2. Number of Persons R

Required per Task
Separate individuals are

a identified for each trusted role to ensure the integrity
i of the CA
operations. Two or more
m persons are required to perform the foollowing tasks for
CAs that issue Classs 1, Class 2 or Class 3 certificates:
1. CA key generation;
on;
2. CA signing key activation;

ac and
3. CA private key backup.
In addition, sensitivee CA operations like operations of the cryptog ographic units and
certificate manager requ
equires the m-out-of-n control to handle the operations
ope of these
sensitive functions. A
Also split control is implemented to ensure seg gregations between
physical and logical acc
access to systems. Personnel having secret shares
sh do not have
physical access and vice-versa.
v All roles are assigned to multiplee pe
persons in order to
support continuity of ope
operations.
5.2.3. Identification and Authe

Authentication for Each Role
All personnel seeking

ng to become trusted persons are required to be in the payroll of
CA. Thorough backgrround checks are carried out prior to engaging such
su personnel for
CA Operations. The he Certifying Authority follow the proceduocedures approved by
management for the
he backg
background check and there are documented for audit
a purpose.
CA ensures that perrsonnel have achieved trusted status and approval

app has been
given before such perssonnel are:
• Issued access deviices and granted access to the required facilities

• Issued electronicc ccredentials to access and perform specific func
unctions on CA’s IT
systems.
5.2.4. Roles Requiring Sepaaration of Duties
5.2.4.1. Class 1, Class 2 aand Class 3
Role separation
on is enforced either by the CA equipment, or procedurally, or
by both means.. Individuals may assume more than one role, exc
xcept:
1. Individualss who assume an Officer role will not assume CA

A Administrator or
Audit Admiinistrator role;
Version 4.0.0
2. Individualss who assume an Audit Administrator role wil

ill not assume any
other rolee on the CA; and
3. Under no ccircumstances any of the four roles willl perform

pe its own
compliance
ance aud
audit function.
No individual will
wil be assigned more than one role.
5.3. Personnel Controls
5.3.1. Qualifications, Experien

perience, and Clearance Requirements
All persons filling trus

usted roles shall be selected on the basis of trus
ustworthiness, and
integrity, and shall be subject to background investigation. Personnel
nnel will be appointed
to trusted roles (CA trus
usted roles) on the basis of :
1. Having successfull
lly completed an appropriate training program;
2. Having demonstraated the ability to perform their duties;
3. Being trustworthy;;
4. Having no other duties that would interfere or conflict with their duties for the
trusted role;
5. Having not been previously relieved of duties for reasons of negligence or non-
performance of duties;
6. Having not been denied a security clearance, or had a security clearance revoked
for cause;
7. Having not been convicted of an offense; and
8. Being appointed in writing by an appointing authority.
5.3.2. Background Check P

Procedures
All persons filling trususted roles (including CA trusted roles trusted

ed roles) shall have
completed a favorablee background investigation. The scope of the background
backg check
shall include the folloowing areas covering the past five years:
1. Employment;
2. Education (Regarddless of the date of award, the highest educational

onal degree shall be
verified);
Version 4.0.0
3. Place of residence (3 years);
4. Law Enforcement;; and
5. References
The results of these checks

c will not be released except as required in
n Sections
Sec 9.3 and
9.4
The background will be verified every three years.
5.3.3. Training Requiremen

ents
CA ensures that alll personnel

pe performing duties with respect to thee operation
o of a CA
receive comprehensivee training. Training will be conducted in the foll
llowing areas:
1. CA security princiiples and mechanisms
2. All PKI software versions

v in use on the CA system
3. All PKI duties theyy are expected to perform
4. Disaster recovery and business

bu continuity procedures.
5. Subscriber verifica
cation requirements
5.3.4. Retraining Frequency and Requirements
Training (awareness)s) is conducted to make the trusted personnel

personn aware of any
significant change to the operations, and the executions of such plann are documented.
Such changes aree CA software or hardware upgrade, changes in automated
au security
systems, and relocation
on of equipment.
Periodic security awarreness and any new technology changes training

ng is provided on an
ongoing basis, based on the newer versions or releases of the products.
s.
5.3.5. Job Rotation Frequency and Sequence
No stipulation.
5.3.6. Sanctions for Unautho

horized Actions
CA will take appropri riate administrative and disciplinary actions agaiinst personnel who
violate this policy. Acction taken and will be documented.
Version 4.0.0
5.3.7. Documentation Supp

plied To Personnel
All the relevant documments relating to CA operation required for trus

usted personnel to
perform their duties such as Certificate Policy, the applicable CPS,C Verification
Guidelines, user Manua
anuals , Administrator Manual, policies or contrac
acts etc. are made
available to CA personn
sonnel. CA maintains the documents identifying all personnel who
received training and the level of training completed.
5.4. Audit Logging Procedures
Audit log files are generatted for all events relating to the security of the CAs. The security
audit logs either automaticcally collected or if not possible, a logbook, paper form, or other
physical mechanism are used.
us All security audits logs, both electronic and
a non-electronic,
are retained and made avaailable during compliance audits. The securityy audit
aud logs for each
auditable event defined in this
t section shall be maintained in accordance with w Section 5.5.2.
5.4.1. Types of Events Recoorded
All security auditing capab

capabilities of the CA operating system and the
he CA applications
required by this CPS are enabled. Each audit record shall include the
he following (either
recorded automaticallyy or manually for each auditable event):
1. The type of event,
2. The date and time the event occurred,
3. Success or failure where appropriate

appropriate, and
4. The identity of the entity and/or operator that caused the event. The following
events shall be audited:
Auditable Event CA
SECURITY AUDIT T
Any changes to the Audit
A parameters, e.g., audit frequency, type
of event audited
Any attempt to delete
elete or modify the Audit logs
IDENTITY-PROOF FING
Successful and unsucccessful attempts to assume a role
The value of maximximum number of authentication attempts is
changed
The number of unsucccessful authentication attempts exceeds the
maximum
authentication attemppts during user login
Version 4.0.0
An Administrator unnlocks an account that has been locked as a

result of unsuccessfuul authentication attempts
An Administrator chhanges the type of authenticator, e.g., from a
password to a biomet etric
LOCAL DATA ENT TRY
All security-relevant data that is entered in the system
REMOTE DATA ENTRY E
All security-relevant messages that are received by the system
DATA EXPORT AN ND OUTPUT
All successful and unsuccessful
u requests for confidential and
security-relevant infoormation
KEY GENERATIO ON
Whenever the Compo ponent generates a key (not mandatory for
single session or one-- time use symmetric keys)
PRIVATE KEY LO OAD AND STORAGE
The loading of Compponent private keys
All access to certificate
tificate subject Private Keys retained within the
CA for key recoveryy purposes
TRUSTED PUBLI LIC KEY ENTRY, DELETION AND
STORAGE
All changes to thee trusted
tr Component Public Keys, including
additions and deletion ons
PRIVATE AND SEC CRET KEY EXPORT
The export of private ate and secret keys (keys used for a single
session or message arre excluded)
CERTIFICATE RE EGISTRATION
All certificate requests ts
CERTIFICATE RE EVOCATION
All certificate revocaation requests
CERTIFICATE ST TATUS CHANGE APPROVAL
The approval or rejecction of a certificate status change request
CONFIGURATION N
Any security-relevaant changes to the configuration of the
Component
ACCOUNT ADMINI NISTRATION
Roles and users are added
a or deleted
The access control privileges of a user account or a role are
modified
CERTIFICATE PR PROFILE MANAGEMENT
All changes to the cer ertificate profile
CERTIFICATE ST TATUS PROVIDERMANAGEMENT
All changes to the CSP SP profile (e.g. OCSP profile)
REVOCATION PROFILE PR MANAGEMENT
All changes to the revvocation profile
Version 4.0.0
CERTIFICATE REVOCATION LIST PROFILE

MANAGEMENT
All changes to the cer
ertificate revocation list profile
MISCELLANEOUS S
Appointment of an inndividual to a Trusted Role
Designation of persononnel for multiparty control
Installation of the Opperating System
Installation of the PKI
KI Application
Installation of hardwaare cryptographic modules
Removal of hardwaree cryptographic modules
Destruction of cryptoographic modules
System Startup
Logon attempts to PKI KI Application
Receipt of hardware / software
Attempts to set passw words
Attempts to modify ppasswords
Back up of the internnal CA database
Restoration from bacck up of the internal CA database
File manipulation (e.gg., creation, renaming, moving)
Posting of any materialial to a PKI Repository
Access to the internal
al CA database
All certificate comproomise notification requests
Loading tokens with certificates
Shipment of Tokens
Zeroizing Tokens
Re-key of the Compoonent
CONFIGURATION N CHANGES
Hardware
Software
Operating System
Patches
Security Profiles
PHYSICAL ACCESS SS / SITE SECURITY
Personnel Access to room
roo housing Component
Access to the Compo ponent
Known or suspected vviolations of physical security
ANOMALIES
Software error conditio
itions
Software check integgrity failures
Receipt of improper messages
m
Misrouted messages
Network attacks (susppected or confirmed)
Equipment failure
Electrical power outaages
Version 4.0.0
Uninterruptible Powerer Supply (UPS) failure

Obvious and significa
ificant network service or access failures
Violations of Certificate
icate Policy
Violations of Certificati
ication Practice Statement
Resetting Operating SSystem clock
5.4.2. Frequency of Process

Processing Audit Logs
Audit logs are examined

ned for key security and operational events at least on a weekly
basis. In addition, C
CA reviews its audit logs as required in the t event of any
suspicious or unusuall activity
ac based on irregularities and incidents wit
ithin CA systems.
The processing of aud udit logs includes a review of the audit logs and recording of
significant events in an audit log summary. It includes a verification that
t the log has not
been tampered with, a brief inspection of all log entries, and a detaailed investigation
of any irregularities inn the logs. Actions taken based on audit log revieews are recorded.
5.4.3. Retention Period forr Aud

Audit Logs
See Section 2.
5.4.4. Protection of Audit L

Logs
System configuration
on and procedures are implemented together to enssure that:
1. Only authorized
zed peop
people have read access to the logs;
2. Only authorized
zed peop
people may archive audit logs; and,
3. Audit logs are not modified.
After back-up and arch

chived, the audit logs are allowed by the system to
t be over-written.
5.4.5. Audit Log Backup Pro

rocedures
Audit logs and audit summaries

su shall be archived as per Section
on 5.5.1.
5.4.6. Audit Collection Systtem (internal vs. external)
Automated audit datta is generated and recorded at the applicati tion, network and
operating system levell. Manually generated audit data is recorded by CA personnel.
Version 4.0.0
Audit processes are innvoked at system startup, and cease only at sysstem shutdown. In
the case of failure of audit collection system, CA operations are suspended
su until the
problem is remedied.
5.4.7. Notification to Event

ent-Causing Subject
This CPS imposes no requirement to provide notice (that an event was w audited) to the
individual, organization,
on, device,
de or application that caused the event.
5.4.8. Vulnerability Assessm

ments
Events in the audit log

l are recorded, in part, to monitor system vulnerabilities. A
vulnerability assessment
ent is performed, reviewed, and revised following
ng an examination
of these monitored even
ents.
5.5. Records Archival
5.5.1. Types of Records Arc

Archived
CA retains an archivee of information and actions that are material al to each certificate
application and to thehe ccreation, Issuance, revocation, expiration,
on, and renewal of each
certificate issued by the
he CCA. These records include all relevant evidence
dence regarding:
Data To Be Archived
Certification Practice
tice Statement
Contractual obligatiions
System and equipmeent configuration
Modifications and uupdates to system or configuration
Certificate requests
Revocation requests
ests
Subscriber identity authentication
a data as per Section 3.2.3
Documentation of reeceipt and acceptance of certificates
Documentation of reeceipt of Tokens
All certificates issued
ed or published
Record of Componeent CA Re-key
All CRLs and CRLss issued and/or published
All Audit Logs
All Audit Log Summ maries
Other data or applic
lications to verify archive contents
Compliance audit reeports
Version 4.0.0
5.5.2. Retention Period forr Ar

Archive
Records associated with

wi certificates are archived for a period of 7 yea
ears from the date
of expiry of the certifiicate.
5.5.3. Protection of Archive

ve
CA protects its arch chived records so that only authorized persons sons can access the
archived data. CA prrotects the archive against unauthorized viewi wing, modification,
deletion, or other tampe
pering, by storage within a trustworthy system. The media holding
the archive data and the
t systems required to process the archive dataa are maintained to
ensure that the archivee data can be accessed for the time period
5.5.4. Archive Backup Proced

cedures
CA creates back-up copies

c of archives compiled as and when the arch chives are created.
Backup copies of the he aarchive and copies of paper-based records aree maintained in an
off-site disaster recovvery/ warehouse facility. CA has implemented a process to scan
and digitize the physiccal documents to ensure tracking and easy retrievval.
5.5.5. Requirements for Tim

ime-Stamping of Records
Archived records are ti

time stamped such that order of events can be deetermined.
Certificates, CRLs, otther revocation databases and usage entries con

ntain time and date
information provided
ded by System time, which is synchronized with ISTST (NPLI).
5.5.6. Archive Collection Syst

ystem (internal or external)
The archive collection

on system is internal to the CA.
5.5.7. Procedures to Obtain

n & Verify Archive Information
Only CA trusted personn

sonnel are permitted to access the archived data.
a. Additionally, the
archive information m
may be made available to the CCA upon request.
5.6. Key Changeover
CA keys are changed peri riodically as stipulated by the IT Act and thehe key changes are
a
processed as per key generation
gene specified in this CPS. If CA private keey is used to sign
CRLs, then the key shall be retained and protected.
CA provides reasonable notice

no to the subscriber’s relying parties of any change to a new key
pair used by CA to sign digital certificates under its trust hierarchy. The subscribers is
Version 4.0.0
issued digital certificate for a specified period of time. The subscriberss generates a new
private-public key pair and submit the public key along with the new app pplication to the CA
for generating a new Certifi
rtificate, preferably before the existing certificatee expires.
exp
The following table providdes the life times for certificates and associated private
p keys.
Key 2048 Bit Keys

Private Key Certificate
Ce
Intermediate CA 10 years 10 years
Time Stamping 3 years 3 years
OCSP Responder 1 years 1 years
Human Subscriber Signa
gnature 3 years 3 years
Human Subscriber Encr
Encryption Always 3 years
Device/System 3 years 3 years
5.7. Compromise and Disaster Recovery
5.7.1. Incident and Comprom

omise Handling Procedures
If a CA detects a potential
po hacking attempt or other form of co ompromise, it will
perform an investigatiion in order to determine the nature and the degree
d of damage.
If the CA key is susspected of compromise, the procedures outlined ned in Section 5.7.3
shall be followed. Othe
herwise, the scope of potential damage shall be assessed in order
to determine if the CCA needs to be rebuilt, only some certificates need to be revoked,
and/or the CA key needs to be declared compromised.
CA will inform CCA if

i any of the following cases occur:
1. Suspected or detec
ected compromise of the CA system;
2. Physical or electron
onic attempts to penetrate the CA system;
3. Denial of service
ce aattacks on the CA system; or
4. Any incident prevventing CA from issuing a CRL within 24 hours hou of the time
specified in the next update field of its currently valid CRL. A CA will make all
efforts to restoree capability
capab to issue CRL as quickly as possible.
5.7.2. Computing Resourcees, Software, and/or Data are Corrupted
CA have a Disaster Recovery center as per the guidelines of IT Act. Act The disaster
recovery site will be made
m operational using the latest available backup
up data.
da
Version 4.0.0
If CA equipment is damaged
d or rendered inoperative, but the signa
gnature keys are not
destroyed, CA makes all efforts to establish the operation as quickly
y as possible, giving
priority to the ability to generate CRL or make use of Disaster Reco ecovery facility for
CRL generation.
If both primary and Disaster recovery sites cannot be used to est

stablish revocation
capability in a reasonab
onable time-frame, the CA may request for
or revocation of its
certificate(s) to CCA.
5.7.3. Private Key Comprom

promise Procedures
If CA signature keys are

ar compromised, lost, or suspected to be comproomised:
CCA shall be notified

ed at the earliest feasible time so that RCAI can revoke the CA
certificate;
1. A CA key pair shalall be generated by CA in accordance with procedu

ocedures set forth in
this applicable CPS;
PS;
2. New CA certificacates shall be requested in accordance with the

he initial registration
process set elsewhe
here in this CP;
3. If the CA can obttain accurate information on the certificates it has issued and that
are still valid (i.e.,
.e., not expired or revoked), the CA may re-issue ue (i.e., renew) those
certificates with the
he not After date in the certificate as in original certificates;
ce and
4. The CA shall also

so investigate what caused the compromise
se or loss, and what
measures must be taken to preclude recurrence.
5.7.4. Business Continuityy Capabilities

Cap after a Disaster
In the case of a disastter whereby CA installation is physically damaged

aged and all copies
of the CA Signing Key are destroyed as a result, the CA shalll request that its
certificates be revokedd. The CA shall follow steps 1 through 4 in Secti
tion 5.7.3 above.
5.8. CA Termination
In the event of termination C

CA will revoke all certificates issued.
CA will archive all audit loogs and other records prior to termination. CA will destroy all its
private keys upon termination.
on.
Version 4.0.0
6. Technical Security Controls
6.1. Key Pair Generation and Installation
6.1.1. Key Pair Generation

on
The following tablee provides

p the requirements for key pair generati
tion for the various
entities.
Entity FIPS 140-1/2 Hardware or Generated

Level Software in Entity
Module
CA 3 Hardware Yes
Time Stamp Authority 3 Hardware Yes
OCSP Responder 1 Hardware Yes
RA 2 Hardware Yes
Human Subscriber 1 for Class 1 Software for Class 1 Yes
Signature
2 for Class 2 & 3 Hardware for Class 2 &
3
Human Subscriber 1 for Class 1 Software for Class 1 No
Encryption Requiremen
2 for Class 2 & 3 Hardware for Class 2 & t
3
Device/System 2 for Class 3 Software for Class 2 Yes
Hardware for Class 3

Document Signer 2 for Class 3 Software for Class 2 Yes
Hardware for Class 3
Multiparty controls are

ar used by CA for key pair generation,
on, as specified
sp in Section
5.2.2.
CA creates a verifiab able audit trail for key pair generation as per the security
requirements Procedu
cedures which are followed and the same will be documented. The
process is validated byy an Auditor.
6.1.2. Private Key Delivery

ivery to Subscriber
Subscriber private keyy is generated by the end subscriber and hence the
here is no delivery
to the end subscriberrs. In the case of hardware based tokens or smart cards, pre-
formatted tokens are sent
s to the subscribers and the associated PIN is sent by an out-
of-band process. The end user then uses the token and the client sofftware provided to
Version 4.0.0
him to generate and sstore the private key and also initiates an online
ne session with the
CA server for certifica
cate generation.
6.1.3. Public Key Delivery

ry to C
Certificate Issuer
End user subscribers generate a PKCS#10 requests containing their public key and send
it to the CA. This is accomplished using the client software which initiates an online
session with the CA server and deliver the signed certificates to the subscriber. The
online session is secured by SSL.
6.1.4. CA Public Key Delive

very to Relying Parties
CA makes its Publicc Keys available to relying parties in reposit

sitory available at
https://prodigisign.com/repository/cer/
6.1.5. Key Sizes
The key length and hash

h algorithms used by CA and subscriber certifi
rtificates are given
below
Cryptographic Function
Func Cryptographic Algorithm
Signature 2048-bit RSA or ECDSA with -p256p256
curve parameter
Hashing SHA-256
6.1.6. Public Key Parameteers Generation and Quality Checking
RSA and ECC keys ar

are generated in accordance with FIPS 186-2.
6.1.7. Key Usage Purposess (as per X.509 v3 key usage field)
Key usages are covered

ed in certificate profiles defined in CCA-IOG.
6.2. Private Key Protection and Cryptographic Module Engineering Controls
6.2.1. Cryptographic Modu

ule Standards and Controls
The relevant standarrd for cryptographic modules is FIPS PUB

B 140-2, Security
Requirements foror CCryptographic Modules. The additional
onal requirements for
cryptographic modules
es are
a covered in CCA-CRYPTO
The table in Section 6.1.1 summarizes the minimum requirements for cryptographic
modules; higher levelss may be used.
Version 4.0.0
6.2.2. Private Key Multi-Person

erson Cont
Control
Use of a CA private signing

si key requires action by at least two person
sons.
6.2.3. Private Key Escrow
CA creates backup of its signature keys. These are stored in encrypted form and under
the sole custody of CA.
The end entity private keys used solely for decryption are escrowed prior to the
generation of the corresponding certificates. The subscriber can keep the escrowed
keys.
6.2.4. Private Key Backup
6.2.4.1. Backup of CA Private Signature Key
CA private signa
gnature keys are backed up under the same multii-person control as
the original signa
gnature key. Numbers of backup copies are lim mited to three and
securely stored under the same multi-person control as the operrational key.
6.2.4.2. Backup of Subscriber

ubscriber Private Signature Key
The CA is nevver in possession of Subscribers private signing

ng keys.
ke
6.2.5. Private Key Archival

val
At the end of the vali

lidity period, CA private key will be destroyed
ed and will not be
archived.
6.2.6. Private Key Transfer

er into or from a Cryptographic Module
CA key pairs are gene

enerated and secured by hardware cryptograph
aphic modules. CA
ensures that The CA private keys are backed up in secure manner and transferred in
an encrypted form.
6.2.7. Private Key Storage

orage on Cryptographic Module
CA stores Private Keyys in hardware cryptographic module and keys are not accessible
without authentication
on mechanism that is in compliance with FIPS 140-2
14 rating of the
cryptographic module.e.
Version 4.0.0
6.2.8. Method of Activating

ng Private Key
The user must be authenticated

au to the cryptographic module befo fore the activation
of any private key(s). Acceptable means of authentication include ude but are not limited to
pass-phrases, Personal
onal Identification Numbers (PINs) or biom metrics. Entry of
activation data is prottected from disclosure (i.e., the data should not be
b displayed while
it is entered).
6.2.9. Methods of Deactivati

ting Private Key
Cryptographic modulee that has been activated is never left unattended ended or otherwise
available to unauthori rized access. After use, cryptographic modulees are deactivated.
After deactivation, the
he use of the cryptographic modules based CA key pair pa requires the
presence of the trusted
ed roles with the activation data in order to reacttivate said CA key
pair.
6.2.10. Method of Destroying

ng Private Key
Private signature keyss will be destroyed when they are no longer needed,
ne or when the
certificates to which they correspond expire or are revoked. Destr stroying private key
inside cryptographic mmodules requires destroying the key(s) inside the he HSM using the
‘zeroization’ function of the cryptographic modules in a manner that hat any information
cannot be used to reco
ecover any part of the private key. All the privatee key
k back-ups are
destroyed in a manner
anner that any information cannot be used to recovver any part of the
private key. If the func
unctions of cryptographic modules are not acceessible in order to
destroy the key contaained inside, then the cryptographic modules will wil be physically
destroyed. The destruc
uction operation is realized in a physically securee environment
en
6.2.11. Cryptographic Modu

ule Rating
See Section 6.2.1.
6.3. Other Aspects Of Key Maanagement
6.3.1. Public Key Archival
The public key is arch

chived as part of the certificate archival.
6.3.2. Certificate Operation

nal Periods/Key Usage Periods
See Section 5.6

Version 4.0.0
6.4. Activation Data
6.4.1. Activation Data Gener

eration and Installation
The activation data usused to unlock private keys is protected from

om disclosure by a
combination of cryptog
ographic and physical access control mechanismms. Activation data
holders are responsiblee for their accountability and protection.
When they are not used,

ed, activation data are always stored in a safe for
f which access is
controlled by holders in
i limited roles.
6.4.2. Activation Data Prottection
The activation data useed to unlock private keys is protected from discl
closure.
After a predetermined
ned nnumber of failed login attempts, a facility to
o lock the account
temporarily has been pprovided.
The activation data writt

written on paper is stored securely in a safe.
6.4.3. Other Aspects of Acttivation Data
CA changes the acti tivation data whenever the HSM is re-keyed or returned from
maintenance. Before sending a cryptographic module for maintenanenance, all sensitive
information contained
ned in the cryptographic module is destroyed.
Subscribers are respons

onsible to ensure the protection of their activation
on data
da
6.5. Computer Security Contrrols
6.5.1. Specific Computer Secu

ecurity Technical Requirements
The following compuputer security functions are provided by the operating

ope system, or
through a combination
on of ope
operating system, software, and physical saffeguards.
1. Require authentica
cated logins for trusted roles
2. Provide Discretiona
onary Access Control
3. Provide a security audit capability
4. Require a trusted path

pa for identification and authentication
5. Provide domain iso

solation for process
Version 4.0.0
6. Provide self-protec
ection for the operating system
CA computer systemss are configured with minimum required accoun

ounts and network
services.
CA has implemented ed a combination of physical and logical secu curity controls to

ensure that the CA ad
administration is net carried out with less than twoo person
p control.
6.5.2. Computer Securityy Rating

Ra
Not applicable.
6.6. Life-Cycle
Cycle Technical Controls
6.6.1. System Developmentt Controls

The system developm
ment controls for the CA are as follows:
1. Hardware and software

so are purchased in such a way so as to reduce the
likelihood that any particular component was tampered with.
2. All hardware must

ust be shipped or delivered via controlled metthods that provide
a continuous chaiin of accountability, from the purchase location
on to the operations
location
3. The hardware and nd software are dedicated to performing the PK

KI activities. There
are no other applilications; hardware devices, network connections,
ons, or component
software installed
ed which is not part of the PKI operation.
4. Proper care is taken

aken to prevent malicious software from being
ng loaded onto the
equipment. Onlyy applications required performing the PK KI operations is
obtained from sou
sources authorized by local policy.
5. CA hardware annd software are scanned for malicious

us code on first use and
periodically therea
eafter.
6.6.2. Security Managemen

nt Controls
The configuration of the CA system as well as any modification on and upgrade is

documented and con controlled. There is a mechanism for detecti ting unauthorized
modification to the CA so
software or configuration. A formal configurration management
methodology is used for installation and ongoing maintenance of thehe CA system. The
CA software, when first loaded, is verified as being that supplieded from the vendor,
with no modifications,
ons, and be the version intended for use.
Version 4.0.0
6.6.3. Life Cycle Security Controls

Cont
Capacity demands arre monitored and projections of future capacity

capa requirements
made to ensure that adequate
ade processing power and storage are availab
able.
6.7. Network Security Controls

ols
CA employs appropriate seecurity measures to ensure that they are guardedded against denial of
service and intrusion attack
acks. Such measures include the use of hardware firewalls,
fir hardware
filtering routers, and intrus
usion detection systems. Unused network portss and services are
turned off. Protocols that provide
p network security attack vector(s) is not permitted through
the boundary control deviceces.
Any boundary control devvices used to protect the network on which PKI equipment is
hosted will deny all but the necessary services to the PKI equipment
ent even if those
services are enabled for other
her devices on the network.
6.8. Time Stamping
All CA components are regularly synchronized with a time service ce such as Indian
Standard Time Service. Tim
me derived from the time service is used for est
stablishing the time
of:
• Initial validity time of a Sub

Subscriber’s Certificate
• Revocation of a Subscricriber’s Certificate
• Posting of CRL updates es
• OCSP
Asserted times is accuratee to within three minutes. Electronic or manual

anual procedures are
used to maintain system time.
ti Clock adjustments are auditable events ass listed in Section
5.4.1.
Version 4.0.0
7. Certificate, CRL and OCSP

SP Profiles
7.1. Certificate Profile
Certificate profiles are listed under CCA-IOG,

CCA Annexure III - Reference Certificate Profiles. The
CA Certificates issued under this CPS conform to X
X-509
509 Version 3 digital Certificate.
The End User Certificate Profile (issued for personal use) and CA cert
certificate
ificate profiles are listed
below
1. CA Certificate Profile
CA CERTIFICATE -BASIC FIELDS

Version Version 3
Serial number Positive number of maximum Length 20 bytes and unique to each
certificate issued by issuer CA
Signature Algorithm SHA256 with RSA Encryption (null parameters)
Issuer DN Subject DN of the issuing CA

Validity Validity expressed in UTC Time for certificates valid through
2049
Subject DN The X.500 distinguished name of the entity associated with the
public key certified in the subject public key field of the
certificate (Common Name (CN),House Identifier, Street
Address, State / Province, Postal Code, Organisational Unit
(OU),Organisation (O),Country (C) )
Subject Public Key rsaEncryption {1 2 840 113549 1 1 1}, 2048 RSA Key modulus,
public exponent
Signature Issuer CA’s signature
EXTENSIONS
authorityKeyIdentifier Identifies the CA certificate that must be used to verify the
CA certificate. It contains subjectKeyIdentifier of the issuing
CA certificate
subjectKeyIdentifier unique value associated with the Public key
basicConstraints CA Boolean = True, pathLenConstraints 0
keyUsage keyCertSign and cRLSign
certificatePolicies The value must contain the OID representing the India PKI
certificate policy the certificate is valid for . (Policy
Identifier=2.16.356.100.2)
cRLDistributionPoints location of CRL information
authorityInfoAccess location of OCSP Responder (only required if OCSP is
needed to check revocation status of CA Certificate)
2. User Certificate Profile(personal)
END ENTITY CERTIFICATE -BASIC FIELDS

Version 4.0.0
Version Version 3
Serial number Positive number of maximum Length 20 bytes and unique to each
certificate issued by a issuer CA
Signature Algorithm SHA256 with RSA Encryption (null parameters)
or
ECDSA with SHA256 {1 2 840 10045 4 3 2}
Issuer DN Subject DN of the issuing CA
Validity Validity expressed in UTC Time for certificates valid through 2049
Subject DN The X.500 distinguished name of the entity associated with the
public key certified in the subject public key field of the certificate
( Common Name, Serial Number,State or Province Name, Postal
Code, Telephone number, PseudPseudonym,
onym, Organisation, Country)
Subject Public Key rsaEncryption {1 2 840 113549 1 1 1}, 2048 RSA Key modulus,
public exponent OR
ecPublicKey { 1.2.840.10045.2.1}, namedCurve, {
1.2.840.10045.3.1.7} (NIST curve P P-256)
Signature Issuer CA’s signature
EXTENSIONS
authorityKeyIdentifier Identifies the CA certificate that must be used to verify the
subscriber’s certificate. Issuing CA SubjectkeyIndetifier
subjectKeyIdentifier Octet String of unique value associated with the Public key
basicConstraints CA=False
keyUsage DigitalSignature, nonRepudiation(optional)
Extended Key Usage Document Signing: {1.3.6.1.4.1.311.10.3.12}
certificatePolicies The value must contain the OID representing the India PKI
certificate policy the certificate is valid for .( (Policy
Identifier=2.16.356.100.2.4.1 or 2.16.356.100.2.4.2 )
cRLDistributionPoints location of CRL information
7.2. CRL Profile
The CRL profiles are listed

ed be
below.
7.2.1. Full and Complete

ete C
CRL
A CA makes a full and complete CRL available to the OCSP Respon ponders as specified
below. This CRL is prrovided to the relying parties and published on the
he repository.
repos
Field Value
Version V2 (1)
Issuer Signature sha256WithRSAEncryption {1 2 840
Algorithm 113549 1 1 11}
Version 4.0.0
Issuer Distinguishedd Per the requirements in [CCA-IOG]

Name
this Update expressed in UTC Time until 2049
Next Update expressed in UTC Time until 2049 (>=
this Update + CRL
issuance frequency)
Revoked certificates
es 0 or more 2-tuple of certificate serial
list number and revocation date (in
Generalized Time)
Issuer’s Signature sha256 With RSA Encryption {1 2 8400
113549 1 1 11}
CRL Extension Value
CRL Number c=no; monotonically increasing integer
(never repeated)
Authority Key c=no; Octet String (same as in Authority y
Identifier Key Identifier field in certificates issued
ued
by the CA)
CRL Entry Extensiion Value
Reason Code c=no; optional
7.2.2. Distribution Point Bas

Based Partitioned CRL
CA issues only full and co

complete CRL signed by CA
7.3. OCSP Profile
OCSP requests and respons

ponses are in accordance with RFC 2560 as listed
ed below.
be
7.3.1. OCSP Request Form

mat
Requests sent to Issueruer CA OCSP Responders are not required to t be signed. The
following table lists the
he fields that are expected by the OCSP Responde
nder.
Field Value
Version V1 (0)
Requester Name DN of the requestor (required)
Request List List of certificates as specified in RFC 2560
Request Extension Value
None None
Request Ent
ntry Value
Extension
None None
7.3.2. OCSP Response Form

mat
Version 4.0.0
See RFC2560 for detaailed syntax. The following table lists which fieelds are populated
by the OCSP Responde
onder.
Field Value
Response Status As specified in RFC 2560
Response Type id-pkix-ocsp-basic {1 3 6 1 5 5 7 48 1 1}
Version V1 (0)
Responder ID Octet String (same as subject key iden
dentifier in
Responder certificate)
Produced At Generalized Time
List of Responses Each response will contain certificatee id; certificate
status1, this Update, next Update2,
Responder Signaturee sha256 With RSA Encryption {1 2 84 40 113549 1 1
11}
Certificates Applicable certificates issued to the OCSP
O Responder
Response Extension
on Value
Nonce c=no; Value in the nonce field of reque
equest (required, if
present in request)
Response Entry Value
Extension
None None
1
If the certificate is revoked, the OCSP Responder shalll provide revocation time and revocation reason from CRL entry and CRL entry extension.
2
The OCSP Responder shall use this Update and next Update
Up from CA CRL.
Version 4.0.0
8. Compliance Audit and Other Assessments
8.1. Frequency or Circumstan

ances of Assessments
Annual compliance audit by b CCA empanelled Auditor is carried out of CAs

C infrastructure
apart from half yearly interrnal audit
8.2. Identity and Qualification

ns of Assessor
CCA empanel auditors ba based on the competence in the field of compliance

co audits,
qualifications and thorough
ugh familiarity with requirements of the IT Act, CP and CPS. The
auditors perform such commpliance audits as per the terms of empanelment
ent and also under the
guidance of CCA
8.3. Assessor’s Relationship too Ass

Assessed Entity
The auditor is indepen

ndependent from the entity being audited. The office of CCA
determines whether an aud
auditor meets this requirement.
8.4. Topics Covered by Assessm

ssment
CA has a compliance audiit mechanism in place to ensure that the requireements of this CPS
are enforced.
8.5. Actions Taken as a Result

lt of Deficiency
Office of CCA may determ mine that a CA is not complying with its obliga
gations set forth in
this CPS or the applicable CP. When such a determination is made, the office
o of CCA may
suspend operation of CA A, or may revoke the CA certificate, or may ay direct that other
corrective actions be taken
aken which allow operation to continue.
When the auditor finds a discrepancy

d between how the CA is designed or is being operated
or maintained, and the requ
equirements of this CP, or the applicable CPS, the
he auditor
aud take the
following actions:
1. The auditor note the disscrepancy;
2. The auditor notify the

he aud
audited CA; and
3. The auditor notifies the

he office
o of CCA.
8.6. Communication of Results

lts
Version 4.0.0
On completion of audit by ann empanelled auditor, Auditor submit an Auditt Report, including
identification of corrective m
measures taken or being taken by CA, to the office
o of CCA and
a copy to CA. The report idenntifies the version of the CPS used for the assessm
ment.
Version 4.0.0
9. Other Business and Legal Matters

M
9.1. Fees
9.1.1. Certificate Issuancee and Renewal Fees
The fees for variousous types of certificates are made available on CA website at
https://prodigisign.com and will be updated from time to time.
9.1.2. Certificate Access

ss Fees
CA is not charging any fees to relying parties or other public for accessing the
certificate information
on from the repository. The certificate search facility
fac is provided
free of cost at its websit
site (https://prodigisign.com).
9.1.3. Revocation Status In

nformation Access Fees
CA does not charge a fee for access to any revocation status infformation through
CRL. CA may charge
ge a fee for providing certificate status information
on via OCSP.
9.1.4. Fees for Other Services
Not applicable
9.1.5. Refund Policy
The refund policycy and other payments terms are governed as per the terms in the
subscriber agreement.. In case the application is rejected the full amount would be
refunded to the subscri
riber.
9.2. Financial Responsibility
9.2.1. Insurance Coverage
CA maintain reasonab
onable levels of insurance coverage to address all fooreseeable liability
obligations to PKI Parti
rticipants described in Section 1.3 of this CPS
9.2.2. Other Assets
CA also maintains reasonable and sufficient financial resourrces to maintain

operations, fulfill duti
ties, and address commercially reasonable liabiility obligations to
PKI Participants descriribed in Section 1.3 of this CPS.
Version 4.0.0
9.2.3. Insurance or Warran

ranty Coverage for End-Entities
CA offers no protection
on to end entities that extends beyond the protec
ections provided in
this CPS
9.3. Confidentiality of Busine

ness Information
CA maintain the confidenti tiality of confidential business information that

hat is clearly marked
or labeled as confidential, or by its nature reasonably is understood to be confidential, and
treat such information wit
with the same degree of care and security as the CA treats its
own most confidential infoormation.
9.4. Privacy of Personal Infor

formation
CA stores, process, and disclose

d personally identifiable information inn accordance with
the provisions of IT Act
ct 2000 & Rules made there under.
9.5. Intellectual Property Righ

hts
CA will not knowingly vioolate any intellectual property rights held by othe
hers.
9.5.1. Property Rights in

n Ce
Certificates and Revocation Information
CAs claims all Intellec

ectual Property Rights in and to the Certificattes and revocation
information that theey issue. However, permission to reproduce oduce and distribute
Certificates and revoca
ocation information on a nonexclusive royalty y-free, world-wide
basis, may be granted
ed provided
p that the recipient agrees to distribute them
hem at no cost.
9.5.2. Property Rights in th

he CPS
This CPS is based on the Performa CPS published by Office of CCA for Licensed CAs
and as amended from om time-to-time. All Intellectual Property Rights in this CPS
pertaining to CA aree oowned by the CA.
9.5.3. Property Rights in

n Na
Names
CA may claim all righ ghts, if any, in any trademark, service mark, or trade name of
its services under the llaw for the time being in force.
9.5.4. Property Rights in K

Keys
Version 4.0.0
CA may claim properrty rights to the keys used (e.g., CA key pair, OCSP Responder
key pair, time stampp au
authority key pair, etc.) under the law for the timee being
be in force
Subject to any agreem ments between CA and its customers, ownershiip of and property
rights in key pairs corr
rresponding to Certificates of Subscribers is speccified in this CPS.
9.6. Representations and Warr

rranties
9.6.1. CA Representations
ons and Warranties
9.6.1.1. CA
CA represents and warrants in accordance with provisions of IT Act, 2000 &

Rules made therre under that;
1. signing privvate key is protected and that no unauthorized

zed person shall ever
has access to
t that private key;
2. Each Subscricriber has been required to represent

ent and warrant that all
information
on supplied by the Subscriber in connection with,
h, and/or contained
in the Certifi
tificate is true.
3. Only verified
ed information appears in the certificate
9.6.2. Subscriber
A Subscriber is requequired to sign a document (e.g., a subsccriber agreement)

containing the requir
irements the Subscriber shall meet respecting protection of the
private key and use of the certificate before being issued the certifica
cate.
In signing the
he docu
document described above, each Subscriberr should
shou agree to the
following:
1. Subscriber shall accurately

accu represent itself in all communicati
tions with the CA
conducted.
2. The data contained

ned in any certificates about Subscriber is accurate.
e.
3. The Subscriber sha hall protect its private key at all times, in accordance
acco with this
policy, as stipulated
ed in the certificate acceptance agreements, and local
l procedures
4. The Subscriber lawf

wfully holds the private key corresponding to puublic key identified
in the Subscriber’ss certificate.
Version 4.0.0
5. The Subscriber wilwill abide by all the terms, conditions, and restri
strictions levied on
the use of their pri
rivate keys and certificates.
6. Subscriber shall promptly

p notify the appropriate CA upon susspicion of loss or
compromise of the heir private keys. Such notification shall be made directly or
indirectly through
ough mechanisms consistent with this CPS.
7. The subscriber shal

all follow the duties as mentioned in the IT Act.
9.6.3. Relying Party
Parties who rely upon the certificates issued under a policy defined
ned in this document
shall:
1. Use the certificatee for the purpose for which it was issued, as indicated in the
certificate informaation (e.g., the key usage extension);
2. Check each certifi

rtificate for validity, using procedures described
bed in RFC 5280,
prior to reliance;
3. Preserve original signed data, the applications necessary to read

ead and process that
data, and the crypptographic applications needed to verify the diggital signatures on
that data for as long
ong as it may be necessary to verify the signa
gnature on that data.
Note: data formatat chang
changes associated with application upgrades will
wil often invalidate
digital signatures
es and shou
should be avoided.
9.6.4. Representationss and W

Warranties of Other Participants
Not applicable.
9.7. Disclaimers of Warranties

ies
To the extent permitted byy app

applicable law and any other related agreemen
ents, CA disclaims
all warranties other than any express warranties contained in such agreem
ments or set forth in
this CPS.
9.8. Limitations of Liabilities
CA limit liabilities as long

ong as CA meet the liability requirements stated ed in IT Act, 2000
and Rules made there unde
under. CA is responsible for verification of any Subscriber
Subsc to whom it
has issued a certificatee and to all relying parties who reasonably relyy on such
su certificate in
accordance with this CPS, S, for damages suffered by such persons that are a caused by the
failure of the CA to compply with the terms of its CPS or its Subscriber ber Agreement, and
sustained by such persons as a result of the use of or reliance on the certifica
cate.
Version 4.0.0
The verification requiremen ents for certificate issuance by CA are as specifi

ified under IT Act
2000 and Rules made therre under and reasonable effort by CA. CA cannot guarantee the
activities or conduct of the subscribers.
CA shall not be liable for f any indirect, exemplary, special, punitive, e, incidental, and
consequential losses, dam mages, claims, liabilities, charges, costs, expenses
expen or injuries
(including without limitation
on loss of use, data, revenue, profits, business and for any claims
of Subscribers or Users or other third parties including Relying parties).
CA shall not be liable for

or any delay, default, failure, breach of its obli
ligations under the
Subscribers Agreement, ReRelying Party Terms & Conditions and Regiistration Authority
Agreement
All liability is limited to acctual and legally provable damages. CA's liabili
lity is as per the IT
Act,2000 other governing Indian laws and Agreement. If the liability is not dealtdea under the
provisions of ITACT 2000, 0, the following caps limit CA’s damages concern ning specific
certificates.
Class Liability Caps/per Certificate

Class 1 Indian Rupees Ten Thousand
Class 2 Indian Rupees One Lakh
Class 3 Indian Rupees One Lakh
eKYC- Single Factor Indian Rupees - One Thousand
eKYC- Multi Factor Indian Rupees - One Thousand
9.9. Indemnities
Indemnification by Subsc
ubscribers
To the extent permitted

ed by app
applicable law, subscriber agreement requir
ires Subscribers to
indemnify CA for:
• False and misrep epresentation of fact by the subscriber on the subscriber’s

certificate applicati
tion,
• Suppression of a mmaterial fact on the certificate application, if the omission was

made negligently or with intent to deceive any party,
• The subscriber’s failure to protect the subscriber’s privatee key, to use a

trustworthy system
m, or to otherwise take the precautions necessar
ary to prevent the
compromise, loss, disclosure, modification, or unauthorized use of the subscriber’s
private key, or
Version 4.0.0
• The subscriber’s use of a name (including without limitation within wit a common
name, domain nam me, or e-mail address) that infringes upon the Inntellectual Property
Rights of a thirdd party.
pa
ng parties
Indemnification by relying
To the extent permitted by applicable law, relying party agreement requires, relying
parties to indemnify CA foor:
• The relying party’s
pa failure to perform the representations and warranties as
outlined in the section
s 9.6.3 of this CPS.
• The relying
ng pa
party’s reliance on a certificate that is not reassonable under the
circumstances,, or
• The relying parrty’s failure to check the status of such certifi

rtificate to determine
if the certificatee is expired or revoked.
9.10. Term and Termination
9.10.1. Term
The CPS becomes eff ffective upon approval by the Office of CCA. Am mendments to this
CPS become effectivee upon ratification by approval by CCA and publication
pub by CA
at https://prodigisign.com/cps. There is no specified term for this CP
PS.
9.10.2. Termination
While this CPS mayy be amended from time to time, it shall remmain in force until
replaced by a newer vversion or explicitly terminated by CCA.
9.10.3. Effect of Termination

on and Survival
Upon termination of this CPS, CA is nevertheless bound by its terms for all
Certificates issued for
or the remainder of the validity periods of such h Certificates.
Ce The
sections 5.5 and 9.00 of this CPS shall survive the termination or expiraation of this CPS.
9.11. Individual Notices and Communications

C with Participants
Unless otherwise specified

ed by agreement between the parties, CA uses us commercially
reasonable methods to com
mmunicate, taking into account the criticality
y and subject matter of
the communication.
9.12. Amendments
Version 4.0.0
9.12.1. Procedure for Amend

endment
CA will review this C CPS at least once every year. Additional review
ws may be enacted
at any time at the discr
cretion of the CCA.
If the Office of CCAA wishes to recommend amendments or correc

ections to this CPS,
such modifications will
wil be submitted to CCA for approval.
CA will use reasonablle efforts to notify subscribers and relying parties

es of changes.
change
9.12.2. Notification Mechaniism and Period
Errors and anticipated

ed changes to this CPS resulting from revieews are published
online at https://prodigisign.com.
This CPS and any subs

bsequent changes are made publicly available within seven days
of approval.
9.12.3. Circumstancess under Which OID Must be Changed
equirement for changing the Certificate Policy OIDs.

CCA determines the requ O
9.13. Dispute Resolution Provis

visions
9.13.1. Disputes among Licensed

Licen CAs and Customers
Unless the provision for dispute resolution under the IT Act is invvoked, any dispute
based on the contentss of this CPS, between CA and one of itss customers
cu who has
availed specific services
ces will be resolved according to provisions in the applicable
agreement between thehe pa
parties.
Any dispute based on the contents of this CPS, between/among

ong CAs shall be
resolved by CCA.
9.13.2. Alternate Disputee Re

Resolution Provisions
No stipulations.
9.14. Governing Law
The laws of India and more

m particularly the Information Technology
gy Act, 2000, The
Information Technology (Ce
Certifying Authorities) Rules, 2000 and Inform
mation Technology
Version 4.0.0
(Certifying Authority)) Reg

Regulations, 2001, and the guidelines issued
ued and clarifications
c made
from time to time by the Controller of Certifying Authorities, Ministry of Electronics and
Information Technology ogy shall govern the construction, validity, enforceability
en and
performance of actions perr this CPS.
9.15. Compliance with Applicable Law
This CPS is subject to applicable

app national, state, local and rules, regulaations, ordinances,
decrees, and orders includ
uding, but not limited to, restrictions on exporti rting or importing
software, hardware, or techn
echnical information.
9.16. Miscellaneous Provisions
9.16.1. Entire Agreement
No stipulation.
9.16.2. Assignment
Except where specified ed by other contracts, no party may assign or delegate this CPS
or any of its rights or duties under this CPS, without the prior written
en consent of CCA.
Further, the Office
ce of CCA in its discretion may assign and delegatte this CPS to any
party of its choice.
9.16.3. Severability
If any provision of thhis CPS is held to be invalid by a court of compepetent jurisdiction,

then the remaining proovisions will nevertheless remain in full force
ce and effect.
9.16.4. Waiver of Rights
No waiver of any breach

each or de
default or any failure to exercise
se any right hereunder is
construed as a waiverer of any subsequent breach or default or relinqu
nquishment of any
future right to exercise
se such
su right. The headings in this CPS are for or convenience
con only
and cannot be used inn interpreting this CPS.
9.16.5. Force Majeure
CA is not liable for any failure or delay in its performance under thiss CPS due to causes
that are beyond their reasonable control, including, but not limited to, an act of God,
act of civil or militaryy authority, fire, epidemic, flood, earthquake, riot,
ri war, failure of
equipment, failure of telecommunications lines, lack of Internet acce ccess, sabotage, and
governmental action.
Version 4.0.0
9.17. Other Provisions
Not applicable.
Version 4.0.0
10. Bibliography
The following documents werre used in part to develop this CPS:
FIPS 140-2 Secuurity Requirements for Cryptographic Module les, 1994-01

http:///csrc.nist.gov/cryptval/
FIPS 186-2 Digittal Signature Standard, 2000-01-27
http:///csrs.nist.gov/fips/fips186.pdf
ITACT 2000 Thee IInformation Technology Act, 2000, Governmeent of India,
June 9, 2000.
RFC 3647 Certiificate Policy and Certificate Practices Framework,
F
Chokkhani, Ford, Sabett, Merrill, and Wu. November 2003.
CCA-IOG Interop
operability Guidelines for DSC
http:///www.cca.gov.in/cca/?q=guidelines.html
CCA-CP X.5009 Certificate Policy for India PKI
CCA-IVG Identtity Verification Guidelines,
CCA-TSG Timee Stamping Services Guidelines for CAs,
http:/
://www.cca.gov.in/cca/?q=guidelines.html
CCA-OCSP OCSP Service Guidelines for CAs,
CCA-OID OID Hierarchy
Hi for India PKI(OID)
CCA-CASITESP CA SITE
S SPECIFICATION
CCA-CRYPTO Secuurity Requirements for Crypto Devices
CCA-CALIC CA Licensing
L Guidelines
Version 4.0.0
11. Acronyms and Abbreviations

ns
AES Advanced Encryyption Standard

CA Certifying Authohority
CCA Controller of Certifying
Ce Authorities
CP Certificate Policy
cy
CPS Certification Pracactice Statement
CRL Certificate Revoca
ocation List
CSP Certificate Status
us Provider
DN Distinguished N Name
DNS Domain Namee Service
Se
FIPS (US) Federal Infformation Processing Standard
FIPS PUB (US) Federal Infformation Processing Standard Publication
HR Human Resources ces
HTTP Hypertext Transf sfer Protocol
IAO Information Assuurance Officer
ID Identifier
IETF Internet Engineeering Task Force
IT Informationon Techno
Technology
OID Object Identifier
er
PIN Personal Identifi
tification Number
PKI Public Key Infraastructure
PKIX Public Key Infraastructure X.509
RA Registration Autthority
RFC Request For Comm mments
RSA Rivest-Shamir-A Adleman (encryption algorithm)
RCAI Root Certifying
ng Authority Of India
SHA-2 Secure Hash Algo gorithm, Version 4
SSL Secure Sockets L Layer
TLS Transport Layer Security
UPS Uninterrupted PoPower Supply

ProDigiSign CPS

Uploaded by

Copyright:

Available Formats

ProDigiSign CPS

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ProDigiSign CPS

Uploaded by

Copyright:

Available Formats

Certification Practice Statement

KUMAR 11:27:38 +05'30'

Phone: +91 020 49105678 / +91 8657212347

Document Name CPS of ProDigiSign CA

3.2.6. Criteria for Interoperation ................................

4.9.9. Online Revocation Checking

5.5.3. Protection of Archive ................................................................................................................................

6.8. Time Stamping ................................................................................................................................

9.10. Term and Termination ................................

“Act” means Information Technology IT Act, 2000

"IT Act" Information

“ASP” or “Application Service Provider

“CA” refers to ProDigiSign CA , a Certifying Authority, licensed by Controller of Certifying

"Certificationn Practice Statement or CPS

“Certificate”—A Digital Signature C

“Certificate Issuance”—The actions ons performed by a CA in creating a Digital Siggnature Certificate

“Certificate Policy”—The India PK KI Certificate Policy laid down by CCA and

“Controller” or “CCA” means the Controller of Certifying Authorities appointed

Organization—An entity with whicch a user is affiliated. An organization may also

“Registration Authority” or “RA”“R is an entity engaged by CA to collect DSC

“Relying Party” is a recipient who acts

Subscriber—A person in whose name

Subscriber Agreement—The agreeement executed between a subscriber and CA f o r the provision

"Trusted Person" means any person rson who has:-

ProDigiSign CA is managed by Professional DigiSign Private Limited. The term “Certifying

1.1. Overview of CPS

India PKI CP defines certifica

The Certification Practice Stat

iv. e-Authentication guidelines

vi. CA Site Specificationon [CCA-CASITESP]: Requirements for the construction of

The contact details are mentiooned in section 1.5.2 of this CPS.

Assurance Level OID

The OIDs allocated to CA and CPS

Serial No. Product OID

OID for document signer certificates

document signer 2.16.356.100.10.1

1.3.1. PKI Authorities

1.3.1.1. Controller of Certif

In the context of the CPS,

1. Developing and adminiistering India PKI CP.

2. compliance analysis and

3. Laying down guidelines

4. Ensuring continued conformance

The ProDigiSign CA is licensed

ProDigiSign CA certificate is certified by Root Certifying Authority y of India (RCAI). In

Sr. No. CA Name Certified

CA issue Digital Signature

1.3.2. PKI Services

i. Certificate Services:: BBased on the assurance level requirements,

ii. CRL Services:: CA makes available CRL on the website

iii. OCSP (Online Certifi

iv. eSign on line Digital Signatu

The identity and

ESP of CA facilitates DSC application form generation; key generation of DSC

of applicants are destroyed immediately after certificate generation and signature

1.3.3. Registration Authority (RA) and Organizational Registration Authority (ORA)

Registration Authority (RA): RA is an entity engaged by CA to collect DSC

Organizational Registration Authority (ORA): An organizational RA (ORA) collects