BELSIGNTM CPS BELSIGN CERTIFICATION PRACTICE STATEMENT BASED ON VERISIGN CERTIFICATION PRACTICE STATEMENT AND ADAPTED TO BELGIAN LAWS AND CODES OF PRACTICE IN SUPPORT OF BELSIGN'S PUBLIC CERTIFICATION SERVICES CLASS 1 - 3 DIGITALCERTIFICATES VERSION 1.0 DATE OF PUBLICATIONFRIDAY, AUGUST 16, 1996: OCTOBER 10, 1996 BelSign Certification Practice Statement Without limiting the rights reserved above, no part of this publication may be reproduced, stored in or introduced into a retrieval system, or transmitted, in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), without prior written permission of BelSign, NV/SA. Notwithstanding the above, permission is granted to reproduce and distribute this BelSign Certification Practice Statement on a nonexclusive, royalty-free basis, provided that (i) the foregoing copyright notice and the beginning paragraphs are prominently displayed at the beginning of each copy, and (ii) this document is accurately reproduced in full, complete with attribution of the document to BelSign, NV/SA. Requests for any other permission to reproduce this BelSign Certification Practice Statement (as well as requests for copies from BelSign) must be addressed to BelSign, NV/SA, Parijsstraat 74, 3000 Leuven, BELGIUM. Net: practices@belsign.be. QUICK SUMMARY OF IMPORTANT CPS RIGHTS AND OBLIGATIONS PLEASE SEE THE TEXT OF THIS CPS FOR DETAILS. THIS SUMMARY IS INCOMPLETE. MANY OTHER IMPORTANT ISSUES ARE DISCUSSED IN THE CPS. 1. This Certification Practice Statement (see definitions) controls the provision and use of BelSignÕs public certification services (see definitions) Ð including certificate (see definitions) application [¤ 4], application validation [¤ 5], certificate issuance [¤ 6], acceptance [¤ 7], use [¤ 8], and suspension and revocation [¤ 9]. 2. You (the user) acknowledge that BelSign has provided you with sufficient information to become familiar with digital signatures (see definitions) and certificates (see definitions) before applying for, using, and relying upon a certificate [¤ 1.6]. 3. BelSign offers different classes of certificates [¤ 2.2]. You must decide which class(es) of certificate is right for your needs. 4. Before submitting a certificate application [¤ 4.2], you must generate a key pair [¤¤ 2.3.3, 4.1] and keep the private key secure [¤ 4.1] from compromise (see definitions) in a trustworthy (see definitions) manner [¤ 4.1.1]. Your software system should provide this functionality. 5. You must accept (see definitions) a certificate [¤ 7.1] before communicating it to others, or otherwise inducing their use of it. By accepting a certificate (see definitions), you make certain important representations [¤ 7.2]. 6. If you are the recipient of a digital signature or certificate, you are responsible for deciding whether to rely on it. Before doing so, BelSign recommends that you check the BelSign repository (see definitions) to confirm (see definitions) that the certificate (see definitions) is valid (see definitions) and not revoked (see definitions), or suspended (see definitions) and then use the certificate to verify [¤ 8.1] that the digital signature (see definitions) was created during the operational period of the certificate by the private key (see definitions) corresponding to the public key (see definitions) listed in the certificate (see definitions), and that the message (see definitions) associated with the digital signature (see definitions) has not been altered. 7. You agree to notify [¤ 12.10] BelSign that is the applicable issuing authority (see definitions) upon compromise (see definitions) of your private key (see definitions). 8. This Certification Practice Statement (see definitions) provides various warranties and promises made by BelSign [¤ 11]. Otherwise, warranties are disclaimed and liability is limited by BelSign [¤¤ 11.2, 4.3]. 9. The Certification Practice Statement (see definitions) contains various miscellaneous provisions [¤ 12], requires compliance with applicable export regulations [¤ 12.2], indemnifies subscribers [¤ 11.5], and prohibits infringement [¤ 12.14]. For more information, see BelSign's website at https://www.belsign.be or contact customer service at customer_service@belsign.be. ACKNOWLEDGMENTS The BelSign Certification Practice Statement are based on the VeriSign Certification Practice Statement, which is considered as the 'de facto' standard for public and private Certification Practice Statements. We thank VeriSign for their collaboration and assistance and the right to use the VeriSign CPS as source document. The collaboration and assistance of Professor Dumortier and his team at ICRI are greatly acknowledged in the adaptation of the VeriSign CPS to Belgian Laws and codes of practice. COMMENTS AND SUGGESTIONS Editorial comments and suggestions for future revisions of this CPS are solicited from the user community. Please send your comments to: practices@belsign.be or, to BelSign, NV/SA, Parijsstraat 74, 3000 Leuven, BELGIUM Attn: Practices. TABLE OF CONTENTS 1. PREFATORY MATERIAL 1.1 EXECUTIVE SUMMARY 1.2 STRUCTURE OF THE CPS 1.3 CITING THE CPS 1.4 UNDERLINED TEXT 1.5 PUBLICATION 1.6 CUSTOMER SERVICE ASSISTANCE, EDUCATION, AND TRAINING 1.7 TABLE OF ACRONYMS AND ABBREVIATIONS 2. BELSIGN CERTIFICATION INFRASTRUCTURE 2.1 TRUST INFRASTRUCTURE 2.1.1 General Discussion of Certificate Issuance and Management 2.1.2 Security Services 2.2 CERTIFICATE CLASSES 2.2.1 Class 1 Certificates 2.2.2 Class 2 Certificates 7 2.2.3 Class 3 Certificates 8 2.3 CERTIFICATE CLASS PROPERTIES 2.3.1 Confirmation of Subscriber Identity 2.3.2 BelSign Private Key Protection 2.3.3 Certificate Subscriber (and Applicant) Private Key Protection 2.3.4 Possible Applications Supported 2.3.5 Operational Controls 2.4 EXTENSIONS AND ENHANCED NAMING 2.4.1 Extension Mechanisms and the Authentication Framework 2.4.2 Standard and Service-Specific Extensions 2.4.3 Identification and Criticality of Specific Extensions 2.4.4 Certificate Chains and Types of IAs 2.4.5 End-User Subscriber Certificate Extensions 2.4.6 ISO-Defined Basic Constraints Extension 2.4.7 ISO-Defined Key Usage Extension 2.4.8 ISO-Defined Certificate Policy Extension 2.4.9 Enhanced Naming and BelSign Extensions 2.5 PKI HIERARCHY 2.5.1 Certification Authorities (CAs) 18 2.5.2 Local Registration Authorities (LRAs) 18 2.5.3 BelSign Repository 19 2.5.4 Publication by the BelSign Repository 19 2.6 CHAMBERS OF COMMERCE 20 3. FOUNDATION FOR CERTIFICATION OPERATIONS 20 3.1 CONFORMANCE TO THIS CPS 20 3.2 TRUSTWORTHINESS 20 3.3 FINANCIAL RESPONSIBILITY 20 3.4 RECORDS DOCUMENTING COMPLIANCE 20 3.5 TIME STAMPING 21 3.6 RECORDS RETENTION SCHEDULE 21 3.7 AUDIT 21 3.8 CONTINGENCY PLANNING AND DISASTER RECOVERY 22 3.9 AVAILABILITY OF IA CERTIFICATES 22 3.10 PUBLICATION BY BELSIGN 22 3.11 CONFIDENTIAL INFORMATION 22 3.12 PERSONNEL MANAGEMENT AND PRACTICES 23 3.12.1 Trusted Positions 23 3.12.2 Investigation and Compliance 23 3.12.3 Removal of Persons in Trusted Positions 23 3.13 ACCREDITATIONS 23 3.13.1 Approval of Software and Hardware Devices 23 3.13.2 Personnel in Trusted Positions 23 3.13.3 Organizational Good Standing 24 3.14 BELSIGN KEY GENERATION 24 3.15 SECRET SHARING 24 3.15.1 Hardware Protection 24 3.15.2 Representations by BelSign 25 3.15.3 Acceptance of Secret Shares by Secret Share Holders 25 3.15.4 Safeguarding the Secret Share 25 3.15.5 Availability and Release of Secret Shares 25 3.15.6 Record Keeping by Secret Share Issuers and Holders 26 3.15.7 Secret Share Holder Liability 26 3.15.8 Indemnity by Secret Share Issuer 26 3.16 SECURITY REQUIREMENTS 26 3.16.1 Communication Security Requirements 26 3.16.2 Facilities Security Requirements 27 3.17 LOCAL REGISTRATION AUTHORITY (LRA) REQUIREMENTS 27 3.18 TERMINATION OR CESSATION OF IA OPERATIONS 28 3.18.1 Requirements Prior to Cessation 28 3.18.2 Reissuance of Certificates by a Successor IA 28 4. CERTIFICATE APPLICATION PROCEDURES 4.1 KEY GENERATION AND PROTECTION 4.1.1 Holder Exclusivity; Controlling Access to Private Keys 4.1.2 Delegation of Responsibilities for Private Keys 4.2 CERTIFICATE APPLICATION INFORMATION AND COMMUNICATION 4.3 SOFTWARE PUBLISHER'S PLEDGE 5. VALIDATION OF CERTIFICATE APPLICATIONS 5.1 VALIDATION REQUIREMENTS FOR CERTIFICATE APPLICATIONS 5.1.1 Personal Presence 5.1.2 Third-Party Confirmation of Personal Data 5.1.3 Third-Party Confirmation of Business Entity Information 5.1.4 Postal Address Confirmation 5.1.5 Domain Name Confirmation & Serial Number Assignment 5.2 APPROVAL OF CLASS 1 OR 3 CERTIFICATE APPLICATIONS 5.3 APPROVAL OF CLASS 2 CERTIFICATE APPLICATIONS 5.4 REJECTION OF CERTIFICATE APPLICATION 6. ISSUANCE OF CERTIFICATES 6.1 CERTIFICATES 6.2 CONSENT BY SUBSCRIBER FOR ISSUANCE OF CERTIFICATE BY BELSGIN 38 6.3 REFUSAL TO ISSUE A CERTIFICATE 38 6.4 BELSIGN'S REPRESENTATIONS UPON CERTIFICATE ISSUANCE 38 6.4.1 BelSign's Representations to Subscriber 38 6.4.2 BelSign's Representations to Relying Parties 39 6.5 BELSIGN'S REPRESENTATIONS UPON PUBLICATION 39 6.6 TIME OF CERTIFICATE ISSUANCE 39 6.7 CERTIFICATE VALIDITY AND OPERATIONAL PERIODS 39 6.8 RESTRICTIONS ON ISSUED BUT NOT ACCEPTED CERTIFICATES 40 7. ACCEPTANCE OF CERTIFICATES BY SUBSCRIBERS 41 7.1 CERTIFICATE ACCEPTANCE 41 7.2 REPRESENTATIONS BY SUBSCRIBER UPON ACCEPTANCE 42 7.3 SUBSCRIBER DUTY TO PREVENT PRIVATE KEY DISCLOSURE 43 7.4 INDEMNITY BY SUBSCRIBER 43 7.5 PUBLICATION 44 8. USE OF CERTIFICATES 8.1 VERIFICATION OF DIGITAL SIGNATURES 8.2 EFFECT OF VALIDATING AN END-USER SUBSCRIBER CERTIFICATE 8.3 PROCEDURES UPON FAILURE OF DIGITAL SIGNATURE VERIFICATION 8.4 RELIANCE ON DIGITAL SIGNATURES 8.5 WRITINGS 8.6 SIGNATURES 8.7 SECURITY MEASURES 8.8 ISSUING CERTIFICATES 9. CERTIFICATE SUSPENSION AND REVOCATION 9.1 REASONS FOR SUSPENSION OR REVOCATION, GENERALLY 9.2 SUSPENSION OR REVOCATION OF A BELSIGN CERTIFICATE 9.3 TERMINATION OF A SUSPENSION OF A BELSIGN CERTIFICATE 48 9.4 REVOCATION AT SUBSCRIBER'S REQUEST 49 9.5 REVOCATION DUE TO FAULTY ISSUANCE 49 9.6 NOTICE AND CONFIRMATION UPON SUSPENSION OR REVOCATION 49 9.7 EFFECT OF SUSPENSION OR REVOCATION 49 9.7.1 On Certificates 49 9.7.2 On Underlying Obligations 50 9.8 SAFEGUARDING OF PRIVATE KEY UPON SUSPENSION OR REVOCATION 50 10. CERTIFICATE EXPIRATION 51 10.1 NOTICE PRIOR TO EXPIRATION 51 10.2 EFFECT OF CERTIFICATE EXPIRATION ON UNDERLYING OBLIGATIONS 51 10.3 RE-ENROLLMENT AND SUBSCRIBER RENEWAL 51 11. OBLIGATIONS OF BELSIGN, AND LIMITATIONS UPON SUCH OBLIGATIONS 52 11.1 LIMITED WARRANTIES AND OTHER OBLIGATIONS 52 11.2 DISCLAIMERS AND LIMITATIONS ON OBLIGATIONS OF BELSIGN 52 11.3 EXCLUSION OF CERTAIN ELEMENTS OF DAMAGES 53 11.4 DAMAGE AND LOSS LIMITATIONS 53 11.5 SUBSCRIBER LIABILITY TO RELYING PARTIES 54 11.6 NO FIDUCIARY RELATIONSHIP 54 11.7 HAZARDOUS ACTIVITIES 55 12. MISCELLANEOUS PROVISIONS 56 12.1 CONFLICT OF PROVISIONS 56 12.2 COMPLIANCE WITH EXPORT LAWS AND REGULATIONS 56 12.3 GOVERNING LAW 56 12.4 DISPUTE RESOLUTION 56 12.4.1 Notification Among Parties to a Dispute 56 12.4.2 Arbitration 56 12.5 SUCCESSORS AND ASSIGNS 57 12.6 MERGER 57 12.7 SEVERABILITY 57 12.8 INTERPRETATION 57 12.9 NO WAIVER 57 12.10 NOTICE 57 12.11 HEADINGS AND APPENDICES OF THIS CPS 58 12.12 CHANGE OF SUBSCRIBER INFORMATION ON FILE WITH BELSIGN; CHANGE TO CPS 58 12.13 PROPERTY INTERESTS IN SECURITY MATERIALS 58 12.14 INFRINGEMENT AND OTHER DAMAGING MATERIAL 59 12.15 FEES 60 12.16 CHOICE OF CRYPTOGRAPHIC METHODS 60 12.17 SURVIVAL 60 13. APPENDICES 61 13.1 DEFINITIONS 61 Executive Summary This BelSign Certification Practice Statement presents the practices that BelSign in the provision of BelSignÕs public certification services (PCS) employs in issuing and managing certificates and in maintaining a certificate-based public key infrastructure (PKI). It details and controls the certification process, from establishing an IA, commencing IA and repository operations, to enrolling subscribers. The PCS provide for issuing, managing, using, suspending, revoking, and renewing of certificates. The CPS is intended to legally bind and provide notice to all parties that create, use, and validate certificates within the context of the PCS. As such, the CPS plays a central role in governing the PCS, as represented in Figure 1. This CPS governs only a portion of the complement of services offered by BelSign. The PCS will inevitably evolve to accommodate other structures in response to market demand. Structure of the CPS The CPS takes a life cycle, or Òcradle-to-grave,Ó approach to describing certification processes. It begins with IA establishment and start-up procedures and then covers general IA operations; enrollment; use of certificates; certificate suspension, revocation, and expiration. The benefits of this approach include a chronological presentation of events and compatibility with the anticipated structure of leading private- and public-sector practice statements. Citing the CPS This Certification Practice Statement should be cited in other documents as the "BelSign CPSÓ or the "BelSign Certification Practice Statement.Ó It is internally cited as the "CPS,Ó or as ÒCPS ¤ _Ó and its appendices as ÒAppendix ¤ 13._Ó The CPS is updated periodically. Versions of the CPS are denoted by a version number following ÒCPSÓ (e.g., "version 1.0" or ÒCPS 1.0Ó). Underlined Text Underlined text represents the first instance in which defined terms(see Appendix 13.1 - Definitions) are used in this CPS. The WWW-based version(s) of this CPS use hypertext-linked underlined text (using HTML) for cross-referencing within the CPS and for quick reference to definitions and other relevant documents. Publication This CPS is published: (i) in electronic form within the BelSign repository at https://www.belsign.be and ftp://ftp.belsign.be/repository/CPS, (ii) in electronic form via E-mail from CPS-requests@belsign.be, and (iii) in paper form from BelSign, NV/SA, Parijsstraat 74, 3000 Leuven, BELGIUM, Attn: Certification Services. ¥ Each of the referenced BelSign World Wide Web URLs is intended to invoke the HTTP with the Secure Sockets Layer (SSL) security protocol to facilitate Òsecure modeÓ record retrieval (when using a browser supporting SSL). Each such record is also available in Òunsecure modeÓ by replacing https:// with http://. The secure mode must be used to access the official version of all Web-accessed documents contained within the BelSign repository. ¥ To assure readers of this CPS of its integrity, it is "hashed" by BelSign using a hash function. The hash value is listed in the BelSign repository as well as with downloadable versions of the CPS. ¥ Certain URLs cited in this CPS point to directories rather than to actual messages. This facilitates maintaining such messages in multiple formats for the convenience of the reader. Much of the information referenced by BelSign URLs in the CPS is also available as records in electronic and paper form by E-mail request to customer_service@belsign.be. Customer Service Assistance, Education, and Training This CPS assumes that the reader is generally familiar with digital signatures, PKIs, and BelSignÕs PCS. If not, we advise some training in the use of public key techniques before the reader applies for a certificate. Educational and training information is accessible from BelSign at https://www.belsign.be . Additional assistance is available from BelSign customer service representatives (customer_service@belsign.be). ALL PCS APPLICANTS AND SUBSCRIBERS ACKNOWLEDGE THAT (I) THEY HAVE BEEN ADVISED TO RECEIVE PROPER TRAINING IN THE USE OF PUBLIC KEY TECHNIQUES PRIOR TO APPLYING FOR A CERTIFICATE AND THAT (II) DOCUMENTATION, TRAINING, AND EDUCATION ABOUT DIGITAL SIGNATURES, CERTIFICATES, PKI, AND THE PCS ARE AVAILABLE FROM BELSIGN. Table of Acronyms and Abbreviations BSP BELSIGN Certification INFRASTRUCTURE Trust Infrastructure BelSignÕs public certification services (PCS) are designed to support secure electronic commerce and other general security services to satisfy users' technical, business, and personal needs for digital signatures and other network security services. To accomplish this, BelSign serves as a trusted third party, issuing, managing, suspending, and revoking certificates in accordance with published practices. The management and administrative functions of BelSignÕs PCS are established to accommodate a large, public, widely distributed community of users with diverse needs for communications and information security. To assure users that BelSign services are substantially uniform, the BelSign CPS is based on the VeriSign CPS, the 'de facto' standard for Certification Practice Statements. As a result of such practices, BelSign's PCS accommodate a large and geographically dispersed community, enhancing usersÕ trust in these services. General Discussion of Certificate Issuance and Management BelSign acts as a trusted third party to facilitate the confirmation of the relationship between a public key and a named entity (see definition for "naming"). Such confirmation is expressly represented by a certificate Ð a message which is digitally signed and issued by BelSign (see CPS ¤ 2.5). The high-level management of this certification process includes registration, naming, appropriate applicant authentication, issuance, revocation, suspension, and audit-trail generation. Naming may be performed principally by BelSign or by another party. Naming of subscribers includes a registration process distinct from that used for certificate management which determines when certificates are valid and operational. BelSign currently offers three distinct levels of public certification services. Each level, or class, of certificate provides specific functionality and security features. Certificate applicants choose from this set of service qualities according to their needs; they must specify which class of certificate they desire. Depending on the class of certificate desired, certificate applicants may apply electronically or in writing to BelSign, or they may be required to apply in person by visiting a local registration authority (LRA) or with the necessary assistance of an LRAÕs delegate. Each certificate issued by BelSign corresponds to a specific PCS trust level. Certificate management also includes the deactivation of certificates and the decommission of the corresponding private keys, through a process involving the revocation and suspension of certificates. Additional IA services may include the listing, distribution, publication, storage, and retrieval of certificates in accordance with their particular intended use. Security Services BelSignÕs public certification services support a variety of security mechanisms to protect communications and information assets. Certificates alone do not, however, constitute such a mechanism. Rather, BelSign's PCS provide a framework within which security services may be used by other communicating parties. This framework uses digital signatures and their verification to facilitate the protection of communication and computer-based trade and commerce over open data networks and provides a means for determining whether security services are in fact providing the intended assurances. Certificate-based security services may be used to counter threats to security in a user-defined environment. Users select security mechanisms, security technology, security service agreements, and PCS suitable for the users' anticipated levels of risk, to protect users' communications environments from compromise. BelSignÕs PCS currently use the RSA public key system for all certification-related purposes. However, BelSign is committed to supporting other digital signature standards as market demand materializes for alternatives. Certificate Classes BelSign currently supports three distinct certificate classes within the CPS. Each class provides for a designated level of trust. The following subsections describe each certificate class. Also, further detail is provided in Table 2 (Certificate Attributes Affecting Trust). THE DESCRIPTIONS FOR EACH CERTIFICATE CLASS (INCLUDING WITHIN TABLE 2, BELOW) REFLECT APPLICATIONS AND COMMUNICATIONS SYSTEMS THAT HAVE BEEN OR ARE IN THE PROCESS OF BEING IMPLEMENTED BY USERS. THEY DO NOT REPRESENT AN ENDORSEMENT OR RECOMMENDATION BY BELSIGN FOR ANY PARTICULAR APPLICATION OR PURPOSE, AND THEY MUST NOT BE RELIED UPON AS SUCH. USERS MUST INDEPENDENTLY ASSESS AND DETERMINE THE APPROPRIATENESS OF EACH CLASS OF CERTIFICATE FOR ANY PARTICULAR PURPOSE. Class 1 Certificates Description: Class 1 certificates are issued to individuals only. Class 1 certificates confirm that a userÕs name (or alias) and E-mail address form an unambiguous subject name within the BelSign repository. Class 1 certificates are communicated electronically to subscribers and added to his or her set of available certificates. They are typically used primarily for Web browsing and personal E-mail, to modestly enhance the security of these environments. They are also used to establish continuity in the sequence of communications (providing assurances that follow-up communications are from the same user). Assurance level: Class 1 certificates do not facilitate the authentication of the identity of the subscriber. Rather, they merely represent a simple check of the non-ambiguity of the subject name within the BelSign repository. The subscriberÕs common name contained in a Class 1 certificate is considered nonverified subscriber information (NSI). THESE CERTIFICATES PROVIDE THE LOWEST LEVEL OF ASSURANCE OF ALL BELSIGN CERTIFICATES. THEY ARE NOT INTENDED FOR COMMERCIAL USE WHERE PROOF OF IDENTITY IS REQUIRED AND SHOULD NOT BE RELIED UPON FOR SUCH USES. THEY ARE ONLY INTENDED FOR DEMONSTRATION PURPOSES. BELSIGN HAS THE RIGHT, BUT NOT THE OBLIGATION, TO REVOKE CLASS 1 CERTIFICATES UPON COMPROMISE OR FOR OTHER DUE CAUSE. CURRENTLY, REVOCATION OF CLASS 1 CERTIFICATES UPON SUBSCRIBER REQUEST IS PROVIDED ONLY IN THE SOLE DISCRETION OF BELSIGN. Class 2 Certificates Description: Class 2 certificates are currently issued to individuals: residentials and employees. Class 2 certificates confirm that the application information provided by the subscriber does not conflict with information in well-recognized consumer and/or business databases. Class 2 certificates are typically used primarily for intraorganizational and interorganizational E-mail; small, Òlow-riskÓ transactions; personal/individual E-mail; password replacement; software validation; online purchases and on-line subscription services. BelSign offers specialized-use Class 2 individual software publisher certificates intended to support software validation. Class 2 certificates are currently available only for subscribers residing within Belgium and Luxembourg, because of international database limitations. Assurance level: Class 2 certificates may provide reasonable, but not foolproof, assurance of a subscriberÕs identity, based on an automated on-line process that compares the applicantÕs name, address, and other personal information on the certificate application against widely referenced consumer and/or business databases. Confirmation is based upon BelSign proprietary matching criteria of third-party databases against the information in the application. ALTHOUGH BELSIGNÕS CLASS 2 ON-LINE IDENTIFICATION PROCESS IS AN ADVANCED AUTOMATED METHOD OF AUTHENTICATING A CERTIFICATE APPLICANTÕS IDENTITY, IT DOES NOT REQUIRE THE APPLICANTÕS PERSONAL APPEARANCE BEFORE A TRUSTED PARTY (SUCH AS A LOCAL REGISTRATION AUTHORITY OR CHAMBER OF COMMERCE). CONSEQUENTLY, THE DECISION TO OBTAIN, USE, OR RELY UPON A CLASS 2 CERTIFICATE SHOULD TAKE INTO ACCOUNT ITS RELATIVE BENEFITS AND LIMITATIONS, AND THE CERTIFICATE SHOULD BE USED ACCORDINGLY. FURTHER INFORMATION ABOUT THIS ON-LINE AUTHENTICATION PROCESS IS ACCESSIBLE FROM THE BELSIGN REPOSITORY AT https://www.belsign.be. Class 3 Certificates Description: Class 3 certificates are issued to individuals and organizations. ¥ To individuals Ð Class 3 certificates provide important assurances of the identity of individual subscribers by requiring their personal (physical) appearance before a Class 3 LRA or its delegate . ¥ To organizations Ð Class 3 certificates can provide assurances of the existence and name of various public- and private-sector organizations (such as government agencies and corporations). Validation of Class 3 certificate applications for organizations includes review by BelSign of authorization records provided by the applicant or third-party business databases, and independent call-backs (Òout-of-bandÓ communications) to the organization. Class 3 certificates are used by BelSign customers primarily for certain electronic commerce applications such as electronic banking, electronic data interchange (EDI), software validation, and membership-based on-line services. BelSign also offers specialized-use Class 3 commercial software publisher certificates intended to support software validation. Assurance level: Individual Class 3 certificate processes utilize various procedures to obtain probative evidence of the identity of individual subscribers. These validation procedures provide stronger assurances of an applicantÕs identity than Class 2 certificates. The practical uses and reliability of Class 3 certificates are bolstered by utilizing LRA's or Chambers of Commerce (an existing, important, and legally-recognized authentication process). For business entity Class 3 certificates, the requirement for Òout-of-bandÓ communication with the business organization and confirmation of business entity information via third parties provide further assurance of trustworthiness. Certificate Class Properties Table 2 describes certain properties of each certificate class. Each of the tableÕs headings is described below. Confirmation of Subscriber Identity This refers to various actions taken by BelSign to validate certificate applicantsÕ identity and confirm the information they provide during the application process. The type, scope, and extent of confirmation depends upon the class of certificate, the type of applicant, and other factors. The particular confirmation methods and their rigor depend upon the class of certificate. Confirmation is further described in CPS ¤ 5. BelSign Private Key Protection BelSign's private key is secured against compromise via trustworthy hardware products. However, Class 1 IAs (see Figure 4) may secure the secrecy of their private keys via encryption software alone. See CPS ¤ 4.1 (Key Generation and Protection). Certificate Subscriber (and Applicant) Private Key Protection The secrecy of the private keys of certificate subscribers (and applicants) must be protected through the use of encryption software or hardware tokens (such as smart cards or PC cards) as specified in this CPS. See CPS ¤ 4.1 (Key Generation and Protection). BELSIGN NEITHER GENERATES NOR HOLDS THE PRIVATE KEYS OF CERTIFICATE APPLICANTS OR SUBSCRIBERS. ALSO, BELSIGN CANNOT ASCERTAIN OR ENFORCE ANY PARTICULAR PRIVATE KEY PROTECTION REQUIREMENTS OF ANY CERTIFICATE APPLICANT OR SUBSCRIBER. Possible Applications Supported The examples listed in Table 2, above, simply reflect BelSignÕs understanding of existing uses of the various certificate classes. As BelSign observes new PCS usage patterns, it will consider providing a specific organizational structure that responds to such patterns. THE USE OF CERTIFICATES DOES NOT CONVEY EVIDENCE OF AUTHORITY ON THE PART OF ANY USER TO ACT ON BEHALF OF ANY PERSON OR TO UNDERTAKE ANY PARTICULAR ACT. VERIFIERS OF DIGITALLY SIGNED MESSAGES ARE SOLELY RESPONSIBLE FOR EXERCISING DUE DILIGENCE AND REASONABLE JUDGMENT BEFORE RELYING ON CERTIFICATES AND DIGITAL SIGNATURES. A CERTIFICATE DOES NOT GRANT FROM AN IA ANY RIGHTS OR PRIVLEDGES EXCEPT AS PROVIDED IN THIS CPS. Operational Controls Operational controls refer to the organizational, human resources, and other management-oriented controls implemented for each class of certificate. Such controls include limits on who is permitted to obtain certificates, requirements concerning the training and education of BelSign personnel, policies establishing the separation of duties within BelSign, documentation requirements, and prescribed procedures and audits. Many of these controls are identified in CPS ¤ 3 (Foundation for Certification Operations). Extensions and Enhanced Naming Extension Mechanisms and the Authentication Framework The PCS facilitate the use of X.509 v1, v2, and v3 certificates. X.509 v3 certificates expand the capabilities of v1 and v2, including the ability to add certificate extensions. This capability, a standard component of BelSign's PCS, augments the standard authentication services model. Standard and Service-Specific Extensions The X.509 "Amendment 1 to ISO/IEC 9594-8:1995" defines a number of extensions. These provide various management and administrative controls useful for large-scale and multipurpose authentication. BelSign's PCS exploit a number of these controls for the purposes intended by X.509. (Note: X.509-compliant user software is assumed to enforce the validation requirements of this CPS. BelSign cannot guarantee that such software will support and enforce these controls.) In addition, this CPS allows users to define additional "private" extensions for purposes or modes of use specific to their application environment. Definitions for service-oriented extensions to and practices for handling such information during certificate application, approval, and issuance, are specified in the BSP and in publicly available documents from relevant sponsoring organizations. Examples of private extensions implemented within the PCS for service-specific purposes include the software validation scheme exploited by some versions of Microsoft Windows® software and the Netscape Communications Corporation's scheme for SSL security technology. See http://www.microsoft.com/ie, http://microsoft.com/intdev/signcode, and http://home.netscape.com/newsref/ref/netscape-security.html. Identification and Criticality of Specific Extensions The function of each extension is indicated by a standard OBJECT IDENTIFIER value (see definition for X.509). Additionally, each extension in a certificate is assigned a "criticality" true/false value. This value is set by BelSign, possibly on the basis of information provided by the certificate applicant on the certificate application. This value must conform to certain constraints imposed by the organization responsible for the extension definition. The presence of a criticality value of true upon a specific extension requires all persons validating the certificate to consider the certificate invalid if they lack knowledge of the purposes and handling requirements for any specific extension with criticality value of true. If the criticality value of such extension is false, all persons shall process the extension in conformance with the applicable definition when performing validation or else ignore the extension. Certificate Chains and Types of IAs BelSign's PCS use chains of certificates. There are three generic roles an IA may play: root registration authority, IA for another IA, and IA for subscribers. An IA must be a subscriber of another IA. Where an IA is its own root, its self-signed public key shall conform to X.509 v1 format. It can potentially be trusted (based-upon out-of-band authentication mechanisms) without recourse to additional validation during verification of digital signatures (see CPS § 8 – Use of Certificates). When registered by a root registration authority, however, the IA's certificate may contain extensions. End-User Subscriber Certificate Extensions IAs serving end-user subscribers may issue certificates containing extensions defined both by the X.509 Amendment 1 to ISO/IEC 9594-8:1995 and by sponsoring organizations such as Microsoft and Netscape (see CPS § 2.4.2). Briefly, the use of these extensions control the process of issuing and validating certificates. Table 3 describes which extensions are present in particular certificates. ISO-Defined Basic Constraints Extension The basic constraints extension serves to delimit the role and position an IA or end-user subscriber certificate plays in a chain of certificates. For example, certificates issued to CAs and subordinate CAs contain a basic constraint extension that identifies them as IA certificates. End-user subscriber certificates contain an extension that constrains the certificate from being an IA certificate. ISO-Defined Key Usage Extension The key usage extension serves to limit the technical purposes for which a public key listed in a valid certificate may be used within the BelSign PCS. IA certificates may contain a key usage extension that restricts the key to signing certificates, certificate revocation lists, and other data. ISO-Defined Certificate Policy Extension The certificate policy extension limits a certificate to the practices required by (or indicated to) relying parties. The certificate policy extension, as implemented in the PCS, points its users to this CPS and qualifies appropriate usages (see CPS § 2.4.9.1). Enhanced Naming and BelSign Extensions All end-user subscriber certificates, except for certain S/MIME v1 certificates, contain an additional "Organizational Unit" field — an X.520 attribute — that contains a brief statement regarding liability and incorporates by reference the complete CPS, such as ÒOU= www.belsign.be/repository/CPS Incorp. by Ref.,LIAB.LTD(c)96 Ò (this references the primary URL of the CPS, notes that liability is limited, and includes a copyright notice). This or comparable information may be present in application-defined X.509 v3 extensions for display to users by ÒlocalÓ (non-BelSign vendor controlled) means. Note: the content of this Organizational Unit field is abbreviated because of the X.509 limitation of 64 bytes. This usage of an Organizational Unit field will be retired when functional and consistent use of X.509 v3 extensions become ubiquitous. When digital signature-verifying software or hardware (collectively, Òverifying softwareÓ) facilitates the acceptance and use of v3 certificate extensions, the verifying software will display both a reference to the CPS and a set of extensions that describe important portions of it. If the verifying software supports only limited or privately defined v3 extensions, the verifying software may then make use of those application-specific extensions, as appropriate, to equivalently disclose certain critical practice statement sections. Figure 3 illustrates how BelSign has implemented this approach within v3 certificates. Key elements in the figure are explained below. Incorporation by Reference Extensions and enhanced naming are either fully expressed within a certificate or they are at least partially expressed in a certificate with the balance expressed in an external document incorporated by reference in the certificate (see definition of INCORPORATE BY REFERENCE). The information contained in the enhanced Organizational Unit field is also present in the certificatePolicy extension, when present in a certificate. This CPS constitutes a "certificate policy" as defined by X.509 Amendment 1 to ISO/IEC 9594-8:1995. BelSign, acting as a policy-defining authority, has assigned to the CPS an object identifier value which is present in the certificatePolicy extension. The definition of this "certificate policy" requires the use of a policy qualifier which BelSign has defined to include pointer values, warnings, liability limitations, and warranty disclaimers as described in Table 3 and as follows. Pointers to CPS Both computer-based pointers (using URLs or other identifiers and mechanisms) and English (human-readable) text or pointers are used, so that certificate users can easily locate and access the CPS and other relevant information. Warnings, Liability Limitations, and Warranty Disclaimers Each certificate includes a brief statement detailing applicable limitations of liability and disclaimers of warranty, with a pointer to the full text of such warnings, limitations, and disclaimers in the CPS. Alternatively, such information may be displayed by a certificate-viewing function, possibly following a hypertext link to a message accessible by users or agents, rather than being embedded in the certificate. The methods of communicating information (to be displayed by a user) are as follows: an enhanced naming organizational unit attribute; a BelSign standard qualifier to a BelSignÐregistered certificate policy (using a standard v3 extension); and other vendors' registered extensions (such as a NetscapeÐregistered ÒCommentÓ extension). An "enhanced" organizational unit attribute contains the string ÒOU= www.belsign.be/repository/CPS Incorp. by Ref.,LIAB.LTD(c)96Ó, or similar string. Table 3 describes the contents of certificate extensions and the elements of the qualifier to the BelSign CPS certificate policy extension. NAME/CERT. EXTENSION FIELDS ------------------------ basicConstraints keyUsage General Extensions for End-User Subscriber ----------------------- basicConstraints certificatePolicy PKI Hierarchy BelSignÕs public certification services are set up to be implemented within a PKI-entity hierarchy composed of other CAs (including subordinate CAs) . Within the PKI-entity hierarchy, IAs are interrelated via the relationship of Òlocation subordinate to,Ó which indicates that one IA serves on behalf of another. An IA shall issue IA certificates using either general or enhanced authentication procedures (for IA validation), depending upon the certificate class of the end-user subscriber certificates issued by the last IA in the hierarchy. In addition, IAs may delegate certain registration functions to one or more LRAs. Figure 4 provides an overview of the PKI-entity hierarchy. (LRAs are not included in Figure 4, to further simplify the figure). Note: BelSign will use a key size of 1024 bits within max 3 months. Local Registration Authorities (LRAs) Local registration authorities (LRAs) evaluate and approve or reject certificate applications on behalf of and under the exclusive authority of BelSign, the CA that actually issues the certificates. BelSign may have more than one LRA. Without otherwise limiting their authority, LRAs may rely upon the following for confirming certificate applicant information: (i) notarial acts that reasonably appear to be performed in good order and (ii) well-recognized forms of identification, such as passports and driverÕs licenses. Chambers of Commerce may serve as LRAs if so designated by BelSign, and support certain validation functions for certificate applications. LRA requirements are presented in CPS ¤ 3.17, below. BelSign Repository The BelSign repository is a publicly available collection of databases for storing and retrieving certificates and other information related to certificates. The BelSign repository's content includes but is not limited to the following: certificates, CRLs and other suspension and revocation information, current and prior versions of the BelSign CPS, and other information as prescribed by BelSign from time to time. Publication by the BelSign Repository The BelSign repository will act promptly to publish certificates, amendments to the CPS, notices of certificate suspension or revocation, and other information, consistent with this CPS and applicable law. The BelSign repository is accessible at https://www.belsign.be/repository and by other communications methods as may be designated by BelSign from time to time. BelSign may publish both within and outside of the BelSign repository a subscriberÕs certificate and CRL-related data. This CPS prohibits accessing of any data in the repository (or data otherwise maintained by BelSign) that is declared confidential by the CPS and/or by the BelSign repository, unless authorized by BelSign. Chambers of Commerce Chambers of Commerce are generally outside of BelSign's PKI (except as provided in this CPS). However, Chambers of Commerce do serve identity-confirming and other traditional certification roles, such as by acknowledging certain types of certificates (such as Class 3 individual certificates). FOUNDATION FOR CERTIFICATION OPERATIONS This section establishes the foundation and controls for trustworthy PCS operations. It includes the operating requirements for BelSign's PCS, including record keeping, auditing, and personnel requirements. It also presents the obligations of BelSign upon the termination or cessation of its operations. NOTE: CERTIFICATE APPLICATION PROCEDURES ARE PRESENTED IN CPS ¤ 4, BELOW [hot link to CPS ¤ 4]. Conformance to this CPS BelSign shall conform to this CPS in performing their respective services. Trustworthiness BelSign shall utilize only trustworthy systems in performing their respective services. Financial Responsibility BelSign shall have sufficient financial resources to maintain their operations and perform their duties, and BelSign must be reasonably able to bear the risk of liability to subscribers and recipients of certificates and other persons who may rely on the certificates and time stamps they issue. BelSign shall also maintain insurance coverage for errors and omissions. Records Documenting Compliance BelSign shall maintain records in a trustworthy fashion, including (i) documentation of their own compliance with the CPS, and (ii) documentation of actions and information that is material to each certificate application and to the creation, issuance, use, suspension, revocation, expiration, and renewal or re-enrollment of each certificate it issues. These records shall include all relevant evidence in BelSign's possession regarding ¥ the identity of the subscriber named in each certificate (except for Class 1 certificates, for which only a record of the subscriberÕs unambiguous name is maintained), ¥ the identity of persons requesting certificate suspension or revocation (except for Class 1 certificates, for which only a record of the subscriberÕs unambiguous name is maintained), ¥ other facts represented in the certificate, ¥ time stamps, and ¥ certain foreseeable material facts related to issuing certificates. Records may be kept in the form of either computer-based messages or paper-based documents, provided their indexing, storage, preservation, and reproduction are accurate and complete. BelSign may require a subscriber or its agent to submit documents to enable BelSign to comply with this section. Time Stamping Time stamping is intended to enhance the integrity of BelSignÕs PCS and the trustworthiness of certificates and to contribute to the nonrepudiation of digitally signed messages. Time stamping creates a notation that indicates (at least) the correct date and time of an action (expressly or implicitly) and the identity of the person or device that created the notation. All time stamps reflect Greenwich mean time (GMT) and adopt the Universal Time Conventions (UTC). For purposes of this CPS, any two-digit year in the range 00-69 means 2000-2069, and in the range 70-99 means 1970-1999. The following data shall be time stamped, either directly on the data or on a correspondingly trustworthy audit trail, by BelSign: ¥ certificates, ¥ CRLs and other suspension and revocation database entries, ¥ each version of the CPS, ¥ customer service messages, and ¥ other information, as prescribed by this CPS. Records Retention Schedule BelSign shall retain in a trustworthy fashion Class 1 and 2 records for at least five (5) years and Class 3 Highest Assurance records for at least thirty (30) years after the date a certificate is revoked or expires. Such records may be retained as either retrievable computer-based messages or paper-based documents. Audit BelSign shall implement and maintain trustworthy systems to preserve an audit trail for all material events, such as key generation and certificate application, validation, suspension, and revocation. A certified public accountant with demonstrated expertise in computer security or an accredited computer security professional shall audit the operations of BelSign and corresponding LRAs at least annually, to evaluate its compliance with this CPS and other applicable agreements, guidelines, procedures, and standards. BelSignÕs receipt of such third-party audit reports constitutes neither endorsement nor approval on the part of BelSign of the content, findings, and recommendations of such reports. BelSign may review such reports to protect BelSignÕs PCS. Since BelSign is not the author of such audit reports, and is therefore not responsible for their content, BelSign does not express any opinion on such audit reports and shall not be held responsible for any damages to anyone resulting from BelSignÕs reliance on such audit reports. Contingency Planning and Disaster Recovery BelSign shall implement, document, and periodically test appropriate contingency planning and disaster recovery capabilities and procedures, consistent with this CPS and the BSP. Availability of IA Certificates BelSign shall make copies of their own certificates (i.e., those in which BelSign is the subject) and any revocation data (where applicable) available to any person who has and desires to duly verify a digital signature that is verifiable by reference to such a certificate. Publication by BelSign BelSign must publish their certificate, revocation data, and this CPS. Confidential Information The following information shall be considered received and generated in confidence by BelSign and may not be disclosed except as provided below: ¥ Subscriber agreements and certificate application records (except for information placed in a certificate or repository per this CPS), ¥ transactional records (both full records and the audit trail of transactions), ¥ PCS audit trail records created or retained by BelSign, ¥ PCS audit reports created by BelSign, BelSign repository (to the extent such reports are maintained), or their respective auditors (whether internal or public), ¥ contingency planning and disaster recovery plans, and ¥ security measures controlling the operations of BelSign hardware and software and the administration of certificate services and designated enrollment services. BelSign shall not disclose or sell applicant names or other identifying information, and neither shall share such information, except in accordance with this CPS. Note, however, that the BelSign repository shall contain certificates, revocation and other information (see CPS ¤¤ 2.5.3, 2.5.4 regarding the BelSign repository). Voluntary Release / Disclosure of Confidential Information. BelSign shall not release or be required to release any confidential information without an authenticated, reasonably specific request prior to such release from (i) the person to whom the BelSign owes a duty to keep information confidential and (ii) the person requesting confidential information (if not the same person); or a court order. BelSign may require that the requesting person pay a reasonable fee before disclosing such information. Personnel Management and Practices BelSign shall formulate and follow personnel and management practices that provide reasonable assurance of the trustworthiness and competence of their employees and of the satisfactory performance of their duties. Such practices shall be consistent with this CPS. Trusted Positions All employees, contractors, and consultants of BelSign (collectively, ÒpersonnelÓ) that have access to or control over cryptographic operations that may materially affect the BelSign issuance, use, suspension, or revocation of certificates, including access to restricted operations of the BelSign repository, shall, for purposes of this CPS, be considered as serving in a trusted position. Such personnel include, but are not limited to, all customer service personnel, system administration personnel, designated engineering personnel, and executives who are designated to oversee the BelSign trustworthy system infrastructures. Investigation and Compliance BelSign shall conduct an initial investigation of all personnel who are candidates to serve in trusted positions to make a reasonable attempt to determine their trustworthiness and competence. BelSign shall conduct periodic investigations of all personnel who serve in trusted positions to verify their continued trustworthiness and competence in accordance with BelSign's personnel practices or equivalent. Removal of Persons in Trusted Positions All personnel who fail an initial or periodic investigation shall not serve in a trusted position. The removal of any person serving in a trusted position shall be at the sole discretion of BelSign. Accreditations Approval of Software and Hardware Devices All PCS-related hardware and software shall be approved by BelSign, an authorized BelSign consultant, or other recognized authority (as designated from time to time by BelSign), as appropriate. Personnel in Trusted Positions All personnel serving in trusted positions shall be accredited by a recognized external accreditation organization, as appropriate. This provision does not include members of the board of directors of BelSign, except for such persons serving in an operational capacity in the PCS. Organizational Good Standing BelSign shall be in good standing with (and, where applicable, accredited, certified, or licensed by) applicable agencies and authorities whose rules and regulations materially affect BelSign's trustworthiness and as required by law or contract. BelSign Key Generation BelSign shall securely generate and protect its own private key(s), using a trustworthy system, and take necessary precautions to prevent its loss, disclosure, modification, or unauthorized use. Secret Sharing BelSign shall use secret sharing (see definitions), using authorized secret share holders, to enhance the trustworthiness of their private key(s) and provide for their keys' recovery, as described below. ENTITY TABLE 4 Ð SECRET SHARE DISTRIBUTION Hardware Protection BelSign must use approved trustworthy hardware cryptomodules for all operations requiring the use of their private key, except for Class 1 CAs, which may use trustworthy software with secret sharing. The procedure for creating such private keys may be published in the BelSign repository. Representations by BelSign BelSign intending to distribute secret shares of its private key(s) represents and warrants to all applicable entities that it lawfully possesses private key(s) intended to be secret shared and has the authority to transfer them to authorized secret share holders, in accordance with this CPS. Acceptance of Secret Shares by Secret Share Holders For a secret share holder to accept a secret share, a majority of the designated secret share holders must have personally observed the creation, re-creation, and distribution of the share and its subsequent chain of custody. Each secret share holder must receive the secret share within a physical medium, such as a BelSign-approved hardware token. Once the secret share holder is satisfied that his or her inspection of the delivered secret share is complete, he or she shall acknowledge acceptance of the secret share by signing and returning to BelSign a secret share acceptance form provided by Belsign. Safeguarding the Secret Share The secret share holder shall use trustworthy systems to protect the secret share against compromise. Except as provided in this CPS, the secret share holder agrees that he or she shall not ¥ divulge, disclose, copy, make available to third parties, or make any unauthorized use whatsoever of the secret share, ¥ reveal (expressly or implicitly) that he or she, or any other secret share holder, is a secret share holder, or ¥ store the secret share in a location that fails to provide for its recovery in the event the secret share holder becomes incapacitated or unavailable (except when the secret share is being used for authorized purposes). Availability and Release of Secret Shares The secret share holder shall make the secret share available to authorized entities (listed in the secret share holder acceptance form) only when provided with proper authorization by an authenticated record (see next paragraph). In the event of a disaster situation (when declared by the secret share issuer), the secret share holder shall report to a disaster recovery site in accordance with instructions from the secret share issuer. Prior to traveling to any contingency/disaster recovery site and releasing the secret share, the secret share holder shall authenticate the declaration of the secret share issuer as specified on the secret share acceptance form (except where prohibited by law or legal process, such as concerning certain criminal investigations). This procedure will include the use of a challenge phrase (communicated from the secret share issuer to the secret share holder) to ensure that the secret share holder is not tricked into traveling to the wrong location thereby incapacitating the secret share issuerÕs ability to recover. At the disaster recovery site, the secret share holder shall physically deliver (in person) the secret share in order to participate in the disaster recovery procedure. The secret share holder may rely upon any instruction, document, message, record, instrument, or signature he or she reasonably believes to be genuine, provided he or she authenticates such declaration of the secret share issuer in the manner provided by the preceding paragraph. The secret share issuer will provide the secret share holder with a sample set of all signatures to be used to authenticate the instructions of the secret share issuer. Record Keeping by Secret Share Issuers and Holders Secret share issuers and holders shall keep records of activities pertaining to all secret share materials. The secret share holder shall provide information regarding the status of the secret share to the secret share issuer or its designee upon authenticated request. Secret Share Holder Liability The secret share holder shall perform his or her obligations under this CPS and must act in a reasonable and prudent manner in all respects. The secret share holder shall notify the secret share issuer of any loss, theft, improper disclosure, or compromise of the secret share immediately upon learning of it. The secret share holder is not responsible for failure to fulfill his or her obligations due to causes beyond his or her reasonable control but shall be liable for improper disclosure of secret shares or failure to notify the secret share issuer of improper disclosure or compromise through his or her fault, including negligence or recklessness. Indemnity by Secret Share Issuer The secret share issuer agrees to indemnify and hold harmless the secret share holder from all claims, actions, damages, judgments, arbitration fees, expenses, costs, attorney's fees, and other liabilities incurred by the secret share holder related to the secret share that are not caused or contributed to by the secret share holderÕs fault, including negligence, or recklessness. Security Requirements Communication Security Requirements All communications pursuant to this CPS among BelSign and the other parties in the PCS must use an application that provides appropriate security mechanisms commensurate with the attendant risks. Without limiting the generality of the foregoing, computer-based notices, corresponding notice acknowledgments, and any other communications affecting the security of the PCS shall also be appropriately secured. Facilities Security Requirements BelSign shall operate trustworthy facilities that are in substantial conformance with the BSP, or equivalent. Local Registration Authority (LRA) Requirements LRAs serve in trusted positions (see CPS ¤ 3.12 Ð Personnel Management and Practices). The minimum requirements for an LRA depend upon the class of certificate application that an LRA is authorized to approve. Such requirements are presented in Table 5: Requirements Prior to Cessation Before ceasing to act as an IA, BelSign must: (i) Provide to the subscriber of each unrevoked or unexpired certificate it issued ninety (90) days notice of its intention to cease acting as an IA. (ii) Revoke all certificates that remain unrevoked or unexpired at the end of the ninety (90) day notice period, whether or not the subscribers have requested revocation. (iii) Give notice of revocation to each affected subscriber, as detailed in CPS ¤ 9. (iv) Make a reasonable effort to ensure that discontinuing its certification services will cause minimal disruption to its subscribers and to persons duly needing to verify digital signatures by reference to the public keys contained in outstanding certificates. (v) Make reasonable arrangements for preserving its records. (vi) Pay reasonable restitution (not to exceed the certificate purchase price) to subscribers for revoking their certificates before their expiration date. Reissuance of Certificates by a Successor IA To provide uninterrupted IA services to its certificate applicants and subscribers, a discontinuing IA must arrange with another such authority, subject to the other IAÕs prior written approval, for reissuance of its outstanding subscriber certificates. In reissuing a certificate, the succeeding IA (not to be confused with a subordinate IA) subrogates to the rights and defenses of the discontinuing IA and, to the extent agreed in writing between the discontinuing and succeeding IA, assumes all of its obligations and liabilities regarding outstanding certificates. Unless a contract between the discontinuing IA and a subscriber provides otherwise, and subject to the succeeding IAÕs written approval, the CPS will remain in effect under the succeeding IA as under the original IA. The requirements of this subsection may be varied by contract, provided such modifications affect only the contracting parties. CERTIFICATE APPLICATION PROCEDURES This section describes the certificate application process. It includes the requirements for key pair generation and protection and lists the information required for each class of certificate. All persons (other than BelSign) desiring a certificate shall contemporaneously complete the following general procedures for each certificate application: ¥ generate a key pair and demonstrate to BelSign that it is a functioning key pair, ¥ protect the private key (of this key pair) from compromise, ¥ determine a proposed distinguished name, and ¥ submit a certificate application (and subscriber agreement), including the public key of this key pair, to BelSign. Key Generation and Protection The following procedures are applicable to all entities generating keys as provided in this CPS. Holder Exclusivity; Controlling Access to Private Keys Unless otherwise permitted by this CPS, each certificate applicant shall securely generate his, her, or its own private key, using a trustworthy system, and take necessary precautions to prevent its compromise, loss, disclosure, modification, or unauthorized use. It is understood that subscribers (and certificate applicants) will generally use non-BelSign products that provide appropriate protection to keys. EACH CERTIFICATE APPLICANT (AND, UPON APPROVAL, EACH SUBSCRIBER) ACKNOWLEDGES THAT SUCH PERSON, AND NOT BELSIGN, IS EXCLUSIVELY RESPONSIBLE FOR PROTECTING HIS, HER, OR ITS PRIVATE KEY(S) FROM COMPROMISE, LOSS, DISCLOSURE, MODIFICATION, OR UNAUTHORIZED USE. Users and BelSign agree not to monitor, interfere with, or reverse engineer the technical implementation of the PCS except as explicitly permitted by this CPS or upon prior written approval of BelSign. Delegation of Responsibilities for Private Keys Delegation, if it occurs, does not relieve the delegator of his, her or its responsibilities and liabilities concerning the generation, use, retention, or proper destruction of his, her, or its private key. Certificate Application Information and Communication Certificate application information includes the items listed in the following Table 6. Not all of the following information will appear in a certificate (see Figure 3 - Certificates and Information Incorporated by Reference). Note: The items of such information not included in the certificate will be kept confidential by BelSign (see CPS ¤ 3.11). CLASS OF CERTIFICATE Method of Communicating Application: BelSign communicates an on-line enrollment process to the certificate applicant. By completing this on-line dialog via a secure Web channel, the certificate applicant then affirms that the certificate applicant information is accurate. Upon completion of specified validation procedures, BelSign sends a certificate to the certificate applicant. Business Entities: Class 1 certificates are issued to individuals only. Required Information (a) E-mail address (b) Legal name (in the form of a common name) (c) Proposed distinguished name (d) Street, apartment number (if applicable), city, postal/zip code, country (of residence) (e) Subject public key (f) Date of birth (g) Voice telephone numbers (of residence) (h) Challenge phrase (to later authenticate subscriber to BelSign) (i) Payment information (if applicable) (j) Executed subscriber agreement (k) The Òsoftware publisher's pledgeÓ (for individual software publisher certificate applicants only Ð see CPS ¤ 4.3) Optional (q) Other information as prescribed by BelSign Method of Communicating Application: BelSign communicates an on-line enrollment process and a subscriber agreement to the certificate applicant. By completing this on-line dialog via a secure Web channel, the certificate applicant then affirms that (i) the certificate applicant information is accurate and (ii) he or she has read, understands, and agrees to the term of the subscriber agreement. Upon completion of specified validation procedures, BelSign sends E-mail to the E-mail address that was previously provided by the certificate applicant in the certificate application. This E-mail contains an URL (and optionally, a draft of information content to be included in the certificate) that authorizes the certificate applicant to obtain a certificate from BelSign. Agents/Authorized Representatives: n/a Business Entities: Class 2 certificates are issued to individuals residentials and employees only. Individuals - Employees: Required Information (a) E-mail address (b) Subject public key (c) Legal name (d) Legal name of the organisation (in the form of a common name) (e) Street, (if applicable), city, postal/zip code, country (of the organisation) Personal Information (f) Date of birth (g) Challenge phrase (to later authenticate subscriber to BelSign) Organization Information (h) General telephone number (of your organisation) (i) VAT-number (j) Trade Register number (k) Executed subscriber agreement (l) Payment information (if applicable) (m) The Òsoftware publisher's pledgeÓ (for individual software publisher certificate applicants only Ð see CPS ¤ 4.3) Optional (n) Other information as prescribed by BelSign Method of Communicating Application: BelSign communicates an online enrollment process and a subscriber agreement to the certificate applicant. By completing this on-line dialog via a secure Web channel, the certificate applicant then affirms that (i) the certificate applicant information is accurate and (ii) he or she has read, understands, and agrees to the term of the subscriber agreement. Upon completion of specified validation procedures, BelSign sends E-mail to the E-mail address that was previously provided by the certificate applicant in the certificate application. This E-mail contains an URL (and optionally, a draft of information content to be included in the certificate) that authorizes the certificate applicant to obtain a certificate from BelSign. Agents/Authorized Representatives: n/a Business Entities: Class 2 certificates are issued to individuals residentials and employees only. Business Entities: Required Information Distinguished Name Domain name Legal Name of the Organization Organizational unit (if applicable) Street, city, postal/zip code, country Technical and billing contact persons VAT-number Trade Register number Server Software Payment Information (j) Proof of right to use name (via third-party database checks and out-of-band verification) The following information shall be submitted by fax and courier to BelSign (k) Proof of organizational status (such as proof of articles of incorporation, where applicable, or comparable proof): 1. For business: article of trade register 2. For universities: notarized letter from office of dean 3. For government organizations: notarized letter from a properly-authorized person (l) Proof of agentÕs authority (m) The Òsoftware publisher's pledgeÓ (for commercial software publisher certificate applicants only Ð see CPS ¤ 4.3) Optional- (n) Other information as prescribed by BelSign Agents/Authorized Representative: See above Method of Communicating Application: The completed application (and subscriber agreement) shall be submitted in electronic form. In addition to the other representations, obligations, and warranties contained or referenced in the certificate application, the [individual] [commercial] software publisher certificate applicant represents and warrants that he, she, or it shall exercise reasonable care consistent with prevailing industry standards to exclude programs, extraneous code, viruses, or data that may be reasonably expected to damage, misappropriate, or interfere with the use of data, software, systems, or operations of the other party. [For commercial software publisher certificate applicants:] The commercial software publisher certificate applicant further warrants that he, she, or it shall create and maintain its private key exclusively on a hardware-based cryptomodule (such as a smart card or PC card). This software publisher's pledge is made exclusively by the [individual] [commercial] software publisher certificate applicant. BelSign shall not be held responsible for the breach of such representations and warranties by the [individual] [commercial] software publisher under any circumstance. VALIDATION OF CERTIFICATE APPLICATIONS This section presents the requirements for validation of certificate applications to be performed by BelSign or by an authorized local registration authority. It also explains the procedures for applications that fail validation. Validation Requirements for Certificate Applications Upon receipt of a certificate application (per CPS ¤ 4 Ð Certificate Application Procedures) BelSign shall perform all required validations as a prerequisite to certificate issuance (per CPS ¤ 6 Ð Issuance of Certificates), as follows. Confirm that (a) the certificate applicant is the person identified in the request (in accordance with and only to the extent provided in the certificate class descriptions, see CPS ¤ 2, and as further described below), (b) the certificate applicant rightfully holds the private key corresponding to the public key to be listed in the certificate (this obligation may be satisfied by a statement to this effect from the certificate applicant), (c) the information to be listed in the certificate is accurate, except for nonverified subscriber information (NSI), and any agents who apply for a certificate listing the certificate applicantÕs public key (permissible for Class 3 certificates, for business entities only) are duly authorized to make such a request. Once a certificate is issued, BelSign shall have no continuing duty to monitor and investigate the accuracy of the information in a certificate, unless Belsign is notified in accordance with this CPS of that certificateÕs compromise. Table 7 (Validation Requirements for Certificate Applications) highlights certain differences between the validation requirements for each certificate class. BelSign reserves the right to update these validation procedures to improve the validation process. Further details concerning validations are presented below. Updated validation procedures (when released) are presented in the BelSign repository at https://www.belsign.be and may also be obtained from BelSign, NV/SA, Parijsstraat 74, 3000 Leuven, Belgium Attn. Certification Services. VALIDATION REQUIREMENTS Personal Presence In order to effect an appropriate binding between the applicant and the applicantÕs public key, individuals applying for Class 3 certificates must appear personally before a trusted entity (such as a Chamber of Commerce or an LRA) to facilitate the confirmation of their identity. A personal presence requirement has many variables (depending upon the class and type of certificate), including but not limited to specified identification documents. Third-Party Confirmation of Personal Data Where required, a third party confirms personal information provided by the certificate applicant by comparing it to the third partyÕs databases. Confirmation is achieved if the certificate applicant's data is consistent with the database information, based on BelSignÕs custom matching algorithm or another appropriate determination process. On-line investigation provides some assurance of identity by comparing certificate applicant identity information against consumer databases. These databases may also provide confirmation of the applicantÕs address. The scope of on-line investigations is, however, subject to individual countriesÕ data protection laws. Special procedures may also be implemented by BelSign, depending on the requirements of the certificate applicant and the class of certificate to be issued. Third-Party Confirmation of Business Entity Information Where required, the third party confirms the business entity's name, address, and other registration information through comparison with third-party databases and through inquiry to the appropriate government entities. Confirmation of information of companies, banks, and their agents requires certain customized (and possibly localized) procedures focusing on specific business-related criteria (such as proper business registration). The third party also provides telephone numbers that are used for out-of-band communications with the business entity to confirm certain information (for example, to confirm an agent's position within the business entity or to confirm that the particular individual listed in the application is in fact the applicant). If its databases do not contain all the information required, the third party may undertake an investigation, if requested by BelSign, or the certificate applicant may be required to provide additional information and proof. Postal Address Confirmation Upon issuance of a Class 2, BelSign shall ask letters with reference to the postal address submitted in the certificate application and confirmed (via third party database - see CPS § 5.1.2). This procedure provides further confirmation that the subscriber's address matches the address listed in the certificate application and therefore provides further assurances that the subscriber is who he or she purports to be. Domain Name Confirmation & Serial Number Assignment The naming authority used by BelSign shall have sole discretion regarding the assignment of relative distinguished names (RDNs) and certificate serial numbers appearing in the certificates they issue. BelSign shall use the Domain Name Service for resolving RDN assignment where appropriate. For information about Domain Name procedures and assurances, see http://www.dns.be. Approval of Class 1 or 3 Certificate Applications Upon successful performance of all required validations of a Class 1 or 3 certificate application (in accordance with CPS ¤ 5.1), BelSign shall approve the application. Approval is demonstrated by issuing a certificate according to CPS ¤ 6 (Issuance of Certificates). Approval of Class 2 Certificate Applications Upon successful performance of all required BelSign-internal validations of a Class 2 certificate application (in accordance with CPS ¤ 5.1), BelSign shall approve the certificate application. Such approval is demonstrated by BelSign issuing a certificate according to CPS ¤ 6.1 (Certificates). Rejection of Certificate Application If a validation fails, BelSign shall reject the certificate application by promptly notifying the certificate applicant of the validation failure and providing the reason code (except where prohibited by law) for such failure. Where such validation failure is caused as a result of third-party database information, BelSign shall provide the certificate applicant with the third-party database company's contact information for inquiry and dispute resolution. Such notice shall be communicated to the certificate applicant using the same method as was used to communicate the certificate application to BelSign (or LRA). A person whose certificate application has been rejected may thereafter reapply. ISSUANCE OF CERTIFICATES This section presents the requirements for the issuance of certificates. It also lists the specific representations issuing authorities make upon issuing certificates. Certificates Upon approving a certificate application (per CPS ¤ 5), BelSign issues a certificate. The issuance of a certificate indicates a complete and final approval of the certificate application by BelSign. The certificate is deemed to be a valid certificate upon the subscriberÕs acceptance of it (see CPS ¤ 7 regarding acceptance). Consent by Subscriber for Issuance of Certificate by BelSign Belsign shall not issue certificates without the certificate applicant's consent. Consent to issue is presumed from applicantÕs submission of an application notwithstanding the fact that acceptance of a certificate has not yet occurred. Refusal to Issue a Certificate BelSign may refuse to issue a certificate to any person, at its sole discretion, without incurring any liability or responsibility for any loss or expenses arising out of such refusal. Belsign Representations Upon Certificate Issuance BelSign Representations to Subscriber (i) Unless otherwise provided in this CPS or mutually agreed upon by both BelSign and the subscriber in an authenticated record, BelSign promises to the subscriber named in the certificate that (a) there are no misrepresentations of fact in the certificate known to BelSign or originating from BelSign, (b) there are no data transcription errors as received by Belsign from the certificate applicant resulting from a failure of BelSign to exercise reasonable care in creating the certificate, and (c) the certificate meets all material requirements of this CPS. (ii) Unless otherwise provided in this CPS or mutually agreed upon by both BelSign and the subscriber in an authenticated record, BelSign promises to the subscriber to make reasonable efforts, consistent with the terms of this CPS, (a) to promptly revoke or suspend certificates in accordance with CPS ¤ 9, and (b) to notify subscribers of any facts known to it that materially affect the validity and reliability of the certificate it issued to such subscriber. (iii) The obligations and representations in CPS ¤¤ 6.4.1 (i) and (ii) are made and undertaken solely for the benefit of the subscriber and are not intended to benefit or be enforceable by any other party. Belsign makes reasonable efforts, for purposes of CPS ¤ 6.4.1(ii), if its conduct substantially complies with this CPS and applicable law. BelSign's Representations to Relying Parties By issuing a certificate BelSign represents to all who reasonably rely on a digital signature verifiable by the public key listed in the certificate that consistent with this CPS: (i) all information in or incorporated by reference within the certificate, except nonverified subscriber information (NSI), is accurate, and (ii) BelSign has substantially complied with the CPS when issuing the certificate. Belsign Representations Upon Publication By publishing a certificate (see CPS ¤ 7.5), BelSign certifies to the BelSign repository and to all who reasonably rely on the information contained in the certificate that it has issued the certificate to the subscriber and that the subscriber has accepted the certificate, as described in CPS ¤ 7.1. Time of Certificate Issuance BelSign shall make reasonable efforts to confirm certificate application information and issue end-user subscriber certificates once all relevant information is received by BelSign within the following time periods: Certificate Validity and Operational Periods All certificates shall be considered valid upon issuance by BelSign and acceptance by the subscriber (see CPS ¤ 7). The standard operational periods for the various classes of certificates are as follows, subject to earlier termination of the operational period due to suspension or revocation. CERTIFICATE \ISSUED BY: ACCEPTANCE OF CERTIFICATES BY SUBSCRIBERS This section explains the requirements for certificate acceptance by subscribers, the representations made by subscribers upon acceptance, subscribersÕ obligations to protect their private keys, and procedures for the publication of certificates. Certificate Acceptance A subscriber is deemed to have accepted a certificate when, following communication of the application per CPS ¤ 4.2, approval is manifested as described in Table 10. CLASS Business Entities: n/a E-mail (S/MIME): The certificate applicant submits a CSR to Belsign to accept the certificate. Upon completion of specified validation procedures, BelSign then sends the certificate to the E-mail address from which the certificate application originated. Note: The certificate applicant must promptly notify BelSign of any inaccuracy or defect in a certificate or earlier notice of informational content to be included in the certificate. Business Entities: n/a Business Entities: On-line (via the Web): Same as on-line Class 1. E-mail (S/MIME): TBD Representations by Subscriber Upon Acceptance By accepting a certificate issued by BelSign, the subscriber certifies to and agrees with BelSign and to all who reasonably rely on the information contained in the certificate that at the time of acceptance and throughout the operational period of the certificate, until notified otherwise by the subscriber, (i) each digital signature created using the private key corresponding to the public key listed in the certificate is the digital signature of the subscriber and the certificate has been accepted and is operational (not expired, suspended or revoked) at the time the digital signature is created, (ii) no unauthorized person has ever had access to the subscriberÕs private key, (iii) all representations made by the subscriber to BelSign regarding the information contained in the certificate are true, (iv) all information contained in the certificate is true to the extent that the subscriber had knowledge or notice of such information and does not promptly notify BelSign of any material inaccuracies in such information as set forth in CPS § 6.1, (v) the certificate is being used exclusively for authorized and legal purposes, consistent with this CPS, and (vi) the subscriber is an end-user subscriber and not an IA, and will not use the private key corresponding to any public key listed in the certificate for purposes of signing any certificate (or any other format of certified public key) or CRL, as an IA or otherwise, unless expressly agreed in writing between subscriber and BelSign. BY ACCEPTING A CERTIFICATE, THE SUBSCRIBER ACKNOWLEDGES THAT HE, SHE, OR IT AGREES TO THE TERMS AND CONDITIONS CONTAINED IN THIS CPS AND THE APPLICABLE SUBSCRIBER AGREEMENT. Subscriber Duty to Prevent Private Key Disclosure By accepting a certificate, the subscriber assumes a duty to retain control of the subscriberÕs private key, to use a trustworthy system, and to take reasonable precautions to prevent its loss, disclosure, modification, or unauthorized use. Indemnity by Subscriber BY ACCEPTING A CERTIFICATE, THE SUBSCRIBER AGREES TO INDEMNIFY AND HOLD BELSIGN, AND THEIR AGENT(S) AND CONTRACTORS HARMLESS FROM ANY ACTS OR OMISSIONS RESULTING IN LIABILITY, ANY LOSS OR DAMAGE, AND ANY SUITS AND EXPENSES OF ANY KIND, INCLUDING REASONABLE ATTORNEYSÕ FEES, THAT BELSIGN, AND THEIR AGENTS AND CONTRACTORS MAY INCUR, THAT ARE CAUSED BY THE USE OR PUBLICATION OF A CERTIFICATE, AND THAT ARISES FROM (I) FALSEHOOD OR MISREPRESENTATION OF FACT BY THE SUBSCRIBER (OR A PERSON ACTING UPON INSTRUCTIONS FROM ANYONE AUTHORIZED BY THE SUBSCRIBER); (II) FAILURE BY THE SUBSCRIBER TO DISCLOSE A MATERIAL FACT, IF THE MISREPRESENTATION OR OMISSION WAS MADE NEGLIGENTLY OR WITH INTENT TO DECEIVE THE IA, BELSIGN, OR ANY PERSON RECEIVING OR RELYING ON THE CERTIFICATE; OR (III) FAILURE TO PROTECT THE SUBSCRIBER'S PRIVATE KEY, TO USE A TRUSTWORTHY SYSTEM, OR TO OTHERWISE TAKE THE PRECAUTIONS NECESSARY TO PREVENT THE COMPROMISE, LOSS, DISCLOSURE, MODIFICATION, OR UNAUTHORIZED USE OF THE SUBSCRIBER'S PUBLIC KEY. When a certificate is issued at the request of a subscriber's agent, both the agent and the subscriber shall jointly and severally indemnify BelSign, and their agents and contractors pursuant to this subsection. The subscriber has a continuing duty to notify the issuer of any misrepresentations and omissions made by an agent. Publication Upon subscriber's acceptance of the certificate, and checking by BelSign, BelSign shall publish a copy of the certificate in the BelSign repository and in one or more other repositories, as determined by BelSign. Subscribers may publish their BelSign CPS certificates in other repositories. USE OF CERTIFICATES This section addresses the rights and obligations of the entities whose rights and obligations are intended to be controlled by this CPS (see definition of "parties") regarding the use of digital signatures and digitally signed messages corresponding to BelSign-issued certificates. The parties (BelSign and the parties who are "users" of the certificate, i.e., the subscriber and the relying parties), are hereby notified of the following rules governing the respective rights and obligations of the parties among themselves, which are also deemed to be agreed by the parties, effective (i) upon publication of this CPS in the case of Belsign; (ii) upon submission of an application for a certificate, in the case of an applicant or subscriber; and (iii) upon reliance of a certificate or a digital signature verifiable with reference to a public key listed in the certificate, in the case of a recipient of a certificate or a relying party. Verification of Digital Signatures Verification of a digital signature, is undertaken to determine that (i) the digital signature was created by the private key corresponding to the public key listed in the signerÕs certificate and that (ii) the associated message has not been altered since the digital signature was created. Such verification shall be undertaken in a manner consistent with this CPS, as follows: ¥ Establishing a certificate chain for the digital signature Ð A digital signature shall be verified with regard to a successful confirmation of certificate chain. ¥ Ensuring that the identified certificate chain is the most suitable for the digital signature Ð It is possible to have more than one valid certificate chain leading from a given certificate to an acceptable root (such as through cross-certification among other possibilities). If there is more than one certificate chain to an acceptable root, the person verifying the digital signature may have various options in selecting and validating the certificate chain. ¥ Checking the BelSign (or other) repository for revocation or suspension of certificates in the chain Ð The recipient must determine if any of the certificates along the chain from the signer to an acceptable root within the PCS has been revoked or suspended, because a revocation or suspension has the effect of prematurely terminating the operational period during which verifiable digital signatures can be created. This may be ascertained in two different ways. The BelSign repository may be queried for the most up-to-date revocation status. Alternatively, CRLs may have been provided in the certificate chain. These CRLs may be used to determine the revocation status of certificates in the chain. ¥ Delimiting data to which digital signatures are attached Ð In order to verify a digital signature it is necessary to know precisely what data has been signed. In the case of public key cryptography standards (PKCS), a standard signed message format is specified to accurately denote the signed data. ¥ Indicating digital signature time and date of creation Ð In order for a digital signature to support nonrepudiation, the data to which the corresponding digital signature is attached must include, or reference, a time stamp. The time stamp shall reflect the time at which date and time the digital signature is affixed. ¥ Establishing the assurances intended by its signer Ð Various technical means may be used to determine the purpose (or meaning) of the digital signature intended by its signer. In formal protocols (such as EDI), digital signatures are classified as specified security services with defined semantics so as to convey their precise meaning. The verifier should also determine whether the certificate is normal or provisional. ¥ Ensuring that all certificates in the chain authorize use of an end-user subscriber private key Ð Belsign may limit the purposes for which a private key corresponding to a certificate it issues may be used. Such limitations are indicated or incorporated by reference in the certificate and provide a means to warn recipients of situations for which reliance upon the certificate would not be considered reasonable. Persons validating certificates must inspect certificate contents for such warnings and limitations to ensure that no certificate in the chain denies appropriate use of an end-user subscriber certificate. ¥ Confirmation of a certificate chain Ð Each IA is certified by a superior IA (except for the root, which has a self-signed public key) and thus inherits the trust associated with its superior IA. Each IA is presumed to be at least as trustworthy as its superior IA. Confirmation of a certificate chain is the process of validating a certificate chain and subsequently validating an end-user subscriber certificate. Effect of Validating an End-User Subscriber Certificate A digital signature is binding against its maker if it (i) was created during the operational period of a valid certificate, (ii) such digital signature can be properly verified by confirmation of certificate chain (iii) the relying party has no knowledge or notice of a breach of the requirements of this CPS by the signer, and (iv) the relying party has complied with all requirements of this CPS. Procedures upon Failure of Digital Signature Verification A person relying on an unverifiable digital signature assumes all risks with regard to it and is not entitled to any presumption that the digital signature is effective as the signature of the subscriber under CPS §§ 8.4-8.6. Reliance on Digital Signatures A recipient of a message signed by a digital signature of the subscriber may rely upon that digital signature as binding against the subscriber if: (i) the digital signature was created during the operational period of a valid certificate and it can be verified by referencing a validated certificate chain, and (ii) such reliance is reasonable under the circumstances. If the circumstances indicate a need for additional assurances, the relying party must obtain such assurances for such reliance to be reasonable. Additionally, the verifier should consider the class of certificate. The final decision concerning whether or not to rely on a verified digital signature is exclusively that of the verifier. Writings A message bearing a digital signature verified by the public key listed in a valid certificate is as valid, effective, and enforceable as if the message had been written and signed on paper. Signatures Where a rule of law or applicable practice requires a signature or provides for certain consequences in the absence of a signature, that rule is satisfied in relation to a message by a digital signature affixed by a signer with the intention of signing a message and subsequently verified by reference to the public key listed in a valid certificate. Security Measures Any person using or relying upon a BelSign PCS-issued certificate in conjunction with a message shall apply reasonable security measures to the message to provide message authentication and, as required, to support data confidentiality. Issuing Certificates Only authorized IAs may issue certificates. CERTIFICATE SUSPENSION AND REVOCATION This section explains the circumstances under which a certificate may (or must) be suspended or revoked. It also details the procedures for suspending, revoking, and reinstating certificates. Reasons for Suspension or Revocation, Generally A certificate shall be suspended or revoked if ¥ there has been a loss, theft, modification, unauthorized disclosure, or other compromise of the private key of the certificateÕs subject, ¥ the certificateÕs subject (whether BelSign or a subscriber) has breached a material obligation under this CPS, or ¥ the performance of a personÕs obligations under this CPS is delayed or prevented by an act of God, natural disaster, computer or communications failure, or other cause beyond the person's reasonable control, and as a result another personÕs information is materially threatened or compromised. Suspension or Revocation of a BelSign Certificate BelSign must make a reasonable effort to suspend or revoke a certificate, if it determines any of the following: ¥ a material fact represented in the certificate is known or reasonably believed by BelSign to be false, ¥ a material prerequisite to certificate issuance was neither satisfied nor waived, ¥ the private key or trustworthy system was compromised in a manner materially affecting the certificate's reliability, or ¥ the certificateÕs subject has breached a material obligation under this CPS. Note: Suspension is not currently available for end-user subscriber certificates. It is contemplated to be offered as a service later in 1997. BelSign will announce its availability on its website. Revocation is currently available for both end-user subscriber and servers. Termination of a Suspension of a BelSign Certificate BelSign shall terminate a certificate suspension (thereby reinstating the certificate), if (i) the subscriber requests it and BelSign confirms his or her identity, (ii) BelSign determines that the request for suspension was made without the suspended Belsign's authorization, or (iii) BelSign determines that the reasons for the suspension were unfounded. Revocation at SubscriberÕs Request BelSign must revoke a certificate upon the subscriberÕs request once it has confirmed that the person requesting the revocation is in fact the subscriber. Revocation Due to Faulty Issuance BelSign shall revoke a certificate promptly upon discovering and confirming that it was not issued in accordance with the procedures required by this CPS. A certificate may be suspended while BelSign investigates to confirm grounds for revocation. Table 12 details revocation prerequisites. ¥ a listing of revoked (and suspended) certificates available through a secure channel, ¥ a certificate revocation list (CRL) designating both revoked and suspended certificates, BelSign may also provide the following suspension and revocation notification services upon request and payment of associated fees by the requester: ¥ confirming that a certificate has been suspended or revoked, if asked to do so by a recipient of a digitally signed message originated by the subject of that certificate, and ¥ providing a Òpush serviceÓ to provide notice from BelSign to the requester upon the suspension or revocation of designated certificates. Effect of Suspension or Revocation On Certificates During suspension, or permanently upon revocation of a subscriber's certificate, that certificate's operational period shall immediately be considered terminated. On Underlying Obligations Suspension or revocation of a certificate shall not affect any underlying contractual obligations created or communicated under this CPS. Safeguarding of Private Key upon Suspension or Revocation Private keys corresponding to public keys contained in suspended or revoked certificates shall be safeguarded by the subscriber in a trustworthy manner throughout the period of suspension and, upon revocation for the applicable retention period, unless destroyed. CERTIFICATE EXPIRATION This section describes partiesÕ obligations regarding certificate expiration. This is distinct from certificate suspension and revocation (see CPS ¤ 9). Certificate validity and operational periods are addressed in CPS ¤ 6.7. Notice Prior to Expiration BelSign will make a reasonable effort to notify subscribers, via E-mail, of the impending expiration of their certificates (Except for Class1 Certificates). Such notice is intended solely for the convenience of the subscriber in the re-enrollment or renewal process, whichever is applicable. Effect of Certificate Expiration on Underlying Obligations Expiration of a certificate shall not affect the validity of any underlying contractual obligations created or communicated under this CPS. Re-enrollment and Subscriber Renewal Subscriber renewal and re-enrollment shall be initiated as follows: CLASS 1 OBLIGATIONS OF BELSIGN, AND LIMITATIONS UPON SUCH OBLIGATIONS This section summarizes and provides references to the warranties and promises made by BelSign and presents disclaimers and limitations upon such obligations. Limited Warranties and Other Obligations BelSign (to the extent specified in the referenced CPS sections) warrant and promise to ¥ provide the infrastructure and certification services, including the establishment and operation of the BelSign repository, as delineated in CPS ¤ 2 (BelSign Certification Infrastructure), ¥ provide the controls and foundation for PKI, including IA key generation, key protection, and secret sharing procedures, presented in CPS ¤ 3 (Foundation for Certification Operations), ¥ perform the application validation procedures for the indicated class of certificate as set forth in CPS ¤ 5 (Validation of Certificate Applications), ¥ issue certificates in accordance with CPS ¤ 6 and honor the various representations to subscribers and to relying parties presented in CPS ¤ 6.5 (IA's Representations Upon Certificate Issuance), ¥ publish accepted certificates in accordance with CPS ¤ 6.6 (BelSign's Requirements Upon Publication) and CPS ¤ 7.5 (Publication), ¥ perform the obligations of an IA and support the rights of the subscribers and relying parties who use certificates in accordance with CPS § 8 (Use of Certificates), ¥ suspend and revoke certificates as required by CPS ¤ 9 (Certificate Suspension and Revocation), ¥ provide for the expiration, re-enrollment, and renewal of certificates as stated in CPS ¤ 10 (Certificate Expiration), and ¥ comply with the provisions contained in CPS ¤ 12 (Miscellaneous Provisions). Additionally, BelSign warrant that their own private keys are not compromised unless they provide notice to the contrary via the BelSign repository. BELSIGN MAKES NO OTHER WARRANTIES AND HAS NO FURTHER OBLIGATIONS UNDER THIS CPS. Disclaimers and Limitations on Obligations of BelSign EXCEPT AS EXPRESSLY PROVIDED IN THE FOREGOING (CPS ¤ 11.1), BELSIGN DISCLAIMS ALL WARRANTIES AND OBLIGATIONS OF ANY TYPE, INCLUDING ANY WARRANTY OF MERCHANTABILITY, ANY WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE, AND ANY WARRANTY OF THE ACCURACY OF INFORMATION PROVIDED, AND FURTHER DISCLAIMS ANY AND ALL LIABILITY FOR NEGLIGENCE AND LACK OF REASONABLE CARE. Except as expressly stated in the foregoing CPS ¤ 11.1, BelSign ¥ does not warrant the accuracy, authenticity, reliability, completeness, currentness, merchantability, or fitness of any information contained in certificates or otherwise compiled, published, or disseminated by or on behalf of BelSign, ¥ shall not incur liability for representations of information contained in a certificate, provided the certificate content substantially complies with this CPS, ¥ does not warrant ÒnonrepudiationÓ of any certificate or message (because nonrepudiation is determined exclusively by law and the applicable dispute resolution mechanism), and ¥ does not warrant any software. Exclusion of Certain Elements of Damages IN NO EVENT (EXCEPT FOR FRAUD OR WILFULL MISCONDUCT) SHALL BELSIGN BE LIABLE FOR ANY INDIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES, OR FOR ANY LOSS OF PROFITS, LOSS OF DATA, OR OTHER INDIRECT, CONSEQUENTIAL OR PUNITIVE DAMAGES ARISING FROM OR IN CONNECTION WITH THE USE, DELIVERY, LICENSE, PERFORMANCE OR NONPERFORMANCE OF CERTIFICATES, DIGITAL SIGNATURES, OR ANY OTHER TRANSACTIONS OR SERVICES OFFERED OR CONTEMPLATED BY THIS CPS, EVEN IF BELSIGN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Damage and Loss Limitations IN NO EVENT (EXCEPT FOR FRAUD OR WILFULL MISCONDUCT) WILL THE LIABILITY OF BELSIGN TO ALL PARTIES (INCLUDING WITHOUT LIMITATION A SUBSCRIBER, AN APPLICANT, A RECIPIENT, OR A RELYING PARTY) EXCEED THE APPLICABLE LIABILITY CAP FOR SUCH CERTIFICATE SET FORTH IN TABLE 14, BELOW. THE LIABILITY OF BELSIGN TO ANY AND ALL PERSONS CONCERNING A SPECIFIC CERTIFICATE SHALL BE LIMITED TO AN AMOUNT NOT TO EXCEED THE FOLLOWING, FOR THE AGGREGATE OF ALL DIGITAL SIGNATURES AND TRANSACTIONS RELATED TO SUCH CERTIFICATE: This limitation on damages applies to loss and damages of all types, including but not limited to direct, compensatory, indirect, consequential, exemplary, or incidental damages incurred by any person, including without limitation a subscriber, an applicant, a recipient, or a relying party, that are caused by reliance on or use of a certificate BelSign issues, manages, uses, suspends or revokes, or such a certificate that expires. This limitation on damages applies as well to liability under contract, tort, and any other form of liability claim within the limits of the law. The liability cap on each certificate shall be the same regardless of the number of digital signatures, transactions or claims related to such certificate. In the event the liability cap is exceeded, the available liability cap shall be apportioned first to the earliest claims to achieve final dispute resolution, unless otherwise ordered by a court of competent jurisdiction. In no event shall BelSign be obligated to pay more than the aggregate liability cap for each certificate, regardless of the method of apportionment among claimants to the amount of the liability cap. Subscriber Liability to Relying Parties Without limiting other subscriber obligations stated in this CPS, subscribers are liable for any misrepresentations they make in certificates to third parties who, having verified one or more digital signatures with the certificate, reasonably rely on the representations contained therein. No Fiduciary Relationship BELSIGN IS NOT THE AGENT, FIDUCIARY, TRUSTEE, OR OTHER REPRESENTATIVE OF SUBSCRIBERS OR RELYING PARTIES. The relationship between BelSign and subscribers and that between BelSign and relying parties is not that of agent and principal. Neither subscribers nor relying parties have any authority to bind BelSign, by contract or otherwise, to any obligation. BelSign shall make no representations to the contrary, either expressly, implicitly, by appearance, or otherwise. Hazardous Activities BelSignÕs public certification services are not designed, intended, or authorized for use or resale as control equipment in hazardous circumstances or for uses requiring fail-safe performance such as the operation of nuclear facilities, aircraft navigation or communication systems, air traffic control systems, or weapons control systems, where failure could lead directly to death, personal injury, or severe environmental damage. MISCELLANEOUS PROVISIONS This section presents general terms and conditions of this CPS that are not covered in the other sections. Conflict of Provisions In the event of a conflict between this CPS and other rules, guidelines, or contracts, the subscriber shall be bound by the provisions of this CPS, except as to other contracts either (i) predating the first public release of the CPS or (ii) expressly superseding this CPS for which such contract shall govern as to the parties thereto, and except to the extent that the provisions of this CPS are prohibited by law. Compliance with Export Laws and Regulations Export of certain software used in conjunction with BelSignÕs PCS may require the approval of appropriate government authorities. The parties shall conform to applicable export laws and regulations. Governing Law The Belgian law shall govern the enforceability, construction, interpretation, and validity of this CPS, irrespective of contract or other choice of law provisions. This choice of law is made to ensure uniform procedures and interpretation for all users, no matter where they reside or use their certificates. Dispute Resolution Notification Among Parties to a Dispute Before invoking arbitration (as detailed below) with respect to a dispute involving any aspect of this CPS or a certificate issued by BelSign, aggrieved persons shall notify BelSign, and any other party to a dispute for the purpose of seeking dispute resolution among themselves. Arbitration If the dispute is not resolved within ten (10) days after initial notice pursuant to CPS Sect. 12.4.1, then parties will submit the dispute to arbitration, in accordance with art. 1676-1723 of the Belgian Judicial Code. There will be 3 arbitrators. Each party will chose one arbitrator. The third arbitrator will be chosen by the two parties in agreement. The place of the arbitration will be determined by mutual agreement. The cost and its division will be determined by the arbitrators. Successors and Assigns This CPS inures to the benefit of, and shall be binding upon the successors, executors, heirs, representatives, administrators, and assigns, whether express, implied, or apparent, of the parties. The rights and obligations detailed in this CPS are assignable by the parties, by operation of law (including as a result of merger or a transfer of a controlling interest in voting securities) or otherwise, provided such assignment is undertaken consistent with CPS ¤ 3.21, concerning termination or cessation of IA operations; and provided further, that such assignment does not effect a novation of any other debts or obligations the assigning party owes to other parties at the time of such assignment. Merger No term or provision of this CPS directly affecting the respective rights and obligations of BelSign may be orally amended, waived, supplemented, modified, or terminated, except by an authenticated message or document of such affected party, except to the extent provided otherwise herein. Severability If any provision of this CPS, or the application thereof, is for any reason and to any extent found to be invalid or unenforceable, the remainder of this CPS (and the application of the invalid or unenforceable provision to other persons or circumstances) shall be interpreted so as best to reasonably effect the intent of its parties. IT IS EXPRESSLY UNDERSTOOD AND AGREED THAT EACH AND EVERY PROVISION OF THIS CPS THAT PROVIDES FOR A LIMITATION OF LIABILITY, DISCLAIMER OF OR LIMITATION UPON ANY WARRANTIES OR OTHER OBLIGATIONS, OR EXCLUSION OF DAMAGES IS INTENDED TO BE SEVERABLE AND INDEPENDENT OF ANY OTHER PROVISION AND IS TO BE ENFORCED AS SUCH. Interpretation Unless otherwise provided, this CPS shall be interpreted consistently with what is commercially reasonable under the circumstances. In interpreting this CPS, regard is to be given to its international scope and application, to the benefits in promoting uniformity in its application, and to the observance of good faith. No Waiver Failure by any person to enforce a provision of this CPS will not be deemed a waiver of future enforcement of that or any other provision. Notice Whenever any person hereto desires or is required to give any notice, demand, or request with respect to this CPS, such communication shall be made either using digitally signed messages consistent with the requirements of this CPS, or in writing. Electronic communications shall be effective upon the senderÕs receiving a valid, digitally signed acknowledgment of receipt from the recipient. Such acknowledgment must be received within five (5) days, or else written notice must then be communicated. Communications in writing must be delivered by a courier service that confirms delivery in writing or via certified or registered mail, postage prepaid, return receipt requested, addressed as follows: To BelSign: BelSign, NV/SA. Parijsstraat 74 3000 Leuven Attn: Certification Services Headings and Appendices of this CPS The headings, subheadings, and other captions in this CPS are for convenience and reference only and shall not be used in interpreting, construing, or enforcing any of the provisions of this CPS. The appendices, including the definitions to this CPS, are for all purposes an integral and binding part of the CPS. Change of Subscriber Information on File with BelSign; Change to CPS Any subscriber may change certain information about itself on file with BelSign that does not appear within its certificate (typically, information provided in the subscriber agreement or certificate application) upon giving thirty (30) days notice in accordance with CPS ¤ 12.10 (Notice). Such change in information shall be effective after such thirty (30) day period. BelSign may amend or modify this CPS from time to time (prospectively and not retroactively). Each change shall become effective fifteen (15) days after BelSign publishes a proposal for the change in the BelSign repository unless (i) BelSign has published a notice of withdrawal of the proposed change in the BelSign repository prior to the end of such fifteen (15) day period, or (ii) failure by BelSign to make the proposed change may result in a compromise of the PCS or any portion of it, in which case, the proposed change is effective upon publication in the BelSign repository. A subscriberÕs decision not to request revocation of his, her, or its certificate following the publication of a proposed change shall constitute agreement to the change. Property Interests in Security Materials Unless otherwise agreed, property interests in the following security-related information materials and data are regarded as the property of the parties indicated below: ¥ Certificates: Certificates are the personal property of their respective IA. Certificates issued by BelSign CA contain a copyright notice: ÒCopyright (c)1996 BelSign, Inc., All Rights ReservedÓ or Ò(c)96Ó in connection with BelSign. Permission is hereby granted to reproduce and distribute certificates on a nonexclusive, royalty-free basis, provided that they are reproduced and distributed in full, except that certificates shall not be published in any publicly accessible repository or directory without the express written permission of BelSign. This restriction is intended, in part, to protect the privacy of subscribers against unauthorized republication of their certificates. Questions concerning this copyright notice should be sent to BelSign as listed in CPS ¤ 12.10 (Notice), or to practices@belsign.be. ¥ CPS: This CPS is the personal property of BelSign, Inc. ¥ Distinguished names: Distinguished names are the personal property of the persons named (or their employer or principal). ¥ Private keys: Private keys are the personal property of the subscribers who rightfully use or are capable of using them (or their employer or principal), regardless of the physical medium within which they are stored and protected. ¥ Public keys: Public keys are the personal property of subscribers (or their employer or principal), regardless of the physical medium within which they are stored and protected. ¥ Secret shares of private keys: Secret shares of an IAÕs private key are the personal property of the applicable IA. Infringement and Other Damaging Material Certificate applicants (and, upon acceptance, subscribers) represent and warrant that their submission (to BelSign) and use of a domain and distinguished name (and all other certificate application information) does not interfere with or infringe upon the rights of any third parties in any jurisdiction with respect to their trademarks, service marks, trade names, company names, or any other intellectual property right, and that they are not seeking to use the domain and distinguished names for any unlawful purpose, including, without limitation, tortious interference with contract or prospective business advantage, unfair competition, injuring the reputation of another, and confusing or misleading a person, whether natural or incorporated. Certificate applicants (and, upon acceptance, subscribers) shall defend, indemnify, and hold BelSign harmless for any loss or damage resulting from any such interference or infringement. BelSign shall not be responsible for nonverified subscriber information (NSI) submitted to BelSign, or the BelSign repository or otherwise submitted for inclusion in a certificate. In particular, subscribers shall be solely responsible for the legality of the information they present for use in certificates issued under this CPS, in any jurisdiction in which such content may be used or viewed. Because laws regarding the transmission and availability of information content are constantly changing and vary widely, certificate applicants' and subscribersÕ responsibilities are determined not only by laws in existence at the time BelSign issues a certificate to a certificate applicant but also by any laws that may be enacted after such date. Certificate applicants and subscribers should be aware that there are many laws regarding the transmission of data, especially data that is encrypted or involves encryption algorithms, and that these laws may vary dramatically from country to country. Further, it is generally not possible to limit the distribution of content on the Internet or certain other networks based on the locality of the user/viewer, and this may require certificate applicants and subscribers to comply with the laws of each jurisdiction in which the content may be viewed or used. Certificate applicants and subscribers will not submit to BelSign, or the BelSign repository any materials that contain statements that (i) are libelous, defamatory, obscene, pornographic, abusive, bigoted, hateful, or racially offensive, (ii) advocate illegal activity or discuss illegal activities with the intent to commit them, or (iii) otherwise violate any law. Fees BelSign may charge subscribers fees for their use of BelSign's services. A current schedule of such fees is available from the BelSign repository at https://www.belsign.be. Such fees are subject to change seven (7) days following their posting in the BelSign repository. Choice of Cryptographic Methods All persons acknowledge that they (not BelSign) are solely responsible for and have exercised independent judgment in choosing security software, hardware, and encryption/digital signature algorithms, including their respective parameters, procedures, and techniques. Survival The obligations and restrictions contained within CPS ¤¤ 3.7 (Audit), 3.11 (Confidential Information), CPS ¤ 11 (Obligations of BelSign, and Limitations Upon Such Obligations), and CPS ¤ 12 (Miscellaneous Provisions) shall survive the termination of this CPS. *** APPENDICES Definitions A-B ACCEPT (A CERTIFICATE) To demonstrate approval of a certificate by a certificate applicant while knowing or having notice of its informational contents, in accordance with the CPS. ACCESS A specific type of interaction between a submission and communications or information resources that results in a flow of information, the exercise of control, or the activation of a process. ACCREDITATION A formal declaration by a BelSignÐdesignated approving authority that a particular information system, professional or other employee or contractor, or organization is approved to perform certain duties and to operate in a specific security mode, using a prescribed set of safeguards. AFFIRM / AFFIRMATION To state or indicate by conduct that data is correct or information is true. ALIAS A pseudonym. APPLICANT (See CERTIFICATE APPLICANT) ARCHIVE To store records and associated journals for a given period of time for security, backup, or auditing purposes. ASSURANCES Statements or conduct intended to convey a general intention, supported by a good-faith effort, to provide and maintain a specified service by an IA. "Assurances" does not necessarily imply a guarantee that the services will be performed fully and satisfactorily. Assurances are distinct from insurance, promises, guarantees, and warranties, unless otherwise expressly indicated. AUDIT A procedure used to validate that controls are in place and adequate for their purposes. Includes recording and analyzing activities to detect intrusions or abuses into an information system. Inadequacies found by an audit are reported to appropriate management personnel. AUTHENTICATE (See AUTHENTICATION) AUTHENTICATED RECORD A signed document with appropriate assurances of authentication or a message with a digital signature verified by a valid Class 3 certificate by a relying party. However, for suspension and revocation notification purposes, the digital signature contained in such notification message must have been created by the private key corresponding to the public key contained in the certificate for the applicable certificate class. AUTHENTICATION A process used to confirm the identity of a person or to prove the integrity of specific information. Message authentication involves determining its source and verifying that it has not been modified or replaced in transit. (Cf., VERIFY (a DIGITAL SIGNATURE)) AUTHENTICODE (see MICROSOFT AUTHENTICODE; SOFTWARE VALIDATION) AUTHORIZATION The granting of rights, including the ability to access specific information or resources. AVAILABILITY The extent to which information or processes are reasonably accessible and usable, upon demand, by an authorized entity, allowing authorized access to resources and timely performance of time-critical operations. BINDING An affirmation by an IA (or its LRA) of the relationship between a named entity and its public key. C CERTIFICATE (PUBLIC KEY CERTIFICATE) A message (see definition for MESSAGE) that, at least, states a name or identifies the IA, identifies the subscriber, contains the subscriberÕs public key, identifies the certificate's operational period, contains a certificate serial number, and is digitally signed by the IA. All references to a ÒClass [1, 2, or 3] certificateÓ or to a ÒcertificateÓ without a modifying adjective are intended as references to normal certificates, unless the context requires otherwise. References to a certificate refer exclusively to certificates issued by an IA. (Cf., NORMAL CERTIFICATE) CERTIFICATE APPLICANT A person or authorized agent that requests the issuance of a public key certificate by an IA. (Cf., CA APPLICANT; SUBSCRIBER) CERTIFICATE APPLICATION A request from a certificate applicant (or authorized agent) to an IA for the issuance of a certificate. (Cf., CERTIFICATE APPLICANT; CERTIFICATE SIGNING REQUEST) CERTIFICATE CHAIN An ordered list of certificates containing an end-user subscriber certificate and IA certificates (See VALID CERTIFICATE) CERTIFICATE EXPIRATION The time and date specified in the certificate when the operational period ends, without regard to any earlier suspension or revocation. CERTIFICATE EXTENSION An extension field to a certificate which may convey additional information about the public key being certified, the certified subscriber, the certificate issuer, and/or the certification process. Standard extensions are defined in Amendment 1 to ISO/IEC 9594-8:1995 (X.509). Custom extensions can also be defined by communities of interest. CERTIFICATE HIERARCHY A PCS domain of IAs, each categorized with respect to its role in a "tree structure" of subordinate IAs. An IA issues and manages certificates for end-user subscribers and/or for one or more IAs at the next level. Note: an IA in a trust hierarchy must observe uniform practices addressing issues such as naming, maximum number of levels, etc., to assure integrity of the domain and thereby ensure uniform accountability, auditability, and management through the use of trustworthy operational processes. CERTIFICATE ISSUANCE The actions performed by an IA in creating a certificate and notifying the certificate applicant (anticipated to become a subscriber) listed in the certificate of its contents. CERTIFICATE MANAGEMENT Certificate management includes, but is not limited to, storage, dissemination, publication, revocation, and suspension of certificates. An IA undertakes certificate management functions by serving as a registration authority for subscriber certificates. An IA designates issued and accepted certificates as valid by publication. CERTIFICATE OF AUTHENTICITY A document issued by an authorized official of the jurisdiction in which an acknowledgment by a notary was taken, such as the secretary of state of a state (U.S.) to authenticate the status of a notary. CERTIFICATE REVOCATION (See REVOKE A CERTIFICATE) CERTIFICATE REVOCATION LIST (CRL) A periodically (or exigently) issued list, digitally signed by an IA, of identified certificates that have been suspended or revoked prior to their expiration dates. The list generally indicates the CRL issuer's name, the date of issue, the date of the next scheduled CRL issue, the suspended or revoked certificates' serial numbers, and the specific times and reasons for suspension and revocation. CERTIFICATE SERIAL NUMBER A value that unambiguously identifies a certificate generated by an IA. CERTIFICATE SIGNING REQUEST (CSR) A machine-readable form of a certificate application. (Cf., CERTIFICATE APPLICATION) CERTIFICATE SUSPENSION (See SUSPEND A CERTIFICATE) CERTIFICATION / CERTIFY The process of issuing a certificate by an IA. CERTIFICATION AUTHORITY (CA) A person (see definition for PERSON) authorized to issue certificates. BelSign is a CA. (Cf., REGISTRATION AUTHORITY; TRUSTED THIRD PARTY) CERTIFICATION PRACTICE STATEMENT (CPS) This document, as revised from time to time (representing BelSignÕs statement of the practices BelSign employs in issuing certificates). CERTIFIER (See IA) CHALLENGE PHRASE A set of numbers and/or letters that are chosen by a certificate applicant, communicated to the IA with a certificate application, and used by the IA to authenticate the subscriber for various purposes as required by the CPS. A challenge phrase is also used by a secret share holder to authenticate himself, herself, or itself to a secret share issuer. CLASS [1, 2, OR 3] CERTIFICATE A certificate of a specified level of trust. (See CPS ¤ 2.2) COMMERCIAL REASONABLENESS In the context of electronic commerce, the implementation and use of technology, controls, and administrative and operational procedures that reasonably ensure system and message trustworthiness. COMMERCIAL SOFTWARE PUBLISHER CERTIFICATE A Class 3 Highest Level certificate that is issued to organizations only and is used for software validation. (Cf., INDIVIDUAL SOFTWARE PUBLISHER CERTIFICATE; SOFTWARE VALIDATION) COMMON KEY Some systems of cryptographic hardware require arming through a secret-sharing process and require that the last of these shares remain physically attached to the hardware in order for it to stay armed. In this case common key refers to this last share. It is not assumed to be secret as it is not continually in an individualÕs possession. COMPROMISE A violation (or suspected violation) of a security policy, in which an unauthorized disclosure of, or loss of control over, sensitive information may have occurred. (Cf., DATA INTEGRITY) CONFIDENTIALITY The condition in which sensitive data is kept secret and disclosed only to authorized parties. CONFIRM To ascertain through appropriate inquiry and investigation. (Cf., AUTHENTICATE; VERIFY A DIGITAL SIGNATURE) CONFIRMATION OF CERTIFICATE CHAIN The process of validating a certificate chain and subsequently validating an end-user subscriber certificate. CONTENT INTEGRITY SERVICES Content integrity services provide certificates to software publishers who desire to digitally sign their software publications to facilitate their customersÕ (end-usersÕ) ability to undertake software validation. CONTROLS Measures taken to ensure the integrity and quality of a process. CORRESPOND To belong to the same key pair. (See also PUBLIC KEY; PRIVATE KEY) CROSS-CERTIFICATION A condition in which either or both BelSign and a non-BelSign certificate issuing entity (representing another certification domain) issues a certificate having the other as the subject of that certificate. CRYPTOGRAPHIC ALGORITHM A clearly specified mathematical process for computation; a set of rules that produce a prescribed result. CRYPTOGRAPHY (Cf., PUBLIC KEY CRYPTOGRAPHY) (i) The mathematical science used to secure the confidentiality and authentication of data by replacing it with a transformed version that can be reconverted to reveal the original data only by someone holding the proper cryptographic algorithm and key. (ii) A discipline that embodies the principles, means, and methods for transforming data in order to hide its information content, prevent its undetected modification, and/or prevent its unauthorized uses. CRYPTOMODULE A trustworthy implementation of a cryptosystem which safely performs encryption and decryption of data. D DATA Programs, files, and other information stored in, communicated, or processed by a computer. DATABASE A set of related information created, stored, or manipulated by a computerized management information system. DATA CONFIDENTIALITY (See CONFIDENTIALITY) DATA INTEGRITY A condition in which data has not been altered or destroyed in an unauthorized manner. (See also THREAT; cf., COMPROMISE) DENIAL OF SERVICE (See AVAILABILITY) DIGITAL IDsm (See CERTIFICATE) VeriSignÕs service-marked name for a certificate. DIGITAL SIGNATURE A transformation of a message using an asymmetric cryptosystem such that a person having the initial message and the signerÕs public key can accurately determine whether the transformation was created using the private key that corresponds to the signer's public key and whether the message has been altered since the transformation was made. DIRECTORY (Cf., REPOSITORY) DISTINGUISHED NAME A set of data that identifies a real-world entity, such as a person in a computer-based context. (e.g., countryName=US, state=California, organizationName=Electronic Inc., commonName=JohnDoe). DOCUMENT A record consisting of information inscribed on a tangible medium such as paper rather than computer-based information. (Cf., MESSAGE; RECORD) E-F ELECTRONIC MAIL (ÒE-MAILÓ) Messages sent, received or forwarded in digital form via a computer-based communication mechanism. ENCRYPTION The process of transforming plaintext data into an unintelligible form (ciphertext) such that the original data either cannot be recovered (one-way encryption) or cannot be recovered without using an inverse decryption process (two-way encryption). END-USER SUBSCRIBER A subscriber which is not also an IA. ENHANCED NAMING The use of an extended organization field (OU=) in an X.509 v3 certificate. ENROLLMENT The process of a certificate applicantÕs applying for a certificate. ENTITY (See PERSON) EXTENSIONS Extension fields in X.509 v3 certificates. (See X.509) FILE TRANSFER PROTOCOL (FTP) The application protocol that offers file system access from the Internet suite of protocols. FTP (See FILE TRANSFER PROTOCOL) GÐH GENERATE A KEY PAIR A trustworthy process of creating private keys during certificate application whose corresponding public key are submitted to the applicable IA during certificate application in a manner that demonstrates the applicant's capacity to use the private key. HASH (HASH FUNCTION) An algorithm that maps or translates one set of bits into another (generally smaller) set in such a way that i. A message yields the same result every time the algorithm is executed using the same message as input. ii. It is computationally infeasible for a message to be derived or reconstituted from the result produced by the algorithm. iii. It is computationally infeasible to find two different messages that produce the same hash result using the same algorithm. I IA (See ISSUING AUTHORITY) IDENTIFICATION / IDENTIFY The process of confirming the identity of a person. Identification is facilitated in public key cryptography by means of certificates. IDENTITY A unique piece of information that marks or signifies a particular entity within a domain. Such information is only unique within a particular domain. INCORPORATE BY REFERENCE To make one message a part of another message by identifying the message to be incorporated, with information that enables the receiving party to access and obtain the incorporated message in its entirety, and by expressing the intention that it be part of the incorporating message. Such an incorporated message shall have the same effect as if it had been fully stated in the message to the extent permitted by law. INDIVIDUAL SOFTWARE PUBLISHER CERTIFICATE A Class 2 certificate that is issued to individuals only and is used for software validation. (Cf., COMMERCIAL SOFTWARE PUBLISHER CERTIFICATE; SOFTWARE VALIDATION) INTEGRITY (See DATA INTEGRITY) ISSUING A CERTIFICATE (See CERTIFICATE ISSUANCE) ISSUER (See ISSUING AUTHORITY) ISSUING AUTHORITY (IA) BelSign that issues, suspends, or revokes a certificate. IAs are identified by a distinguished name on all certificates and CRLs they issue. J-L KEY GENERATION The trustworthy process of creating a private key/public key pair. The public key is supplied to an IA during the certificate application process. KEY PAIR A private key and its corresponding public key. The public key can verify a digital signature created by using the corresponding private key. In addition, depending upon the type of algorithm implemented, key pair components can also encrypt and decrypt information for confidentiality purposes, in which case a private key uniquely can reveal information encrypted by using the corresponding public key. LOCAL REGISTRATION AUTHORITY (LRA) An entity appointed by an IA to assist other entities in applying for certificates, revoking (or where authorized, suspending) their certificates, or both and also approving such applications. An LRA is not the agent of a certificate applicant. An LRA may not delegate the authority to approve certificate applications. M-N MESSAGE A digital representation of information; a computer-based record. A subset of RECORD. (Cf., MESSAGE; RECORD) MESSAGE INTEGRITY (See INTEGRITY) MICROSOFT AUTHENTICODE (SEE SOFTWARE VALIDATION) NAME A set of identifying attributes purported to describe an entity of a certain type. NAMING Naming is the assignment of descriptive identifiers to objects of a particular type by an authority which follows specific issuing procedures and maintains specific records pertinent to an identified registration process. (Cf., NAMING AUTHORITY; BELSIGN NAMING AUTHORITY) NAMING AUTHORITY A body which executes naming policy and procedures and has control over the registration and assignment of primitive (basic) names to objects of a particular class. (Cf., NAMING; BELSIGN NAMING AUTHORITY) NONREPUDIATION Provides proof of the origin or delivery of data in order to protect the sender against a false denial by the recipient that the data has been received or to protect the recipient against false denial by the sender that the data has been sent. Note: Only a trier of fact (someone with the authority to resolve disputes) can make an ultimate determination of nonrepudiation. By way of illustration, a digital signature verified pursuant to this CPS can provide proof in support of a determination of nonrepudiation by a trier of fact, but does not by itself constitute nonrepudiation. NONVERIFIED SUBSCRIBER INFORMATION (NSI) Information submitted by a certificate applicant to an IA, and included within a certificate, which has not been confirmed by the IA and for which the IA provides no assurances other than that the information was submitted by the certificate applicant. Information such as titles, professional degrees, and accreditations are considered NSI unless otherwise indicated. NON-BELSIGN IA An IA that is not owned or operated by BelSign. (See CPS ¤ 3.1; Cf., IA) NORMAL CERTIFICATE (See CERTIFICATE) NOTARY A natural person authorized by an executive governmental agency to perform notarial services such as taking acknowledgments, administering oaths or affirmations, witnessing or attesting signatures, and noting protests of negotiable instruments. NOTICE The result of notification in accordance with this CPS. (See CPS ¤ 12.10) NOTIFY To communicate specific information to another person as required by this CPS and applicable law. O-P ON-LINE Communications that provide a real-time connection to the BelSign PCS. OPERATIONAL CERTIFICATE A certificate which is within its operational period at the present date and time or at a different specified date and time, depending on the context. OPERATIONAL PERIOD The period starting with the date and time a certificate is issued (or on a later date and time certain if stated in the certificate) and ending with the date and time on which the certificate expires or is earlier suspended or revoked. ORGANIZATION An entity with which a user is affiliated. An organization may also be a user. ORIGINATOR A person by whom (or on whose behalf) a data message is purported to have been generated, stored, or communicated. It does not include a person acting as an intermediary. PARTIES The entities whose rights and obligations are intended to be controlled by this CPS. These entities may include certificate applicants, IAs, subscribers, and relying parties. (See USERS; IAS; RELYING PARTY) PASSWORD (PASS PHRASE; PIN NUMBER) Confidential authentication information, usually composed of a string of characters used to provide access to a computer resource. PC CARD (See also SMART CARD) A hardware token compliant with standards promulgated by the Personal Computer Memory Card International Association (PCMCIA) providing expansion capabilities to computers, including the facilitation of information security. PERSON A human being or an organization (or a device under the control of a human being or organization) capable of signing or verifying a message, either legally or as a matter of fact. (A synonym of ENTITY.) PERSONAL PRESENCE The act of appearing (physically rather than virtually or figuratively) before an LRA or its designee and proving one's identity as a prerequisite to certificate issuance under certain circumstances. PKI HIERARCHY A set of IAs whose functions are organized according to the principle of delegation of authority and related to each other as subordinate and superior IA. PLEDGE (See SOFTWARE PUBLISHER'S PLEDGE) PRIVATE KEY A mathematical key (kept secret by the holder) used to create digital signatures and, depending upon the algorithm, to decrypt messages or files encrypted (for confidentiality) with the corresponding public key. (See also PUBLIC KEY CRYPTOGRAPHY; PUBLIC KEY) PUBLIC CERTIFICATION SERVICES (See BELSIGN PUBLIC CERTIFICATION SERVICES) PUBLIC KEY A mathematical key that can be made publicly available and which is used to verify signatures created with its corresponding private key. Depending on the algorithm, public keys are also used to encrypt messages or files which can then be decrypted with the corresponding private key. (See also PUBLIC KEY CRYPTOGRAPHY; PRIVATE KEY) PUBLIC KEY CERTIFICATE (See CERTIFICATE) PUBLIC KEY CRYPTOGRAPHY (Cf., CRYPTOGRAPHY) A type of cryptography that uses a key pair of mathematically related cryptographic keys. The public key can be made available to anyone who wishes to use it and can encrypt information or verify a digital signature; the private key is kept secret by its holder and can decrypt information or generate a digital signature. PUBLIC KEY INFRASTRUCTURE (PKI) The architecture, organization, techniques, practices, and procedures that collectively support the implementation and operation of a certificate-based public key cryptographic system. The PKI consists of systems which collaborate to provide and implement the PCS and possibly other related services. PUBLIC/PRIVATE KEY PAIR (See PUBLIC KEY; PRIVATE KEY; KEY PAIR) PUBLISH / PUBLICATION To record or file information in the BelSign repository and optionally in one or more other repositories in order to disclose and make publicly available such information in a manner that is consistent with this CPS and applicable law. Q-R QUALIFIER (See BELSIGN QUALIFIER) RECIPIENT (of a DIGITAL SIGNATURE) A person who receives a digital signature and who is in a position to rely on it, whether or not such reliance occurs. (Cf., RELYING PARTY) RECORD Information that is inscribed on a tangible medium (a document) or stored in an electronic or other medium and retrievable in perceivable form. The term "record" is a superset of the two terms "document" and "message". (Cf., DOCUMENT; MESSAGE) RE-ENROLLMENT (Cf., RENEWAL) REGISTERED STRING A class of object subject to registration and recording procedures which demonstrates the value is unambiguous within the records of the registration authority. The type of value recorded is a string of characters. REGISTRATION AUTHORITY An entity trusted to register other entities and assign them a relative distinguished value such as a distinguished name or, a hash of a certificate. A registration scheme for each registration domain ensures that each registered value is unambiguous within that domain. (Cf., CERTIFICATION AUTHORITY) RELATIVE DISTINGUISHED NAME (RDN) A set of attributes comprising an entityÕs distinguished name that distinguishes the entity from others of the same type. RELY / RELIANCE (on a CERTIFICATE and DIGITAL SIGNATURE) To accept a digital signature and act in a manner that could be detrimental to oneself were the digital signature to be ineffective. (Cf., RELYING PARTY; RECIPIENT) RELYING PARTY A recipient who acts in reliance on a certificate and digital signature. (Cf., RECIPIENT; RELY OR RELIANCE (on a CERTIFICATE and DIGITAL SIGNATURE)) RENEWAL The process of obtaining a new certificate of the same class and type for the same subject once an existing certificate has expired. REPOSITORY A database of certificates and other relevant information accessible on-line. REPUDIATION (See also NONREPUDIATION) The denial or attempted denial by an entity involved in a communication of having participated in all or part of the communication. REVOKE A CERTIFICATE (See CERTIFICATE REVOCATION) The process of permanently ending the operational period of a certificate from a specified time forward. RSA A public key cryptographic system invented by Rivest, Shamir & Adelman. S SECRET SHARE A portion of a cryptographic secret split among a number of physical tokens. SECRET SHARE HOLDER An authorized holder of a physical token containing a secret share. SECRET SHARE ISSUER The person designated by an IA to create and distribute secret shares. SECRET SHARING (See also SECRET SHARE) The practice of distributing secret shares of a private key to a number of secret share holders; threshold-based splitting of keys. SECURE CHANNEL A cryptographically enhanced communications path that protects messages against perceived security threats. SECURITY The quality or state of being protected from unauthorized access or uncontrolled losses or effects. Absolute security is impossible to achieve in practice and the quality of a given security system is relative. Within a state-model security system, security is a specific "state" to be preserved under various operations. SECURITY POLICY A document which articulates requirements and good practices regarding the protections maintained by a trustworthy system in support of the PCS. SECURITY SERVICES Services provided by a set of security frameworks and performed by means of certain security mechanisms. Such services include, but are not limited to, access control, data confidentiality, and data integrity. SELF-SIGNED PUBLIC KEY A data structure that is constructed the same as a certificate but that is signed by its subject. Unlike a certificate, a self-signed public key cannot be used in a trustworthy manner to authenticate a public key to other parties. A PCA self-signed public key digitally signed by the VR shall constitute a certificate. (Cf., CERTIFICATE) SERIAL NUMBER (See CERTIFICATE SERIAL NUMBER) SERVER A computer system that responds to requests from client systems. SIGN To create a digital signature for a message, or to affix a signature to a document, depending upon the context. SIGNATURE A method that is used or adopted by a document originator to identify himself or herself, which is either accepted by the recipient or its use is customary under the circumstances. (Cf., DIGITAL SIGNATURE) SIGNER A person who creates a digital signature for a message, or a signature for a document. SMART CARD A hardware token that incorporates one or more integrated circuit (IC) chips to implement cryptographic functions and that possesses some inherent resistance to tampering. S/MIME A specification for E-mail security exploiting a cryptographic message syntax in an Internet MIME environment. SOFTWARE PUBLISHER'S PLEDGE The representations and guarantees made by individual and commercial software publishers as stated in the CPS. (See CPS ¤ 4.3) SOFTWARE VALIDATION BelSign services which provide assurances in accordance with the CPS and the software publisher's pledge (see CPS ¤ 4.3) of an individual or commercial software publisher that digitally-signed software was duly published by the subject of the corresponding BelSign-issued certificate and has not been undetectably modified since it was digitally signed. (Cf., INDIVIDUAL SOFTWARE PUBLISHER CERTIFICATE; COMMERCIAL SOFTWARE PUBLISHER CERTIFICATE; SOFTWARE PUBLISHER'S PLEDGE; VALIDATION (OF CERTIFICATE APPLICATION)) SUBJECT (OF A CERTIFICATE) The holder of a private key corresponding to a public key. The term "subject" can refer to both the equipment or device that holds a private key and to the individual person, if any, who controls that equipment or device. A subject is assigned an unambiguous name which is bound to the public key contained in the subjectÕs certificate. SUBJECT NAME The unambiguous value in the subject name field of a certificate which is bound to the public key. SUBSCRIBER A person who is the subject of, has been issued a certificate, and is capable of using, and authorized to use, the private key that corresponds to the public key listed in the certificate. (See also SUBJECT; cf., CERTIFICATE APPLICANT; USER) SUBSCRIBER AGREEMENT The agreement executed between a subscriber and an IA for the provision of designated public certification services in accordance with this CPS. SUBSCRIBER INFORMATION Information supplied to a certification authority as part of a certificate application. (Cf., CERTIFICATE APPLICATION) SUSPEND A CERTIFICATE A temporary "hold" placed on the effectiveness of the operational period of a certificate without permanently revoking the certificate. A certificate suspension is invoked by, e.g., a CRL entry with a reason code. (Cf., REVOKE A CERTIFICATE)?? T THREAT A circumstance or event with the potential to cause harm to a system, including the destruction, unauthorized disclosure, or modification of data and/or denial of service. TIME STAMP A notation that indicates (at least) the correct date and time of an action, and identity of the person or device that sent or received the time stamp. TOKEN A hardware security token containing a userÕs private key(s), public key certificate, and, optionally, a cache of other certificates, including all certificates in the userÕs certification chain. TRANSACTION A computer-based transfer of business information which consists of specific processes to facilitate communication over global networks. TRUST Generally, the assumption that an entity will behave substantially as expected. Trust may apply only for a specific function. The key role of this term in an authentication framework is to describe the relationship between an authenticating entity and an IA. An authenticating entity must be certain that it can trust the IA to create only valid and reliable certificates, and users of those certificates rely upon the authenticating entityÕs determination of trust. TRUSTED PERSON A person who serves in a trusted position and is qualified to serve in it in accordance with this CPS. (Cf., TRUST; TRUSTED POSITION; TRUSTED THIRD PARTY; TRUSTWORTHY SYSTEM) TRUSTED POSITION A role within an IA that includes access to or control over cryptographic operations that may materially affect the issuance, use, suspension, or revocation of certificates, including operations that restrict access to a repository. TRUSTED THIRD PARTY In general, an independent, unbiased third party that contributes to the ultimate security and trustworthiness of computer-based information transfers. A trusted third party does not connote the existence of a trustor-trustee or other fiduciary relationship. (Cf., TRUST) TRUSTWORTHY SYSTEM Computer hardware, software, and procedures that are reasonably secure from intrusion and misuse; provide a reasonable level of availability, reliability, and correct operation; are reasonably suited to performing their intended functions; and enforce the applicable security policy. A trustworthy system is not necessarily a Òtrusted systemÓ as recognized in classified government nomenclature. TYPE (OF CERTIFICATE) The defining properties of a certificate which limit its intended purpose to a class of applications uniquely associated with that type. U-V UNAMBIGUOUS NAME (See DISTINGUISHED NAME) UNIVERSAL RESOURCE LOCATOR (URL) A standardized device for identifying and locating certain records and other resources located on the World Wide Web. USER An authorized entity that uses a certificate as applicant, subscriber, recipient or relying party, but not including the IA issuing the certificate. (Cf., CERTIFICATE APPLICANT; ENTITY; PERSON; SUBSCRIBER) VALID CERTIFICATE A certificate issued by an IA and accepted by the subscriber listed in it. VALIDATE A CERTIFICATE (i.e., of an END-USER SUBSCRIBER CERTIFICATE) The process performed by a recipient or relying party to confirm that an end-user subscriber certificate is valid and was operational at the date and time a pertinent digital signature was created. VALIDATE A CERTIFICATE CHAIN For each certificate in a chain, the process performed by the recipient or relying party to authenticate the public key (in each certificate), confirm that each certificate is valid, was issued within the operational period of the corresponding IA certificate, and that all parties (IAs, end-user subscribers, recipients, and relying parties) have operated in accordance with this CPS as to all certificates in the chain. VALIDATION (OF CERTIFICATE APPLICATION) The process performed by the IA (or its LRA) following submission of a certificate application as a prerequisite to approval of the application and the issuance of a certificate. (Cf., AUTHENTICATION; SOFTWARE VALIDATION) VALIDATION (OF SOFTWARE) (See SOFTWARE VALIDATION) VERIFY (a DIGITAL SIGNATURE) In relation to a given digital signature, message, and public key, to determine accurately that (i) the digital signature was created during the operational period of a valid certificate by the private key corresponding to the public key contained in the certificate and (ii) the associated message has not been altered since the digital signature was created. (Cf., AUTHENTICATION; CONFIRM) BELSIGN NAMING AUTHORITY A BelSign registration authority that establishes and enforces controls over and has decision-making authority regarding the issuance of relative distinguished names for all IAs (but not for end-user subscribers). (Cf., NAMING AUTHORITY). BELSIGN PUBLIC CERTIFICATION SERVICES (PCS) The certification system provided by BelSign and any BelSign-authorized IAs described in this CPS. BELSIGN QUALIFIER A data syntax facilitating the representation of a set of values which restrict the meaning of the BelSign CPS. The qualifier value augments the standard certificate policy extension present in all certificates according to the rules defined by X.509 for that extension type. BELSIGN SECURITY PROCEDURES (BSP) The comprehensive document describing BelSignÕs internal security techniques and procedures. Note: for security reasons, BelSign cannot disclose the BSP for external review or publication. W-Z WORLD WIDE WEB (WWW) A hypertext-based, distributed information system in which users may create, edit, or browse hypertext documents. A graphical document publishing and retrieval medium; a collection of linked documents that reside on the Internet. WRITING Information in a record that is accessible and usable for subsequent reference. X.509 The ITU-T (International Telecommunications Union-T) standard for certificates. X.509 v3 refers to certificates containing or capable of containing extensions. *** COPYRIGHT ©1996 BELSIGN, NV/SA. ALL RIGHTS RESERVED BELSIGN CPS VERSION 1.0 - ii - Published October 10, 1996 COPYRIGHT ©1996 BELSIGN, NV/SA. ALL RIGHTS RESERVED BELSIGN CPS VERSION 1.0 - 1 - Published October 10, 1996