X.509 Certificate Policy for India PKI

Transcription

1 X.509 Certificate Policy for India PKI Version 1.1 December 2010 Controller of Certifying Authorities Department of Information Technology Ministry of Communications and Information Technology

2 Document Control Document Name X 509 Certificate Policy for India PKI Status Release Version 1.1 Last update 14 April 2011 Document Owner Controller of Certifying Authorities, India Signature Controller of Certifying Authorities (CCA) DATE

3 Table of Contents 1 INTRODUCTION Overview Certificate Policy (CP) Relationship between CP and CPS Document Identification PKI Participants PKI Authorities Registration Authority (RA) Subscribers Relying Parties Applicability Certificate Usage Appropriate Certificate Uses Prohibited Certificate Uses Policy Administration Organization administering the document Contact Person Person Determining Certification Practice Statement Suitability for the Policy CPS Approval Procedures Waivers PUBLICATION & PKI REPOSITORY RESPONSIBILITIES PKI Repositories Repository Obligations Publication of Certificate Information Publication of CA Information Interoperability Publication of Certificate Information Access Controls on PKI Repositories IDENTIFICATION & AUTHENTICATION Naming Types of Names Need for Names to be Meaningful Anonymity or Pseudonymity of Subscribers Rules for Interpreting Various Name Forms Uniqueness of Names Recognition, Authentication & Role of Trademarks Name Claim Dispute Resolution Procedure... 7 i

4 3.2 Initial Identity Validation Method to Prove Possession of Private Key Authentication of Organization user Identity Authentication of Individual Identity Non-verified Subscriber Information Validation of Authority Criteria for Interoperation Identification and Authentication for Re-Key Requests Identification and Authentication for Routine Re-key Identification and Authentication for Re-key after Revocation Identification and Authentication for Revocation Request CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS Certificate requests Submission of Certificate Application Enrollment Process and Responsibilities Certificate Application Processing Performing Identification and Authentication Functions Approval or Rejection of Certificate Applications Certificate Issuance CA Actions during Certificate Issuance Notification to Subscriber of Certificate Issuance Certificate Acceptance Conduct Constituting Certificate Acceptance Publication of the Certificate by the CA Notification of Certificate Issuance by the CA to Other Entities Key Pair and Certificate Usage Subscriber Private Key and Certificate Usage Relying Party Public Key and Certificate Usage Certificate Renewal Circumstance for Certificate Renewal Who may Request Renewal Processing Certificate Renewal Requests Notification of New Certificate Issuance to Subscriber Conduct Constituting Acceptance of a Renewal Certificate Publication of the Renewal Certificate by the CA Notification of Certificate Issuance by the CA to Other Entities Certificate Re-Key Circumstance for Certificate Re-key Who may Request Certification of a New Public Key ii

5 4.7.3 Processing Certificate Re-keying Requests Notification of New Certificate Issuance to Subscriber Conduct Constituting Acceptance of a Re-keyed Certificate Publication of the Re-keyed Certificate by the CA Notification of Certificate Issuance by the CA to Other Entities Certificate Modification Certificate Revocation and Suspension Circumstance for Revocation of a Certificate Who Can Request Revocation of a Certificate Procedure for Revocation Request Revocation Request Grace Period Time within which CA must Process the Revocation Request Revocation Checking Requirements for Relying Parties CRL Issuance Frequency Maximum Latency for CRLs Online Revocation Checking Availability Online Revocation Checking Requirements Other Forms of Revocation Advertisements Available Special Requirements Related To Key Compromise Circumstances for Suspension Who can Request Suspension Procedure for Suspension Request Limits on Suspension Period Certificate Status Services Operational Characteristics Service Availability Optional Features End of Subscription Key Escrow and Recovery Key Escrow and Recovery Policy and Practices FACILITY MANAGEMENT & OPERATIONAL CONTROLS Physical Controls Site Location & Construction Physical Access Power and Air Conditioning Water Exposures Fire Prevention & Protection iii

6 5.1.6 Media Storage Waste Disposal Off-Site backup Procedural Controls Trusted Roles Number of Persons Required per Task Identification and Authentication for Each Role Roles Requiring Separation of Duties Personnel Controls Qualifications, Experience, and Clearance Requirements Background Check Procedures Training Requirements Retraining Frequency and Requirements Job Rotation Frequency and Sequence Sanctions for Unauthorized Actions Independent Contractor Requirements Documentation Supplied To Personnel Audit Logging Procedures Types of Events Recorded Frequency of Processing Audit Logs Retention Period for Audit Logs Protection of Audit Logs Audit Log Backup Procedures Audit Collection System (internal vs. external) Notification to Event-Causing Subject Vulnerability Assessments Records Archival Types of Records Archived Retention Period for Archive Protection of Archive Archive Backup Procedures Requirements for Time-Stamping of Records Archive Collection System (internal or external) Procedures to Obtain & Verify Archive Information Key Changeover Compromise and Disaster Recovery Incident and Compromise Handling Procedures iv

7 5.7.2 Computing Resources, Software, and/or Data are Corrupted Private Key Compromise Procedures Business Continuity Capabilities after a Disaster CA, CSP, and RA Termination TECHNICAL SECURITY CONTROLS Key Pair Generation and Installation Key Pair Generation Private Key Delivery to Subscriber Public Key Delivery to Certificate Issuer CA Public Key Delivery to Relying Parties Key Sizes Public Key Parameters Generation and Quality Checking Key Usage Purposes (as per X.509 v3 key usage field) Private Key Protection and Cryptographic Module Engineering Controls Cryptographic Module Standards and Controls Private Key Multi-Person Control Private Key Escrow Private Key Backup Private Key Archival Private Key Transfer into or from a Cryptographic Module Private Key Storage on Cryptographic Module Method of Activating Private Key Methods of Deactivating Private Key Method of Destroying Private Key Cryptographic Module Rating Other Aspects Of Key Management Public Key Archival Certificate Operational Periods/Key Usage Periods Activation Data Activation Data Generation and Installation Activation Data Protection Other Aspects of Activation Data Computer Security Controls Specific Computer Security Technical Requirements Computer Security Rating Life-Cycle Technical Controls System Development Controls Security Management Controls v

8 6.6.3 Life Cycle Security Controls Network Security Controls Time Stamping CERTIFICATE, CRL AND OCSP PROFILES Certificate Profile CRL Profile Full and Complete CRL Distribution Point Based Partitioned CRL OCSP Profile OCSP Request Format OCSP Response Format COMPLIANCE AUDIT AND OTHER ASSESSMENTS Frequency or Circumstances of Assessments Identity and Qualifications of Assessor Assessor s Relationship to Assessed Entity Topics Covered by Assessment Actions Taken as a Result of Deficiency Communication of Results OTHER BUSINESS AND LEGAL MATTERS Fees Certificate Issuance and Renewal Fees Certificate Access Fees Revocation Status Information Access Fees Fees for Other Services Refund Policy Financial Responsibility Insurance Coverage Other Assets Insurance or Warranty Coverage for End-Entities Confidentiality of Business Information Privacy of Personal Information Intellectual Property Rights Property Rights in Certificates and Revocation Information Property Rights in the CPS Property Rights in Names Property Rights in Keys Representations and Warranties CA Representations and Warranties Subscriber Relying Party Representations and Warranties of Other Participants vi

9 9.7 Disclaimers of Warranties Limitations of Liabilities Indemnities Term and Termination Term Termination Effect of Termination and Survival Individual Notices and Communications with Participants Amendments Procedure for Amendment Notification Mechanism and Period Circumstances under Which OID Must be Changed Dispute Resolution Provisions Disputes among Licensed CAs and Customers Alternate Dispute Resolution Provisions Governing Law Compliance with Applicable Law Miscellaneous Provisions Entire Agreement Assignment Severability Waiver of Rights Force Majeure Other Provisions DIFFERENCES AMONG VARIOUS ASSURANCE LEVELS BIBLIOGRAPHY ACRONYMS AND ABBREVIATIONS vii

10 1 Introduction This Certificate Policy (CP) defines certificate policies to facilitate interoperability among subscribers and relying parties for e-commerce and e-governance in India. The CP and Certifying Authorities (CAs) are governed by the Controller of Certifying Authorities (CCA). Secure e-commerce and e-governance in India is governed by the Information Technology (IT) Act In support of the IT Act of 2000, the Government of India has developed and implemented the India Public Key Infrastructure (India PKI). The 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 IT Act. CAs can be private sector companies, Government departments, public sector companies, or Non- Government Organizations (NGOs). These are also called Licensed CAs The certificate policies apply to all components of the India PKI, if applicable. Examples of India PKI components include but are not limited to RCAI, CAs, Registration Authorities (RAs), and repositories. Any use of or reference to this CP outside the purview of the India PKI is completely at the using party s risk. A CA that is not a member of the India PKI shall not assert the object identifiers (OIDs) listed in Section 1.2 of this CP in any certificates the CA issues. This CP is consistent with the Internet Engineering Task Force (IETF) Public Key Infrastructure X.509 (IETF PKIX) RFC 3647, Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practice Statement Framework. Organization Hierarchy 1.1 Overview Certificate Policy (CP) Certificates contain one or more registered certificate policy OID, which may be used by a Relying Party to decide whether a certificate is trusted for a particular purpose. The party that registers the OIDs also publishes the CP, for examination by Relying Parties Relationship between CP and CPS This CP states what assurance can be placed in a certificate issued under this policy. A Certification Practice Statement (CPS) for PKI component(s) states how the PKI component(s) meet the assurance requirements. 1

11 1.2 Document Identification There are three levels of assurance in this Certificate Policy, which are defined in subsequent sections. Each level of assurance has an OID that can be asserted in certificates issued by the India PKI if the certificate issuance meets the requirements for that assurance level. The OIDs are registered under the CCA arc as follows: id-india PKI ::= { } id-cp ::= (id-india PKI 2} id-class1 ::= {id-cp 1} id-class2 ::= {id-cp 2} id-class3 ::= {id-cp 3} Unless otherwise stated, a requirement stated in this CP applies to all assurance levels. The assurance levels asserted above are hierarchical with Class 3 being the highest level of assurance. 1.3 PKI Participants PKI Authorities Controller of Certifying Authorities (CCA) The CCA is responsible for: 1. Drafting and approval of the India PKI CP;. 2. Commissioning compliance analysis and approval of the licensed CAs CPS; 3. Accepting and processing applications from Entities desiring to become Licensed CA; and 4. Ensuring continued conformance of Licensed CAs with this CP by examining compliance audit results Root Certifying Authority of India (RCAI) A Root CA is a trust anchor for subscribers of a PKI domain when the subscribers act as relying party. The Root Certifying Authority of India (RCAI) shall be controlled by and operated under the direction of CCA Intermediate CA An Intermediate CA is one that Licensed by CCA as per Information Technology Act. The Intermediate CA is not a Root CA and its primary function is to issue certificates to sub-cas. In case Intermediate CAs wish to issue end entity certificates then no Sub-CAs can be used in its operations. Intermediate CAs can only issue end entity certificates whenever required to facilitate in-house CA operations 2

12 A CA with sub-ca must necessarily issue end entity certificates only through its sub-ca. The only exception will be for code signing and time stamping certificates, which may directly be issued by the CA Sub-CA A Certifying Authority can create sub-cas to meet the business branding requirement. These sub-cas, which will be part of the same legal entity as the CA, will issue certificates to the end entities or subscribers. A sub-ca shall not issue certificates to other CAs or sub-cas. The sub-ca model will be based on the following principles: The CAs MUST NOT have more than ONE level of sub-ca The sub-ca MUST use a sub-ca certificate issued by the CA for issuing end entity certificates The sub-ca must necessarily use the CAs infrastructure for issuing certificate The sub-cas operations shall be subject to same audit procedures as the CA The certificate policies of the sub-ca must be same as or sub-set of the CA s certificate policies CCA ABC CA XYZ CA PQR CA End User End User JHL Sub-CA MNO Sub-CA End User End User Certificate Status Provider (CSP) A CSP is an authority that provides status of certificates or certification paths. CSP can be operated in conjunction with the CAs or independent of the CAs. Examples of CSP are: 1. Online Certificate Status Protocol (OCSP) Responders that provide revocation status of certificates. 3

13 2. Standard Based Certificate Validation Protocol (SCVP) Servers that validate certifications paths or provide revocation status checking services. OCSP Responders that are keyless and simply repeat responses signed by other Responders and SCVP Servers that do not provide certificate validation services shall adhere to the same security requirements as repositories Registration Authority (RA) An RA is the entity that collects and verifies each Subscriber s identity and information that are to be entered into his or her public key certificate. An RA interacts with the CA to enter and approve the subscriber certificate request information Subscribers A Subscriber is the entity whose name appears as the subject in a certificate, who asserts that it uses its key and certificate in accordance with the certificate policy asserted in the certificate, and who does not itself issue certificates. CAs are sometimes technically considered subscribers in a PKI. However, the term Subscriber as used in this document refers only to those who request certificates for uses other than signing and issuing certificates or certificate status information Relying Parties A Relying Party is the entity that relies on the validity of the binding of the Subscriber's name to a public key. The Relying Party is responsible for deciding whether or how to check the validity of the certificate by checking the appropriate certificate status information. The Relying Party can use the certificate to verify the integrity of a digitally signed message, or to identify the creator of a message,. A Relying Party may use information in the certificate (such as certificate policy identifiers) to determine the suitability of the certificate for a particular use Applicability The following are general guidelines. Additional guidelines are available in IT Act of India 2000 and specific guidelines from CCA. Assurance Level Class 1 Class 2 Applicability This level provides a basic level of assurance relevant to environments where there are risks and consequences of data compromise, but they are not considered to be of major significance. This may include access to private information where the likelihood of malicious access is not high. It is assumed at this security level that users are not likely to be malicious. This level is relevant to environments where risks and consequences of data compromise are moderate. This may 4

14 Class 3 include transactions having substantial monetary value or risk of fraud, or involving access to private information where the likelihood of malicious access is substantial. This level is relevant to environments where threats to data are high or the consequences of the failure of security services are high. This may include very high value transactions or high levels of fraud risk. 1.4 Certificate Usage Appropriate Certificate Uses Certificate usage shall be governed by the IT Act of 2000 and Interoperability Guidelines from CCA Prohibited Certificate Uses Certificate usage shall be governed by the IT Act of 2000 and Interoperability Guidelines from CCA. 1.5 Policy Administration Organization administering the document The CCA is responsible for all aspects of this CP Contact Person Questions regarding this CP shall be directed to the CCA at info@cca.gov.in Person Determining Certification Practice Statement Suitability for the Policy The determination of suitability of a CPS shall be based on an independent auditor s results and recommendations CPS Approval Procedures The CCA shall approve the Licensed CA and RCAI CPS auditor s assessment will also be taken into account Waivers There shall be no waivers to this CP. 5

15 2 Publication & PKI Repository Responsibilities 2.1 PKI Repositories Licensed CAs shall operate Hypertext Transfer Protocol (HTTP) or LDAP based repositories that provide the following information: 1. CA Certificates Issued to their sub-cas 2. Certificate Revocation List (CRL) a) Issued by the Licensed CA b) Issued by their sub-cas 3. Digital Signature Certificates issued by Licensed CA/sub-CA Repository Obligations Repository shall have high availability. 2.2 Publication of Certificate Information Publication of CA Information See Section Interoperability See Section Publication of Certificate Information Certificates and certificate status information shall be published as specified in this CP in Section Access Controls on PKI Repositories Any PKI Repository information not intended for public dissemination or modification shall be protected. 6

16 3 Identification & Authentication 3.1 Naming Types of Names The CAs shall generate and sign certificates containing an X.500 Distinguished Name (DN) in the Issuer and in Subject fields. Subject Alternative Name may also be used, if marked non-critical. Further requirements for name forms are specified in [CCA- PROF] Need for Names to be Meaningful The certificates issued pursuant to this CP are meaningful only if the names that appear in the certificates can be understood and used by Relying Parties. Names used in the certificates must identify the person or object to which they are assigned in a meaningful way. All DNs and associated directory information tree shall accurately reflect organizational structures. When DNs are used, it is preferable that the common name represents the subscriber in a way that is easily understandable for humans. For people, this will typically be a legal name. For equipment, this may be a model name and serial number, or an application process (e.g., Organization X Mail List or Organization Y Multifunction Interpreter) Anonymity or Pseudonymity of Subscribers CA and subscriber certificates shall not contain anonymous or pseudonymous identities Rules for Interpreting Various Name Forms Rules for interpreting name forms shall be in accordance with applicable Standards Uniqueness of Names Name uniqueness of Root CA, licensed CA and SubCA shall be enforced Recognition, Authentication & Role of Trademarks No stipulation Name Claim Dispute Resolution Procedure The CCA shall resolve any name collisions (other than subscribers) brought to its attention that may affect interoperability or trustworthiness. 7

17 3.2 Initial Identity Validation Method to Prove Possession of Private Key In all cases where the party named in a certificate generates its own keys that party shall be required to prove possession of the private key, which corresponds to the public key in the certificate request. For signature keys, this may be done by the entity using its private key to sign a value and providing that value to the issuing CA. The CA shall then validate the signature using the party s public key. The CCA may allow other mechanisms that are at least as secure as those cited here Authentication of Organization user Identity Requests for certificates in the name of an organizational user shall include the user name, organization name, address, and documentation of the existence of the organization. The CA or an RA shall verify the information relating to the authenticity of the requesting representative Authentication of Individual Identity A CA shall ensure that the applicant s identity information is verified. The CA or an RA shall ensure that the applicant s identity information and public key are properly bound. Additionally, the CA or the RA shall record the process that was followed for issuance of each certificate. Process information shall depend upon the certificate level of assurance and shall be addressed in the applicable CPS. The process documentation and authentication requirements shall include the following: 1. The identity of the person performing the identity verification; 2. A signed declaration by that person that he or she verified the identity of the applicant; 3. The applicant shall present one photo ID. The applicant shall also present a document as a proof of residential address. 4. Unique identifying numbers from the Identifier (ID) of the verifier and from an ID of the applicant; 5. The date and time of the verification; and 6. A declaration of identity signed by the applicant using a handwritten signature or equivalent per Indian Laws. For Class 3 certificates, identity shall be established by in-person proofing before the RA, to confirm identities; information provided shall be verified to ensure legitimacy. A trust relationship between the RA and the applicant which is based on an in-person antecedent may suffice as meeting the in-person identity proofing requirement Authentication of Component Identities Some computing and communications components (routers, firewalls, servers, etc.) will be named as certificate subjects. In such cases, the component shall have a 8

18 human sponsor. The PKI sponsor shall be responsible for providing the following registration information: 1. Equipment identification (e.g., serial number) or service name (e.g., Domain Name Service (DNS) name) 2. Equipment public keys 3. Contact information to enable the CA or RA to communicate with the sponsor when required Non-verified Subscriber Information Information that is not verified shall not be included in certificates Validation of Authority Certificates that contain explicit or implicit organizational affiliation shall be issued only after ascertaining the applicant has the authorization to act on behalf of the organization in the asserted capacity Criteria for Interoperation Certificates shall be issued in accordance with [CCA-PROF] in order to ensure interoperability. 3.3 Identification and Authentication for Re-Key Requests Identification and Authentication for Routine Re-key The CAs and subscribers shall identify themselves through use of their current Signing Key or by using the initial identity-proofing process as described above. Identity shall be established through the initial identity-proofing process for each assurance level per the table below: Assurance Level Class 1 Class 2 Class 3 Initial Identity Proofing Every 2 Years Every 2 Years Every 2 Years When current Signing Key is used for identification and authentication purposes, the life of the new certificate shall not exceed beyond the initial identity-proofing times specified in the table above. 9

19 3.3.2 Identification and Authentication for Re-key after Revocation After a certificate has been revoked other than during a renewal action, the subject (i.e., a CA or an end entity) is required to go through the initial registration process described in Section 3.2 to obtain a new certificate. 3.4 Identification and Authentication for Revocation Request Revocation requests shall be authenticated. Requests to revoke a certificate may be authenticated using that certificate's associated public key, regardless of whether or not the private key has been compromised. In the case of loss of key, RA/CA can suspend/revoke the certificate on verifying the subscriber s identity. In the case where subscriber is not in a position to communicate (death, unconscious state, mental disorder), on receiving such information RA or CA can suspend the certificate and after verification the certificate can be revoked. 10

20 4 Certificate Life-Cycle Operational Requirements Communication among the CA, RA, and subscriber shall have requisite security services (i.e., source authentication, integrity, non-repudiation, or confidentiality) applied to them commensurate with the assurance level of the certificate being managed. For example, packages secured and transported in a tamper-evident manner by a certified mail carrier meet the integrity and confidentiality requirements for Class 3 assurance level. When cryptography is used, the mechanism shall be at least as strong as the certificates being managed. For example, web site secured using Class 2 Secure Socket Layer (SSL) certificate and set up with appropriate algorithms and key sizes satisfies the integrity and confidentiality requirements for Class 2 certificate management. The content of communication shall dictate if some, all, or none of the security services are required. 4.1 Certificate requests Requests by a Licensed CA for CA certificate shall be submitted to the CCA using a procedure issued by Office of CCA. The CCA shall make the procedure available to all entities. The application shall be accompanied by a CPS written to the format of the Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework [RFC3647]. The CCA shall evaluate the application in accordance with the provisions under the IT Act, and make a determination regarding whether or not to issue the requested certificate(s), depending on the results of audit of the CPS per section 1.5 and subsections thereof. Upon issuance, each certificate issued by the RCAI shall be manually checked to ensure each field and extension is properly populated with the correct information, before the certificate is published or delivered to the Subject CA Submission of Certificate Application For CA certificate requests to the RCAI, an authorized representative of the Licensed CA shall submit the request to the CCA. For end entity certificates, the Licensed CA CPS shall describe the submission process Enrollment Process and Responsibilities Applicants for public key certificates shall be responsible for providing accurate information in their applications for certification. 4.2 Certificate Application Processing It is the responsibility of the CA to verify that the information in certificate applications is accurate. Applicable CPS shall specify procedures to verify information in certificate applications. 11

21 4.2.1 Performing Identification and Authentication Functions See Section and subsections thereof Approval or Rejection of Certificate Applications A CA may approve or reject a certificate application. 4.3 Certificate Issuance Upon receiving a request for a certificate, the CA shall respond in accordance with the requirements set forth in applicable CPS. If databases are used to confirm Subscriber information, then these databases must be protected from unauthorized modification to a level commensurate with the level of assurance of the certificate being sought CA Actions during Certificate Issuance A CA shall verify the source of a certificate request before issuance. Certificates shall be checked to ensure that all fields and extensions are properly populated. After generation, verification, and acceptance, a CA shall post the certificate as set forth in the CA s CPS Notification to Subscriber of Certificate Issuance A CA shall notify a subject (End Entity Subscriber) of certificate issuance. 4.4 Certificate Acceptance Conduct Constituting Certificate Acceptance The subject must confirm acceptance of the certificate upon notification of issuance by the CA Publication of the Certificate by the CA See Section Notification of Certificate Issuance by the CA to Other Entities No Stipulation. 4.5 Key Pair and Certificate Usage Subscriber Private Key and Certificate Usage Subscribers and CAs shall protect their private keys from access by any other party. Subscribers and CAs shall use their private keys for the purposes as constrained by the extensions (such as key usage, extended key usage, certificate policies, etc.) in the certificates issued to them. 12

22 4.5.2 Relying Party Public Key and Certificate Usage Relying parties shall use public key certificates and associated public keys for the purposes as constrained by the extensions (such as key usage, extended key usage, certificate policies, etc.) in the certificates. 4.6 Certificate Renewal Renewing a certificate means creating a new certificate with the same name, key, and other information as the old one, but a new, extended validity period and a new serial number. Certificates may be renewed in order to reduce the size of CRLs. A certificate may be renewed if the public key has not reached the end of its validity period, the associated private key has not been compromised, and the Subscriber name and attributes are unchanged Circumstance for Certificate Renewal A certificate may be renewed if the public key has not reached the end of its validity period, the associated private key has not been revoked or compromised, and the Subscriber name and attributes are unchanged. In addition, the validity period of the certificate must not exceed the remaining lifetime of the private key, as specified in Section 5.6. The identity proofing requirement listed in Section shall also be met Who may Request Renewal A Subject may request the renewal of its certificate. A PKI Sponsor may request renewal of component certificate. A CA may request renewal of its subscriber certificates, e.g., when the CA re-keys Processing Certificate Renewal Requests A certificate renewal shall be achieved using one of the following processes: 1. Initial registration process as described in Section 3.2; or 2. Identification & Authentication for Re-key as described in Section 3.3, except the old key can also be used as the new key Notification of New Certificate Issuance to Subscriber See Section Conduct Constituting Acceptance of a Renewal Certificate See Section Publication of the Renewal Certificate by the CA See Section

23 4.6.7 Notification of Certificate Issuance by the CA to Other Entities See Section Certificate Re-Key The longer and more often a key is used, the more susceptible it is to loss or discovery. Therefore, it is important that a Subscriber periodically obtains new keys and reestablishes its identity. Re-keying a certificate means that a new certificate is created that has the same characteristics and level 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 number, and it may be assigned a different validity period Circumstance for Certificate Re-key A CA may issue a new certificate to the Subject when the Subject has generated a new key pair and is entitled to a certificate Who may Request Certification of a New Public Key A Subject may request the re-key of its certificate. A PKI Sponsor may request may request re-key of component certificate Processing Certificate Re-keying Requests A certificate re-key shall be achieved using one of the following processes: 1. Initial registration process as described in Section 3.2; or 2. Identification & Authentication for Re-key as described in Section Notification of New Certificate Issuance to Subscriber See Section Conduct Constituting Acceptance of a Re-keyed Certificate See Section Publication of the Re-keyed Certificate by the CA See Section Notification of Certificate Issuance by the CA to Other Entities See Section Certificate Modification No Stipulation 14

24 4.9 Certificate Revocation and Suspension Revocation requests must be authenticated. Requests to revoke a certificate may be authenticated using that certificate's associated private key, regardless of whether or not the private key has been compromised Circumstance for Revocation of a Certificate A certificate shall be revoked when the binding between the subject and the subject s public key defined within a certificate is no longer considered valid. Examples of circumstances that invalidate the binding are: 1. Identifying information or affiliation components of any names in the certificate become invalid; 2. The Subject can be shown to have violated the stipulations of its agreement with the CA; 3. The private key is suspected of compromise; or 4. The Subject or other authorized party (as defined in the applicable CPS) asks for the subscriber s certificate to be revoked. 5. Key Lost 6. Subscriber is not in a position to use certificate(death copy of Death certificate made available to the issuing CA) Whenever any of the above circumstances occur, the associated certificate shall be revoked and placed on the CRL. Revoked certificates shall be included on all new publications of the certificate status information until the certificates expire. A revoked certificate shall appear on at least one CRL Who Can Request Revocation of a Certificate A certificate subject, human supervisor of a human subject (for organizational user), Human Resources (HR) person for the human subject (for organizational user), PKI Sponsor for component, or issuing CA, may request revocation of a certificate. For CA certificates, authorized individuals representing the Licensed CA may request revocation of certificates Procedure for Revocation Request A request to revoke a certificate shall identify the certificate to be revoked, explain the reason for revocation, and allow the request to be authenticated (e.g., digitally or manually signed by the subject). Upon receipt of a revocation request, a CA shall authenticate the request and then revoke the certificate Revocation Request Grace Period There is no revocation grace period. Responsible parties must request revocation as soon as they identify the need for revocation. 15

25 4.9.5 Time within which CA must Process the Revocation Request A CA shall make best efforts to process revocation request so that it is posted in the next CRL unless a revocation request is received and approved within two hours of next CRL generation Revocation Checking Requirements for Relying Parties Use of revoked certificates could have damaging or catastrophic consequences in certain applications. The matter of how often new revocation data should be obtained is a determination to be made by the Relying Party. If it is temporarily infeasible to obtain revocation information, then the Relying Party must either reject use of the certificate, or make an informed decision to accept the risk, responsibility, and consequences for using a certificate whose authenticity cannot be guaranteed to the standards of this policy. Such use may occasionally be necessary to meet urgent operational requirements CRL Issuance Frequency CRLs shall be issued periodically, even if there are no changes to be made, to ensure timeliness of information. Certificate status information may be issued more frequently than the issuance frequency described below. A CA shall ensure that superseded certificate status information is removed from the PKI Repository upon posting of the latest certificate status information. CRLs shall be published not later than the next scheduled update. At least once every 7 days for Root with minimum validity period of 30 days; At Least Once every 24 hours for all others with minimum validity of 7 days. In addition, if a certificate is revoked for the reason of CA compromise or key compromise, the issuing CA shall issue and post a CRL immediately Maximum Latency for CRLs CRLs shall be published immediately after generation. Furthermore, each CRL shall be published no later than the time specified in the nextupdate field of the previously issued CRL. CAs must issue CRLs at least once every 24 hours, and the nextupdate time in the CRL may be no later than 7 days after issuance time (i.e., the thisupdate time) Online Revocation Checking Availability In addition to CRLs, CAs and Relying Party client software may optionally support online status checking. Client software using on-line status checking need not obtain or process CRLs. If on-line revocation/status checking is supported by a CA, the latency of certificate status information distributed on-line by the CA or its delegated status responders shall meet or exceed the requirements for CRL issuance stated in

26 Online Revocation Checking Requirements No stipulation beyond Section Other Forms of Revocation Advertisements Available Any alternate forms used to disseminate revocation information shall be implemented in a manner consistent with the security and latency requirements for the implementation of CRLs and on-line revocation and status checking Checking Requirements for Other Forms of Revocation Advertisements No stipulation Special Requirements Related To Key Compromise None beyond those stipulated in Section (check section numbering) Circumstances for Suspension Suspension shall be permitted in the event that a user s token is temporarily unavailable to them Who can Request Suspension A human subscriber, human supervisor of a human subscriber (organizational user), Human Resources (HR) person for the human subscriber (organizational user), issuing CA, may request suspension of a certificate Procedure for Suspension Request A request to suspend a certificate shall identify the certificate to be suspended, explain the reason for suspension, and allow the request to be authenticated (e.g., digitally or manually signed). The reason code CRL entry extension shall be populated with certificate Hold. The Hold Instruction Code CRL entry extension shall be absent Limits on Suspension Period A certificate may only be suspended for up to 15 days. If the subscriber has not removed their certificate from hold (suspension) within that period, the certificate shall be revoked for the reason of Key Compromise. In order to mitigate the threat of unauthorized person removing the certificate from hold, the subscriber identity shall be authenticated in person using initial identity proofing process described in Section Certificate Status Services CAs are not required to support online certificate status services such as SCVP Operational Characteristics No stipulation. 17

27 Service Availability Relying Parties are bound to their obligations and the stipulations of this CP irrespective of the availability of the online certificate status service Optional Features No stipulation End of Subscription Certificates that have expired prior to or upon end of subscription are not required to be revoked Key Escrow and Recovery Key Escrow and Recovery Policy and Practices Under no circumstances shall a CA or end entity signature key be escrowed by a thirdparty. 18

28 5 Facility Management & Operational Controls 5.1 Physical Controls Physical security controls shall be in accordance with the Information Technology (IT) Act of 2000, India and guidelines from CCA Site Location & Construction The location and construction of the facility housing CA and CSP equipment shall be consistent with facilities used to house high value, sensitive information. The site location and construction, when combined with other physical security protection mechanisms such as guards and intrusion sensors, shall provide robust protection against unauthorized access to the CA and CSP equipment and records Physical Access CA Physical Access CA and CSP equipment shall always be protected from unauthorized access. The physical security requirements pertaining to CA and CSP equipment are: 1. Ensure no unauthorized access to the hardware is permitted 2. Ensure all removable media and paper containing sensitive plain-text information is stored in secure containers 3. Be manually or electronically monitored for unauthorized intrusion at all times 4. Ensure an access log is maintained and inspected periodically 5. Provide at least three layers of increasing security such as perimeter, building, and CA room 6. Require two person physical access control to both the cryptographic module and computer system for CAs issuing Class 2 and Class 3 certificates. Removable cryptographic modules shall be deactivated prior to storage. When not in use, removable cryptographic modules, activation information used to access or enable cryptographic modules shall be placed in secure containers. Activation data shall either be memorized, or recorded and stored in a manner commensurate with the security afforded the cryptographic module, and shall not be stored with the cryptographic module. A security check of the facility housing the CA and CSP equipment shall occur if the facility is to be left unattended. At a minimum, the check shall verify the following: 1. The equipment is in a state appropriate to the current mode of operation (e.g., that cryptographic modules are in place when open, and secured when closed ); 2. For off-line CAs, all equipment other than the PKI Repository is shut down); 19

29 3. Any security containers are properly secured; 4. Physical security systems (e.g., door locks, vent covers) are functioning properly; and 5. The area is secured against unauthorized access. A person or group of persons shall be made explicitly responsible for making such checks. When a group of persons is responsible, a log identifying the person performing a check at each instance shall be maintained. If the facility is not continuously attended, the last person to depart shall initial a sign-out sheet that indicates the date and time, and asserts that all necessary physical protection mechanisms are in place and activated Power and Air Conditioning CAs shall have backup power sufficient to automatically lockout input, finish any pending actions, and record the state of the equipment before lack of power or air conditioning causes a shutdown. PKI Repositories shall be provided with Uninterrupted Power sufficient for a minimum of six hours operation in the absence of commercial power, to support continuity of operations Water Exposures No stipulation Fire Prevention & Protection No stipulation Media Storage CA media shall be stored so as to protect it from accidental damage (water, fire, electromagnetic). Media that contains audit, archive, or backup information shall be duplicated and stored in a location separate from the CA location Waste Disposal Sensitive waste material shall be disposed off in a secure fashion Off-Site backup Full system backups of the CAs, sufficient to recover from system failure, shall be made on a periodic schedule, described in the respective CPS. Backups shall be performed and stored off-site not less than once every 7 days. At least one full backup copy shall be stored at an offsite location (at a location separate from the CA equipment). Only the latest full backup need be retained. The backup shall be stored at a site with physical and procedural controls commensurate to that of the operational CA. 20

30 5.2 Procedural Controls Trusted Roles A trusted role is one whose incumbent performs functions that can introduce security problems if not carried out properly, whether accidentally or maliciously. The people selected to fill these roles must be extraordinarily responsible or the integrity of the CA is weakened. The functions performed in these roles form the basis of trust for all uses of the CA. Two approaches are taken to increase the likelihood that these roles can be successfully carried out. The first ensures that the person filling the role is trustworthy and properly trained. The second distributes the functions among more than one person, so that any malicious activity would require collusion. The requirements of this policy are drawn in terms of four roles listed below: 1. CA Administrator authorized to install, configure, and maintain the CA; establish and maintain user accounts; configure profiles and audit parameters; and generate component keys. 2. CA Officer authorized to request or approve certificates or certificate revocations. 3. Audit Administrator authorized to view and maintain audit logs. 4. System Administrator authorized to perform system backup and recovery. The following sections define these and other trusted roles CA Administrator The administrator shall be responsible for: 1. Installation, configuration, and maintenance of the CA; 2. Establishing and maintaining CA system accounts; 3. Configuring certificate profiles or templates and audit parameters, and; 4. Generating and backing up CA keys. Administrators shall not issue certificates to subscribers CA Officer The CA officer shall be responsible for issuing certificates, that is: 1. Registering new subscribers and requesting the issuance of certificates; 2. Verifying the identity of subscribers and accuracy of information included in certificates; 3. Approving and executing the issuance of certificates, and; 4. Requesting, approving and executing the revocation of certificates Audit Administrator The Audit Administrator shall be responsible for: 1. Reviewing, maintaining, and archiving audit logs; 21

31 2. Performing or overseeing internal compliance audits to ensure that the CA is operating in accordance with its CPS; System Administrator The System Administrator shall be responsible for the routine operation of the CA equipment and operations such as system backups and recovery or changing recording media Registration Authority An RA's responsibilities are: 1. Verifying identity, pursuant to section 3.2; 2. Entering Subscriber information, and verifying correctness; 3. Securely communicating requests to and responses from the CA; The RA role is highly dependent on public key infrastructure implementations and local requirements. The responsibilities and controls for RAs shall be explicitly described in the CPS of a CA if the CA uses an RA CSP Roles A CSP shall have at least the following roles. The CSP administrator shall be responsible for: 1. Installation, configuration, and maintenance of the CSP; 2. Establishing and maintaining CSP system accounts; 3. Configuring CSP application and audit parameters, and; 4. Generating and backing up CSP keys. The CSP Audit Administrator shall be responsible for: 1. Reviewing, maintaining, and archiving audit logs; 2. Performing or overseeing internal compliance audits to ensure that the CSP is operating in accordance with its CPS; The system administrator shall be responsible for the routine operation of the CSP equipment and operations such as system backups and recovery or changing recording media PKI Sponsor A PKI Sponsor fills the role of a Subscriber for non-human system components that are named as public key certificate subjects. The PKI Sponsor works with the RAs to register components (routers, firewalls, etc.) in accordance with Section , and is responsible for meeting the obligations of Subscribers as defined throughout this document Number of Persons Required per Task Two or more persons shall be required to perform the following tasks for CAs that issue Class 2 or Class 3 certificates: 22