Certificate Policy Statement

Table of Contents

1.0

Introduction

1.1

Definitions

1.2

Contact Details

2.0

General Provisions

2.1

Obligations

2.2

Warranty

2.3

Intellectual Property Rights

3.0

Identification and Authentication

3.1

Initial Registration and Issuance

4.0

Operational Practices

4.1

Certificate Renewal

4.2

Certificate Revocation

4.3

Security Audit Procedures

4.4

Certificate Validity Periods

4.5

CA Termination

5.0

Technical Security Practices

5.1

Key Pair Generation and Installation

5.2

Private Key Protection

5.3

Other Aspects of Key Pair Management

5.4

Computer Security Controls

5.5

Life Cycle Technical Controls

6.0

Certificate Profiles

6.1

Certificate Profile

1.0 Introduction

This document describes the practices used by “COMPANY” IT services, when issuing, managing, revoking, and renewing digital certificates upon which “COMPANY”’s PKI is based.

1.1. Definitions

·         CA:  Certificate Authority:  All Trusted Persons and entities involved in the issuance of Certificates within “COMPANY”

·         CPS: Certificate Practice Statement:  This statement of the practices that “COMPANY” employs in approving or rejecting Certificate Applications and issuing, managing, revoking, and renewing Certificates.

·         Certificate:  A message that, at least, states a name or identifies the CA, identifies the Subscriber, contains the Subscriber’s public key, identifies the Certificate’s validity period, contains a Certificate serial number, and is digitally signed by the CA.

·         Certificate Applicant:  The end-entity or representative thereof requesting a Certificate.

·         Certificate Application:  A request from a Certificate Applicant (or authorized agent of the Certificate Applicant) to a CA for the issuance of a Certificate.

·         End-entity:  A partner, or customer in a business relationship with “COMPANY”.

·         PKI:  Public Key Infrastructure:  The architecture, organization, techniques, practices, and procedures that collectively support the implementation and operation of a certificate-based public key cryptographic system.

·         Subscriber:  In the case of an individual Certificate, a person who is the subject of, and has been issued, a Certificate.  In the case of an organizational Certificate, an organization that owns the equipment or device that is the subject of, and that has been issued, a Certificate.  A Subscriber is capable of using, and is authorized to use, the private key that corresponds to the public key listed in the Certificate.

·         Trusted Person:  An administrator within “COMPANY” responsible for managing infrastructure trustworthiness, its services, its facilities, and/or its practices.

·         Personal Certificates: Certificates provided to individuals performing “COMPANY” corporate functions to enable access to online services and applications.

·         Server Certificates: Certificates provided for the purpose of uniquely identifying servers on the “COMPANY” network that support corporate services and applications.

·         Certificate Authority Certificates: Certificates for the purpose of establishing a hierarchy of trust among “COMPANY”’s Certificate Authorities.

·         Special Certificates: Certificates provided for the purpose of providing specific special capabilities not provided by the other three types of certificates.

1.2. Contact Details

The group administering this CPS is the “COMPANY” in Information Technology Department.  Inquiries about the COMPANY system should be made to COMPANY CONTACT EMAIL ADDRESS.

2.0 General Provisions

This section identifies the policies to which the PKI must conform and states the purposes for which private keys and Certificates are to be used.

2.1. Obligations

MultiFactor Corporation’s SecureAuth Certificate Authority Appliance issues the following certificates:

·         Personal SSL Certificates

The Certificate Applicant agrees that no unauthorized person will ever have access to the private key.

The Certificate Applicant agrees that all representations made in the submitted Certificate Application are true.

The Certificate Applicant agrees that the Certificate is being used exclusively for authorized purposes, consistent with this CPS.

2.2. Warranty

“COMPANY” includes a warranty to Subscribers who reasonably rely on a “COMPANY” issued Certificate that all information in or incorporated by reference in such Certificate is accurate.

“COMPANY” offers no warranties or remedies associated with the misuse or unauthorized use of “COMPANY” certificates that are issued by “COMPANY”.

2.3 Intellectual Property Rights

Key pairs corresponding to Certificates of CAs and Subscribers are the property of the CAs and Subscribers that are the respective subjects of these Certificates.  “COMPANY”’s root public keys and the root Certificates containing them, including all public keys and self-signed Certificates, are the property of “COMPANY” Corporation.

3.0 Identification and Authentication

This section describes the mechanisms used to establish and prove the validity of Certificate Applicants.  This section also addresses naming practices.

3.1. Initial Registration and Issuance

Certificate Applicants must request a Certificate through the SecureAuth Enrollment Appliance.

Before a Certificate will be issued to a Certificate Applicant, “COMPANY” may access or request some form(s) of identification, including but not limited to the following:

4.0 Operational Practices

The operational practices describe the operating procedures for the CAs and Subscribers.

4.1. Certificate Renewal

Prior to the expiration of an existing Subscriber Certificate, it is necessary for the Subscriber to obtain a new Certificate to maintain continuity of Certificate usage.  “COMPANY” generally requires that the Subscriber generate a new key pair to replace the expiring key pair.

4.2. Certificate Revocation

A Certificate may be revoked by “COMPANY” for any reason, including but not limited to the following reasons:

 Revocation of a Certificate can be requested at any time by any of the following entities:

Prior to the revocation of a Certificate, “COMPANY” will verify that the revocation has been requested by the appropriate entity.  This communication with the entity requires reasonable assurances that the person or organization requesting revocation is, in fact, that person or organization.  Depending on the circumstances, such communication may include one or more of the following:  telephone, facsimile, e-mail, postal mail, or courier service.

4.3. Security Audit Procedures

“COMPANY” can manually or automatically log any of the following significant events:

·        Certificate life cycle management events

·        Security-related events

4.4. Certificate Validity Periods

Certificate validity will be determined by the Certificate Authority and will be dependent on the relationship of the end-entity with “COMPANY”.  Validity will be reviewed on a regular basis.

The validity period of a Certificate ends upon its expiration or revocation.

. Certificate validity.

The length of the Certificate validity period will be determined by the Certificate Authority and will vary by Subscriber, depending upon the relationship of the end-entity to “COMPANY”. The standard Key lengths will be as follows.

4.5. CA Termination

In the event that it is necessary for a “COMPANY” CA to cease operation, “COMPANY” will make a reasonable effort to notify affected entities of such termination in advance.

5.0 Technical Security Practices

Technical security practices deal with the required technical standards for the components of the system.  These practices include computer security controls and cryptographic module engineering controls.

5.1. Key Pair Generation and Installation

Subscribers submit their public key to “COMPANY” for certification electronically through the use of a PKCS#10 Certificate Signing Request (CSR) or other digitally signed package in a session secured by Secure Sockets Layer (SSL) or WSE 3.0.  Where “COMPANY” generates key pairs, this requirement is not applicable.

5.2. Private Key Protection

“COMPANY “does not creates backup copies of CA private keys.

All “COMPANY” PKI participants are required to protect the activation data for their private keys against loss, theft, modification, unauthorized disclosure, or unauthorized use.

The “COMPANY” standard for private key protection is for end-entities to take reasonable measures for the physical protection of the Subscriber’s workstation to prevent use of the workstation and its associated private key without the end-entity’s authorization.

All Subscribers are required to report unauthorized disclosure of their private key.

Upon discovery of the unauthorized disclosure of the private key, Subscribers will be required to contact “COMPANY” IT Services within one working day. This notification should be made via the contact point as listed in Section 1.2 of this CPS.

5.3. Other Aspects of Key Pair Management

“COMPANY” CA and Subscriber Certificates may be backed up and archived as part of “COMPANY”‘s routine backup procedures.

If a Subscriber is unable to complete re-authentication procedures under the “COMPANY” CPS successfully or is unable to prove possession of such private key when required by the foregoing, “COMPANY” can automatically revoke the Certificate.

5.4. Computer Security Controls

“COMPANY” ensures that the systems maintaining CA software and data files are reasonably secure from unauthorized access. In addition, “COMPANY” limits access to CA system servers to those individuals with a valid business reason for such access.

5.5. Life Cycle Technical Controls

Upon installation and periodically thereafter, “COMPANY” validates the integrity of its CA systems.

6.0 Certificate Profiles

6.1. Certificate Profile

The “COMPANY” CPS defines “COMPANY”’s Certificate profile and Certificate content requirements for Certificates issued under this CPS.

“COMPANY” CA and Subscriber Certificates are X.509v3 Certificates.

Where X.509v3 Certificates are used, “COMPANY” populates Certificates with the extensions required by the CPS.  Private extensions are permissible as long as their use is consistent with this CPS.

“COMPANY” X.509v3 Certificates are signed with SHA1. 

“COMPANY” may include additional fields in its Certificates as necessary, except when interoperability limitations within Certificates make such a field impossible to use in conjunction with the application for which the Certificates are intended.