FernUniversität in Hagen: Certification Authority (CA) Certification Practice Statement VERSION 1.1 Ralph Knoche 18.12.2009
Contents 1. Introduction... 4 1.1. Overview... 4 1.2. Scope of the Certification Services... 4 1.3. CA Identity... 5 1.4. Publication... 5 1.5. Further Information... 5 2. CA Certification Infrastructure... 6 2.1. Overview... 6 2.2. Roles and Responsibilities... 6 2.3. Certificate Classes... 6 2.3.1. Client Certificates... 7 2.3.2. Server Certificates... 7 2.4. Certification Authority (CA)... 7 2.5. Registration Authority (RA)... 7 2.6. Certificate Database and Repository... 8 3. Certificate Application... 9 3.1. Overview... 9 3.2. Application for Client and Server Certificates... 9 3.2.1. Client Certificates... 9 3.2.2. Server Certificates... 10 3.2.3. Intermediate Certificates... 11 4. Validation of Certificate Application... 13 4.1. Overview... 13 4.2. Validation Requirements for Certificate Application... 13 4.3. Approval of Certificate Application... 14 4.4. Rejection of Certificate Application... 14 5. Certificate Issuance... 15 5.1. Overview... 15 5.2. Issuance & Publication... 15 5.2.1. Denial of Certification... 15 5.3. Certificate Validity and Operational Periods... 15 5.4. Certificate Format... 16 6. Certificate Suspension... 17 2
6.1. Overview... 17 7. Certificate Revocation... 18 7.1. Overview... 18 7.2. General Reasons for Revocation... 18 7.3. Specific Reasons for Revocation... 18 7.4. Revocation of employers- and guest-certificates... 18 7.5. Automatic Revocation of student's certificates... 19 7.6. Revocation at Subscriber's Request... 19 7.6.1. Procedure for Automatic Revocation Request... 19 7.6.2. Procedure for Non-Automatic Revocation Request... 20 7.7. Revocation at RA or CA officer's Request... 20 8. Certificate Expiration... 22 8.1. Overview... 22 8.2. Certificate Expiry... 22 8.3. Certificate Renewal... 22 9. Security Audit Procedures... 23 9.1.1. Types of Events Recorded... 23 9.1.2. Frequency of Processing Log... 23 9.1.3. Protection of Audit Log... 23 9.1.4. Audit Log Backup Procedures... 24 9.1.5. Notification to Event Causing Subject... 24 9.2. Records Archival... 24 9.2.1. Events Recorded in Operational Authority Database... 24 9.2.2. Retention Period for Archive Files... 25 9.2.3. Protection of Archive Files... 25 9.2.4. Archive Backup Procedures... 25 9.2.5. Archive Collection System... 25 9.2.6. Procedures to Obtain and Verify Archive Information... 26 9.3. Compromise of the Certificate Authority Private Key... 26 9.4. Disaster Recovery... 27 9.5. Certificate Authority Termination of Services... 27 10. Relationship between CPS and CP... 28 11. List of Changes... 30 12. Appendix... 31 12.1. Definitions... 31 12.2. Key words for use in RFCs to Indicate Requirement Levels... 31 3
1. Introduction 1.1. Overview Scope of the document This Certificate Practice Statement (CPS) describes the practices and standards employed by the FernUniversität in Hagen 1 Certification Authority (CA) in the performance of certification services. By explaining the methods used by the CA to manage and complete tasks associated with certificate generation, the CPS will promote and engender trust in the CAs Public Key Infrastructure (PKI). This CPS is applicable to all parties with relationships to the CA, whose roles are defined in it, including subscribers (e.g. certificate owners). Relationship to other documents Every CAs has to adopt the regulations defined in the Scientific Trust Certificate Policy (CP). More detailed information about the general regulations, which conforming CAs employ in their operations in issuing certificates, can be found in the Scientific Trust Certificate Policy (CP). Nomenclature Within the document the words ''must'', ''must not'', ''required'', ''shall'', ''optional'',..., are to be interpreted as defined in RFC 2119. Scope of the CPS CP, section 1.1. 1.2. Scope of the Certification Services The certification services are provided to improve the use of electronic mail (S/MIME), electronic communications, electronic commerce, electronic transactions and other activities by securing e.g. web-, mail-, ldap- or other network services. Certification Services provide the universities' users and those who deal and communicate with them a higher level of internet-security. To accomplish this objective, the CA will issue and manage certificates in accordance with this CPS. The certification services offered by the CA cover the following: Certificate Application/Request, Certificate Issuance, Certificate Publication, Certificate Expiry, Certificate Revocation, 1 succeeding: university 4
Certificate Revocation List (CRL) Generation and Management. 1.3. CA Identity The FernUniversität in Hagen Certification Authority (CA) performs certification services on behalf of the following organization: Company Name: Registered Offices: Address: FernUniversität in Hagen Zentrum für Medien und IT Certification Authority (CA) Feithstraße. 150b, 58084 Hagen Telephone: +49 (23 31) 9 87-28 29 Fax: +49 (23 31) 9 87-19 - 28 29 Electronic mail: caadmin@fernuni-hagen.de 1.4. Publication This Certificate Practice Statement is published in electronic form at http://ca.fernuni-hagen.de/. 1.5. Further Information A website, containing information regarding the use of digital certificates issued by FernUniversität in Hagen's Certification Authority (CA), is provided at http://ca.fernuni-hagen.de/. Users, server administrators and relying parties must familiarize themselves with this CPS and the associated CP before applying for, using, or relying upon certificates. 5
2. CA Certification Infrastructure 2.1. Overview The CA will facilitate the confirmation of identity within the universities domain. Such facilitation shall be accomplished by means of a certificate, i.e., a digitally signed message, issued by the CA as part of a certification process. The high level management of this certification process includes registration, naming, appropriate applicant authentication, issuance, revocation, and audittrail generation. 2.2. Roles and Responsibilities The Policy Managing Authority (PMA) is the CA itself. The PMA is responsible for the selection and definition of certificate policies for the university, approval of any cross-certification agreements with external Certification Authorities, conducting compliance audits of the CA, and review of this CPS to ensure consistency with the ''Certification Policy (CP)''. The CA is operated by the University of Hagen`s computing center. CA has operational authority over the universities Public Key Infrastructure. As of the effective date of this CPS, the sole universities Registration Authority (RA) is the CA. However, as it seems appropriate, the CA may appoint organizations outside of the computing center as additional RAs. In such event, all RAs shall collectively constitute the CA. The RA is needed for the physical identification/authentication of subscribers. CA security officers will interface with the system mainly for CA functions and the computing centers help desk personnel will interface with the system mainly for managing subscribers. The names of the employees filling the described positions are available from the computing center. Policy Management Authority CP, section 1.4.1. Certification Authority (CA) CP, section 1.3.1. Registration Authority (RA) CP, section 1.3.2. CPS approval procedures CP, section 8.3. 2.3. Certificate Classes The CA issues client and server Certificates. Authorization levels differ from the type of certificate requested. Important Notice: Data recovery can not be assured for any kind of certificates. No encrypted files, emails or data may be recovered. This CA does not support key escrow and key recovery at all. 6
Private key escrow CP, section 6.2.3. 2.3.1. Client Certificates The client certificate is for users 2 with a valid network ID and password. It is used for email and file encryption, server log-on and browser purposes. Authentication level is web. 2.3.2. Server Certificates The server certificate is intended for server and code signing purposes. Employee applicants for a server Certificate must physically identify themselves. Applicants will be authenticated by CAs security officers in the computing centers location with their identity card or passport. No other documents will be accepted. Authentication level is personal. Server certificates will not be issued for universities students or guests. 2.4. Certification Authority (CA) The CA shall operate in accordance with this CPS and the ''Certification Policy (CP)'' and issue, manage, and revoke client and server certificates. Functions of the CA cover the following: Certificate Application, Certificate Issuance, Certificate Publication, Certificate Expiry, Certificate Revocation, Certificate Revocation List (CRL) issue and Management. CA obligations CP, section 2.1.1. 2.5. Registration Authority (RA) With the exceptions noted below, the RA will evaluate and approve or reject certificate applications on behalf of the CA, who will actually issue the certificates. 2 Universities students, employees and guests. 7
RA officers will coordinate certificate applications, validate the identity of certificate applicants, and confirm the information obtained during the application process. The type, scope and extent of confirmations required are dependent upon the certificate applied for. The RA will approve certificate applications, on behalf of the CA after ensuring that the whole certification application procedure has been performed in accordance with the practice defined by this CPS. Certificate requests will be accepted via the certificate server web forms only. RA obligations CP, section 2.1.2. 2.6. Certificate Database and Repository A certificate database shall be maintained to keep track of the pending certificate requests, issued or revoked certificates and Certificate Revocation Lists (CRL). Only the RA and CA shall have the authority to update this database. A web user interface will be provided for users to query the status of their certificate requests and any issued or revoked certificate. The web server interface is available at https://ca.fernuni-hagen.de/certserver/. Publication of CA information CP, section 2.6.1. Personnel Controls CP, section 5.3. 8
3. Certificate Application 3.1. Overview This section describes the certificate application process. It includes the requirements for key pair generation and protection and lists the information required for each certificate. 3.2. Application for Client and Server Certificates The CA establishes different authentication levels for client and server certificates. 3.2.1. Client Certificates For client certificates authentication level is web. Actor's actions are as defined below: Actor Number Action Applicant 1. Enroles at the university and has to accept the enrollment rules, The applicant is legally bound to indicate his proper email adress and retieve at least every 14 days the email box. University 2. Identifies the applicants address. University 3. Stores address, e-mail, registration number and network ID in central database. Applicant 4. Submits his registration number by filling out the web form https://account.fernunihagen.de/password.php in order to apply for a password. CA 5. Generates and stores password in combination with first name, second name, e-mail, network ID in certificate database. CA 6. Sends password by postal services to address located in central database. Applicant 7. Submits his registration number and password by filling out web form https://ca.fernunihagen.de/certserver/, follows the instructions displayed and requests a certificate. CA 8. Receives and reviews the request automatically. CA 9. Issues the requested certificate and offers it for download. 9
CA 10. Stores the certificate in certificate database and publishes it (https://ca.fernunihagen.de/certserver/). Applicant 11. Downloads and installs certificate. Applicant 12. Ensures certificate usage in conformity with CP and this CPS. Subscriber obligations CP, section 2.1.3. Authentication of the individual identity CP, section 3.1.9. Certificate Application CP, section 4.1. Certificate Issuance CP, section 4.2. 3.2.2. Server Certificates For server certificates authentication level is personal. Server certificates are issued only for the universities employees. Actor's actions are as defined below: Actor Number Action Applicant 1. Takes employment at the university. University 2. Stores office address, network ID in central database and assigns the applicant an e-mail adress Applicant 3. Submits his network ID by filling out the web form https://account.fernunihagen.de/password.php in order to apply for a password. CA 4. Stores password in combination with first name, second name, e-mail, network ID in certificate database. CA 5. Sends password by postal services to address located in central database. Applicant 6. Submits his network ID and password by filling out the web form https://ca.fernunihagen.de/certserver/, follows the instructions displayed and requests a certificate. CA 7. Receives and reviews the request manually. 10
CA 8. Identifies the applicant with applicants identity card. CA 9. Verifies the domain ownership by asking the dns administrator of the university. The administrator knows the link between person and domain ownership. CA 10. Issues the requested certificate. CA 11. Hands out certificate to applicant. CA 12. Stores the certificate in certificate database and publishes it (https://ca.fernunihagen.de/certserver/). Applicant 13. Ensures certificate usage in conformity with CP and this CPS. If an Intermediate CA wants to issue an Intermediate CA certificate, we want to add the following to the Scientific Trust CPS document: For intermediate certificates authentication level is personal. Actor's actions are as defined below: 3.2.3. Intermediate Certificates For intermediate certificates authentication level is personal. Actor's actions are as defined below: Actor Number Action Applicant 1. Wants to have an intermediate certificate Intermediate CA 2. Requests more informationen over the applicant and wants a CPS document. Applicant 3. Submits his CPS document to the CA Intermediate CA Scientific Trust Intermediate CA Intermediate CA 4. Checks the CPS document. 5. CA performs an audit at the applicant. 6. Issues the requested certificate. 7. Hands out certificate to applicant. Applicant 8. Ensures certificate usage in conformity with CP and this CPS. 11
Subscriber obligations CP, section 2.1.3. Authentication of individual identity CP, section 3.1.9. Certificate Application CP, section 4.1. Certificate Issuance CP, section 4.2. 12
4. Validation of Certificate Application 4.1. Overview This section presents the requirements for validation of certificate applications to be performed by the RA on behalf of the CA. It also explains the procedures applicable to applications that are not approved. 4.2. Validation Requirements for Certificate Application Upon receipt of a certificate application, the RA shall perform all required validations as a prerequisite to certificate issuance by the CA. Once a certificate is issued, the CA and RA shall have no continuing duty to monitor and investigate the accuracy of the information in the certificate, unless the CA or RA is notified in accordance with this CPS of that certificate's compromise or a request to change any significant detail (i.e., Name, Department, etc.). The following table highlights certain differences between the validation requirements for each certificate class. The CA shall have the right to update these validation requirements to improve the validation process. client certificate server certificate personal authentication not applicable mandatory web authentication mandatory mandatory authentication code mandatory mandatory identity card validation not applicable mandatory The following table describes, who is allowed to apply for which type of certificate: client certificate server certificate students yes no employees yes yes guests yes no Authentication of the individual identity CP, section 3.1.9. Certificate Issuance CP, section 4.2. 13
4.3. Approval of Certificate Application Upon successful accomplishment of all certificate application validation requirements, the RA shall approve applications on behalf of the CA. The CA shall issue the appropriate certificates based upon such approvals. 4.4. Rejection of Certificate Application If any of the validation requirements have not been fulfilled, the RA shall reject the certificate application on behalf of the CA and promptly notify the certificate applicant of the validation failure and the reason for such failure. Any applicant whose certificate application is rejected may reapply, provided that the reason for rejection has been resolved. Certificate Issuance CP, section 4.2. 14
5. Certificate Issuance 5.1. Overview This section presents additional information concerning the issuance of certificates. 5.2. Issuance & Publication Upon approval of a certificate application by the RA on behalf of the CA, and receipt of the approval by the CA via the certificate server, the CA will issue a certificate. The issued certificate and the corresponding public key will be added by the CA to the universities certificate repository where it is publicly accessible. CA obligations CP, section 2.1.1. RA obligations CP, section 2.1.2. Repository obligations CP, section 2.1.5. Certificate Issuance CP, section 4.2. 5.2.1. Denial of Certification The university may deny issuance of a certificate to any person, at its sole discretion, and assumes no liability or responsibility for any damages, losses or expenses of any nature arising out of or caused by such denial. Certificate Issuance CP, section 4.2. 5.3. Certificate Validity and Operational Periods Certificates shall be considered valid if Issued by the CA, and Listed on the CAs repository, and Not listed on the current CAs CRL, and Not expired, and Verifiable by a valid CA certificate. The standard operational periods for the various classes of certificates are as follows, subject to earlier suspension or revocation of the operational period. 15
certificate class client server CA validity period 3 years 3 years 10 years 5.4. Certificate Format The format of all certificates issued by the CA complies with ISO/IEC 9594 X.509 version 3. Certificate Profile CP, section 7.1. Version number(s) CP, section 7.1.1. 16
6. Certificate Suspension 6.1. Overview This CA does not support certificate suspension at all. Instead of being suspended, a certificate may be revoked and the user can reapply for a new certificate. Circumstances for suspension CP, section 4.4.5. 17
7. Certificate Revocation 7.1. Overview This section sets forth the circumstances under which a certificate may or must be revoked by the CA. It also details the procedures for revoking certificates. 7.2. General Reasons for Revocation A certificate shall be revoked by the CA if There has been a loss, theft, unauthorized disclosure, or other compromise of the private key of the subscriber. The subscriber has breached a significant requirement of this CPS. Information pertaining to the security of the certificate is essentially threatened or compromised for any reason. There has been a modification of the information contained in the certificate concerning the subscriber. The student has left university. The subscriber is no longer employed or in the universities service, or is no longer doing business with the university, or the reason for issuance of the certificate ceases to exist. The subscriber applies for revocation. Circumstances for revocation CP, section 4.4.1. 7.3. Specific Reasons for Revocation The CA must revoke a certificate if An essential fact represented in the certificate application or certificate is or is reasonably believed by the RA or CA to be false. An essential prerequisite to certificate issuance was not satisfied. The private key or other aspect of the system was compromised in a manner significantly affecting the certificate's reliability. The subscriber has breached a significant requirement of this CPS. Circumstances for revocation CP, section 4.4.1. 7.4. Revocation of employers- and guest-certificates 18
When universities employers or guests are no longer doing business with the university, they have to request for revocation. The procedure for this revocation process is described in section 6.2. 7.5. Automatic Revocation of student's certificates A certificate will be automatically revoked, if a student leaves university. 7.6. Revocation at Subscriber's Request A certificate shall be revoked by the CA upon receipt of a formal request from the subscriber. Important Notice: This section describes the secure and trustworthy process used to initiate a revocation request. This process is often manual, e.g., in person, via secure e mail, telephone verification. The important factor is that the process should provide for the authentication of the requestor and integrity of the request. The requirements for identification and authentication of revocation requests are based on a threat, risk analysis based on the use of the certificates and type of subscribers, and should follow security guidelines in the universities security policy. Who can request revocation CP, section 4.4.2. Revocation Requests CP, section 3.4. 7.6.1. Procedure for Automatic Revocation Request Upon automatic validation of a revocation request from a subscriber, the certificate will be revoked automatically. The request must be made by submission of the web form https://ca.fernuni-hagen.de/certserver/ by the subscriber to the certificate server: Actor Number Action Subscriber 1. Submits registration number / network ID and password by filling out web form https://ca.fernuni-hagen.de/certserver/. Subscriber 2. Requests revocation of the certificate. CA 3. Receives and reviews the request automatically. CA 4. Revokes the requested certificate. CA 5. Issues and publishes a new CRL automatically ( 19
CA 6. Informs the subscriber. Procedure for revocation request CP, section 4.4.3. Revocation Requests CP, section 3.4. 7.6.2. Procedure for Non-Automatic Revocation Request Upon validation of a revocation request from a subscriber, the certificate will be revoked by the RA or CA Officer. Under specific circumstances, e.g., where the subscriber is travelling, the subscriber may be permitted to request revocation directly to the RA, CA or help desk. Under such circumstances, the help desk will authenticate the subscriber's request appropriate through data available in central databases. This procedure is the only procedure for revoking server certificates. Actor Number Action Subscriber 1. Contacts CA, RA or help desk. Subscriber 2. Requests revocation of the certificate. CA 3. Authenticates the Subscriber in a secure and trustworthy process. CA 4. Receives and reviews the request. CA 5. Revokes the requested certificate. CA 6. Issues and publishes a new CRL automatically CA 7. Informs the subscriber. Procedure for revocation request CP, section 4.4.3. Revocation requests CP, section 3.4. 7.7. Revocation at RA or CA officer's Request Under circumstances in which a key compromise is strongly suspected, the RA, CA or help desk will immediately revoke the certificate. In the case of 6.2 the decision to revoke the certificate shall be made by the RA, CA or the help desk respectively. 20
If a security officer of the RA or CA is initiating a revocation request, he must login by providing the appropriate credentials to the certificate server and initiate a revocation request. 21
8. Certificate Expiration 8.1. Overview This section provides information about certificate expiry and renewal procedures. 8.2. Certificate Expiry The CA will make reasonable efforts to notify subscribers via email, fourteen (14) days before the expiration date of their certificates, of the impending expiration of their certificates. All such notices will be sent for the convenience of subscribers only to assist them in the process of renewing their certifications. It is the responsibility of subscribers to monitor the expiration dates of their certificates. 8.3. Certificate Renewal For renewals of all classes of certificates, subscribers must apply for a new certificate as described in chapters 3 to 5 Routine Rekey CP, section 3.2. Rekey after Revocation CP, section 3.3. 22
9. Security Audit Procedures 9.1.1. Types of Events Recorded All significant security events on the CAs Public Key Infrastructure will be automatically recorded in audit trail files maintained by the CA. These events include: Events related to password issuance, events related to certificate application, issuance, publication and revocation, events related to security policy modification and validation, events related to database backup and management, events related to cross certification, events related to web server / certificate server usage, and events related to other miscellaneous events. Security Audit Procedures CP, section 4.5. Types of event recorded CP, section 4.5.1. 9.1.2. Frequency of Processing Log The audit trail shall be processed (reviewed for policy violations or other significant events) by the CA periodically, but at least once a month. Frequency of processing log CP, section 4.5.2. 9.1.3. Protection of Audit Log The audit trail will be stored in regular operating system flat files. Each audit trail file will consist of an audit header that contains information about the audits in the file and a list of events. The audit trail will be capable of being spread across many files. A new audit trail file will be created when the it deems to be appropriate for the CA officer. Individuals with security officer or audit privileges will be capable of viewing and processing audit trail files through custom built audit reduction reports / tools. Protection of audit log CP, section 4.5.4. 23
9.1.4. Audit Log Backup Procedures Audit trail files will be archived by the system administrator on a daily basis. All files, including the latest audit trail file, will be moved to magnetic tapes and stored in a secure archive facility in accordance with the universities operational backup procedures. Audit log backup procedures CP, section 4.5.5. 9.1.5. Notification to Event Causing Subject There is no notification system to inform the users of the universities PKI about audit event causing actions. Notification to event-causing subject CP, section 4.5.7. 9.2. Records Archival Both the audit trail files and the operational authority database will be archived, as described below. Audit logs will be maintained in accordance with existing universities standards. Records Archival CP, section 4.6. 9.2.1. Events Recorded in Operational Authority Database The types of events that will be recorded in the audit trail files are described in Section 9.1.1. of this CPS. The types of events that will be recorded in the operational authority database include: Creation of the CA signing key pair, Addition and removal of subscribers from the system; Changes to the encryption key pair history and verification public key history for all subscribers, including certificate issuance and revocation events, Addition/removal of administrator and security officer privileges; Changes to the privileges of RA personnel; 24
Changes to policy, such as certificate validity period, and Creation and revocation of cross certificates. Types of event recorded CP, section 4.6.1. 9.2.2. Retention Period for Archive Files The archives will be retained as required by the universities record retention policy. Retention period for archive CP, section 4.6.2. 9.2.3. Protection of Archive Files The operational authority database will be encrypted and protected by master user keys. Protection of the audit trail files will be as described in section 9.1.3. of this CPS. All archive media will be protected by physical security and will be retained in a restricted access facility to which only CA officers and the operational authority will have access. Protection of archive CP, section 4.6.3. 9.2.4. Archive Backup Procedures Archive files will be backed up as they are created. They will be stored on site and housed with the operational authority system. Archive backup procedures CP, section 4.6.4. 9.2.5. Archive Collection System The archive collection system (backup facility) for the operational authority database will be internal to the operational authority system. 25
The archive collection system (backup facility) for the audit trail files will be as described in section 9.1.4. of this CPS. The archiving will be external from the operational authority system. Archive collection system CP, section 4.6.6. 9.2.6. Procedures to Obtain and Verify Archive Information The archive tapes will regularly be retrieved and examined by the operational authority to ensure that no damage or loss of data has occurred. In addition, the condition of the archive will be verified during every compliance audit. Procedures to obtain and verify archive information CP, section 4.6.7. 9.3. Compromise of the Certificate Authority Private Key In case of a compromise, the CA will take the following steps, as a minimum, to recover a secure environment: Generate a new CA signing key in software or hardware (on separate HSM token). Update the CA signing key. This will renew the CAs certificate. Ensure all passwords are changed for the RA and CA security officers and administrators. Force key updates for all subscribers. Subscribers will generate new private signing keys / decryption keys the first time they log in and new subscriber public certificates signed by the new CA signing key will be issued. Archive the certificate database and the CRL. Revoke the old CA signing key. Any digital signatures created before the old CA key is revoked will no longer validate within the PKI because the PKI will no longer trust the revoked CA certificate and the old digital signatures can not be checked against a valid CRL. Relying parties will receive a message that the certificate should not be trusted. Important Notice: The specific actions to be taken in response to a CA private key compromise will be dependent on a threat, risk analysis and the nature of the compromise. 26
Compromise and disaster recovery CP, section 4.8. Computing resources, software and / or data are corrupted CP, section 4.8.1. 9.4. Disaster Recovery All operations of the PKI will be covered by a business continuity plan prepared by the CA that provides for a smooth transition to the Disaster Recovery (DR) facility. The business continuity plan shall provide for the following actions: The directory data, encryption certificates and CRLs will be restored from backup archives by the personnel responsible for doing so at the DR facility; The master user will restore the CA; and Should the profile of a security officer, administrator or the RA need recovery, another security officer will do so. If there are not enough security officers with valid security officer privileges in existence to recover a security officer profile, two master users will perform the recovery. Compromise and Disaster Recovery Computing resources, software and / or data are corrupted CP, section 4.8. CP, section 4.8.1. 9.5. Certificate Authority Termination of Services In the event that the CA ceases operation, the following procedures will be performed, as a minimum: All certificates issued by the CA will be revoked and a CRL will be published as long as any issued certificate would be valid without revocation. An archive of the certificate database will be created and retained for a minimum of 7 years. No further CRL or directory services are offered. The archive will be kept off-line. The archive will be made available only on the official directive of law enforcement agencies. CA Termination CP, section 4.9. 27
10. Relationship between CPS and CP The Certification Practice Statement defines the practices for managing certificates as defined in the Certification Policy. This CPS is based on Scientific Trusts Certification Policy. CPS chapters match to CP chapters as follows: CPS CP 1.1 Overview 1.1 Overview 2.2 Roles and Responsibilities 1.4.1 Specification administration organization 1.3.1 Certification Authorities 1.3.2 Registration Authorities 8.3 CPS approval procedure 2.3 Certificate Classes 6.2.3 Private Key Escrow 2.4 Certification Authority 2.1.1 CA obligations 2.5 Registration Authority 2.1.2 RA obligations 2.6 Certificate Database and Repository 2.6.1 Publication of CA Information 5.3 Personnel Controls 3.2.1 Client Certificates 2.1.3 Subscriber Obligations 3.1.9 Authentication of Individual Entity 4.1 Certificate Application 4.2 Certificate Issuance 4.2 Validation Requirements for Certificate Application 4.4 Rejection of Certificate Application 3.1.9 Authentication of Individual Entity 4.2 Certificate Issuance 4.2 Certificate Issuance 5.2 Issuance and Publication 2.1.1 CA obligations 2.1.2 RA obligations 2.1.5 Repository Obligations 4.2 Certificate Issuance 5.2.1 Denial of Certification 4.2 Certificate Issuance 28
5.4 Certificate Format 7.1 Certificate Profile 7.1.1 Version Numbers 6.1 Overview 4.4.5 Circumstances for Suspension 7.2 General Reasons for Revocation 4.4.1 Circumstances for Revocation 7.3 Specific Reasons for Revocation 4.4.1 Circumstances for Revocation 7.5 Revocation at Subscriber's Request 7.5.1 Procedure for Automatic Revocation Request 7.5.2 Procedure for Non-Automatic Revocation Request 4.4.2 Who can Request Revocation 3.4 Revocation Request 4.4.3 Procedure for Revocation Request 3.4 Revocation Request 4.4.3 Procedure for Revocation Request 3.4 Revocation Request 8.3 Certificate Renewal 3.2 Routine Rekey 3.3 Rekey after Revocation 9.1.1 Types of Events Recorded 4.5 Security Audit Procedures 4.5.1 Types of Events Recorded 9.1.2 Frequency of Processing Log 4.5.2 Security Audit Procedures 9.1.3 Protection of Audit Log 4.5.4 Protection of Audit Log 9.1.4 Audit Log Backup Procedures 4.5.5 Audit Log Backup Procedures 9.1.5 Notification to Event Causing Subject 4.5.7 Notification to Event Causing Subject 9.2 Records Archival 4.6 Records Archival 9.2.1 Events Recorded in Operational Authority Database 9.2.2 Retention Period for Archive Files 4.6.1 Types of Events Recorded 4.6.2 Retention Period for Archives 9.2.3 Protection of Archive Files 4.6.3 Protection for Archive 9.2.4 Archive Backup Procedure 4.6.4 Archive Backup Procedure 9.2.5 Archive Collection System 4.6.6 Archive Collection System (internal vs. external) 9.1.6 Procedures to Obtain and Verify Archive Information 4.6.7 Procedures to Obtain and Verify Archive Information 29
9.2 Compromise of the Certificate Authority Private Key 4.8 Compromise and Disaster Recovery 4.8.1 Computing Resources, Software, and/or Data are Corrupted 9.3 Disaster Recovery 4.8 Compromise and Disaster Recovery 4.8.1 Computing Resources, Software, and/or Data are Corrupted 9.4 Certificate Authority Termination of Services 4.9 CA Termination 11. List of Changes Version Date Changes 0.1 04.06.2003 not applicable 0.4 17.06.2003 DFN review 1.0 18.06.2009 Scientific Trust review 1.1 18.12.2009 new Section 3.2.3 30
12. Appendix 12.1. Definitions An authority trusted by one or more users to create and assign public key certificates. Optionally the CA may create the user's keys. It is important to note that the CA is responsible for the public key certificates during their whole lifetime, not just for issuing them. A certificate for one CAs public key issued by another CA. A named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements. For example, a particular certificate policy might indicate applicability of a type of certificate to the authentication of electronic data interchange transactions for the trading of goods within a given price range. A statement of the practices, which a certification authority employs in issuing, certificates. A CRL is a time stamped list identifying revoked certificates, which is signed by a CA and made freely available in a public repository. The expression ''conforming CA'' is used to indicate a CA whose behavior is conforming to the set of provisions specified in this document. In particular, this may be Scientific Trust RootCA or one of its Intermediate CAs. The Authority responsible for the maintenance of the CP and CPS. The set of hardware, software, people, policies and procedures needed to create, manage, store, distribute, and revoke PKCs based on public key cryptography. An entity that is responsible for identification and authentication of certificate subjects, but that does not sign or issue certificates (i.e., an RA is delegated certain tasks on behalf of a CA). [Note: The term Local Registration Authority (LRA) is used elsewhere for the same concept.] A recipient of a certificate who acts in reliance on that certificate and/or digital signatures verified using that certificate. In this document, the terms ''certificate user'' and ''relying party'' are used interchangeably. 12.2. Key words for use in RFCs to Indicate Requirement Levels According to RFC 2119 ''Key words for use in RFCs to Indicate Requirement Levels'', we specify how the main keywords used in RFCs should be interpreted. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words ''must'', ''must not'', ''required'', ''shall'', ''shall not'', ''should'', ''should not'', ''recommended'', ''may'', and ''optional'' in this document are to be interpreted as described in RFC 2119. This word, or the terms ''required'' or ''shall'', mean that the definition is an absolute requirement of the specification. This phrase, or the phrase ''shall not'', mean that the definition is an absolute prohibition of the specification. 31
This word, or the adjective ''recommended'', mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. This phrase, or the phrase ''not recommended'' mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. This word, or the adjective ''optional'', mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option must be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option must be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) 32