Makedonski Telekom CA Certificate Policy (CP) Public part of the rules defined by Makedonski Telekom AD - Skopje as a certificate authority

Transcription

1 Makedonski Telekom CA Certificate Policy (CP) Public part of the rules defined by Makedonski Telekom AD - Skopje as a certificate authority

2 Document versions Document Makedonski Тelekom CA Certificate Policy (CP) Version 1.0 Date Author: Makedonski Telekom CA Operation Authority 2

3 Content 1. INTRODUCTION Overview Document name and identification PKI participants Certification authorities Makedonski Telekom CA Registration authorities (RA) Subscribers Relying parties Other participants Certificate usage Appropriate certificate uses Prohibited certificate uses Policy administration Organization administering the document Contact person Person determining CPS suitability for the policy CPS approval procedures Definitions and acronyms PUBLICATION AND REPOSITORY RESPONSIBILITIES Repositories Publication of certification information Time or frequency of publication Access controls on repositories IDENTIFICATION AND AUTHENTICATION Naming Types of names Need for names to be meaningful Anonymity or pseudonymity of subscribers Rules for interpreting various name forms Uniqueness of names Recognition, authentication, and role of trademarks Initial identity validation Method to prove possession of private key Authentication of organization identity Authentication of individual identity Non-verified subscriber information Validation of authority Criteria for interoperation Identification and authentication for re-key requests Identification and authentication for routine re-key Identification and authentication for re-key after revocation Identification and authentication for revocation request CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS Certificate Application Who can submit a certificate application Enrollment process and responsibilities Certificate application processing Performing identification and authentication functions Approval or rejection of certificate applications Time to process certificate applications Certificate issuance CA actions during certificate issuance Notification to subscriber by the CA of issuance of certificate Certificate acceptance Conduct constituting certificate acceptance Publication of the certificate by the CA Notification of certificate issuance by the CA to other entities Key pair and certificate usage Subscriber private key and certificate usage Relying party public key and certificate usage Certificate renewal (without generating a new key) Circumstance for certificate renewal Who may request renewal Processing certificate renewal requests Notification of new certificate issuance to subscriber Conduct constituting acceptance of a renewal certificate

4 Publication of the renewal certificate by the CA Notification of certificate issuance by the CA to other entities Certificate re-key (renewal with generating a new key) Circumstance for certificate re-key Who may request certification of a new public key Processing certificate re-keying requests Notification of new certificate issuance to subscriber Conduct constituting acceptance of a re-keyed certificate Publication of the re-keyed certificate by the CA Notification of certificate issuance by the CA to other entities Certificate modification Circumstance for certificate modification Who may request certificate modification Processing certificate modification requests Notification of new certificate issuance to subscriber Conduct constituting acceptance of modified certificate Publication of the modified certificate by the CA Notification of certificate issuance by the CA to other entities Certificate revocation and suspension Circumstances for revocation Who can request revocation Procedure for revocation request Revocation request grace period Time within which CA must process the revocation request Revocation checking requirement for relying parties CRL issuance frequency (if applicable) Maximum latency for CRLs (if applicable) On-line revocation/status checking availability On-line revocation checking requirements Other forms of revocation advertisements available Special requirements regarding key compromise Circumstances for suspension Who can request suspension Procedure for suspension request Limits on suspension period Certificate status services Operational characteristics Service availability Optional features End of subscription Key escrow and recovery Key escrow and recovery policy and practices Session key encapsulation and recovery policy and practices FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS Physical controls Site location and construction Physical access Power and air conditioning Water exposures Fire prevention and protection Media storage Waste disposal Off-site backup Procedural controls Trusted roles Number of persons required per task Identification and authentication for each role Roles requiring separation of duties Personnel controls Qualifications, experience, and clearance requirements Background check procedures Training requirements Retraining frequency and requirements Job rotation frequency and sequence Sanctions for unauthorized actions Independent contractor requirements Documentation supplied to personnel

5 5.4. Audit logging procedures Types of events recorded Frequency of processing log Retention period for audit log Protection of audit log Audit log backup procedures Audit collection system (internal vs. external) Notification to event-causing subject Vulnerability assessments Records archival Types of records archived Retention period for archive Protection of archive Archive backup procedures Requirements for time-stamping of records Archive collection system (internal or external) Procedures to obtain and verify archive information Key changeover Compromise and disaster recovery Incident and compromise handling procedures Computing resources, software, and/or data are corrupted Entity private key compromise procedures Business continuity capabilities after a disaster CA or RA termination TECHNICAL SECURITY CONTROLS Key pair generation and installation Key pair generation Private Key delivery to subscriber Public key delivery to certificate issuer CA public key delivery to relying parties Key sizes Public key parameters generation and quality checking Key usage purposes (as per X.509 v3 key usage field) Private Key Protection and Cryptographic Module Engineering Controls Cryptographic module standards and controls Private key (n out of m) multi-person control Private key escrow Private key backup Private key archival Private key transfer into or from a cryptographic module Private key storage on cryptographic module Method of activating private key Method of deactivating private key Method of destroying private key Cryptographic Module Rating Other aspects of key pair management Public key archival Certificate operational periods and key pair usage periods Activation data Activation data generation and installation Activation data protection Other aspects of activation data Computer security controls Specific computer security technical requirements Computer security rating Life cycle technical controls Development controls Security management controls Life cycle security controls Network security controls Time-stamping CERTIFICATE, CRL, AND OCSP PROFILES Certificate profile Version number(s) Certificate extensions Algorithm object identifiers Name forms

6 Name constraints Certificate policy object identifier Usage of Policy Constraints extension Policy qualifiers syntax and semantics Processing semantics for the critical Certificate Policies extension CRL profile Version number(s) CRL and CRL entry extensions OCSP profile Version number(s) OCSP extensions COMPLIANCE AUDIT AND OTHER ASSESSMENTS Frequency or circumstances of assessment Identity/qualifications of assessor (internal audit) Assessor's relationship to assessed entity (internal audit) Topics covered by assessment Actions taken as a result of deficiency Communication of results OTHER BUSINESS AND LEGAL MATTERS Fees Certificate issuance or renewal fees Certificate access fees Revocation or status information access fees Fees for other services Refund policy Financial responsibility Insurance coverage Other assets Insurance or warranty coverage for end-entities Confidentiality of business information Scope of confidential information Information not within the scope of confidential information Responsibility to protect confidential information Privacy of personal information Privacy plan Information treated as private Information not deemed private Responsibility to protect private information Notice and consent to use private information Disclosure pursuant to judicial or administrative process Other information disclosure circumstances Intellectual property rights Representations and warranties CA representations and warranties RA representations and warranties Subscriber representations and warranties Relying party representations and warranties Representations and warranties of other participants Disclaimers of warranties Limitations of liability Indemnities Term and termination Term Termination Effect of termination and survival Individual notices and communications with participants Amendments Procedure for amendment Notification mechanism and period Circumstances under which OID must be changed Dispute resolution provisions Governing law Compliance with applicable law Miscellaneous provisions Entire agreement Assignment Severability

7 Enforcement (attorneys' fees and waiver of rights) Force Majeure Other provisions Closing part Appendix

8 1.1. Overview 1. INTRODUCTION The document herein is the public part of the rules defined by Makedonski Telekom AD - Skopje, as a certificate authority. The purpose of this document is to clarify the technical, procedural and organizational activities, as well as the application of the public key infrastructure (PKI of Makedonski Telekom CA) and the implemented certification procedures, which demonstrate the confidentiality of Makedonski Telekom AD- Skopje as a public key certificate authority. This document is harmonized with the requirements of the Law on Data in Electronic Form and Electronic Signature and the by-laws adopted on the basis of the said Law. The rules defined in this document are based upon the RFC 3647 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework which contains the basis of the Certification Authority rules and is harmonized with ETSI TS Policy requirements for Certification authorities issuing qualified certificates and ETSI TS V1.2.2 ( ) Policy requirements for Certification authorities issuing public key certificates. The policy describes the public rules for the following categories of qualified certificates: Certificate category Cert Usage/backup Token Usage M - mandatory, enrolled by user O - optional, enrolled by user I - issued on tokey by CA Confidentiality KS+ Qualified DS on token M Confidentiality KS Qualified DS O Confidentiality KS++ Qualified DS issued on token I Confidentiality KSSC+ Qualified DS on token M Confidentiality KSSC++ Qualified DS on token I Confidentiality KSN+ Confidentiality KSN Qualified with two key pairs on token: DS (no recovery); KE (recovery) Qualified two key pairs: DS (no recovery); KE (recovery) Confidentiality KSS+ Qualified DS,KE (no recovery) on token M Confidentiality KSS DS,KE (no recovery) 0 Confidentiality KSS++: Confidentiality KS Non-repudiation Qualified DS,KE (no recovery) issued on token Qualified NR (no recovery, non repudiation) M O I I And the following categories of normalized certificates: Certificate category Cert Usage/backup Token Usage M - mandatory, enrolled by user O - optional, enrolled by user I - issued on tokey by CA Confidentiality NSER+ Normalized KE (with recovery) on token M Confidentiality NSER Normalized KE (with recovery) O Confidentiality NSE+ Normalized KE (no recovery)on token M 8

9 Certificate category Cert Usage/backup Token Usage M - mandatory, enrolled by user O - optional, enrolled by user I - issued on tokey by CA Confidentiality NSE Normalized KE (no recovery) O Confidentiality SSL NS Confidentiality VPN NS Confidentiality CS NS Normalized DS, KE (serverauth) Normalized DS, KE (serverauth) Normalized DS (codesign) O O O 1.2. Document name and identification This document is Makedonski Telekom Certification Authority Certificate Policy. The document can also be referenced with short name as a Makedonski Telekom CA CP. The policy herein is published on url and is publicly available. The following Object Identifiers (OIDs) are assigned to certificate categories issued under this CP: Certificate policy identification Certificate category (OID) Confidentiality KS+ OID Confidentiality KS OID Confidentiality KS++ OID Confidentiality KSSC+ OID Confidentiality KSSC++ OID Confidentiality KSN+ OID Confidentiality KSN OID Confidentiality KSS+ OID Confidentiality KSS OID Confidentiality KSS++: OID Confidentiality KS Non-repudiation OID Confidentiality NSER+ OID Confidentiality NSER OID Confidentiality NSE+ OID Confidentiality NSE OID Confidentiality SSL NS OID Confidentiality VPN NS OID Confidentiality CS NS OID PKI participants Certification authorities Makedonski Telekom CA is intended for issuing public key certificates to organizations or individuals that are outside of Makedonski Telekom AD-Skopje, as well as to be used for internal needs. 9

10 Makedonski Telekom CA operates on the basis of self-signed certificate issued by itself in the process of Root Key Generation ceremony. Makedonski Telekom CA includes people who are responsible for the overall operation of the CA and people who operate and maintain the CA server and the CA software. The CA Operation Authority (OA) is responsible for the establishment and administration of the CA Practice Statement and management of CA private cryptographic keys. The OA is responsible for reviewing the operations of the RAs. The OA reports to the PMA regarding issues of CA operation. The CA Officers are responsible for the operation and administration of the CA server and CA software. The Makedonski Telekom CA is responsible for: CA key pairs generation, the secure management of CA private keys, and the distribution of CA public keys; establishing an environment and procedure for certificate applicants to submit their certificate applications; the identification and authentication of individuals or entities applying for a certificate; the approval or rejection of certificate applications; signing and issuance of X.509 certificates binding subscribers with their public keys in response to approved certificate applications; disseminating X.509 certificates through Directories; the initiation of certificate revocations, either at the subscriber s request or upon the entity s own initiative; the revocation of certificates, including issuing and publishing Certificate Revocation Lists ( CRLs ); the identification and authentication of individuals or entities submitting requests to renew certificates or seeking a new certificate following a re-keying process, and processes set forth above for certificates issued in response to approved renewal or re-keying requests; operating the CA in accordance with MK laws and this CPS; approving and assigning individuals to fulfill PKI Officer positions; reviewing and auditing RA and LRA operations within its domain; resolving disputes between end users and the CA, RA or LRA; requesting revocation of CA Officer s and RAs' certificates. When necessary, this CPS distinguishes the different users and roles accessing the CA functions. When this distinction is not required, the term CA is used to refer to the total CA entity, including the software and its operations Makedonski Telekom CA Registration authorities (RA) Makedonski Telekom CA RA service uses two general categories of RAs. The first RA category (Local Registration Authority, or LRA) includes RAs who are responsible for performing face-to-face identity proofing and user information collection to support user enrollment and routine re-keys. The second RA category (Primary Registration Authority or PRA) includes personnel who review user information and approve registration requests. LRA functions for public certificates are performed by dedicated employees from Makedonski Telekom AD - Skopje. PRA functions are performed by dedicated sales managers from Makedonski Telekom AD- Skopje. LRA officers are responsible and accountable for: 10

11 the identification and authentication of individuals or entities applying for a certificate; the identification and authentication of individuals or entities submitting requests to renew certificates or seeking a new certificate following a re-keying process, and processes set forth above for certificates issued in response to approved renewal or re-keying requests; the approval or rejection of certificate applications; verifying and confirming the identity of Subscribers; verifying data on a subscriber applications, and submitting certificate requests, key recovery requests, certificate suspension requests and certificate revocation requests to the Makedonski Telekom CA OA. PRA officers are responsible and accountable for: the approval certificate issuance; receiving from the Makedonski Telekom CA OA, and distributing, subscriber; authorization codes and assisting with subscriber activation within the prescribed time period for activation; monitoring the status of subscriber information Subscribers Subscribers of Makedonski Telekom CA are entities including natural persons (individuals) and/or legal persons (companies) that use Makedonski Telekom CA PKI services. Subscriber is a party requiring Makedonski Telekom CA certificate on behalf of one or more subjects. For example, company requiring certificate for its employees. Subject is entity identified in a certificate as the holder of the private key associated with the public key given in the certificate. The subscriber bears ultimate responsibility for the use of the private key associated with the public key certificate but the subject is the individual that is authenticated by the private key. In the case of certificates issued to individual for their own use the subscriber and subject is the same entity. Subscriber and subject (certificate holder) terms with this explicit distinction are used in this document wherever it is meaningful to do so Relying parties Relying parties are entities including natural persons (individuals) and/or legal persons (companies) that rely on a certificate and/or electronic signature verifiable with reference to a public key listed in a subject's certificate. To verify the validity of a certificate they receive, relying parties must always refer to the Makedonski Telekom CA CRL prior to relying on information in a certificate Other participants Not applicable Certificate usage Appropriate certificate uses Makedonski Telekom CA certificates may serve the following purposes: Applications requiring the use of qualified certificates in line with the Law on Data on Electronic Form and Electronic Signature of the Republic of Macedonia Article 13. Encrypt and decrypt documents in electronic form 11

12 Verify electronically signed documents Certificate holder identification Secure communication Other purposes at the request of the users and in line with the Law on Data in Electronic Form and Electronic Signature and other relevant laws in RM Prohibited certificate uses All certificates issued by the Makedonski Telekom CA shall be used in accordance with the Republic of Macedonia legislation Policy administration Organization administering the document Makedonski Telekom CA is managed by Makedonski Telekom AD - Skopje Contact person Address: Makedonski Telekom AD - Skopje Orce Nikolov b.b., Skopje Internet: cainfo@telekom.mk Person determining CPS suitability for the policy Not applicable CPS approval procedures Makedonski Telekom CA CP is developed and maintained by Makedonski Telekom CA Operations Authority, and approved by the Chief Executive Officer Definitions and acronyms Definitions: Electronic signature denotes a sequence of data in an electronic form, which are comprised in or logically related to other data in an electronic form and which are aimed at establishing the authenticity of the data and the identity of the signer. Advanced electronic signature is deemed as electronic signature if: It is exclusively and solely related to the signer; It provides the possibility of determining the signer with certainty; It is created by using data and devices for advanced signature which are under the full control of the signer, and It is related with the data to which it refers in a manner which enables the acknowledgement of any further modification of the data to which the signature refers or a modification of the logical relation of the data themselves. Time-stamp denotes an electronically signed certificate by the certificate authority, on certain data content at a specific time and date. Signer is the person who affixes an electronic signature, i.e. signs in an electronic form on his/her own behalf or on behalf of another legal or physical entity which he/she represents. Information system is the system used for compiling, sending, receiving, storing or other type of electronic data processing. 12

13 Signature-creation data are the only data used during the creation of the electronic signature, such as codes or private cryptographic keys. Signature-creation device is a configured program or machine equipment used for forming the electronic signature. Secure-signature-creation device - SSCD is: a device which provides unique, safe and confidential data on electronic signature, prevents the possibility of obtaining data on the electronic signature within a reasonable time and by means of reasonable devices from the data for verification of the electronic signature, ensure the protection from forgery of the electronic signature by using a currently available technology and provides for the signer to be able to safely guard the data on electronic signature against unauthorized access. Signature-validation data are the only data used in the course of the electronic signature validation, such as codes or public cryptographic keys. Signature-validation device for an electronic signature is a configured program or machine equipment which is utilized for validation of the electronic signature. Certificate is a certification in an electronic form which certifies the relation between the data for validation of the electronic signature with a certain person, the certificate subject and the identity of that person. Qualified certificate is a certificate containing the name or title and the country of the residence, i.e. the seat of the authority, the name or the title, i.e. the pseudonym of the subject or the title, i.e. the pseudonym of the information system bearing the designation of the subject, data for verification of the electronic signature which are related to the data for electronic signature, commencement and expiry of the certificate validity, certificate identification number, advanced electronic signature of the authority and possible limitations on the utilization of the certificate. Normalized certificate is a certificate having the same technical properties and offering the same level of confidentiality as the qualified certificate, however without the legal constraints of its intended purpose. Certificate authority is any legal or physical entity which issues certificates or provides other services relating to certificates, i.e. electronic signatures. Subject is any entity identified in the certificate as lessee of a private key related with a public key included in the certificate. Subscriber is a party requesting a certificate from a certificate authority on behalf of one or several subjects. The subscriber may also be a subject when issuing the certificate to an individual for personal use. Relying party is an entity which has reasonable confidence in the certificate. Computer user account - a computer user account denotes a set of attributes which enable access to the computer system for a certain person. Each user account is unique for each computer system, which is implemented by means of internal functions of the computer system. The basis for access to the user account is a pair of a user name and a password. The user name is a sequence of alpha-numeric characters which comprises an identification name of the user in a given computer system. Such identification name has to be unique on the level of the computer system. The password is also a sequence of alpha-numeric characters, which is known solely to the user account user. The user password for those computer systems which require a high level of security may be supplemented or replaced with a chip card. Encryption key pair denotes a pair of symmetric keys comprised of a public encryption key and an auxiliary private decryption key. It is also known as a confidentiality key pair. Private decryption key see Encryption key pair. 13

14 Private signing key see Encryption key pair. Public encryption key see Encryption key pair. Public dual-usage key certificate is a certificate which contains a public key that is used in parallel both for encryption and for verification. Public encryption key certificate is a certificate containing a public encryption key. Public signature verification key see Encryption key pair. Public signature verification key certificate is a certificate containing a public key for signature. Signature key pair is a pair of asymmetric key comprised of a private signature key and an auxiliary public key for signature verification. SSCD (Smart Card) is a smart card / token on which all key pairs can be stored. Abbreviations: A list of abbreviations, which are mentioned in this document and in the Policy, is given in the following table: Abbreviation Explanation ARL Authority Revocation List CA Certification Authorities CN Common Name X.500 CPS Certification Practice Statement CRL Certificate Revocation List DN Distinguished Name X.500 EAL MAKEDONSKI TELEKOM AD Skopje LRA FIPS PKCS #10 PKI PKIX PKIX-CMP Evaluation Assurance Level Makedonski Telekom AD - Skopje Local registration offices responsible employees from Makedonski Telekom AD -Skopje Federal Information Processing Standards Public-Key Cryptography Standard #10 Public Key Infrastructure X.509 based PKI PKIX-Certificate Management Protocols described in RFC 4510 RA Registration Authority X.509 Standard for electronic certificates, described in RFC

15 2.1. Repositories 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES Makedonski Telekom CA is publishing certification services related information in the repositories on the following addresses: Public web site: LDAPv3 directory: ldap://ldap-ca.ca.telekom.mk 2.2. Publication of certification information Makedonski Telekom CA is publishing: Issued encryption certificates Partitioned and combined Certificate Revocation Lists (CRL) CA s certificate Certification Policy End Users Agreements Application forms List of Local Registration Authorities Makedonski Telekom CA notices and announcements, and other certification services related public information 2.3. Time or frequency of publication Certificates are published immediately after they are issued as specified in Section 4.4. The CRL is published immediately after they are issued, and as specified in Section All information is published promptly after it is changed or becomes available to the CA Access controls on repositories All public information is accessible as read-only without restrictions. Repositories are additionally protected from unauthorized modifications. 15

16 3.1. Naming Types of names 3. IDENTIFICATION AND AUTHENTICATION The subject name attribute in the certificates issued by the Makedonski Telekom CA contains the subscriber s authenticated name as defined for a Common Name (CN) in a table in section Rules for interpreting various name forms. The certificate Subject attribute in the CA certificate and in certificates issued to subscribers is the form of X.501 Distinguished Name (DN) type. The DN is in the form of a X.501 UTF8String and it must be present in all issued certificates Need for names to be meaningful The set of certificate s subject DN attributes uniquely identifies each certificate holder and has meaningful values. The serialnumber attribute is, when present, used to differentiate between names where the subject field would otherwise be identical Anonymity or pseudonymity of subscribers Not applicable Rules for interpreting various name forms The subject name field is defined as the X.501 type Name (x.500 Distinguished Name), in conformity with RFC Makedonski Telekom CA subject attribute and Certificate Authority attribute in the CA certificate is: Distinguished Name component Value Country (C) МК Organization (О) Makedonski Telekom Common Name (CN) Makedonski Telekom CA The x.500 Distinguished Name in the certificates issued by the Makedonski Telekom CA takes the following format: Distinguished Name component Country (C ) Organization (O ) Organizational Unit (OU ) Organizational Unit (OU ) Common Name (CN) Serial Number (serialnumber ) Value MK Makedonski Telekom Name and tax number of the legal entity; or residential optional department / level of organization unit (in a certificates issued to legal persons) Name and surname of the certificate holder when the certificate is issued to a natural persons Fully qualified domain name or IP address when for servers, services or devices, and optional unique serial number The CRL combined list announcement is of the following type: Distinguished Name component Value Country (C) МК Organization (О) Makedonski Telekom 16

17 Common Name (CN) Makedonski Telekom CA: Certificate Revocation List The announcement of the distributed CRL is of the following type: Distinguished Name component Value Country (C) МК Organization (О) Makedonski Telekom Common Name (CN) Makedonski Telekom CA Common Name (CN) CRLn (n = ordinal number in the Registry) Serial number (serialnumber) is, if used, included in the Distinguished Name as part of the multi-valued RDN (RDN = CN + serialnumber) Uniqueness of names Makedonski Telekom CA assigns in the certificate subject a combination of Distinguished Name attributes, as defined in sections and 3.1.4, to ensure un-ambiguity and uniqueness of names Recognition, authentication, and role of trademarks Makedonski Telekom CA will strictly adhere to the rules for assigning names given under items Types of names and meaningful names. The subscribers are forbidden to request the name of the entities which would cause a breach of the intellectual and property rights of the other subscribers. Makedonski Telekom CA makes reasonable efforts to resolve disputes that may arise over the allocation of names, e.g. the CA may contact the applicant and agree that the Common Name (CN) attribute in the subject be modified, to distinguish the DN from an existing DN. Makedonski Telekom CA may at its discretion, reject, change, re-issue or revoke certificates in relation to any DN Initial identity validation Method to prove possession of private key Proof of possession of subscriber private keys is provided via a secure exchange between the CA application and PKI client applications using Certificate Management Protocols in accordance with PKIX-CMP, or PKCS#10 in accordance with RSA PKCS#10 Certification Request Syntax Standard Authentication of organization identity An organization (legal person), wishing to become Makedonski Telekom CA subscriber, must provide sufficient evidence that the organization has the identity it claims to possess. The form for obtaining qualified digital certificate for legal entities registered for the performance of activities (on behalf of a legal entity) is filled in by the legal entity s authorized person. The authorized person or the person authorized thereby submits the completed form together with their ID documents and Power of Attorney of the legal entity verified by a notary to the authorized RA given in the list of RA. Makedonski Telekom CA will verify the identity of the authorized person as defined in section Authentication of individual identity, and his authority to act on behalf of the organization as defined in section Validation of authority. Makedonski Telekom CA keeps a records of the means by which the identity of the organization and the individual authorized to act on behalf of the organization has been verified. Makedonski Telekom CA doesn t keep the copies of the identification documentation itself. 17

18 Authentication of individual identity All individuals (natural persons), wishing to become Makedonski Telekom CA subscriber, will be verified face to face. The physical person is identified by the person in charge of registration matters by viewing a valid ID card or passport and a copy of an ID card or passport of the person requesting the certificate or service. Makedonski Telekom CA keeps a records of the means by which the identity of the individual has been verified. Makedonski Telekom CA doesn t keep the copies of the identification document itself Non-verified subscriber information Not applicable Validation of authority The individual requesting a certificate in the name of an organization (legal person) must provide valid documentation for the organizational (corporate) name that should be included in the certificate, in compliance with provisions of section Authentication of organization identity. The organizational or corporate name that should be included in the certificate must be identical to the organizational full or short name as determined in the documentation provided. Subscribers making requests for public certificates for the use on their own must be authenticated as the person identified in the certificate Criteria for interoperation Makedonski Telekom CA shall be mutually recognized with the other registered CAs of the Ministry of Finance by means of a joint contract and in accordance with the LAW ON DATA IN ELECTRONIC FORM AND ELECTRONIC SIGNATURE and all relevant bylaws in the Republic of Macedonia. Procedures and practices of cross-certified CAs shall be materially equivalent to the Makedonski Telekom CA procedures and practices defined in this Certificate Policy. The Makedonski Telekom CA defines detailed requirements on a case-by-case basis Identification and authentication for re-key requests Identification and authentication for routine re-key Routine rekeying takes place when the validity of the certificate or private key usage period expires. For the certificates issued and managed in accordance with PKI-CMP, a new key and its associate certificate will be generated automatically. Subscribers are authenticated using their valid digital signature key pairs. The subscribers using certificates issued and managed in accordance with PKIX#10, are authenticated as specified in sections Authentication of organization identity and Authentication of individual identity after expiration of the contract. During the Contract the new key and its associate certificates will be generated as specified in section without subscriber s certificate application and authentication Identification and authentication for re-key after revocation Subscribers requesting re-key after revocation are authenticated as specified in sections Authentication of organization identity and Authentication of individual identity. This verification is performed prior to the re-key a certificate issuance. 18

19 3.4. Identification and authentication for revocation request Revocation requests can be made by the subscriber or certificate holders by sending a signed revocation application by surface mail or fax, in person in the CA registration authority office, or by digitally signed request, which shall be signed with the private signature key of the subject requesting revocation. Authorized individuals requesting a revocation via a signed electronic communication are authenticated on the basis of their digital signature, even when the private signing key used is suspected of having been compromised. Otherwise, authorized individuals are authenticated based on information contained in the subscriber s file or as provisioned in sections Authentication of organization identity and Authentication of individual identity. 19

20 4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS Certificate Application Who can submit a certificate application Certification application for public certificates can submit: any individual (natural person) who fulfills the requirements specified in the registration form, Makedonski Telekom CA Certificate Policy and relevant End-User Agreement; any organization (legal person) that fulfills the requirements specified in the registration form, Makedonski Telekom CA Certificate Policy and relevant End-User Agreement and has valid contract between CA and Client Corporation Enrollment process and responsibilities Makedonski Telekom CA issues certificates only after subscriber s identity validation and successful completion of the registration process. The main steps of the certificate enrollment process are: Subscriber submits signed registration form and provides valid identification documentation Subscriber accepts the Makedonski Telekom CA Certificate Policy and his obligations by signing the End-User Agreement Certification request is approved by the Makedonski Telekom CA Registration Authority Registration Authority submits certification request to the Makedonski Telekom CA OA Makedonski Telekom CA OA creates a user with appropriate certificate profile and generates Activation Codes, which consist of a Reference Number and Authorization Code. BothActivation Codes are needed by the end user to request a certificate from a CA application. Activation Codes for certificate enrollment are send to a certificate's holder: o o Reference Number is ed to the subscriber on the address provided on the certificate registration form. Authorization Code is sent to subscriber using surface mail; SMS or personally provided at CA registration authority offices printed in security envelop message. The subscriber uses Activation Codes to request his certificate from the CA application, using client application provided by the Makedonski Telekom CA, or internet browser. List of supported client applications and Internet browsers is published, together with user guides; on the Makedonski Telekom CA public web page listed in section 2.1 Repositories Certificate application processing Performing identification and authentication functions Makedonski Telekom CA performs identification and authentication forms as defined in sections Authentication of organization identity and Authentication of individual identity Approval or rejection of certificate applications Certification request for Makedonski Telekom CA certificate will be approved if all of the following requirements are met: The subscriber has submitted the registration form and presented identification documentation in person; 20

21 The applicant has appropriate authorization, if acting on behalf of an organization (legal person); Registration form, provided identification documentation and authorizations has been verified successfully, The requestor has signed End-User Agreement or has valid contract between Makedonski Telekom CA and legal person. In the case that any of the criteria above is not met, or if a reasonable doubt exists that a requestor violates the provisions of this document, End-User Agreement or applicable legislation, the Makedonski Telekom CA Registration Authority will reject a certification request. Makedonski Telekom CA reserves the right to reject certification request without giving reasons Time to process certificate applications Certification request application and identification documentation are verified and processed during requestor s presence in the Makedonski Telekom CA Registration Authority office Certificate issuance CA actions during certificate issuance The Makedonski Telekom CA application will upon receipt of a certification request: verify the validity of activation codes included in the request; verify that a subscriber possesses private key associated with the public key sent for certification, as provisioned in section Method to prove possession of private key; verify the certificate requests for compliance with the protocol (PKIX-CMP or PKCS#10) technical specification. Issue the requested certificate if all of the above conditions are met Notification to subscriber by the CA of issuance of certificate Makedonski Telekom CA application will present to the requestor issued certificate immediately, so there is no need for additional notification Certificate acceptance Conduct constituting certificate acceptance The certificate enrollment procedure depends on the certificate type. SSCD (smart card / Token) is delivered to the subscriber personally or by registered mail to the subscriber s address if it concerns a physical person, whereas for legal persons it is delivered to the address of the legal entity or by personal collection; The Confidentiality KSN and Confidentiality KSN+ certificates are enrolled using a PKIX- CMP protocol and appropriate application; Confidentiality KS, Confidentiality KS+, Confidentiality CS NS, Confidentiality SSL NS, and Confidentiality VPN NS certificates are enrolled using Internet Browser application. The instructions for certificate enrollment can be found on the Makedonski Telekom CA WEB page at the address The subscriber will also receive instructions by when he/she receives the reference number. The instructions themselves are subject to change in accordance with the current changes within the PKI and are not an integral part of this Policy. For successful certificate enrollment, the last published instructions are relevant. The subscriber can enroll certificate (this does not refer to the SSCD certificates) only with valid activation data: reference number and authorization code. The lifetime of activation data 21

22 is limited to 30 days. Upon the expiry of the activation data, the registration procedure needs to be repeated. In the case of unsuccessful enrollment process, certificate holder shall report the problem to the Makedonski Telekom CA RA (see RA contact information in section Contact person) Publication of the certificate by the CA Makedonski Telekom CA will publish all certificates with encryption bit set in public LDAP directory specified in section 2.1. Repositories. Certificates used only for digital signatures (only digital signature of non-repudiation bit set) will not be published Notification of certificate issuance by the CA to other entities Makedonski Telekom CA will not notify any other entities Key pair and certificate usage Subscriber private key and certificate usage The Makedonski Telekom CA is issuing certificates that can support a number of key usages. This support is provided by the inclusion of the appropriate key usage extensions. Subscribers shall use certificates in accordance with keyusage and extkeyusage X.509 certificate extensions and for purposed defined in section Appropriate certificate uses. Subscribers must keep their private key secure, and take precautions to prevent key compromise and unauthorized usage Relying party public key and certificate usage Relying party shall restrict reliance on public keys contained in certificates issued by the Makedonski Telekom CA to appropriate use as detailed in section Appropriate certificate uses. Relying part is also responsible for: Be aware of the limitations of the certificate and the CA liability as detailed in this Policy. Ensure that the certificate has not been revoked by accessing on-line, any and all applicable Certificate Revocation Lists (CRLs). Immediately notify the CA of any suspected or known misuse of any certificate issued by the CA Certificate renewal (without generating a new key) Certificate renewal is a process in which a CA issues new certificate for the same subject and public key. The certificate renewal in is not allowed and supported by the Makedonski Telekom CA Circumstance for certificate renewal Not supported as stated in 4.6. Certificate renewal Who may request renewal Not supported as stated in 4.6. Certificate renewal Processing certificate renewal requests Not supported as stated in 4.6. Certificate renewal Notification of new certificate issuance to subscriber Not supported as stated in 4.6. Certificate renewal. 22

23 Conduct constituting acceptance of a renewal certificate Not supported as stated in 4.6. Certificate renewal Publication of the renewal certificate by the CA Not supported as stated in 4.6. Certificate renewal Notification of certificate issuance by the CA to other entities Not supported as stated in 4.6. Certificate renewal Certificate re-key (renewal with generating a new key) Certificate re-key is a process in which a CA issues new certificate to a subscriber. New certificate contains the same subject information as the old certificate and new public key Circumstance for certificate re-key Certificate re-key takes place: after a certificate revocation; after a certificate has expired or key usage period has expired Who may request certification of a new public key Certificate re-key may request subscriber, certificate holder or authorized representative who requested initial certificate issuance Processing certificate re-keying requests Certificate re-key of the certificates managed using PKIX-CMP is performed automatically before the holders signing private key expires. If the private key expires before the certificate re-key took place, the process is the same as for initial certificate request. Certificate re-key of the certificates managed using PKCS#10 is performed in the same manner as initial certificate request after expiration of the contract. During the Contract the new key and its associate certificates will be generated as specified in section without subscriber s certificate application and authentication Notification of new certificate issuance to subscriber As described in section Notification to subscriber by the CA of issuance of certificate Conduct constituting acceptance of a re-keyed certificate As described in section Conduct constituting certificate acceptance Publication of the re-keyed certificate by the CA As described in section Publication of the certificate by the CA Notification of certificate issuance by the CA to other entities As described in section Notification of certificate issuance by the CA to other entities Certificate modification Certificate modification is procedure which facilitates subscribers to request a certificate with modified information. Certificate modification mandates certificate re-key and is processed as initial certification request. 23