Aeromacs PKI Certificate Policy

Aeromacs PKI Certificate Policy

WiMAX FORUM PROPRIETARY

WiMAX Forum® Network Architecture DRAFT-T32-006-R010v01-D

AeroMACS PKI Certificate Policy

Copyright Notice, Use Restrictions, Disclaimer, and Limitation of Liability

Copyright 2015WiMAX Forum. All rights reserved.

The WiMAX Forum® owns the copyright in this document and reserves all rights herein. This document is available for download from the WiMAX Forum and may be duplicated for internal useby the WiMAX Forum Members, provided that all copies contain all proprietary notices and disclaimers included herein. Except for the foregoing, this document may not be duplicated, in whole or in part, or distributed without the express written authorization of the WiMAX Forum.

Use of this document is subject to the disclaimers and limitations described below. Use of this document constitutes acceptance of the following terms and conditions:

THIS DOCUMENT IS PROVIDED “AS IS” AND WITHOUT WARRANTY OF ANY KIND. TO THE GREATEST EXTENT PERMITTED BY LAW, THE WiMAX Forum DISCLAIMS ALL EXPRESS, IMPLIED AND STATUTORY WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF TITLE, NONINFRINGEMENT, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE WiMAX ForumDOES NOT WARRANT THAT THIS DOCUMENT IS COMPLETE OR WITHOUT ERROR AND DISCLAIMS ANY WARRANTIES TO THE CONTRARY.

Any products or services provided using technology described in or implemented in connection with this document may be subject to various regulatory controls under the laws and regulations of various governments worldwide. The user is solely responsible for the compliance of its products and/or services with any such laws and regulations and for obtaining any and all required authorizations, permits, or licenses for its products and/or services as a result of such regulations within the applicable jurisdiction.

NOTHING IN THIS DOCUMENT CREATES ANY WARRANTIES WHATSOEVER REGARDING THE APPLICABILITY OR NON-APPLICABILITY OF ANY SUCH LAWS OR REGULATIONS OR THE SUITABILITY OR NON-SUITABILITY OF ANY SUCH PRODUCT OR SERVICE FOR USE IN ANY JURISDICTION.

NOTHING IN THIS DOCUMENT CREATES ANY WARRANTIES WHATSOEVER REGARDING THE SUITABILITY OR NON-SUITABILITY OF A PRODUCT OR A SERVICE FOR CERTIFICATION UNDER ANY CERTIFICATION PROGRAM OF THE WiMAX Forum OR ANY THIRD PARTY.

The WiMAX Forum has not investigated or made an independent determination regarding title or noninfringement of any technologies that may be incorporated, described or referenced in this document. Use of this document or implementation of any technologies described or referenced herein may therefore infringe undisclosed third-party patent rights or other intellectual property rights. The user is solely responsible for making all assessments relating to title and noninfringement of any technology, standard, or specification referenced in this document and for obtaining appropriate authorization to use such technologies, technologies, standards, and specifications, including through the payment of any required license fees.

NOTHING IN THIS DOCUMENT CREATES ANY WARRANTIES OF TITLE OR NONINFRINGEMENT WITH RESPECT TO ANY TECHNOLOGIES, STANDARDS OR SPECIFICATIONS REFERENCED OR INCORPORATED INTO THIS DOCUMENT.

IN NO EVENT SHALL THE WiMAX Forum OR ANY MEMBER BE LIABLE TO THE USER OR TO A THIRD PARTY FOR ANY CLAIM ARISING FROM OR RELATING TO THE USE OF THIS DOCUMENT, INCLUDING, WITHOUT LIMITATION, A CLAIM THAT SUCH USE INFRINGES A THIRD PARTY’S INTELLECTUAL PROPERTY RIGHTS OR THAT IT FAILS TO COMPLY WITH APPLICABLE LAWS OR REGULATIONS. BY USE OF THIS DOCUMENT, THE USER WAIVES ANY SUCH CLAIM AGAINST THE WiMAX Forum AND ITS MEMBERS RELATING TO THE USE OF THIS DOCUMENT.

The WiMAX Forum reserves the right to modify or amend this document without notice and in its sole discretion. The user is solely responsible for determining whether this document has been superseded by a later version or a different document.

“WiMAX,” “Mobile WiMAX,” “Fixed WiMAX,” “WiMAX Forum,” “WiMAX Certified,” “WiMAX Forum Certified,” “WiGRID,” the WiMAX Forum logo and the WiMAX Forum Certified logo are trademarks or registered trademarks of the WiMAX Forum. All other trademarks are the property of their respective owners.

Page - 1

WiMAX FORUM PROPRIETARY

WiMAX Forum® Network Architecture DRAFT-T32-006-R010v01-D

AeroMACS PKI Certificate Policy

Document Status

WiMAX Forum Document ID: / T32-006-R010-v01
Document Title: / AeroMACS PKI Certificate Policy
Status: / Work in Progress / Draft / Issued / Closed
Distribution Restrictions: / Author Only / AeroMACS/ Member / AeroMACS/ Member/
Vendor / Public

Revision History

Revision / Date / Remarks
A / 2015-10-13 / Initial Draft to propose structure and outline certificate profiles in section 7
B / 2015-10-14 / Outline of all future sections added for context
C / 2015-11-10 / Section 6 added and Section 7 updated
D / 2015-11-24 / Section 5 and 8 added

Key to Document Status Codes:

Work in Progress / An incomplete document, designed to guide discussion and generate feedback that may include several alternative requirements for consideration.
Draft / A document in specification format considered largely complete, but lacking review by Members. Drafts are susceptible to substantial change during the review process.
Issued / A stable document, which has undergone rigorous review and is suitable for publication.
Closed / A static document, reviewed, tested, validated, and closed to further documentation change requests.

TABLE OF CONTENTS

WiMAX Forum® Network Architecture

1.Introduction

1.1Overview

1.2Document Name and Identification

1.3PKI Participants

1.4Certificate Usage

1.5Policy Administration

1.6Definitions and Acronyms

2.Introduction

2.1Repositories

2.2Publication of Certification Information

2.3Time or Frequency of Publication

2.4Access Controls on Repositories

3.Identification and Authentication

3.1Naming

3.2Initial Identity Validation

3.3Identification and Authentication for Re-key Requests

3.4Identification and Authentication for Revocation Request

4.Certificate Life-cycle Operational Requirements

4.1Certificate Application

4.2Certificate Application Processing

4.3Certificate Issuance

4.4Certificate Acceptance

4.5Key Pair and Certificate Usage

4.6Certificate Renewal

4.7Certificate Re-key

4.8Certificate Modification

4.9Certificate Revocation and Suspension

4.10Certificate Status Services

4.11End of Subscription

4.12Key Escrow and Recovery

5.Facility, Management, and Operational Controls

5.1Physical Controls

5.1.1Site Location and Construction

5.1.2Physical Access for CA Equipment

5.1.3Power and Air Conditioning

5.1.4Water Exposures

5.1.5Fire Prevention and Protection

5.1.6Media Storage

5.1.7Waste Disposal

5.1.8Off-Site Backup

5.2Procedural Controls

5.2.1Trusted Roles

5.2.2Number of Persons Required per Task

5.2.3Identification and Authentication for Each Role

5.2.4Roles Requiring Separation of Duties

5.3Personnel Controls

5.3.1Qualifications, Experience, and Clearance Requirements

5.3.2Background Check Procedures

5.3.3Training Requirements

5.3.4Retraining Frequency and Requirements

5.3.5Job Rotation Frequency and Sequence

5.3.6Sanctions for Unauthorized Actions

5.3.7Independent Contractor Requirements

5.3.8Documentation Supplied to Personnel

5.4Audit Logging Procedures

5.4.1Types of Events Recorded

5.4.2Frequency of Processing Log

5.4.3Retention Period for Audit Log

5.4.4Protection of Audit Log

5.4.5Audit Log Backup Procedures

5.4.6Audit Collection System (Internal vs. External)

5.4.7Notification to Event-Causing Subject

5.4.8Vulnerability Assessments

5.5Records Archival

5.5.1Types of Events Archived

5.5.2Retention Period for Archive

5.5.3Protection of Archive

5.5.4Archive Backup Procedures

5.5.5Requirements for Time-Stamping of Records

5.5.6Archive Collection System (Internal or External)

5.5.7Procedures to Obtain and Verify Archive Information

5.6Key Changeover

5.7Compromise and disaster recovery

5.7.1Incident and Compromise Handling Procedures

5.7.2Computing Resources, Software, and/or Data Are Corrupted

5.7.3Entity (CA) Private Key Compromise Procedures

5.7.4Business Continuity Capabilities after a Disaster

5.8CA Termination

6.TECHNICAL SECURITY CONTROLS

6.1Key Pair Generation and Installation

6.1.1Key Pair Generation

6.1.2Private Key Delivery to Subscriber

6.1.3Public Key Delivery to Certificate Issuer

6.1.4CA Public Key Delivery to Relying Parties

6.1.5Key Sizes

6.1.6Public Key Parameters Generation and Quality Checking

6.1.7Key Usage Purposes (as per X.509 v3 Key Usage Field)

6.2Private Key Protection and Cryptographic Module Engineering Controls

6.2.1Cryptographic Module Standards and Controls

6.2.2Private Key (n out of m) Multi-Person Control

6.2.3Private Key Escrow

6.2.4Private Key Backup

6.2.5Private Key Archival

6.2.6Private Key Transfer into or from a Cryptographic Module

6.2.7Private Key Storage on Cryptographic Module

6.2.8Method of Activating Private Key

6.2.9Method of Deactivating Private Key

6.2.10Method of Destroying Private Key

6.2.11Cryptographic Module Rating

6.3Other Aspects of Key Pair Management

6.3.1Public Key Archival

6.3.2Certificate Operational Periods and Key Pair Usage Periods

6.4Activation data

6.4.1Activation Data Generation and Installation

6.4.2Activation Data Protection

6.4.3Other Aspects of Activation Data

6.5Computer security controls

6.5.1Specific Computer Security Technical Requirements

6.5.2Computer Security Rating

6.6Life Cycle Technical Controls

6.6.1System Development Controls

6.6.2Security Management Controls

6.6.3Life Cycle Security Controls

6.7Network Security Controls

6.8Time-Stamping

7.CERTIFICATE, CRL, AND OCSP PROFILES

7.1Certificate Profile

7.1.1Version Number(s)

7.1.2Certificate Extensions

7.1.3Algorithm Object Identifiers (OIDs)

7.1.4Name Forms

7.1.5Name Constraints

7.1.6Certificate Policy Object Identifier

7.1.7Usage of Policy Constraints Extension

7.1.8Policy Qualifiers Syntax and Semantics

7.1.9Processing Semantics for the Critical Certificate Policies Extension

7.2CRL Profile

7.2.1Version Number(s)

7.2.2CRL and CRL entry extensions

7.3OCSP Profile

7.3.1Version Number(s)

7.3.2OCSP Extensions

8.Compliance Audit and Other Assessments

8.1Frequency or Circumstances of Assessment

8.2Identity/Qualifications of Assessor

8.3Assessor's Relationship to Assessed Entity

8.4Topics Covered by Assessment

8.5Actions Taken as a Result of Deficiency

8.6Communication of Results

9.Other Business and Legal Matters

9.1Fees

9.2Financial Responsibility

9.3Confidentiality of business information

9.4Privacy of Personal Information

9.5Intellectual Property Rights

9.6Representations and Warranties

9.7Disclaimers of warranties

9.8Limitations of liability

9.9Indemnities

9.10Term and termination

9.11Individual notices and communications with participants

9.12Amendments

9.13Dispute Resolution Provisions

9.14Governing Law

9.15Compliance with Applicable Law

9.16Miscellaneous provisions

9.17Other Provisions

10.References

11.Glossary

12.Abbreviations and Acronyms

TABLE OF FIGURES (If applicable)

TABLE OF TABLES

Table 1: Algorithm Type and Key Size

Table 2: keyUsage Extension for all CA certificates

Table 3: keyUsage Extension for all Subscriber Signature Certificates

Table 4: keyUsage Extension for all Key Management Certificates

Table 5: keyUsage Extension for all Server Certificates

Table 6: Certificate Profile Basic Fields

Table 7: Root CA Certificate Standard Extensions

Table 8: Sub-CA Certificate Standard Extensions

Table 9: Subscriber Certificate Standard Extensions

Table 10: OCSP Certificate Standard Extensions

Table 11: subjectKeyIdentifier Extension for AeroMACS CA Certificates

Table 12: basicConstraints Extension for AeroMACS Root CA Certificates

Table 13: basicConstraints Extension for AeroMACS Sub-CA Certificates

Table 14: extKeyUsageExstension for AeroMACS Server Certificates

Table 15: extKeyUsageExstension for AeroMACS Client Certificates

Table 16: Signature OIDS for Certificates

Table 17: subjectPublicKeyInfo for Certificate

Table 18: Root CA Certificate issuer and subject Fields

Table 19: Sub-CA Certificate subject Fields

Table 20: Subscriber Certificate subject Fields

Table 21: certificatePolicies Extension for AeroMACS Certificates

Table 22: CRL Profile Basic Fields

Page - 1

WiMAX FORUM PROPRIETARY

WiMAX Forum® Network Architecture DRAFT-T32-006-R010v01-D

AeroMACS PKI Certificate Policy

1.Introduction

1.1Overview

1.2Document Name and Identification

1.3PKI Participants

1.4Certificate Usage

1.5Policy Administration

1.6Definitions and Acronyms

2.Introduction

2.1Repositories

2.2Publication of Certification Information

2.3Time or Frequency of Publication

2.4Access Controls on Repositories

3.Identification and Authentication

3.1Naming

3.2Initial Identity Validation

3.3Identification and Authentication for Re-key Requests

3.4Identification and Authentication for Revocation Request

4.Certificate Life-cycle Operational Requirements

4.1Certificate Application

4.2Certificate Application Processing

4.3Certificate Issuance

4.4Certificate Acceptance

4.5Key Pair and Certificate Usage

4.6Certificate Renewal

4.7Certificate Re-key

4.8Certificate Modification

4.9Certificate Revocation and Suspension

4.10Certificate Status Services

4.11End of Subscription

4.12Key Escrow and Recovery

5.Facility, Management, and Operational Controls

All entities performing CA functions shall implement and enforce the following physical, procedural, logical, and personnel security controls for a CA.

5.1Physical Controls

CA equipment shall be protected from unauthorized access while the cryptographic module is installed and activated. The CA shall implement physical access controls to reduce the risk of equipment tampering even when the cryptographic module is not installed and activated. CA cryptographic modules shall be protected against theft, loss, and unauthorized use.

All the physical control requirements specified below apply equally to the Root and subordinate CAs, and any remote workstations used to administer the CAs except where specifically noted.

5.1.1Site Location and Construction

All CA operations shall be conducted within a physically protected environment that deters, prevents, and detects unauthorized use of, access to, or disclosure of sensitive information and systems.Such environments are based in part on the establishment of physical security tiers. A tier is a barrier such as a locked door or closed gate that provides mandatory access control for individuals and requires a positive response (e.g., door unlocks or gate opens) for each individual to proceed to the next area. Each successive tier provides more restricted access and greater physical security against intrusion or unauthorized access. Moreover, each physical security tier encapsulates the next inner tier, such that an inner tier must be fully contained in an outside tier and cannot have a common outside wall with the outside tier, the outermost tier being the outside barrier of the building (e.g., a perimeter fence or outside wall).

The location and construction of the facility housing the CA equipment, as well as sites housing remote workstations used to administer the CAs, shall be consistent with facilities used to house high-value, sensitive information. The site location and construction, when combined with other physical security protection mechanisms such as guards, high security locks, and intrusion sensors, shall provide robust multi-tier protection against unauthorized access to the CA equipment and records.

5.1.2Physical Access for CA Equipment

The physical access controls for CA equipment, as well as remote workstations used to administer the CAs, shall be auditable and:

  • Ensure that no unauthorized access to the hardware is permitted.
  • Ensure that all removable media and paper containing sensitive plain-text information is stored in secure containers.
  • Be manually or electronically monitored for unauthorized intrusion at all times.
  • Ensure an access log is maintained and inspected periodically.
  • Require two-person physical access control to both the cryptographic module and computer systems.

Removable cryptographic modules shall be deactivated prior to storage. When not in use, removable cryptographic modules and the activation information used to access or enable cryptographic modules shall be placed in secure containers. Activation data shall be either memorized or recorded and stored in a manner commensurate with the security afforded the cryptographic module, and shall not be stored with the cryptographic module or removable hardware associated with remote workstations used to administer the CA.

A security check of the facility housing the CA equipment or remote workstations used to administer the CAs shall occur if the facility is to be left unattended. At a minimum, the check shall verify the following:

  • The equipment is in a state appropriate to the current mode of operation (e.g., that cryptographic modules are in place when “open,” and secured when “closed,” and for the CA, that all equipment other than the repository is shut down).
  • Any security containers are properly secured.
  • Physical security systems (e.g., door locks, vent covers) are functioning properly.
  • The area is secured against unauthorized access.

A person or group of persons shall be made explicitly responsible for making such checks. When a group of persons is responsible, a log identifying the person performing a check at each instance shall be maintained. If the facility is not continuously attended, the last person to depart shall initial a sign-out sheet that indicates the date and time and asserts that all necessary physical protection mechanisms are in place and activated.

5.1.3Power and Air Conditioning

The CA facilities shall be equipped with primary and backup power systems to ensure continuous, uninterrupted access to electric power. Also, these facilities shall be equipped with primary and backup heating/ventilation/air conditioning systems for temperature control.

The CA facilities shall have backup capability sufficient to lock out input, finish any pending actions, and record the state of the equipment automatically before lack of power or air conditioning causes a shutdown. The repositories (containing CA certificates and CRLs) shall be provided with uninterrupted power sufficient for a minimum of 6 hours operation in the absence of commercial power, to maintain availability and avoid denial of service.

5.1.4Water Exposures

CA equipment shall be installed such that it preventsdamage from exposure to water. Potential water damage from fire prevention and protection measures (e.g., sprinkler systems) are excluded from this requirement.

5.1.5Fire Prevention and Protection

CA facilities shall be equipped and procedures shall be implemented, to prevent damaging exposure to flame or smoke.These measures shall meet all local applicable safety regulations.

5.1.6Media Storage

CA Media shall be stored so as to protect them from accidental damage (e.g., water, fire, or electromagnetic) and unauthorized physical access. Media that contains audit, archive, or backup information shall be duplicated and stored in a location separate from the CA location.

5.1.7Waste Disposal

Sensitive media and documentation that are no longer needed for operations shall be destroyed in a secure manner. For example, sensitive paper documentation shall be shredded, burned, or otherwise rendered unrecoverable.

5.1.8Off-Site Backup

Full system backups sufficient to recover from system failure shall be made on a periodic schedule, and described in a CA’s CPS. Backups are to be performed and stored off-site not less than once per week, unless the CA is off-line, in which case, it shall be backed up whenever it is activated or every 7 days, whichever is later. At least one full backup copy shall be stored at an off-site location (separate from CA equipment). Only the latest full backup need be retained. The backup shall be stored at a site with physical and procedural controls commensurate to that of the operational CA.

Requirements for CA private key backup are specified in section 6.2.4.

5.2Procedural Controls

5.2.1Trusted Roles

A trusted role is one whose incumbent performs functions that can introduce security problems if not carried out properly, whether accidentally or maliciously. The people selected to fill these roles must be extraordinarily responsible, or the integrity of the CA will be weakened. The functions performed in these roles form the basis of trust for the entire PKI. Two approaches are taken to increase the likelihood that these roles can be successfully carried out. The first ensures that the person filling the role is trustworthy and properly trained. The second distributes the functions among more than one person, so that any malicious activity would require collusion.

The roles are defined as:

  1. Administrator – authorized to install, configure, and maintain the CA; establish and maintain system accounts; configure audit parameters; and generate component keys.
  2. Officer – authorized to request or approve certificate issuance and revocations.
  3. Auditor – authorized to review, maintain, and archive audit logs.
  4. Operator – authorized to perform system backup and recovery.

Administrators do not issue certificates to subscribers.