CERTIFICATION PRACTICE STATEMENT

Version 2.1

IMPORTANT NOTICES

This Certification Practice Statement (‘CPS’) describes the policies, practices and procedures employed by DIGICERT Sdn Bhd (‘DIGICERT’) to perform Certification Authority services.

DIGICERT maintains sole rights and property to this CPS. DIGICERT disclaims any warranty whatsoever in relation to the use of this CPS by parties not covered within DIGICERT’s public key certification services described in CPS Part 2.

Subscibers of DIGICERT’s public key certification services are advised to become familiar with public key cryptography, digital signatures and certificates; the requirements under the Digital Signature Act 1997 (‘DSA’) and the Digital Signature Regulations 1998 (‘DSR’); and the rights, duties and liabilities of the licensed Certification Authority (‘CA’), the subscriber and the relying party before applying for a certificate from DIGICERT.

Before the subscribers can communicate the certificate to others, the subscribers must accept the certificate. By accepting the certificate, they are making important representations.

Subscribers are responsible for deciding on the class of certificate that is appropriate for their needs. Relying parties are responsible for deciding on whether to rely on certificates issued by DIGICERT. DIGICERT recommends that relying parties confirm the validity of the certificates by checking with the recognised repositories before relying upon a digital signature.

Subscribers can generate their own key pair or request for the generation of key pair from DIGICERT. DIGICERT is not responsible to keep the subscribers’ private keys. Subscribers must protect their private keys in a trustworthy manner and notify DIGICERT immediately upon any compromise of their private key.

Subscribers may be informed by DIGICERT of the need to re-sign the data with the digital signature, as the value of the digital signature decreases with time.

The provisions of this CPS, which may be amended from time to time, are incorporated into all certificates that refer to this CPS, and which are issued on or after the effective date of publication of this CPS.

This CPS shall not be reproduced, whether in full or in part, in any form whatsoever or be stored in any reproducible form whether electronic or otherwise without the prior consent of DIGICERT. This consent must be obtained by contacting:

DIGICERT Sdn Bhd
Lot 2-1 Enterprise 1
Technology Park Malaysia , Bukit Jalil
57000 Kuala Lumpur, Malaysia
Tel: +603 8996 1600
Fax: +603 8996 1054
Email: cps-request@digicert.com.my

TABLE OF CONTENTS

1.0 Preface

1.1 Overview

1.2 Citation of CPS

1.3 Notation format

1.4 Publication and notification

1.5 Amendment of CPS

1.6 CPS approval procedures

1.7 Customer service and acknowledgement

1.7.1 Acknowledgement

1.7.2 Customer service contact details

1.8 Acronyms and abbreviations

2.0 DIGICERT certification infrastructure

2.1 Trust infrastructure

2.2 Certificate classes

2.2.1 Class 1 certificates

2.2.2 Class 2 (basic) certificates

2.2.3 Class 2 (enhanced) certificates

2.2.4 Server certificates

2.3 Certificate profile

2.3.1 Version number

2.3.2 Certificate extensions

2.3.3 Algorithm object identifiers

2.3.4 Name forms

2.3.5 Processing semantics for the critical certificate policy extension

2.4 CRL profile

2.4.1 Version number(s)

2.4.2 CRL and CRL entry extensions

3.0 DIGICERT operational requirements

3.1 Certificate application

3.1.1 Key generation and protection

3.1.2 Certificate application

3.1.3 Validation of certificate applications

3.1.4 Notice of approval

3.2 Certificate issuance

3.2.1 Certificate acceptance

3.2.2 Refusal to issue a certificate

3.2.3 Time of certificate issuance

3.2.4 Certificate validity and operational periods

3.2.5 Representation upon issuance of certificates

3.3 Usage of certificates

3.4 Certificate revocation and suspension

3.4.1 Revocation by DIGICERT

3.4.2 Revocation by subscriber

3.4.3 CRL issuance frequency

3.4.4 Revocation status

3.5 Certificate expiration

3.5.1 Notice of expiration

3.5.2 Effect of certificate expiration

3.5.3 Renewal of certificate

3.6 Security audit procedures

3.6.1 Types of event recorded

3.6.2 Frequency of processing log

3.6.3 Retention period for audit log

3.6.4 Protection of audit log

3.6.5 Audit log backup procedures

3.6.6 Audit collection system

3.7 Records archival

3.7.1 Retention period for archive

3.7.2 Protection of archive

3.7.3 Archive backup procedures

3.7.4 Archive collection system (internal or external)

3.7.5 Procedures to obtain and verify archive information

3.8 Compromise and disaster recovery

4.0 Security controls

4.1 Physical controls

4.2 Procedural controls

4.2.1 Trusted roles

4.2.2 Number of persons required per task

4.2.3 Identification and authentication for each role

4.3 Personnel controls

4.3.1 Personnel Management

4.3.2 Background check procedures

4.4 Key management controls

4.4.1 Key pair generation and installation

4.4.2 Private key protection

4.5 Logical access controls

4.6 Information security controls

4.6.1 Computer security requirements

4.6.2 Computer security rating

4.7 Cryptographic module engineering controls

5.0 General provisions

5.1 Obligations

5.1.1 CA obligations

5.1.2 Subscriber obligations

5.1.3 Relying party obligations

5.2 Liability

5.2.1 CA liability

5.3 Financial responsibility

5.3.1 Fiduciary relationships

5.4 Interpretation and enforcement

5.4.1 Governing law

5.4.2 Severability, survival, merger, notice

5.4.3 Dispute resolution procedures

5.5 Fees

5.5.1 Certificate issuance or renewal fees

5.6 Publication and Repository

5.6.1 Publication of CA information

5.6.2 Frequency of publication

5.6.3 Repositories

5.7 Compliance audit

5.7.1 Frequency of entity compliance audit

5.7.2 Identity/qualifications of auditor

5.7.3 Audit coverage

5.7.5 Actions taken as a result of deficiency

5.7.6 Communication of results

5.8 Confidentiality

5.8.1 Types of information to be kept confidential

5.8.2 Types of information not considered confidential

5.8.3 Disclosure of certificate revocation/suspension information

5.8.4 Release to law enforcement officials

5.9 Intellectual property rights

5.10 Limitations on usage of services

5.11 Conflict of provisions

5.12 Interpretation and validity of this CPS

5.13 Force Majeure

6.0 Appendices

6.1 Glossary of terms

1.0 Preface

1.1 Overview

The purpose of this CPS is to describe the policies, practices and procedures employed by DIGICERT to perform Certificate Authority services. It outlines the procedures of issuing, managing, suspending, revoking and renewing certificates. The CPS is intended to legally bind all parties that intend to use and validate certificates; governing their rights, duties and liabilities in this contract.

The CPS is divided into 6 sections:

Part 1 provides preliminary information pertaining to this CPS.
Part 2 describes the trust model and the key components within DIGICERT’s Public Key Infrastructure (‘PKI’). This section further elaborates on the important functions of each entity and its role within the PKI.
Part 3 explains the procedures and operational requirements the application, issuance, revocation and renewal of certificate. A life-cycle approach is used to describe the certification process.
Part 4 demonstrates the critical security measures and controls employed by DIGICERT in providing trustworthy certification services.
Part 5 outlines the important legal provisions. In this section, DIGICERT’s obligations, limitations and warranties will be highlighted.
Part 6 contains the definition of specific technical and legal terminology used throughout this CPS.

It is important that potential subscribers fully understand the contents of this CPS before submitting a certificate application.

1.2 Citation of CPS

This CPS is to be cited in other documents as "DIGICERT Certification Practice Statement" or the "DIGICERT CPS". It is cited as "CPS" or "CPS Part _" within this document. The version number of the CPS must be appended after the above citation phrase (e.g. Version 1.1). A Uniform Resource Locator (‘URL’) which points to the latest CPS available at DIGICERT’s web site must be included in the citing document.

1.3 Notation format

The following notation format will apply throughout this CPS:

electronic references, all email addresses, URL references and other similar items will be in italics (e.g. customercare@digicert.com.my , http://www.digicert.com.my )
all references to a particular part or section of this CPS will be in bold (e.g. CPS Part 3); and
the first instance of key words referred to in the Glossary of Terms in CPS Part 6 will be underlined (e.g. digital signature, Certification Authority).

1.4 Publication and notification

This CPS can be obtained:

in electronic form via DIGICERT’s Internet servers at http://www.digicert.com.my

To maintain integrity of this document, the web-based version of the CPS must be viewed using SSL-enabled browsers, e.g. Netscape Navigator 4.05 and above, or Microsoft Internet Explorer 4.73 and above.
in electronic form via email from CPS-request@digicert.com.my

The electronic copy of this CPS is currently available in Microsoft Word 95 v7.0 format only.
in paper form by contacting:

DIGICERT Sdn Bhd
Lot 2-1 Enterprise 1
Technology Park Malaysia , Bukit Jalil
57000 Kuala Lumpur, Malaysia
Tel: +603 8996 1600
Fax: +603 8996 1054

Attn: CPS Request

Business Inquiries, Certification services, PKI and technical inquiries:

Email: customercare@digicert.com.my

If the CPS is requested in paper form, all costs of printing and mailing will be borne by the requestor.

From time to time DIGICERT may make changes to its practices in order to improve its services. Some of these changes may require an amendment to the CPS. These updates will be posted at DIGICERT’s web site at URL http://www.digicert.com.my/CPS/updates. Please refer to CPS Part 1.5 for details on amendment of the CPS.

1.5 Amendment of CPS

DIGICERT reserves the right to amend this CPS at any time (prospectively and not retroactively). Amendments to the CPS will be made available either as an amended version of the CPS or retrospectively can be posted in the Notices section of DIGICERT’s web site at the following URL http://www.digicert.com.my/CPS/updates. These amendments shall supersede any conflicting provisions of the referenced version of the CPS.

The amendments will become enforceable automatically within fourteen (14) working days of this CPS being made available at the DIGICERT’s web site unless DIGICERT explicitly states otherwise or issues a notice of withdrawal prior to the end of the fourteen (14) day period.

1.6 CPS approval procedures

This CPS and any subsequent changes are approved by the Director of DIGICERT.

1.7 Customer service and acknowledgement

1.7.1 Acknowledgement

Prior to applying for a certificate and accepting the terms and conditions of this CPS, the subscribers acknowledge that they have been advised to have prerequisite knowledge regarding the following information:

public key cryptography;
digital signatures and certificates;
the requirements under the DSA and the DSR; and
the rights, duties and liabilities of the licensed Certification Authority (‘CA’), subscriber and relying party.

The subscribers can obtain the above information or documentation from DIGICERT.

1.7.2 Customer service contact details

Subscribers are advised to consult DIGICERT’s web site at http://www.digicert.com.my for relevant information and assistance. A list of terms and definitions are also included in CPS Part 6.1 to assist the subscribers.

For further assistance, please contact:

DIGICERT Sdn Bhd
Lot 2-1 Enterprise 1
Technology Park Malaysia , Bukit Jalil
57000 Kuala Lumpur, Malaysia
Tel: +603 8996 1600
Fax: +603 8996 1054

Business inquiries, Certification services, PKI and technical inquiries:

Email: customercare@digicert.com.my

1.8 Acronyms and abbreviations

ARL	Authority Revocation List
CA	Certification Authority
CPS	Certification Practice Statement
CRL	Certificate Revocation List
DSA	Digital Signature Act 1997
DSR	Digital Signature Regulations 1998
DN	Distinguished Name
FIPS	Federal Information Processing Standard
FTP	File Transfer Protocol
HTTP	Hypertext Transfer Protocol
HTTPS	Hypertext Transfer Protocol with SSL
IP	Internet Protocol
ISO	International Standard Organisation
ITU	International Telecommunications Union
PIN	Personal Identification Number
PKCS	Public Key Cryptography Standard
PKI	Public Key Infrastructure
RA	Registration Authority
RP	Registration Personnel
RSA	Rivest, Shamir, Adleman (see CPS Part 6.1 for definition)
SSL	Secure Socket Layer
URL	Uniform Resource Locator
WWW	World Wide Web
X.509	ITU-T standard for certificates format

2.0 DIGICERT certification infrastructure

2.1 Trust infrastructure

DIGICERT’s public key certification services are intended for local and foreign organisations and individuals (end-entities) to conduct secure electronic commerce in the open communication network. To achieve this objective, three key aspects must be adequately addressed:

a robust PKI trust model to facilitate the management, control, issuance, revocation and renewal of digital certificates;
the effective use of digital signatures in ensuring non-repudiation, authentication and integrity of electronic documents and transactions; and
the uniformity of service and standards across DIGICERT and its appointed RAs.

A simplified overview of DIGICERT’s PKI model can be diagrammatically represented as follows:

Figure 1 DIGICERT PKI trust model

Controller of CA

The function of the Controller of CA (‘the Controller’) is conceived under the DSA. The Controller is designated by the Minister to monitor, regulate and ensure the legitimacy of CA operations in Malaysia.

The Office of the Controller is the regulatory agency established under the jurisdiction of the Ministry of Communications and Multimedia Commissions. It is fully empowered to issue licences to CAs and certificates of recognition to Repository and Date/Time stamp service providers and Foreign CA. The Office of the Controller is not an entity in DIGICERT’s PKI hierarchy.

DIGICERT Sdn Bhd (Licensed CA)

DIGICERT is a licensed CA operating in compliance with the requirements of the DSA and the DSR. In electronic commerce, trust involves the combination of secure technology with reliable, visible processes for the identification and authentication of all parties. DIGICERT uses a trustworthy certificate management system (see CPS Part 4) to provide public key certification services to its subscribers.

The policies and practices adopted by DIGICERT are as important as the security attributes of the certificate management system. DIGICERT ensures that the policies and practices conform to industry standard DIGICERT’s public key certification services have been designed to address the requirements of a diverse group of users as well as to comply with the DSA and DSR. This CPS sets out DIGICERT’s practices to ensure the uniformity of its services and standards. DIGICERT’s RAs will operate in accordance with the requirements of this CPS.

Figure 2 DIGICERT PKI HIERARCHY

DIGICERT Root CA is owned and operated by DIGICERT. It is used to issue certificates to Primary CA. The initial Root key length is 1024 bits and it is created using a trustworthy device complying with the requirement of the DSA.

DIGICERT Root CA and other issuing CA are also owned and operated by DIGICERT. The key length is 2048 bits and it is created in a trustworthy environment. These Root CAs are categorised according to the certificate policies. Therefore, there can be a chain of certificates in support of each digital signature.

DIGICERT acts as the main naming authority in the PKI structure. The naming convention for all subjects of certificates registered through RAs will be determined by DIGICERT. The naming convention for Enterprise CA will be determined by DIGICERT on request from the respective Enterprise CA.

If the recipient does not know the CA of the signer of a given message, the recipient can search for the CA’s certificate from the recognised repositories. Recipients are also advised to refer to the Controller’s web site to view the CA’s licence and disclosure record.

Registration Authorities (RAs)

RAs are trusted entities appointed by DIGICERT to assist subscribers in applying for certificates, to approve certificate requests and/or to help DIGICERT in revoking certificates. The functions that the RAs shall carry out vary from case to case but shall also include personal authentication, token distribution, revocation reporting, name assignment and subscribers key generation.

The organisations that are appointed as Registration Authority (RA) for DIGICERT Sdn. Bhd. shall be officially published on DIGICERT’s website and other printed materials deemed necessary ad copyrighted by DIGICERT. The list of DIGICERT’s Registration Authorities is available at http://www.digicert.com.my/ra.htm

Recognised Repository

The repository service is fundamental and critical to the operation of an open PKI. DIGICERT will operate as a recognised repository that complies with the requirement of the DSA and the DSR. The repository is a publicly accessible collection of databases containing the certificates of its subscribers, the most recent Certification Revocation List (‘CRL’) and DIGICERT’s Root certificate. DIGICERT’s disclosure records are maintained by the Controller.

DIGICERT will promptly publish the certificates, CRL and other information consistent with this CPS, the DSA and the DSR.

Enterprise CA

In a distributed PKI model, organisations may wish to become the issuer of end-entity certificates. An Enterprise CA shall be the party who accepts applications, verifies, issues and revoke end-entity client certificates, subject to the agreement between Digicert and the party being the Enterprise CA.

Enterprise CA has the authority to act as their own RA.

End-entities

End-entities are subscribers or relying parties of CA services. They could be individuals or organisations who hold and/or rely on digital certificates in electronic transactions. End-entity need not necessarily be a natural person, it could also be a certificate using system such as a secure web server. Each end-entity could own as many certificates as it needs and may use them for different purposes.

2.2 Certificate classes

2.2.1 Class 1 certificates (Digisign ID)

Attribute	Details
Level of trust	Low
Assurance	The subscriber's name is a unique and unambiguous entry in DIGICERT’s repository. Class 1 certificates do not provide assurance on the identity of the subscriber.
Issued to	Malaysian and foreign individuals.
Validation	Simple email validation is performed to establish the validity of the email address supplied in the application form of the subscriber.
Possible usage	Class 1 certificates are used for rudimentary security requirements during web browsing and email exchange. They provide assurance that replies to emails are from the same source. They also provide assurance that the email address of the named subscriber is valid. This helps eliminate resource wastage as persons who provide feedback in the form of emails can filter out non-existent addresses.

2.2.2 Class 2 certificates (Individuals)

Attribute	Details
Level of trust	Intermediate / High (depending on the media user)
Assurance	The subscriber is not a falsely created person insofar as the records of the subscriber’s identity are maintained by reliable and independent third parties. RAs and enterprise CA provide that the subscriber is as portrayed by the information provided by government agencies (i.e. National Registration Department, Immigration Department etc). Trust is based on confirmation of the subscriber’s identity. This is done through the physical presentation of the identification documents. For example, the RA could request for the original identification document (see CPS Part 3.1.2). All material representations made by the subscriber to DIGICERT, including all information known to the subscriber and represented in the certificate, shall be accurate and complete to the best of the subscriber’s knowledge.
Issued to	Malaysian and foreign individuals (aged 18 years and above).
Validation	Strict verification and authentication by the CA, RA or its appointed agents is required for certificates issued in smart card, virtual smart card (floppy disk) or any other applicable tokens. Confirmation is based upon the official identification document issued by government agencies. The reliability of the information is determined at the sole discretion of the CA, RAs or Enterprise CA.
Possible usage	Class 2 individual certificates are used for communications requiring various levels of security. Some possible applications include on-line registration via the web, validation of user-identity for downloading of software or software upgrades and communication of user-ID creation within an organisation.

2.2.3 Class 2 certificates (Organisation)

Attribute	Details
Level of trust	High.
Assurance	The subscriber is indeed the organisation that owns the secure server and the server has a valid URL as portrayed by the information contained in the certificate. However, the assurance provided is only correct at the time of the application for the certificate. Any subsequent changes to this information will only be known when it is communicated to DIGICERT.
Issued to	Malaysian and foreign legal entities.
Validation	Strict verification and authentication by the CA, RA or its appointed agents is required. The subscriber must appear before the Registration Officer at DIGICERT along with supporting documentation to prove ownership of the specified domain name of the web service (see CPS Part 3.1.2). The Registration Officer must be convinced of the validity and legitimacy of the legal entity as claimed by the documentation produced.
Possible usage	Class 2 certificates (organisation) are used for high-level security requirements. Examples of applications include the authentication of servers that contain private or confidential data, electronic commerce including Electronic Data Interchange (EDI) and electronic banking.

2.3 Certificate profile

This section describes the profile of certificates issued by DIGICERT. Some of the important elements of this profile will be highlighted. This enables users of this CPS to understand the structure of a certificate and identify possible applications to take advantage of this structure.

Certificate format version			Version 3
Certificate serial number			12345678
Digital signature algorithm identifier for CA			RSA with MD5/SHA-1
CA distinguished name			c=MY, o=DIGICERT Sdn Bhd
Validity period			As per business contract terms requires but not exceeding three years as sanctioned by DSA 1997 Section 59. Most common validity period applies is either 1 year or 2 years or 3 years. e.g. 2 years validity: start = 01/01/2005 end = 01/11/2007
Subject distinguished name			c=MY, o=DIGICERT Sdn Bhd, cn=Ali (with enhance option)
Subject public key information			RSA
CA unique identifier			OPTIONAL
Subject unique identifier			1.NRIC Number; or 2. Passport Number; or 3.Any Other Acceptable Unique Identifier.
Type	Criticality	Value	Standard extensions

Type	Criticality	Value	Standard extensions
CA signature

Figure 3 X.509 v3 Certificate format

All the fields of the X.509 version 3 certificate format will be used except for following:

issuer unique identifier.

2.3.1 Version number

DIGICERT’s certificates adopt the X.509 version 3 standard.

2.3.2 Certificate extensions

DIGICERT issues certificates that comply with the X.509 (Amendment 1 to ISO / IEC 9594-8:1995) certificate format (see Figure 3). This standard provides DIGICERT with management and administrative controls to ensure that the application of the certificates is consistent with its policies. Such control can be achieved by defining the policies in the certificate extensions. A standard Object Identifier indicates the function of each extension.

Each ISO / IEC 9594-8:1995(E) extension comprises two fields:

Criticality; and
Value.

The ‘Criticality’ field is a single-bit toggle flag. When set to true, this indicates that the corresponding ‘Value’ field contains data that cannot be ignored by an application. For humans, this translates into understanding the data within the ‘Value’ field and having the knowledge of handling these data. For example, it could contain a disclaimer on the use of the certificate or a URL that points to a location where this information is available. When set to false, it indicates that the data within the ‘Value’ field can be ignored.

The ‘Value’ field holds any necessary data that is appended to the certificate.

As described previously, the X.509 "Amendment 1 to ISO / IEC 9594-8:1995" defines a number of extensions. These extensions can be categorised into the following four groups:

Key Information Extensions

These extensions define the usage of a public key pair and certificate.

Policy Information Extensions

These extensions define a means for the CA to specify the method of interpretation and the use of the certificate. There are 2 extensions in this group:

Certificate policy extension (see CPS Part 2.3.6).

Policy mapping extension serves a similar purpose to the certificate policies extension. However, it applies only to cross certificates. This field allows an application to search and establish a set of consistent policies across multiple CAs.

User and CA Attribute Extensions

These extensions provide a means of specifying additional information regarding the subscriber and the CA that issued the certificate.

Certification Path Extensions

These extensions are used in cross-certified environments e.g. where two CAs cross-certify each other. They allow CAs to limit third-party trust in such an environment. This group can be subdivided into:

Basic constraint extension specifies whether the subject of the certificate shall act as a subscriber only or as both a subscriber and a CA.
Name constraints extension
Policy constraints extension

A number of X.509 version 3 certificate extensions are included in certificates issued by DIGICERT. These are outlined in CPS Part 2.3.2.1. The X.509 version 3 certificate extensions, which are never present in certificates issued by DIGICERT, are outlined in CPS Part 2.3.2.2.

2.3.2.1 Supported Extensions

The following certificate extensions are used in DIGICERT PKI :

Extension	Criticality	Optional	Notes
AuthorityKeyIdentifier	No	No	contains a 20 byte hash of the s ubjectPublicKeyinfo in the CA certificate only element [0] AuthorityKeyIdentifier is filled.
SubjectKeyIdentifier	Yes	No	· contains a 20 byte hash of the subjectPublicKeyInfo in the CA certificate
KeyUsage	Yes	No	· elements [5] keyCertSign and [6] cRLSign are set for CA certificate
PrivateKeyUsagePeriod	No	No	· notafter is always used · notbefore is always used
SubjectAltName	No	Yes	· GeneralName – choices [0], [3] and [5] are not implemented.
BasicConstraints	Yes	No	· only the CA Boolean is used
CertificatePolicies	Yes	No	· only policyIdentifier element is supported with up to 10 OlDs · policyQualifier s contains URL indicating the location of DIGICERT CPS
CRLDistributionPoints	No	No	· only 1 distribution point name is included in each certificate · only element [0] (distribution point) is used and includes the full DN

2.3.2.2 Unsupported Extensions

The following X.509 version 3 certificate extensions are optionally used whenever applicable in this PKI:

extended key usage;
policy mappings;
name constraints;
policy constraints;
issuer alternative name; and
subject directory attributes.

2.3.3 Algorithm object identifiers

Algorithm	Object Identifier
RSA-with-SHAl	1 2 840 113549 1 1 5
RSA-with-MD5	1 2 840 113549 1 1 4

2.3.4 Name forms

The Distinguished Name (‘DN’) and subject DN fields contain the full X.500 DN of the certificate issuer or certificate subject. If the SubjectAltName extension is present in a certificate, it contains the certificate subject's rfc822Name with an optional email address are used.

2.3.5 Processing semantics for the critical certificate policy extension

The only certificate extension, which shall be identified as critical in certificates issued by this CA, is the CRLDistributionPoints extension. The CRL or ARL will be retrieved from the CRL distribution point directory entry indicated in the certificate.

2.4 CRL profile

The following fields of the X.509 version 2 CRL format are used in this PKI:

version: set to v2;
signature: identifier of the algorithm used to sign the CRL;
issuer: Distinguished Name of the CA issuing the CRL;
this update: time of CRL issue;
next update: time of next expected CRL update; and
revoked certificates: list of revoked certificate information.

2.4.1 Version number(s)

CRLs issued by DIGICERT are X.509 version 2 CRL.

2.4.2 CRL and CRL entry extensions

A number of X.509 version 2 CRL and CRL entry extensions are used in this PKI. These are outlined in CPS Part 2.4.2.1. The X.509 version 2 CRL and CRL entry extensions which are never present in CRLs issued by DIGICERT are outlined in CPS Part 2.4.2.2.

2.4.2.1 Supported Extensions

The following CRL and CRL entry extensions are used in this PKI:

X.509 v2 CRL Extension	Criticality	Optional	Notes
AuthorityKeyIdentifier	No	No	only element [0] (AuthorityKeyIdentifier)is filled in contains a 20 byte hash of the subjectPublicKeyInfo in the CA certificate
CRLNumber	No	No	Incremented each time a particular CRL is changed
ReasonCode	No	No	CRL entry extension – only reason codes [0], [1], [3], [4] and [5] supported [6],[2]
IssuingDistributionPoint	No	No	Element [0] (distributionPoint) includes the full DN of the distribution point Element[1] (onlyContainsUserCerts) is included for CRLs Element [2] (onlyContainsCACerts) is included for s Element [1] and [2] are never present together in the same revocation list Elements [3] and [4] are not used.

2.4.2.2 Unsupported Extensions

The following X.509 version 2 CRL extensions are not used in this PKI:

issuer alternative name;
invalidity date;
certificate issuer; and
delta CRL indicator.

3.0 DIGICERT operational requirements

3.1 Certificate application 3.1.1 Key generation and protection

Subscribers are given the option to either generate their own key pairs or request DIGICERT to generate the key pairs. Subscribers who choose to generate their own key pairs should be responsible for ensuring that the key pairs are generated in a trustworthy manner. When DIGICERT creates subscriber key pairs. DIGICERT warrants that it will not keep or escrow a copy of the subscriber’s private key. The following key generation options are available:

Certificate class	Options available
Class 1 (Digisign ID)	CA generates key.
Class 2 (Digisign ID Basic)	CA generates key.
Class 2 (Digisign ID Enhanced)	CA or subscriber generates key.
Class 2 (Digisign Server ID)	Subscriber generates server key pair.
Class 2 ( Enterprise CA)	CA or Enterprise CA generates key pair

3.1.2 Certificate application

The following section will outline the procedures in applying for and reviewing of a certificate application. The table below specifies the requirements for obtaining certificates. The table briefly describes the certificate application process based on the certificate policies. Where necessary, mandatory requirements will be highlighted.

Certificate	Mode of application
Class 1 (Digisign ID)	Email to customercare@digicert.com.my to request for Digisign ID purchase. Alternatively, customers may choose to have a walk in registration. Available to all Malaysian and foreign individuals.
Class 2 (Digisign ID Basic/Enhanced)	Walk-in registration at DIGICERT or its RA. The source of identification documents required to accompany the application is either: One (1) of the following: NRIC / Passport; OR Two (2) of the following: Birth Certificate / Valid Driving Licence / credit card bill / bank statement / Letter of Employment / Certificate of Adoption / any documentation deemed fit by the CA. For Enterprise CA, requests shall have to come from the organisation assuming the role of Enterprise CA itself, subject to prior arrangement between DIGICERT and the Enterprise CA. Available to all Malaysian and foreign individuals who are 18 years and above.
Class 2 (Digisign Server ID)	Walk-in registration at DIGICERT or any of its appointed RAs. At least two sources of identification documents (Certificate of Incorporation AND/OR Certificate of Registration OR either any two of the following: Memorandum of Association / Articles of Association / Societies Bylaws booklet / Cooperative Bylaws booklet / latest audited financial statement / latest income tax return) should accompany the application. In addition, the server public key and an authorisation letter from the management are required to allow a representative of the organisation to submit this application. Available to all Malaysian and foreign legal entities (except individuals).

The RP of DIGICERT or its RA or the appointed Authorised Personnel of an Enterprise CA is principally responsible for ensuring that the required information is obtained from the subscriber prior to approving the application for a certificate. The application must be rejected should the information be incomplete or is discovered to be inaccurate upon investigation. The information requirements of each class of certificate is outlined below:

Class 1 (Digisign ID)	i) name (as indicated on the applicant’s NRIC or Passport); ii) email address; iii) the telephone number; iv) postal address (this should be the place where the applicant will reside for more than one year in the immediate future, if no such place is available, the current place of residence will suffice); v) the new NRIC / Passport number; vi) date of birth; vii) a valid credit card number and its expiration date (if applicable)
Class 2 (Digisign ID Basic/Enhanced)	i) name (as indicated on the applicant’s NRIC or Passport); ii) email address(optional); iii) the telephone number; iv) postal address (this should be the place where the applicant will reside for more than one year in the immediate future, if no such place is available, the current place of residence will suffice); v) the new NRIC / Passport number; vi) date of birth
Class 2 (Digisign Server ID )	i) domain name of the server; ii) name of the organisation that operates the server; iii) name of the organisation unit within the organisation (specified in (ii) above) that operates the server; (optional) iv) mailing address of the organisation (as specified in (ii) above); v) the proposed distinguished name of the server; vi) the telephone number and facsimile number of the organisation; vii) email address through which the organisation may be contacted; and vii) the name of the contact person in the organisation who is responsible of the server.
Class 2 ( Enterprise CA)	Similar to Individual Class 2 certificates mentioned above. Any changes in the requirements shall be reflected in the agreement between Digicert and Enterprise CA.

3.1.3 Validation of certificate applications

The validation requirements of applicants for certificates differ between the classes of certificates. The level of validation detail is commensurate with the level of trust guaranteed by the certificate. Should the validation of the application fail at any stage due to reasons outside of the RA’s control, the application should be rejected (see CPS Part 3.2.2).

Upon receipt of the application details from an applicant, the RP at DIGICERT or its RA will perform the following validation requirements to identify the applicant:

Certificate class	Validation requirements
Class 1 (Digisign ID)	The email address of the user must be from the domain of a valid Internet Service Provider (ISP). Web-based email accounts will be rejected. The validity of the email address is confirmed by the email reply from the subscriber.
Class 2 (Digisign ID Basic/Enhanced)	The identity of the applicant is verified through the presentation of the identification documents as described in CPS Part 3.1.2.
Class 2 ( Enterprise CA)	The identity of the applicant is verified by the Enterprise CA as described by CPS Part 3.1.2 and agreement between DIGICERT and the Enterprise CA.
Class 2 (Digisign Server ID)	The scope of verification for Class 2 Server applicants is limited to the organisation that operates the server. The identity of the applicant is verified through the presentation of two identification documents as described in CPS Part 3.1.2.

If the application is approved, the following table summarises the nature of communication for the different classes of certificates:

Certificate class	Nature of communication
Class 1 (Digisign ID)	The subscriber shall receive the digital certificate and PIN number to access the private key via separate e-mail.
Class 2 (Digisign ID Basic)	The subscriber shall receive the certificate and the related private key in his preferred media (smart card, USB token, floppy disk or any other applicable tokens). A PIN number to access the private key will be sent later to the subscriber via regular mail.
Class 2 (Digisign ID Enhanced)	The subscriber shall receive the certificate and the related private key in a smart card or any other applicable tokens. A PIN number to access the private key will be sent later to the subscriber via regular mail.
Class 2 (Digisign Server ID)	The subscriber shall receive the certificate in a floppy disk or smart card.
Class 2 ( Enterprise CA)	The subscriber shall receive the certificate and the related private key in a media agreed upon by the Enterprise CA and DIGICERT.

3.2 Certificate issuance

3.2.1 Certificate acceptance

Certificates are issued to the subscribers upon successful processing of the application and the acceptance of the certificates by the subscribers (see CPS Part 3.3).

subcribers demonstrate their acceptance of the certificate by adhering to the following procedures:

Certificate class	Nature of communication
Class 1 (Digisign ID)	For Digisign ID, subscriber indicates acceptance by using the certificate after receiving the necessary PIN.
Class 2 (Digisign ID Basic/Enhanced)	Subscriber indicates acceptance by receiving the smart card, virtual smart card or any other applicable tokens from DIGICERT or its RAs and usage of the digital certificate.
Class 2 ( Enterprise CA)	Similar to Class 2 (Basic / Enhanced) unless indicated in the agreement between DIGICERT and the Enterprise CA
Class 2 (Digisign Server ID)	Subscriber indicates acceptance by physically obtaining the floppy disk/ smart card containing the digital certificate from DIGICERT or its RAs.

The subscriber is advised to verify all details contained within the certificate. Errors or omissions must be communicated immediately to DIGICERT. It is imperative that the subscriber is aware of this requirement . DIGICERT’s scope of responsibility extends only to ensure that the information contained within the certificate accurately reflects the information that was provided to DIGICERT by the subscriber during the application stage.

3.2.2 Refusal to issue a certificate

DIGICERT shall refuse to issue a certificate if the subscriber provides incomplete, falsified or fraudulent information and, if the identity of the subscriber cannot be verified.

3.2.3 Time of certificate issuance

DIGICERT will make reasonable efforts to adhere to the following time-schedule in issuing certificates. However, no guarantees can be provided as circumstances beyond the control of DIGICERT may inhibit such adherence. In particular, the timeliness of the following schedule will depend on the amount of co-operation received from the subscriber, including but not limited to payment, and the provision of accurate and complete information. Incomplete application forms will invariably cause the application to be delayed or rejected.

All time frames quoted depend upon the receipt of the confirmation to proceed with the application from the applicant. The following sets out the time-schedule for the issuance of certificates:

Class 1 certificate

Class 2 certificate

(Server)

The issuance is immediate upon receiving payment and the PIN number will be sent within 3 business days via regular mail.

For the virtual smart card (floppy disk) (Basic only), the issuance is immediate, and the PIN number will be sent within 3 business days via regular mail.

For the smart card (Basic/Enhanced), the issuance requires 7 business days, and the PIN Mailer will be sent within 5 business days via regular mail.

For Enterprise CA, the issuance is as per agreement with the Enterprise CA itself.

For the application by organisation for server certificate, the issuance is immediate after the subscriber fulfil all the requirements including providing the supporting documents, key request from the server and the payment.

PIN Number for Server ID in smart card will sent within 5 business days via regular mail.

3.2.4 Certificate validity and operational periods

Certificates issued by DIGICERT must be renewed periodically. Renewal procedures can be found in CPS Part 3.5.3. All certificates issued by DIGICERT have a validity period of one (1) to three (3) years (whichever applicable).

3.2.5 Representation upon issuance of certificates

By issuing certificates DIGICERT makes certain representations to the subscriber and to the subsequent parties relying on the certificates.

DIGICERT makes no representations or guarantees, which includes but is not limited to, the accuracy, integrity, reliability, completeness, fitness for a particular purpose or the authenticity of the information contained within the digital certificate. DIGICERT shall not be liable to any person for any liabilities, damages or claims whatsoever in respect of any loss suffered, economic or otherwise, whether consequential, direct or indirect, resulting from the person’s reliance on such information.

DIGICERT makes no further representations and provides no further guarantees of any kind whatsoever to any person regarding the identity of the subscriber to whom DIGICERT has issued a certificate to the extent that such identity has been verified in the manner set out within this CPS.

In addition, subscribers must maintain full responsibility to ensure that their private key is not compromised, stolen, modified or used in an unauthorised manner. The subscribers assume this responsibility upon transmission of the key from DIGICERT (if the subscriber did not generate the key).

In this respect, DIGICERT will not guarantee that the receiving party is the subscriber in person. DIGICERT will only guarantee that the private key was transmitted to an address, whether electronic or otherwise, or to a natural person, designated by the subscriber as being the address or the natural person through which he will receive the private key. DIGICERT will not be liable in any way for damages suffered, whether directly or indirectly, as a result of a person’s reliance that the private key was transmitted to the actual intended party.

The subscribers may delegate to another person the responsibilities to prevent compromise, theft, modification, or unauthorised use of the private key. However, this does not negate the delegator of his responsibilities as outlined in the above paragraphs.

By accepting a certificate issued by DIGICERT, the subscriber acknowledges and represents the following to DIGICERT and to persons relying on the information contained within the certificate throughout the validity period of the certificate (until such time that the certificate is revoked, suspended or expired):

all information contained in the certificate is true to the best of the subscriber’s knowledge to the extent that any changes to the information is not made known to DIGICERT or has been made known to DIGICERT but has not been amended by DIGICERT due to an unreasonable time frame or reasons beyond the control of DIGICERT;
the subscriber promises to notify DIGICERT as soon as practicable of changes to the information contained in the certificate;
the private key of the subscriber has not been compromised, stolen, modified, or used in an unauthorised manner and the subscriber has taken necessary steps to prevent these from happening;
the private key of the subscriber is not to be used in any manner other than its intended use as described in CPS Part 3.3;
digital signatures created by the subscriber are used for legal purposes (within the context of applicable local laws) and subject to the terms and conditions within this CPS; and
digital signatures created by the subscriber are signed with the private key that corresponds to the public key listed in the certificate.

Upon acceptance of the certificate by the subscriber, a copy of the certificate will be published in DIGICERT’s repository. This copy will be maintained until such time that the certificate is expired, revoked or suspended.

3.3 Usage of certificates

The certificates containing public key that is intended for verifying digital signature created using the corresponding private key, should only be used for its intended usage.

Certificates shall not be used in an illegal or discriminatory manner including, but not limited to, trafficking of illegal material, engaging in activities that compromise national security and utilising the certificate for accessing illegal material.

If certificates are used in an illegal manner, DIGICERT will not hesitate to revoke the certificate without prior notice to the subscriber. In addition, future applications made by the subscriber shall be prejudiced against this.

3.4 Certificate revocation and suspension

Suspension or Revocation of certificates can occur due to the reasons specified in CPS Part 3.4.1 and CPS Part 3.4.2.

In the event that DIGICERT believes or has reason to believe, due to reliable evidence or while acting in good faith, that a certificate should be suspended or revoked, DIGICERT will take all necessary to do so even if this is without the consent of the subscriber. In most instances, the suspension or revocation occurs when there is a security breach of the private key or the certificate will materially affect the truth of the information reflected in the certificate and thus possibly mislead a person relying on that information.

In the event that the subscriber requested for a revocation or suspension, DIGICERT will take all necessary precautions to verify the identity of the subscriber. Suspension and Revocation will not proceed without the verification that the purported party is indeed the subscriber.

Upon revocation of the certificate, DIGICERT shall within 24 hours indicate that it is revoked by updating the CRL. The CRL will be published in at least one recognised Repository at an interval specified in CPS Part 3.4.3. Subscribers with revoked certificates are allowed to reapply for a new certificate at the discretion of DIGICERT. Under no circumstances can the revoked certificate be reinstated to its original state after revocation.

3.4.1 Revocation by DIGICERT

In general, a revocation could be initiated by DIGICERT when one or a combination of the following conditions has occurred:

upon such instruction from the Controller or upon the requirements of an applicable law.
the certificate was not issued in accordance with the requirements of Section 29 and 30 of DSA;
certificates become unreliable due to the following :
breach of the private key’s security including unauthorised use;
the information contained within the certificate as supplied by the applicant has changed in such a manner that it will be grossly inaccurate to allow the certificate to continue to be operative without it being withdrawn and updated;
the applicable obligations, terms and conditions under this CPS have been materially breached by the certificate holder; or
a material fact contained in the certificate is misstated or known to be misstated.

The above list is not meant to be exhaustive but merely to highlight the more common cases of suspension or revocation. Should the revocation be carried out, a notice of revocation will be sent to the subscriber. This notice will contain:

a notice that the subscriber's certificate has been revoked;

DIGICERT shall notify the subscriber by email. The contact information of the subscriber that was submitted during the application stage or that was subsequently updated in the digital certificate will be used as the destination for the transmission of this notice.

3.4.2 Revocation by subscriber

Revocation by a subscriber can be initiated due to the following reasons:

breach of the private key’s security including unauthorised use;
the media / token containing the private is loss or damaged;

The above list is not meant to be exhaustive but merely to highlight the more common cases of suspension or revocation.

There are currently two options available for the subscriber to initiate a request for revocation:

walk in to DIGICERT or any of DIGICERT appointed RA's premises and filling in the Revocation of Certificate form; or
fax in the revocation form to DIGICERT or any of DIGICERT appointed RA's.

The informational content of the message channelled to DIGICERT to initiate revocation will depend on the mode of communication chosen. The following table will summarise this point and include verification procedures to prevent malicious acts of sabotage where a certificate is revoked without the subscriber’s knowledge:

Certificate Class	Verification procedures
Class 1 Digisign ID	Revocation Required information includes the email address. The system shall email back to confirm request. Upon the request confirmation via email, the certificate shall be immediately revoked.
Class 2 (Digisign ID Basic/Enhanced)	Walk-in to DIGICERT or its RA Subscriber shall fill in Revocation Request Form upon the request for revocation with following details: NRIC/Passport Smart card / floppy disk / certificate serial number Reason for revocation is required
Enterprise CA	Subscribers shall provide the information as above to the Enterprise CA or Digicert upon request for revocation. Unless stated otherwise, Digicert shall assume all requests from Enterprise CA on behalf of subscribers as legitimate.
Class 2 (Digisign Server ID)	Walk-in to DIGICERT or its RA Subscriber shall fill in the Revocation Request Form and provide the following information to DIGICERT or its RA: Company name Company incorporation number Certificate number Reason for revocation An authorisation letter is required if an agent is appointed to for request revocation.

DIGICERT’s decision on whether to revoke the certificate will be final. If the revocation is instructed by the Controller, notice will be sent to the subscriber before the revocation is made. Sufficient time will be given to the subscriber to be heard. The subscriber will be notified via email or regular mail when the certificate is revoked. Upon the successful revocation of the certificate, the Certificate Revocation List will be updated to reflect this fact within one business day after receiving the request of the revocation.

3.4.3 CRL issuance frequency

All revocation will be updated in the CRL automatically after the revocation at the system and DIGICERT shall publish the CRL in its repository and other recognised repository (if available) after the certificate being revoked.

3.4.4 Revocation status

Status of revocation will be made available in a publicly accessible Certificate Revocation List. DIGICERT shall publish the revocation status in the website, which DIGICERT deems appropriate.

3.5 Certificate expiration

The following section serves to provide the necessary procedures to be carried out by the parties involved. Certificates will expire after it exceeds its deemed operational period as described in CPS Part 3.2.4.

3.5.1 Notice of expiration

DIGICERT will provide notice to the subscriber on the expiry date as follows :

Notice	Class 1 Certificate (Digisign ID)	Class 2 Certificate (Digisign ID Basic/ Enhanced)	Class 2 Certificate (Digisign Server ID)	Enterprise CA
First	One month	Two month	Two months	Two months
Second	One month	One month	One month	-
Third	One month	One week	One week	-

The time frames specified above are relative to the expiry date of the certificate. For example, Class 2 (Digisign ID Basic/ Enhanced) certificate users will be notified initially one month prior to the expiry date; the notification will be sent again one week prior to the expiry date.

The expiry notice time frames for certificate issued by RA and Enterprise CA are similar to Class 2 (Basic / Enhanced) unless indicated in the agreement between DIGICERT and the RA/Enterprise CA

3.5.2 Effect of certificate expiration

Expired certificates will not be revoked or removed. Upon expiration of the certificate, subscribers can either:

cease to be a subscriber; or
renew the expired certificate.

3.5.3 Renewal of certificate

The certificate renewal process is similar to an application for a new certificate. However, for all classes of certificates with the exception of Class 1, the subscriber only needs to provide information that has changed since the expiration date of the certificate. Class 1 certificates can only be renewed by re-applying for a new certificate using the same procedure as described in CPS Part 3.1.

Subscribers shall be solely responsible to update DIGICERT in regards to any information changes during this renewal process.

3.6 Security audit procedures

3.6.1 Types of event recorded

All significant security events on DIGICERT CA software are automatically time stamped and recorded in audit trail files. These include but are not limited to the following events:

successful and failed attempts to create, remove, login as, set reset and change passwords of and revoke privileges of DIGICERT’s operative personnel and its Registration Officer;
failed interactions with the directory including failed connection attempts, read and write operations by DIGICERT CA software; and
all events related to certificate revocation, security policy modification and validation, DIGICERT CA software start-up and stop, database backup, cross-certification, attribute certificate management, DN change, database and audit trail management, certificate life-cycle management and other miscellaneous events.

3.6.2 Frequency of processing log

Critical system events, access attempts and CA operation events are logged on a daily basis. The audit trail is reviewed at least once per week.

3.6.3 Retention period for audit log

The monthly backup of the audit trails files is retained for ten (10) years under normal operations.

3.6.4 Protection of audit log

The audit trail is stored in regular operating system flat files. Audit trail for CA operation events is digitally signed to ensure integrity. Each log record contains the time stamp, the type of log entry and the identity of log event. A new audit trail file is created when the current audit trail file reaches a preset size. Only the authorised Manager or the Security Officer is authorised to view and process audit trail files.

3.6.5 Audit log backup procedures

Audit trail files are backed up by the System Administrator on a daily, weekly and monthly basis. All files including the latest audit trail file are stored either in a magneto-optical media or DAT tape and kept in a secure archive facility.

3.6.6 Audit collection system

The audit trail accumulation system is part of the operating system. The log can be viewed using a standard NT event viewer.

3.7 Records archival

3.7.1 Retention period for archive

The archive of the DIGICERT CA database and audit trail files will be retained for at least ten (10) years.

3.7.2 Protection of archive

The DIGICERT CA archive media is kept in a fireproof safe and retained in a restricted access facility to which only authorised personnel have access. Protection of the audit trail is as described in CPS Part 3.6.4.