Your IP Address
Digital Certificate Policies Of IRAN’s Public Key Infrastructure (CP)

1          Introduction

Digital certificate policies of IRAN’s public key infrastructure include a collection of functionality and security criteria and requirements which govern the country’s public key infrastructure. Public key infrastructure (PKI) is a collection of services, policies, procedures and hardware/software systems, which are used to manage and apply X.509 digital certificates, and also to present different security services based on public key cryptography.
Secure electronic interactions in IRAN is in the context of electronic commerce law which was approved in the parliament in January 14, 2004, and also its executive regulation (for article No. 32) was approved in August 28, 2007 by cabinet. According to executive regulation (article no. 32) of e-commerce law, in order to perform digital signature over the country, a hierarchical model is approved as the architecture of PKI. This model includes: IRAN’s Digital Certificate Policy Council, Government Root Certificate Authority, as trust point, and the lower intermediate certificate authorities. The intermediate certificate authorities may be a collection of organizations or public/private companies. They being to present digital certificate services in the hierarchical model of PKI, after being approved by Government Root Certificate Authority and also obtaining permission from IRAN’s Digital Certificate Policy Council.
In the hierarchical model of IRAN’s PKI, Government Root Certificate Authority, is required to prepare digital certificate policies (CP) according to security and functionality requirements of the country in different domains; therefore this document contains digital certificate policies of country’s public key infrastructure, including the requirements and procedures of Government Root Certificate Authority, and also the required policies for trust making and providing integration and interoperation between different components of PKI.
The document of digital certificate policies of IRAN’s public key infrastructure is an integrated document which approved certificate authorities have to be established on its framework. All the mentioned conditions in this document are valid for different types of certificate authorities, unless the contrary is explicitly stated.
The programs which have the capability of presenting security services based on public key infrastructure provide services such as authentication, confidentially, integrity and non-repudiation, by using public key cryptography. The trusting strength of public key cryptography is the direct result of trusted performance of PKI, which will be obtained by secure designing and establishing of certificate authorities including equipment, installations, personnel and procedures. Secure operation of certificate authorities is dependent to existence of policies for digital certificate of trust point -that is Government Root Certificate Authority- in hierarchical model.
Therefore, designing a public key infrastructure with a suitable level of security is so essential for relying parties trusting in digital certificates. This trust means trust in the relation between subscriber and his public key.
Digital certificate policies of IRAN’s public key infrastructure are prepared according to X.509 standard and RFC3647[1].

1.1         Overview

 

This document includes the policies and procedures of Government Root Certificate Authority, and also policies and requirements of all the intermediate certificate authorities in hierarchical model of PKI. Also this document is applicable for subscribers, relying parties and registration authorities.
This document defines four certificate policies for issuance of digital certificates which will be used in IRAN’s public key infrastructure. These policies are defined in below assurance levels:
  • Level 1 (bronze)
  • Level 2 (silver)
  • Level 3 (gold)
  • Level 4 (platinum)
In the below table, the certificates which are issued under these policies and their function, are defined.
Table 1: types of certificates and considering assurance level
Assurance Level Certificate Name Function
Level 1 Bronze ·      This level provides the lowest assurance level to identity of subscriber.
·      One of the primary functions of level 1 is to provide security service or to ensure the integrity of signed data.
·      Using level 1 is not suitable for transactions which need authentication, but when identification of certificate applicants in an organization is independent of certificate authorities or registration authorities, using this certificate for authentication only in that organization is permitted.
·      Using this level for transactions which need confidentially (such as secure email) is not recommended, however when using higher level certificates is not possible, using this level is permitted.
·      This level must be used in environments in which the risk of abuse, forging and disclosure of information is low.
Level 2 Silver ·      This level must be used in environments in which the risk of abuse, forging and disclosure of information is in average level.
·      Considering article 1, the certificates of this level can be used for transactions which need authentication, confidentially or non-repudiation.
Level 3 Gold ·      This level must be used in environments in which the risk of abuse, forging and disclosure of information is high.
·      This level can be used for transactions which have considerable financial value, and in which the risk of abuse, forging and disclosure of information is high.
·      By considering article 1 and 2, the certificates of this level can be used for transactions which need authentication, confidentially, non-repudiation.
Level 4 Platinum ·      This level is used for the environments in which threats on information resources or damages resulting from deficiency or failure are very high.
·      This level can be used for transactions which have high financial value and in which the risk of abuse, forging and disclosure of information is very high.
·      Considering article 1 and 2, the certificates of his level can be used for transactions which need authentication, confidentially or non-repudiation.
 
 
Persons or organizations applicant for certificate, are responsible for choosing their needed assurance level, and according to sensitivity and importance of systems which are use digital certificates, they should request certificate appropriate with the suitable assurance level.
Certificate authorities are divided into 4 different classes according to the level of certificates that they can issue. A certificate authority can implement certificate policies for more than one assurance level; for example, a class 3 certificate authority can issue certificate for assurance levels 1, 2, and 3. In below table you can see available certificate levels for different classes of certificate authorities
Table 2: levels of intermediate certificate authorities and the levels of certificates
The class of intermediate certificate authorities The level of certificates which they can present
Class 1 Level 1
Class 2 Level 1 and 2
Class 3 Level 1, 2 and 3
Class 4 Level 1, 2, 3 and 4
 

1.2         Document name and identification

 

This document is named “Digital certificate policies of IRAN’s public key infrastructure” and is approved in the meeting of Digital Certificate Policy Council in July 17, 2012. This document was published in July 21, 2012 and it is available on Government Root Certificate Authority website: http://www.rca.gov.ir.
Object identifiers of digital certificate policies of Government Root Certificate Authority, are shown in below table according to four security levels.
Table 3: object identifiers of assurance level policies
Assurance level Object identifier
Level 1 2.16.364.101.1.1.1
Level 2 2.16.364.101.1.1.2
Level 3 2.16.364.101.1.1.3
Level 4 2.16.364.101.1.1.4

1.3         PKI Participants

1.3.1. Certification Authorities

 

Certificate authorities in IRAN’s PKI are composed of Government Root Certificate Authority and intermediate certificate authorities. In this section, we will describe different types of certificate authorities and hierarchical architecture of IRAN’s public key infrastructure.
Government Root Certificate Authority: IRAN Government Root Certificate Authority which will be named “IR.GRCA” is the Trust point in IRAN’s public key infrastructure. According to paragraph (a) of article 4  from executive regulation of article 32 of e-commerce law (approved in October 22, 2007), this CA has obtained the license to create, sign, issue and revoke the digital certificate of intermediate certificate authorities. IR.GRCA is responsible for all dimensions of issuance and management of intermediate certificate authorities including observation on enrollment, authentication, issuance of intermediate CAs certificates, publishing and revocation the certificates and re-key processes.
Hierarchical model of IRAN’s public key infrastructure, without considering assurance levels, is shown in below figure.

Figure 1: hierarchical model of IRAN’s public key infrastructure
As shown in above figure, IR.GRCA under supervision of IRAN’s Digital Certificate Policy Council (which is explained in section 1.3.5) is in the first level of infrastructure and in the second level, intermediate certificate authorities are placed.
Certificate authorities, which have obtained their license and certificates from IR.GRCA, are named intermediate certificate authorities; these certificate authorities are called “intermediate CAs” in this document. These CAs have the authority to issue and revoke digital certificates. Intermediate CAs should be in accordance with the conditions of this document, in order to obtain their certificate. In the following, different types of Intermediate CAs are listed:
  • Governmental General Intermediate CA
This is a unique CA which presents digital certificate services for all different functions to applicants in general form.
Note- until establishment of private intermediate CAs, this CA is permitted to present digital certificate services to private customers for non-governmental functions.
  • Governmental Intermediate CA
Each of executive organizations can establish governmental intermediate CA, after obtaining license from IR.GRCA.
Note- governmental intermediate CA can be established through coalition of some executive organizations in common areas under responsibility of one of those organizations and under united certificate practice statement (CPS).
  • Dependent Intermediate CA
Governmental intermediate CAs (if they have the related qualifications) can establish dependent intermediate CA in their dependent organizations, only in their acting domain.
Note1- until superior organizations of dependent intermediate CA applicants; have not established governmental intermediate CA, dependent intermediate CA can be established under general intermediate CA.
Note 2- if CPS of dependent intermediate CA applicant is not accordant  with CPS of superior organization, applicant, in the first place, can obtain the license of establishing general intermediate CA, and in second place, can obtain the license of establishing governmental intermediate CA.
  • Private Intermediate CA
These CAs will obtain license from government root CA, for issuance of digital certificate which are used in private section, after authentication of their quality, quantity and legal qualifications.
  • External Intermediate CA
Private Intermediate CA can obtain “external intermediate CA” license from IR.GRCA, after authentication of their qualifications and also after signing contract with related governmental organization. These CAs can only issue digital certificates for applications such as: Government to business (G2B) and Government to customer (G2C) (digital certificate of private persons who have relation with governmental organizations).
Establishing approval of intermediate CA including governmental, general, private, external and dependent, is issued after approval of related CPS by IR.GRCA and approval of the council. By the way, IR.GRCA is responsible for periodic audits of all the mentioned intermediate CAs and these CAs are bound to do required cooperation.
As it was mentioned in section 1.1, by considering the certificate level which certificate authorities can present, they are divided into 4 different classes, and a certificate authority can establish certificate policies for more than one assurance level. Categorization of IR.GRCA and intermediate CA is as follow:
Table 4: different levels of certificate authorities
Type of certificate authority Class of certificate authority
IR.GRCA Class 4
General governmental intermediate CA Class 3 and upper
Governmental Intermediate CA Class 3 and upper
Private Intermediate CA Class 2 and upper
External Intermediate CA Class 3 and upper
Dependent Intermediate CA Class 2 up to class of superior Intermediate CA
 
 
As it is shown in Figure 1, hierarchical model of IRAN’s PKI is composed of maximum 3 layers, which can be corresponding with a chain formed of 3 certificates (for example; certificate of IR.GRCA, general intermediate CA, and dependent intermediate CA).
It should be mentioned that general intermediate CA and governmental intermediate CA are allowed to create third layer (dependent) CA only after approval of IR.GRCA; and private or external intermediate CA are not allowed to create this layer.
According to table 4, IR.GRCA is able to issue certificate in four security levels: platinum, gold, silver and bronze. These certificates, dependent to intermediate CA class, are assigned to them. For example; for a governmental intermediate CA class 3, certificates in 3 levels (bronze, silver, and gold) are issued, so that this CA presents digital certificate services in security levels 1, 2, and 3, appropriate with each level’s policies.

1.3.2. Registration Authorities

 

Registration authority (RA) is an optional entity which has the responsibility of identification, and checking the accuracy of received information from digital certificate applicants. In fact, registration authority is responsible for preparing issuance request, revocation and updating certificate and also re-key request by checking applicant’s identity. Registration authority should be approved by certificate authorities, and there should be a contract or agreement between these two, so that registration authority undertakes to present services according to CPS of intermediate CA.
Registration Authority must accommodate its operations with CPS of related CA. 

1.3.3. Subscribers

 

Subscriber is a person or an organization who has obtained certificate from certificate authorities, and its name is registered as subject name in digital certificate. The identity of subscriber is checked by certificate authority or registration authority before the certificate is issued.
Subscriber may be a certificate authority, person, organization, staffs of an organization or other entities such as firewall, trusted server, etc. which are used in an organization for making secure communication.

1.3.4. Relying Parties

 

Relying party is a person or an organization that trusts the accuracy of conformity between specifications and public key of subscriber and relies on its digital certificate.

1.3.5. Other Participants

1.3.5.1. IRAN’s Digital Certificate Policy Council

 

In order to protect the integration and preventing the breakdown of solutions and standards used in certificate authorities, policy making in the area of IR.GRCA activities and updating certificate policies of this CA and approving the conformity of CPS of all the intermediate CAs with this document, a council called Digital Certificate Policy Council is established, which from now we call it “council” in this document. The council consists of below persons:
  • Minister of industry, mine and trade, or its deputy minister
  • Deputy Minister of justice
  • Deputy Minister of information
  • Deputy Minister of information and communications technology
  • Deputy Minister of economy and finance
  • Deputy Minister of health and medical education
  • Vice presidency for strategic planning and control
  • Vice chairman of central bank of Islamic Republic of IRAN
  • President of the Chamber of Commerce, Industries and Mines
  • Head of Registration of Deeds and Properties organization
  • Head of computer guild system organization
  • Secretary of informatics supreme council
  • Secretary of information technology supreme council
  • Head of center for e-commerce development which is subsidiary of ministry of industry, mine and trade, as the council secretary (non-voting)
  • One, two or three certified consultant recommended by chief and approved by majority of other council members

1.3.5.2. The Council’s Regulatory Committee

 

In order to do regulatory activities, the council chooses a five person committee (preferably selected from council members) named regulatory committee, for a 1 year period. The presence of three members is essential for activating hardware security module of IR.GRCA.

1.4         Certificate Usage

 

1.4.1. Appropriate Certificate Uses

 

IRAN’s PKI is designed to provide security services such as confidentially, integrity, non-repudiation and authentication. If intermediate CA use different assurance levels, they should stipulate the definition of these assurance levels, their utility and IDs in their CPS. Usages/ types of defined certificates and their function in public key infrastructure of IRAN, is shown in below table.
Table 5: types of certificate usage
Usage/ type of certificate Description
Signature certificate This certificate can be used for signing documents, electronic transactions, and also client authentication.
secure E-mail certificate This certificate, through S/MIME protocol, provides the possibility to make E-mail secure and confidential by encryption of message contents and signing E-mails.
authentication certificate This certificate is used for subscriber authentication, in order to login. For example; this certificate can be used to login to system by two factor authentication based on public key, in Microsoft operating systems. Through this certificate, we can logon by using a smart card.
organizational stamp certificate This certificate is considered as certificate of a company/ organization signature. This can be used as organizational stamp of that company, in the form of a digital signature.
Server certificate This certificate is considered to be used in server side. SSL/TLS and Domain Controller certificates are 2 examples of common usage of this certificate.
SSL/TLS is specifically issued for an internet address (URL), and is used to guarantee the authenticity of a server, and in other words to guarantee the relationship between address and website to which is referred. Also using this certificate a secure and encrypted connection is established between browser and web server.
Domain Controller certificate is used to logon to a system in a Domain and in server side (Domain Controller), and is corresponding to MS Smartcard Logon certificate in user side.
CodeSigning certificate This certificate is used to ensure the authenticity and protecting the integration of different software especially which are published through internet, such as ActiveX, and Java Applet. Therefore, when users download signed software, they can be assured of source code accuracy and also its integrity.
IR.GRCA certificate Self-signed certificate which belongs to government root certificate authority.
intermediate CA certificate Certificate which belongs to intermediate certificate authorities available in hierarchical model of IRAN’s public key infrastructure, which is issued by superior certificate authorities.
registration authorities (RA) certificate Certificate which belongs to registration authorities dependent to a certificate authority, which is used for signing requests in RA side.
Online certificate status protocol certificate Certificate which belongs to OCSP responder, which is used to sign OCSP responses prepared by this server.
time stamp authority certificate Basically, time stamp is used to store the exact time of signing at the moment of signing different documents, such as contracts, or agreements. By using time stamp, it is possible to prove obviously that data corresponding with a time stamp is not changed, since the time mentioned in time stamp. Time stamp certificate is used by time stamp authority, to do signature operation in time stamp process.
 

1.4.2. Prohibited Certificate Uses

 

Unauthorized usages of certificate are listed in the following:
  • Certificates should not be used in illegal cases and contrary to public discipline.
  • Certificates should be used in considered usages which are mentioned in section 1.4.1.
  • Issued certificates for persons and clients are designed to be used in applications of the client, and they should not be used as service provider certificate or organizational certificate.
  • Certificate of certificate authority should be used just in the area of certificate authority.
  • Certificate of end entity should not be used as the certificate of certificate authority.

1.5         Policy Administration

 

1.5.1. Organization Administrating the Document

 

The responsibility of drafting, revising, and reviewing this document is on IR.GRCA, and the responsibility of approving this document is on the council. The only authorized organization for interpretation of this document is IR.GRCA, and this CA will respond to every question about this document in accordance with section 1.5.2.

1.5.2. Contact Information

 

Questions about certificate policies will be responded by government root certificate authority:
  • E-mail: rca@ecommerce.gov.ir
  • URL: http://www.rca.gov.ir
  • Phone: +98-21-88955951
  • Fax: +98-21-88955953
  • Address: building no. 1 of ministry of industry, mine and trade, no. 11, Shahid Nadery St., Keshavarz Blvd., Tehran, IRAN

1.5.3. Person determining CPS suitability for the policy

 

Digital Certificate Policy Council is responsible for approving the adaptation of CPSs of intermediate CA with digital certificate policies of IRAN’s public key infrastructure, according to the report presented by IR.GRCA. Only after the confirmation of government root certificate authority and council, CPSs of intermediate CA are effective.

1.5.4. CPS Approval Procedures

 

Applicants for setting up an intermediate CA should prepare their CPSs according to RFC3647 and in accordance with digital certificate of IRAN’s public key infrastructure, and then he should send it together with relating documents, to IR.GRCA. The presented instruction together with related documents will be evaluated in IR.GRCA, and after being approved they will be sent to council for confirmation.

1.6         Definitions and Acronyms

 

Acronyms
Table 6: acronyms
Abbreviation Equivalent Meaning
CA Certificate authority An entity which is allowed to issue and manage digital certificates.
CP Certificate policy A collection of regulations which identifies digital certificate policies of IRAN’s public key infrastructure.
CPS Certificate Practice Statement Practice statement which intermediate CA uses it to issue digital certificate.
CRL Certificate revocation list Data structure which lists digital certificate that are expired and are not valid anymore.
CSR Certificate signing request A defined transaction format by PKCS#10, including synthetic name and a number of optional features, which is signed by certificate applicant, and are sent to certificate authority, and then is changed into X.509 certificate.
DN Distinguished name A unique ID which presents the available object in data tree of X.509 format directory.
DNS Domain name system DNS or domain name system is a hierarchical method which distributes database relating to symbolic names and their IP equivalent. Each station can find its IP address, in a hierarchical method. This system is introduced in 1984.
FIPS Federal information processing standard Professional guidelines which NIST has provided them for preparing system equipment’s and information processing service.
IR.GRCA IRAN Government Root Certificate Authority It is a certificate authority which is directly trusted by end entity. “IR.GRCA”, is the Trust point in IRAN’s public key infrastructure. According to According to paragraph (a) of article 4  from executive regulation of article 32 of e-commerce law (October 22, 2007), this CA has obtained the license to create, sign, issue and revoke the digital certificate of intermediate certificate authorities.
IETF Internet engineering task force IETF is a big international community of network designers, operators, sellers, and researchers relating with internet architecture development, and smooth and accurate function of internet.
OCSP Online certificate status protocol OCSP is a protocol which is used to declare online status of X.509 certificate revocation or not revocation. The nature of OCSP protocol is based on request and response.
OID Object identifier OID is a unique and official ID, which is composed of a collection of digits (defined in ASN.1 standard) that are used to mention objects with certain features.
PKCS#10 Public key cryptography standard It is public key cryptography standard number 10, which defines a structure for certificate request.
PKI Public key infrastructure PKI is a collection of services, policies, processes and hardware/software systems which are used to manage and apply X.509 digital certificates, and also to present different security services based on public key encryption.
PKIX Public key infrastructure (X.509) PKIX was established in 1995, in order to develop internet standards to support public key infrastructure based on X.509.
RA Registration authority RA is an optional entity in public key infrastructure which does not sign digital certificates or revoked certificate list, but it is responsible to register and identify information needed by certificate authority to issue digital certificate or revoked certificate list.
RFC Request for comment RFC is an agreement published by IETF, which describes method, manner, research, or innovation in working with internet and connected systems to internet
RSA Rivest-Shamir-Adelman Encryption algorithm of public key, which is created by Rivest, Shamir, Adleman in 1978.
URL Uniform resource locator URL is a string of characters that identifies the source place which is available in internet.
X.500 X.500 X.500 is a collection of standards presented by ITU-T and global organization of ISO which describes “directory service” carefully.
X.501 X.501 X.501 is a standard in X.500 standards series. A network service such as router may need X.501 for using LDAP directory service, or producing PKCS certificate requests.
X.509 X.509 X.509 is a standard in X.500 standards series, which is defined for authentication in directory system collection. X.509 standard is the most common standard for issuance of digital certificate.
 
 
Definitions
Table 7: definitions
Word Meaning
Access Availability of connection to system, in order to use system resources for controlling or obtaining information inside system.
Activation data Private information (except for keys), which are needed for accessing to private key.
Algorithm A limited collection of step-by-step instructions to solve computational problems and routines, especially routines which run by computer.
Archive A collection of information which are saved for a long time for purposes such as supporting event record service and system integrity service.
Assurance A feature of information system which ensures that system works in accordance with security policies.
Assurance level A special level in hierarchical scale that is an indicator of assurance for conformity of purpose with needs.
Authentication The process of authenticating the identity which is claimed by an entity.
Authenticity Principle of being trusted and recognizable.
Authorization A mechanism which specifies that a person whose identity is authenticated, is allowed to do what kind of operations.
Availability To deliver information at the right time to the right person.
Backup To copy files, information and programs for facilitate data recovering.
biometric authentication A method to produce authentication information by making physical features electronically; for example fingerprint.
Certificate authority A CA which is responsible to issue and manage digital certificates and grantee the connection between certificate information.
Certificate expiration The certificate is not valid anymore, because it is expired.
Certificate extensions Information which are defined to add additional specifications to X.509, V3 certificate.
Certificate policy A collection of regulations which specifies certificate policies of IRAN’s public key infrastructure.
Certificate Practice Statement (CPS) Practice statements which certificate authority use it to issue certificate.
Certificate rekey The process of renewal of digital certificate public key, through issuance of a new certificate which has a new different key.
Certificate renewal Producing a new certificate similar to previous one, the only difference is that new certificate has a different validity time and different serial number.
Certificate renewal The process of validity renewal of digital certificate by issuance of a new certificate.
Certificate request A message about requesting a signature certificate from registration authority by applicant.
Certificate revocation To declare that digital certificate (which is issued by a certificate authority and has expiration date) is not valid anymore.
Certificate Revocation List Data structure which lists digital certificate that are expired and are not valid anymore.
Certificate suspension Temporary non validity of digital certificate.
Certification path A chain of digital certificates that enables relying parties to verify signature and authenticate the latest certificate of this chain
Compliance audit Independent review and checking of document and system activities for recognition of system control adequacy, assurance of conformity with CPS, fault detection in certificate issuance service, and change recommendations.
Confidentiality Hiding secret information from unauthorized persons/ organizations.
Configuration Software and hardware setting of computer systems.
Cryptography Finding secure solutions for a collection of two or more users, who wants to make relationship on a public channel which is exposed to the attack of a foreign adversary. In other words, an area of knowledge and technique for transferring data, in order to:
Hide its content
Prevent unwanted changes
Prevent illegal access
Digital certificate An electronic data structure to which a digital signature (according to its data structure) is added, and is used to match name and specifications of an entity, with his/its public key.
Digital signature A digital string that, in a complex method, is extracted from a document’s content and after being encrypted with private key of document owner, is attached to document and sent, so that, every information receiver can recognize the source and integrity of information.
Disaster recovery A process that recovers all information which is lost in fire, destruction, natural disasters, or system failure.
Distinguished name A unique ID that presents the object available inside information tree of X.500 format directory.
End entity An entity which uses keys and certificates to create or verifying the accuracy of signature or confidentially. End entities are subscribers, organizations, or relying parties.
 
Entry The input information of documents, applications and databases.
Field A part of a certificate which its content is a special kind of data (pre-defined by X.509 standard).
Firewall An inter-network connection that confines data traffic between connected networks, and protects system resources against other network hazards.
hardware Physical components of computer system.
Hardware security module (HSM) A kind of secure hardware module that can maintain cryptographic keys securely and also can run cryptographic mechanisms with demanded performance, through software interfaces.
Identification Recognition and identification of an entity from other entities, through checking identification cards, and other recognition information, such as password, biometric information, etc.
Identity A collection of tangible and intangible personal features, which distinguishes persons from each other.
Identity verification To present information in order to verify that claimed identity is real.
Initialization An incoming parameter that initializes cryptographic algorithm.
Integrity A collection of mechanisms which prevents any kind of change, manipulation, information repeat or illegal removing, or at least detects such actions.
Intellectual property right The right to control, and create benefit from what is created, or discovered.
Intermediate CA It is a certificate authority which obtains its license from IR.GRCA, and can issue certificate for subscribers.
Intermediate Certificate The certificate of intermediate certificate authority that is signed by IR.GRCA, and allows intermediate certificate authority issues certificate for subscribers.
IR.GRCA It is a certificate authority which is directly trusted by end entity. “IR.GRCA”, is the Trust point in IRAN’s public key infrastructure. According to According to paragraph (a) of article 4 from executive regulation of article 32 of e-commerce law (October 22, 2007), this CA has obtained the license to create, sign, issue and revoke the digital certificate of intermediate certificate authorities.
Key escrow Key recovery technique to save encryption key information, with third party responsibility, in order to recover the key and use it in special situations.
Key generation The process of producing encryption keys.
Key pair A collection of mathematical related keys (public and private key), which are used for asymmetric encryption, and are produced in a way that obtaining private key from public key is impossible.
Key recovery The process of obtaining the value of an encryption key, which was used before for encryption operation.
Login/logon Access of a system entity to system resources that is normally done through username and password which authenticate the identity of users, or two-factor authentication is done.
M of N mechanism Dividing a responsibility between N entities, in the way that less than M persons cannot do the responsibility and M persons of those N persons is needed to do the responsibility.
Modulus Defined constant value in modulus account. A section of public key of RSA encryption system is usually according to modulus account.
Network A collection of host computers that exchanges information with other networks or internet network.
Non-repudiation A collection of mechanisms which grant legal backing to messages and transactions, and does not allow the sender to deny message sending, and also does not allow the receiver to deny message receiving.
Object identifier A unique and official ID, which is composed of a collection of digits (defined in ASN.1 standard) that are used to mention objects with certain features.
OCSP responder A service provider that declares X.509 certificate revocation or validity status online. The nature of OCSP is based on request and response.
Online certificate status protocol An internet protocol to obtain digital certificate status and its relating information from service provider by customer.
Operating system A computer program which performs principle operations of the system (such as; management of system resources, running utility applications, system file assemble, etc.).
Password Secret authentication information, which is usually composed of a string of characters.
PKI Security Officer A person who is in charge for administering PKI managers, together with other PKI security officers. This person is also responsible for configuring security policies of certificate authority.
Policy object identifier A unique and official ID, which is composed of a collection of digits (defined in ASN.1 standard) that are used to mention certificate policies belonging to a certificate authority.
Public key infrastructure (PKI) PKI is a collection of services, policies, processes and hardware/software systems which are used to manage and apply X.509 digital certificates, and also to present different security services based on public key encryption.
Registration An executive process for primary registration, and other features of a person/organization in certificate authorities or registration authorities (before issuance of digital certificate).
Registration authority an optional entity in public key infrastructure which does not sign digital certificates or revoked certificate list, but it is responsible to register and identify information needed by certificate authority to issue digital certificate or revoked certificate list.
Relying party A person who trusts the validity of certificate information.
Repository A storage and distribution system of digital certificates and its relating information (for example; CRL), for relying parties.
Router A network computer that directs out the internet protocol packages which their destinations is not computer.
Security A collection of operations which are done for protecting a system, such as: preventing or reducing dangerous risks and system revival after happening of these risks.
Serial number A digital value that is given to certificate by certificate authority, and is unique among all of the certificates.
Server A system entity that provides services for customer, in response to requests of other system entity.
Signature A digital certificate containing a public key which is used to verify a digital signature
Subject name A name which is assigned to the holder of private key corresponding with public key. In organizational certificates, a name which describes the organization or equipments using private Key is used.
Subscriber A person whom the certificate is issued, and he can use private key relating to the public key which is inside the certificate.
Symmetric Algorithm A cryptography algorithm in which, cryptography and decoding keys are the same.
Time stamp A digital signature which includes date and time, and testifies that its contents are signed in a specific time.
To be compromised A security event that put information exposed to illegal access.
Token Token is a portable electronic media for secure maintaining of cryptographic key pair and identification values and doing its relating calculations (for example; different encryption operations). This device can also be used for access control.
Trusted certificate A certificate that relying party trusts to its accuracy without evaluating it. Specially the digital certificate that is used in certificate path, in order to provide the first certificate public key.
Validity of certificate A data unit in digital certificate which in validity time, specifies the relation between certificate information and the key inside the certificate.
Virus A hidden software including destructive regions which is distributed by infecting. For example; it copies itself to other applications and changes to a part of it. Virus cannot run by itself, and hosted application should run for activating virus.
Zeroize A method to remove saved information electronically, at the moment of information source change, so that information could not be recovered.

2          Publication and Repository Responsibilities

2.1         Repository

 

All intermediate certificate authorities are required to create and maintain a public repository to publish certificates, CRL, and other related information, which are available to users online. The minimum information that should be published in repository is introduced in section 2.2. Certificate authorities should inform subscribers from certificate and CRLs publishment address, or OCSP responder server address. The CPS document of intermediate CA, after being approved by council, should be placed in repository.
IR.GRCA publishes self-signed certificate(s) and CRL of issued certificates for intermediate CA, on http://www.rca.gov.ir.

2.2         Publication of Certification Information

 

All intermediate CAs should publish below information through repository, so that subscribers and relying parties can access to information:
  • All the issued certificates by intermediate CA;
  • The latest issued version of CRL;
  • CPS document of digital certificate of certificate authority (CPS);
  • Document of digital certificate policies of IRAN’s public key infrastructure (CP);
  • OCSP service, in the condition that intermediate CA supports OCSP protocol;
  • Agreement with relying party;
  • Agreement with subscriber.
IR.GRCA publishes following information on its URL:
  • Certificate(s) of IR.GRCA;
  • Issued certificates for intermediate CA;
  • Certificate revocation list (CRL);
  • Document of digital certificate policies of IRAN’s public key infrastructure;
  • comprehensive document of IRAN’s PKI profiles;
  • Guidelines to request for setting up an intermediate CA;
  • IRAN’s public key infrastructure standards;
  • The list of cryptography modules and certificate issue and management software, approved by IR.GRCA;
·        All the council legislations and other relating documents, which IR.GRCA decides that it is required to be published.
  • Time or Frequency of Publication
Requirements of schedule and frequency of publication for all certificate authorities are as follow:
  • Issued certificates should be published (according to section 4.4), after accepting the certificate by certificate subscriber.
  • Time or frequency of CRL publication, is determined according to assurance level in section 4.9.7.
  • If certificate authority supports OCSP protocol, OCSP responder server should present certificate status to OCSP client in real time.
  • This document will be published after being approved by council, and will be checked annually, if there is a need to do changes in it.

2.3         Access Control on Repositories

 

Certificate authorities should protect repository information from unauthorized changes. Any change or update in repository should be done by reliable roles mentioned in section 5.2.1. Certificate authorities should configure their operating system and repository in a way that only authorized roles of certificate authority (after being approved by the council) are able to replace online copy of certificate policy document or CPS.
Changing and updating repository of IR.GRCA is only possible by authorized personnel, and after applying multi-layer access control process; this document will be published, after being electronically signed by an authorized role of IR.GRCA, in PDF format.

3          Identification and Authentication

3.1         Naming

 

Every entity that owns the certificate should have a distinct and unique name in “subject name” and “issuer name” fields in X.501 standard form, according to PKIX Part 1. In this section, we explain how subscribers are named and recognized. Naming requirements for different types/functions of digital certificate is explained in comprehensive Requirements of IRAN’s PKI profiles (Appendix).

3.1.1. Types of Names

 

Table 8: naming requirements
Assurance level Requirements
Level 1 Every entity should:
·      Have a distinct and unique name in “subject name” and “issuer name” extensions in X.501 standard form.
·      By using “subjectName” extension, an optional name in another format may be determined for entity.
·      Distinguished name should be recorded in certificate in form of a X.501 printable string, and it must have a value.
Level 2
Level 3
Level 4
 

 

3.1.2. Need for Names to be Meaningful

 

Table 9: need for names to be meaningful
Assurance level Requirements
Level 1 Since the identity of subscribers is not checked by certificate authority, using meaningful names necessarily needed; unless the process of identification is done by an organization independent from certificate authority.
Level 2 The content of each of fields (issuer and subject) should be relevant with identification name of entity. The value of mentioned fields should be valued in accordance with comprehensive document of IRAN’s PKI profiles.
Level 3
Level 4
 

3.1.3. Anonymity or Pseudonymity of subscribers

 

In the level of an identity, subscribers are not checked by certificate authorities of registration authorities. Therefore, considered distinguished name for issued certificates in this level, may be unreal or nick name. Nevertheless unreal or nick names cannot be used for issued certificates in levels 2, 3, and 4.

3.1.4. Rules for Interpreting Various Name Forms

 

It is not defined.

3.1.5. Uniqueness of Names

 

Names in certificate authorities should be unique. All certificate authorities should use X.501distinguished names which are approved by council. Assigning distinguished names to subscribers is the responsibility of certificate authorities. Certificate authorities can use serial numbers or other information to maintain the uniqueness of distinguished name. In comprehensive document of IRAN’s PKI profiles, it is described how to apply uniqueness in naming process of certificate.

3.1.6. Recognition, Authentication and the Role of Trademarks

 

Certificate authorities should not issue certificate for the names which abuse other organization’s trademark.

3.2         Initial Identify Validation

3.2.1. Method to prove possession of private key

 

Since in IRAN’s public key infrastructure, the process of key generatioin is usually done by certificate applicant, applicant should prove that whether his private key is in accordance with public key that is presented for registration authority or certificate authority, or not. If the process of key generation is done by registration authority, the conformity between public key available in request and produced private key should be proved to certificate authority.
Table 10: the method to prove private key ownership
Assurance level Requirements
Level 1 Proving the ownership of private key is not needed.
Level 2 Before issuance of certificate, final users (for presenting certificate request to intermediate CA) and intermediate CA (for presenting intermediate CA certificate request to overhead certificate authorities) should prove the possession of their private key.
The process of proving possession of private key of intermediate CA, and authenticating it by IR.GRCA, should be in accordance with PKCS#10 standard.
All intermediate CAs should specify the method of proving certificate applicant’s possession of private key, in their CPS.
Level 3
Level 4
 

3.2.2. Authentication of Organization Identity

 

Organizations should present their certificate request to registration authority through a representative. According to section 1.4.1 and comprehensive document of IRAN’s PKI profiles, certificates that can be issued for organizations, include: organizational stamp certificate, code signing certificate, server certificate and certificate authorities related certificates.
Organizational certificate request should contain name, address, and legal and official documents of organization to prove organization existence. Registration authority should also check the identity of organization representative, and authorization of representative in representing the organization. Authentication of representative should be done according to sections 3.2.3 and   3.2.5.
Registration authorities or intermediate CAs should archive a copy of identification type and details which are used in organization authentication, and the authentication date according to section 5.5.2.

3.2.3. Authentication of Individual Identity

3.2.3.1. A person requests certificate personally

 

Before recording and sending request to intermediate CA, intermediate CAs or registration authorities should authenticate the identity of person, according to identification system described in below table.
Table 11: individual authentication
Assurance level Identification method
Level 1 Without any need to registration formalities and is based on self-reporting and trust.
Level 2 Authentication requirements for requesting second level certificate for affiliated and non-affiliated individuals are as follow:
·      Two kinds of identification cards that one of them should have photo on it together with other needed documents.
·      If a second level or upper level certificate is already issued for an applicant, and its certificate is valid and its private key is not revealed, the process of certificate request can be done by digital signing of a certificate request form, through the key corresponding to previous certificate; in this method the process of applicant authentication should be described in practice statement of intermediate CA.
Level 3 Affiliated individuals: personally and with 2 valid identification cards and at least 100 scores.
Non-affiliated individuals: personally and with 2 valid identification cards (there should be photo on them) together with biometric identification only by real person (biometric identification of individuals who are representative is not acceptable).
Level 4 Affiliated individuals: personally and with 2 valid identification cards and at least 150 scores.
 
 
Table 12: methods to score individuals
Index Score Example
Accepted work experience 1 to 2 years: 10 scores
2 to 4 years: 20 scores
4 to 7 years: 40 scores
7 to 10 years: 60 scores
More than 10 years: 70 scores
100 scores = 2 ID cards (80) + 2 years of experience (20)
100 scores = 2 ID cards (80) + contract type (10) + 1 year of experience (10)
150 scores = 2 ID cards (80) + job title: manager (50) + 3 years of experience (20)
150 scores = 2 ID cards (80) + biometric authentication (20) + 5 years of experience (40) + contract type (10)
150 scores = 2 ID cards (80) + 10 years of experience (70)
Job title General manager/ CEO or upper= 50 scores
Contract type Official or contractual= 10 scores (just for governmental organizations)
Maximum 2 ID card Birth certificate 10 scores
National ID card 40 scores
Passport 20 scores
Driving license 20 scores
Biometric authentication 20 scores
 
 
Registration authorities or intermediate CAs should keep a copy of individual’s identity details in the validity time of certificate.
All intermediate CAs should explain the process of authentication of individuals and their ID cards, in their CPS.

3.2.3.2. A person acting on behalf of an organizational subscriber or participant

 

An individual can request certificate through another person by granting representation to him. Before recording and sending request to intermediate CA, registration authority should authenticate the identity of person or his representative according to section 3.2.3.1. Moreover, registration authority should ensure that representative is allowed to request certificate by certificate applicant.
Information relating to method and details of individual/representative authentication should be kept by intermediate CA or registration authority. Moreover, intermediate CA should exactly specify the process of authentication in situations that certificate request is done by a representative.

3.2.3.3. A person requests certificate for his organizational role

 

Before recording and sending request to intermediate CA, registration authority should authenticate the identity of person or his representative according to section 3.2.3.1. Moreover, registration authority should ensure that representative is allowed to request certificate by certificate applicant.
 All intermediate CAs should exactly specify the process of authentication in situations that certificate request is done by a representative.

3.2.4. Non-verified Subscriber Information

 

Information that is presented to registration authority by certificate applicant, and does not need to be verified, is as follow:
  • Organizational unit (OU): assurance level 1 and 2;
  • The name of subscriber for assurance level 1;
  • Other information that are specified in certificate as non-certified information.

3.2.5. Validation of Authority

 

Whenever a requested name for an individual’s certificate is related to a specific organization, when a person as representative of an organization requests certificate for that organization, registration authority should:
  • Follow up the organization existence through database or official and legal documents which have been presented;
  • Authenticate the identity of applicant through telephone inquiry for assurance level 2.
  • Authenticate the identity of applicant through written inquiry for assurance levels 3 and 4.

3.2.6. Criteria for interoperation

 

It is not defined.

3.3         Identification and authentication for re-key requests

 

Re-key of a certificate means producing a new certificate similar to the previous one, except that the new certificate has a public key, in accordance with private key, and different serial number and validity time.
Individuals and organizations that intend to re-key, should present their re-key request to registration authority, and RA should authenticate the identity of applicant according to sections 3.3.1 and 3.3.2. Re-key requests should be recorded and maintained.

3.3.1. Identification and authentication for routine re-key

 

Identification and authentication for re-key, includes check and testify that an individual or organization that presented re-key request is the real subscriber or his authorized representative. The process of re-key request and authentication of subscriber or his representative is in accordance with section 3.2; the only difference is that registration authority should compare presented information and document by applicant with information included in its database and archive (which is recorded at the moment of certificate request). If information is matched, registration authority approves re-key request and sends it to intermediate CA.

3.3.2. Identification and authentication for re-key after revocation

 

It is not defined.

3.4         Identification and authentication for revocation request

 

Identification and authentication for revocation request includes check and testify that an individual or organization that has requested to revoke the certificate, is the real subscriber or his authorized representative. The process of certificate revocation request and authentication of subscriber or his representative is in accordance with sections 3.2.2 and 3.2.3. , the only difference is that registration authority should compare presented information and document by applicant with information included in its database and archive (which is recorded at the moment of certificate request). If information is matched, registration authority approves certificate revocation request and sends it to intermediate CA. Certificate revocation requests should be recorded and maintained.

4          Certificate Life-Cycle Operational Requirements

4.1         Certificate Application

 

Certificate applicant and registration authority should follow below steps at the moment of presenting certificate request:
  • Identification of subscriber (according to section 3.2)
  • Recording of applicant fundamental information, according to CPS of intermediate CA;
  • Generating key pair and presenting public key together with each certificate request;
  • To ensure the relationship between presented public key and subscriber private key (according to section 3.2.1)
The order of the above mentioned steps may be changed, but all of them should be done before issuance of digital certificate. The process of certificate request by subscribers should be presented in CPS of intermediate CAs.
Certificate request of Intermediate CA should be done through the contact information presented in section 1.5.2 and according to “Guidelines to request for setting up an intermediate CA” which is published on IR.GRCA URL. Applicants for setting up an Intermediate CA should present their CPS to IR.GRCA, according to certificate policies of IRAN’s public key infrastructure and in framework of RFC3647. CPS will be sent to council to be evaluated and approved, after being checked by IR.GRCA. If CPS is approved, the steps of setting up an intermediate CA will be continued. Intermediate CAs are allowed to issue certificate which contains digital certificate policy ID of IR.GRCA, only after they obtain written permission of council and also after issuance of certificate by superior certificate authorities.
1. 
2. 
3. 
4. 
4.3. 
4.4. 
4.5. 

4.1.1. Who can submit a certificate application

 

Individuals, who may present certificate request, include:
  • An individual who wants to own the certificate;
  • Authorized representative for an organization or entity (for presenting certificate request for another person, organizational role, equipment or utility application, or presenting organizational certificate request);
  • Authorized representative for intermediate CA to present certificate request from overhead certificate authority.

4.1.2. Enrollment process and responsibilities

 

Every individual or organization that intends to request issuance of a certificate from a certificate authority should do following steps:
  • Certificate applicant should present certificate request together with proof of possession of the private key (according to section 3.2.1) to certificate authority or registration authority, or he should transfer the process of key generation to certificate authority or registration authority;
  • He should present required documents for creating certificate request (according to section 3.2), to registration authority;
  • He should sign an agreement about certificate usage conditions.

4.2         Certificate Application Processing

 

Intermediate CAs should express the processes and requirements of certificate issuance request, in CPS. They also should inform applicants about required information for certificate request process.

4.2.1. Performing identification and authentication functions

 

Registration authority or certificate authority should identify and authenticate all the required information which is presented by applicant, for issuance of a certificate, according to section 3.2.

4.2.2. Approval or Rejection of Certificate Applications

 

If applicant authentication is done successfully according to section 3.2, registration authority should confirm certificate application. Registration should reject application if one of the following occurs:
  • Applicant authentication is not done completely according to presented documents;
  • The process of proof of possession of private key is not done successfully;
  • Certificate applicant does not accept certificate usage agreement;
  • Certificate applicant does not respond to registration authority notes in due date;
All intermediate CAs should explain the process of approving or rejecting certificate request, in their CPS.

4.2.3. Time to process certificate applications

 

The maximum time limit between receiving and approving the application and certificate issuance for each assurance level should be in accordance with below table.
Table 13: time to process certificate applications
Assurance level Maximum time period between receiving and approving the request
Level 1 There is no boundary.
Level 2 End entity certificates are issued during 5 days from request time.
Level 3 End entity certificates are issued during 2 days from request time.
Level 4 End entity certificates are issued right at the moment of request time.
 

4.3         Certificate issuance

CA actions during certificate issuance

 

Certificate is issued after final approving of certificate request by certificate authority or after receiving certificate request by registration authority and validating the signature of request.
Certificate authority should issue certificate for applicant, according to information included in certificate request.

4.3.2. Notification to subscriber by the CA of issuance of certificate

 

All certificate authorities offer issuance of certificate, should notify subscriber that certificate is issued according to method which is given in their CPS.
IR.GRCA, after issuance of certificate, informs the applicant that his certificate is issued through an informative letter.

4.4         Certificate Acceptance

4.4.1Conduct constituting certificate acceptance

 

Certificate reception by certificate applicant, is a precondition for using digital certificate. Intermediate CAs should explain the process of certificate acceptance by certificate applicant, in their CPS and also in their agreement with certificate applicant. The processes of issuance, informing, and acceptance, are dependent to factors such as the place in which key pair is produced, and how certificate is available for end entities. Acceptance of a certificate means that end entity testifies that all the mentioned information in digital certificate is true.
If the certificate is not accepted in any way (for example; non-compliance of available information in certificate with requested information), subscriber should declare it to certificate authority in the way that is mentioned in agreement, and the certificate should be revoked by certificate authority.
After IR.GRCA issues certificate for an intermediate CA, it gives the certificate in the form of a CD to intermediate CA representative, and representative signs the certificate acceptance form. Only after representative receives the certificate, IR.GRCA publishes the certificate in its repository.

4.4.2. Publication of the certificate by the CA

 

Certificate authority should publish issued and received certificates in its repository.

4.4.3 Notification of certificate issuance by the CA to other entities

 

Registration authority may be notified of certificate issuance which it has approved and recorded its application.

4.5         Key pair and Certificate Usage

4.5.1. Subscriber private key and certificate usage

 

Using private key which is in accordance with public key is allowed just in the situations that subscriber accepts the usage conditions of certificate.
Subscriber should use certificate according to agreements between subscriber and certificate authority, digital certificate policies of IRAN’s public key infrastructure, and CPS of related intermediate CA. Certificate usage should not be inconsistent with KeyUsage extension of certificate extensions.
Subscriber should not use his private key in unauthorized applications. Moreover, he could not use the private key which is in accordance with a revoked certificate.

4.5.2. Relying party public key and certificate and usage

 

In a public key infrastructure through X.509 certificates, the specifications of an entity binds to its public key. One of the most important capabilities that a public key enabled  (PKE) application should support is the process of certificate path validation. Through this process, it can be understood that whether we can trust in a digital certificate for using it in special software or not. In other words, in this process the accuracy of relation between subscriber and his public key, is validated.
In a certificate path, each certificate is signed by certificate issuer, and this path continues from end entity certificate to the certificate belonging to IR.GRCA. For example; a certificate path may include user certificate, which is signed by its certificate authority (CA), CA certificate, which is signed by its root CA, and root CA certificate, which is signed by itself.
Root CA→CA→User
Relying parties should always pay attention to the proportionality of certificate usage with its defined usages, and also should ensure that certificate is not used in unhallowed ways, which are specified by CP and CPS of intermediate CA. They should consider below options, before trusting a certificate:
  • The availability or unavailability of certificate belonging certificate authority in certificate path, should be checked (name chaining);
  • The signatures of all certificates available in certificate path should be verified (signature chaining);
  • The proportionality of certificate usage with its defined usages in certificate extensions (such as KeyUsage extension) should be considered (for example; if digital signature usage is not activated for certificate, this certificate should not be used to testify digital signature of subscriber);
  • The status (revocation or non-revocation) of subscriber’s certificate and all certificates belonging to certificate authorities of certificate path should be checked. If each of certificates of certificate path is revoked, relying party exclusively is responsible to trust in subscriber’s certificate and the testified signature of this signature.
  • The validity of all CRLs which are related to certificate path should be checked.
Assuming that a certificate is used in a suitable way, relying parties should use proper software or hardware to signature verification, certificate path validation or other cryptography operations dependent to public key. This operation is one of the conditions of trusting to certificate, which includes identification of a certificate path and verifying the signature in certificate path. All public key enabled applications (PKE applications), should be approved by IR.GRCA, and should be tested and validated in PKI laboratory of IR.GRCA.

4.6         Certificate Renewal

 

Certificate renewal means producing a new certificate, similar to previous one; the only difference is in validity time and serial number.

4.6.1. Circumstances for certificate renewal

 

Certificate renewal is possible in the condition that its expiring time is not reached, and certificate is not revoked.

4.6.2. Who may request renewal

 

In IRAN’s public key infrastructure, certificate renewal applicant may include:
  • Subscriber or his legal representative can request certificate renewal.
  • Registration authorities (the process of certificate renewal should be mentioned in CPS of intermediate CA).

4.6.3. Processing certificate renewal requests

 

The process of checking certificate renewal requests is according to section 3.3.1.

4.6.4. Notification of new certificate issuance to subscriber

 

The process of notifying a subscriber that his certificate is issued is according to section 4.3.2.

4.6.5. Conduct constituting acceptance of a renewal certificate

 

The process of acceptance of a renewed certificate is according to section 4.4.1.

4.6.6. Publication of the renewal certificate by CA

 

The new issued certificates that their validity time is renewed, and are acceptance by subscriber, should be published through repository.

4.6.7. Notification of certificate issuance by the CA to other entities

 

Registration authority may be notified of certificate issuance which it has approved and recorded its request.

4.7         Certificate Re-Key

 

Certificate re-key means producing a new certificate similar to previous one, except in is that new certificate has a new and different public key (in accordance with a new private key), and a different serial number and validity time.

4.7.1. Circumstances for certificate re-key

 

Subscriber should perform certificate re-key operation, before the certificate expiration time reaches, in this way the continuity of using certificate usages is maintained. If one of the following occurs, a certificate re-key may be done:
  • The certificate validity time is being finished, and extending its time is not possible;
  • The private key corresponding to certificate is at disclosure risk.
Presenting re-key services in intermediate CAs, is dependent to facilities of intermediate CA, and presenting these services should be mentioned in their CPS.
For performing re-key of end entity certificate, the previous certificate should be revoked. If re-key operation should be performed because key is at disclosure risk, previous certificate shall be revoked.

4.7.2. Who may request certification of a new public key

 

For organizational certificates, only subscriber or his representative can requests certificate re-key.

4.7.3.Processing certificate re-keying requests

 

The process of checking certificate re-key requests is according to section 3.3.1.

4.7.4. Notification of new certificate issuance by the CA to subscriber

 

The process of notifying subscriber that his new certificate is issued is according to section 4.3.2.

4.7.5.Conduct constituting acceptance of a re-keyed certificate

 

This process is according to section 4.4.1.

4.7.6. Publication of the re-keyed certificate by the CA

 

New certificates which their public key is renewed, and are accepted by subscriber, should be published through repository.

4.7.7. Notification of certificate issuance by the CA to other entities

 

Registration authority may be informed of certificate issuance which it has approved and registered its request.

4.8         Certificate modification

 

Not applicable at this time.

4.8.1. Circumstances for certificate modification

 

Not applicable at this time.

4.8.2. Who may request certificate modification

 

Not applicable at this time.

4.8.3. Processing certificate modification requests

 

Not applicable at this time.

4.8.4. Notification of new certificate issuance to subscriber

 

Not applicable at this time.

4.8.5. Conduct constituting acceptance of modified certificate

 

Not applicable at this time.

4.8.6. Publication of the modified certificate by the CA

 

Not applicable at this time.

4.8.7. Notification of certificate issuance by the CA to other entities

 

Not applicable at this time.

4.9         Certificate revocation and suspension

4.9.1. Circumstances for revocation

 

A certificate is revoked when the binding between subscriber’s specifications and public key is not valid.

4.9.1.1. The conditions of certificate revocation of intermediate CAs

 

If any of the following occurs, intermediate CA should request from IR.GRCA or its superior CA, to revoke its certificate:
  • Private key of intermediate CA is at disclosure risk;
  • There is no need to certificate any more. This may be because presented services by intermediate CA is finished, or its contract with its superior intermediate CA is finished.
If one of the following occurs, IR.GRCA or intermediate CA should revoke the certificate of its intermediate CA:
  • If the certificate of IR.GRCA or superior CA is revoked, then the certificates of all related intermediate CAs should be revoked too;
  • If intermediate CA or its related registration authority violates the rules, and this violation is approved by council;
  • If it is confirmed that certificate is issued based on unreal information (intentional or unintentional);
  • Revocation request by competent judicial authorities;
  • If IRAN Government root or superior CA terminate its activities.
At the moment of rupture of intermediate CA operation, and when the operation of this CA is stopped by court decree or because of other reasons, IR.GRCA should publish CRL according to method mentioned in 9th paragraph of article 5 from paragraph (a) of article 4 from executive regulation of article 32 of e-commerce law. Also it should publish new CRL in Iranian Official Gazette. The responsibility of damage compensation resulting from certificate revocation of intermediate CA should be mentioned in CPS or in agreement between intermediate CA and subscriber.

4.9.1.2. Conditions of certificate revocation of end entity

 

If any of the following occurs, subscriber of his representative should request certificate revocation from intermediate CA:
  • Private key of subscriber is at disclosure risk;
  • Information available in certificate is changed in any way (such as subscriber specifications);
  • There is no need to certificate anymore; this is may be a result of stopping the operation of an organization or a person in an organization, or changing of organizational position of subscriber.
If any of the following occurs, certificate authority should revoke the certificate of subscriber without any need to his approval:
  • If private key of intermediate CA is used in an unauthorized way, in case of forgery or being at disclosure risk, or the certificate of IR.GRCA is revoked, all the certificates which have been signed by certificate authority should be revoked;
  • Certificate revocation request by competent judicial;
  • Violation of subscriber from his commitments;
  • Certificate authority is not active anymore;
  • If IR.GRCA is not active anymore;
  • Subscriber is dead.
All certificate authorities, in their agreement with subscribers, should force them, that if they were informed of private key disclosure risk, notify related CA as soon as possible, and proceed for certificate revocation.

4.9.2. Who can request revocation

4.9.2.1. End entities

 

Table 14: authorized entities to present certificate revocation request
Assurance level Authorized entities to present certificate revocation request
Level 1 There is no boundary.
Level 2 Certificate revocation request is presented by below individuals:
·      Subscriber;
·      Subscriber’s authorized representative (section 3.2.3);
·      Authorized representative of an organization for presenting organizational certificate revocation request of a personnel’s certificate;
·      Authorized representative of registration authority for certificate revocation;
·      competent judicial authorities.
Level 3
Level 4
 
 

4.9.2.2. Intermediate Certificate Authorities

 

Authorized entities to present certificate revocation request belonging to Intermediate CAs are as below:
  • Authorized representative of this CA for revocation the certificates of this CA;
  • competent judicial authorities;
  • Council;
  • IR.GRCA.
All the requests are applicable after being approved by the policy maker council.

4.9.3. Procedures for revocation request

 

Each certificate revocation request should be exclusively for one certificate, and it should describe revocation reason, and also it should be in accordance with section 3.4.
If certificate revocation request is valid, certificate authority should revoke the certificate, through placing its serial number in CRL. The requirements of handling certificate revocation request include:
  • Identification and authentication of certificate revocation request (according to section 3.4);
  • Recording and maintaining all information related to request;
  • Updating CRL and OCSP responder server after certificate revocation

4.9.4. Revocation request grace period

 

If certificate private key is at disclosure risk (for example; disclosure of cryptographic module password), certificate revocation request should be presented as soon as possible.

4.9.5.Time within which CA must process the revocation request

 

The maximum allowed time to process certificate revocation request by certificate authorities (especially in private key disclosure situation), is specified in below table. All intermediate CAs should specify the needed time for presenting confirmed certificate revocation request (by registration authority) to intermediate CA, in their CPS.
Table 15: Processing time of certificate revocation request by certificate authority
Assurance level Processing time of certificate revocation request by certificate authority
Level 1 There is no special obligation.
Level 2 ·         If revocation request is received in working hours, it should be processed in less than 2 hours.
·         If certificate revocation request is not received in working hours, it should be processed immidiately in the next working day.
·         If certificate revocation request is not received in working hours and the next day is holiday, process of certificate revocation should not last more than 24 hours.
Level 3 Certificate revocation should be processed in less than 1 hour.
Level 4 Certificate revocation should be processed immediately.
 

4.9.6. Revocation checking requirement for relying parties

 

Relying party should check the certificate status (revoked or non-revoked), before using it. If in special situations, access to certificate status information is not possible; the responsibility of trusting to certificate is on relying party. The requirements of revocation checking by relying parties, is mentioned below.
  • In validation process of certificate path, the status of all certificates available in path should be checked, through CRL or OCSP protocol.
  • The accuracy and integrity of CRL should be checked.
  • For level 4, certificate revocation information should not be cached for next time uses.
Certificate authorities should inform relying party about the CRL distribution point, and access point of OCSP responder server, in order to check the status of certificate.

4.9.7. CRL issuance frequency

 

CRL is issued periodically and sent to repository to confirm information (even if there is no change or update in it). If in special situations, intermediate CA performs CRL update sooner; these special situations should be mentioned in CPS. Intermediate CA should ensure that previous CRL is removed from repository before publication of the newest version.
IR.GRCA issues and publishes a CRL per 6 months. The requirements of CRL issuance frequency by intermediate CAs is mentioned in below table.
Table 16: frequency of CRL issuance
Assurance level frequency of certificate revocation issuance
Level 1 ·         Updated CRL version should be issued per 30 days at minimum
·         If the reason of revoking a certificate is private key disclosure, maximum 1 day after receiving and processing of certificate revocation request, an updated version of CRL should be issued.
Level 2 ·         Updated CRL version should be issued per 24 hours at minimum.
·         An updated version of CRL should be issued immediately after receiving and processing of certificate revocation request.
Level 3 ·         Updated CRL version should be issued per 12 hours at minimum.
·         An updated version of CRL should be issued immediately after receiving and processing of certificate revocation request.
Level 4 ·         Updated CRL version should be issued per 4 hours at minimum.
·         An updated version of CRL should be issued immediately after receiving and processing of certificate revocation request.
 
 

4.9.8. Maximum latency for CRLs

 

Normally, CRL should be automatically and immediately published in repository, after the certificate is revoked; unless, the maximum allowed delay between certificate revocation and publishing CRL in repository, is 2 hours.

4.9.9. On-line revocation/status checking availability

 

Certificate authorities (if supporting OCSP protocol) should provide access to a OCSP responder based on web, for relying parties; so that they can refer to OCSP responder in order to obtain information about certificate status or other details. If clients’ software uses OCSP protocol to obtain information about certificate revocation status, this software does not need to receive CRL and process it to control certificate revocation status.

4.9.10. On-line revocation checking requirements

 

Relying party should check certificate status, before using it. All certificate authorities and PKE software, if supporting OCSP protocol, should also support CRL, in order to ensure permanent access to status protocol service. If clients’ software uses OCSP protocol to obtain information about certificate revocation status, this software does not need to receive CRL and process it to control certificate revocation status.

4.9.11. Other forms of revocation advertisements available

 

If a CA uses a method rather than OCSP and CRL for certificate status protocol, it should mention this method in its CPS.

4.9.12. Special Requirements in re key compromise

 

In key disclosure times, certificate authority should publish updated CRL according to section 4.9.7, after it revoked the certificate, and OCSP responder client should be provided according to section 4.9.9.

4.9.13.Circumstances for Suspension

 

According to certificate policies of IRAN public key infrastructure, for now certificate suspension is not possible in IRAN public key infrastructure.

4.9.14. Who can request suspension

 

It is not defined.

4.9.15. Procedures for suspension request

 

It is not defined.

4.9.16. Limits on suspension period

 

How long the suspension may last
It is not defined.

4.10   Certificate status services

 

Certificate authorities should declare and publish certificate status through CRL.

4.10.1. Operational characteristics

 

The latest updated version of CRL should be available to download through repository. Relying parties can use online certificate status protocol, through software which support producing and sending an OCSP request and validating an OCSP response according to RFC2560.
Functionality properties of CRL are mentioned in section 7.2, and functionality properties of online certificate status protocol is mentioned in section 7.3.

4.10.2. Service availability

 

Certificate status protocol service should be always available in certificate life time.

4.10.3. Optional features

 

Online certificate status protocol service (OCSP) is an optional feature in presenting certificate protocol services that can be used by software which support OCSP (according to RFC2560).

4.11   End of Subscription

 

Only if one of the following occurs, certificate authorities can terminate presenting certificate services to subscribers:
  • If certificate validation time is expired and no certificate renewal request is received;
  • If certificate is revoked and no re-key request or certificate renewal request is received.

4.12   Key escrow and recovery

 

Not applicable at this time.

4.12.1. Key escrow and recovery policy and practices

 

It is not defined.

4.12.2. Policies and practice statement of recovery and needed information to access to key

 

Not applicable.

5          Facility, equipment, management and Operational Controls

5.1         Physical Security Controls

 

Installations of certificate authority should have equipment which is specially designed for certificate authority activities.
Unauthorized use of certificate authority equipment is forbidden. Physical security controls should be run to protect software and hardware of this CA from unauthorized access, robbery and damage.

5.1.1. Site location and construction

 

Certificate and registration authorities operations should be done in a physically protected environment, so that is prevent any unauthorized use, access, and information disclosure. Therefore building site should be chosen based on security essentials. Such essentials are based on separation of security layers. Security layer means a locked door equipped with access control system.
Continuous security levels ordered by more limited access provide more physical security against unauthorized access. Each internal security layer surrounds the next internal layer, and each internal security layer should be totally inside the external security layer. External wall, floor and roof, are the most external layer. The minimum required security layer for CA is 3 to 4 layers dependent to CA building architecture.
Certificate authorities should explain the applied procedure in their building.

5.1.2. Physical access

 

Access to physical security layers should be able to be recorded, controlled and inspected, so that each security layer is available to authorized personnel.
Registration authority equipment should be protected against unauthorized access at the moment of activating of cryptography module.
Activation data which are used to access and activating cryptography modules and equipment, in certificate authorities, should be maintained safe when are not being used.
Each operator should perform and archive a security audit which includes below cases, in the shape of a control and operation form, before he leaves the site.
  • Equipment is in normal functionality status;
  • All the cases which contain security information are safe;
  • All physical security systems (locks, access control systems) are working well;
The above mentioned form should include performed operations report; and every change which is made by operator should be returned to its stable form.
Certificate authority site is protected by intrusion detection systems. Moreover, per 24 hours an audit should be done to ensure that no attack against security mechanisms has been performed.

5.1.3. Power and air conditioning

 

Power supply of electronic devices of CA and RA security equipment should be uninterrupted, so that continuous access to them is ensured. Moreover, this security equipment should be equipped to air conditioner to control temperature and moisture.

5.1.4. Preventing water penetration

 

CA equipment should be installed in a way that water cannot penetrate to them. For example; these equipment can be installed on tables, or in other high places. Moisture sensors should be installed in places that are suspicious to water penetration. Individuals, who are responsible for fire control devices in certificate authorities, should ensure that this equipment work properly.

5.1.5. Fire prevention and protection

 

Certificate authorities should perform required operations to prevent and protect against fire.
An instruction about fire damage recovery should be added to damage recovery plan of certificate authority.

5.1.6. Media storage protection

 

Storage media should be protected against water, fire, electromagnetic, and other environmental factors.
Certificate and registration authorities should use security operations to detect and prevent unauthorized access, or disclosure of storage media. Medias containing security audit information, archives or backup information should be maintained in a place separate from CA equipment.

5.1.7. Waste disposal

 

All the devices containing important information (which are not used anymore), should be destructed in a way that they cannot be recovered. Personnel of certificate authorities should mention the reason of information destruction.

5.1.8. Off-site backup

 

Backup copies which are provided to recover the damages and contain important information should be created according to section 5.5.2, and a backup copy should be kept outside of certificate authority site. Backup copy should be kept in a place with physical controls.
Certificate authorities should ensure that backup site, is similar with CA site in security elements.

5.2         Procedural Controls

5.2.1. Trusted roles

 

All the activities of certificate authorities are done in the form of drafted responsibilities for defined roles, which are assigned to personnel. Individuals who are selected for these roles should be reliable, as it is mentioned in section 5.3. To increase security, performing the activities of certificate authority needs the presence of more than one reliable role. It prevents destructive activities which need collusion.
Intermediate CA should define reliable roles which are responsible for performing below operations in its CPS, and also it should define each role’s duties as well:
  • Certificate issue and management;
  • Publication of certificates and CRL;
  • Creating backup copy;
  • Performing activities such as key generation, management of cryptography modules, and control operations;
  • Match audit;
  • Software development (if required);
Executive operations in registration authority:
  • Applicant authentication and information accuracy confirmation;
  • Final request approving;
  • Sending requests to certificate authorities and receiving result in a safe way;
  • Delivering certificate to subscriber;
Common executive operations in certificate authorities and registration authorities:
  • Installation, running and primary configuration of system;
  • Internal audit;
  • System and equipment technical support;
  • Safe information archiving;
  • Damage recovery in accordance with continues services plan (section 5.7.4).

5.2.2.  Nnumber of persons required per task

 

Table 17: the number of required individuals for each role
Assurance level the number of required individuals for each role
Level 1 Is done by 1 person at minimum.
Level 2 For performing roles which doing their duties requires access to important information of certificate authority (such as private key), 2 persons are required at minimum. For performing duties of other roles, 1 person is enough.
Level 3
Level 4
 
 

5.2.3. Identification and authentication for each role

 

Before each of CA personnel is assigned in below positions, their identity should be authenticated:
·         To be assigned in the list of access to CA site
·         To be assigned in the list of physical access to CA site;
·         To be assigned for a reliable role in certificate authority or registration authority;
·         To create user account in systems related to public key infrastructure, if user account is required.
·         This user account should:
a.    Be assignable only to one person directly;
b.   Not be communal;
c.    Be limited authorized activities of that role through using CA software, and operating system.
Certificate authority should run these requirements through using CA software, and operating system.

5.2.4. Roles which their duties need to be separated

 

Certificate authority should mention separation of duties for critical duties, in its CPS according to section 5.2.1.

5.3         Personnel Controls

 

Activities that certificate authority assigns to personnel should not be inconsistence with their defined duties. Moreover personnel should:
  1. Sign written commitment for following laws;
  2. Be engaged to conditions and laws of their assigned position through contract;
  3. Be obliged not to reveal security information or user information according to contract;
  4. Be trained about their duties;

5.3.1. Qualifications, experience and clearances requirements

 

Personnel, who are assigned for certificate authorities, should be selected according to technical capability, reliability, and trusteeship. Moreover, all personnel should be originally Iranian and also should have judicial penal records from police department of IRAN.
Personnel who are assigned to work with certificate authority equipment should have following characteristics:
  • They have passed a training course successfully;
  • They have proved their abilities for doing assigned duties;
  • They are reliable;
  • They have no other job which interferes with their duties;
  • They present performance guarantee certificate (if they have related job experience)
  • They do not have judicial penal records;
  • They do not have criminal conviction;

5.3.2. Background checks procedures

 

This process should be done according to IRAN’s law. The procedures of checking individual’s job experience should be mentioned in CPS of CA.
IR.GRCA reviews the employees’ job experiences, according to government employment rules.

5.3.3. Training requirements

 

All the CA employees should be trained for what they do. They should also pass these training programs periodically. The subjects of these training programs should be: security issues and CA structure introduction, working with related software and hardware, event reporting and handling, damage recovery processes, applying required security operations, and required information for applying digital certificate policies of public key infrastructure. Special trainings are dependent to applied equipment and selected employees. There should be provided a training plan for establishing CA, and passed training programs should be documented by employees.

5.3.4. Retraining frequency and requirements

 

Certificate authorities should provide new training programs minimum 1 time per year, to ensure that the employees have required abilities to do their responsibilities. Making any change in CA operation, needs a training program.

5.3.5. Job rotation frequency and sequence

 

It is not defined.

5.3.6. Sanctions for unauthorized actions

 

If any employee performs an unauthorized task or he is suspected to do so, the manager can suspend his access to system.

5.3.7. Independent contractor requirements

 

Certificate authority should specify contract signing steps, to ensure that all contract parties are acting according to policies and CPS of CA.

5.3.8. Documentation supplied to personnel

 

Certificate authority should provide enough documents to define the services and duties of each role, so that employees do their responsibilities as well as possible.

5.4         Audit Logging Procedures

 

This section explains the requirements of security audit for certificate authorities.

5.4.1. Types of events recorded

 

Certificate authority should ensure that it has the capacity of recording all events relating to CA security -such as firewalls, directory and hosted clients of RA and CA software- in its audit events record file. Security events record option should be automatically activated in CA operating systems.
The following events should be recorded in CA or RA systems:
  • System turns off/on;
  • Logon and logout to RA and CA applications;
  • Any affairs about generating, removing or changing the system password;
  • Defining, removing, or adding user or roles;
  • Making any change in CA details or keys;
  • Making any change in settings;
  • Any logon/ logout to RA and CA applications;
  • Any unauthorized affair toward access to RA or CA systems;
  • Any affair toward not authenticating the identity to access to system files;
  • Making change in system configuration;
  • Database backup or recovery;
  • Production or backup of CA keys or other keys;
  • Issue, revoke, renew, and update certificate keys;
  • Signing the CRL;
  • Producing and sending approved requests in RA;
  • Performing authentication process of private key owner, according to section 3.2.1;
  • Sending any data to repository;
  • Unsuccessful reading and writing operation in certificate repository and CRL;
  • Occurred error in system and their occurrence conditions.
All registered cases, electronically and manual should include event date and time.
Certificate authority should manually or electronically collects security information which is not produced by CA. This information includes:
  • Events relating to physical access;
  • Changes relating to system configuration, as defined in CPS;
  • Changes relating to CA personnel;
  • Reports relating to agreements and disagreements;
  • Reports relating to losing important information;
  • Previous and current versions of digital certificate policies;
  • Reports relating to vulnerability evaluation;
  • Reports relating to risks and threats evaluation;
  • Equipment damage;
  • Time and period of power cut off;
  • Reports relating to certificate issue;
  • Reports relating to audit acceptance;
  • Previous and current versions of user agreements and other information that user has accepted it;
  • CA personnel assignment;
  • CA personnel training.
CA should specify different types of considerable events in its CPS, and should declare information relating to recorded events to ensure integrity.

5.4.2. Frequency of processing log

 

Certificate authority should ensure that important events are explained in audit events abstract, and CA personnel should review events for each assurance level according to following table.
This review includes reviewing recorded events to ensure that they are not modified and also inspecting all incomes. Wherever a warning is seen, CA personnel should perform a more comprehensive research. Certificate authority should specify the person who is responsible for performing audit events review and performing audit events abstract, in CPS.
If there is any suspicious case, certificate authority should review events (including RA side events) electronically or manually.
Certificate authority should to document any activities which are done in these reviews.
Table 18: frequency processing log
Assurance level frequency of recorded information processing
Level 1 Processing and checking events is done per 6 months.
Level 2 Processing and checking events is done per 2 months.
Level 3 Processing and checking events is done per month.
Level 4
 

5.4.3. Retention period for audit log

 

Certificate authority should maintain recorded information 2 months at minimum, and this information should be kept and protected according to section 5.5.2.

5.4.4. Protection of audit log

 

Certificate authority should protect recorded information by use of an electronically device. Recorded events information should be protected against unauthorized individuals. Unauthorized persons should not be able to modify, remove, or damage information, before maintenance period is expired. The person who is in charge for archiving information should not be able to change them either. Recorded events information should not be kept in CA. Certificate authority should explain the mechanisms which are used to protect recorded events information, in its CPS.

5.4.5. Audit log backup procedures

 

Creating backup copy from recorded events information should be done per month.

5.4.6. Audit collection system

 

Event record process should be activated at the moment of system turn on and should be stopped at the moment of system turn off. If it is specified that event record system is stopped and system integrity is at risk, CA should stop all of its activities except certificate revocation. In such situations, certificate authority should use mechanisms to prevent continuous of unauthorized activities. These mechanisms should be explained in CPS of digital certificate.

5.4.7. Notification to event-causing subject

 

Since events are recorded by system, it is not needed to inform individuals, organization.

5.4.8. Vulnerability assessments

 

Certificate authority personnel should be aware of activities which are done to interrupt system integrity. Inspector should check recorded security events information for events such as repetitive unsuccessful activities to access system, try to obtain private information and try to access system files and unapproved responses. The abstract of security audit review results, should be recorded.

5.5         Records Archival

5.5.1. Types of records archived

 

Following information about certificate authority and registration authority should be archived:
  • All recorded events according to section 5.4;
  • Processed requests by RA (issue, revoke, update certificate and key renewal);
  • Certificate signing request files (CSR);
  • All issued certificates and produced CRL by CA;
  • Certificate status;
  • Date and reason of revoked certificates;
  • Agreements between subscriber or applicant and certificate authority;
  • Contracts or agreements signed between certificate authority and registration authority;
  • Documents related to authentication of certificate applicant, according to section 3.2.3;
  • Documents related to certificate reception, according to section 4.4;
  • All reports relating to internal audit;
  • Practice statements and policies of certificate;
  • Any agreement that certificate authority is banned to;
  • System equipment configuration;
  • Backup of management and issuance systems of digital certificate database;
  • All correspondences with council, other CAs and event record inspectors.

5.5.2. Retention period for archive

 

Registered information in CA archive for each assurance level should be maintained according to following table.
Table 19: retention period for archive
Assurance level Maintenance period of archived information
Level 1 Registered information should be maintained 5 years at minimum in archive
Level 2 Registered information should be maintained 16 years at minimum in archive
Level 3 Registered information should be maintained 24 years at minimum in archive
Level 4 Registered information should be maintained 30 years at minimum in archive
 

5.5.3. Protection of archive

 

Archived information should be protected in a way that only authorized individuals can access it. Achieved Information should be saved in a safe system, so that unauthorized individuals can not remove or change it. Hardware storage of an archive and software which processes information should be protected in a way that in retention period, access to information is possible.

5.5.4. Archive Backup Procedures

 

Table 20: archive backup procedures
Assurance level Archive backup processes
Level 1 There is no obligation.
Level 2 A complete archive backup should be created monthly.
Level 3
Level 4

5.5.5. Requirements for time-stamping of records

 

Certificates, CRL and all information relating to certificate revocation, should include registration date and time. All forms and documents should include date as well.

5.5.6. Archive collection system (internal or external)

 

Archive information can be collected using different methods. Certificate authorities should describe archive collecting system in their CPS.

5.5.7. Procedures to obtain and verify archive information

 

Table 21: procedures to obtain and verify archive information
Assurance level Procedures to obtain and verify archive information
Level 1 There is no obligation.
Level 2 ·      Only authorized reliable persons can access archived information
·      The integrity of archived information should be checked per 6 months. The integrity of paper copies should be checked annually.
·      CA should specify the process according to which the integrity of information is checked, in its CPS.
Level 3
Level 4

5.6         Key Changeover

 

Certificate authorities use private key to sign certificates. Since relying parties use CA certificate to evaluate subscriber’s certificate, subscriber’s certificate cannot have a longer validity period than CA certificate and its public keys validity period.
Certificate authorities can renew signature private key in a specific period, to minimize the risk of public key infrastructure (CA key disclosure risk). In this situation, the previous private key should be protected until all certificates which are signed by it are expired. Certificate relating to CA previous key will be valid until all certificates which are signed by it are expired. The processes of doing so should be explained in CPS of CA.
If there is any need to key renewal, IR.GRCA composes its new key by mixing the previous key certificate values, and it publishes new certificate through repository. Previous certificate is valid and available on repository, until underside intermediate CA certificate is revoked. CA should specify following elements in its CPS:
  1. Time period before certificate is revoked, in which it is possible to renew private key of subscriber.
  2. Processes of key renewal by CA and subscribers.

5.7         Compromise and Disaster Recovery

5.7.1. Incident and compromise handling procedures

 

If it is understood that any attempt is done to hack certificate authority, or information is at disclosure risk in any other secret ways, these attempts should be checked, so that we can specify the type and level of damage. If possibility of key disclosure exists, the processes which are explained in section 5.7.3 should be performed, unless the domain of received damage should be checked to realize that if certificate authority should be reconstructed, or only some of certificates should be revoked.
If OCSP responder key is at disclosure risk, the certificate authority, which has issued certificate for OCSP responder, should revoke its certificate, and also publish its information in repository. Then, OCSP should receive a new key.

5.7.2. Computing resources, software, and/or data are corrupted

 

Certificate authority should make backups from databases, and private keys, to recover them in software damage or data losing situations. If systems or data are lost, certificate authority should start systems and data recovery after informing IR.GRCA according to section 5.7.4.

5.7.3. Entity private key compromise procedures

 

If a certificate authority is at disclosure risk, overhead certificate authority should revoke its certificate and publishes revoked information in repository. Then, as mentioned in section 5.7.4, certificate authority systems should be reconstructed. Self-signed certificate of IR.GRCA should be picked up of utility applications of relying parties, and should be replaced by new certificate which is published by this CA.

5.7.4. Business continuity capabilities after a disaster

 

Certificate authority should have a work continuity plan, in which there is a safe method to run activities again, if any natural event happens.
Work continuity plan should include following elements:
  • Definition of roles and responsibilities of individuals who are in charge for running different components of this plan;
  • Conditions of plan activation, it explains the process which should be performed before activation of plan;
  • Action method in urgent situations which damage human life or work;
  • Resuming method, which explains required activities to get back to normal work;
  • Repair and maintenance program, which specifies the method and time of plan test and also plan maintenance process;
  • Training and awareness activities, which are designed to realize work continuity processes and also to ensure that processes are effective.

5.8         CA or RA Termination

 

If operations of intermediate CA stop or considerable changes happen in its operations, it should inform IR.GRCA and all the entities for which certificates are issued.
Right after termination of intermediate CA activities, all available private keys or private keys which might be used for intermediate CA cryptography operation, should be revoked and destroyed according to section 6.2.10. CRL should be produced and published. The process of intermediate CA activity termination is as follow:
  • Informing IR.GRCA and debating it in council, 4 months before CA activity termination;
  • Informing relating entities, including subscribers, relying parties, registration authorities, and customers;
  • Intermediate CA certificate revocation, by overhead certificate authority,
  • Maintaining and presenting intermediate CA archive for a specific period to a reliable source (which is specified by council), by this document,
At the moment of intermediate CA activity termination, intermediate CA should maintain CA information by a reliable trustee which is specified by council, in these certificate policies. This information includes:
  • Intermediate CA certificates;
  • Issued certificates;
  • CRL;
  • Security audit information according to section 5.4;
  • Other archived information as mentioned in section 5.5.
Intermediate CA for maintaining any data (such as password) should ensure that intermediate CA information is usable (such as encrypted data that can be decoded when needed). Information should be transferred safely and according to section 5.1.8.

6          Technical Security Controls

6.1         Key pair generation and installation

6.1.1. Key pair generation

6.1.1.1. Key pair generation for certificate authorities

 

IR.GRCA supports RSA algorithm of key pair, to issue certificate. Key generation in this CA is done through a HSM which is approved and evaluated by IR.GRCA (in which security requirements are observed according to FIPS 140-2 in 3rd level and in 3 out of 5 multi-person control mechanism). Requirements relating to key generation for intermediate CA are mentioned in below table.
Table 22: Key pair generation for intermediate CA
Assurance level Key pair generation of intermediate CA
Level 1 Intermediate CA should ensure Key pair generation is done by algorithms which are approved in IRAN’s public key infrastructure, and by a trusted and authorized role.
Level 2 ·      Key pair generation of intermediate CA:
·      Should be done by operators with trusted and authorized role to produce key.
·      Should be done inside hardware cryptographic module according to section 6.2.1 requirements.
·      Should be done by using algorithms which are approved in IRAN’s public key infrastructure.
·      Should be done by key generation operation through multi-person control according to section 6.2.2 in 3rd and 4th level.
·      Intermediate CAs should document key generation and present needed documents to prove that documentation processes are done.
Level 3
Level 4
 
 

6.1.1.2. Key pair generation for registration authority

 

Table 23: Key pair generation for registration authority
Assurance level Key pair generation of registration authority
Level 1 Intermediate CA should ensure that RA key generation is done by using algorithms which are approved in IRAN’s public key infrastructure.
Level 2 Should be done inside hardware cryptographic module according to section 6.2.1 requirements, and also should by using algorithms which are approved in IRAN’s public key infrastructure.
Level 3
Level 4
 

6.1.1.3. Key pair generation for subscriber

 

Table 24: key generation for subscriber
Assurance level Key pair generation for subscriber
Level 1 ·      Key pair generation for subscribers should be done by using algorithms which are approved in IRAN’s public key infrastructure.
Level 2 ·      Key pair generation for subscriber should be done inside hardware cryptographic module according to section 6.2.1 requirements (software key generation can be done just by subscriber).
·      Key pair generation for subscribers should be done by using algorithms which are approved in IRAN’s public key infrastructure.
Level 3 ·      Key pair generation for subscriber should be done inside hardware cryptographic module according to section 6.2.1 requirements.
·      Key pair generation for subscribers should be done by using algorithms which are approved in IRAN’s public key infrastructure.
Level 4
 
 
It should be mentioned that, if intermediate CA (as representative of applicant) produces key pair, this issue should be described in agreement between these two parties. Intermediate CA should explain this process in its CPS.

6.1.2. Private key delivery to subscriber

 

Table 25: private key delivery to subscriber
Assurance level Delivering private key to end entity
Level 1 There is no obligation.
Level 2 If key generation is done by RA or CA (as representative of subscriber), this operation should be internally approved by a reliable cryptographic hardware (according to section 6.1.1), and private key should be delivered to subscriber through this hardware.
The software generates a key pair should only be done by the subscriber and public key corresponding to the Intermediate CA or RA must be accompanied by a proof of ownership's private key.
Level 3 If key generation is done by RA or CA (as representative of subscriber), this operation should be internally approved by a reliable cryptographic hardware (according to section 6.1.1), and private key should be delivered to subscriber through this hardware.
Level 4

6.1.3. Public key delivery to certificate issuer

 

If key generation is done by subscriber or registration authority, delivering public key to certificate authority should be done in a way that correspondence of presented public key and private key of subscriber, and also its integrity, can be checked by certificate authority.
All intermediate CAs should deliver their public key to IR.GRCA in PKCS#10 standards, for presenting certificate issuance request to this CA.

6.1.4. CA public key delivery to relying parties

 

IR.GRCA deliver its public key to relying parties through its repository which only authorized roles of IR can access to it or make changes in it. Requirements relating to intermediate CAs are mentioned it following table:
 
Table 26: CA public key delivery to relying parties
Assurance level Delivering intermediate CA public key to relying parties
Level 1 There is no obligation.
Level 2 Intermediate CA public key should be delivered to relying parties in a safe mode, so that, its accuracy and validity is guaranteed. The method of delivering public key should be explained in CPS of intermediate CA.
Level 3
Level 4
 

6.1.5. Key sizes

 

IR.GRCA uses RSA 2048 bit key length for G2 hierarchical model and RSA 4096 bit key length for G3 hierarchical model. G2 and G3 structures are introduced in section 7.1.3. Requirements relating to key length for subordinate CAs are mentioned in below table.
Table 27: key sizes requirements
Assurance level Key sizes requirements
Level 1 The minimum key length for intermediate CAs is RSA 2048 bit and minimum key length for end entities is RSA 1024 bit.
Level 2
Level 3 The minimum key length for intermediate CAs and end entities is RSA 2048 bit.
Level 4
 

6.1.6. Public key parameters generation and quality checking

 

It is not defined yet.

6.1.7. Key usage purposes (as per X.509 v3 key usage field)

 

Table 28: key usage
Assurance level Key usages
Level 1 There is no obligation.
Level 2 Private key of certificate should be used just in usages defined in ExtendedKeyUsage and KeyUsage fields of certificate. Defined usages for digital certificate are described in section 1.4.1. KeyUsage extension should be in accordance with comprehensive document of IRAN’s PKI profiles.
Level 3
Level 4
 

6.2         Private Key protection and Cryptographic Modules Engineering Controls

6.2.1. Cryptographic module standards and controls

 

In all cryptographic modules which are used in IRAN’s PKI (for example; smart cards and HSM), the following requirements of IR.GRCA should be evaluated and approved:
  • Security requirements (FIPS 140 standard)
  • Functionality requirements (PKCS#11 standard)
  • Performance requirements
CA private key is maintained in a safe hardware system (HSM), in which the standards of 3rd level are evaluated. Key generation for IR.GRCA and signing issued certificates is done through this HSM in on-board mode.
The requirements relating to controls and standards of cryptographic modules in IRAN’s PKI is mentioned in following table.
Table 29: requirements of cryptographic modules
Assurance level The last standard FIPS 140 series Certificate authorities Registration authorities Subscribers
Level 1 Not required The minimum requirements of 2nd level of FIPS 140 should be applied The minimum requirements of 1st level of FIPS 140 should be applied Not required
Level 2 Not required The minimum requirements of 3rd  level of FIPS 140 should be applied The minimum requirements of 2nd level of FIPS 140 should be applied The minimum requirements of 1st and 2nd level of FIPS 140 should be applied
Level 3 Not required The minimum requirements of 3rd  level of FIPS 140 should be applied The minimum requirements of 2nd level of FIPS 140 should be applied The minimum requirements of 2nd level of FIPS 140 should be applied
Level 4 Not required The minimum requirements of 3rd  level of FIPS 140 should be applied The minimum requirements of 3rd  level of FIPS 140 should be applied The minimum requirements of 3rd  level of FIPS 140 should be applied
 

6.2.2. Private key (n out of m) multi-person control

 

In IR.GRCA, key generation and key life time management operations are done through 3 out of 5 multi-person controls via HSM. Requirements relating to multi-person control for subordinate CAs are mentioned in below table.
Table 30: multi-person control to private key
Assurance level Multi-person control to private key
Level 1 It is not required.
Level 2
Level 3 For intermediate CA private key generation and usage, there should be a multi-person control through at least two authorized roles.
Level 4
 

6.2.3. Private key escrow

 

Not applicable.

6.2.4. Private key backup

 

IR.GRCA creates a backup copy of its private key using multi-person control, and keeps it in a safe place for using it in backup site of IR.GRCA. Requirements of creating backup of intermediate CA private key are mentioned in below table.
Table 31: private key backup
Assurance level Creating backup copy of private key
Level 1 There is no obligation
Level 2 Intermediate CA should create backup copy of its private key to making a copy of private key and transferring it to backup module according to sections 6.2.6 and 6.2.7.
Level 3
Level 4
 
­
Intermediate CAs should explain private key backup procedures in its CPS.

6.2.5. Private key archival

 

It cannot be applied.

6.2.6. Private key transfer into or from a cryptographic module

 

Table 32: transferring private key into/ from a cryptographic module
Assurance level transferring private key to/ from a cryptographic module
Level 1 It is not defined.
Level 2 Certificate authorities should create their private keys by safe cryptographic modules and maintain them in these modules. When creating backup copy from private key, this key should be transferred into module in encrypted, and it should be maintained in backup site of certificate authority.
Level 3
Level 4
 

6.2.7. Private key storage on cryptographic module

 

Private Key storing should be done in a cryptographic module according to mentioned requirements in section 6.2.1.

6.2.8. Method of activating private key

 

Table 33: Method of activating private key
Assurance level Method of activating private key
Level 1 It can be done through password.
Level 2 Some method such as password use, required data for multi-person control, biometric information and other authentication methods can be used to activate private key in cryptographic device. Activation data should be delivered to subscriber in the way that is explained in CPS of intermediate CA (if private key is delivered to subscriber by RA or CA, subscriber should be informed to change cryptographic hardware password as soon as possible).
There should not be any disclosure risk when entering activation data (For example activation data should not be shown on monitor screen when user enters it).
Level 3
Level 4

6.2.9. Method of deactivating private key

Table 34: Method of deactivating private key

 

Assurance level Method of deactivating private key
Level 1 It is not defined.
Level 2 Cryptographic modules should not be remained unused in active mode. After using modules, they should be deactivated, for example; system logout manual method or connection cut off after a specific time.
When private keys are deactive, they should be removed from storage after releasing storage, and they should be maintained in encrypted format.
Level 3
Level 4
 

6.2.10. Method of destroying private key

 

Table 35: Method of destroying private key
assurance level Method of destroying private key
Level 1 It is not defined.
Level 2 When there is no need to private keys, or when their relating certificate is expired of revoked, private keys should be destroyed.
For software cryptographic modules, this can be done by overwriting on previous information. For hardware cryptographic modules, this is done by running zeroize command which should be integrated to storage overwriting operation.
Level 3
Level 4
 

6.2.11. Cryptographic Module Rating

 

Refer to section 6.2.1.

6.3         Other Aspects of Key Pair Management

6.3.1. Public key archival

 

Certificate authorities should archive public keys of their certificates and also public keys of issued certificates, according to section 5.5.2.

6.3.2. Certificate operational periods and key pair usage periods

 

Validity life time of certificate of IR.GRCA is 20 years. Requirements of validity life time of intermediate CA certificates and issued certificates by them are mentioned in below table.
Table 36: Certificate operational periods and key pair usage periods
Assurance level   Intermediate CA End entity
Level 1 Key length 2048 1024 2048
Maximum validity time 12 years 3 years 8 years
Level 2 Key length 2048 1024 2048
Maximum validity time 12 years 2 years 8 years
Level 3 Key length 2048 2048 -
Maximum validity time 12 years 8 years -
Level 4 Key length 2048 2048 -
Maximum validity time 12 years 8 years -
 

6.4         Activation Data

6.4.1. Activation data generation and installation

 

All activation data should be unique and unpredictable. Password for activating private key should include at least 8 characters, and should be produced by random (if possible). If generating password by random is not possible by subscriber, password should not be predictable. Activation data should not be similar to meaningful words.
If random passwords are used as activation data, it should be according to requirements of random number generators.

6.4.2. Activation data protection

 

Table 37: Activation data protection
Assurance level Activation data protection
Level 1 It is not defined.
Level 2 Activation data should be kept in mind and should not be written on papers. If it is written on paper, this paper should be kept in high security level. Private key activation data should be only available to subscribers.
Level 3
Level 4
 

6.4.3. Other aspects of activation data

 

It is not defined.

6.5         Computer security controls

6.5.1. Specific computer security technical requirements

 

Certificate authorities should activate below requirements in their operating systems:
  • System logon just after a unified authentication;
  • Creating controlled access to information and applications according to defined identity in system;
  • The ability to set and establish event recording system and checking it;
Certificate authorities should be equipped by antivirus systems with following specifications:
  • Possibility to be updated to the latest virus definitions;
  • Possibility to search in all systematic and unsystematic files automatically;
  • Event recording related to system scan and possible viruses.

6.5.2. Computer security rating

 

Table 38: computer security rating
Assurance level Computer security rating
Level 1 There is no obligation.
Level 2 A reliable third party laboratory should evaluate the security of essential elements of certificate authority.
Level 3
Level 4
 

6.6         Life Cycle Technical Controls

6.6.1. System development controls

 

Certificate authorities should use certificate issuance software which is designed under a development method.
Certificate authorities should use certificate issuance and management systems which are approved by IR.GRCA.
Certificate authorities can develop their software and hardware systems, only after informing IR.GRCA, and approval of this CA.
Purchased hardware or software should be in a sealed package, and should be installed by trained personnel.

6.6.2. Security management controls

 

CA hardware and software should be specially used for certificate authorities. CA systems should not include applications, hardware or network connections which are not related to certificate authorities. The security of CA hardware and software systems should be evaluated in IR.GRCA laboratory.
Certificate authority should mention policies and processes which prevents destructive software in CA equipment, in their CPS. CA systems should be scanned periodically for detecting destructive codes.
Certificate authorities should use a configuration management process for installing and continuous maintaining of CA systems. When for the first time CA software is installed on system, it should provide a method for certificate authority that approves the software on system:
1)      Is rooted from software developer;
2)      Is not changed before installation;
3)      Is the selected version to use.
Certificate authority should provide a mechanism for periodically checking of database integrity of certificate authority. Certificate authority should also have mechanisms and policies to control and observe the system configuration of certificate authority. All these mechanisms should be mentioned in CPS of CA.
Table 39: periodic checking of database integrity
Assurance level Periodic checking of database integrity
Level 1 There is no obligation.
Level 2 Database integrity of certificate authority should be checked, at the moment of installation and per month.
Level 3 Database integrity of certificate authority should be checked, at the moment of installation and per week.
Level 4 Database integrity of certificate authority should be checked, at the moment of installation and per day.
 

6.6.3. Life cycle security controls

 

It is not implemented.

6.7         Network security controls

 

Table 40: network security controls
Assurance level Network security controls
Level 1 There is no obligation.
Level 2 Certificate authority should ensure that security controls and proving CA integrity and its availability, is done through every global network which is connected to it. Such a protection should include installation of one or more than one configuration system, so that only protocols and orders which are needed by CA executive operations are accepted.
Certificate authorities should mention such mechanisms and procedures (which are considered to do network security control) in their CPS.
Level 3
Level 4
 

6.8         Time-stamping

 

Table 41: time-stamping
Assurance level Time stamp
Level 1 There is no obligation.
Level 2 Certificate authority can include the ability to add time stamp for subscribers in their transactions.
Level 3
Level 4
 

7          Certificate, CRL and OCSP Profiles

7.1         Certificate profile

 

Profiles of issued certificates by certificate authorities should be in accordance with RFC5280 and comprehensive Requirements of IRAN’s PKI profiles : Appendix, and issuance of any kind of certificate which is not according to defined profiles, is not allowed. Each X.509 certificate should at least contain main fields and each field should be valued according to bounds which are defined for its values. X.509 certificate fields are mentioned in following table. Full description of the digital certificate profiles are presented in a comprehensive Requirements of IRAN’s PKI profiles : Appendix.
Table 42: the requirements of certificate specifications
Field Requirements of certificate specifications
Serial number Serial number which is issued for each certificate is a unique value for certificate authority.
Signature algorithm algorithm ID used for signing the certificate (section 7.1.3)
Issuer ID It is explained in section 7.1.4.
Validity Certificate validity time
Subject DN It is explained in section 7.1.4.
Subject public key Public key of subscriber which is encoded according to RFC5280.
signature Certificate signature which is encoded according to RFC5280.
 

7.1.1. Version number

 

Certificates should be issued according to 3rd version of X.509 standard.

7.1.2. Certificate extensions

 

The requirements related to availability or unavailability of processing certificate extensions, are mentioned in comprehensive Requirements of IRAN’s PKI profiles : Appendix.

7.1.3. Algorithm Object Identifiers

 

Certificates issued by certificate authority should be signed by one of following algorithms:
·Sha25withRSAEncryption OBJECT IDENTIFIER ∷= {
Iso (1) member-body (2) us (840) rsadsi (113549) pkcs (1) pkcs-1 (1) 11}
·Sha-1WithRSAEncryption OBJECT IDENTIFIER ∷= {
Iso (1) member-body (2) us (840) rsadsi (113549) pkcs (1) pkcs-1 (1) 5}
IRAN’s public key infrastructure contains 2 hierarchical models: G2 and G3. G2 structure is compatible with SHA1 hash function, and can be used in hardware and software that support this hash function. G2 structure is compatible with SHA256 hash function and is used for higher level of security.

7.1.4. Names forms

 

Giving value to combinatorial names relating to subscriber and certificate authority should be according to section 3.1.

7.1.5. Name constraints

 

Name constraints extension should be mentioned in certificate according to what is explained in comprehensive Requirements of IRAN’s PKI profiles : Appendix

7.1.6. Certificate Policies Object Identifier

 

Certificate authority should ensure the accuracy of OID value or OID of CP which are included in certificate.

7.1.7. Usage of the “Policy Constraints” extension

 

Policy constraints extension should be included in certificate according to what is explained in comprehensive Requirements of IRAN’s PKI profiles : Appendix.

7.1.8. “Policy Qualifiers” syntax and semantics

 

3rd version of X.509 certificates contains a policy describer in policy qualifiers extension, which for example indicates access address of CPS.

7.1.9. Processing semantics for the critical “Certificate Policies” extension

 

According to comprehensive Requirements of IRAN’s PKI profiles : Appendix, a non-critical status is assigned for certificate policy extension.

7.2         CRL Profile

 

CRL profile should be according to RFC5280 standard. CRL should include main fields and their specified values (which are mentioned in following table):
Table 43: the requirements of CRL specifications
Field The requirements of revocation list specifications
Version It is explained in section 7.2.1.
Signature algorithm The ID of used algorithm for signing CRL (section 7.1.3).
Issuer Combinatorial name of entity which produces and signs CRL.
Effective date CRL issuance date
Next update Issuance date of next CRL; Requirements of CRL frequency are mentioned in section 4.9.7.
Revoked CRL including revoked certificates serial numbers and revocation dates.
 

7.2.1. Version number

 

Certificate authority should support 2nd version of X.509 for CRL, in accordance with RFC5280.

7.2.2. CRL and CRL entry extensions

 

Requirements of availability and unavailability of processing CRL and CRL Entry are mentioned in comprehensive Requirements of IRAN’s PKI profiles : Appendix.

7.3         OCSP profile

7.3.1. Version number

 

Certificate authority should support first version of OCSP which is defined in RFC2560.

7.3.2. OCSP extensions

 

OCSP extensions should be used according to comprehensive Requirements of IRAN’s PKI profiles : Appendix. OCSP responder service provider should use “Nonce” extension which is defined in RFC2560, to prevent replay attacks and ensuring OCSP client of freshness of OCSP response. The value of this extension is equal to “Nonce” extension of client OCSP request.

8          Compliance Audit and Other Assessment

 

Compliance audit is done to ensure certificate authority functionality, and also to check the compatibility of certificate authority functionality with requirements and processed which are mentioned in CP and CPS. In IRAN’s PKI two mechanisms are defined for compliance audit:
  • Certificate Policy Making Council Audit: according to article 3 from executive regulation of article 32 of e-commerce law, one of the duties and responsibilities of the council, is to supervise and audit operation reports and violations of CAs. Therefore, the inspector(s) who are confirmed by the council should periodically inspect CAs.
  • IR.GRCA audit: according to article 5 from executive regulation of article 32 of e-commerce law, one of the responsibilities and duties of IR.GRCA is to ensure correct operation of intermediate CAs. IR.GRCA inspects intermediate CAs to ensure these CAs’ accurate operations.

8.1         Frequency and circumstances of assessment

 

Compliance audit of all certificate authorities should be done according to following table.
Table 44: frequency and conditions of assessment
Assurance level Frequency and conditions of evaluation
Level 1 There is no obligation.
Level 2 Compliance audit should be done at least one time in a year.
Level 3
Level 4 Compliance audit should be done at least one time and preferably two times in a year.
 
Time and frequency of audit is changeable dependent to certificate authority operation volume.

8.2         The identity and qualifications of the assessor

 

IR.GRCA audits intermediate CAs by its authorized experts, in specified domains which are mentioned in section 8.4, and the council audits CAs by persons (natural or legal) who are approved by the council.
Inspector should be completely familiar with IRAN’s PKI and its standards, certificate policies of IRAN’s public key infrastructure and CPS of intermediate CAs.

8.3         Assessor’s relationship to assessed entity

 

Assessment of all certificate authorities should be only done by persons specified in section 8.2.

8.4         Topics covered by assessment

 

Compliance audit should at least include following subjects:
  • CPS of intermediate CA, technical, procedural and personnel instructions of CA, and technical plan of equipment and building;
  • Compliance audit of intermediate CA; including building, equipment, software, hardware, personnel and procedures, with instructions and documents which are mentioned in first paragraph;
  • Compliance audit of equipment, software, and registration authority operations with CPS of intermediate CA.

8.5         Actions taken as a result of deficiency

 

If in audit process any variance is seen with certificate policies of IRAN’s public key infrastructure and CPS of intermediate CAs, or if any defect or security problem is seen in audit process, following actions should be done:
  • Inspector should record defects or variances;
  • Inspector should inform parties specified in section 8.6, about variances and defects;
  • Certificate authority should obviate defects of variances in time specified audit CA;
  • If defect or variance is not obviated by CA in specified time, variance report should be delivered to council;
  • Council can make decision about extending defect obviation time, preventing the activities of CA, or revocation the certificate of CA.

8.6         Results reporting

 

Results of IR.GRCA assessment from intermediate CA should be delivered to the council; these results should be considered as confidential information and they should not be disclosed unless by the permission of competent judicial authority.

9          Other Business and Legal Matters

9.1         Fees

 

Certificate authorities should take fee for services which are signified by government cabinet.

9.1.1. Certificate issuance or renewal fees

 

Registration cost of certificate authorities for all activities relating to digital certificate should be in accordance with notified fees by government cabinet.

9.1.2. Certificate access fees

 

No fee is assigned.

9.1.3. Revocation or status information access fees

 

Currently, since government cabinet has not signified fee for certificate revocation or access to certificate status information, no fee will be taken for these operations.

9.1.4. Fees for other services

 

Certificate authorities take no fee for other services such as access to digital certificate policies of IRAN’s public key infrastructure and CPS.
Currently, since government cabinet has not signified fee for other services, no fee will be taken for these services.

9.1.5. Refund policy

 

For all certificates issued by IR.GRCA, subordinate CA and registration authority, it is possible to refund if applicant cancels his certificate request before certificate is issued. Refund conditions should be mentioned in CPS of intermediate CA.

9.2         Financial Responsibility

9.2.1. Insurance Coverage

 

Insurance coverage is not currently supported by IR.GRCA nevertheless; intermediate CAs can insure certificate applicants, through signing contract with official insurance companies.

9.2.2. Other assets

 

Non-governmental intermediate CAs should have sufficient finance strength to continue working and doing their duties. Intermediate CAs should have sufficient finance strength to cover the dangers of responsibilities against subscribers and relying parties.

9.2.3. Insurance or warranty coverage for end-entities

 

Currently there is no comprehensive insurance coverage, nevertheless some intermediate CAs insure mistakes that they do in certificate issuance process, in the condition that certificate applicants do their legal duties. Information related to these guarantee should be mentioned in CPS of intermediate CAs.

9.3         Confidentiality of business information

9.3.1. Scope of confidential information

 

Certificate authorities should keep information similar to below information confidentially:
  • Information of each certificate request that is maintained by certificate authorities and is not included in issued certificates, should be kept confidential.
  • All private keys and activation data which are used in certificate authorities and registration authorities;
  • Trading usage history and digital certificate usage history;
  • Intermediate CA and registration authority certificate request that may include information such as business plan, sale information, business secrets;
  • All information related to handling event recording which is created and maintained by certificate authority;
  • Safety measures which are decided for technical plan of equipment, building, software, and presenting certificate services.

9.3.2. Information not within the scope of confidential information

 

  • All information available in certificate authority repository;
  • All identification information and other information available in certificates are not confidential, unless it is mentioned as confidential in agreement.

9.3.3. Responsibility to protect confidential information

 

Certificate authorities and registration authorities are responsible to protect confidential information against disclosure and unauthorized access.

9.4         Privacy of Personal Information

 

Information related to certificate applicant or subscriber which is maintained by certificate authorities and is not available in issued certificate, is named private information. By private information we do not necessarily mean confidential information.

9.4.1. Privacy plan

 

Subscriber privacy plan is defined according to Islamic Republic of IRAN laws, such as e-commerce law approved in January 14, 2004, 3rd article of 3rd chapter (paragraphs 58-61), and 2nd article of 4th chapter (paragraphs 71-73).
Intermediate CAs can apply privacy plan in their CPS document, within the law of Islamic Republic of IRAN.

9.4.2. Information treated as private

 

All types of information about certificate applicant which is presented to certificate authorities and are not open to public, are considered as private information.

9.4.3. Information not deemed private

 

Information available in published certificate and is easily seen, or issued CRL information, is not considered as private.

9.4.4. Responsibility to protect private information

 

Certificate authorities and registration authorities are responsible to protect personal and private information of subscribers.

9.4.5. Notice and consent to use private information

 

Certificate authorities are not allowed to transfer private information of subscribers. If subscriber decides to transfer his information to a third party, he should present his written contentment to certificate authority.

9.4.6. Disclosure pursuant to judicial or administrative process

 

In the condition that certificate authority has to deliver information of subscriber to judicial authority, in line with protecting public security of country and citizen rights, and also crime detection and offender prosecution, this cooperation is done just by official judicial decree.

9.4.7. Other conditions of information disclosure

 

It is not applicable.

9.5         Intellectual Property Rights

 

  • Intellectual property of certificate and certificate revocation information; intellectual property of all issued certificates and certificate revocation information, belongs to certificate authorities. Subscribers and relying parties have permission to use issued certificates in authorized usages according to agreements and instructions of certificate authorities.
  • Intellectual property of documents; intellectual property of documents of certificate authorities, such as practice statement of certificate issuance, belongs to certificate authorities related to these documents.
  • Intellectual property of names; each digital certificate which is issued according to rules, includes intellectual property of names for subscriber. This name belongs exclusively to subscriber, and no one can register it again.
  • Intellectual property of keys; intellectual property of key pair relating to certificate, belongs to subscriber.
  • Other cases; intellectual property of all information published in repository, belongs to certificate authorities.

9.6         Representations and Warranties

9.6.1. CA Representations and Warranties

9.6.1.1. IR.GRCA Representations and Warranties

 

IR.GRCA is responsible for below cases:
  • Recommending CP and CPS of IR.GRCA and its relating documents, and presenting them to the council;
  • Implementing council’s policies and instructions;
  • Updating this document together with other needed documents and presenting them to council to approve;
  • Ensuring the compatibility of IR.GRCA with this document;
  • Checking and confirming CPS of intermediate CA certificate;
  • Checking and authenticating needed qualifications of applicants who want to establish intermediate CA;
  • Taking suitable obligation from applicants who want to establish intermediate CA;
  • Ensuring that information registered in issued certificates is accurate and valid;
  • Doing periodic audits to ensure accurate operation of intermediate CAs.
  • Public informing to subscribers and relying parties about fundamental changes in certificate authorities operation;
  • Revocation the certificates of intermediate CAs, which have acted against their commitments;
  • Publishing revoked certificate of intermediate CAs in website and public informing through newspapers;
  • Handling subscribers’ and other entities’ complains about intermediate CAs.
  • To guarantee the security of data related to signature, to prevent simulation of intermediate CAs certificates
  • Ensuring online certificate status protocol service of intermediate CAs.

9.6.1.2. Intermediate CAs Representations and Warranties

 

Intermediate CAs should guarantee below cases:
  • Codification of CPS document and taking confirmation from IR.GRCA
  • Intermediate CAs are responsible to create and sign certificate for subscribers;
  • Ensuring the security of data related to signature, to prevent simulation of certificates
  • Ensuring online certificate status protocol service of intermediate
  • Ensuring continual access to repository according to CPS of intermediate CAs;
  • Updating CPS of intermediate CA and taking confirmation from IR.GRCA
  • Qualification control of their registration authorities and issuing certificate for them
  • To guarantee presenting digital certificate management services, such as certificate issuance, revocation, publication, and online certificate status protocol;
  • Doing periodic audits from their intermediate CAs, and registration authorities
  • If intermediate CA generates key pair as applicant representative, it does this operation safely and according to section 6.1.1.3.
  • Ensuring that key pair is under exclusive ownership of subscriber;
  • Ensuring that key pair is not copied by their intermediate CAs and registration authorities
  • Compatibility of intermediate CA with this document, standards presented by IR.GRCA, CPS of intermediate CA, and contract between intermediate CA and IR.GRCA;
  • Ensuring that standards of IRAN’s public key infrastructure are applied;
  • To announce accepting or rejecting their intermediate certificate, after receiving certificate issuance proclamation (to accept Intermediate certificate issued by IR.GRCA, means that intermediate CA confirms the accuracy of certificate information);
  • To issue digital certificate using private key, only when issued certificate by IR.GRCA, is valid;
  • Informing IR.GRCA immediately, about losing key or key disclosure risk, and requesting certificate revocation;
  • Obligation to related laws
  • Following physical and electronic security issues
  • Being aware that intermediate CA is responsible for any damage resulting from violating above mentioned issues.

9.6.2. RA Representations and Warranties

 

Registration authorities should guarantee following cases:
  • Working according to CPS of intermediate CA, presented standards by IR.GRCA and agreements between registration authority and intermediate CA;
  • Receiving certificate issue, key renewal, extending, and revocation request, and delivering them to intermediate CA;
  • Doing authentication of applicant and ensuring the accuracy of information delivered to intermediate CA;
  • Obligation to related laws
  • Following physical and electronic security issues

9.6.3. Subscriber Representations and Warranties

 

A subscriber for whom certificate is issued by one of certificate authorities should guarantee below cases:
  • Evaluating certificate when using it, according to section 4.5.2.
  • Generating key pair according to section 6.1.1.3.
  • Maintaining private key so that unauthorized individuals have no access to it;
  • Presenting accurate information related to request and informing any changes in information in certificate validity period.
  • Certificate should just be used in authorized and legal usages, according to usages mentioned in certificate;
  • Presenting certificate revocation request according to section 4.9.1.2.
  • Ensuring that software being used in laboratory of public key infrastructure of IR.GRCA is evaluated and approved by IR.GRCA.
  • Ensuring that computer environment, which is being used, is safe;
  • Adherence to agreements between applicant and certificate authority;
  • Using certificate in assurance level compatible with defined assurance levels in section 1.1.

9.6.4. Relying Parties Representations and Warranties

 

Relying party should consider below cases before trusting the certificate:
  • Using valid repository announced by certificate authority;
  • Evaluating certificate when using it, according to section 4.5.2.
  • Receiving self-signed certificate of IR.GRCA, and intermediate CA certificate of certificate issuer, through a safe publishing channel;
  • Ensuring that certificate is exclusively used in authorized usages according to usages mentioned in certificate;
  • Ensuring that software being used in laboratory of public key infrastructure of IR.GRCA is evaluated and approved by IR.GRCA.
  • Ensuring that certificate is used in assurance level compatible with defined assurance levels in section 1.1.
  • Ensuring that computer environment of relying parties is safe;
  • Maintaining signed information and information related to signature, certificate, and processes relating to encryption operation.

9.6.5. Representations and Warranties of other participants

9.6.5.1. Warranties of IRAN’s Digital Certificate Policy Council

 

According to article 3 from executive regulation of article 32 of e-commerce law, the responsibilities of policy council are as follows:
  • Offering macro policies and programs related to IRAN’s public key infrastructure domain;
  • To issue permission to establish certificate authorities;
  • Approving certificate policies and CPS of CAs;
  • Approving standards, procedures and CPS of CAs;
  • To supervise and check operation report and violations of IR.GRCAs and intermediate CAs, if their permission is cancelled;
  • making decision about creating, removing, and applying changes in different domains of IRAN’s public key infrastructure and other needed activities to develop public key infrastructure;
  • Doing audit from certificate authorities on council demand;
  • Handling disputes between certificate authorities
  • Handling reported violations of intermediate CAs from IR.GRCA.
  • To supervise on sub-domain operations to maintain balance and compatibility with each other in national level and with other domains in international level

9.6.5.2. Warranties of the council supervisory committee

 

The responsibilities of this committee are:
  • To issue digital certificate and generating self-signed key for IR.GRCA;
  • To issue intermediate CA certificate, that policy council has approved its CPS;
  • To supervise on activities and operation method of IR.GRCA and intermediate CAs;
  • Committee in time periods, that council has specified it, present their report collected from its supervision on IR.GRCAs and intermediate CAs.
Note- primary dispute resolution CA is IR.GRCA and intermediate CAs.
Note- committee meeting would be official by presence of 3 members. In the ceremony of digital certificate issuance (generating self-signed key) for IR.GRCA, the presence of all members is mandatory.

9.7         Disclaimers of Warranties

 

Except for mentioned responsibilities and obligations, IR.GRCA is not responsible for direct, indirect, accidental, or criminal damages about certificates that are issued by intermediate CAs.
Intermediate CAs cannot claim IR.GRCA and council for cases such as revocation intermediate CA certificate. Subscribers and relying parties cannot claim IR.GRCA for wrong information of certificate which is issued by an intermediate CA.

9.8         Limitations of Liability

 

Certificate authorities do not accept any responsibility about damages resulting from reception of certificates issued from relying parties, or rejecting a valid certificate, or reception of a revoked certificate by relying parties.

9.9         Indemnities

 

If intermediate CAs apply digital certificate policies of IRAN’s public key infrastructure correctly and present services in line with e-commerce law, they do not accept to pay any money for damages resulting from accepting or rejecting issued certificates.

9.10   Term and Termination

9.10.1. Term

 

This document is valid until publication of a newer version of document.

9.10.2. Termination

 

Once a newer version is published, this document validity will be terminated.

9.10.3. Effects of termination and survival

 

It is not defined.

9.11   Individual notices and communications with participants

 

Registration authorities and certificate authorities should keep in touch to each other. This relation can be done through email, fax, web pages, or any other methods which are mentioned in this document or CPS. Special informing or declaration is different from what was mentioned in section 2.2 in the field of information publication through repository.
Certificate authorities and registration authorities should inform in operations that have effect on their relationship. In other words, if a registration authority wants to cancel its contract with intermediate CA, it should inform intermediate CA. Before termination of certificate authority activities, their information should be archived.

9.12   Amendments

9.12.1. Procedures of Amendment

 

Any change in this document should be published in web URL after council approval.

9.12.2. Notification mechanism and period

 

All changes in this document should be published maximum after 5 days in web URL of IR.GRCA, after council approval.

9.12.3. Circumstances under which OID must be changed

 

It is not usable.

9.13   Dispute Resolution Provisions

 

When any dispute occurs between IR.GRCA and intermediate CAs, at first council supervisory committee handles it and if it was not solved, it is handled in council. Any dispute between intermediate CAs and subscribers should be solved by dispute resolution commission in intermediate CA, and if it was not solved by this commission and IR.GRCA, it is referred to judicial CAs.

9.14   Governing Law

 

All laws of Islamic Republic of IRAN such as e-commerce law (approved in January 14, 2004), executive regulation of article 32 of e-commerce law, and legislations of IRAN’s Digital Certificate Policy Council, govern activities and contracts between certificate authorities, subscribers and relying parties.

9.15   Compliance with Applicable Law

 

This document is compatible with executive law of section 9.14.

9.16   Miscellaneous Provisions

 

It is not defined.

9.16.1. Entire agreement

 

It is not defined.

9.16.2. Assignment

 

It is not defined.

9.16.3. Severability

 

IR.GRCA owns an independent character and acts independently within the law.

9.16.4. Attorneys’ fees and waiver of rights

 

It is not defined.

9.16.5. Force Majeure

 

Force majeure cases are cases that are codified in public laws of Islamic Republic of IRAN. Intermediate CAs can extend the domain of force majeure cases, to the extent that is allowed by law.

9.17   Other Provisions

 

It is not defined.
 
 

10     Appendix: Comprehensive Requirements of IRANs PKI Profiles

10.1            Profiles of End Entity Certificates

 

Digital Signature certificate Profile:
Value Field
V3 Version
Must be unique for each CA Serial Number
sha-1WithRSAEncryption
or
sha256WithRSAEncryption
Issuer Signature Algorithm
Subject Distinguished Name of Issuer Issuer Distinguished Name
Certificate duration in UTC Validity Period

According to GRCA LDAP schema and certificate naming requirements

 

  Subject Distinguished Name
1024 or 2048 bit RSA key modulus, rsaEncryption Subject Public Key Information
Not Present Issuer Unique Identifier
Not Present Subject Unique Identifier
sha-1WithRSAEncryption
or
 sha256WithRSAEncryption
Issuer Signature
Extensions
c=no* ; Octet String (20 byte SHA-1 hash of the binary DER encoding of the Organization CA’s public key information) Authority key identifier
c=no; Octet String (20 byte SHA-1 hash of the binary DER encoding of the Application CA’s public key information) subject key identifier
c=yes* ; digitalSignature, nonRepudiation key usage
Client Authentication (1.3.6.1.5.5.7.3.2) Extended key usage
Not Present Private key usage period
c=no; { Certificate Policy OID }
Qualifier : CPS URL
Certificate policies
Not Present Policy Mapping
Not Present subject Alternative Name
Not Present Issuer Alternative Name
Not Present Subject Directory Attributes
Not Present Basic Constraints
Not Present Name Constraints
Not Present Policy Constraints
c=no; pointer to OCSP Responder (if supported)      Authority Information Access
c = no;
CRL address; sample:
URL=http://server1.name.com/Repository/caname.crl
CRL Distribution Points
 
* C=yes: Critical Extension
* C=no: Non Critical Extension
 
Secure Email certificate Profile:
Value Field
V3 Version
Must be unique for each CA Serial Number
sha-1WithRSAEncryption
or
sha256WithRSAEncryption
Issuer Signature Algorithm
Subject Distinguished Name of Issuer Issuer Distinguished Name
Certificate duration in UTC Validity Period
According to GRCA LDAP schema and certificate naming requirements Subject Distinguished Name
1024 or 2048 bit RSA key modulus, rsaEncryption Subject Public Key Information
Not Present Issuer Unique Identifier
Not Present Subject Unique Identifier
sha-1WithRSAEncryption
or
sha256WithRSAEncryption
Issuer Signature
Extensions
c=no; Octet String (20 byte SHA-1 hash of the binary DER encoding of the Organization CA’s public key information) Authority key identifier
c=no; Octet String (20 byte SHA-1 hash of the binary DER encoding of the Application CA’s public key information) subject key identifier
c=yes; digitalSignature, Key encipherment, nonRepudiatio key usage
c=yes; emailProtection Extended key usage
SMIME Netscape Cert Type[2]
Not Present Private key usage period
c=no; { Certificate Policy OID }
Qualifier : CPS URL
Certificate policies
Not Present Policy Mapping
Subscriber's email addresses: rfc822Name format subject Alternative Name
Not Present Issuer Alternative Name
Not Present Subject Directory Attributes
Not Present Basic Constraints
Not Present Name Constraints
Not Present Policy Constraints
c=no; pointer to OCSP Responder (if supported)     Authority Information Access
c = no;  CRL address; sample:
URL=http://server1.name.com/Repository/caname.crl
CRL Distribution Points
 
                       
Authentication  certificate Profile:
Value Field
V3 Version
Must be unique for each CA Serial Number
sha-1WithRSAEncryption
or
sha256WithRSAEncryption
Issuer Signature Algorithm
Subject Distinguished Name of Issuer Issuer Distinguished Name
Certificate duration in UTC Validity Period
According to GRCA LDAP schema and certificate naming requirements Subject Distinguished Name
1024 or 2048 bit RSA key modulus, rsaEncryption Subject Public Key Information
Not Present Issuer Unique Identifier
Not Present Subject Unique Identifier
sha-1WithRSAEncryption
or
sha256WithRSAEncryption
Issuer Signature
Extensions
c=no; Octet String (20 byte SHA-1 hash of the binary DER encoding of the Organization CA’s public key information) Authority key identifier
c=no; Octet String (20 byte SHA-1 hash of the binary DER encoding of the Application CA’s public key information) subject key identifier
c=yes; digitalSignature, nonRepudiation key usage
c=yes;
Client Authentication (1.3.6.1.5.5.7.3.2)
Smart Card Logon (1.3.6.1.4.1.311.20.2.2)
Extended key usage
Not Present Private key usage period
c=no; { Certificate Policy OID }
Qualifier : CPS URL  
Certificate policies
Not Present Policy Mapping
For SmartCard Logon Certificate:
Other Name: Principal Name= (UPN).
For example: UPN = user1@name.com

The UPN OtherName OID is : "1.3.6.1.4.1.311.20.2.3"
The UPN OtherName value: Must be ASN1-encoded UTF8 string
subject Alternative Name
Not Present Issuer Alternative Name
Not Present Subject Directory Attributes
Not Present Basic Constraints
Not Present Name Constraints
Not Present Policy Constraints
c=no; pointer to OCSP Responder (if supported)     Authority Information Access
c = no; CRL address; sample:
URL=http://server1.name.com/Repository/caname.crl
CRL Distribution Points
 
 
Organization Stamp  certificate Profile:
Value Field
V3 Version
Must be unique for each CA Serial Number
sha-1WithRSAEncryption
or
sha256WithRSAEncryption
Issuer Signature Algorithm
Subject Distinguished Name of Issuer Issuer Distinguished Name
Certificate duration in UTC Validity Period
According to GRCA LDAP schema and certificate naming requirements Subject Distinguished Name
1024 or 2048 bit RSA key modulus, rsaEncryption Subject Public Key Information
Not Present Issuer Unique Identifier
Not Present Subject Unique Identifier
sha-1WithRSAEncryption
or
sha256WithRSAEncryption
Issuer Signature
Extensions
c=no ; Octet String (20 byte SHA-1 hash of the binary DER encoding of the Organization CA’s public key information) Authority key identifier
c=no; Octet String (20 byte SHA-1 hash of the binary DER encoding of the Application CA’s public key information) subject key identifier
c=yes ; digitalSignature, nonRepudiation key usage
Not Present Private key usage period
c=no; { Certificate Policy OID }
Qualifier : CPS URL
Certificate policies
Not Present Policy Mapping
Not Present subject Alternative Name
Not Present Issuer Alternative Name
Not Present Subject Directory Attributes
Not Present Basic Constraints
Not Present Name Constraints
Not Present Policy Constraints
c=no; pointer to OCSP Responder (if supported)     Authority Information Access
c = no; CRL address; sample:
URL=http://server1.name.com/Repository/caname.crl
CRL Distribution Points
 
 
 
Organization Stamp  certificate Profile:
 
Value
Field
V3 Version
Must be unique for each CA Serial Number
sha-1WithRSAEncryption
or
sha256WithRSAEncryption
Issuer Signature Algorithm
Subject Distinguished Name of Issuer Issuer Distinguished Name
Certificate duration in UTC Validity Period
According to GRCA LDAP schema and certificate naming requirements Subject Distinguished Name
1024 or 2048 bit RSA key modulus, rsaEncryption Subject Public Key Information
Not Present Issuer Unique Identifier
Not Present Subject Unique Identifier
sha-1WithRSAEncryption
or
sha256WithRSAEncryption
Issuer Signature
Extensions
c=no; Octet String (20 byte SHA-1 hash of the binary DER encoding of the Organization CA’s public key information) Authority key identifier
c=no; Octet String (20 byte SHA-1 hash of the binary DER encoding of the Application CA’s public key information) subject key identifier
c=yes; Digital Signature, Key Encipherment key usage
c=no;
Client Authentication (1.3.6.1.5.5.7.3.2)
Server Authentication (1.3.6.1.5.5.7.3.1)
Extended key usage
Not Present Private key usage period
c=no; { Certificate Policy OID }
Qualifier : CPS URL
Certificate policies
Not Present Policy Mapping
c=no;
  • for SSL/TLS Certificate in server side: URL of server in IA5 string
  • for Domain Controllet server certificate: domain controller unique identifier (GUID); Domain Name (DNS) of server
sample for Domain Controller certificate:
Other Name: 1.3.6.1.4.1.311.25.1 = ac 4b 29 06 aa d6 5d 4f a9 9c 4c bc b0 6a 65 d9
DNS Name=server1.Domain.com
subject Alternative Name
Not Present Issuer Alternative Name
Not Present Subject Directory Attributes
Not Present Basic Constraints
Not Present Name Constraints
Not Present Policy Constraints
c=no; pointer to OCSP Responder (if supported)  
 
Authority Information Access
c = no; CRL address; sample:
URL=http://server1.name.com/Repository/caname.crl
CRL Distribution Points
DomainController Certificate Template Name
 
 
Code Signing  certificate Profile:
Value Field
V3 Version
Must be unique for each CA Serial Number
sha-1WithRSAEncryption
or
sha256WithRSAEncryption
Issuer Signature Algorithm
Subject Distinguished Name of Issuer Issuer Distinguished Name
Certificate duration in UTC Validity Period
According to GRCA LDAP schema and certificate naming requirements Subject Distinguished Name
1024 or 2048 bit RSA key modulus, rsaEncryption Subject Public Key Information
Not Present Issuer Unique Identifier
Not Present Subject Unique Identifier
sha-1WithRSAEncryptionl
or
sha256WithRSAEncryption
Issuer Signature
Extensions
c=no; Octet String (20 byte SHA-1 hash of the binary DER encoding of the Organization CA’s public key information) Authority key identifier
c=no; Octet String (20 byte SHA-1 hash of the binary DER encoding of the Application CA’s public key information) subject key identifier
c=yes; Digital Signature, nonRepudiation key usage
c=yes; id-kp-codeSigning {1 3 6 1 5 5 7 3 3} Extended key usage
Not Present Private key usage period
c=no; { Certificate Policy OID }
Qualifier : CPS URL
Certificate policies
Not Present Policy Mapping
Not Present subject Alternative Name
Not Present Issuer Alternative Name
Not Present Subject Directory Attributes
Not Present Basic Constraints
Not Present Name Constraints
Not Present Policy Constraints
c=no; pointer to OCSP Responder (if supported) Authority Information Access
c = no; CRL address; sample:
URL=http://server1.name.com/Repository/caname.crl
CRL Distribution Points
 
 

10.1            Profiles of CA Certificates

 

 

GRCA Certificate Profile:

 

Value Field
V3 Version
براي هر گواهي ميبايست منحصر به فرد باشد. Serial Number
sha-1WithRSAEncryption
or
sha256WithRSAEncryption
Issuer Signature Algorithm
Same as the Subject Distinguished Name. Issuer Distinguished Name
دوره اعتبار گواهي در قالب UTC Validity Period
منطبق با بخش Error! Reference source not found.مقداردهي ميگردد. Subject Distinguished Name
 2048 bit RSA key modulus, rsaEncryption Subject Public Key Information
Not Present Issuer Unique Identifier
Not Present Subject Unique Identifier
sha-1WithRSAEncryption
or
sha256WithRSAEncryption
Issuer Signature
Extensions
Not Present Authority key identifier
c=no; Octet String (20 byte SHA-1 hash of the binary DER encoding of the Application CA’s public key information)
(منطبق با بخش Error! Reference source not found.مقداردهي ميگردد)
subject key identifier
c=yes; digitalSignature, keyCertSign, cRLSign key usage
Not Present Extended key usage
Not Present Private key usage period
c=no; { Certificate Policies OID }
منطبق با بخش Error! Reference source not found.مقداردهي ميگردد.
Certificate policies
Not Present Policy Mapping
Not Present subject Alternative Name
Not Present Issuer Alternative Name
Not Present Subject Directory Attributes
c=yes; cA=True; no path length constraint Basic Constraints
Not Present Name Constraints
Not Present Policy Constraints
Not Present Authority Information Access
Not Present CRL Distribution Points
 

Intermediate CA’s Certificate Profile:

 

Value Field
V3 Version
براي هر گواهي ميبايست منحصر به فرد باشد. Serial Number
sha-1WithRSAEncryption
or
sha256WithRSAEncryption
Issuer Signature Algorithm
Subject Distinguished Name of Issuer Issuer Distinguished Name
دوره اعتبار گواهي در قالب UTC Validity Period
منطبق با بخش Error! Reference source not found.مقداردهي ميگردد. Subject Distinguished Name
2048 bit RSA key modulus, rsaEncryption Subject Public Key Information
Not Present Issuer Unique Identifier
Not Present Subject Unique Identifier
sha-1WithRSAEncryption
or
sha256WithRSAEncryption
Issuer Signature
Extensions
 c=no; Octet String (20 byte SHA-1 hash of the binary DER encoding of the Organization CA’s public key information)
(منطبق با بخش Error! Reference source not found.مقداردهي ميگردد)
Authority key identifier
c=no; Octet String (20 byte SHA-1 hash of the binary DER encoding of the Application CA’s public key information)
(منطبق با بخش Error! Reference source not found.مقداردهي ميگردد)
subject key identifier
c=yes; digitalSignature, keyCertSign, cRLSign key usage
Not Present Extended key usage
Not Present Private key usage period
c=no; { Certificate Policy OID }
منطبق با بخش Error! Reference source not found.مقداردهي گردد.
Certificate policies
Not Present Policy Mapping
Not Present subject Alternative Name
Not Present Issuer Alternative Name
Not Present Subject Directory Attributes
c=yes; CA = True, pathLenConstraints 0 or 1 depending on sub-CA
منطبق با بخش Error! Reference source not found.مقداردهي مي‌گردد.
Basic Constraints
Not Present Name Constraints
Not Present Policy Constraints
Not Present Authority Information Access
c = no;
نشاني دسترسي به CRL؛ منطبق با بخش Error! Reference source not found.مقداردهي گردد. مثال:
URL= http://crl.rca.gov.ir/irica.crl
CRL Distribution Points
 

10.2            Profiles of CA related Certificates

 

 
 

RA’s Certificate Profile:

 

Value Field
V3 Version
براي هر گواهي ميبايست منحصر به فرد باشد. Serial Number
sha-1WithRSAEncryption
or
sha256WithRSAEncryption
Issuer Signature Algorithm
Subject Distinguished Name of Issuer Issuer Distinguished Name
دوره اعتبار گواهي در قالب UTC Validity Period
منطبق با بخش Error! Reference source not found.مقداردهي گردد. Subject Distinguished Name
1024 or 2048 bit RSA key modulus, rsaEncryption Subject Public Key Information
Not Present Issuer Unique Identifier
Not Present Subject Unique Identifier
sha-1WithRSAEncryption
or
sha256WithRSAEncryption
Issuer Signature
Extensions
 c=no; Octet String (20 byte SHA-1 hash of the binary DER encoding of the Organization CA’s public key information)
(منطبق با بخش Error! Reference source not found.مقداردهي گردد)
Authority key identifier
c=no; Octet String (20 byte SHA-1 hash of the binary DER encoding of the Application CA’s public key information)
(منطبق با بخش Error! Reference source not found.مقداردهي گردد)
subject key identifier
c=yes; digitalSignature, nonRepudiation key usage
Not Present Extended key usage
Not Present Private key usage period
c=no; { Certificate Policy OID }
منطبق با بخش Error! Reference source not found.مقداردهي گردد.
Certificate policies
Not Present Policy Mapping
Not Present subject Alternative Name
Not Present Issuer Alternative Name
Not Present Subject Directory Attributes
Not Present Basic Constraints
Not Present Name Constraints
Not Present Policy Constraints
Not Present Authority Information Access
c = no;
نشاني دسترسي به CRL؛ منطبق با بخش Error! Reference source not found.مقداردهي گردد. مثال:
URL=http://server1.name.com/Repository/caname.crl
CRL Distribution Points
 

OCSP Responder Certificate Profile:

 

 
Value
Field
V3 Version
براي هر گواهي ميبايست منحصر به فرد باشد. Serial Number
sha-1WithRSAEncryption
or
sha256WithRSAEncryption
Issuer Signature Algorithm
Subject Distinguished Name of Issuer Issuer Distinguished Name
دوره اعتبار گواهي در قالب UTC Validity Period
منطبق با بخش Error! Reference source not found.  مقداردهي گردد. Subject Distinguished Name
1024 or 2048 bit RSA key modulus, rsaEncryption Subject Public Key Information
Not Present Issuer Unique Identifier
Not Present Subject Unique Identifier
sha-1WithRSAEncryption
or
sha256WithRSAEncryption
Issuer Signature
Extensions
 c=no; Octet String (20 byte SHA-1 hash of the binary DER encoding of the Organization CA’s public key information)
(منطبق با بخش Error! Reference source not found.مقداردهي گردد)
Authority key identifier
c=no; Octet String (20 byte SHA-1 hash of the binary DER encoding of the Application CA’s public key information)
(منطبق با بخش Error! Reference source not found.مقداردهي گردد)
subject key identifier
c=yes; digitalSignature, nonRepudiation key usage
c=yes; id-kp-OCSPSigning {1 3 6 1 5 5 7 3 9} Extended key usage
Not Present Private key usage period
c=no; { Certificate Policy OID }
منطبق با بخش Error! Reference source not found.مقداردهي گردد.
Certificate policies
Not Present Policy Mapping
Not Present subject Alternative Name
Not Present Issuer Alternative Name
Not Present Subject Directory Attributes
Not Present Basic Constraints
Not Present Name Constraints
Not Present Policy Constraints
Not Present Authority Information Access
c = no;
نشاني دسترسي به CRL؛ منطبق با بخش Error! Reference source not found.مقداردهي گردد. مثال:
URL=http://server1.name.com/Repository/caname.crl
CRL Distribution Points
 
 

TSA Certificate Profile:

 

 
Value
Field
V3 Version
براي هر گواهي ميبايست منحصر به فرد باشد. Serial Number
sha-1WithRSAEncryption
or
sha256WithRSAEncryption
Issuer Signature Algorithm
Subject Distinguished Name of Issuer Issuer Distinguished Name
دوره اعتبار گواهي در قالب UTC Validity Period
منطبق با بخش Error! Reference source not found.مقداردهي گردد. Subject Distinguished Name
 1024 or 2048 bit RSA key modulus, rsaEncryption Subject Public Key Information
Not Present Issuer Unique Identifier
Not Present Subject Unique Identifier
sha-1WithRSAEncryption
or
sha256WithRSAEncryption
Issuer Signature
Extensions
 c=no; Octet String (20 byte SHA-1 hash of the binary DER encoding of the Organization CA’s public key information)
(منطبق با بخش Error! Reference source not found.مقداردهي گردد)
Authority key identifier
c=no; Octet String (20 byte SHA-1 hash of the binary DER encoding of the Application CA’s public key information)
(منطبق با بخش Error! Reference source not found.مقداردهي گردد)
subject key identifier
c=yes; digitalSignature, nonRepudiation key usage
 c=yes; id-kp-timestamping {1 3 6 1 5 5 7 3 8} Extended key usage
Not Present Private key usage period
c=no; { Certificate Policy OID }
منطبق با بخش Error! Reference source not found.مقداردهي گردد.
Certificate policies
Not Present Policy Mapping
Not Present subject Alternative Name
Not Present Issuer Alternative Name
Not Present Subject Directory Attributes
Not Present Basic Constraints
Not Present Name Constraints
Not Present Policy Constraints
     چنانچه مركز مياني از پروتكل OCSP پشتيباني نمايد:
c=no; pointer to OCSP Responder      
Authority Information Access
c = no;
نشاني دسترسي به CRL؛ منطبق با بخش Error! Reference source not found.مقداردهي گردد. مثال:
URL=http://server1.name.com/Repository/caname.crl
CRL Distribution Points
 
 

10.3            Profiles of CRLs

 

 
GRCA CRL Profile
Value Field
V2(1) Version
sha-1WithRSAEncryption or sha256WithRSAEncryption Issuer Signature Algorithm
Subject Distinguished Name of Issuer Issuer Distinguished Name
CRL Duration in UTC This Update
UTC; thisUpdate + 185 days ≥ nextUpdate ≥ thisUpdate + CRL Issuance Frequency + 1 day Next Update
 0 or more 2-tuple of certificate serial number and revocation date (in UTC) Revoked certificates list
sha-1WithRSAEncryption or sha256WithRSAEncryption Issuer Signature
CRL Extensions
 Integer (Never repeated) CRL Number
c=no; Octet String (20 byte SHA-1 hash of the binary DER encoding of the Application root CA’s public key information) Authority Key Identifier
CRL Entry Extensions
Optional Invalidity Date
Must be present if one of the following: key compromise; CA compromise; affiliation changed; superseded; and cessation of operations. Absent otherwise. Reason Code
 
 
Intermediate CA’s CRL Profile
Value Field
V2(1) Version
sha-1WithRSAEncryption
or
sha256WithRSAEncryption
Issuer Signature Algorithm
Subject Distinguished Name of Issuer Issuer Distinguished Name
CRL Duration in UTC This Update
UTC; thisUpdate + 7 days ≥ nextUpdate ≥ thisUpdate + CRL Issuance Frequency + 4 hours Next Update
 0 or more 2-tuple of certificate serial number and revocation date (in UTC) Revoked certificates list
sha-1WithRSAEncryption
or
sha256WithRSAEncryption
Issuer Signature
CRL Extensions
 Integer (Never repeated) CRL Number
c=no; Octet String (20 byte SHA-1 hash of the binary DER encoding of the Application CA’s public key information) Authority Key Identifier
CRL Entry Extensions
Optional Invalidity Date
Must be present if one of the following: key compromise; CA compromise; affiliation changed; superseded; and cessation of operations. Absent otherwise. Reason Code
 
 

10.4            Profiles of OCSP

 

In IR PKI, OCSP request and response is according to rfc2560 with this section profiles.
OCSP Request Profile:
Value Field
V1(0) Version
Not Present Requester Name
List of certificate serial numbers that their revocation status are requested. Request List
Extensions
 Random Number Nonce
 
OCSP Response Profile:
Value Field
Successful | Malformed Request| internalError| Try Later Response Status
id-pkix-ocsp-basic {1 3 6 1 5 5 7 48 1 1} Response Type
V1(0) Version
Hash of Responder Public key Responder ID
Generalized Time Produced At
Response must be composed of:
·         Certificate ID
·         Certificate Status
·         thisUpdate
·         nextUpdate
List of Responses
Sha-1WithRSAEncryption {1 2 840 113549 1 1 5}
Or
sha256WithRSAEncryption
Signature Algorithm
Present Signature
Applicable certificates issued to OCSP Responder Certificates
Extensions
Will be present if nonce extension is present in the request Nonce
                                                    

10.5            GRCA Recommended Naming and LDAP Schema

 

[1] Internet X.509 public key infrastructure certificate policy and certification practices framework.
 

تاریخ ابلاغ : 2012/7/17
مصوبه : Islamic Republic of IRAN Government Root Certificate Authority
PDF file :