National Center for Scientific and Technical Research Certification Authority MaGrid CA Certificate Policy and Certification Practice Statement Document OID: 1.3.6.1.4.1.26529.10.1.2.0 Version 1.2.0 July 09, 2007 CONTENTS 1 INTRODUCTION 8 1.1 OVERVIEW 8 1.2 DOCUMENT NAME AND IDENTIFICATION 8 1.3 PKI PARTICIPANTS 9 1.3.1 Certification Authorities 9 1.3.2 Registration Authorities 9 1.3.3 Subscribers 9 1.3.4 Relying parties 9 1.3.5 Other participants 9 1.4 CERTIFICATE USAGE 10 1.4.1 Appropriate certificate uses 10 1.4.2 Prohibited certificate uses 10 1.5 POLICY ADMINISTRATION 10 1.5.1 Organization administering the document 10 1.5.2 Contact Person 10 1.5.3 Person determining CPS suitability for the policy 11 1.5.4 CPS approval procedures 11 1.6 DEFINITIONS AND ACRONYMS 11 1.6.1 Definitions 11 1.6.2 Acronyms 14 2 PUBLICATION AND REPOSITORY RESPONSIBILITIES 15 2.1 REPOSITORIES 15 2.2 PUBLICATION OF CA INFORMATION 15 2.3 TIME OR FREQUENCY OF PUBLICATION 15 2.4 ACCESS CONTROL ON REPOSITORIES 15 3 IDENTIFICATION AND AUTHENTICATION 16 3.1 NAMING 16 3.1.1 Types of names 16 3.1.2 Need for names to be meaningful 16 3.1.3 Anonymity or pseudonimity of subscribers 17 3.1.4 Rules for interpreting various name forms 17 3.1.5 Uniqueness of names 17 3.1.6 Recognition, authentication and role of trademarks 17 3.2 INITIAL IDENTITY VALIDATION 17 3.2.1 Method to prove possession of private key 17 3.2.2 Authentication of organization identity 17 3.2.3 Authentication of individual identity 18 3.2.4 Non-verified subscriber information 18 3.2.5 Validation of Authority 18 3.2.6 Criteria of interoperation 18 3.3 IDENTIFICATION AND AUTHENTICATION FOR RE-KEY REQUESTS 19 3.3.1 Identification and authentication for routine re-key 19 3.3.2 Identification and authentication for re-key after revocation 19 3.4 IDENTIFICATION AND AUTHENTICATION FOR REVOCATION REQUEST 19 4 CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS 19 4.1 CERTIFICATE APPLICATION 19 4.1.1 Who can submit a certificate application 19 4.1.2 Enrollment process and responsibilities 19 4.2 CERTIFICATE APPLICATION PROCESSING 20 4.2.1 Performing identification and authentication functions 20 4.2.2 Approval or rejection of certificate applications 20 4.2.3 Time to process certificate applications 20 4.3 CERTIFICATE ISSUANCE 20 4.3.1 CA actions during certificate issuance 20 4.3.2 Notification to subscriber by the CA of issuance of certificate 20 4.4 CERTIFICATE ACCEPTANCE 21 4.4.1 Conduct constituting certificate acceptance 21 4.4.2 Publication of the certificate by the CA 21 4.4.3 Notification of certificate issuance by the CA to other entities 21 4.5 KEY PAIR AND CERTIFICATE USAGE 21 4.5.1 Subscriber private key and certificate usage 21 4.5.2 Relying party public key and certificate usage 21 4.6 CERTIFICATE RENEWAL 21 4.6.1 Circumstance for certificate renewal 21 4.6.2 Who may request renewal 21 4.6.3 Processing certificate renewal requests 22 4.6.4 Notification of new certificate issuance to subscriber 22 4.6.5 Conduct constituting acceptance of a renewal certificate 22 4.6.6 Publication of the renewal certificate by the CA 22 4.6.7 Notification of certificate issuance by the CA to other entities 22 4.7 CERTIFICATE RE-KEY 22 4.7.1 Circumstance for certificate re-key 22 4.7.2 Who may request certification of a new public key 22 4.7.3 Processing certificate re-keying requests 22 4.7.4 Notification of new certificate issuance to subscriber 22 4.7.5 Conduct constituting acceptance of a re-keyed certificate 22 4.7.6 Publication of the re-keyed certificate by the CA 23 4.7.7 Notification of certificate issuance by the CA to other entities 23 4.8 CERTIFICATE MODIFICATION 23 4.8.1 Circumstance for certificate modification 23 4.8.2 Who may request certificate modification 23 4.8.3 Processing certificate modification requests 23 4.8.4 Notification of new certificate issuance to subscriber 23 4.8.5 Conduct constituting acceptance of modified certificate 23 4.8.6 Publication of the modified certificate by the CA 23 4.8.7 Notification of certificate issuance by the CA to other entities 23 4.9 CERTIFICATE REVOCATION AND SUSPENSION 23 4.9.1 Circumstances for revocation 23 4.9.2 Who can request revocation 24 4.9.3 Procedure for revocation request 24 4.9.4 Revocation request grace period 24 4.9.5 Time within which CA must process the revocation request 24 4.9.6 Revocation checking requirement for relying parties 24 4.9.7 CRL issuance frequency 24 4.9.8 Maximum latency for CRLs 24 4.9.9 On-line revocation/status checking availability 25 4.9.10 On-line revocation checking requirements 25 4.9.11 Other forms of revocation advertisements available 25 4.9.12 Special requirements re-key compromise 25 4.9.13 Circumstances for suspension 25 4.9.14 Who can request suspension 25 4.9.15 Procedure for suspension request 25 4.9.16 Limits on suspension period 25 4.10 CERTIFICATE STATUS SERVICES 25 4.10.1 Operational characteristics 25 4.10.2 Service availability 25 4.10.3 Optional features 25 4.11 END OF SUBSCRIPTION 25 4.12 KEY ESCROW AND RECOVERY 26 4.12.1 Key escrow and recovery policy and practices 26 4.12.2 Session key encapsulation and recovery policy and practices 26 5 FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS 26 5.1 PHYSICAL CONTROLS 26 5.1.1 Site location and construction 26 5.1.2 Physical access 26 5.1.3 Power and air conditioning 26 5.1.4 Water exposures 27 5.1.5 Fire prevention and protection 27 5.1.6 Media storage 27 5.1.7 Waste disposal 27 5.1.8 Off-site backup 27 5.2 PROCEDURAL CONTROLS 27 5.2.1 Trusted roles 27 5.2.2 Number of persons required per task 27 5.2.3 Identification and authentication for each role 27 5.2.4 Roles requiring separation of duties 27 5.3 PERSONNEL CONTROLS 28 5.3.1 Qualifications, experience, and clearance requirements 28 5.3.2 Background check procedures 28 5.3.3 Training requirements 28 5.3.4 Retraining frequency and requirements 28 5.3.5 Job rotation frequency and sequence 28 5.3.6 Sanctions for unauthorized actions 28 5.3.7 Independent contractor requirements 29 5.3.8 Documentation supplied to personnel 29 5.4 AUDIT LOGGING PROCEDURES 29 5.4.1 Types of events recorded 29 5.4.2 Frequency of processing log 30 5.4.3 Retention period for audit log 30 5.4.4 Protection of audit log 30 5.4.5 Audit log backup procedures 30 5.4.6 Audit collection system (internal vs. external) 30 5.4.7 Notification to event-causing subject 30 5.4.8 Vulnerability assessments 30 5.5 RECORDS ARCHIVAL 30 5.5.1 Types of records archived 30 5.5.2 Retention period for archive 30 5.5.3 Protection of archive 30 5.5.4 Archive backup procedures 31 5.5.5 Requirements for time-stamping of records 31 5.5.6 Archive collection system (internal or external) 31 5.5.7 Procedures to obtain and verify archive information 31 5.6 KEY CHANGEOVER 31 5.7 COMPROMISE AND DISASTER RECOVERY 31 5.7.1 Incident and compromise handling procedures 31 5.7.2 Computing resources, software, and/or data are corrupted 32 5.7.3 Entity private key compromise procedures 32 5.7.4 Business continuity capabilities after a disaster 32 5.8 CA OR RA TERMINATION 32 6 TECHNICAL SECURITY CONTROLS 33 6.1 KEY PAIR GENERATION AND INSTALLATION 33 6.1.1 Key pair generation 33 6.1.2 Private key delivery to subscriber 33 6.1.3 Public key delivery to certificate issuer 33 6.1.4 CA public key delivery to relying parties 33 6.1.5 Key sizes 33 6.1.6 Public key parameters generation and quality checking 34 6.1.7 Key usage purposes (as per X.509 v3 key usage field) 34 6.2 PRIVATE KEY PROTECTION AND CRYPTOGRAPHIC MODULE ENGINEERING CONTROLS 34 6.2.1 Cryptographic module standards and controls 34 6.2.2 Private key (n out of m) multi-person control 34 6.2.3 Private key escrow 34 6.2.4 Private key backup 34 6.2.5 Private key archival 35 6.2.6 Private key transfer into or from a cryptographic module 35 6.2.7 Private key storage on cryptographic module 35 6.2.8 Method of activating private key 35 6.2.9 Method of deactivating private key 35 6.2.10 Method of destroying private key 35 6.2.11 Cryptographic Module Rating 35 6.3 OTHER ASPECTS OF KEY PAIR MANAGEMENT 35 6.3.1 Public key archival 35 6.3.2 Certificate operational periods and key pair usage periods 35 6.4 ACTIVATION DATA 35 6.4.1 Activation data generation and installation 35 6.4.2 Activation data protection 36 6.4.3 Other aspects of activation data 36 6.5 COMPUTER SECURITY CONTROLS 36 6.5.1 Specific computer security technical requirements 36 6.5.2 Computer security rating 36 6.6 LIFE CYCLE TECHNICAL CONTROLS 36 6.6.1 System development controls 36 6.6.2 Security management controls 36 6.6.3 Life cycle security controls 36 6.7 NETWORK SECURITY CONTROLS 36 6.8 TIME-STAMPING 37 7 CERTIFICATE, CRL, AND OCSP PROFILES 37 7.1 CERTIFICATE PROFILE 37 7.1.1 Version number(s) 37 7.1.2 Certificate extensions 37 7.1.3 Algorithm object identifiers 38 7.1.4 Name forms 38 7.1.5 Name constraints 38 7.1.6 Certificate policy object identifier 39 7.1.7 Usage of Policy Constraints extension 39 7.1.8 Policy qualifiers syntax and semantics 39 7.1.9 Processing semantics for the critical Certificate Policies extension 39 7.2 CRL PROFILE 39 7.2.1 Version number(s) 39 7.2.2 CRL and CRL entry extensions 39 7.3 OCSP PROFILE 39 7.3.1 Version number(s) 39 7.3.2 OCSP extensions 40 8 COMPLIANCE AUDIT AND OTHER ASSESSMENTS 40 8.1 FREQUENCY OR CIRCUMSTANCES OF ASSESSMENT 40 8.2 IDENTITY/QUALIFICATIONS OF ASSESSOR 40 8.3 ASSESSOR'S RELATIONSHIP TO ASSESSED ENTITY 40 8.4 TOPICS COVERED BY ASSESSMENT 40 8.5 ACTIONS TAKEN AS A RESULT OF DEFICIENCY 41 8.6 COMMUNICATION OF RESULTS 41 9 OTHER BUSINESS AND LEGAL MATTERS 41 9.1 FEES 41 9.1.1 Certificate issuance or renewal fees 41 9.1.2 Certificate access fees 41 9.1.3 Revocation or status information access fees 41 9.1.4 Fees for other services 41 9.1.5 Refund policy 41 9.2 FINANCIAL RESPONSIBILITY 41 9.2.1 Insurance coverage 41 9.2.2 Other assets 41 9.2.3 Insurance or warranty coverage for end-entities 42 9.3 CONFIDENTIALITY OF BUSINESS INFORMATION 42 9.3.1 Scope of confidential information 42 9.3.2 Information not within the scope of confidential information 42 9.3.3 Responsibility to protect confidential information 42 9.4 PRIVACY OF PERSONAL INFORMATION 42 9.4.1 Privacy plan 42 9.4.2 Information treated as private 42 9.4.3 Information not deemed private 42 9.4.4 Responsibility to protect private information 42 9.4.5 Notice and consent to use private information 43 9.4.6 Disclosure pursuant to judicial or administrative process 43 9.4.7 Other information disclosure circumstances 43 9.5 INTELLECTUAL PROPERTY RIGHTS 43 9.6 REPRESENTATIONS AND WARRANTIES 44 9.6.1 CA representations and warranties 44 9.6.2 RA representations and warranties 44 9.6.3 Subscriber representations and warranties 44 9.6.4 Relying party representations and warranties 45 9.6.5 Representations and warranties of other participants 45 9.7 DISCLAIMERS OF WARRANTIES 45 9.8 LIMITATIONS OF LIABILITY 45 9.9 INDEMNITIES 46 9.10 TERM AND TERMINATION 46 9.10.1 Term 46 9.10.2 Termination 46 9.10.3 Effect of termination and survival 46 9.11 INDIVIDUAL NOTICES AND COMMUNICATIONS WITH PARTICIPANTS 46 9.12 AMENDMENTS 47 9.12.1 Procedure for amendment 47 9.12.2 Notification mechanism and period 47 9.12.3 Circumstances under which OID must be changed 47 9.13 DISPUTE RESOLUTION PROVISIONS 47 9.14 GOVERNING LAW 47 9.15 COMPLIANCE WITH APPLICABLE LAW 47 9.16 MISCELLANEOUS PROVISIONS 47 9.16.1 Entire agreement 47 9.16.2 Assignment 47 9.16.3 Severability 48 9.16.4 Enforcement (attorneys' fees and waiver of rights) 48 9.16.5 Force Majeure 48 9.17 OTHER PROVISIONS 48 10 REFERENCES 49 11 LIST OF CHANGES 50 1 INTRODUCTION This document is structured according to RFC 3647 [RFC3647]. Not all sections of RFC 3647 are used. Sections that are not included have a default value of "No stipulation". This document describes the set of rules and procedures established by CNRST (Centre National pour la Recherche Scientifique et Technique) for the operations of the Moroccan Grid Certification Authority (MaGrid CA) service. The data center housing the MaGrid CA server is located in Rabat. This document will include both the Certificate Policy and the Certification Practice Statement for the MaGrid CA. The general architecture is a single certification authority and several registration authorities. 1.1 OVERVIEW MaGrid is the infrastructure to support e-science activities provided by the CNRST according the Moroccan National Grid Initiative. This document describes the set of rules and operational practices that shall be used by the MaGrid CA, the Certification Authority (CA) for MaGrid, for issuing certificates. This and any subsequent CP/CPS document can be found on its web site http://www.magrid.ma/ca/ 1.2 DOCUMENT NAME AND IDENTIFICATION Title: MaGrid CA Certificate Policy (CP) and Certification Practice Statement (CPS) Version: 1.2.0, July 09, 2007 Expiration: This document is valid until further notice OID assigned: 1.3.6.1.4.1.26529.10.1.2.0 OID structure: 1.3.6.1.4.1 IANA Iso(1). org(3). dod(6). internet(1). private(4). enterprise(1) 26529 CNRST 10 MaGrid CA 1 CP/CPS 2 Major CP/CPS version number 0 Minor CP/CPS version number 1.3 PKI PARTICIPANTS 1.3.1 Certification Authorities The certification authority is a stand-alone self-signed CA. The MaGrid CA does not issue certificates to subordinate Certification Authorities. 1.3.2 Registration Authorities The MaGrid CA does not perform the role of RA. Each participating organization in MaGrid may appoint an RA for its own members and servers. It is also possible that one RA can manage members and servers for other participants in MaGrid if no RA exists for these users. The list of RAs for the MaGrid is available from the MaGrid CA web site http://www.magrid.ma/ca/ 1.3.3 Subscribers Subscribers MUST belong to one of the following types of organizations to be eligible for certification by the MaGrid CA: a) Moroccan academic organizations (e.g. public and private universities and educational institutes); b) Moroccan academic research centers (either public or private, non-profit ones); c) Other organizations with research and development (R&D) affiliations with one of the above classes of organization. The subject entities for certificates are of the following types: d) Employees, researchers and students related with the above organizations; or, e) Computer systems and services related with the above organizations; 1.3.4 Relying parties Relying parties may be: " natural persons receiving signed e-mails, or accessing hosts or services " hosts to which certificate owners log in or send processes or jobs " services called by owners of a certificate 1.3.5 Other participants No stipulation. 1.4 CERTIFICATE USAGE 1.4.1 Appropriate certificate uses The certificates issued by MaGrid CA may be used for any application that is suitable for X.509 certificates, in particular: " authentication of users, hosts and services " authentication and encryption of communications " authentication of signed e-mails " authentication of signed objects They may only be used or accepted for actions compatible with the certificate extensions.. 1.4.2 Prohibited certificate uses The certificates issued by MaGrid CA must not be used for financial transactions. They must not be used for purposes that violate Moroccan law or the law of the country in which the target entity (i.e. application or host to use, addressee of an e-mail) is located. 1.5 POLICY ADMINISTRATION 1.5.1 Organization administering the document The MaGrid CP/CPS was authored and is administered by MARWAN/MaGrid department of CNRST, located in Rabat (Morocco). CNRST is responsible for registration, maintenance, and interpretation of this CP/CPS. It is reachable at: CNRST 52, Av Omar Ibn AlKhattab BP 8027.Agdal -10102 Rabat Morocco Phone : +212 37 68 62 33/34 Fax : +212 37 68 62 35 E-mail : magrid@cnrst.ma Home page : http://www.cnrst.ma 1.5.2 Contact Person The CA manager (contact person for questions related to this policy document) is: Redouane Merrouch CNRST-MaGrid, 52, Av Omar Ibn AlKhattab BP 8027.Agdal 10102 Rabat Morocco. Phone : +212 37 68 62 23 Fax : +212 37 68 62 35 E-mail : merrouch@cnrst.ma 1.5.3 Person determining CPS suitability for the policy The manager of the MaGrid CA (see 1.5.2) is responsible for determining the CPS suitability for the policy. 1.5.4 CPS approval procedures The approved document shall be submitted to EUGridPMA for acceptance and accreditation. 1.6 DEFINITIONS AND ACRONYMS 1.6.1 Definitions 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 [RFC2119]. Activation Data Data values, other than keys, that are required to operate cryptographic modules and that need to be protected (i.e., a PIN, a passphrase, or a manually-held key share). Authentication The process of establishing that individuals, organizations, or things are who or what they claim to be. In the context of a PKI, authentication can be the process of establishing that an individual or organization which applies for or seeks access to something under a certain name is, in fact, the proper individual or organization. This process corresponds to the second process involved with identification, as shown in the definition of "identification" below. Authentication can also refer to a security service providing assurances that individuals, organizations, or things are who or what they claim to be or that a message or other data originated from a specific individual, organization, or device. Thus, it is said that a digital signature of a message authenticates the message's sender. Certification Authority (CA) An authority trusted by one or more subscribers to create and assign public key certificates and to be responsible for them during their whole lifetime. That entity / system issues X.509 identity certificates (places a subject name and public key in a document and then digitally signs that document using the private key of the CA) Certificate Policy (CP) A named set of rules indicating the applicability of a certificate to a particular community and/or class of applications 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. Certification Practice Statement (CPS) A statement of the practices, which a certification authority employs in issuing certificates. Community RM One or more RMs that serve multiple, low request rate, sites / Virtual Organizations. Host Certificate A Certificate for server certification and encryption of communications (SSL/TSL). It will represent a single machine. Identification The process of establishing the identity of an individual or organization, i.e., to show that an individual or organization is a specific individual or organization. In the context of a PKI, identification refers to two processes: (1) establishing that a given name of an individual or organization corresponds to a real world identity of an individual or organization, and (2) establishing that an individual or organization applying for or seeking access to something under that name is, in fact, the named individual or organization. A person seeking identification may be a certificate applicant, an applicant for employment in a trusted position within a PKI participant, or a person seeking access to a network or software application, such as a CA administrator seeking access to CA systems. Issuing Certification Authority (Issuing CA) In the context of a particular certificate, the issuing CA is the CA that issued the certificate. Person Certificate A certificate used for authentication to establish a Grid Person Identity. It will represent an individual person. Policy Qualifier The Policy-dependent information that accompanies a certificate policy identifier in an X.509 certificate. Point of Contact The member of a site/VO RA that has been chosen to handle all communications about policy matters with the Grid manager. Private RM RMs that serve high certificate request rate sites / Virtual Organizations, and that are operated by the site/VO. Registration Authority (RA) 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). Registration Agent (RAg) or "Agent" RAg is the entity that interacts with the RM in order to cause the CA to issue certificates. Registration Manager (RM) The RM is a front-end Web server for the CA that provides a Web user interface for CA subscribers and agents. The RM forwards certificate signing requests to the actual CA to issue X.509 certificates. Relying Party (RP) A recipient of a certificate who acts in reliance on that certificate and/or digital signatures verified using that certificate. Repository A storage area, usually on-line, which contains lists of issued certificates, CRLs, policy documents, etc. Service Certificate A certificate for a particular service running on a host. It will represent a single service on a single host. Subscriber Or sometimes called End Entity is a person who a digital certificate is issued. Virtual Organization (VO) An organization that has been created to represent a particular research or development effort independent of the physical sites that the Scientist or Engineers work at. (i.e. PPDG, FNC, EDG, etc). 1.6.2 Acronyms C Country CA Certification Authority CN Common Name CDROM Compact Disc Read Only Memory CP Certificate Policy CPS Certification Practice Statement CRL Certificate Revocation List CSR Certificate Signing Request DN Distinguished Name EUGridPMA The European Grid Authentication Policy Management Authority in e-Science, http://www.eugridpma.org/ MaGrid CA Moroccan Grid Certification Authority MARWAN Moroccan Academic and Research Network CNRST National Center for Scientific and Technical Research LDAP Lightweight Directory Access Protocol MIME Multi-purpose Internet Mail Extensions NTP Network Time Protocol O Organization OU Organizational Unit PKI Public Key Infrastructure RA Registration Authority SSL Secure Sockets Layer UPS Uninterruptible Power Supply URI Universal Resource Identifier URL Universal Resource Locator OID Object Identifier FQDN Fully Qualified Domain Name 2 PUBLICATION AND REPOSITORY RESPONSIBILITIES 2.1 REPOSITORIES The online repository of information from the MaGrid CA is accessible at the URL http://www.magrid.ma/ca/ 2.2 PUBLICATION OF CA INFORMATION The MaGrid CA will operate a secure online repository that contains: 1. The MaGrid CA's certificate, and all previous ones necessary to check still valid certificates, 2. The certificates issued by the CA, 3. A Certificate Revocation List, 4. A copy of the most recent version of this policy and all previous versions, 5. The official contact e-mail address and physical contact address, 6. Other information deemed relevant to the MaGrid CA service. 2.3 TIME OR FREQUENCY OF PUBLICATION All information published shall be up-to-date. Certificates will be published to the MaGrid CA repository as soon as issued. The certificate revocation list (CRL) shall have a lifetime of at most 30 days. The MaGrid CA must issue a new CRL at least 7 days before expiration or immediately after having processed a revocation, whichever comes first. A new CRL must be published immediately after its issuance. This CP/CPS will be published whenever it is updated. 2.4 ACCESS CONTROL ON REPOSITORIES The online repository is maintained on a best effort basis and is available substantially on 24 hours per day, 7 days per week basis, subject to reasonable scheduled maintenance. Outside the period 08:30-16:30 (local time - GMT) Monday-Friday it may run unattended. The MaGrid CA does not impose any access control on its CP/CPS, its certificate, issued Certificates or CRLs. 3 IDENTIFICATION AND AUTHENTICATION 3.1 NAMING 3.1.1 Types of names The subject names for the certificate applicants shall follow the X.500 standard: 1. in the case of user certificates the subject name must include the person's name in the CN field; 2. in the case of host certificates the subject name must include the DNS FQDN in the CN field; 3. in the case of service certificates the subject name must include the service name and the DNS FQDN separated by a '/' in the CN field. Any name under this CP/CPS is in the form of "C=MA, O=MaGrid, OU=string". The following part is the "CN" which is distinguished for each person, each host or each service. Illustration of a full subject distinguished name for a user: C=MA, O=MaGrid, OU= CNRST, CN= Nabil Talhaoui (Name Surname) Illustration of a full subject distinguished name for a host: C=MA, O=MaGrid, OU= CNRST, CN=serv1.cnrst.ma Illustration of a full subject distinguished name for a service: C=MA, O=MaGrid, OU= CNRST, CN=ldap/serv1.cnrst.ma The common names must be encoded as Printable Strings according with RFC 1778 [RFC1778] and RFC 2252 [RFC2252]. The characters allowed in the common names of personal certificates are as follows: 1. ' ' (space), '(', ')' and '-'; 2. '0' - '9'; 3. 'a' - 'z' and 'A' - 'Z'. In addition, the characters '.' (period) and '/' (slash) are allowed in host and service certificates. The period must be used to separate the DNS host name components and the slash must be used to separate the service name or the keyword "host" from the DNS host name. 3.1.2 Need for names to be meaningful The Subject Name in a certificate must have a reasonable association with the authenticated name of the subscriber. Subscribers must choose a representation of their names in the permitted character set (see 3.1.1). The name must not refer to a role. Subscribers can neither be anonymous nor pseudonymous. 3.1.3 Anonymity or pseudonimity of subscribers No natural person certificates shall be issued to roles or functions, only to named and identified persons. 3.1.4 Rules for interpreting various name forms See section 3.1.1. 3.1.5 Uniqueness of names The Distinguished Name must be unique for each end entity certified by the MaGrid CA service. The MaGrid checks uniqueness before approving the request. In this policy two names are considered identical if they differ only in case. In other words, case must not be used to distinguish names. If necessary, additional numbers or letters are appended to the common name to guarantee the uniqueness of the subject name. Name uniqueness is preserved for the lifetime of the CA Certificates must apply to unique individuals or resources. Subscribers must not share certificates. 3.1.6 Recognition, authentication and role of trademarks No stipulation. 3.2 INITIAL IDENTITY VALIDATION 3.2.1 Method to prove possession of private key The MaGrid CA verifies the possession of the private key relating to certificates requests by out-of-band, non-technical means at the time of authentication. When submitting a request to the CA, the subscriber types a PIN (a personal string known only to the subscriber). When the subscriber verifies his or her identity to the RA Operator, the operator can check the PIN to ensure that the request he or she is about to approve was the one made by the subscriber. Only one way hashes of the PINs are processed by the CA and seen by the RA Operator (unless the subscriber chooses to reveal it to the RA Operator). The MaGrid CA will not generate the key pair for subscribers and will not accept or retain private keys generated by subscribers. 3.2.2 Authentication of organization identity " If an organization wishes to establish an RA they must contact the CA. The CA verifies the eligibility of the organization. " An organization/unit that wants to get a certificate for a natural person, a server or a service, has to announce this officially to the appropriate RA. The RA has to ascertain that the organization or organizational unit exists and is entitled (see 1.3.3) to request a MaGrid certificate. 3.2.3 Authentication of individual identity In order to enable the RA to authenticate the individual's identity the latter must meet in person with the RA (face to face) and present an officially recognized document proving the requesting party's identity. Only documents accepted by Moroccan law (Moroccan national identity card, driving license or passport) will be accepted. For each authentication, the RA will record and archive: " The type, identification number and name in the identification document presented by the subject to be authenticated; " A contact e-mail, phone number and address of the requester; " The identification of the person that has performed the authentication; " The date, time and place of the authentication; For host or service certificates, the requests must be signed with a MaGrid CA issued personal certificate corresponding to the system administrator or person responsible of the resource. The RA corresponding to the organization mentioned in the certificate request distinguish name will verify whether the requester has the right to request a certificate for the intended host or service and that the FQDN has been registered in the Internet's DNS. The RA shall send in a signed e-mail to the MaGrid CA, an electronic copy of the recorded authentication documentation and the certificate request. The information will be stored in a secure database at the CA site and shall be considered private and confidential (see 9.4). 3.2.4 Non-verified subscriber information No stipulation. 3.2.5 Validation of Authority Any organization or unit willing to host an RA for MaGrid certificates shall appoint one or more representatives who are entitled to request server or service/application certificates and answer all questions related to natural-person certificate requests. These representatives shall be the first in their organization/unit to request individual certificates according to the provisions outlined in 3.2.3. The signatures of these individuals with the private key associated with the certified public key shall be sufficient for all future information exchanges with or requests from that organization/unit. When the organization/unit rescinds the individual's authorization it has to inform the RA and the MaGrid CA in the same way as it has made the authorization known. 3.2.6 Criteria of interoperation No stipulation. 3.3 IDENTIFICATION AND AUTHENTICATION FOR RE-KEY REQUESTS 3.3.1 Identification and authentication for routine re-key Re-key before the certificate expires can be done using a secure web interface or by sending a re-key request based on a new public key in an e-mail signed with old private key to the appropriate RA of the MaGrid CA. After expiration of the certificate no re-key is possible; a new application for initial registration must be made instead. 3.3.2 Identification and authentication for re-key after revocation After revocation of a key, no re-key is possible. A new application for initial registration must be made. 3.4 IDENTIFICATION AND AUTHENTICATION FOR REVOCATION REQUEST Unless the revocation request originates from the MaGrid CA because it has independently verified that a key compromise has occurred, the revocation request has to be verified and the requesting party has to be authenticated. Such a request coming from an RA must be made in a signed transfer sent to the CA. Before revoking a certificate the MaGrid CA has to authenticate the source of the request as it did for the request for certification. In case of emergency the revocation can be initiated via oral communication with the appropriate RA or the MaGrid CA. The RA or the MaGrid CA have to use their best effort to authenticate the request. 4 CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS 4.1 CERTIFICATE APPLICATION 4.1.1 Who can submit a certificate application The MaGrid CA issues certificates to subscribers from eligible organizations (see 1.3.3) for: " natural persons, " hosts administered by the requesting organization: o hosts belonging to the member organization o hosts under the member organization responsibility " services provided on a host that is administered by an eligible organization. 4.1.2 Enrollment process and responsibilities The requesting party generates the key pair with a size of at least 1024 bit on their system through the form provided at the MaGrid CA web site. After the form has been completed the encrypted private key will be stored on the system where the browser runs, in a file only accessible to the requester (if the operating system allows such a restriction). 4.2 CERTIFICATE APPLICATION PROCESSING 4.2.1 Performing identification and authentication functions For the natural persons the RA operator must authenticate the individual's identity (see 3.2.3). In the case of a server/service request it must also check that the user is a representative (see 3.2.5) of the organization or unit responsible for the host 4.2.2 Approval or rejection of certificate applications Upon successful authentication, an electronic copy (signed by the RA) of the certification request shall be sent to the MaGrid CA. Alternatively, a secure transmission to the MaGrid CA may be used, if it is at least as secure as a signed e-mail. The necessary provisions that must be followed in any certificate application request to the MaGrid CA are in order to be approved: 1. the certificate request must be submitted by the user via an online procedure. 2. the certificate application must be authenticated by the RA as described in section 4.2.1; 3. the subject must be an acceptable subscriber entity, as defined by this Policy; 4. the request must obey the MaGrid CA distinguished name scheme; 5. the distinguished name must be unambiguous and unique; 6. the key must have at least 1024 bits. If the certificate request does not meet one or more of the above criteria, it will be rejected and signed notification e-mail will be sent by the RA to the subject with carbon copy to magrid-ra@magrid.ma 4.2.3 Time to process certificate applications Each certificate application will take no more than 3 working days to be processed. 4.3 CERTIFICATE ISSUANCE 4.3.1 CA actions during certificate issuance The CSR shall be transfered to the computer which holds the private key of MaGrid CA and which is not connected to any network. On this system the certificate is created and signed. The signed certificate shall then be transfered back to the MaGrid online server. 4.3.2 Notification to subscriber by the CA of issuance of certificate The MaGrid system shall then send a mail to the requesting party with the URL of the certificate download page. It shall also send an acknowledgment of the issuance to the appropriate RA. 4.4 CERTIFICATE ACCEPTANCE 4.4.1 Conduct constituting certificate acceptance The requesting party shall notify the MaGrid CA of the rejection of a certificate, explaining the MaGrid CA and the RA the reasons for the rejection. Certificates whose rejection have not been received by the MaGrid CA within a week shall be considered accepted. 4.4.2 Publication of the certificate by the CA The MaGrid CA will publish on its web server certificates as soon as they are issued. 4.4.3 Notification of certificate issuance by the CA to other entities The RA that has handled communication with the subscriber will be notified of the certificate issuance. 4.5 KEY PAIR AND CERTIFICATE USAGE 4.5.1 Subscriber private key and certificate usage Certificates issued by the MaGrid CA and their associated private keys must only be used according to the permissions and prohibitions stated in section 1.4. They must only be used according to the key usage fields of the certificate. When a certificate is revoked or has expired the associated private key shall not be used anymore. 4.5.2 Relying party public key and certificate usage A relying party must, upon being presented with a certificate issued by the MaGrid CA check " its validity by o verifying that the certificate is issued by MaGrid CA , o checking that the certificate hasn't expired, o consulting the MaGrid CA CRL in effect at the time of use of the certificate. " that the intended use of the certificate is appropriate as indicated by the key usage fields in the certificate and as specified in the CP pointed to by the certificate. 4.6 CERTIFICATE RENEWAL 4.6.1 Circumstance for certificate renewal MaGrid CA will not renew subscribers certificate. Subscribers must follow the re-key procedure as defined in section 4.7. 4.6.2 Who may request renewal See section 4.6.1. 4.6.3 Processing certificate renewal requests See section 4.6.1. 4.6.4 Notification of new certificate issuance to subscriber See section 4.6.1. 4.6.5 Conduct constituting acceptance of a renewal certificate See section 4.6.1. 4.6.6 Publication of the renewal certificate by the CA See section 4.6.1. 4.6.7 Notification of certificate issuance by the CA to other entities See section 4.6.1. 4.7 CERTIFICATE RE-KEY 4.7.1 Circumstance for certificate re-key For security reasons, the certificate re-key is the preferred method for issuing a new certificate to a subscriber whose certificate is about to expire or who require a change in the certificate's parameters. The MaGrid CA does not perform a re-key of a certificate after its revocation. A new certificate must be requested and the procedure for obtaining a new certificate must be followed. 4.7.2 Who may request certification of a new public key Same as in section 4.1.1 4.7.3 Processing certificate re-keying requests Expiration warnings will be issued to subscribers 30 days before re-key time arrives. Re-key before expiration can be accomplished using a secure web interface or by sending a re-key request signed with the current user certificate (see 3.3.1). Re-key after expiration follows the same authentication procedure as for a new certificate. At least once every 5 years the subscriber must go through the same authentication procedure as the one described for a new certificate. In case the request for a new certificate is due to revocation or compromise of certificate the subscriber must follow the same procedure as the one described in for a new one. 4.7.4 Notification of new certificate issuance to subscriber Same as in section 4.3.2 4.7.5 Conduct constituting acceptance of a re-keyed certificate Same as in section 4.4.1 4.7.6 Publication of the re-keyed certificate by the CA Same as in section 4.4.2 4.7.7 Notification of certificate issuance by the CA to other entities Same as in section 4.4.3 4.8 CERTIFICATE MODIFICATION 4.8.1 Circumstance for certificate modification Certificates must not be modified. The old certificate must be revoked, and a new key pair must be generated and a request for the modified certificate contents must be submitted with the new public key. 4.8.2 Who may request certificate modification Not applicable. 4.8.3 Processing certificate modification requests Not applicable. 4.8.4 Notification of new certificate issuance to subscriber Not applicable. 4.8.5 Conduct constituting acceptance of modified certificate Not applicable. 4.8.6 Publication of the modified certificate by the CA Not applicable. 4.8.7 Notification of certificate issuance by the CA to other entities Not applicable. 4.9 CERTIFICATE REVOCATION AND SUSPENSION 4.9.1 Circumstances for revocation A certificate will be revoked in the following circumstances: 1. the subject of the certificate has ceased being an eligible end entity for certification, as described in this policy; 2. the subject does not require the certificate any more; 3. the private key has been lost or compromised; 4. the information in the certificate is wrong or inaccurate; 5. the system to which the certificate has been issued has been retired; 6. the subject has failed to comply with the rules of this policy. 4.9.2 Who can request revocation A certificate revocation can be requested by 1. the owner of the certified key 2. the MaGrid CA or any RA that has proof of a compromise 3. the organization that wants to revoke its consent to its inclusion in the certificate 4. the Registration Authority which authenticated the holder of the certificate; 5. the holder of the private key; 6. any person presenting proof that the any one of the circumstances in section 4.9.1 is fulfilled. 4.9.3 Procedure for revocation request Unless the MaGrid CA acts on its own a revocation request must be made by: 1. the owner of the certificate, properly authenticated, using the online revocation facilities. In case of emergency (key compromise), the owner of the certificate must go to the RA as soon as possible and ask the appropriate RA to request revocation. Or, 2. the RA administrator using a secure web interface 4.9.4 Revocation request grace period There is no grace period defined for a revocation request. The MaGrid CA shall process the authenticated request with priority and publish the revocation as fast as possible. 4.9.5 Time within which CA must process the revocation request The MaGrid CA must process all revocation requests without delay within 1 working day. 4.9.6 Revocation checking requirement for relying parties Before using a certificate the relying party must validate it against the CRL most recently published in the MaGrid CA repository. 4.9.7 CRL issuance frequency A new CRL is published in the on-line repository after every certificate revocation and at least 7 days before the expiration of the current CRL. 4.9.8 Maximum latency for CRLs The CRL shall be copied to a removable device immediately after creation on the offline CA system and transfered without delay to the on-line repository. 4.9.9 On-line revocation/status checking availability No stipulation. 4.9.10 On-line revocation checking requirements No stipulation. 4.9.11 Other forms of revocation advertisements available No stipulation. 4.9.12 Special requirements re-key compromise No stipulation. 4.9.13 Circumstances for suspension MaGrid CA does not suspend certificates. 4.9.14 Who can request suspension See section 4.9.13. 4.9.15 Procedure for suspension request See section 4.9.13. 4.9.16 Limits on suspension period See section 4.9.13. 4.10 CERTIFICATE STATUS SERVICES 4.10.1 Operational characteristics See section 2.2. 4.10.2 Service availability The on-line repository is maintained on best effort basis with intended availability of 24x7. 4.10.3 Optional features No stipulation. 4.11 END OF SUBSCRIPTION The subscription ends with the expiry of the certificate if it is not renewed before that date. A subscription may end earlier if the subscriber requests a revocation of its certificate. 4.12 KEY ESCROW AND RECOVERY 4.12.1 Key escrow and recovery policy and practices No key escrow or recovery services are provided. The key owner must take all steps to prevent a loss. 4.12.2 Session key encapsulation and recovery policy and practices See Section 4.12.1. 5 FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS 5.1 PHYSICAL CONTROLS The MaGrid CA is located at the MARWAN/MaGrid Department of the CNRST in Rabat. The MaGrid CA is offline at all times and in a safe when not in use. CNRST maintains a limited access procedure to the system. All accesses to the server are limited to the MaGrid/Marwan staff. The MaGrid CA is run on Linux system (Fedora Core). 5.1.1 Site location and construction The MaGrid CA is located at the following address: CNRST 52, Av Omar Ibn AlKhattab BP 8027.Agdal -10102 Rabat Morocco 5.1.2 Physical access The CA operates in a controlled environment, where access is restricted to authorized people and logged. The machine hosting the CA (also known as the signing machine) and the private key are kept locked in a safe when not used.. 5.1.3 Power and air conditioning The online machine operates in an air conditioned environment and is not rebooted or power-cycled except for essential maintenance. The signing machine is switched off between signing operations and operates in an air conditioned environment. The MaGrid CA signing machine and the online machine are both protected by uninterruptible power supplies 5.1.4 Water exposures Due to the location of the MaGrid CA facilities, floods are not expected. 5.1.5 Fire prevention and protection MaGrid CA facilities adhere to the Moroccan law regarding fire prevention and protection in public buildings. 5.1.6 Media storage Several copies of the MaGrid CA private key are kept on removable storage media of different types (floppy, flash and CD-ROM) in secure location. 5.1.7 Waste disposal Waste containing data to be protected (cryptographically relevant data like private keys or passphrases, or personal data) shall be disposed off in a way to guarantee that the information may not be re-used. 5.1.8 Off-site backup No off-site backups are currently performed. 5.2 PROCEDURAL CONTROLS 5.2.1 Trusted roles All employees, contractors, and consultants of the MaGrid CA (collectively "personnel") that have access to or control over cryptographic operations that may materially affect the CA's issuance, use, suspension, or revocation of certificates, including access to restricted operations of the CA's repository, shall, for purposes of this Policy, be considered as serving in a trusted role. Such personnel include, but are not limited to, system administration personnel, operators, engineering personnel, and executives who are designated to oversee the CA's operations. 5.2.2 Number of persons required per task One person per task. 5.2.3 Identification and authentication for each role No stipulations. 5.2.4 Roles requiring separation of duties No stipulations. 5.3 PERSONNEL CONTROLS 5.3.1 Qualifications, experience, and clearance requirements All MaGrid CA personnel must be suitably trained persons who are familiar with the PKI infrastructure and operation, and who possess the relevant technical and professional competence. 5.3.2 Background check procedures " All access to the servers and applications that comprise the MaGrid service is limited to MARWAN/MaGrid staff. " The RA Manager must be an employee of the Physical Organization hosting that Registration Authority and must be appointed by an Authority responsible for a Department within that physical organization. The RA Manager has to be a member of that Department. The Registration Authority will make a declaration to the CA Manager in writing on the organization's headed note paper. The information that must be contained in this letter is defined by the CA Manager. " The RA Operator must be an employee of the site hosting that Registration Authority and will be appointed by the RA Manager concerned. The RA Manager will make a declaration to the CA Manager in writing on the organization's headed note paper. If the RA Operator is appointed in a different department from the RA Manager then the letter must be countersigned by an authority for the department in which the Operator is appointed. The information that must be contained in this letter is defined by the CA Manager. RA Operators must have certificates and must adhere also to the subscriber's obligations. " An RA Manager may appoint himself/herself as an RA Operator. " An RA Manager may appoint any number of RA Operators. 5.3.3 Training requirements Internal training is given to MaGrid CA/RA operators 5.3.4 Retraining frequency and requirements Retraining shall be mandatory when new software or features, as well as new organizational procedures are introduced. 5.3.5 Job rotation frequency and sequence No stipulation. 5.3.6 Sanctions for unauthorized actions In the event of unauthorized actions, abuse of authority or unauthorized use of entity systems by the CA or RA Operators, the CA manager may revoke the privileges concerned. The MaGrid CA also reserves the right to prosecute unauthorized actions to the fullest extent under the legal provisions of the appropriate organization and Moroccan law. 5.3.7 Independent contractor requirements No stipulation. 5.3.8 Documentation supplied to personnel All MaGrid CA personnel shall be provided with all documentation required for successfully performing their task. " It is the responsibility of the CA Manager to provide the CA Operators with a copy of the "MaGrid CA Operator's Procedure". " It is the responsibility of the CA Manager to provide the RA Manager with a copy of the "MaGrid RA Manager's Procedure". " It is the responsibility of the RA Manager to provide the RA Operator with a copy of the "MaGrid RA Operator's Procedure" 5.4 AUDIT LOGGING PROCEDURES 5.4.1 Types of events recorded The following events shall be recorded: " MaGrid CA host o login / logout / reboot o issued signed certificates o creation and signing of certificates o revocation of certificates o CRL issues o audit log events " MaGrid web online server o login / logout / reboot o receipt of certificate request o issued certificates o receipt of certificate revocation request o validation of certificate request from online server o export of CSRs from online server o revocation of certificate o deleted certificate request o CRL issues o implemented versions of the CP/CPS documents. 5.4.2 Frequency of processing log The log files shall be analyzed once a month, or after a potential security breach is suspected or known; whichever comes first. 5.4.3 Retention period for audit log The minimal retention period for the audit logs is 3 years. 5.4.4 Protection of audit log The audit logs shall only be accessible to the MaGrid CA operators and managers. The protection shall be state-of-the-art best effort. 5.4.5 Audit log backup procedures The audit logs shall be backed-up on a removable medium every night except on weekends and holidays when no activity happens on the offline host and only read access to the online repositories happens on the online server. 5.4.6 Audit collection system (internal vs. external) The audit log accumulation system is internal to the MaGrid CA. 5.4.7 Notification to event-causing subject Not defined 5.4.8 Vulnerability assessments Not defined 5.5 RECORDS ARCHIVAL 5.5.1 Types of records archived Following data will be recorded: " all events defined in section 5.4.1. " identity validation records which RA collects, defined in section 3.2.3. 5.5.2 Retention period for archive The minimum retention period is 3 years. 5.5.3 Protection of archive The archive shall only be accessible to the MaGrid CA operation, to management personnel and to authorized external auditors (see Section 8.3) 5.5.4 Archive backup procedures Records shall be backed up on removable media, which shall be stored in a room with restricted access. 5.5.5 Requirements for time-stamping of records All event records shall bear a time-stamp. 5.5.6 Archive collection system (internal or external) The archive collection system is internal to the MaGrid CA. 5.5.7 Procedures to obtain and verify archive information All certificate data published by MaGrid CA are publicly available. Data used for the registration and identification of subscribers are for internal use only. The integrity of MaGrid CA archives is verified: " at the time the archive is prepared " at the time of a programmed security audit " at any other time when a full security audit is required. 5.6 KEY CHANGEOVER In the case of a changeover of the MaGrid CA's key pair, an overlap of the old and new keys will exist. While the new key will be used for signing certificate, the older but still valid certificate must be available to verify old digital signatures - and the private key to sign CRLs - until all the certificates signed using the associated private key have also expired. The overlap of the old and new key must therefore be at least as long as the validity of an end entity certificate (see 6.3.2). 5.7 COMPROMISE AND DISASTER RECOVERY 5.7.1 Incident and compromise handling procedures If the private key of an end entity is lost or compromised due to corruption, the end entity must inform their RA immediately in order to request the revocation of their certificate. All relying parties known to accept the key should be informed by the owner of the key. If the private key of the MaGrid CA is (or is suspected to be) compromised, the CA Manager must: " make every reasonable effort to notify subscribers and RAs; " terminate the issuing and distribution of certificates and CRLs; " request revocation of the compromised certificate; " generate a new CA key pair and certificate and publish the certificate in the repository; " revoke all of the valid certificates that have been previously signed by the compromised key; " publish the new CRL on the MaGrid CA repository; " Notify relevant security contacts; and " Notify relying parties and cross-certifying CAs, of which the CA is aware, as widely as possible. 5.7.2 Computing resources, software, and/or data are corrupted The CA will take best effort precautions to enable recovery. In order to be able to resume operation as fast as possible after the compute basis of the CA is corrupted, the following steps shall be performed: " All CA software shall be backed-up on removable media after a new release of any of its components is installed. " All data files of the offline CA shall be backed-up on a removable medium after each change, before the session is closed. If the hardware or software of the signing machine becomes corrupt, the status shall be diagnosed and suitably repaired. If there is any doubt about the extent of the damage involved, this shall imply rebuilding the machine from scratch, using original supplied parts and software distributions. If data become corrupted, the cause shall be diagnosed and the data restored from the latest back-up. 5.7.3 Entity private key compromise procedures In case the key of an end entity or an RA is compromised, the corresponding certificate must be revoked. All relying parties known to accept the key should be informed by the owner of the key. 5.7.4 Business continuity capabilities after a disaster The MaGrid CA is located inside a building that is part of governmental facilities for research and higher education. The plans for business continuity and disaster recovery for governmental activities related to research and education are applicable. 5.8 CA OR RA TERMINATION Before MaGrid CA terminates its services, it will: " Inform the Registration Authorities, subscribers and relying parties the CA is aware; " Inform the EUGridPMA; " Make information of its termination widely available; " Stop issuing certificates " Revoke all certificates " Issue an publish CRL " Destroy its private keys and all copies An advance notice of no less than 60 days will be given in the case of normal (scheduled) termination. The CA Manager at the time of termination shall be responsible for the subsequent archival of all records as required in section 5.5.2. The CA Manager may decide to let the CA issue CRLs only during the last year (i.e. the maximal lifetime of a subscriber certificate) before the actual termination; this will allow subscribers' certificates to be used until they expire. In that case notice of termination is given no less than one year and 60 days prior to the actual termination, i.e. no less than 60 days before the CA ceases to issue new certificates. 6 TECHNICAL SECURITY CONTROLS 6.1 KEY PAIR GENERATION AND INSTALLATION 6.1.1 Key pair generation The key pair for the MaGrid CA is generated by authorized CA staff on a computer which is not connected to the network. The keys are generated by software using OpenSSL. The key pairs for natural-person (including RA agents), host or service certificates are generated by the requesting parties themselves on their system (web interface). 6.1.2 Private key delivery to subscriber Each subscriber must generate his/her own key pair using the MaGrid CA web interface. The CA does not generate private keys for its subscribers. 6.1.3 Public key delivery to certificate issuer Subscribers public keys are delivered to the issuing CA by the SSL protected HTTP protocol via the MaGrid CA web interface. 6.1.4 CA public key delivery to relying parties The CA certificate (containing its public key) is delivered to subscribers by online transaction from the MaGrid CA online web server. It can be downloaded from the repository (see 2.1). 6.1.5 Key sizes RSA Keys with a modulus of less than 1024 bits are not accepted. The MaGrid CA key is of length 2048 bits. 6.1.6 Public key parameters generation and quality checking Not defined. 6.1.7 Key usage purposes (as per X.509 v3 key usage field) The keys may be used according to the type of certificate: " With an end-entity certificate for o authentication o key encipherment o message integrity o session establishment " With the self-signed CA certificate o certificate signing o CRL signing o Certificate revocation The CA's private key is the only key that can be used for signing certificates and CRLs. 6.2 PRIVATE KEY PROTECTION AND CRYPTOGRAPHIC MODULE ENGINEERING CONTROLS 6.2.1 Cryptographic module standards and controls No stipulation. 6.2.2 Private key (n out of m) multi-person control No stipulation. 6.2.3 Private key escrow Private keys must not be escrowed. 6.2.4 Private key backup An extra instance of the private key encrypted with a randomly generated passphrase of at least 15 characters shall be stored on removable media which must be deposited in a safe and locked up place; the passphrase shall be stored on a different removable media or written down, and the media or paper shall be placed in a sealed envelop and stored in a secure place. No instance of the private CA key (plain or encrypted) shall reside on the permanent disc of any computer that is online. 6.2.5 Private key archival No stipulation. 6.2.6 Private key transfer into or from a cryptographic module No stipulation. 6.2.7 Private key storage on cryptographic module No stipulation. 6.2.8 Method of activating private key The CA private key is activated by providing the passphrase. 6.2.9 Method of deactivating private key The plain private key shall only be stored in RAM and erased when the activity for which it is needed is finished and the signing machine is powered down. 6.2.10 Method of destroying private key After termination of the CA, all media that contain the private key of the CA will be securely and permanently destroyed, according to the best current practice. 6.2.11 Cryptographic Module Rating No stipulation. 6.3 OTHER ASPECTS OF KEY PAIR MANAGEMENT 6.3.1 Public key archival The CA archives all issued certificates on removable media that is stored offline in a secure vault. 6.3.2 Certificate operational periods and key pair usage periods The validity of the certificate issued by the MaGrid CA is defined by this CP/CPS document. Subscriber's certificates have a validity period of one year plus 30 days, or less if the affiliation of the requesting party to the group participating in MaGrid is less than one year. The CA certificate has a validity period of 10 years. 6.4 ACTIVATION DATA 6.4.1 Activation data generation and installation Each private key are protected by a strong passphrase consisting of at least 15 characters. 6.4.2 Activation data protection All MaGrid CA Operators know the activation data for the CA private key. No other person knows the activation data. However, activation data for the CA private key is also kept in a sealed envelope in a safe. Access to the safe is restricted only to the authorized personnel. For end entity certificates, the subscriber is responsible for protecting the activation data for the private key. 6.4.3 Other aspects of activation data Not defined. 6.5 COMPUTER SECURITY CONTROLS 6.5.1 Specific computer security technical requirements The server hosting the CA product is run on a Linux system (Fedora Core). No other services or software are loaded or operated on the CA server. The server will receive occasional patches and other adjustments if the security risk warrants, in the judgment of MARWAN/MaGrid staff. 6.5.2 Computer security rating Not defined. 6.6 LIFE CYCLE TECHNICAL CONTROLS 6.6.1 System development controls No stipulation. 6.6.2 Security management controls No stipulation. 6.6.3 Life cycle security controls No stipulation. 6.7 NETWORK SECURITY CONTROLS The signing machine will never be connected to a computer network under any circumstances. Certificates are generated on a machine not connected to any kind of network, located in a secure environment and managed by a suitably trained person. The public machine is protected by a suitably configured firewall. 6.8 TIME-STAMPING All time stamping of entries created on the online servers at the MaGrid CA is based on the network time provided by the time server of CNRST, synchronized with the official providers of time signals. The hardware clock of the offline system for the certificate and CRL signing, which determines the time stamping of the certificates and the CRLs, will be synchronized manually by the operator whenever the host starts. 7 CERTIFICATE, CRL, AND OCSP PROFILES 7.1 CERTIFICATE PROFILE All certificates issued by the MaGrid CA conform to the Internet PKI profile (PKIX) for X.509 certificates as defined by RFC 3280 [RFC3280]. 7.1.1 Version number(s) Only X.509 version 3 certificates are issued by the MaGrid CA. 7.1.2 Certificate extensions The extensions to the X.509 v3 certificate that shall be present in the MaGrid CA certificates are: For natural person certificates: " Basic Constraints: critical, ca: false " Subject Key Identifier: hash " Authority Key Identifier: keyid, DirName, serial " Key Usage: critical, digitalSignature, KeyEncipherment " Extended Key Usage clientAuth, emailProtection " Netscape Comment: STRING " CRL Distribution Points: URI " Certificate Policies: OID " Subject alternative name: Subscriber's E-mail address For servers/services certificates: " Basic Constraints: critical, ca: false " Subject Key Identifier: hash " Authority Key Identifier: keyid, DirName, serial " Key Usage: critical, digitalSignature, keyEncipherment " Extended Key Usage serverAuth, clientAuth " Netscape Comment: STRING " CRL Distribution Points: URI " Certificate Policies: OID " Subject alternative name: Server's DNS FQDN host name For CA certificate: " Basic Constraints: critical, ca: true " Subject Key Identifier: hash " Authority Key Identifier: keyid, DirName, serial " Key Usage: critical, KeyCertSign, cRLSign " Netscape Cert Type: SSL Certification authority, Email CA, Authority Object Signing " Netscape Comment: STRING " Netscape CA Revocation Url: URL " Netscape CA Policy Url: URL " CRL Distribution Points: URI 7.1.3 Algorithm object identifiers The OIDs for algorithms used for signatures of certificates issued by the MaGrid CA are according to: a) hash function: id-sha 1 1.3.14.3.2.26 b) encryption: rsaEncryption 1.2.840.113549.1.1.1 c) signature: sha1WithRSAEncryption 1.2.840.113549.1.1.5 7.1.4 Name forms Each entity has a unique and unambiguous Distinguished Name (DN) in all the certificates issued to the same entity by the MaGrid CA. The DN of the CA is "C=MA, O=MaGrid, CN=MaGrid CA". For the name forms of subscriber certificates the DN will be of the form defined in section 3.1.1. 7.1.5 Name constraints There are no other name constraints than those that are to be derived from the stipulations in 7.1.4, 3.1.2 and 3.1.1. 7.1.6 Certificate policy object identifier MaGrid CA identifies this policy with the object identifier (O.I.D) specified in section 1.2. 7.1.7 Usage of Policy Constraints extension No stipulation. 7.1.8 Policy qualifiers syntax and semantics No stipulation. 7.1.9 Processing semantics for the critical Certificate Policies extension No stipulation. 7.2 CRL PROFILE 7.2.1 Version number(s) The MaGrid CA creates and publish X.509 v2 CRLs. 7.2.2 CRL and CRL entry extensions The MaGrid CA shall issue complete CRLs for all certificates issued by itself independently of the reason for the revocation. The reason for the revocation shall not be included in the individual CRL entries. The CRL shall include the date by which the next CRL shall be issued. A new CRL shall be issued before this date if new revocations are issued. The CRL extensions that shall be included are: " The Authority Key Identifier " The CRL Number The CRL entry extensions that will be included are: " CRL Reason Code " Invalidity Date 7.3 OCSP PROFILE No stipulation. 7.3.1 Version number(s) No stipulation. 7.3.2 OCSP extensions No stipulation. 8 COMPLIANCE AUDIT AND OTHER ASSESSMENTS 8.1 FREQUENCY OR CIRCUMSTANCES OF ASSESSMENT The MaGrid CA shall make at least once a year a self-assessment to check the compliance of the operation with the CP/CPS document in effect. The CA shall at least once a year assess the compliance of the procedures of each RA with the CP/CPS document in effect. The auditor, as his/her discretion, may ask to carry out an audit at anytime, in particular, in the event of (or suspicion of) malpractice by CA or RA personnel, security flaws or complaints from subscribers or relying parties. In addition,The MaGrid CA will accept at least one external compliance audit per year when requested by a Relying Party. The entire cost of such an audit must be borne by the requestor. 8.2 IDENTITY/QUALIFICATIONS OF ASSESSOR Not defined 8.3 ASSESSOR'S RELATIONSHIP TO ASSESSED ENTITY The assessments are made by personnel of the MaGrid CA or all eligible organizations of MaGrid. An external audit can be performed by any Moroccan government department or academic institution. Member organizations of the EuGridPMA may also undertake assessments if previously approved by EuGridPMA. If other trusted CAs or relying parties request an external assessment, the costs of the assessment must be paid by the requesting party, except for the costs of MaGrid CA's personnel and infrastructure. 8.4 TOPICS COVERED BY ASSESSMENT The audit will verify that the services provided by the CA comply with the latest approved version of the CP/CPS. 8.5 ACTIONS TAKEN AS A RESULT OF DEFICIENCY In case of a deficiency, the MaGrid CA Manager will announce the steps that will be taken to remedy the deficiency. This announcement will include a timetable. If a discovered deficiency has direct consequences on the reliability of the certification process, the certificates (suspected to be) issued under the influence of this problem shall be revoked immediately. 8.6 COMMUNICATION OF RESULTS The CA Manager will make the result publicly available on the CA web site with as many details of any deficiency as she/he considers necessary. 9 OTHER BUSINESS AND LEGAL MATTERS 9.1 FEES No fees are charged for the certification service for the CNRST constituency and therefore there are no financial encumbrances. 9.1.1 Certificate issuance or renewal fees See 9.1. 9.1.2 Certificate access fees See 9.1. 9.1.3 Revocation or status information access fees See 9.1. 9.1.4 Fees for other services No fees shall be charged. 9.1.5 Refund policy See 9.1. 9.2 FINANCIAL RESPONSIBILITY No Financial responsibility is accepted for certificates issued under this policy. 9.2.1 Insurance coverage No stipulation. 9.2.2 Other assets No stipulation. 9.2.3 Insurance or warranty coverage for end-entities No stipulation. 9.3 CONFIDENTIALITY OF BUSINESS INFORMATION 9.3.1 Scope of confidential information No stipulation. 9.3.2 Information not within the scope of confidential information No stipulation. 9.3.3 Responsibility to protect confidential information No stipulation. 9.4 PRIVACY OF PERSONAL INFORMATION The MaGrid CA service collects information about the subscribers. Information included in issued certificates and CRLs is not considered confidential. The MaGrid CA collects a subscriber's name, work telephone numbers and e-mail address. Additionally, for RA Managers and Operators, personal contact information is kept by the CA (work telephone number, work address). Under no circumstances will the MaGrid CA have access to the private keys of any subscriber to whom it issues a certificate. 9.4.1 Privacy plan No stipulation. 9.4.2 Information treated as private The information provided by the subscriber to verify his/her identity will be kept confidential. 9.4.3 Information not deemed private Information included in issued certificates and CRLs is not considered confidential. RA contact information is not considered confidential since this information is generally available from the web pages of the RA's employer. Statistics regarding certificates issuance and revocation don't contain any personal information and is not considered confidential. 9.4.4 Responsibility to protect private information The responsibility to protect private information rests with the MaGrid CA and all its accredited RAs. 9.4.5 Notice and consent to use private information If the MaGrid CA or any of its accredited RAs wants to use private information, it must ask the subscriber for a written consent. No subscriber shall be under the impression that he/she has an obligation to agree. 9.4.6 Disclosure pursuant to judicial or administrative process The CA will not disclose confidential information to any third party unless authorized to do so by the subscriber or when required by law enforcement officials who exhibit regular warrant. 9.4.7 Other information disclosure circumstances Disclosure upon owner's request is done according to the Data Protection Law. Specifically, information is released to the subscriber if the CA has received a signed e-mail from the subscriber requesting the information. The CA charges no fee for this. The CA will recognize requests in writing for the release of personal information from a subscriber provided the subscriber can be properly authenticated 9.5 INTELLECTUAL PROPERTY RIGHTS The MaGrid CA does not claim any intellectual property rights on certificates which it has issued. This document is based on the following sources: " RFC 3647 [RFC3647] and RFC 2527 [RFC2527] Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework; " RFC 1778 [RFC1778] The String Representation of Standard Attribute Syntaxes; Parts in this document are inspired or even copied (in no particular order) from the: " pkIRISGrid CA [ESCPCPS] " SeeGrid CA [SEECPCPS] " SRCE CA [CRCPCPS] " TR-Grid CA [TRCPCPS] " UFF BrGrid CA [BRCPCPS] " UK e-Science CA [UKCPCPS] and indirectly from the documents on which they are based. Anybody may freely copy from any version of the MaGrid CA's Certificate Policy and Certification Practices Statement provided they include an acknowledgment of the source. 9.6 REPRESENTATIONS AND WARRANTIES 9.6.1 CA representations and warranties The MaGrid CA guarantees to issue certificates only to subscribers identified by requests received from RAs via secure routes. The MaGrid CA will revoke a certificate only in response to an authenticated request from the subscriber, or the RA which approved the subscriber's request, or if it has itself reasonable proof that circumstances for revocation are fulfilled. The MaGrid CA does not takes responsibility for problems arising from its operation or the use made of the certificates it provides and gives no guarantees about the security or suitability of the service. The CA only guarantees to verify subscribers' identities according to procedures described in this document. 9.6.2 RA representations and warranties All accredited RAs shall perform their task of identification of the requesting parties as described in 3.2.3 and 3.2.2 to the best of their knowledge. No other warranties are accepted. An RA can conclude, at its strictly own risk, a more stringent agreement with its subscribers, but this shall never commit the MaGrid CA nor any of its other accredited RAs. It is the RA's responsibility to request revocation of a certificate if the RA is aware that circumstances for revocation are satisfied. 9.6.3 Subscriber representations and warranties By requesting a MaGrid CA certificate a subscriber commits itself to use and protect the certificate and the certified keys according to the stipulations of the CP/CPS document in effect at the date of issuance of the said certificate. She/he may however apply more stringent observances. subscribers must: " Read and adhere to the procedures published in this document " Use the certificate for the permitted purposes only " Authorize the processing and conservation of personal data (as required under the Data Protection Law) " Take every precaution to prevent any loss, disclosure or unauthorized access to or use of the private key associated with the certificate, including: o (Personal certificates) selecting a strong passphrase of at least 15 characters; o (Personal certificates) protecting the passphrase from others; o Notifying immediately the MaGrid CA and any relying parties if the private key is lost or compromised; o Requesting revocation if the subscriber is no longer entitled to a certificate, or if information in the certificate becomes wrong or inaccurate. In case of a breach of stipulations of the CP/CPS document that the subscriber has agreed to by requesting the MaGrid CA certificate the certificate shall be revoked immediately. No further warranties are required from the subscriber. 9.6.4 Relying party representations and warranties A relying party must accept the subscriber's certificate for authentication purposes if: " The relying party must check the MaGrid CA's CP and the CPS under which the certificate was issued before drawing any conclusion on trust of the subscriber's certificate; and " The reliance is reasonable and in good faith in light of all circumstances known to the relying party at the time of reliance; and " The certificate is used for permitted purposes only; and " The relying party checked the validity and status of the certificate to their own satisfaction prior to reliance. 9.6.5 Representations and warranties of other participants No stipulation. 9.7 DISCLAIMERS OF WARRANTIES The MaGrid CA uses software and procedures for the authentication of entities that, to the best of its knowledge, perform as required by this CP/CPS document. However it declines any warranty as to their full correctness. Also the MaGrid CA cannot be held responsible for any misuse of its certificate by a subscriber or any other party who got in possession of the corresponding private key, and of any unchecked acceptance of any of its certificates by a relying party. Any relying party that accepts a certificate for any usage for which it was not issued does so on its own risk and responsibility. 9.8 LIMITATIONS OF LIABILITY Except if explicitly dictated otherwise by the Moroccan law the MaGrid CA declines any liability for damages incurred by a relying party accepting one of its certificates, or by a subscriber whose valid certificate is refused or whose revoked certificate is unduly accepted by a relying party. It also declines any liability for damages arising from the non-issuance of a requested certificate, or for the revocation of a certificate initiated by the CA or the appropriate RA acting in conformance with this CP/CPS. The CA does not accept any liability for financial loss, or loss arising from incidental damage or impairment, resulting from its operation. No other liability, implicit or explicit, is accepted. 9.9 INDEMNITIES The MaGrid CA declines any payment of indemnities for damages arising from the use or rejection of certificates it issues. End entities shall indemnify and hold harmless the MaGrid CA and all appropriate RAs operating under this CP/CPS against all claims and settlements resulting from fraudulent information provided with the certificate application, and the use and acceptance of a certificate which violates the provisions of this CP/CPS document. 9.10 TERM AND TERMINATION 9.10.1 Term This document becomes effective after its publication on the Web site of the MaGrid CA starting at the date announced there. There is no term set for its expiration. 9.10.2 Termination This CP/CPS remains effective until it is superseded by a newer version. 9.10.3 Effect of termination and survival Its text shall remain available for at least 5 years after the last certificate issued under this CP/CPS expires or is revoked. 9.11 INDIVIDUAL NOTICES AND COMMUNICATIONS WITH PARTICIPANTS All e-mail communications between the CA and its accredited RAs must be signed with a certified key. All e-mail communications between the CA or an RA and a subscriber must be signed with a certified key in order to have the value of a proof. All requests for any action must be signed. 9.12 AMENDMENTS 9.12.1 Procedure for amendment Amendments to this CP/CPS must undergo the same procedures as for the initial approval (see 1.5.4). Rephrasing provisions to improve their understandability as well as pure spelling corrections are not considered amendments. 9.12.2 Notification mechanism and period The amended CP/CPS document shall be published on the MaGrid CA Web pages at least 2 weeks before becoming effective. The MaGrid CA will inform its subscribers and all relying parties it knows of by means of an e-mail. 9.12.3 Circumstances under which OID must be changed Substantial changes shall cause the OID to be changed. The decision is made by the manager of the MaGrid CA and submitted to the EUGridPMA for approval. 9.13 DISPUTE RESOLUTION PROVISIONS Disputes arising out of the CP/CPS shall be resolved by the Manager of the MaGrid CA. 9.14 GOVERNING LAW The MaGrid CA and its operation are subject to the Moroccan law. All legal disputes arising from the content of this CP/CPS document, the operation of the MaGrid CA and its accredited RAs, the use of their services, the acceptance and use of any certificate issued by MaGrid CA shall be treated according to Moroccan law. 9.15 COMPLIANCE WITH APPLICABLE LAW All activities relating to the request, issuance, use or acceptance of a MaGrid CA certificate have to comply with the Moroccan law. Activities initiated from or destined for another country than Morocco must also comply with that country's law 9.16 MISCELLANEOUS PROVISIONS 9.16.1 Entire agreement This CP/CPS document supersedes any prior agreements, written or oral, between the parties covered by this present document. 9.16.2 Assignment No provisions. 9.16.3 Severability Should a clause of the present CP/CPS document become void because it is conflicting with the governing law (see 9.14) or because it has been declared invalid or unenforceable by a court or other law-enforcing entity, this clause shall become void (and should be replaced as soon as possible by a conforming clause), but the remainder of this document shall remain in force. 9.16.4 Enforcement (attorneys' fees and waiver of rights) No stipulation. 9.16.5 Force Majeure In the case of Force Majeure the MaGrid CA will make its best effort to maintain the service in accordance with its policy and will invoke the disaster recovery procedures as appropriate. 9.17 OTHER PROVISIONS No stipulation. 10 REFERENCES [RFC3647] S. Chokani, W. Ford, R. Sabett, C. Merrill and S. Wu, " Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework" , RFC 3647, November 2003 [replaces RFC 2527] http://www.ietf.org/rfc/rfc3647.txt [RFC2527] S. Chokani and W. Ford, " Internet X.509 Infrastructure Certificate Policy andCertification Practices Framework" , RFC 2527, March 1999 http://www.ietf.org/rfc/rfc2527.txt [RFC3280] R. Housley, W. Polk, W. Ford and D. Solo, " Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" , RFC 3280, April 2002 http://www.ietf.org/rfc/rfc3280.txt [RFC2119] S. Bradner, " Key words for use in RFCs to Indicate Requirement Levels" RFC 2119, March 1997 http://www.ietf.org/rfc/rfc2119.txt [RFC1778] T. Howes, S. Kille, W. Yeong, C. Robbins , " The String Representation of Standard Attribute Syntaxes" RFC 1778, March 1995 http://www.ietf.org/rfc/rfc1778.txt [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, " Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions " RFC 2252, December 1997 http://www.ietf.org/rfc/rfc2252.txt [ESCPCPS] Certification Authority pkIRISGrid CA Certificate Policy (CP) and Certification Practices Statement (CPS), Version 1.1.1, February 2006 http://www.irisgrid.es/pki/policy/1.3.6.1.4.1.7547.2.2.4.1.1.1/pkIRISGridCA_CP_CPS_1_1_1.pdf [SEECPCPS] Certification Authority SeeGrid CA Certificate Policy (CP) and Certification Practices Statement (CPS), Version 1.1.1, September 2004 http://www.grid.auth.gr/pki/seegrid-ca/documents/cps/SeeGridCA-CPS-1.1.pdf [CRCPCPS] Certification Authority SRCE CA Certificate Policy (CP) and Certification Practices Statement (CPS), Version 1.0, May 2006 http://ra.srce.hr/policy.pdf [TRCPCPS] Certification Authority TR-Grid CA Certificate Policy (CP) and Certification Practices Statement (CPS), Version 1.1.0, June 2005 http://www.grid.org.tr/ca/policy/cpcps.pdf [BRCPCPS] Certification Authority UFF BrGrid CA Certificate Policy (CP) and Certification Practices Statement (CPS), Version 1.0, July 2006 https://brgridca.ic.uff.br//index.php?option=com_docman&task=doc_download&gid=1&Itemid=13 [UKCPCPS] UK e-Science Certification Authority Certificate Policy and Certification Practices Statement Version 1.3, 4 Aug 2006 http://www.grid-support.ac.uk/files/cps/cps-1.3.pdf 11 LIST OF CHANGES " January 10, 2007. Initial release CP/CPS Version 1.1.0 " April 2, 2007. CP/CPS Version 1.1.1 " May 26, 2007. CP/CPS Version 1.1.2 " May 31, 2007. CP/CPS Version 1.1.3 " July 09, 2007. CP/CPS Version 1.2.0