CERTIFICATION PRACTICE STATEMENT

Version 1.0

15 May 2002

1.     INTRODUCTION

1.1       Overview

1.1.1        OISTE SA

1.1.2        Certificate types issued

1.1.3        Definitions

1.1.4        PKI Operational Infrastructure

1.1.4        Scope

1.2       Identification

1.2.1        X500 Object Identifier hierarchy

1.3       Community and Applicability

1.3.1.       OISTE PKI Community

1.3.1.1.        OISTE Root Certification Authority (WRCA)

1.3.1.2     OISTE Policy Approval Authority (WPAA)

1.3.1.3     Platinum Service Provider (PSP)

1.3.1.4     Gold Service Providers (GSP)

1.3.1.5     Silver Service Providers (SSP)

1.3.1.6     Bronze Service Providers (BSP)

1.3.1.7     End Users

1.3.1.8     Relying Parties

1.3.2        Applicability

1.4 Contact Details

2.     GENERAL PROVISIONS

2.1       Obligations

2.1.1        Root CA Obligations

2.1.2        Affiliate Certification Authority Obligations

2.1.3.       Relying Party obligations

2.2       Liability Limits and Disclaimers

2.3       Financial responsibility

2.3.2        No Fiduciary relationships

2.4       Interpretation and Enforcement

2.4.1        Governing Law

2.4.1.1     Applicable contract structure

2.4.2        Severability, survival, merger, notice

2.4.2.1     Severability

2.4.2.2     Survival

2.4.2.3     Merger

2.4.2.4     Notice

2.4.2.5     Headings and Appendices

2.4.3        Dispute resolution procedures

2.4.3.1     Hierarchy of the Certification Practice Statement

2.4.3.2     Process

2.5       Fees

2.5.1        Certificate Management fees

2.5.2        Certificate Validation Fees

2.5.3        Fees for Printed Documents

2.5.4        Refund Policy

2.6       Publication and Librarium

2.6.1        Publication of OISTE information on its Certification Services

2.6.2        Frequency of publication

2.6.3        Access Control

2.7       Compliance Audit

2.7.1        OISTE and Affiliate Certification Authority compliance audits

2.7.2        Topics covered by audit

2.7.3        Communication of results

2.8       Confidentiality

2.8.1        Types of information to be kept confidential

2.8.1.1     Collection and Use of Personal Information

2.8.1.2     Registration  information (Identification Information)

2.8.1.3     Certificate and Certificate Status information (Summary Information)

2.8.1.4     Service provider documentation

2.8.1.5     Audit Information

2.8.2        Types of information not considered confidential

2.8.2.1     Certificate information

2.8.2.2     Service provider documentation

2.8.3        Disclosure of Certificate revocation/suspension information

2.8.3.1     Disclosure of Certificate suspension information

2.8.3.2     Disclosure of Certificate revocation information

2.8.4        Release to law enforcement officials

2.8.5        Release as part of civil evidence or discovery purposes

2.9       Intellectual Property rights

2.9.1        General provision

2.9.1.2     Public and private keys

2.9.1.3     Certificate

2.9.1.4     Distinguished names

2.9.2        Copyright

2.9.2.1     General

3.     IDENTITY VERIFICATION

3.1       General

3.2       Initial Registration of Affiliate CAs

3.2.1        Types of names

3.2.2        Name claim dispute resolution procedure

3.2.3        Recognition, Identification Verification and Role of Trademarks

3.2.4        Method to prove possession of private key

3.2.5        Verification of Applicant’s Identity

3.2.6. Verification of the Identity of Persons Representing the ACA Applicant:

3.3       Routine Rekey

3.4       Rekey after Revocation

3.5       Suspension or Revocation requests

4.     OPERATIONAL REQUIREMENTS

4.1       Certificate Application

4.1.1        Certificate Application Submission

4.1.2        Information and Documentation required in an Application

4.1.3        Certificate Application Evaluation:

4.2       Certificate issuance

4.2.1        Certificate issue process

4.2.2        Operational periods

4.3       Certificate Acceptance

4.4       Certificate Suspension and Revocation

4.4.1        Circumstances for suspension

4.4.2        Who can Request a Suspension or Revocation?

4.4.3        Procedure for suspension request

4.4.4        Limits on suspension period

4.4.5        Circumstances for revocation

4.4.6        Procedure for revocation request

4.4.6.1     Affiliate CA duties

4.4.7        Revocation request grace period

4.4.8        Global Validation Service Update Frequency

4.4.9        Certificate Validity Checking Requirements

4.4.10      On-Line Revocation/Status Checking Availability

4.5       Security Audit procedures

4.5.1        Types of event recorded

4.5.2        Frequency of processing log

4.5.3        Retention period for audit log

4.5.4        Protection of audit log and backup procedures

4.5.6        Audit collection system

4.5.7        Notification to event-causing subject

4.5.8        Vulnerability assessments

4.6       Records Archival

4.6.1        Archival Practices

4.6.2        Procedures to obtain and verify archive information

4.7       Key changeover

4.8       Compromise and Disaster Recovery

4.9       CA Termination

5.     PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS

5.1 Physical Controls for Root CA and Global Validation Service

5.2 Procedural Controls

5.3 Personnel Controls

6.     Technical Security Controls

6.1.      Key Pair Generation and Installation

6.1.1        Key Pair Generation

6.1.2        Private Key delivery to entity

6.1.3        Public key delivery to certificate issuer

6.1.4        CA public key delivery to users

6.1.5        Root CA Public Key Delivery to Users

6.1.6        Key sizes

6.1.7        Public key parameters checking

6.1.8        Parameter quality checking

6.1.9        Hardware/software key generation

6.1.10      Key usage purposes

6.2.      Private Key Protection

6.2.1.       Standards for cryptographic module

6.2.2.       Private key (n out of m) multipersonal control

6.2.3.       Private key escrow

6.2.4.       Private key backup

6.2.5.       Private key archival

6.2.6.       Private key entry into cryptographic module

6.2.7.       Method of activating private key

6.2.8.       Method of deactivating private key

6.2.9.       Method of destroying private key

6.3       Other Aspects of Key Pair Management

6.3.1        Public key archival

6.3.2        Usage periods for the public and private key

6.4       Activation Data

6.4.1        Activation data generation and installation

6.4.2        Activation data protection

6.5       Computer Security Controls

6.5.1        Specific computer security technical requirements

6.6       Life Cycle Technical Controls

6.6.1        System development controls

6.6.2        Security management controls

6.7       Network Security Controls

7.     Certificate and CRL Profiles

7.1       Certificate Profile

7.2       CRL Profile

8.     Specification Administration

8.1       Specification change procedures

8.1.1        Initial publication

8.1.2        Changes

8.1.2.1     Authority to amend

8.1.2.2     Nature of Amendments and Effective Date

8.1.2.3     Consultation Period

8.1.2.4     Consent to Amendments

8.2       Publication and notification policies

8.3       CPS and CP approval procedures

Appendix – Glossary

1. INTRODUCTION

1.1       Overview

This Certification Practice Statement (CPS) has been written to decribe the practices followed with regard to all certificates issued by the OISTE (World Internet Secure Key) Root Certification Authority, including those issued to the Global Validation Service (GVS).

The OISTE Root Certification Authority (WRCA) has been designed and is operated in accordance with the broad strategic direction of international PKI (Public Key Infrastructure) standards and is intended to serve as a common root for Certification Authorities worldwide that comply with OISTE requirements.

The technologies, infrastructure, practices, and procedures implemented by the OISTE Root CA, and required of the Affiliate Certification Authorities (ACAs) that it issues certificates to, have been designed with a high standard of security and trustworthiness in mind.[JAAV1]

This CPS provides factual information that describes the:

·        Practices employed by OISTE in operating the Root CA and Global Validation Service and in providing certification services to Affiliate Certification Authorities.

·        Use of technologies and procedures to support the underlying operational structure.

The practices described in this CPS, together with the technologies, policies and procedures referred to in the documents contained and incorporated into the OISTE Librarium (http://www.OISTE.com/librarium/), illustrate the efforts made to convey trustworthiness by providing high levels of security of the OISTE Root CA certification operations throughout the certificate lifecycle, from certificate application to revocation or expiry.

This CPS undergoes a regular review process, by which the reviewers involved strive to take into consideration developments in international PKI standardisation initiatives, developments in technology and information security, as well as other relevant circumstances. Revisions of this document are identified through a configuration baseline schema and numbering convention.

The structure of this CPS is broadly based on the Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework [RFC2527].

1.1.1    OISTE

The establishment of OISTE as an entity through which trust can be channelled, emanates from the fact that it manages the OISTE’s Global Root Cryptographic Key. OISTE is a foundation under Swiss law, and as such, it does not belong to any individual or company nor does it have shareholders. It is subject to annual audits by the Swiss Federal Government and is therefore bound to pursue the objectives that have been set out for it, which are to:

The OISTE Root CA operations and certification services provision have been designed and are in constant evolution taking into consideration the technological and regulatory realities worldwide. The regulatory environment has been of great concern in recent years due to the fact that in many jurisdictions, regulators have sought to promote the development of electronic commerce by enacting rules intended to provide legal certainty for the use of electronic records and signatures. In doing so, the drafting methods have varied from detailed rules on the technology or technological implementations to be deemed legally valid, to general technology-neutral rules dependent on the fulfilment of specific conditions for the satisfaction of legal requirements. This has resulted in a patchwork of regulatory approaches and acceptable technology standards that create the potential for unnecessary obstacles to the development of electronic commerce and the use of electronic media in general.

In view of this, OISTE is deploying its PKI in a jurisdictionally fragmented manner allowing, to the extent possible, for each certification service provider to adapt to local regulations while maintaining minimum common high-security requirements that must be complied with across the OISTE PKI worldwide. The local certification service providers that form part of the OISTE PKI are, where possible, chosen by taking into consideration their position as trusted entities in the provision of more traditional roles within their respective communities.  In addition to this, OISTE pursues to model its certification practices and policies in accordance with emerging international standards and guidelines and thus leveraging the local and international developments.

This unique framework designed by OISTE allows affiliated international and national certification authorities to use a common Root Certification Authority. It also provides an exceptional trust management mechanism:

·        top-down trust management is provided by its high security standards in the use of the Root Cryptographic Key and in its ownership byOISTE

·        bottom-up trust management is provided by its choice of local entities that are trusted in their traditional roles and are simultaneously capable of providing trustworthy certification services.

This results in a series of links between entities that conform a chain of trust running throughout the OISTE PKI.

1.1.2     Certificate types issued

The Root CA only issues high-security certificates to Affiliate Certification Authorities (ACAs) and to the OISTE Global Validation Service. All other certificates types that may exist within the OISTE PKI are issued by subordinate entities.

1.1.3     Definitions

Definitions used within this document are contained in Appendix A – Glossary.

1.1.4     PKI Operational Infrastructure

The OISTE Root Community is restricted to the OISTE Root CA itself, the Global Validation Service and the Affiliate Certification Authorities to which the OISTE Root CA issues certificates. The OISTE PKI as a whole extends to several other entities which, although not issued certificates directly by the OISTE Root CA, are subordinate to the entities that have been issued such certificates.

1.1.4                 Scope

This CPS covers the practices followed by the OISTE Root CA for the issuance, use, validation, suspension, revocation and expiry of certificates, as well as the operational maintenance of the Root CA.

1.2      Identification

This CPS is referred to as the ‘OISTE Root Certification Authority CPS’. The primary source of the current version of the CPS and other important OISTE documents is http://www.OISTE.com/librarium/.

1.2.1        X500 Object Identifier hierarchy

Object Identifiers (OIDs) are assigned by OISTE and documented in a Configuration baseline. OIDs are not assigned to Certification Authorities or Registration Authorities.

OIDs have been assigned by OISTE to:

·        Certificate policies under which Certificates are issued, by the OISTE Root CA and by Affiliate CAs

·        Private extensions included in any certificates issued by Affiliate CAs

The OISTE corporate OID is:

·        2.16.756.5.14

1.3      Community and Applicability

1.3.1.        OISTE PKI Community

The OISTE PKI community spans several entities which may or may not have been issued a certificate by the OISTE Root CA. In the following sections, each one of the entities which are considered a part of the OISTE PKI Community are briefly described.

1.3.1.1.             OISTE Root Certification Authority (WRCA)

The OISTE Root CA is the highest point of trust within the OISTE PKI hierarchy. The primary functions of the WRCA are to process certificate applications, manage the lifecycle of certificates issued by it and operate and maintain the OISTE PKI Global Validation Service.

The OISTE RCA self-signs its own Global Root Certificate with the World Internet Security – WISeFoundation Root Cryptographic Key that it manages. This Root Private Cryptographic Key is maintained off-line in a high security facility in the Swiss Alps. The OISTE PKI Global Validation Service (GVS) is maintained on-line allowing real-time validations for the entire OISTE PKI. All certificates issued within the OISTE PKI, including Affiliate CA certificates, Affiliate RA certificates, Registration Officers, and End User certificates can be validated through the Global Validation Service.

1.3.1.2              OISTE Policy Approval Authority (OPAA)

The OPAA is managed and organised by OISTE and has been established to approve the practices, policies and procedures under which the entire OISTE PKI operates. Its members are experts and executives working within the OISTE PKI. The controls exercised by the OPAA are exercised by:

·        Instigating the drafting of practices, policies and procedures for new trust entities entering the PKI and for new or modified activities to be performed using the OISTE PKI certificates.

·        Maintaining existing practices, policies and procedures are effectively complied with and updated.

·        Reviewing and approving all practices and policies within the scope of the OISTE PKI as well as all procedures which are relevant to the security of the PKI.

·        Endorsing the operations and processes undertaken in support of the practices, policies and procedures approved by the WPAA.

·        Maintaining all practices, policies, and procedures applicable within the OISTE PKI published and readily available to the appropriate community of interest.

·        Delegating Policy Creation Authority responsibilities as required.

·         Liasing with external Policy Approval Authorities on issues of common concern.

·        Approving naming conventions used by the Root CA and by Affiliate CAs.

·        Ensuring the performance of the periodic audits within the OISTE PKI as well as the “spot-check” audits and any audits required as a result of a security breach or non-compliance with the approved practices, policies and procedures.

·        Investigating and deciding whether certificates issued by the OISTE Root CA should be suspended or revoked.

The OPAA may be contacted at:

1.3.1.3                Platinum Service Provider (PSP)

Platinum Service Providers are high-level Affiliate Certification Authorities that have been issued a certificate by the OISTE Root CA and has as subordinate entities other Affiliate Certification Authorities.

1.3.1.4              Gold Service Providers (GSP)

Gold Service Providers may be issued its certificates either by the OISTE Root CA or a Platinum Service Provider and must comply with the OISTE Root CPS, the CPS of the Platinum Service Provider and/or its own CPS. They perform a wide variety of functions within the OISTE PKI and in doing so, may have a direct relation with Silver Service Providers (SSP), Bronze Service Providers (BSP) and End Users. In their relationship with SSPs and BSPs, Gold Service Provider’s perform Affiliate Certification Authority and Affiliate Registration Authority functions, depending on the nature of the entity in question, as depicted in the graphic in § 1.1.4. Additionally, Gold Service Providers may directly perform Affiliate Certification Authority, Affiliate Registration Authority and Registration Officer functions in their relationships with End Users.

1.3.1.5              Silver Service Providers (SSP)

Silver Service Providers are Affiliate Registration Authorities (ARAs) that have a contractual relationship with the Gold Service Provider that issued its certificates and must comply with the Certification Practice Statement of that Gold Service Provider. Silver Service Providers perform Affiliate Registration Authority functions for Registration Officers and perform ACA, ARA and Registration Officer functions for end users. All Registration Officers and their infrastructure operating under an SSP are required to be the property of such SSP, regardless of whether they operate internally or externally.

As part of their operations, Silver Service Providers are able to:

·        Determine the certificate policies they will support from those available through their Gold service provider;

·        Have the Web-based Registration Officer user interface tailored to their own local needs, e.g. local language support, localised presentation format etc.;

·        If required, negotiate with their Gold Service Provider in order to have their own policies under which they register users for certificates, particular to their own local needs;

·        Have dedicated hardware infrastructure for handling certificate requests generated by their Registration Officers.

Their specific functions and obligations are identified in the applicable CPS and Certificate Policies.

1.3.1.6              Bronze Service Providers (BSP)

Bronze Service Providers are restricted to the performance of the Registration Officer functions for End Users and are issued certificates by a Gold Service Provider, which performs the ACA and the ARA functions required by the BSP. Bronze Service Providers have less scope than Silver Service Providers for localising and tailoring their certification services to specific needs and do not operate the complex infrastructure required for an SSP.

Their specific functions and obligations are identified in the applicable CPS and Certificate Policies.

1.3.1.7              End Users

End Users are issued certificates generated by a Gold Service Provider but the End User’s certificate application may be processed through any of the aforementioned Service Providers (Gold, Silver or Bronze), in accordance with the Certification Practice Statement of the GSP that issues the certificates. End users are required to sign an End User Agreement, which also includes terms and conditions regarding the reliance on certificates issued within the OISTE PKI.

End User rights and obligations are identified in the CPS and Certificate Policies applicable to the certificates issued to it.

1.3.1.8              Relying Parties

Unless explicitly provided for under an applicable Certificate Policy, the OISTE PKI is fundamentally a network of contractually closed communities of certificate subscribers. In such a closed community, Relying parties are therefore required to be either Subordinate PKI entities or End Users of a valid certificate issued within the OISTE PKI.

This closed community may be opened for specific certificate uses based on Certificate Policies approved by the OISTE Policy Approval Authority. In such cases and subject to the content of the applicable Certificate Policy, an entity (regardless of whether they are or not a OISTE PKI End User) receiving a digitally signed message backed by a OISTE PKI certificate and acting in accordance with the applicable Certificate Policy, may rely on such a digital signature and certificate with regard to the specified use.

Reliance on a digital signature and a certificate will only be deemed reasonable and valid if the applicable certificate policies have been complied with and a successful verification of the digital signature and successful validation of the certificates and certificate chain is achieved in accordance with End User Agreements, Relying Party Agreements, applicable Certification Practice Statements and Certificate Policies.

1.3.2        Applicability

This Certification Practice Statement applies to the certification practices followed by OISTE as a Root Certification Authority in the issuance of certificates. Although the Certification Practice Statement of Affiliate Certification Authorities provides a description of the practices followed by each one, this CPS also establishes for specific areas, the standard that is required to be followed by Affiliate Certification Authorities in the provision of certification services within the OISTE PKI.

1.4 Contact Details

This CPS is administered by OISTE. Enquiries or other communications about this document should be addressed to:

OISTE, SA

29, route de Pré-Bois

Case postale 885

CH-1215 Geneva 15

Switzerland

2.1       Obligations

2.1.1        Root CA Obligations

OISTE hereby warrants that in performing its functions as a Root CA and operator of the Global Validation Service it will:

·        Publish this CPS and other relevant and public information in accordance with §2.6 and §8.2.

·        Perform and have performed compliance audits in accordance with §2.7.

·        Handle confidential information, personal data, and information disclosure in accordance with §2.8.

·        Perform its identity verification functions in accordance with §3.

·        Perform the certificate application processes, certificate issuance, and certificate lifecycle management in accordance with §4.1-§4.4

·        Maintain and operate the event logging and audit systems in accordance with §4.5.

·        Maintain and archive records in accordance with §4.6.

·        Operate the Root CA and Global Validation Service in accordance with §4.7, §4.9, §5, and §6.

·        Have in place a disaster recovery plan in accordance with §4.8.

·        Administer this CPS and the CPS and CP of Affiliate CAs in the OISTE PKI in accordance with §8.

OISTE further warrants and represents that the Root Cryptographic Key it uses to operate the Root CA and provide Root certification services has not been compromised and that the information contained in the certificates it issues is not known by OISTE to be false.

OISTE assumes no other warranties or obligations in the purview of its activities as described in this CPS.

2.1.2        Affiliate Certification Authority Obligations

An Affiliate Certification Authority, upon accepting its certificates from the OISTE Root CA warrants that:

·        it acknowledges OISTE as a global Root CA, as well as OISTE’s deployment methodologies and policies, including the objective of establishing, at a global level, a public key infrastructure of high-security certificates;

·        it shall use its best endeavours to achieve such a public key infrastructure within the limited area in which it operates and provides its certification services;

·        it shall not be in violation of any laws in the operation of its ACA and certification services provision;

·        it shall establish, operate and provide its ACA services in accordance with the Root CA-Affiliate CA Agreement, this CPS, its own CPS and Certificate Policies, as well as any applicable law;

·        its private cryptographic keys associated with the public keys contained in the Certificates issued by OISTE have not been compromised;

·        it shall protect its private cryptographic keys in accordance with this CPS and taking into consideration its role as an Affiliate Certification Authority;

·        the information supplied by it during the certificate application process is truthful and that the data published in the certificate pertaining to it is accurate;

·        it shall immediately notify OISTE of any changes to the information material to the certificates issued to it and that it shall maintain all other information maintained by OISTE with regard to it up to date.

·        it shall not interfere with or damage, or attempt to interfere with or damage, any component of the operational infrastructure of the OISTE PKI;

2.1.3.       Relying Party obligations

Relying Parties, in meeting their obligations under this CPS, shall:

·        Enter into a Relying Party Agreement or other similar agreement (e.g. Root CA – Affiliate CA Agreement) and, unless otherwise allowed by an applicable Certificate Policy, enter into an End User Agreement;

·        Securely obtain the OISTE Root CA Certificate and any other certificates within the corresponding certificate chain;

·        Only rely on digital signatures and certificates when such reliance is deemed reasonable. In considering the reasonableness of reliance, the aspects to be considered shall include whether:

·        the digital signature was created during the validity period of the certificate;

·        the digital signature has been verified successfully;

·        all of the public key hashes (thumbprints) on the certificates within the corresponding certificate chain are verified successfully;

·        the certificates  in the certificate chain have not expired;

·        the certificate and certificate chain are successfully validated;

·        there are no additional circumstances that may affect the reliability of the digital signature, certificate or certificate chain.

2.2      Liability Limits and Disclaimers

EXCEPT AS EXPLICITLY STATED IN §2.1.1 AND UNLESS OTHERWISE PROVIDED FOR IN CERTIFICATE POLICIES APPROVED BY THE WPAA, OISTE DISCLAIMS ANY AND ALL WARRANTIES AND OBLIGATIONS OF ANY KIND IMPLIED BY LAW OR OTHERWISE, INCLUDING ANY WARRANTY OR OBLIGATION TO ACHIEVE A SPECIFIC RESULT, ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, ANY WARRANTY WITH REGARD TO THE ACCURACY OR RELIABILITY OF INFORMATION CONTAINED IN CERTIFICATES THAT IS NOT PROVIDED BY AND/OR VERIFIED BY OISTE, ANY AND ALL WARRANTIES MADE ON BEHALF OF OISTE BY A SUBORDINATE PKI ENTITY IN DOCUMENTS OTHER THAN THE CERTIFICATION PRACTICE STATEMENTS AND CERTIFICATE POLICIES APPROVED BY THE WPAA, ANY AND ALL WARRANTIES THAT GUARANTEE THE FULL-PROOF RELIABILITY OF THE OISTE PKI, AND ANY AND ALL WARRANTIES WITH REGARD TO MATTERS OUTSIDE OISTE’S CONTROL.

IN NO EVENT SHALL OISTE BE RESPONSIBLE OR LIABLE FOR ANY LOSS OF PROFIT, BUSINESS, REVENUES, CONTRACTS, ANTICIPATED SAVINGS, REPUTATION, GOODWILL, FOR ANY LOSS OR CORRUPTION OF DATA, OR FOR ANY SPECIAL, CONSEQUENTIAL INCIDENTAL, INDIRECT OR PUNITIVE DAMAGES INCURRED OR SUFFERED ARISING FROM OR IN CONNECTION WITH THE PROVISION OF ROOT CERTIFICATION SERVICES, THE OPERATION OF THE GLOBAL VALIDATION SERVICE, THE USE IN ANY WAY OF THE CERTIFICATES ISSUED BY IT, THE COMMERCIAL VIABILITY OR STABILITY OF ANY SUBORDINATE PKI ENTITIES, AND ANY OTHER ACTIVITY DESCRIBED IN THIS CPS OR DERIVED FROM OR DEPENDENT ON THE ACTIVITIES DESCRIBED IN THIS CPS, REGARDLESS OF WHETHER OISTE HAS BEEN NOTIFIED OF THE POSSIBILITY OF SUCH DAMAGES. OISTE FURTHER DISCLAIMS ANY AND ALL LIABILITY FOR ANY COSTS, CLAIMS, LOSSES, DAMAGES AND EXPENSES CAUSED BY THIRD PARTY PRODUCTS AND SERVICES (INCLUDING HARDWARE, SOFTWARE AND FIRMWARE), OR THAT ARE ATTRIBUTABLE PARTIALLY OR WHOLLY TO A CERTIFICATE ISSUED BY OISTE OR A CERTIFICATION SERVICE PROVIDED BY OISTE THAT HAS BEEN USED BY ANY END USER, RELYING PARTY OR SUBORDINATE PKI ENTITY IN A MANNER THAT IS NOT COMPLIANT WITH THIS CPS OR OTHER RELEVANT AGREEMENTS.

2.3             Financial responsibility

Unless otherwise explicitly agreed or explicitly provided for in a Certificate Policy approved by the WPAA, OISTE’s liability to End users, Relying Parties and any other entities that are not Subordinate PKI Entities, is limited against claims of any kind, including those of contractual, tortious, extracontractual and delictual nature, on a per claim, per transaction, per digital signature, and an aggregate basis.

The maximum per claim, per transaction or per digital signature liability limit of OISTE towards End users, Relying Parties and any other entities that are not Subordinate PKI Entities with regard to a certificate issued by the OISTE Root is US$12,000.00 (Twelve Thousand US dollars).

The maximum aggregate liability of OISTE towards each End User, Relying Party and any other entities that are not Subordinate PKI Entities with regard to a certificate issued by the OISTE Root is US$60,000.00 (Sixty Thousand US dollars).

Subject to the foregoing limitations, OISTE’s aggregate liability limit towards all End users, Relying Parties and any other entities that are not Subordinate PKI Entities for the whole of the validity period of a certificate issued by the OISTE Root (e.g. 10 years unless revoked or suspended) towards all persons with regard to such certificate is US$5,100,000.00 (Five Million One Hundred Thousand US dollars), with a maximum aggregate per year liability on such certificates of US$510,000.00 (Five Hundred and Ten Thousand US dollars).

In no event shall OISTE’s liability exceed the aforementioned limits. The liability limitations with regard to certificates issued or processed by Subordinate PKI entities shall be provided for in the corresponding Certification Practice Statement and Certificate Policies.

OISTE’s liability limits towards Subordinate PKI Entities are regulated through contractual agreements with such entities. This CPS and other relevant documents are incorporated by reference into such contracts.

2.3.2        No Fiduciary relationships

The OISTE Root CA is not an agent, fiduciary, trustee, or other representative of Affiliate CAs, Affiliate Registration Authorities, Bronze Service Providers other parties within the OISTE PKI, End Users or Relying Parties.

Subordinate PKI entities, End Users and Relying Parties are not agents, fiduciaries, trustees or other representatives of OISTE and shall therefore not bind, make any warranty or representation, act for or in representation of OISTE, nor undertake or assume any obligation or responsibility on its behalf.

2.4       Interpretation and Enforcement

2.4.1        Governing Law

This CPS is be governed and construed in accordance with the laws of Switzerland.

2.4.1.1                Applicable contract structure

The contractual structure that underpins the OISTE PKI as a whole include:

·        Root CA-Affiliate CA Agreement: This is the contractual arrangement through which the relation between OISTE and an Affiliate CA is regulated and by which an entity is authorised to operate as an Affiliate CA.

·        Affiliate CA–Affiliate RA Agreement: This is the contractual arrangement through which the relation between such entities is regulated and by which an entity is authorised to operate as an Affiliate RA.

·        Affiliate CA–Registration Officer Agreement: This is the contractual arrangement through which the relation between such entities is regulated and by which an entity is authorised to operate as a Registration Officer (Bronze Service Provider).

·        Affiliate CA-End User agreement: Establishes a contractual relationship between the Affiliate CA and their End Users. This will state the End Users’ obligations when acting as either a certificate subscriber or a relying party.

2.4.2        Severability, survival, merger, notice

2.4.2.1        Severability

In the event that any one or more of the provisions of this CPS shall for any reason be held to be null, invalid, unconstitutional, illegal, or unenforceable at law, such nullity, invalidity, unconstitutionality, illegality or unenforceability shall not affect any other provision, but this CPS shall then be construed as if such provision or provisions had never been contained herein, and insofar as possible, construed to maintain the original intent of the CPS.

2.4.2.2        Survival

This section and the provisions of sections 1.4 (Contact Details), 2.1 (Obligations), 2.2 (Liability Limits and Disclaimers), 2.3(Financial Responsibility), 2.4 (Interpretation and Enforcement), 2.7 (Compliance Audit), 2.8 (Confidentiality), and 2.9 (Intellectual Property Rights) shall survive the termination of this Certification Practice Statement.

2.4.2.3        Merger

The provisions of this CPS may only be amended in accordance with the procedures provided for herein under §8 of this CPS. Its provisions as well as any rights and obligations corresponding to OISTE, End Users, Relying Parties or any other entities, may not be amended, waived or terminated by oral, written or other means not compliant with the corresponding procedures, except as expressly provided for herein.

2.4.2.4        Notice

Unless otherwise explicitly provided for in this CPS, notices must be done either in a digitally signed message that can be verified with a certificate capable of being validated within the OISTE infrastructure or sent by registered mail or similar courier services that provide a receipt indicating delivery. In either case, the notice will be effective from the moment a digitally signed acknowledgement of receipt or the regular mail delivery receipt is received by the person or entity sending the notice. If it is not received within 5 working days after the moment it was purported to have been received by OISTE, the notice should be considered as not having been received by OISTE.

Notices in accordance with the previous paragraph must be delivered to the following postal address:

OISTE, SA
29, route de Pré-Bois

Case postale 885

CH-1215 Geneva 15

Switzerland

2.4.2.5                            Headings and Appendices

The headings in this CPS are included for convenience purposes only and should not be used to interpret, construe or enforce any of the provisions of the CPS.

The Glossary is an integral part of this CPS but in the event that a contradiction arises between the provisions of this CPS and the Glossary, the former will prevail over the latter.

2.4.2.6.                        Assignment

Entities issued certificates by the OISTE Root may not assign or transfer their rights or obligations under this Certification Practice Statement without explicit approval in accordance with this CPS and any related agreements signed with OISTE.

2.4.3        Dispute resolution procedures

2.4.3.1        Hierarchy of the Certification Practice Statement

In the event of a conflict between this CPS and other policies, plans, agreements, contracts or procedures, where the subject of the conflict is between this CPS and:

·        A Root CA-Affiliate CA agreement, this CPS shall prevail;

·        A CP, the CP shall prevail

·        An End User agreement or Relying Party agreement, this CPS shall prevail

·        Any policy, plan, procedures or any other operational or practices documentation whatsoever, this CPS shall prevail, excepting documents executed or authorised by OISTE that expressly change or exclude practices contained within this CPS.

2.4.3.2        Process

If a dispute arises out of or in connection with these practices, the parties to the dispute undertake in good faith to use all reasonable endeavours to settle the dispute by negotiation. The parties further agree that in such an event, they will notify OISTE of the dispute and, if not a party to the dispute, OISTE shall offer to aid in the negotiations as an independent expert party.

If the parties are not able to resolve the dispute through negotiation within ten (10) days from the date the dispute first arose, then the parties agree to enter into binding arbitration in accordance with the Rules of Conciliation and Arbitration of the International Chamber of Commerce to jointly appoint an independent arbitrator, having appropriate qualifications and practical experience (“Arbitrator”), for the purpose of resolving the dispute and agree to be bound by the decision of that arbitrator. The Arbitral Tribunal shall be conducted in English and have its seat in Geneva, Switzerland. The parties will promptly furnish to the Arbitrator (imposing appropriate obligations of confidence) all information reasonably requested by the Arbitrator relating to the dispute.

The Arbitrator shall apply the laws of the Canton of Geneva, Switzerland and will use all reasonable endeavours to render the Arbitrator’s decision within 30 days following receipt of the information requested or if this is not possible, as soon as practical thereafter, and the parties must co-operate fully with the Arbitrator to achieve this objective.

Regardless of the measures taken by the parties to resolve the dispute in accordance with this CPS, OISTE shall retain its right to seek injunctive relief in the event of alleged or effective material breach of this CPS or any other circumstance related to the dispute which may affect partially or wholly the security of the OISTE PKI.

2.5       Fees

2.5.1        Certificate Management fees

Fees may be payable for the certificate application process and for the issuance, suspension, revocation or renewal of Certificates. Where fees are payable, OISTE will provide up to date fee schedules to the Certification Authorities, based on the particular business arrangements reached with them in the Root CA-Affiliate CA Agreement.

2.5.2        Certificate Validation Fees

Fees may be payable for access to the OISTE Global Validation Service and are stated in relevant contractual agreements, the OISTE Web site or through the Global Validation Service.

2.5.3        Fees for Printed Documents

No fee is to be levied for access to this CPS or other publicly available documents via the OISTE Web site or other authorised Web sites in accordance with the non-exclusive non-commercial license granted in the front page of this CPS. A fee may be charged by OISTE for printed copies of this CPS, other publicly available documents or for uses beyond those granted in the aforementioned license. Authorisation for uses beyond the license granted may be requested from OISTE at the address provided below. Printed copies of this CPS are available from OISTE for a fee of US$10.00 plus postage and handling by requesting them at the following address:

OISTE SA

28, route de Pré-Bois

case postale 885

CH-1215 Geneva 15

Switzerland

2.5.4     Refund Policy

OISTE or an Affiliate Certification Authority may establish a refund policy. Where a refund policy applies, an up to date version shall be provided to all End Users and may be published on a nominated Web site.

2.6      Publication and Librarium

In order to ensure the full availability of this CPS and other essential public documents, OISTE shall maintain the “Librarium” within its Web site. Additionally, the Global Validation Service operated by OISTE shall be maintained online 24 hours a day, 365 days a year (in accordance with §4.4.10) to allow validation of certificates from any level of the OISTE PKI.

2.6.1        Publication of OISTE information on its Certification Services

The publication of OISTE information relevant to its Root certification services is done through its Web site. Unauthorised publications or media are not recognised by OISTE as its own and are therefore not binding upon it.

This document and others describing OISTE’s Root certification services are on the OISTE Web site at http://www.OISTE.com/librarium/.

As provided for in §4.4.8 – §4.4.10, the validation of the OISTE Root certificate, the certificates issued by the OISTE Root CA and the certificates issued and managed by subordinate PKI entities can be done through the Global Validation Service.

2.6.2        Frequency of publication

Newly approved versions of this CPS, Affiliate Certification Authority Certification Practice Statements, Certificate Policies, and any other relevant documents are published in accordance with the amendment and notification procedures in § 8 and any other relevant provisions in the corresponding documents.

Certificate status information shall be updated promptly in accordance with §4.4.8.

2.6.3          Access Control

Access to the OISTE Root CPS, public Certificate Policies and other similar documents, shall be free to any person wishing to do so.

Access to the Global Validation Service will be restricted to those who have signed a relying party agreement within the OISTE PKI or by way of an explicit authorisation in accordance with an approved Certificate Policy or other mechanism approved by OISTE. Access to the Global Validation Service under different circumstances is not authorised by OISTE and reliance on the operations, services or certificates shall not be deemed nor be reasonable.

2.7       Compliance Audit

2.7.1        OISTE and Affiliate Certification Authority compliance audits

OISTE operations and service provision will be audited upon commencement of operations and annually thereafter by a third party with specialist knowledge in the auditing of Certification services and Public Key Infrastructures. The World Internet Security – WISeFoundation may also, directly or indirectly, perform at any moment and with the frequency it considers appropriate, a comprehensive or partial audit to determine whether the OISTE Root Cryptographic Key management is compliant with the World Internet Security – WISeFoundation guidelines (if any) for the management of its Root Cryptographic Key. At both levels, the auditor and audited party shall not have any current or planned financial, legal, or other relationship that could result in a conflict of interest, aside from the audit itself.

OISTE will directly or indirectly perform comprehensive initial audits of operation of the Affiliate CAs, Affiliate RAs, and other OISTE PKI subordinate entities with regard to which it deems audits are required. Such audits are performed to determine their compliance with the OISTE Root CA CPS, Affiliate CA CPS, as well as any other practices or policy documents applicable to the OISTE PKI. Annual audits will also be performed on the entities OISTE deems necessary or as provided for in the corresponding practices or policy documents, in order to determine their ongoing compliance with such practices and policy documents.

Where non-compliance is found, the necessary corrections will be made to restore compliance. Where substantial non-compliance is found, the measures may involve the suspension or revocation of the certificate and, as a result, the loss of the right to operate within the OISTE PKI or the imposition of restrictions on their operations, depending on the circumstances of each case. Where such non-compliance is substantial and is detected during the certification renewal process, the certificate will be refused until compliance can be met.

2.7.2        Topics covered by audit

The topics covered by a compliance audit will include:

·        Physical Security

·        Technology Evaluation

·        CA and RA Services Administration

·        Personnel Vetting

·        Relevant CP and CPS

·        Contracts

·        Data Protection and Privacy Considerations

·        Disaster Recovery Planning Documents

2.7.3        Communication of results

Audit results are considered to be sensitive commercial information. Unless otherwise stipulated by contract, they will be protected as confidential information in accordance with § 2.8 of this CPS.

Copies of the OISTE audit logs and reports will be made available to the independent auditors for the purposes of the audit itself. The Affiliate CA audit logs and reports will be made available to OISTE and to independent auditors, as the case may be.

2.8             Confidentiality

2.8.1          Types of information to be kept confidential

2.8.1.1        Collection and Use of Personal Information

All personal information collected or used by the OISTE Root CA is done in compliance with Swiss Data Protection legislation and based on the distinction provided in this CPS (see glossary) between “summary information” and “identification information”. Personal information collected and used by subordinate PKI entities shall also be required to comply with the applicable data protection legislation.

2.8.1.2        Registration  information (Identification Information)

Identification information shall be treated as confidential information unless consent is explicitly given otherwise by the entity to which the information refers.

2.8.1.3        Certificate and Certificate Status information (Summary Information)

Summary information shall be disclosed for any purposes that may be relevant for the use of such information and certificate status in accordance with the consent given by the certificate subscriber through the subscriber agreement or other agreements. Unless explicitly provided for in a Certificate Policy or Certification Practice Statement, upon acceptance of certificates, the subscribers shall authorise OISTE and the subordinate PKI entities to publish the summary information.

2.8.1.4        Service provider documentation

OISTE maintains a number of sensitive internal documents that detail the operation and configuration of the Root CA and the Global Validation Service. These documents are treated as confidential and are not released outside of OISTE, with the exceptions required for auditing purposes.

2.8.1.5    Audit Information

All audit information received by OISTE concerning the Root CA, the Global Validation Service or any other subordinate PKI entity shall be treated as confidential information, with the exception of limited summaries of such audits which may be published by OISTE, in its sole and absolute discretion or as required by applicable law.

When required by law and the appropriate procedures, warrants or other legal requirements have been obtained or met, the full audit data may be released by OISTE in accordance with §2.8.4 and §2.8.5.

2.8.2        Types of information not considered confidential

2.8.2.1        Certificate information

All certificates issued by the Root CA for public use shall be publicly available. The certificates issued by subordinate PKI entities shall be treated in accordance with the applicable CPS and Certificate Policies. In all cases, the certificate status information of all certificates issued within the OISTE PKI shall be made available to anybody who accesses the Global Validation Service in accordance with this CPS, subordinate PKI CPS, Certificate Policies and any relevant agreements (e.g. relying party agreement).

2.8.2.2        Service provider documentation

The following OISTE PKI documents are publicly available and are not considered to be confidential information:

1.      Approved Public Certificate Policies

2.      this CPS

3.      Privacy Policy

2.8.3     Disclosure of Certificate revocation/suspension information

The reason for the suspension or revocation of the Certificate of a Subordinate PKI entity shall be made public, in accordance with applicable law or in the sole and absolute discretion of OISTE or the subordinate PKI entity that issued the certificate which was suspended or revoked.

2.8.3.1        Disclosure of Certificate suspension information

The Global Validation Service uses OCSP technology and does not disclose the reason for the suspension status.

2.8.3.2        Disclosure of Certificate revocation information

Information about certificate revocation or validity is disclosed using the OCSP protocol. The Global Validation Service discloses whether a requested certificate is valid, revoked or whether the GVS is unaware of the certificate’s status. No further information is disclosed.

2.8.4        Release to law enforcement officials

No document or record retained by OISTE is released to law enforcement agencies or officials except where:

·        A properly constituted warrant or request is produced,

·        the law enforcement official is properly identified, and

·        other applicable legal procedures are complied with.

The documents retained by PKI subordinate entities shall be treated similarly, but in accordance with the corresponding CPS and applicable law.

2.8.5        Release as part of civil evidence or discovery purposes

As a general principal, no document or record belonging to OISTE is released to any person except where:

·        A properly constituted request (i.e. that has complied with all legal procedures) for the production of the information is produced; and

·        The person requiring production is a person authorised to do so and is properly identified.

PKI subordinate entities will be required to release information for civil evidence or discovery purposes from any part of the OISTE PKI in any jurisdiction where the appropriate legal procedures have been followed. An internal efficient procedure may be established across the OISTE PKI for these purposes, subject to compliance with applicable law.

2.9       Intellectual Property rights

2.9.1     General provision

All Intellectual Property Rights including copyright in all certificates issued and, unless otherwise explicitly provided for, all practices, policy and security documents drafted by OISTE (electronic or otherwise), belong to and will remain the property of OISTE.

2.9.1.2        Public and private keys

All Intellectual Property Rights in the public and private keys generated shall vest in the subscriber or the entity designated by the subscriber of the certificates issued by OISTE. Subscribers shall not obtain any rights whatsoever in relation to the certificates, their format or structure.

2.9.1.3        Certificate

OISTE reserves the right at any time to cancel or suspend any certificate in accordance with the procedures and policies set out in this Certification Practice Statement.

2.9.1.4        Distinguished names

Intellectual property rights in distinguished names vest with the OISTE Root CA unless otherwise specified in a CP, contract or other agreement.

2.9.2        Copyright

2.9.2.1        General

The intellectual property in this CPS is the exclusive property of OISTE.

3. IDENTITY VERIFICATION

3.1             General

Subject to proving their identity and capacity to provide Affiliate Certification Authority services in accordance with the OISTE Root CPS, legal persons may become and operate an Affiliate Certification Authorities within OISTE’s chain of trust.

To ensure the integrity and trustworthiness of operations throughout the PKI hierarchy, Affiliate Certification Authorities, during registration must undertake to comply with the practices in this CPS and the CPS adopted by them.

This section states requirements for the verification of the identity of Affiliate Certification Authorities applicants. The requirements for PKI entities subordinated to an Affiliate CA are stated in the corresponding Affiliate CA Certification Practice Statement.

3.2             Initial Registration of Affiliate CAs

3.2.1        Types of names

All Certificate holders require a distinguished name that is in compliance with the X.500 standard for Distinguished Names.

The OISTE PAA approves naming conventions for the creation of distinguished names. As a minimum, it is checked that a proposed distinguished name has not already been used in a certificate issued by the OISTE Root CA to another entity.

3.2.2        Name claim dispute resolution procedure

Any dispute regarding a distinguished name, trade name, trademark, company name, service mark or other intellectual property right to be incorporated into certificates shall be resolved in accordance with § 2.4.3.2.

OISTE shall not be obliged to issue certificates using any of the aforementioned names, or intellectual property rights in certificates, regardless of the outcome of the dispute resolution process.

3.2.3     Recognition, Identification Verification and Role of Trademarks

Affiliate Certification Authorities warrant and represent that:

·        the trademarks, trade names, company names, service marks and other intellectual property rights incorporated into the ACA certificates issued to it, do not infringe the rights of third parties, including through the use of domain names and distinguished names;

·        the information provided by it and incorporated into the ACA certificates issued to it is not used at the moment such information is provided or in the future, for unlawful purposes or to promote unlawful activities. Such information includes, but is not limited to, information which is defamatory, libellous, illegally discriminatory, or pornographic.

Affiliate Certification Authorities undertake to have the subscribers of certificates issued by them and or processed by its subordinate PKI entities, to provide these same warranties and representations with regard to the certificates issued, as well as indemnify OISTE for damages of any kind arising from the breach of such warranties and representations. OISTE, its Affiliate Certification Authorities or any of their subordinate PKI entities do not undertake to verify or declare the rights of any entity over specific intellectual property rights incorporated into certificates and shall therefore rely solely on the warranties and representations provided by certificate subscribers. Disputes shall be dealt with in accordance with § 2.4.3.2 of this CPS.

3.2.4     Method to prove possession of private key

An applicant will generate a self-signed PKCS#10 certificate request to be securely transported to the OISTE Root CA. Verification of the signature on the PKCS#10 request will constitute sufficient proof of possession of the corresponding private key.

3.2.5        Verification of Applicant’s Identity

An applicant’s identity and capacity to provide ACA services within the OISTE PKI is determined from the moment of initial contacts and thereafter during the process of negotiating and establishing an Affiliate Certification Authority. Such process includes:

·        high-level management contacts between OISTE and the applicant;

·        a visit by OISTE staff to the premises of the applicant in accordance;

·        review of the originals or certified copies of the following documents, where applicable:

·        the certificate of incorporation of the legal entity or other similarly reliable document;

·        the memorandum and articles of association of the legal entity; and

·        the number of registration (in the trade registry or other similar register) of the legal entity.

·        if a governmental or public entity, an official letter by the superior governmental entity under which the applicant operates indicating its support and the authority of the applicant to provide ACA services.

·        Verification of the following facts:

·        the full legal name and postal address of the entity, and

·        the identity and authority of the natural person(s) with the mandate to represent the applicant, in accordance with the § 3.2.6 of this CPS.

All documents required under this section that have been issued by a public entity (e.g. articles of incorporation) shall be officially translated to English and duly legalised in Switzerland.

3.2.6. Verification of the Identity of Persons Representing the ACA Applicant:

The legal representatives of the legal entities applying to become an Affiliate Certification Authority are subject to a face-to-face identification procedure in accordance with the following general rules:

·        Provision of sufficient proof of the person’s authority within the legal entity that is applying to become an Affiliate Certification Authority (e.g. share-holders meeting resolutions, board-meeting minutes, or official letter or publication by a public entity);

·        Provision of at least two pieces of identity in original form or as certified copies (which may vary from jurisdiction to jurisdiction) such as anofficial document or any document from a reputable source, which bears a photograph and a signature. This verification shall also include, where available, cross-referencing such documents with the personal identification number, social security or similar numbers as issued by a reputable source, where available.

·        Among the documents which are not acceptable in this identification process are birth certificates, credit cards, traveling cards for buses and trains, membership cards of unions, or school certificates.

·        The identification procedure may involve:

·        verification of the signature;

·        examination of a possible anomaly in the photograph;

·        verification that the documents presented do not show any sign of alteration.

3.3       Routine Rekey

Affiliate Certification Authorities may request certificate renewal provided that:

·        the request is made prior to the expiry of their current certificates;

·        the material certificate information as contained in registration records has not changed;

·        their current certificates have not been revoked;

·        they are not listed as a compromised Affiliate Certification Authority.

If any of these conditions are not met, the Affiliate CA must apply for a new certificate, and follow the initial application procedures delineated in this CPS.

3.4       Rekey after Revocation

Rekey is not permitted after certificate revocation. Entities that have had their certificates revoked lose their status as Affiliate Certification Authorities within the OISTE PKI, except with regard to their ongoing obligations in accordance with this CPS and any contractual agreements with OISTE. They shall therefore be required to initiate the full ACA application procedure in order to regain their status as Affiliate Certification Authorities.

3.5       Suspension or Revocation requests

Entities requesting the suspension or revocation of Certificates shall be subject to the procedures set in § 4.4 of this CPS.

4.     OPERATIONAL REQUIREMENTS

4.1             Certificate Application

The certificate application procedure for certificates issued by the OISTE Root is an integral part of the setting up of an Affiliate Certification Authority. As such, the actual certificate application is a part of the procedure and will only be initiated once the applicant considers it has met or is in a position to meet all technical, financial, infrastructural, know-how, legal and regulatory requirements.

4.1.1     Certificate Application Submission

Certificate applications include a fully documented file proving compliance with the requirements to become a OISTE ACA, including a full set of documents concerning the identity of the legal entity and the natural persons authorised to represent it. Natural persons may not act as Affiliate Certification Authorities.

4.1.2     Information and Documentation required in an Application

Applications must be in original paper form, the documents issued by public entities and as requested by OISTE, must be officially translated to English and duly legalised in Switzerland by the appropriate authorities.

The application requesting to become an Affiliate CA, must contain the following:

·        the documentation required under § 3.2 of this CPS;

·        insurance documentation and a full description of the risk management strategies to be used;

·        a business plan with proof of sufficient financial resources or means of obtaining such resources to sustain the ACA services in accordance with the business plan projections;

·        the registered business names, trade marks, company names and service marks as well as any other intellectual property rights to be used by the applicant in the operation of the proposed Affiliate CA service in compliance with § 3.2 of this CPS;

·        the proposed name, domain name and IP address under which the Affiliate CA will be operating, in accordance with § 3.2 of this CPS;

·        Full contact details as follows:

·        Postal mailing address

·        Address from which ACA services will be provided and other addresses from which specified activities may be performed, where applicable.

·        Telephone and facsimile number(s)

·        Email address

·        Authorised representatives and their contact details

·        Designated operational/administrative contacts and their contact details

·        the following documents that describe in detail the planned operations in compliance with the OISTE Root CPS, adopted Certificate Policies and the minimum standards established by OISTE:

·        Affiliate CA Certification Practice Statement

·        PCA (Policy Creation Authority) Constitution;

·        Certificate policies under which certificates will be issued (other than standard OISTE CPS;

·        General Description of Physical Infrastructure

·        Affiliate CA Privacy Policy

·        Affiliate CA Configuration Parameters

·        Affiliate CA Operating Procedures

·        Affiliate CA Creation Ceremony

·        Affiliate CA Disaster Recovery Plan

·        Personnel Training Policy

·        Subscriber and Relying Party Agreements

·        Affiliate Registration Authority legal agreements (where applicable)

·        Bronze Service Provider legal agreements (where applicable)

In some jurisdictions, attainment of a license, accreditation or recognition may be required. In such cases, the license, accreditation or recognition must be proven to have been obtained or that it is in the process of being obtained. In all cases, Applicants warrant and represent that they are in compliance with local law and regulations, that they do not have any conflicting interests with the provision of ACA services and, in the case of public entities, that they have legal authority to provide ACA services.

4.1.3     Certificate Application Evaluation:

After the initial application is complete, the process for evaluation of applications to become Affiliate CAs comprises the following:

·        Review of the full certificate application by OISTE staff in order to determine its compliance with OISTE PKI requirements and parameters.

·        Visit of a OISTE representative in order to verify their technical, financial, infrastructural, and know-how capacity to provide ACA services within the OISTE PKI.

·        Performance of a full Certification Authority audit at the applicant’s premises by a specialised entity designated by OISTE in accordance with § 2.7 of this CPS, to determine its capacity to provide Affiliate Certification Authority services in compliance with the OISTE PKI and with its own CPS and operational documentation.

Any non-compliance detected during the certificate application evaluation shall be notified to the applicant and its rectification shall be required in the shortest time possible. If non-compliance is substantial, a new certificate application evaluation may be required.

4.2      Certificate issuance

Upon a successful certificate application evaluation or the correction of any non-compliance detected in accordance with § 4.1.3, the OISTE Root CA will commence the certificate issuance process.

The OISTE Root CA uses reasonable endeavours in ensuring that certificate information verified by it does not contain any factual misrepresentations and ensures that no data entry errors are made in the certificate itself with regard to such information. Where information is received that verified and relevant Certificate content is inaccurate, the Certificate may be subject to the suspension and revocation procedures in § 4.4.

4.2.1        Certificate issue process

Certificate issuance to a Affiliate CA involves:

1.      The Affiliate CA conducts its CA Creation Ceremony, which will have gained prior approval by OISTE, and shall be witnessed by OISTE and auditors designated by OISTE.

2.      The applicant will generate its key pairs in an approved hardware security module in accordance with § 6 of this CPS and will generate a PKCS#10 certificate request.

3.      The certificate request will be securely transported to the OISTE Root CA on computer readable media, where OISTE operating staff will verify the request and then generate the Affiliate CA certificate.

4.      The Affiliate CA certificate will then be taken from the Root CA on computer readable media to be disseminated as required.

5.      The certificate will include reference information to the OISTE Validation Authority, which should be used to confirm the validity of the certificate each time it is relied upon subsequently.

6.      All valid certificates issued to Affiliate Certification Authorities shall be published on the OISTE Web site.

4.2.2     Operational periods

All Certificates begin their operational period on the date of issue. The operational period of an Affiliate CA certificates will be determined at the date of issuance and in no shall it exceed the expiration date of the Root CA certificate.

4.3      Certificate Acceptance

Certificate acceptance shall take place as part of the ACA Creation Ceremony and will occur at the moment the applicant, OISTE and the auditor approve compliance of the ceremony with the documented ACA creation rules. Upon acceptance of its Certificates, the applicant becomes an Affiliate Certification Authority.

4.4             Certificate Suspension and Revocation

Certification suspension of certificates issued by OISTE always precedes revocation but revocation shall follow only under the specific procedures described in this section. All suspension and revocation requests are required to be valid. Such validity shall be determined by their compliance or non-compliance with the procedures of this CPS, which include references to the authority of the person who may make a request and the procedures followed by that person.

4.4.1        Circumstances for suspension

The suspension of certificates issued by the OISTE Root may occur immediately or after an investigation has taken place.

Suspension of such certificates may occur immediately when a valid certificate suspension or revocation request has been received by OISTE in accordance with § 4.4.2 of this CPS. Immediate suspension will take place within a period of 48 hours from the reception of the valid suspension or revocation request.

The OISTE PAA will have an ongoing function of investigating any circumstances that may constitute sufficient grounds to suspend or revoke certificates issued by the OISTE Root. Such investigations will be initiated upon the OISTE PAA receiving information which indicates or raises suspicion that:

·        the private key corresponding to the public key in the certificate has been lost, disclosed without authorisation, stolen or compromised in any way.

·        the security, trustworthiness or integrity of the OISTE PKI (or the PKI of any subordinate entity) is materially affected due to the certificate subscriber’s activities.

·        the certificate subscriber does not meet material obligations of their agreements with the OISTE, those of any applicable CPS, or this CPS;

·        there is an improper or faulty issue of a certificate due to:

·        A material prerequisite to the issue of the Certificate not being satisfied;

·        A material fact in the Certificate is known or reasonably believed to be false.

·        the certificate subscriber is bankrupt, being wound-up or is making arrangements or compositions with its creditors;

·        the certificate subscriber ceases to its operations as an Affiliate Certification Authority;

·        the certificate subscriber does not possess sufficient financial resources to maintain its provision of certification services.

·        any other material circumstance that requires investigation to ensure the security, integrity or trustworthiness of the OISTE PKI or the PKI of any subordinate entity.

The result of the investigation will be either the issuance of a suspension request by the WPAA or a decision not to proceed with the suspension.

4.4.2        Who can Request a Suspension or Revocation?

Suspension or revocation may be requested by the following entities outside of OISTE:

·        A representative of the certificate subscriber explicitly given authority to perform suspension or revocation requests and presentation of proof of such authority in accordance with rules established by OISTE.

·        Swiss court decision by which a decision of a foreign court or public authority requesting the suspension or revocation of the certificate issued by OISTE is declared executable (executoire) in Switzerland.

A valid suspension or revocation request received from any of the aforementioned entities shall result in immediate suspension and the initiation of a post-suspension investigation on whether revocation should follow or the suspension should be lifted.

Suspension or revocation of certificates may also be requested by the OISTE PAA. A suspension request from the OISTE PAA will result in the immediate suspension of the certificate and the initiation of a post-suspension investigation. A revocation request by the OISTE PAA will result in immediate revocation in accordance with §4.4.5 of this CPS.

4.4.3        Procedure for suspension request

This section describes the practices followed when a suspension or revocation is requested by any entity external to OISTE.

The suspension or revocation request may be done by the entities referred to in §4.4.2 through the:

·        Submission of a digitally signed suspension or revocation request verifiable with the public key contained in the certificate to which the request refers to and performance of an off-line request in accordance with procedures designed by OISTE for such purpose and disclosed to each ACA on a confidential basis.

·        Submission of a request notarised at a Swiss notary in Switzerland or a Swiss consulate in another jurisdiction (which should be delivered by hand or secure courier to the OISTE PAA) as well as the execution of the procedures designed by OISTE for such purpose and disclosed to each ACA on a confidential basis.

·        Hand delivery of a certificate suspension or revocation request to OISTE by an appropriately authorised person and the execution of the procedures designed by OISTE for such purpose and disclosed to each ACA on a confidential basis.

·        Presentation of an original or certified copy of an executable decision by a Swiss court in accordance with § 4.4.2 of this CPS.

In processing a suspension request of a certificate, the Root CA shall act based on direct request from the WPAA in accordance with procedures described herein:

·        Immediate suspension will take place upon reception of a valid suspension or revocation request from an entity external to OISTE or a suspension request from the OISTE WPAA in accordance with § 4.4.2.

·        In all other cases referred to in § 4.4.1 an investigation into the need for suspension will take place (in accordance with WPAA operational procedures) by which the following is sought:

·         Thoroughly validate the need for suspension and gain authorisation for the suspension from the WPAA.

·        Upon results of suspension investigation, proceed to suspension or to reinstatement of certificate status as valid.

·        Upon suspension of a certificate the Root CA:

·        shall record the reason for the suspension;

·        will immediate generate a CRL (Certificate Revocation List) from the Root CA and export it to the OISTE Global Validation Service;

·        will confirm that the GVS’s OCSP responder reports the revoked certificate as suspended;

·        will issue a notice containing the Certificate details and the date and time of suspension to the subscriber. Such notice shall not to include the reason for suspension.

4.4.4        Limits on suspension period

Certificates shall only remain suspended for a maximum period of twenty (20) days. Upon termination or prior to termination, OISTE shall determine whether it should be revoked or reinstated as valid. The limits on the suspension period may vary depending on the law of the jurisdiction in which the Affiliate Certification Authority is domiciled.

4.4.5        Circumstances for revocation

A certificate issued by the OISTE Root CA shall be revoked in all cases through a certificate revocation request issued by the WPAA and only in the following cases:

·        when, after going through suspension procedures in accordance with § 4.4.3, it is determined that revocation is required due to material circumstances being ascertained in the post-suspension investigation that merit certificate revocation; and

·        when the WPAA requests the revocation of a certificate, regardless of whether the post-suspension investigation has taken place.

4.4.6        Procedure for revocation request

In processing a revocation request, the Root CA will:

·        Revoke the certificate on the Root CA, record the reason for the revocation, and maintain relevant documentation.

·        Generate immediately a CRL (Certificate Revocation List) from the Root CA and export it to the Global Validation Service.

·        Withdraw the certificate from the OISTE Web site (if published).

·        Confirm that the GVS OCSP responder reports the revoked certificate to be known invalid.

·        Issue a notice containing the Certificate details and the date and time of revocation to the certificate subscriber.

·        Notify the Affiliate CA that it is required to follow the necessary rules and procedures applicable to it under its own CPS, its contracts with its PKI subordinate entities, and any applicable law and licensing/accreditation scheme with regard to the revocation of its certificate.

4.4.6.1        Affiliate CA duties

The Affiliate CA of a revoked Certificate is to:

·        Continue to safeguard the private key associated with the revoked Certificate, until the date of Certificate expiry, at which time it should be securely destroyed or

·        Securely destroy the private key associated with the revoked Certificate in accordance with a procedure approved by the WPAA.

4.4.7        Revocation request grace period

Revocation requests shall be processed within 48 hours of having a definitive decision by the WPAA to revoke the certificate in accordance with the WPAA operational procedures.

4.4.8        Global Validation Service Update Frequency

The OISTE Global Validation Service will be issued with an updated CRL (Certificate Revocation List) after every suspension or revocation event. The interval between a suspension/revocation event and consequent update of the Global Validation Service will not exceed 48 hours.

4.4.9        Certificate Validity Checking Requirements

All parties relying on the certificates issued by the OISTE Root CA or any certificates issued based on and subordinated to such certificates (i.e. OISTE PKI certificates) are required to check the validity status of the certificates in the certificate chain leading up to the OISTE Root certificate, each time a OISTE PKI certificate is relied on.

4.4.10       On-Line Revocation/Status Checking Availability

OISTE shall use reasonable endeavours to maintain the Global Validation Service available 24 hours a day and 365 days a year.

4.5      Security Audit procedures

OISTE undertakes comprehensive audits of internal operations and submits to periodic third party audits. Audit procedures are documented in internal procedures, including information from audit documents.

Additionally, subordinate entities within the OISTE PKI are required to maintain secure audit procedures approved by the WPAA and which are documented in the corresponding Certification Practice Statements.

4.5.1        Types of event recorded

The minimum audit records to be kept include all:

1.      Certificate application records, including records relating to rejected applications;

2.      Certificate generation requests, whether or not Certificate generation was successful;

3.      Certificate issuance, suspension and revocation records, including CRLs;

4.      Audit records, including security related events;

5.      Access records to the OISTE secure off-line facilities or the secure facilities of the Affiliate Certification Authority.

4.5.2        Frequency of processing log

Audit logs are processed on a daily, weekly, monthly and annual basis, depending on the type of records and the frequency with which certain activities take place.

4.5.3        Retention period for audit log

Audit logs are retained for a minimum of 12 years.

4.5.4        Protection of audit log and backup procedures

OISTE uses highly secure encryption systems to maintain the integrity of its electronic audit logs over time and has established a series of security procedures regarding their encryption, access and backup.

4.5.6        Audit collection system

The OISTE audit collection system is a combination of automated and manual processes performed by the OISTE Root CA or RA operating system, the OISTE Root CA or RA application, and by operational personnel. The system is therefore maintained through access control mechanisms and role separations with regard to the software and hardware that handles the automated collections and through confidential documented operational procedures to be known and followed by OISTE personnel with regard to manual collection. The control measures of both the automated and the manual processes are audited in accordance with § 2.7 of this CPS.

4.5.7        Notification to event-causing subject

Operations personnel notify their security administrator when a process or action causes a critical security event or discrepancy. Subordinate PKI entities are also required to notify any event that may cause a critical security event or discrepancy.

4.5.8        Vulnerability assessments

A full risk assessment has been completed for the OISTE Root CA operations and will be performed at a minimum annually. Vulnerability assessments for subordinate PKI entities will be defined in the corresponding subordinate CPS in accordance with WPAA approved levels.

4.6      Records Archival

4.6.1     Archival Practices

All OISTE Root CA records concerning the operation of its certification services are archived and are retained for a minimum period of twenty (20) years. The time source for the OISTE Root CA is independently verified periodically and all electronic automated Root CA records are associated with the time and date of their occurrence. Archives of records are maintained under closed access control and are subject to inspection by independent auditors.

4.6.2        Procedures to obtain and verify archive information

The integrity of the electronic automated Root CA archives are verified:

·        At the time the archive is prepared

·        Annually at the time of a programmed Security Audit

·        At any other time when a full security audit is required

·        Upon an appropriate request by a court of law in Switzerland, by an appropriate arbitration body, or other mechanism established under the OISTE PKI.

4.7      Key changeover

Key changeover is not automatic. Keys expire at the same time as their associated Certificates and, with the exception of the OISTE Root CA which issues a new Certificate and new keys to itself, all Affiliate Certification Authorities are to make an application for Certificate renewal and generate new keys provided they comply with the requirements to continue providing Affiliate Certification Authority services.

Affiliate CAs must ensure that key changeover causes minimal disruption to subordinate service providers and End Users in their chain of trust. In this regard, Affiliate CAs are required to instigate key changeover at least eighteen (18) months before the expiration of its certificates in accordance with the procedures established by the OISTE PAA.

4.8      Compromise and Disaster Recovery

OISTE has established a comprehensive Disaster Recovery plan for the event of a compromise or other disaster that might threaten the Root CA or the OISTE Global Validation Service. The Disaster Recovery plan is reviewed periodically in light of changes to the risk environment.

The Disaster Recovery plan addresses:

·        Failure/corruption of computing resources;

·        Key compromise

·        Developments in cryptanalytical techniques that could threaten the security of the Root CA or its Affiliate CAs

·        Natural disasters

·        Intentional attack on OISTE resources

4.9      CA Termination

In the event that the OISTE Root CA should require termination, the WPAA would invoke the applicable Disaster Recovery Plan mentioned in § 4.8.

If it is necessary to terminate an Affiliate CA in the OISTE PKI, the impact of the termination is to be minimised as much as possible in light of the prevailing circumstances. This includes:

·        Providing as much prior notice as is practicable and reasonable to all subordinate entities

·        The progressive transfer of the service, and operational records, to a successor CA

·        Preserving any records not transferred to a successor Affiliate CA

·        Compliance with any applicable laws or regulations concerning the termination of CA activities.

In the case of the programmed termination of an Affiliate CA in the OISTE PKI, the ACA is to provide subordinate PKI entities with a minimum of eight week’s notice of the proposed shut down and maintain the CA system operational for a minimum period of one (01) year from the moment at which the eight-week notice period ends, to allow re-issuance of all certificates. The Affiliate CA shall publicise any arrangements that have been made or are to be made for the continuation of services by a successor CA.

Affiliate CAs and RAs are to promptly notify their End Users, within the aforementioned eight-week period, and may be requested to assist in planning the progressive rollout of new keys and Certificates by a successor CA.

In the event of an emergency shut down of an Affiliate CA, e.g. due to the compromise of the private key, the CA will follow its Disaster Recovery plan, including the notification of subordinate PKI entities with as much notice as is practicable and reasonable under the prevailing circumstances. In accordance with such plan, all keys and Certificates are to be revoked by the CA immediately and prior to the emergency shut down.

5.     PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS

5.1 Physical Controls for Root CA and Global Validation Service

The hardware and software for the OISTE Root CA is maintained off-line in a bunker in a high security facility in the Swiss Alps with comprehensive perimeter security and internal access controls enforced.

Sophisticated intruder detection systems are deployed to notify security personnel of any violation of access controls.

The Global Validation Service is maintained online in a high security facility with comprehensive physical security perimeter, physical entry controls, secure offices, rooms and facilities, security level segregation, and other aspects referenced in the BS 7799-1:1999 standard.

5.2 Procedural Controls

Roles for the operation of the OISTE Root CA have been assigned to meet the role separation requirements defined by NIST as level 4, the highest level defined.

No member of staff is able to gain physical access or operate any component of the Root CA or Global Validation Service without the presence of other designated members of staff who have the skills required to confirm that no unauthorized or inappropriate actions are conducted.

Procedures are defined and documented for all operations upon the Root CA and the Global Validation Service. Operating procedures are subjected to periodic independent audits and are regularly reviewed in the light of new operational requirements.

5.3 Personnel Controls

All OISTE staff involved in the operation of the Root CA or the Global Validation Service is subjected to background checks and vetting by Interpol. Character references are thoroughly investigated for all operational personnel.

All operation of the OISTE Root CA and Global Validation Service is under the direct responsibility of OISTE Executive Officers, who do not hold an operational role within the Root CA or the Global Validation Service.

Personnel involved in the control and operation of the Root CA and Global Validation Service shall be sufficiently trained to comply with the functions allocated to their role and shall be provided with ongoing training to ensure the appropriate levels of awareness of the security policies and procedures.

6. Technical Security Controls

6.1.    Key Pair Generation and Installation

6.1.1          Key Pair Generation

Key pairs for the OISTE Root CA and Validation Authority are generated in a hardware security module (HSM) certified to meet the requirements of FIPS 140-1 level 4.

Affiliate CAs generate their key pairs in a HSM certified to meet the requirements of FIPS 140-1 level 4.

6.1.2     Private Key delivery to entity

Key deliver to Affiliate CAs will not be provided as each ACA will generate its own cryptographic key pairs.

6.1.3     Public key delivery to certificate issuer

Affiliate CAs’ Public keys are delivered to the Root CA as a PKCS#10 certificate request. The signature on the PKCS#10 request is verified to confirm that the Affiliate CA is in possession of the private key associated with each public key delivered.

6.1.4     CA public key delivery to users

Affiliate CAs are responsible for delivery of their public keys to users. Practices for this are documented in the corresponding CPS of the Affiliate CA. Additionally the certificates of Affiliate Certification Authorities shall be available on the OISTE Web site at http://www.OISTE.com/

6.1.5     Root CA Public Key Delivery to Users

The Certificate of the Root CA is distributed to End Users for Certificate path validation purposes. Registration Officers shall provide this service upon issuance of certificates for administering this process.

The certificate hash (thumbprint) of the OISTE Root CA certificate is available on the OISTE Web site (www.OISTE.com/librarium/). Relying parties must confirm the validity of their copy of the Root CA certificate using this thumbprint.

6.1.6     Key sizes

The modulus of the OISTE Root CA, the OISTE Global Validation Service and the keys of Affiliate CAs are all 2048 bits in length and use the RSA algorithm.

6.1.7     Public key parameters checking

The parameters used in the generation of public keys are in accordance with the requirements of FIPS 140-1.

6.1.8     Parameter quality checking

Parameter quality checking is in accordance with FIPS 140-1.

6.1.9     Hardware/software key generation

All entities within the OISTE PKI that issue certificates generate their keys in hardware.

All end user certificates employ hardware key generation.

6.1.10   Key usage purposes

The Root Cryptographic Key may be used for:

·        the issuance of certificates to the OISTE Global Validation Service and Affiliate Certification Authorities that have been approved to become OISTE Affiliates.

·        Protocol functions for the operation of the Root CA

·        Issuance of Certificate Revocation Lists

6.2.    Private Key Protection

6.2.1.    Standards for cryptographic module

The cryptographic module used by the OISTE Root CA and Affiliate Certification Authorities is certified to FIPS 140-1 level 4/ITSEC E3. In the case of the OISTE Root CA, such cryptographic module is maintained offline.

Affiliate Certification Authorities will be required to maintain their hardware security module in a secure online facility that meets FIPS 140-1 level 4/ITSEC E3 standard.

6.2.2.    Private key (n out of m) multipersonal control

The Root Cryptographic Key can only be exported from the hardware security module when split into multiple parts and requires the presence and participation of several authorised OISTE officers to reconstruct.

6.2.3.    Private key escrow

The OISTE Root CA does not provide this service.

6.2.4.    Private key backup

The Root Private Cryptographic Key is only backed up for disaster recovery purposes.

6.2.5.    Private key archival

The Root Private Cryptographic Key will not be archived.

6.2.6.    Private key entry into cryptographic module

Private keys for the Root CA and the Global Validation Service are generated in HSMs as described in § 6.6 of this CPS. Where there is a requirement for a private key to be loaded or unloaded from a cryptographic module (HSM), the private key is never available in plain text whilst outside a secure environment.

6.2.7.    Method of activating private key

Root CA Private key activation requires entry and validation of a PIN/passphrase compliant with specified security parameters

6.2.8.    Method of deactivating private key

The Root CA Private key is automatically deactivated after each use.

6.2.9.    Method of destroying private key

The Root CA Private key in the HSM may be destroyed by returning the HSM to its factory initialised state. Smartcards and other cryptographic tokens used by the Root CA will be physically destroyed prior to disposal.

6.3     Other Aspects of Key Pair Management

6.3.1     Public key archival

All public keys of the Root CA, Global Validation Service and Affiliate CAs are archived by the Root CA.

6.3.2     Usage periods for the public and private key

The OISTE Root CA key pair and certificate will expire after 25 years from the moment of their generation.

The OISTE Global Validation Service key pairs and certificates will expire annually from the moment of their generation.

6.4     Activation Data

6.4.1        Activation data generation and installation

All activation data generation and installation complies with FIPS 140-1, level 4.

6.4.2        Activation data protection

Activation data protection complies with FIPS 140-1, level 4.

6.5     Computer Security Controls

6.5.1        Specific computer security technical requirements

OISTE has established and documented all computer security technical controls implemented for the OISTE Root CA and Global Validation Service.

6.6     Life Cycle Technical Controls

6.6.1        System development controls

The software used by the OISTE Root has been developed in accordance with the requirements of ITSEC (Information Technology Security Evaluation Criteria) Level E3.

The HSM used by the OISTE Root CA and by the Global Validation System has been certified to meet the requirements of ITSEC level E3 and FIPS 140-1 level 4.

6.6.2        Security management controls

Security management controls are enforced by rigid separation of operator roles to meet the requirements of NIST level 4.

6.7     Network Security Controls

The OISTE Root CA is maintained off-line and is not networked with any external components.

The OISTE Global Validation Service is maintained on-line and uses firewalls for connections to untrusted networks including the Internet. These connections are further secured by using screening routers where applicable. The configuration and access control to these network security devices is strictly controlled and limited to authorised personnel only.

7.     Certificate and CRL Profiles

7.1      Certificate Profile

X.509 Extensions

7.2      CRL Profile

The OISTE Root CA does not have a CRL profile because the Global Validation Service only uses Certificate Revocation Lists. No wider publication of CRLs from the Root CA is undertaken. The OISTE Global Validation Service is fully compliant with OCSP (On-Line Certificate Status Protocol), as stated in RFC2560 [June 1999].

8. Specification Administration

OISTE operates a Policy Approval Authority that is responsible for setting certification practices and certificate policy direction for the overall PKI. Contact details for the WPAA appear in this CPS and in each CPS and CP adopted within the OISTE hierarchy. The OISTE Policy Approval Authority is required to follow the guidelines established by the WorldPKI.org Association which has been established to, among other things, draft such guidelines by mandate from World Internet Security – WISeFoundation, which is the entity that owns the Root Cryptographic Key managed by OISTE.

Affiliate Certification Authorities shall have Policy Creation Authorities and have a contractual obligation to operate in compliance with the requirements established by the WPAA. Affiliate CA Certification Practice Statements and Certificate Policies require approval by the WPAA before adoption.

Each CP used under the OISTE PKI hierarchy has been allocated an OID which:

·        Provides a unique identification for the CP

·        Includes a policy version number

8.1             Specification change procedures

8.1.1     Initial publication

The OISTE Root CPS shall be published upon approval by the WPAA. Publication shall take place at the OISTE Web site at http://www.OISTE.com/librarium/. All Affiliate CA Certification Practice Statements and Certificate Policies shall also be published upon approval by the WPAA and the ACA itself. The locations of such documents shall be clearly indicated in the respective CPS.

Affiliate CAs, therefore, apply to the WPAA for:

·        Formal approval of the CPS and Certificate Policies under which they will issue Certificates.

·        The allocation of an OID to a specific CP

After the CPS or CP has been approved (and the OID has been granted in the case of the CP), the Affiliate CA follows the procedures provided for in its CPS in order to ensure its dissemination and availability, including:

·        The Publication of the CPS and Certificate Policies in accordance with the OISTE Root CA guidelines.

·        Advising all relevant subordinate entities of the CPS and CP as well as their applicability.

·        Forwarding a copy of the CPS and each CP to relevant subordinate Certification Authorities and Registration Authorities, together with information on the location of the master CPS and Certificate Policies.

8.1.2     Changes

8.1.2.1              Authority to amend

OISTE, through the WPAA, shall have the right to amend this CPS as well as to request that subordinate Certificate Practice Statements and Certificate Policies be amended. OISTE may, in its sole discretion, make amendments or requests for amendments at any time.

The World Internet Security – WISeFoundation shall also be entitled to require OISTE to comply with the guidelines it issues for the management of the Root Cryptographic Key which may require OISTE to amend its CPS. In these cases, any amendments made by OISTE shall be subject to World Internet Security – WISeFoundation review under the consultation mechanism referred to under 8.1.2.3.

8.1.2.2                            Nature of Amendments and Effective Date

Amendments to the Root CPS shall not be retroactive, shall override any previous versions of the OISTE CPS and conflicting provisions of the amended CPS, and shall apply to all OISTE operations and the whole of the OISTE PKI. The amendments made to the Root CPS may be of three types:

·        Substantial Amendments: these are the amendments which, in the judgment of OISTE, are of such significance that they require to be subject to a consultation on behalf of all Subordinate PKI Entities within the OISTE PKI and by World Internet Security – WISeFoundation prior to their becoming effective.

·        Immediately Effective Substantial Amendments: these are amendments which, in the judgment of OISTE, are of similar significance to the Substantial Amendments but require immediate effectiveness to impede the total or partial loss of integrity, security or trustworthiness to the OISTE PKI.

·        Insubstantial Amendments: these are amendments that are, in the sole judgment of OISTE, of little significance and are therefore not subject to any consultation. Unless otherwise explicitly provided for in OISTE’s sole discretion, these amendments shall have effect upon publication.

Similar amendment classifications may be incorporated into the subordinate Certification Practice Statements and Certificate Policies but in all cases, any amendments to the Root CPS that require modifications to such documents shall impose on the entities administering them the initiation of their amendment procedures in order to make the necessary changes.

Where changes are required to a specific Certificate Policy, the WPAA will determine whether such changes warrant the issuance of a new Object Identifier (OID), depending on the significance of the change in the Certificate Policy. If the WPAA determines that a new OID is required, it shall differ from the previous OID only in the policy version number.

Changes to a specific Certificate Policy will only be approved if the WPAA determines that it is in compliance with the corresponding CPS.

With the exception of Substantial Amendments and unless otherwise explicitly provided for by OISTE, all other amendments (Immediately Effective Substantial Amendments and Insubstantial Amendments) shall become effective upon publication. Substantial Amendments shall become effective upon finalisation of the consultation period and publication of the definitive version on the OISTE Web site. The status of the document and date of effectiveness or finalisation of the consultation period will be clearly indicated on the document in question.

8.1.2.3                            Consultation Period

All Substantial Amendments and others explicitly indicated by OISTE shall be subject to consultation by OISTE Subordinate PKI entities and World Internet Security – WISeFoundation for a minimum period of fifteen (15) days. During such period, OISTE may withdraw the proposed amendments, the aforementioned entities may make comments on the changes proposed, and OISTE may, in its sole discretion, incorporate the changes suggested in such comments. Upon termination of the consultation period, the CPS shall be published with the definitive amendments, if any.

8.1.2.4                            Consent to Amendments

All PKI subordinate entities and their clients that do not agree with the amendments being proposed or which have become effective immediately are entitled to revoke their certificates. In all cases, the revocation request and all applicable procedures (e.g. ACA termination procedures) shall be initiated within five (05) working days following the effectiveness date of the amendments. Upon termination of this period, all certificate holders within the OISTE PKI who have not requested revocation, shall be deemed to have given their consent to such amendments and to comply with them accordingly.

8.2             Publication and notification policies

All amendments and amendment proposals in accordance with the foregoing sections shall be published at the OISTE Librarium athttp://www.OISTE.com/librarium/. Unless otherwise explicitly provided for, such publication shall be deemed sufficient notice for the purposes of consultations, the effectiveness date of the amendments, the consent to the amendments, as well as any other relevant purposes regarding such published documents.

With regard to the new or amended Certificate Practice Statements and Certificate Policies of Subordinate PKI entities, they shall be published on the Web site designated in the corresponding document.

8.3      CPS and CP approval procedures

Certification Practice Statements and Certificate Policies intended for use under the OISTE Root CA must be approved by the OISTE PAA. A document setting out the functions of the WPAA is made available to all subordinate entities responsible for creating or amending Certificate Policies and to any authorised persons conducting security audits.

Appendix – Glossary

Access Control

The prevention of unauthorised use of a resource, including the prevention of use of a resource in an unauthorised manner.

[ISO 7498-2: 1989]

Access Control List

A list of entities, together with their access rights, which are authorised to have access to a resource.

[ISO 7498-2: 1989]

Accountability

The property that ensures that the actions of an entity may be traced uniquely to the entity.

[ISO 7498-2: 1989] [TR 13335-1: 1996]

Applicant

The entity that has applied to be issued a certificate within the OISTE PKI. The verification processes vary in accordance with the nature and, where applicable, the operational role within the PKI corresponding to the certificate the entity is applying for (e.g. ACA, ARA, BSP or end user certificate).

Asymmetric Authentication Method

A method of authentication, in which not all authentication data is shared by both entities.

[ISO/IEC 10181-2: 1996]

Asymmetric Cryptographic Technique

A cryptographic technique that uses two related transformations, a public transformation (defined by the public key) and a private transformation (defined by the private key). The two transformations have the property that, given the public transformation, it is computationally infeasible to derive the private transformation.

[ISO/IEC 11770-1: 1996]

Asymmetric Key Pair

A pair of related keys where the private key defines the private transformation and the public key defines the public transformation.

[ISO/IEC 9798-1 (2nd edition): 1997] [2nd DIS ISO/IEC 11770-3 (08/1997)]

Audit

Audit is defined as an independent review and examination of system records and activities to assess the adequacy and effectiveness of system controls, to ensure compliance with established policies and operational procedures, and to recommend necessary changes in controls, policies, or procedures.

[ISO/IEC POSIX Security]

Audit Event

An action, detected internally by the system which may generate an audit record. If an event causes an audit record to be generated [for recording in the audit trail], it is a “recorded event” otherwise, it is an “unrecorded event”. The system decides, as each event is detected, whether to generate an audit record by the audit pre-selection algorithm. The set of audit events is based upon a system’s security policy.

[ISO/IEC POSIX Security]

Audit Record

The discrete unit of data recorded in the audit trail on the occurrence of a recorded event. An audit record consists of a set of audit descriptions, each of which has a set of audit attributes associated with it. Every audit record always has an audit description for the record’ s header, and usually has additional audit descriptions describing the entity(ies) and object(s) involved in the event.

[ISO/IEC POSIX Security]

Authenticate

The act of verifying that specific data originated from a specific source.

Authentication Data

Information used to authenticate.

Availability

The property of information being accessible and usable upon demand by an authorised entity or process.

Bronze Service Provider

As described in §1.3.1.6.

Certificate Chain

A chain of multiple certificates needed to validate a certificate containing the required public key. A certificate chain would consist of a certificate of the public key owner signed by one certification authority, and one or more additional certificate of certification authorities signed by other certification authorities.

Certificate Generation

Certificate generation is the process of creating a certificate from inputs specific to the application and the user.

Certificate Policy (CP)

A named set of rules that indicate the applicability of a certificate to a particular community and/or class of application with common security requirements. For example, a particular certificate policy might indicate applicability of a type of certificate to the authentication of electronic data interchange transactions for the trading of goods within a given price range.

Certificate Request

Authenticated request by an entity for its parent authority to issue a certificate which binds the identity of that entity to its public key.

Certificate Revocation

Certificate revocation is the process of changing the status of a certificate from valid or suspended to revoked. The status of a certificate as revoked means that it should not longer be relied upon by any entity for whatever purpose.

Certificate Revocation List (CRL)

A signed list of the certificates which have been revoked by a certification authority.

Certificate

A data structure, using the CCITT ITU X.509 standard, containing the public key of an entity, together with associated information, and rendered unforgeable by being digitally signed by the certification authority which issued it.

Certificate Serial Number

An integer value, unique within the issuing CA (certification authority), which is unambiguously associated with a certificate issued by that CA.

[ISO/IEC 9594-8: 1990] [CCITT X.509: 1988]

Certification Authority

An authority trusted by one or more users to create, issue and manage the life-cycle of certificates.

Certification Practice Statement

A statement of the practices which a certification authority employs in issuing certificates.

Compliance Audit

A review and examination of system records and activities in order to test for adequacy of system controls, to ensure compliance with established policy and operational procedures, to detect breaches in security, and to recommend any indicated changes in control, policy and procedures.

Confidentiality

The property that information is not made available or disclosed to unauthorised individuals, entities, or processes.

[ISO 7498-2: 1989] [TR 13335-1: 1996]

Cryptographic Key

A parameter used in conjunction with an algorithm for the purpose of validation, authentication, encipherment or decipherment.

[ISO 8732: 1988]

Cryptographic Token

The medium in which a key is stored (e.g. smart card, cryptographic key).

Cryptography

The discipline which embodies principles, means, and methods for the transformation of data in order to hide its information content, prevent its undetected modification and/or prevent its unauthorised use.

[ISO 7498-2: 1989] [ISO 8732: 1988]

Data Integrity

The quality or condition of being accurate, complete and valid, and not altered or destroyed in an unauthorised manner.

Digital Signature

Data appended to, or a cryptographic transformation of a data unit that allows a recipient of the data unit to prove the source and integrity of the data unit and protect against forgery e.g. by the recipient.

[ISO 7498-2: 1989]

Encryption

The process by which plain text data are transformed to conceal their meaning. Encryption is a reversible process effected by using a cryptographic algorithm and key.

End User

These are entities (legal, natural, mechanical or electronic) that have been issued certificates within the OISTE PKI but are not subordinate PKI entities.

Entity

Any person (legal or natural) or system (mechanical or electronic) that is issued a certificate through the OISTE PKI.

Evaluation

Assessment against defined criteria in order to give a measure of confidence it meets the corresponding requirements.

Identification information

The information obtained or presented to positively identify an entity.

Identity Verification

The process of using identification information to determine the identity of an entity.

Interoperability

Interoperability implies that equipment and procedures in use by two or more entities are compatible, and hence that it is possible to undertake common or related activities.

Key

A sequence of symbols that controls the operation of a cryptographic transformation (e.g. encipherment, decipherment, cryptographic check function computation, signature generation, or signature verification).

[ISO/IEC 9798-1 (2nd edition): 1997] [ISO/IEC 11770-1: 1997]

Key Archiving

Key archiving is the process of storing used key or their ID, and/or certificates as a record in long term storage for future retrieval.

Key Destruction

Key destruction is the process of removing all copies of a key throughout the key management system.

Key Generation

Key generation is the process by which cryptographic keys are created. It is the function of generating variables required to meet particular key attributes.

Key Management

The administration and use of the generation, registration, certification, deregistration, distribution, installation, storage, archiving, revocation, derivation and destruction of keying material in accordance with a security policy.

[ISO/IEC 11770-1: 1997]

Key Management Facility

A protected enclosure (e.g. room or cryptographic equipment) and it contents where cryptographic elements reside.

[ISO 8732: 1988]

Key Pair

The keys in an asymmetric cryptosystem having the property that one of the pair will decrypt what the other encrypts.

OCSP (On-Line Certificate Status Protocol)

A protocol which is used to provide real-time validation of a certificate’s status. An OCSP responder is used to respond to certificate status requests and can issue one of three responses: Valid, Invalid, Unknown.

An OCSP responder replies to certificate status requests on the basis of CRLs (Certificate Revocation Lists) provided to it by certification authorities.

Operational Infrastructure

The technological infrastructure by which the certification services are provided. This infrastructure does not necessarily coincide with the legal infrastructure or relationships that exist or that develop between entities that form part of the OISTE PKI or that use the OISTE PKI certification services in any way.

Physical Security

The measures used to provide physical protection of resources against deliberate and accidental threats.

[ISO 7498-2: 1989]

Plaintext

Unenciphered information.

[ISO 8372: 1987] [ISO 8732: 1988] [ISO/IEC 9798-1 (2nd edition): 1997] [ISO/IEC 10116 (2nd edition): 1997]

Post-Suspension Investigation

Investigation performed by the WPAA after a certificate has been suspended in order to determine whether such certificate should be revoked or reinstated as valid.

Private Key

That key of an entity’s asymmetric key pair which shall normally only be known by that entity.

[2nd DIS ISO/IEC 11770-3 (08/1997)]

Public Key

That key of an entity’s asymmetric key pair which can be made public, although not necessarily available to the public in general, as it may be restricted to a pre-determined group.

Public Key Certificate

A digital certificate that binds unforgeably the public key of an entity to the entity’s distinguishing identifier, and which indicates the validity of the corresponding private key.

[ISO/IEC 13888-1: 1997]

Public Key Infrastructure

The infrastructure needed to generate, distribute, manage and archive keys, certificates and certificate revocation lists, and OCSP responders.

[2nd DIS ISO/IEC 11770-3 (08/1997)]

Recipient

The entity that gets (receives or fetches) a message.

Relying Party

Any entity relying on a certificate that: (1) has agreed to a Relying Party agreement or other similar agreement (e.g. Root CA – Affiliate CA Agreement) or (2) is designated as such by an approved Certificate Policy, despite not having signed a Relying Party agreement.

Rekey

The act of replacing an expired Certificate either by providing a new set of keys.

Registration Authority

An entity whose purpose is to provide local support to a set of Subordinate PKI Entities or End Users  that are physically far from their immediate superior certification authority. A Registration Authority performs a subset of the functions available to a certification authority administrator responsible for directly managing a set of Subordinate PKI Entities and end users. The functions of Registration Authorities within the OISTE PKI are provided for under § 1.3 of this CSP and under the corresponding CPS of its parent ACA.

Revocation

To change the status of a valid or suspended certificate to “revoked” from a specified time and forward.

Root CA (RCA)

It is the apex a PKI hierarchy which is provided by the OISTE Root within the OISTE PKI.

Subordinate PKI Entities

Any entity that forms part of the OISTE PKI as structured in the OISTE Root CPS that have the authority to operate or provide certification services, such as the Affiliate Certification Authority, Affiliate Registration Authority and Bronze Service Providers. The End Users to which the certificates are issued and Relying Parties are not Subordinate PKI Entities.

Summary Information

This information is the basic amount of information required for the production of a public key certificate as well as the information required for the validation of a certificate’s status and the resulting information from such validation.

*Validation

The process of checking the integrity of a message, or selected parts of a message, or the validity of a Certificate in terms of its status (i.e. suspended or revoked).

Verification Process

A process which takes as input the signed message, the verification key and the domain parameters, and which gives as output the result of the signature verification: valid or invalid.

[FCD ISO/IEC 14888-1 (12/1997)]