WiMAX Forum® Network Architecture
AeroMACS PKI Certificate Policy
DRAFT-T32-006-R010v01-D
Draft Specification
(2015-11-23)
WiMAX Forum Proprietary
Copyright © 2015 WiMAX Forum. All Rights Reserved.
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
Copyright Notice, Use Restrictions, Disclaimer, and Limitation of Liability
Copyright 2015 WiMAX 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 use by 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
FORUM DOES 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.
59
Page - i
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
Document Status
1
WiMAX Forum Document ID:
Document Title:
T32-006-R010-v01
AeroMACS PKI Certificate Policy
Status:
Distribution Restrictions:
2
Work in
Progress
Draft
Issued
Closed
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
3
4
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.
Page - ii
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
TABLE OF CONTENTS
2
WIMAX FORUM® NETWORK ARCHITECTURE ...............................................................................I
3
1.
INTRODUCTION ........................................................................................................................... 8
4
5
6
7
8
9
10
Overview ........................................................................................................................................ 8
Document Name and Identification ............................................................................................... 8
PKI Participants.............................................................................................................................. 8
Certificate Usage ............................................................................................................................ 8
Policy Administration..................................................................................................................... 8
Definitions and Acronyms.............................................................................................................. 8
2.
INTRODUCTION ........................................................................................................................... 9
11
12
13
14
15
Repositories .................................................................................................................................... 9
Publication of Certification Information ........................................................................................ 9
Time or Frequency of Publication .................................................................................................. 9
Access Controls on Repositories .................................................................................................... 9
3.
IDENTIFICATION AND AUTHENTICATION ....................................................................... 10
16
17
18
19
20
Naming ......................................................................................................................................... 10
Initial Identity Validation ............................................................................................................. 10
Identification and Authentication for Re-key Requests ............................................................... 10
Identification and Authentication for Revocation Request .......................................................... 10
4.
CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS ................................... 11
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
Certificate Application ................................................................................................................. 11
Certificate Application Processing ............................................................................................... 11
Certificate Issuance ...................................................................................................................... 11
Certificate Acceptance ................................................................................................................. 11
Key Pair and Certificate Usage .................................................................................................... 11
Certificate Renewal ...................................................................................................................... 11
Certificate Re-key......................................................................................................................... 11
Certificate Modification ............................................................................................................... 11
Certificate Revocation and Suspension ........................................................................................ 11
Certificate Status Services ............................................................................................................ 11
End of Subscription ...................................................................................................................... 11
Key Escrow and Recovery ........................................................................................................... 11
5.
FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS ..................................... 12
5.1.1
5.1.2
5.1.3
5.1.4
5.1.5
Physical Controls.......................................................................................................................... 12
Site Location and Construction .................................................................................................... 12
Physical Access for CA Equipment ............................................................................................. 12
Power and Air Conditioning......................................................................................................... 13
Water Exposures .......................................................................................................................... 13
Fire Prevention and Protection ..................................................................................................... 13
Page - iii
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
5.1.6 Media Storage .............................................................................................................................. 13
5.1.7 Waste Disposal ............................................................................................................................. 13
5.1.8 Off-Site Backup............................................................................................................................ 13
Procedural Controls ...................................................................................................................... 13
5.2.1 Trusted Roles................................................................................................................................ 13
5.2.2 Number of Persons Required per Task......................................................................................... 14
5.2.3 Identification and Authentication for Each Role .......................................................................... 15
5.2.4 Roles Requiring Separation of Duties .......................................................................................... 15
Personnel Controls ....................................................................................................................... 15
5.3.1 Qualifications, Experience, and Clearance Requirements............................................................ 15
5.3.2 Background Check Procedures .................................................................................................... 15
5.3.3 Training Requirements ................................................................................................................. 16
5.3.4 Retraining Frequency and Requirements ..................................................................................... 16
5.3.5 Job Rotation Frequency and Sequence ......................................................................................... 16
5.3.6 Sanctions for Unauthorized Actions............................................................................................. 16
5.3.7 Independent Contractor Requirements ......................................................................................... 16
5.3.8 Documentation Supplied to Personnel ......................................................................................... 17
Audit Logging Procedures............................................................................................................ 17
5.4.1 Types of Events Recorded ............................................................................................................ 17
5.4.2 Frequency of Processing Log ....................................................................................................... 19
5.4.3 Retention Period for Audit Log .................................................................................................... 19
5.4.4 Protection of Audit Log................................................................................................................ 19
5.4.5 Audit Log Backup Procedures ..................................................................................................... 19
5.4.6 Audit Collection System (Internal vs. External) .......................................................................... 19
5.4.7 Notification to Event-Causing Subject ......................................................................................... 20
5.4.8 Vulnerability Assessments ........................................................................................................... 20
Records Archival .......................................................................................................................... 20
5.5.1 Types of Events Archived ............................................................................................................ 20
5.5.2 Retention Period for Archive ....................................................................................................... 20
5.5.3 Protection of Archive ................................................................................................................... 21
5.5.4 Archive Backup Procedures ......................................................................................................... 21
5.5.5 Requirements for Time-Stamping of Records.............................................................................. 21
5.5.6 Archive Collection System (Internal or External) ........................................................................ 21
5.5.7 Procedures to Obtain and Verify Archive Information ................................................................ 21
Key Changeover ........................................................................................................................... 21
Compromise and disaster recovery .............................................................................................. 21
5.7.1 Incident and Compromise Handling Procedures .......................................................................... 21
5.7.2 Computing Resources, Software, and/or Data Are Corrupted ..................................................... 22
5.7.3 Entity (CA) Private Key Compromise Procedures ....................................................................... 22
5.7.4 Business Continuity Capabilities after a Disaster ........................................................................ 22
CA Termination............................................................................................................................ 22
6.
TECHNICAL SECURITY CONTROLS .................................................................................... 23
6.1.1
6.1.2
6.1.3
6.1.4
6.1.5
6.1.6
Key Pair Generation and Installation ........................................................................................... 23
Key Pair Generation ..................................................................................................................... 23
Private Key Delivery to Subscriber .............................................................................................. 23
Public Key Delivery to Certificate Issuer ..................................................................................... 24
CA Public Key Delivery to Relying Parties ................................................................................. 24
Key Sizes ...................................................................................................................................... 24
Public Key Parameters Generation and Quality Checking ........................................................... 24
Page - iv
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
6.1.7 Key Usage Purposes (as per X.509 v3 Key Usage Field) ............................................................ 24
Private Key Protection and Cryptographic Module Engineering Controls ................................. 27
6.2.1 Cryptographic Module Standards and Controls ........................................................................... 27
6.2.2 Private Key (n out of m) Multi-Person Control............................................................................ 27
6.2.3 Private Key Escrow ...................................................................................................................... 28
6.2.4 Private Key Backup ...................................................................................................................... 28
6.2.5 Private Key Archival .................................................................................................................... 28
6.2.6 Private Key Transfer into or from a Cryptographic Module ........................................................ 28
6.2.7 Private Key Storage on Cryptographic Module ........................................................................... 29
6.2.8 Method of Activating Private Key ............................................................................................... 29
6.2.9 Method of Deactivating Private Key ............................................................................................ 29
6.2.10 Method of Destroying Private Key .............................................................................................. 30
6.2.11 Cryptographic Module Rating ...................................................................................................... 30
Other Aspects of Key Pair Management ...................................................................................... 30
6.3.1 Public Key Archival ..................................................................................................................... 30
6.3.2 Certificate Operational Periods and Key Pair Usage Periods....................................................... 30
Activation data ............................................................................................................................. 30
6.4.1 Activation Data Generation and Installation ................................................................................ 30
6.4.2 Activation Data Protection ........................................................................................................... 31
6.4.3 Other Aspects of Activation Data ................................................................................................ 31
Computer security controls .......................................................................................................... 31
6.5.1 Specific Computer Security Technical Requirements .................................................................. 31
6.5.2 Computer Security Rating ............................................................................................................ 32
Life Cycle Technical Controls ..................................................................................................... 32
6.6.1 System Development Controls ..................................................................................................... 32
6.6.2 Security Management Controls .................................................................................................... 33
6.6.3 Life Cycle Security Controls ........................................................................................................ 33
Network Security Controls ........................................................................................................... 33
Time-Stamping ............................................................................................................................. 33
7.
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
CERTIFICATE, CRL, AND OCSP PROFILES ........................................................................ 34
7.1.1
7.1.2
7.1.3
7.1.4
7.1.5
7.1.6
7.1.7
7.1.8
7.1.9
7.2.1
7.2.2
7.3.1
7.3.2
8.
Certificate Profile ......................................................................................................................... 34
Version Number(s) ....................................................................................................................... 34
Certificate Extensions................................................................................................................... 35
Algorithm Object Identifiers (OIDs) ............................................................................................ 38
Name Forms ................................................................................................................................. 39
Name Constraints ......................................................................................................................... 41
Certificate Policy Object Identifier .............................................................................................. 41
Usage of Policy Constraints Extension ........................................................................................ 41
Policy Qualifiers Syntax and Semantics ...................................................................................... 41
Processing Semantics for the Critical Certificate Policies Extension .......................................... 41
CRL Profile .................................................................................................................................. 41
Version Number(s) ....................................................................................................................... 42
CRL and CRL entry extensions.................................................................................................... 42
OCSP Profile ................................................................................................................................ 42
Version Number(s) ....................................................................................................................... 42
OCSP Extensions ......................................................................................................................... 42
COMPLIANCE AUDIT AND OTHER ASSESSMENTS ......................................................... 43
Frequency or Circumstances of Assessment ................................................................................ 43
Page - v
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
2
3
4
5
6
Identity/Qualifications of Assessor .............................................................................................. 43
Assessor's Relationship to Assessed Entity .................................................................................. 43
Topics Covered by Assessment .................................................................................................... 43
Actions Taken as a Result of Deficiency ..................................................................................... 43
Communication of Results ........................................................................................................... 44
9.
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
OTHER BUSINESS AND LEGAL MATTERS ......................................................................... 45
Fees............................................................................................................................................... 45
Financial Responsibility ............................................................................................................... 45
Confidentiality of business information ....................................................................................... 45
Privacy of Personal Information................................................................................................... 45
Intellectual Property Rights .......................................................................................................... 45
Representations and Warranties ................................................................................................... 45
Disclaimers of warranties ............................................................................................................. 45
Limitations of liability .................................................................................................................. 45
Indemnities ................................................................................................................................... 45
Term and termination ................................................................................................................... 45
Individual notices and communications with participants ........................................................... 45
Amendments................................................................................................................................. 45
Dispute Resolution Provisions ..................................................................................................... 45
Governing Law ............................................................................................................................. 45
Compliance with Applicable Law ................................................................................................ 45
Miscellaneous provisions ............................................................................................................. 45
Other Provisions ........................................................................................................................... 45
24
10.
REFERENCES .............................................................................................................................. 46
25
11.
GLOSSARY ................................................................................................................................... 47
26
12.
ABBREVIATIONS AND ACRONYMS ..................................................................................... 50
27
28
29
TABLE OF FIGURES (If applicable)
30
31
32
TABLE OF TABLES
33
34
35
36
37
38
39
40
41
42
TABLE 1: ALGORITHM TYPE AND KEY SIZE ................................................................................... 24
TABLE 2: KEYUSAGE EXTENSION FOR ALL CA CERTIFICATES ................................................. 25
TABLE 3: KEYUSAGE EXTENSION FOR ALL SUBSCRIBER SIGNATURE CERTIFICATES....... 25
TABLE 4: KEYUSAGE EXTENSION FOR ALL KEY MANAGEMENT CERTIFICATES................. 26
TABLE 5: KEYUSAGE EXTENSION FOR ALL SERVER CERTIFICATES ...................................... 27
TABLE 6: CERTIFICATE PROFILE BASIC FIELDS ............................................................................. 34
TABLE 7: ROOT CA CERTIFICATE STANDARD EXTENSIONS ...................................................... 35
TABLE 8: SUB-CA CERTIFICATE STANDARD EXTENSIONS ......................................................... 35
TABLE 9: SUBSCRIBER CERTIFICATE STANDARD EXTENSIONS ............................................... 36
Page - vi
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
TABLE 10: OCSP CERTIFICATE STANDARD EXTENSIONS ............................................................ 36
TABLE 11: SUBJECTKEYIDENTIFIER EXTENSION FOR AEROMACS CA CERTIFICATES ....... 37
TABLE 12: BASICCONSTRAINTS EXTENSION FOR AEROMACS ROOT CA CERTIFICATES ... 37
TABLE 13: BASICCONSTRAINTS EXTENSION FOR AEROMACS SUB-CA CERTIFICATES ...... 37
TABLE 14: EXTKEYUSAGE EXSTENSION FOR AEROMACS SERVER CERTIFICATES ............... 38
TABLE 15: EXTKEYUSAGE EXSTENSION FOR AEROMACS CLIENT CERTIFICATES ................ 38
TABLE 16: SIGNATURE OIDS FOR CERTIFICATES .......................................................................... 38
TABLE 17: SUBJECTPUBLICKEYINFO FOR CERTIFICATE ............................................................. 39
TABLE 18: ROOT CA CERTIFICATE ISSUER AND SUBJECT FIELDS ............................................ 39
TABLE 19: SUB-CA CERTIFICATE SUBJECT FIELDS ....................................................................... 40
TABLE 20: SUBSCRIBER CERTIFICATE SUBJECT FIELDS ............................................................. 40
TABLE 21: CERTIFICATEPOLICIES EXTENSION FOR AEROMACS CERTIFICATES.................. 41
TABLE 22: CRL PROFILE BASIC FIELDS ............................................................................................ 41
Page - vii
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
1. Introduction
2
Overview
3
Document Name and Identification
4
PKI Participants
5
Certificate Usage
6
Policy Administration
7
Definitions and Acronyms
Page - 8
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
2. Introduction
2
Repositories
3
Publication of Certification Information
4
Time or Frequency of Publication
5
Access Controls on Repositories
6
Page - 9
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
3. Identification and Authentication
2
Naming
3
Initial Identity Validation
4
Identification and Authentication for Re-key Requests
5
Identification and Authentication for Revocation Request
6
Page - 10
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
4. Certificate Life-cycle Operational Requirements
2
Certificate Application
3
Certificate Application Processing
4
Certificate Issuance
5
Certificate Acceptance
6
Key Pair and Certificate Usage
7
Certificate Renewal
8
Certificate Re-key
9
Certificate Modification
10
Certificate Revocation and Suspension
11
Certificate Status Services
12
End of Subscription
13
Key Escrow and Recovery
14
Page - 11
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
5. Facility, Management, and Operational Controls
2
3
All entities performing CA functions shall implement and enforce the following physical, procedural, logical, and
personnel security controls for a CA.
Physical Controls
4
5
6
7
8
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.
9
10
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.
11
5.1.1 Site Location and Construction
12
13
14
15
16
17
18
19
20
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).
21
22
23
24
25
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.
26
5.1.2 Physical Access for CA Equipment
27
28
The physical access controls for CA equipment, as well as remote workstations used to administer the CAs, shall be
auditable and:
29
30
31
32
33
34





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.
35
36
37
38
39
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.
40
41
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:
42
43
44
45


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.
Page - 12
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
2


Physical security systems (e.g., door locks, vent covers) are functioning properly.
The area is secured against unauthorized access.
3
4
5
6
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.
7
5.1.3 Power and Air Conditioning
8
9
10
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.
11
12
13
14
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.
15
5.1.4 Water Exposures
16
17
CA equipment shall be installed such that it prevents damage from exposure to water. Potential water damage from
fire prevention and protection measures (e.g., sprinkler systems) are excluded from this requirement.
18
5.1.5
19
20
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.
21
5.1.6
22
23
24
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.
25
5.1.7
26
27
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.
28
5.1.8
29
30
31
32
33
34
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.
35
Requirements for CA private key backup are specified in section 6.2.4.
Fire Prevention and Protection
Media Storage
Waste Disposal
Off-Site Backup
Procedural Controls
36
37
5.2.1
Trusted Roles
38
39
40
41
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
Page - 13
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
2
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.
3
The roles are defined as:
4
5
1.
Administrator – authorized to install, configure, and maintain the CA; establish and maintain system
accounts; configure audit parameters; and generate component keys.
6
2.
Officer – authorized to request or approve certificate issuance and revocations.
7
3.
Auditor – authorized to review, maintain, and archive audit logs.
8
4.
Operator – authorized to perform system backup and recovery.
9
Administrators do not issue certificates to subscribers.
10
11
12
The roles required for each level of assurance are identified in Section 5.2.4. These four roles are employed at the
CA and Sub-CA locations as appropriate. Separation of duties shall comply with 5.2.4, and requirements for three
person control with 5.2.2, regardless of the titles and numbers of Trusted Roles.
13
5.2.1.1 Administrator
14
The Administrator shall be responsible for:
15
16
17
18




Installation, configuration, and maintenance of the CA.
Establishing and maintaining CA system accounts.
Configuring certificate profiles or templates and audit parameters.
Generating and backing up CA keys.
19
5.2.1.2 Officer
20
The Officer shall be responsible for issuing certificates, that is:
21
22
23
24




Registering new subscribers and requesting the issuance of certificates.
Verifying the identity of subscribers and accuracy of information included in certificates.
Approving and executing the issuance of certificates.
Requesting, approving, and executing the revocation of certificates.
25
5.2.1.3 Audit Administrator
26
The Audit Administrator shall be responsible for:
27
28
29


Reviewing, maintaining, and archiving audit logs.
Performing or overseeing internal compliance audits to ensure that the CA is operating in accordance with
the CPS.
30
5.2.1.4 Operator
31
32
The operator shall be responsible for the routine operation of the CA equipment and operations such as system
backups and recovery or changing recording media.
33
5.2.2
34
35
36
37
38
39
Multiparty control procedures are designed to ensure that at a minimum, the desired number of trusted personnel are
present to gain either physical or logical access to the CA. Access to CA cryptographic modules shall be strictly
enforced by multiple Trusted Persons throughout its lifecycle, from incoming receipt and inspection to final logical
and/or physical destruction. Once a CA device is activated with operational keys, further access controls shall be
invoked to maintain split control over both physical and logical access to the device. Persons with physical access to
CA modules do not hold credentials to activate the CA and vice versa
40
Three or more persons are required for the following tasks:
41
42


Number of Persons Required per Task
CA key generation;
CA signing key activation;
Page - 14
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1

CA private key backup.
2
3
4
Where multiparty control is required, at least one of the participants shall be an Administrator. All participants must
serve in a trusted role as defined in section 5.2.1. Multiparty control shall not be achieved using personnel that serve
in the Auditor trusted role.
5
5.2.3
6
7
An individual shall identify and authenticate him/herself before being permitted to perform any actions set forth
above for that role or identity.
8
9
An individual in a trusted role shall authenticate to remote components of the PKI using a method commensurate
with the strength of the PKI.
Identification and Authentication for Each Role
10
5.2.4
Roles Requiring Separation of Duties
11
12
13
14
15
Individuals may only assume one of the following roles: Officer, Administrator, and Auditor, but any individual
may assume the Operator role. The CA and Sub-CA software and hardware shall identify and authenticate its users
and shall ensure that no user identity can assume both the Administrator and Officer roles, assume both the
Administrator and Auditor roles, or assume both the Auditor and Officer roles. No individual shall have more than
one identity.
Personnel Controls
16
17
5.3.1
18
19
20
21
CAs shall require that personnel assigned to Trusted roles have the requisite background, qualifications, and
experience or be provided the training needed to perform their prospective job responsibilities competently and
satisfactorily. The requirements governing the qualifications, selection and oversight of individuals who operate,
manage, oversee, and audit the CA shall be set forth in the CPS.
22
23
All persons filling trusted roles shall be selected on the basis of loyalty, trustworthiness, and integrity, and shall be
subject to a background investigation. Personnel appointed to trusted roles shall:
24
25
26
27
28
29
30
31






Qualifications, Experience, and Clearance Requirements
Have successfully completed an appropriate training program.
Have demonstrated the ability to perform their duties.
Be trustworthy.
Have no other duties that would interfere or conflict with their duties for the trusted role.
Have not been previously relieved of duties for reasons of negligence or non-performance of duties.
Have not been convicted of a felony offense.
For PKIs operated at medium-software, medium-hardware, and/or high-hardware, each person filling a trusted role
shall satisfy at least one of the following requirements:
32
33
34
35
36
37
38
39


40
5.3.2
41
CA personnel shall, at a minimum, pass a background investigation covering the following areas:
42
43




The person shall be a citizen of the country where the CA is located; or
For PKIs operated on behalf of multinational government organizations, the person shall be a citizen of one
of the member countries; or
For PKIs located within the European Union, the person shall be a citizen of one of the member states of
the European Union; or
The person shall have a security clearance equivalent to U.S. Secret or higher issued by a NATO member
nation or major non-NATO ally as defined by the International Traffic in Arms Regulation (ITAR) – 22
CFR 120.32.
Background Check Procedures
Confirmation of previous employment;
Confirmation of the highest or most relevant educational degree;
Page - 15
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
2
3
4
5
6
7
8
9
10
11
12
13
14




Place of residence;
Search of criminal records
Check of references
Check of credit/financial records
The period of investigation must cover at least the last five years for each area, excepting the residence check which
must cover at least the last three years. Regardless of the date of award, the highest educational degree shall be
verified.
Factors revealed in a background check that may be considered grounds for rejecting candidates for Trusted
Positions or for taking action against an existing Trusted Person may include but is not limited to the following:




Misrepresentations made by the candidate or Trusted Person
Highly unfavorable or unreliable personal references
Certain criminal convictions
Indications of a lack of financial responsibility
15
The results of these checks shall not be released except as required in Sections 9.3 and 9.4.
16
17
18
If a formal clearance or other check is the basis for background check, the background refresh shall be in accordance
with the corresponding formal clearance or other check. Otherwise, the background check shall be refreshed every
ten years.
19
5.3.3 Training Requirements
20
21
All personnel performing duties with respect to the operation of the CA or Sub0CA shall receive comprehensive
training. Training shall be conducted in the following areas:
22
23
24
25
26





CA (or Sub-CA) security principles and mechanisms;
All PKI software versions in use on the CA (or Sub-CA) system;
All PKI duties they are expected to perform;
Disaster recovery and business continuity procedures; and
Stipulations of this policy.
27
5.3.4 Retraining Frequency and Requirements
28
29
30
31
All individuals responsible for PKI roles shall be made aware of changes in the CA operation. Any significant
change to the operations shall have a training (awareness) plan, and the execution of such plan shall be documented.
Examples of such changes are CA software or hardware upgrade, changes in automated security systems, and
relocation of equipment.
32
33
Documentation shall be maintained identifying all personnel who received training and the level of training
completed.
34
5.3.5 Job Rotation Frequency and Sequence
35
No stipulation.
36
5.3.6 Sanctions for Unauthorized Actions
37
38
The CA shall take appropriate administrative and disciplinary actions against personnel who have performed actions
involving the CA or its Sub-CAs that are not authorized in this CP, CPSs, or other published procedures.
39
5.3.7 Independent Contractor Requirements
40
Contractors fulfilling trusted roles are subject to all personnel requirements stipulated in this policy.
41
42
PKI vendors who provide any services shall establish procedures to ensure that any subcontractors perform in
accordance with this policy and the CPS.
Page - 16
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
5.3.8
2
3
Documentation sufficient to define duties and procedures for each role shall be provided to the personnel filling that
role.
Audit Logging Procedures
4
5
6
7
8
9
Documentation Supplied to Personnel
Audit log files shall be generated for all events relating to the security of the CA. Where possible, the security audit
logs shall be automatically collected. Where this is not possible, a logbook, paper form, or other physical mechanism
shall be used. All security audit logs, both electronic and non-electronic, shall be retained and made available during
compliance audits. The security audit logs for each auditable event defined in this section shall be maintained in
accordance with Section 5.5.2.
10
5.4.1
11
12
13
All security auditing capabilities of CA operating system and CA applications required by this CP shall be enabled
during installation. At a minimum, each audit record shall include the following (either recorded automatically or
manually for each auditable event):
14
15
16
17
18





Types of Events Recorded
The type of event;
The date and time the event occurred;
A success or failure indicator when executing the CA’s signing process;
A success or failure indicator when performing certificate revocation; and
The identity of the entity and/or operator that caused the event.
19
20
A message from any source requesting an action by the CA is an auditable event; the corresponding audit record
must also include message date and time, source, destination, and contents.
21
22
The CA shall record the events identified in the list below. Where these events cannot be electronically logged, the
CA shall supplement electronic audit logs with physical logs as necessary.
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48









SECURITY AUDIT:
o Any changes to the Audit parameters, e.g., audit frequency, type of event audited
o Any attempt to delete or modify the Audit logs
o Obtaining a third-party time-stamp
IDENTIFICATION AND AUTHENTICATION:
o Successful and unsuccessful attempts to assume a role
o The value of maximum authentication attempts is changed
o Maximum authentication attempts unsuccessful authentication attempts occur during user login
o An Administrator unlocks an account that has been locked as a result of unsuccessful
authentication attempts
o An Administrator changes the type of authentication, e.g., from a password to biometric
LOCAL DATA ENTRY:
o All security-relevant data that is entered in the system
REMOTE DATA ENTRY:
o All security-relevant messages that are received by the system
DATA EXPORT AND OUTPUT:
o All successful and unsuccessful requests for confidential and security-relevant information
KEY GENERATION:
o Whenever the Component generates a key. (Not mandatory for single session or one-time use
symmetric keys)
PRIVATE KEY LOAD AND STORAGE:
o The loading of Component private keys
o All access to certificate subject private keys retained within the CA for key recovery purposes
TRUSTED PUBLIC KEY ENTRY, DELETION AND STORAGE:
o All changes to the trusted public keys, including additions and deletions
SECRET KEY STORAGE:
Page - 17
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55












o The manual entry of secret keys used for authentication
PRIVATE AND SECRET KEY EXPORT:
o The export of private and secret keys (keys used for a single session or message are excluded)
CERTIFICATE REGISTRATION:
o All certificate requests
CERTIFICATE REVOCATION:
o All certificate revocation requests
CERTIFICATE STATUS CHANGE APPROVAL:
o The approval or rejection of a certificate status change request
CA CONFIGURATION:
o Any security-relevant changes to the configuration of the Component
ACCOUNT ADMINISTRATION:
o Roles and users are added or deleted
o The access control privileges of a user account or a role are modified
CERTIFICATE PROFILE MANAGEMENT:
o All changes to the certificate profile
REVOCATION PROFILE MANAGEMENT:
o All changes to the revocation profile
CERTIFICATE STATUS AUTHORITY MANAGEMENT:
o All changes to the OCSP profile
MISCELLANEOUS:
o Appointment of an individual to a trusted role
o Designation of personnel for multiparty control
o Installation of the operating system
o Installation of the PKI Application
o Installing hardware cryptographic modules
o Removing hardware cryptographic modules
o Destruction of cryptographic modules
o System startup
o Logon attempts to PKI applications
o Receipt of hardware / software
o Attempts to set passwords
o Attempts to modify passwords
o Backing up CA internal database
o Restoring CA internal database
o Restoration from backup of the internal CA database
o File manipulation (e.g., creation, renaming, moving)
o Posting of any material to a PKI repository
o Access to CA internal database
o All certificate compromise notification requests
o Loading tokens with certificates
o Shipment of tokens
o Zeroizing and destroying tokens
o Re-key of the Component
o Configuration changes:
 Hardware
 Software
 Operating system
 Patches
 Security profiles
PHYSICAL ACCESS / SITE SECURITY:
o Personnel access to room housing Component
o Access to the Component
o Known or suspected violations of physical security
ANOMALIES:
Page - 18
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
o
o
o
o
o
o
o
o
o
o
o
o
1
2
3
4
5
6
7
8
9
10
11
12
Software error conditions
Software check integrity failures
Receipt of improper messages
Misrouted messages
Network attacks (suspected or confirmed)
Equipment failure
Electrical power outages
Uninterruptible power supply (UPS) failure
Obvious and significant network service or access failures
Violations of Certificate Policy
Violations of Certification Practice Statement
Resetting Operating System clock
13
5.4.2
Frequency of Processing Log
14
15
Audit logs shall be reviewed at least once every 30 days, unless the CA is off-line, in which case the audit logs shall
be reviewed when the system is activated or every 30 days, whichever is later.
16
17
18
19
Such reviews involve verifying that the log has not been tampered with and then briefly inspecting all log entries,
with a more thorough investigation of any alerts or irregularities in the logs. A statistically significant portion of the
security audit data generated by the CA since the last review shall be examined. This amount will be described in the
CPS.
20
21
All significant events shall be explained in an audit log summary. Actions taken as a result of these reviews shall be
documented.
22
5.4.3 Retention Period for Audit Log
23
24
25
Audit logs shall be retained on-site until reviewed, in addition to being archived as described in section 5.5. The
individual who removes audit logs from the CA system shall be an official different from the individuals who, in
combination, command the CA signature key.
26
5.4.4 Protection of Audit Log
27
28
29
30
31
32
The security audit data shall not be open for reading or modification by any human, or by any automated process,
other than those that perform security audit processing. CA system configuration and procedures must be
implemented together to ensure that only authorized people archive or delete security audit data. Procedures must be
implemented to protect archived data from deletion or destruction before the end of the security audit data retention
period (note that deletion requires modification access). Security audit data shall be moved to a safe, secure storage
location separate from the location where the data was generated.
33
5.4.5 Audit Log Backup Procedures
34
35
Audit logs and audit summaries shall be backed up at least monthly. A copy of the audit log shall be sent off-site on
a monthly basis.
36
5.4.6 Audit Collection System (Internal vs. External)
37
38
39
40
41
42
The audit log collection system may or may not be external to the CA system. Automated audit processes shall be
invoked at system or application startup, and cease only at system or application shutdown. Audit collection systems
shall be configured such that security audit data is protected against loss (e.g., overwriting or overflow of automated
log files). Should it become apparent that an automated audit system has failed, and the integrity of the system or
confidentiality of the information protected by the system is at risk, operations shall be suspended until the problem
has been remedied.
Page - 19
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
5.4.7 Notification to Event-Causing Subject
2
3
There is no requirement to notify a subject that an event was audited. Real-time alerts are neither required nor
prohibited by this policy.
4
5.4.8 Vulnerability Assessments
5
6
7
8
The CA shall perform routine self-assessments of security controls for vulnerabilities. Events in the audit process are
logged, in part, to monitor system vulnerabilities. The assessments shall be performed following an examination of
these monitored events. The assessments shall be based on real-time automated logging data and shall be performed
at least on an annual basis as input into an entity’s annual Compliance Audit.
9
10
11
The audit data should be reviewed by the security auditor for events such as repeated failed actions, requests for
privileged information, attempted access of system files, and unauthenticated responses. Security auditors should
check for continuity of the audit data.
Records Archival
12
13
5.5.1 Types of Events Archived
14
15
16
CA archive records shall be sufficiently detailed to determine the proper operation of the CA and the validity of any
certificate (including those revoked or expired) issued by the CA. At a minimum, the following data shall be
recorded for archive:
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
























Certificate policy
Certification practice statement
Contractual obligations and other agreements concerning operations of the CA
System and equipment configuration
Modifications and updates to system or configuration
Certificate requests
All certificates issued and/or published
Record of CA re-key
Revocation requests
Subscriber identity authentication data as per section 3.2.3.
Documentation of receipt and acceptance of certificates (if applicable)
Subscriber agreements
Documentation of receipt of tokens
All CRLs issued and/or published
Other data or applications to verify archive contents
Compliance Auditor reports
Any changes to the Audit parameters, e.g. audit frequency, type of event audited
Any attempt to delete or modify the Audit logs
Whenever the CA generates a key (Not mandatory for single session or one-time use symmetric keys)
The export of private and secret keys (keys used for a single session or message are excluded)
The approval or rejection of a certificate status change request
Appointment of an individual to a Trusted Role
Destruction of cryptographic modules
All certificate compromise notifications
41
5.5.2 Retention Period for Archive
42
Archive records must be kept for a minimum of 10 years and 6 months.
Page - 20
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
5.5.3 Protection of Archive
2
3
4
5
6
7
No unauthorized user shall be permitted to write to, modify, or delete the archive. For the CA, archived records may
be moved to another medium. The contents of the archive shall not be released except in accordance with sections
9.3 and 9.4. Records of individual transactions may be released upon request of any subscribers involved in the
transaction or their legally recognized agents. Archive media shall be stored in a safe, secure storage facility separate
from the CA. Archive media shall be stored in a safe, secure storage facility separate from the PKI components with
physical and procedural security controls equivalent or better than those of the PKI.
8
5.5.4 Archive Backup Procedures
9
No stipulation.
10
5.5.5 Requirements for Time-Stamping of Records
11
12
CA archive records shall be automatically time-stamped as they are created. The CPS shall describe how system
clocks used for time-stamping are maintained in synchrony with an authoritative time standard.
13
5.5.6 Archive Collection System (Internal or External)
14
No stipulation.
15
5.5.7 Procedures to Obtain and Verify Archive Information
16
17
Procedures, detailing how to create, verify, package, transmit, and store the CA archive information, shall be
published in the CPS.
18
Key Changeover
19
20
21
22
To minimize risk from compromise of a CA’s private signing key, that key may be changed often. From that time
on, only the new key will be used to sign CA and subscriber certificates. If the old private key is used to sign OCSP
responder certificates or CRLs that cover certificates signed with that key, the old key must be retained and
protected.
23
The CA’s signing key shall have a validity period as described in section 6.3.2.
24
25
26
27
28
29
When a CA updates its private signature key and thus generates a new public key, the CA shall notify all CAs, SubCAs, and subscribers that rely on the CA’s certificate that it has been changed. When a CA that distributes selfsigned certificates updates its private signature key, the CA shall generate key rollover certificates, where the new
public key is signed by the old private key, and vice versa. This permits acceptance of newly issued certificates and
CRLs without distribution of the new self-signed certificate to current users. Key rollover certificates are optional
for CAs that do not distribute self-signed certificates.
30
Compromise and disaster recovery
31
5.7.1 Incident and Compromise Handling Procedures
32
Each organization operating an Entity PKI shall have a formal disaster recovery plan.
33
34
35
36
37
38
39
40
The Policy Authority shall be notified if any CAs operating under this policy experience the following:
 suspected or detected compromise of the CA systems;
 suspected or detected compromise of a certificate status server (CSS) if (1) the CSS certificate has a
lifetime of more than 72 hours and (2) the CSS certificate cannot be revoked (e.g., an OCSP responder
certificate with the id-pkix-ocsp-nocheck extension);
 physical or electronic penetration of CA systems;
 successful denial of service attacks on CA components; or
 any incident preventing the CA from issuing a CRL within 48 hours of the issuance of the previous CRL.
41
The Policy Authority will take appropriate steps to protect the integrity of the PKI.
Page - 21
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
2
The CA’s Management Authority shall reestablish operational capabilities as quickly as possible in accordance with
procedures set forth in the CA's CPS.
3
5.7.2 Computing Resources, Software, and/or Data Are Corrupted
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
When computing resources, software, and/or data are corrupted, CAs operating under this policy shall respond as
follows:
 Before returning to operation, ensure that the system’s integrity has been restored.
 If the CA signature keys are not destroyed, CA operation shall be reestablished, giving priority to the
ability to generate certificate status information within the CRL issuance schedule specified in section 4.9.
 If the CA signature keys are destroyed, CA operation shall be reestablished as quickly as possible, giving
priority to the generation of a new CA key pair.
 If a CA cannot issue a CRL prior to the time specified in the next update field of its currently valid CRL,
then all CAs that have been issued certificates by the CA shall be securely notified immediately. This will
allow other CAs to protect their subscribers’’ interests as Relying Parties.
 If the ability to revoke certificates is inoperative or damaged, the CA shall reestablish revocation
capabilities as quickly as possible in accordance with procedures set forth in the respective CPS. If the
CA’s revocation capability cannot be established in a reasonable time-frame, the CA shall determine
whether to request revocation of its certificate(s). If the CA is a Root CA, the CA shall determine whether
to notify all subscribers that use the CA as a trust anchor to delete the trust anchor.
19
5.7.3 Entity (CA) Private Key Compromise Procedures
20
21
22
23
24
25
26
27
28
If a CA’s signature keys are compromised, lost, or suspected of compromise:
 All cross certified CAs shall be securely notified at the earliest feasible time (so that entities may issue
CRLs revoking any cross-certificates issued to the CA);
 The CA must generate new keys in accordance with section 6.1.1.1.
 If the CA distributed the private key in a Trusted Certificate, the CA shall perform the following
operations:
o Generate a new Trusted Certificate.
o Securely distribute the new Trusted Certificate as specified in section 6.1.4.
o Initiate procedures to notify subscribers of the compromise.
29
30
Subscriber certificates may be renewed automatically by the CA under the new key pair (see section 4.6), or the CA
may require subscribers to repeat the initial certificate application process.
31
5.7.4 Business Continuity Capabilities after a Disaster
32
33
34
In the case of a disaster whereby the CA installation is physically damaged and all copies of the CA signature key
are destroyed as a result, the CA shall request revocation of its certificates. Further, the CA shall re-establish
operations by following the procedures for CA key loss or compromise detailed in Section 5.7.3 above.
35
36
Relying parties may decide of their own volition whether to continue to use certificates signed with the destroyed
private key pending reestablishment of CA operation with new certificates.
37
CA Termination
38
39
When a CA operating under this policy terminates operations before all certificates have expired, the CA
signing keys shall be surrendered to the Policy Authority.
40
41
42
Prior to CA termination, the CA shall provide archived data as specified in the CPS. As soon as possible,
the CA will advise all other organizations to which it has issued certificates of its termination, using an
agreed-upon method of communication specified in the CPS.
43
Page - 22
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
6. TECHNICAL SECURITY CONTROLS
Key Pair Generation and Installation
2
3
6.1.1 Key Pair Generation
4
5
6
7
Key pair generation shall be performed using FIPS 140 approved cryptographic modules and processes that provide
the required cryptographic strength of the generated keys and prevent the loss, disclosure, modification, or
unauthorized use of private keys. Any pseudo-random numbers use and parameters for key generation material shall
be generated by a FIPS-approved method.
8
6.1.1.1 CA Key Pair Generation
9
10
11
12
Cryptographic keying material used by CAs to sign certificates, CRLs, or status information shall be generated in
FIPS 140 approved cryptographic modules that shall be at least FIPS 140 Level 3. Key pairs for Sub-CAs
requesting a medium-assurance hardware Certificate under this CP must be generated in a hardware cryptographic
module rated at least FIPS 140 Level 2.
13
14
CA keys shall be generated in a Key Generation Ceremony using multi-person control for CA key pair generation,
as specified in CP section 6.2.2.
15
16
17
18
CA key pair generation must create a verifiable audit trail that the security requirements for procedures were
followed. The documentation of the procedure must be detailed enough to show that appropriate role separation was
used. An independent third party shall validate the execution of the key generation procedures either by witnessing
the key generation or by examining the signed and documented record of the key generation.
19
6.1.1.2 Subscriber Key Pair Generation
20
21
22
Subscriber key pair generation may be performed by the subscriber, CA, or Sub-CA. If the CA or SubCA generates subscriber key pairs, the requirements for key pair delivery specified in section 6.1.2 must
also be met.
23
24
Key pairs for subscribers requesting a medium-assurance hardware certificate must be generated in a
hardware cryptographic module rated at least FIPS 140 Level 2.
25
26
27
NOTE: The ATA Specification states subscriber private keys will only be generated by the subscriber and never by
the CA. The Federal Bridge PKI CP allows end user key generation by the CA/RA. So this next section aligns with
the Federal Bridge policy (more flexible) but can be removed to follow the ATA Specification if desired.
28
6.1.2 Private Key Delivery to Subscriber
29
30
Subscriber key pair generation may be performed by the Subscriber. In this case, the private key delivery to a
Subscriber is unnecessary.
31
32
When CAs generate key pairs on behalf of the Subscriber, the private keys must be delivered securely to the
Subscriber and the following requirements must be met:
33
34
35
36
37
38
39
40
41
42
43





The CA shall not retain any copy of the key after delivery of the private key to the subscriber.
CAs shall use Trustworthy Systems to deliver private keys to Subscribers and shall secure such delivery
through the use of a PKCS#8 package or, at the CAs sole discretion, any other comparably equivalent
means (e.g., PKCS#12 package) in order to prevent the loss, disclosure, modification, or unauthorized use
of such private keys.
Where key pairs are pre-generated on hardware cryptographic modules, the entities distributing such
modules shall use best efforts to provide physical security of the modules to prevent the loss, disclosure,
modification, or unauthorized use of the private keys.
The subscriber shall acknowledge receipt of the private key(s).
Delivery shall be accomplished in a way that ensures that the certificates and associated private keys are
provided to the correct subscribers.
Page - 23
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
o
1
2
3
4
5
6
o
For hardware cryptographic modules, accountability for the location and state of the module must
be maintained until the subscriber accepts possession of it.
For electronic delivery of private keys, the key material shall be encrypted using a cryptographic
algorithm and key size at least as strong as the private key. Activation data shall be delivered using
a separate secure channel.
6.1.3 Public Key Delivery to Certificate Issuer
7
8
9
10
11
12
When a public key is transferred to the issuing CA to be certified, it shall be delivered through a mechanism
validating the identity of the Subscriber and ensuring that the public key has not been altered during transit and that
the Certificate Applicant possesses the private key corresponding to the transferred public key. The Certificate
Applicant shall deliver the public key in a PKCS#10 Certificate Signing Request package or an equivalent method
ensuring that the public key has not been altered during transit; and the Certificate Applicant possesses the private
key corresponding to the transferred public key.
13
6.1.4 CA Public Key Delivery to Relying Parties
14
15
CA public key certificates shall be delivered to relying parties in a secure fashion to preclude substitution attacks.
Acceptable methods for certificate delivery are:
16
17
18
19




Loading the CA certificate onto tokens delivered to relying parties via secure mechanisms.
The CA Certificate is delivered as part of a subscriber’s certificate request.
Secure distribution of CA certificates through secure out-of-band mechanisms.
Downloading the CA certificates from trusted web sites (CA or PKI-PA web site).
20
6.1.5 Key Sizes
21
22
Key pairs shall be of sufficient length to prevent others from determining the key pair’s private key using
cryptanalysis during the period of expected utilization of such key pairs.
23
AeroMACS certificates shall meet the following requirements for algorithm type and key size:
Table 1: Algorithm Type and Key Size
24
Root CA
Sub-CA
Device Cert
Digest Algorithm
SHA-256
SHA-256
SHA-256
Elliptic Curve
Cryptography
P-256, 384
P-256, 384
P-256
25
26
6.1.6 Public Key Parameters Generation and Quality Checking
27
28
Elliptic Curve Cryptography (ECC) public key parameters shall be selected from the set specified in CP section
7.1.3.
29
6.1.7 Key Usage Purposes (as per X.509 v3 Key Usage Field)
30
31
The use of a specific key is constrained by the key usage extension in the X.509 certificate. All certificates shall
include a critical key usage extension.
32
33
34
35
Public keys that are bound into CA certificates shall be used for signing certificates and status information (e.g.,
CRLs). Table 2 shows the specific keyUsage extension settings for AeroMACS CA certificates and specifies that
all AeroMACS CA certificates (i.e., Root CAs, Sub-CAs):
Page - 24
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
2
3



Shall include a keyUsage extension
Shall set the criticality of the keyUsage extension to TRUE
Shall assert the keyCertSign bit and the cRLSign bit in the key usage extension
4
Table 2: keyUsage Extension for all CA certificates
5
Field
keyUsage
Format
Criticality
Value
BIT STRING
TRUE
{ id-ce 15 }
Comment
Included in all CA certificates
digitalSignature
(0)
0
Not Set
nonRepudiation
(1)
0
Not Set
keyEncipherment
(2)
0
Not Set
dataEncipherment
(3)
0
Not Set
keyAgreement
(4)
0
Not Set
keyCertSign
(5)
1
Set
cRLSign
(6)
1
Set
encipherOnly
(7)
0
Not Set
decipherOnly
(8)
0
Not Set
6
7
8
9
10
11
12
13
Public keys that are bound into subscriber certificates shall be used only for signing or encrypting, but not both.
Table 3 shows the specific keyUsage extension settings for AeroMACS Subscriber signature certificates that contain
ECC public keys and specifies that all Subscriber certificates that contain ECC public keys:




Shall include a keyUsage extension
Shall set the criticality of the keyUsage extension to TRUE
Shall assert the digitalSignature bit
Shall assert the nonRepudiation bit
Table 3: keyUsage Extension for all Subscriber Signature Certificates
14
Field
keyUsage
Format
Criticality
Value
BIT STRING
TRUE
{ id-ce 15 }
Comment
Included in all Subscriber
certificates
digitalSignature
(0)
1
Set
nonRepudiation
(1)
1
Set
keyEncipherment
(2)
0
Not Set
Page - 25
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
dataEncipherment
(3)
0
Not Set
keyAgreement
(4)
0
Not Set
keyCertSign
(5)
0
Not Set
cRLSign
(6)
0
Not Set
encipherOnly
(7)
0
Not Set
decipherOnly
(8)
0
Not Set
1
2
3
4
5
6
Table 4 shows the specific keyUsage extension settings for AeroMACS key management certificates that contain
ECC public keys and specifies that all key management certificates that contain ECC public keys:



Shall include a keyUsage extension
Shall set the criticality of the keyUsage extension to TRUE
Shall assert the keyAgreement bit
Table 4: keyUsage Extension for all Key Management Certificates
7
Field
keyUsage
Format
Criticality
Value
BIT STRING
TRUE
{ id-ce 15 }
Comment
Included in all Subscriber
certificates
digitalSignature
(0)
0
Not Set
nonRepudiation
(1)
0
Not Set
keyEncipherment
(2)
0
Not Set
dataEncipherment
(3)
0
Not Set
keyAgreement
(4)
1
Set
keyCertSign
(5)
0
Not Set
cRLSign
(6)
0
Not Set
encipherOnly
(7)
0
Not Set
decipherOnly
(8)
0
Not Set
8
9
10
11
12
13
14
Table 4 shows the specific keyUsage extension settings for AeroMACS Server certificates that contain ECC public
keys and specifies that all Server certificates that contain ECC public keys:




Shall include a keyUsage extension
Shall set the criticality of the keyUsage extension to TRUE
Shall assert the digitalSignature bit
Shall assert the keyAgreement bit
Page - 26
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
Table 5: keyUsage Extension for all Server Certificates
1
Field
keyUsage
2
3
Format
Criticality
Value
BIT STRING
TRUE
{ id-ce 15 }
Comment
Included in all Server certificates
digitalSignature
(0)
1
Set
nonRepudiation
(1)
0
Not Set
keyEncipherment
(2)
0
Not Set
dataEncipherment
(3)
0
Not Set
keyAgreement
(4)
1
Set
keyCertSign
(5)
0
Not Set
cRLSign
(6)
0
Not Set
encipherOnly
(7)
0
Not Set
decipherOnly
(8)
0
Not Set
The dataEncipherment, encipherOnly, and decipherOnly bits shall not be asserted in certificates issued under this
policy,
Private Key Protection and Cryptographic Module Engineering Controls
4
5
6.2.1 Cryptographic Module Standards and Controls
6
7
8
Private keys within the AeroMACS PKI shall be protected using Trustworthy Systems. Private key holders shall
take necessary precautions to prevent the loss, disclosure, modification, or unauthorized use of such Private Keys in
accordance with this CP and contractual obligations specified in the appropriate AeroMACS Agreement.
9
The relevant standard for cryptographic modules is Security Requirements for Cryptographic Modules [FIPS 140-2].
10
11
12
13
14

15
16

All other entities, including Subscribers with medium-assurance hardware certificates shall use a FIPS 1402 Level 2 or higher approved cryptographic module for all private key operations.
17
18

Servers should use a FIPS 140-2 Level 1 or higher approved cryptographic module for their cryptographic
operations.


Root CAs shall perform all CA cryptographic operations on cryptographic modules approved at a minimum
of FIPS 140-2 level 3 or higher.
Sub-CAs shall use a FIPS 140-2 Level 2 or higher approved hardware cryptographic module.
Subscribers with low- or medium-assurance software certificates shall use a FIPS 140-2 Level 1 or higher
approved cryptographic module for their cryptographic operations.
19
6.2.2 Private Key (n out of m) Multi-Person Control
20
21
22
Multi-person control is enforced to protect the activation data needed to activate CA private keys so that a single
person shall not be permitted to activate or access any cryptographic module that contains the complete CA private
signing key.
Page - 27
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
2
3
CA signature keys may be backed up only under multi-person control. Access to CA signing keys backed up for
disaster recovery shall be under multi-person control. The names of the parties used for multi-person control shall be
maintained on a list that shall be made available for inspection during compliance audits.
4
5
6
7
8
CAs may use “Secret Sharing” to split the private key or activation data needed to operate the private key into
separate parts called “Secret Shares” held by individuals called “Shareholders.” Some threshold number of Secret
Shares (m) out of the total number of Secret Shares (n) shall be required to operate the private key. The minimum
threshold number of shares (m) needed to sign a CA certificate shall be 3. The total number of shares (n) used shall
be greater than the minimum threshold number of shares (m).
9
10
11
12
CAs may also use Secret Sharing to protect the activation data needed to activate private keys located at their
respective disaster recovery sites. The minimum threshold number of shares (m) needed to sign a CA certificate at a
disaster recovery site shall be 3. The total number of shares (n) used shall be greater than the minimum threshold
number of shares (m).
13
6.2.3 Private Key Escrow
14
CA private signature keys and Subscriber private signatures keys shall not be escrowed.
15
16
17
If the CA retains subscriber private encryption keys for business continuity purposes, the CA shall escrow such
subscriber private encryption keys to protect them from unauthorized modification or disclosure through physical
and cryptographic means.
18
6.2.4 Private Key Backup
19
20
21
22
23
24
25
26
CAs shall back up their private keys, under the same multi-person control as the original signature key. The backups
allow the CA to be able to recover from disasters and equipment malfunction. At least one copy of the private
signature key shall be stored off-site. Private keys that are backed up shall be protected from unauthorized
modification or disclosure through physical or cryptographic means. Backups, including all activation data needed
to activate the cryptographic module containing the private key, shall be protected with a level of physical and
cryptographic protection equal to or exceeding that for cryptographic modules within the CA site, such as at a
disaster recovery site or at another secure off-site facility, such as a bank safe. All copies of the CA private signature
key shall be accounted for and protected in the same manner as the original.
27
28
29
30
31
Device private keys may be backed up or copied, but must be held under the control of the Subscriber or other
authorized administrator. Backed up device private keys shall not be stored in plaintext form and storage must
ensure security controls consistent with the security specifications the device is compliant with. Subscribers may
have the option of using enhanced private key protection mechanisms available today including the use of smart
cards, biometric access devices, and other hardware cryptographic modules to store private keys.
32
6.2.5 Private Key Archival
33
34
35
CA private signature keys and subscriber private signatures keys shall not be archived. If the CA retains subscriber
private encryption keys for business continuity purposes, the CA shall archive such subscriber private keys, in
accordance with CP section 5.5.
36
37
38
39
Upon expiration of a CA Certificate, the key pair associated with the certificate will be securely retained for a period
of at least 5 years using hardware cryptographic modules that meet the requirements of this CP. These CA key pairs
shall not be used for any signing events after the expiration date of the corresponding CA Certificate, unless the CA
Certificate has been renewed in terms of this CP.
40
6.2.6 Private Key Transfer into or from a Cryptographic Module
41
42
43
CA private keys may be exported from the cryptographic module only to perform CA key backup procedures as
described in CP section 6.2.4. At no time shall the CA private key exist in plaintext outside the cryptographic
module.
44
45
46
All other keys shall be generated by and in a cryptographic module. In the event that a private key is to be
transported from one cryptographic module to another, the private key must be encrypted during transport; private
keys must never exist in plaintext form outside the cryptographic module boundary.
Page - 28
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
Private or symmetric keys used to encrypt other private keys for transport must be protected from disclosure.
2
3
Entry of a private key into a cryptographic module shall use mechanisms to prevent loss, theft, modification,
unauthorized disclosure, or unauthorized use of such private key.
4
5
6
7
Processing Centers generating CA or Sub-CA private keys on one hardware cryptographic module and transferring
them into another shall securely transfer such private keys into the second cryptographic module to the extent
necessary to prevent loss, theft, modification, unauthorized disclosure, or unauthorized use of such private keys.
Such transfers shall be limited to making backup copies of the private keys on tokens.
8
9
10
11
CAs pre-generating private keys and transferring them into a hardware cryptographic module, for example
transferring generated end-user Subscriber private keys into a smart card, shall securely transfer such private keys
into the module to the extent necessary to prevent loss, theft, modification, unauthorized disclosure, or unauthorized
use of such private keys.
12
6.2.7 Private Key Storage on Cryptographic Module
13
No stipulation beyond that specified in FIPS 140-2.
14
6.2.8 Method of Activating Private Key
15
16
All CAs shall protect the activation data for their private keys against loss, theft, modification, disclosure, or
unauthorized use.
17
CA Administrator Activation
18
Method of activating the CA system by a CA Administrator shall require:
19
20
21
22
23
24


Use a smart card, biometric access device, password in accordance with CP section 6.4.1, or security of
equivalent strength to authenticate the Administrator before the activation of the private key, which
includes, for instance, a password to operate the private key, a Windows logon or screen saver password, or
a network logon password; and
Take commercially reasonable measures for the physical protection of the Administrator’s workstation to
prevent use of the workstation and its associated private key without the Administrator’s authorization.
25
Offline CAs Private Key
26
27
28
Once the CA system has been activated, a threshold number of Shareholders shall be required to supply their
activation data in order to activate an offline CA’s private key, as defined in CP section 6.2.2. Once the private key
is activated, it shall be active until termination of the session.
29
Online CAs Private Keys
30
31
32
An online CA’s private key shall be activated by a threshold number of Shareholders, as defined in CP section 6.2.2,
supplying their activation data (stored on secure media). Once the private key is activated, the private key may be
active for an indefinite period until it is deactivated when the CA goes offline.
33
Subscriber Private Keys
34
35
The AeroMACS standards for protecting activation data for Subscribers’ private keys shall be in accordance with
the specific obligations appearing in the applicable agreement executed between AeroMACS and the Subscriber.
36
37
38
39
For device certificates, the device may be configured to activate its private key, provided that appropriate physical
and logical access controls are implemented for the device. The strength of the security controls shall be
commensurate with the level of threat in the device’s environment, and shall protect the device’s hardware,
software, private keys and its activation data from compromise.
40
6.2.9 Method of Deactivating Private Key
41
42
43
Cryptographic modules that have been activated shall not be available to unauthorized access. After use, the
cryptographic module shall be deactivated, e.g., via a manual logout procedure or automatically after a period of
inactivity. CA cryptographic modules shall be stored securely when not in use.
Page - 29
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
2
When an online CA is taken offline, the CA shall remove the token containing the private key from the reader in
order to deactivate it.
3
4
5
With respect to the private keys of offline CAs, after the completion of a Key Generation Ceremony, in which such
private keys are used for private key operations, the CA shall remove the token containing the private keys from the
reader in order to deactivate them. Once removed from the reader, tokens shall be securely stored.
6
7
When an online CA is taken offline, the CA shall remove the token containing such CA’s private key from the
reader in order to deactivate it.
8
When deactivated, private keys shall be kept in encrypted form only.
9
6.2.10 Method of Destroying Private Key
10
Private keys shall be destroyed in a way that prevents their theft, disclosure, or unauthorized use.
11
12
13
14
15
Upon termination of the operations of a CA or Sub-CA, individuals in trusted roles shall decommission the CA/SubCA private signature keys by deleting it using functionality of the token containing such CA/Sub-CA’s private key
so as to prevent its recovery following deletion, or the loss, theft, modification, disclosure, or unauthorized use of
such private key. CA/Sub-CA private keys shall be destroyed in a manner that reasonably ensures that there are no
residuals remains of the key that could lead to the reconstruction of the key.
16
For Root CAs, PKI-PA security personnel shall witness this process.
17
18
Subscribers may destroy their private signature keys when they are no longer needed or when the certificates to
which they correspond expire or are revoked. Physical destruction of hardware is not required.
19
6.2.11 Cryptographic Module Rating
20
See CP section 6.2.1.
Other Aspects of Key Pair Management
21
22
6.3.1 Public Key Archival
23
The public key is archived as part of the certificate archival.
24
6.3.2 Certificate Operational Periods and Key Pair Usage Periods
25
26
The certificate validity period (i.e., certificate and key pair usage period) shall be set to the time limits set forth as
follows:
27
28
29
30



Root CA certificates shall have a validity period of up to 30 years
Sub-CA certificates shall have a validity period of up to 20 years
Subscriber certificates shall have a validity period of up to 10 years (e.g., 1 to 2 year server certs, 3 year
aircraft certs, up to 10 years for long lived certs)
31
32
Validity periods shall be nested such that the validity periods of issued certificates shall be contained within the
validity period of the issuing CA.
33
AeroMACS PKI Participants shall cease all use of their key pairs after their validity periods have expired.
34
Activation data
35
6.4.1 Activation Data Generation and Installation
36
37
38
CAs shall generate and install activation data for their private keys and shall use methods that protect the activation
data to the extent necessary to prevent the loss, theft, modification, disclosure, or unauthorized use of such activation
data.
Page - 30
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
2
3
To the extent passwords are used as activation data, CAs activation participants shall generate passwords that cannot
easily be guessed or cracked by dictionary attacks. Participants may not need to generate activation data, for
example if they use biometric access devices.
4
6.4.2
5
6
CAs shall protect the activation data for their private keys using methods that protect against the loss, theft,
modification, unauthorized disclosure, or unauthorized use of such private keys.
7
8
9
CAs shall use multi-party control in accordance with CP section 6.2.2. CAs shall provide the procedures and means
to enable Shareholders to take the precautions necessary to prevent the loss, theft, modification, disclosure, or
unauthorized use of the Secret Shares that they possess. Shareholders shall not:
10
11
12


Activation Data Protection
Copy, disclose, or make the Secret Share available to a third party, or make any unauthorized use of it
whatsoever; or
Disclose their or any other person’s status as a Shareholder to any third party.
13
14
The Secret Shares and any information disclosed to the Shareholder in connection with their duties as a Shareholder
shall constitute Confidential/Private Information.
15
16
17
18
CAs shall include in their disaster recovery plans provisions for making Secret Shares available at a disaster
recovery site after a disaster (Note, the important aspect of disaster recovery vis-à-vis shares is that a process exists
for making the necessary number of shares available, even if the requisite shareholders are not available.). CAs
shall maintain an audit trail of Secret Shares, and Shareholders shall participate in the maintenance of an audit trail.
19
6.4.3 Other Aspects of Activation Data
20
Activation Data Transmission
21
22
23
24
25
To the extent activation data for private keys are transmitted, Activation Data Participants shall protect the
transmission using methods that protect against the loss, theft, modification, unauthorized disclosure, or
unauthorized use of such private keys. To the extent desktop computer or network logon user name/password
combination is used as activation data for an end-user Subscriber, the passwords transferred across a network shall
be protected against access by unauthorized users.
26
Activation Data Destruction
27
28
29
30
Activation data for CA private keys shall be decommissioned using methods that protect against the loss, theft,
modification, unauthorized disclosure, or unauthorized use of the private keys protected by such activation data.
After the record retention periods in CP section 5.5.2 lapses, CAs shall decommission activation data by overwriting
and/or physical destruction.
31
Computer security controls
32
6.5.1 Specific Computer Security Technical Requirements
33
34
35
36
CAs shall ensure that the systems maintaining CA software and data files are Trustworthy Systems secure from
unauthorized access, which can be demonstrated by compliance with audit criteria applicable under CP section
5.4.1. In addition, CAs shall limit access to production servers to those individuals with a valid business reason for
access. General application users shall not have accounts on the production servers.
37
38
39
40
CAs shall have production networks logically separated from other components. This separation prevents network
access except through defined application processes. CAs shall use firewalls to protect the production network from
internal and external intrusion and limit the nature and source of network activities that may access production
systems.
41
42
43
44
To the extent that passwords are used, CAs shall require the use of passwords with a minimum character length and
a combination of alphanumeric and special characters, and shall require that passwords be changed on a periodic
basis and whenever necessary. Direct access to a CA’s database maintaining the CA’s repository shall be limited to
Trusted Persons having a valid business reason for such access.
Page - 31
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
Computer security controls are required to ensure CA operations are performed as specified in this policy. The
following computer security functions may be provided by the operating system, or through a combination of
operating system, software, and physical safeguards:













Require authenticated logins
Provide discretionary access control
Provide a security audit capability
Enforce access control for CA services and PKI roles
Enforce separation of duties for PKI roles
Require identification and authentication of PKI roles and associated identities
Prohibit object reuse or require separation for CA random access memory
Require use of cryptography for session communication and database security
Archive CA history and audit data
Require self-test security-related CA services
Require a trusted path for identification of PKI roles and associated identities
Require a recovery mechanism for keys and the CA system
Enforce domain integrity boundaries for security-critical processes.
For other CAs operating under this policy, the computer security functions listed below are required. These
functions may be provided by the operating system, or through a combination of operating system, software, and
physical safeguards. The CA and its ancillary parts shall include the following functionality:





Authenticate the identity of users before permitting access to the system or applications;
Manage privileges of users to limit users to their assigned roles;
Generate and archive audit records for all transactions; (see CP section 5.4)
Enforce domain integrity boundaries for security critical processes; and
Support recovery from key or system failure.
For certificate status servers operating under this policy, the computer security functions listed below are required:




Authenticate the identity of users before permitting access to the system or applications;
Manage privileges of users to limit users to their assigned roles;
Enforce domain integrity boundaries for security critical processes; and
Support recovery from key or system failure.
For remote workstations used to administer the CAs, the computer security functions listed below are required:





Authenticate the identity of users before permitting access to the system or applications;
Manage privileges of users to limit users to their assigned roles;
Generate and archive audit records for all transactions; (see CP section 5.4)
Enforce domain integrity boundaries for security critical processes; and
Support recovery from key or system failure.
36
37
All communications between any PKI trusted role and the CA shall be authenticated and protected from
modification.
38
6.5.2 Computer Security Rating
39
No Stipulation.
40
Life Cycle Technical Controls
41
6.6.1 System Development Controls
42
43
44
The system development controls for the CA and Sub-CA are as follows:
 The CA shall use software that has been designed and developed under a formal, documented development
methodology.
Page - 32
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
2
3
4
5
6
7
8
9
10
11
12
13
14





Hardware and software procured to operate the CA shall be purchased in a fashion to reduce the likelihood
that any particular component was tampered with (e.g., by ensuring the vendor cannot identify the PKI
component that will be installed on a particular device).
Hardware and software developed specifically for the CA shall be developed in a controlled environment,
and the development process shall be defined and documented. This requirement does not apply to
commercial off-the-shelf hardware or software.
The CA hardware and software shall be dedicated to performing one task: the CA. There shall be no other
applications, hardware devices, network connections, or component software installed that are not parts of
the CA operation. Where the CA operation supports multiple CAs, the hardware platform may support
multiple CAs.
Proper care shall be taken to prevent malicious software from being loaded onto the CA equipment. All
applications required to perform the operation of the CA shall be obtained from documented sources.
Hardware and software updates shall be purchased or developed in the same manner as original equipment,
and shall be installed by trusted and trained personnel in a defined manner.
15
6.6.2 Security Management Controls
16
17
18
19
The configuration of the CA system, in addition to any modifications and upgrades, shall be documented and
controlled. There shall be a mechanism for detecting unauthorized modification to the software or configuration.
The CA software, when first loaded, shall be verified as being that supplied from the vendor, with no modifications,
and be the version intended for use.
20
6.6.3 Life Cycle Security Controls
21
No Stipulation.
22
Network Security Controls
23
24
25
A network guard, firewall, or filtering router must protect network access to CA equipment. The network guard,
firewall, or filtering router shall limit services allowed to and from the CA equipment to those required to perform
CA functions.
26
27
28
Protection of CA equipment shall be provided against known network attacks. All unused network ports and
services shall be turned off. Any network software present on the CA equipment shall be necessary to the
functioning of the CA application.
29
30
Any boundary control devices used to protect the network on which PKI equipment is hosted shall deny all but the
necessary services to the PKI equipment.
31
32
33
Repositories, certificate status servers, and remote workstations used to administer the CAs shall employ appropriate
network security controls. Networking equipment shall turn off unused network ports and services. Any network
software present shall be necessary to the functioning of the equipment.
34
35
The CA shall establish connection with a remote workstation used to administer the CA only after successful
authentication of the remote workstation at a level of assurance commensurate with that of the CA.
36
37
38
39
40
Time-Stamping
Certificates, CRLs, and other revocation database entries shall contain time and date information. Such time
information need not be cryptographic-based. Asserted times shall be accurate to within three minutes. Electronic or
manual procedures may be used to maintain system time. Clock adjustments are auditable events (see CP section
5.4.1).
41
Page - 33
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
2
7. CERTIFICATE, CRL, AND OCSP PROFILES
Certificate Profile
3
4
AeroMACS Certificates shall conform to [RFC 5280]: Internet X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile, May 2008.
5
6
7
8
9
AeroMACS Certificates shall contain the identity and attribute data of a subject using the base certificate with
applicable extensions. The base certificate shall contain the version number of the certificate, the certificate’s
identifying serial number, the signature algorithm used to sign the certificate, the issuer’s distinguished name, the
validity period of the certificate, the subject’s distinguished name, information about the subject’s public key, and
extensions (See Error! Reference source not found.).
Table 6: Certificate Profile Basic Fields
10
Field
[RFC5280] Section
Requirement or Recommendation
tbsCertificate
4.1.1.1
Follows [RFC 5280] guidance
version
4.1.2.1
See CP section 7.1.1.
serialNumber
4.1.2.2
Shall be a unique positive integer assigned by
the CA and shall not be longer than 20 octets.
signature
4.1.2.3
See CP section 7.1.3.
issuer
4.1.2.4
See CP section 7.1.4.
validity
4.1.2.5
See CP section 6.3.2.
subject
4.1.2.6
See CP section 7.1.4.
subjectPublicKeyInfo
4.1.2.7
See CP section Error! Reference source not
found..
extensions
4.1.2.9
See CP section 7.1.2.
4.1.1.2
Follows [RFC 5280] guidance
signatureAlgorithm
algorithmIdentifier
4.1.1.2
algorithm
4.1.1.2
See CP section 7.1.3.
parameters
4.1.1.2
See CP section 7.1.3.
4.1.1.3
Follows [RFC 5280] guidance
signatureValue
11
12
7.1.1 Version Number(s)
13
14
AeroMACS Certificates shall be X.509 v3 certificates. The certificate version number shall be set to the integer
value of "2" for Version 3 certificate.
Page - 34
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
7.1.2 Certificate Extensions
2
3
4
AeroMACS Certificate extensions provide methods for associating additional attributes with public keys and for
managing relationships between CAs. AeroMACS Certificates shall follow the guidance in [RFC 5280] and shall
contain the standard extensions shown in the tables below, unless they are denoted as optional.
5
Table 7 shows the certificate extensions for all AeroMACS Root CA certificates.
Table 7: Root CA Certificate Standard Extensions
6
Field
7
Referenced
Standard
Section
Requirement or Recommendation
subjectKeyIdentifier
[RFC 5280]
4.2.1.2
See Error! Reference source not found..
keyUsage
[RFC 5280]
4.2.1.3
See CP section 6.1.7.
certificatePolicies
[RFC 5280]
4.2.1.4
subjectAlternativeName
[RFC 5280]
4.2.1.6
basicConstraints
[RFC 5280]
4.2.1.9
(Optional Extension)
See CP section Error! Reference source not
found..
(Optional Extension)
May be included in Root CA certificate.
Criticality shall be set to FALSE.
See Error! Reference source not found..
Table 8 shows the certificate extensions for all AeroMACS sub-CA certificates.
Table 8: Sub-CA Certificate Standard Extensions
8
Field
Referenced
Standard
Section
Requirement or Recommendation
authorityKeyIdentifier
[RFC 5280]
4.2.1.1
Shall be included in sub-CA certificates.
Criticality shall be set to FALSE.
subjectKeyIdentifier
[RFC 5280]
4.2.1.2
See Error! Reference source not found..
keyUsage
[RFC 5280]
4.2.1.3
See CP section 6.1.7.
certificatePolicies
[RFC 5280]
4.2.1.4
See CP section Error! Reference source not
found..
subjectAlternativeName
[RFC 5280]
4.2.1.6
basicConstraints
[RFC 5280]
4.2.1.9
crlDistributionPoints
[RFC 5280]
(Optional Extension)
May be included in sub-CA certificates.
Criticality shall be set to FALSE.
See Error! Reference source not found..
This extension must appear in all CA certificates
and must contain at least one URI either HTTP
or LDAP. The reasons and cRLIssuer Fields
must be omitted.
9
10
Table 9 shows the certificate extensions for all AeroMACS subscriber certificates.
Page - 35
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
Table 9: Subscriber Certificate Standard Extensions
1
Field
2
Referenced
Standard
Section
Requirement or Recommendation
authorityKeyIdentifier
[RFC 5280]
4.2.1.1
Shall be included in Subscriber certificates.
Criticality shall be set to FALSE.
keyUsage
[RFC 5280]
4.2.1.3
See CP section 6.1.7.
certificatePolicies
[RFC 5280]
4.2.1.4
See CP section Error! Reference source not
found..
subjectAltName
[RFC 5280]
4.2.1.6
extKeyUsage
[RFC 5280]
4.2.1.12
crlDistributionPoints
[RFC 5280]
Set to a Device Class that is defined in the
Manuel on Aeronautical Mobile Airport
Communications System (AeroMACS). The
Device Classes include: Aircraft, Surface
Vehicle, Video Sensor, Ground Critical, or
Ground Default.
Criticality shall be set to TRUE.
(Optional Extension)
See Error! Reference source not found. for
server certificates.
See Error! Reference source not found. for
client certificates.
This extension must appear in all CA certificates
and must contain at least one URI either HTTP
or LDAP. The reasons and cRLIssuer Fields
must be omitted.
Table 10 shows the certificate extensions for all AeroMACS OCSP server certificates.
Table 10: OCSP Certificate Standard Extensions
3
Field
Referenced
Standard
Section
Requirement or Recommendation
Shall be included in OCSP certificates.
Criticality shall be set to FALSE.
authorityKeyIdentifier
[RFC 5280]
4.2.1.1
keyUsage
[RFC 5280]
4.2.1.3
Only the digitalSignature bit shall be set.
Criticality shall be set to TRUE.
certificatePolicies
[RFC 5280]
4.2.1.4
See CP section Error! Reference source not
found..
subjectAltName
[RFC 5280]
4.2.1.6
Shall be set to either the DNS name or the IP
address of the subject.
Criticality shall be set to FALSE.
4
5
Subject Key Identifier Extension
6
7
Table 11 shows the subjectKeyIdentifier extension settings for AeroMACS CA certificates and specifies that all
AeroMACS Root and sub-CA certificates:
8
9


Shall include the subjectKeyIdentifier extension
Shall set the criticality of the subjectKeyIdentifier extension to FALSE
Page - 36
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1

Shall calculate the keyIdentifier of the subjectKeyIdentifier per Method 1
Table 11: subjectKeyIdentifier Extension for AeroMACS CA Certificates
2
Field
Format
subjectKeyIdentifier
keyIdentifier
Criticality
Value
FALSE
{ id-ce 14 }
OCTET
STRING
Comment
Included in all CA certificates
<key identifier>
Calculated per Method 1.
3
Subscriber Certificates shall not include the subjectKeyIdentifier extension.
4
Basic Constraints Extension
5
6
Table 12 shows the basicConstraints extension settings for AeroMACS Root CA certificates and specifies that all
AeroMACS Root CA certificates:
7
8
9



Shall include the basicConstraints extension
Shall set the criticality of the basicConstraints extension to TRUE
Shall set the cA field of the basicConstraints extension to TRUE
Table 12: basicConstraints Extension for AeroMACS Root CA Certificates
10
Field
Format
basicConstraints
cA
BOOLEAN
pathLenConstraint
INTEGER
Criticality
Value
TRUE
{ id-ce 19 }
TRUE
Comment
Included in all Root certificates
Set
Not Set
11
12
13
14
15
16
17
Table 13 shows the basicConstraints extension settings for AeroMACS sub-CA certificates and specifies that all
AeroMACS sub-CA certificates:




Shall include the basicConstraints extension
Shall set the criticality of the basicConstraints extension to TRUE
Shall set the cA field of the basicConstraints extension set to TRUE
Shall set the pathLenConstraint field of the basicConstraints to “0” (zero)
Table 13: basicConstraints Extension for AeroMACS Sub-CA Certificates
18
Field
Format
basicConstraints
Criticality
Value
Comment
TRUE
{ id-ce 19 }
Included in all sub-CA certificates
cA
BOOLEAN
TRUE
pathLenConstraint
INTEGER
0
Set
19
Subscriber Certificates shall not include the basicConstraints extension.
20
21
NOTE: The pathLenConstraint extension gives the maximum number of CA certificates that may follow this
certificate in the certification path. A value of 0 indicates that only an end-entity certificate may follow in the path.
Page - 37
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
2
If the pathLenConstraint value is set, it has to be greater than or equal to 0. If it is not set, then the certification path
may be of any length.
3
Extended Key Usage
4
CA Certificates shall not include the extKeyUsage extension.
5
6
Table 14 shows the extKeyUsage extension settings for AeroMACS Subscriber server certificates (e.g., VTN
certificate) and specifies that all AeroMACS server certificates:
7
8
9



May include the extKeyUsage extension
If included, shall set the criticality of the extKeyUsage extension to FALSE
Shall set the keyPurposeId field of the extKeyUsage to id-kp-serverAuth
Table 14: extKeyUsage Exstension for AeroMACS Server Certificates
10
Field
Format
extKeyUsage
keyPurposeID
11
12
13
14
15
Criticality
Value
FALSE
{ id-ce 37 }
OID
1.3.6.1.5.5.7.3.1
Comment
May be included in Subscriber
server certificates.
id-kp-serverAuth
Table 15 shows the extKeyUsage extension settings for AeroMACS Subscriber client certificates and specifies that
all AeroMACS client certificates:



May include the extKeyUsage extension
If included, shall set the criticality of the extKeyUsage extension to FALSE
Shall set the keyPurposeId field of the extKeyUsage to id-kp-clientAuth
Table 15: extKeyUsage Exstension for AeroMACS Client Certificates
16
Field
Format
extKeyUsage
keyPurposeID
Criticality
Value
FALSE
{ id-ce 37 }
OID
1.3.6.1.5.5.7.3.2
Comment
May be included in Subscriber
client certificates.
id-kp-clientAuth
17
7.1.3 Algorithm Object Identifiers (OIDs)
18
19
This CP requires use of ECDSA signatures. Certificates issued under this policy shall contain elliptic curve public
keys and shall use the following ECC OID for signatures (see Table 16).
Table 16: Signature OIDS for Certificates
20
Field
Format
Criticality
Value
Comment
signature
algorithmIdentifier
algorithm
OID
parameters
ANY
1.2.840.10045.4.3.2
ecdsa-with-Sha256
Absent
Page - 38
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
2
Certificates issued under this CP shall use the following OID to identify the algorithm associated with the subject
public key in certificates with ECC public keys (see Table 17).
Table 17: subjectPublicKeyInfo for Certificate
3
Field
Format
Criticality
Value
Comment
subjectPublicKeyInfo
algorithm
algorithmIdentifier
algorithm
OID
1.2.840.10045.2.1
parameters
ANY
1.2.840.10045.3.1.7
secp256r1
1.3.132.0.34
ansip384r1
BIT STRING
subjectPublicKey
<subject public key>
EC Public Key
Modulus length.
See CP section 6.1.5.
4
5
7.1.4 Name Forms
6
Root CAs
7
8
The following naming attributes shall be used to populate the issuer and subject fields in Root CA Certificates
issued under this CP:
Table 18: Root CA Certificate issuer and subject Fields
9
Name
Field
Value
Requirement
countryName
(C=)
<Country Code>
Shall be the two-letter ISO 3166-1 country
code for the country in which the Root
CA’s service provider’s place of business is
located.
organizationName
(O=)
<Organization>
Shall contain the issuer organization name.
organizationalUnitName
(OU=)
Root CA<Id#>
Shall contain a name that accurately
identifies the Issuing CA. The “<Id#>”
indicates the ID number of the Root and is
populated when the Root CA certificate is
issued. For Example, “Root CA001.”
commonName
(CN=)
<Name> Root CA
Shall contain the common name that
identifies the AeroMACS Root CA. (e.g.
CompanyA Root CA)
10
11
Page - 39
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
2
3
4
5
Sub-CAs
6
The following naming attributes shall be used to populate the sub-CA Certificate subject fields issued under this CP:
7
Table 19: Sub-CA Certificate subject Fields
Name
Field
Value
Requirement
countryName
(C=)
<Country
Name>
Shall be the two-letter ISO 3166-1 country code
for the country in which the CA’s service
provider’s place of business is located.
organizationName
(O=)
<Organization>
organizationalUnitName
(OU=)
<CA type>
CA<Id#>
commonName
(CN=)
<Name> SubCA
Shall contain the issuer organization name
(or abbreviation thereof), trademark, or
other meaningful identifier.
Shall contain additional CA identifying
information. The <CA type> is either
“Intermediate” or “Sub”, the “<Id#>”
indicates the ID number of the CA and is
populated when the CA certificate is issued.
For Example, “Intermediate CA001”.
Shall contain a name that accurately
identifies the CA. (e.g. CompanyA Sub CA)
8
9
10
11
Subscriber Certificates
The following naming attributes shall be used to populate the Subject in Subscriber Certificates issued under this
CP:
Table 20: Subscriber Certificate subject Fields
12
Name
Field
Value
Requirement
countryName
(C=)
<Country
Name>
Shall be the two-letter ISO 3166-1 country code
for the country in which the Subscriber’s place
of business is located.
organizationName
(O=)
<Organization>
Shall contain the Subscriber organization name
(or abbreviation thereof), trademark, or other
meaningful identifier.
organizationalUnitName
(OU=)
<Addition
Information>
(Optional) When included, one or more OUs
shall contain additional identifying information.
commonName
(CN=)
<Device Id>
Shall contain the device MAC Address that is
bound into the certificate that will bind the
Page - 40
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
certificate’s public key to the device.
1
2
7.1.5 Name Constraints
3
The CAs shall not assert name constraints in AeroMACS certificates.
4
7.1.6 Certificate Policy Object Identifier
5
The certificate policy object identifier for this CP is defined in the ATA Specification section 1.2.2.
6
7
Table 21 shows the certificatePolicies extension settings for AeroMACS certificates and specifies that all
AeroMACS certificates:
8
9


May include the certificatePolicies extension
If included, shall set the criticality of the certificatePolicies extension to FALSE
10
Table 21: certificatePolicies Extension for AeroMACS Certificates
11
Field
Format
certificatePolicies
Criticality
Value
Comment
FALSE
{ id-ce 32 }
May be included in all
AeroMACS
certificates
policyInformation
policyIdentifier
OID
policyQualifiers
SEQUENC
E
<Certificate policy
OID>
See ATA
Specification section
1.2.2.
Not Set
12
13
7.1.7 Usage of Policy Constraints Extension
14
The CAs shall not assert policy constraints in CA certificates.
15
7.1.8 Policy Qualifiers Syntax and Semantics
16
Certificates issued under this CP shall not contain policy qualifiers.
17
7.1.9 Processing Semantics for the Critical Certificate Policies Extension
18
Certificates issued under this policy shall not contain a critical certificate policies extension.
19
20
CRL Profile
CRLs shall conform to [RFC 5280] and contain the basic fields and contents specified in the table below:
Page - 41
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
Table 22: CRL Profile Basic Fields
1
Field
Referenced
Standard
Section
5.1.2.1
Requirement or Recommendation
version
[RFC 5280]
See Section 7.2.1.
signature
[RFC 5280]
issuer
[RFC 5280]
5.1.2.3
Entity that has signed and issued the CRL.
thisUpdate
[RFC 5280]
5.1.2.4
Indicates the issue date of the CRL. CRLs are
effective upon issuance.
nextUpdate
[RFC 5280]
5.1.2.5
Indicates the date by which the next CRL will
be issued.
revokedCertificates
[RFC 5280]
5.1.2.6
Listing of revoked certificates, including the
Serial Number of the revoked Certificate and
the Revocation Date.
authoritKeyIdentifier
[RFC 5280]
5.2.1
Follows the guidance in RFC 5280. Criticality
is FALSE.
cRLNumber
[RFC 5280]
5.2.3
A monotonically increasing sequence number
for a given CRL scope and issuer. Criticality is
FALSE.
signatureAlgorithm
[RFC 5280]
5.1.1.2
Follows the guidance in RFC 5280.
signatureValue
[RFC 5280]
5.1.1.3
Follows the guidance in RFC 5280.
Algorithm used to sign the CRL.
2
3
7.2.1 Version Number(s)
4
5
The CAs shall support the issuance of X.509 Version two (2) CRLs. The CRL version number shall be set to the
integer value of "1" for Version 2 [RFC 5280, section 5.1.2.1].
6
7.2.2 CRL and CRL entry extensions
7
Critical CRL extensions shall not be used.
OCSP Profile
8
9
10
11
12
13
14
OCSP (Online Certificate Status Protocol) is a way to obtain timely information about the revocation status of a
particular certificate. OCSP Responses must conform to [RFC5019] and must either be:


Signed by the CA that issued the Certificates whose revocation status is being checked, or
Signed by an OCSP Responder whose Certificate is signed by the CA that issued the Certificate whose
revocation status is being checked. Such OCSP Responder signing Certificate shall contain the extension
id-pkix-ocsp-nocheck as defined by [RFC2560].
15
7.3.1 Version Number(s)
16
OCSP responses shall support use of OCSP version 1 as defined by [RFC2560] and [RFC5019].
Page - 42
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
7.3.2 OCSP Extensions
2
Critical OCSP extensions shall not be used.
3
Page - 43
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
8. Compliance Audit and Other Assessments
2
3
CAs operating under this policy shall have a compliance audit mechanism in place to ensure that the requirements of
their CP/CPS are being implemented and enforced.
4
This specification does not impose a requirement for any particular assessment methodology.
Frequency or Circumstances of Assessment
5
6
CAs and Sub-CAs operating under this policy shall be subject to a periodic compliance audit at least once per year.
Identity/Qualifications of Assessor
7
8
9
10
11
12
The compliance auditor must demonstrate competence in the field of compliance audits, and must be thoroughly
familiar with the CA’s CPS and this CP. The compliance auditor must perform such compliance audits as a regular
ongoing business activity. In addition to the previous requirements, the auditor must be a certified information
system auditor (CISA) or IT security specialist, and a PKI subject matter specialist who can offer input regarding
acceptable risks, mitigation strategies, and industry best practices.
Assessor's Relationship to Assessed Entity
13
14
15
16
17
18
19
20
The compliance auditor shall either represent a firm, which is independent from the entity being audited, or it shall
be sufficiently organizationally separated from that entity to provide an unbiased, independent evaluation. An
example of the latter situation may be an organizational audit department provided it can demonstrate organizational
separation and independence. To further insure independence and objectivity, the compliance auditor may not have
served the entity in develo0ping or maintaining the entity’s PKI Facility, associated IT and network systems, or
certificate practices statement. The Policy Authority shall determine whether a compliance auditor meets this
requirement.
21
22
In the event an entity chooses to engage compliance auditor services internal to its parent organization, it shall
undergo an audit from an external third party audit firm every third year, at a minimum.
Topics Covered by Assessment
23
24
25
26
27
The purpose of a compliance audit shall be to verify that a component operates in accordance with the applicable
CP, CPS, the agreement between the PKI and the Policy Authority, and any additional MOAs between the PKI and
other Entities. The compliance audit must include an assessment of the applicable CPS against the applicable CP, to
determine that the CPS adequately addresses and implements the requirements of the CP.
Actions Taken as a Result of Deficiency
28
29
30
31
32
33
34
35
36
37
38
39
40
When the compliance auditor finds a discrepancy between the requirements of this CP or the stipulations in the CPS
and the design, operation, or maintenance of the PKI Authorities, the following actions shall be performed:



The compliance auditor shall note the discrepancy;
The compliance auditor shall notify the responsible party promptly; and
The party responsible for correcting the discrepancy shall determine what further notifications or actions
are necessary pursuant to the requirements of the applicable CP and the Agreement, and then proceed to
make such notifications and take such actions without delay.
Depending upon the nature and severity of the discrepancy, and how quickly it can be corrected, the Policy
Authority may decide to temporarily halt operation of the CA or Sub-CA, to revoke a certificate issued to the CA or
Sub-CA, or take other actions it deems appropriate. The Policy Authority will develop procedures for making and
implementing such determinations. In accordance with section 8.1, a compliance audit may be required to confirm
the implementation and effectiveness of the remedy.
Page - 44
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
2
3
4
5
6
7
Communication of Results
An Audit Compliance Report package, including identification of corrective measures taken or being taken by the
Entity PKI, shall be provided to the Policy Authority as set forth in Section 8.1. This package shall be prepared in
accordance with the Policy Authority and must include an assertion from the Entity PKI PMA that all PKI
components have been audited – including any components that may be separately managed and operated. The
package shall identify the versions of this CP and CPS used in the assessment. Additionally, where necessary, the
results shall be communicated as set forth in Section 8.5 above.
Page - 45
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
9. Other Business and Legal Matters
2
Fees
3
Financial Responsibility
4
Confidentiality of business information
5
Privacy of Personal Information
6
Intellectual Property Rights
7
Representations and Warranties
8
Disclaimers of warranties
9
Limitations of liability
10
Indemnities
11
Term and termination
12
Individual notices and communications with participants
13
Amendments
14
Dispute Resolution Provisions
15
Governing Law
16
Compliance with Applicable Law
17
Miscellaneous provisions
18
Other Provisions
19
Page - 46
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
10. References
RFC 2119
Key Words for use in RFCs to Indicate Requirement Level, IETF (Bradner), March 1997.
http://www.ietf.org/rfc/rfc2119.txt
RFC 2560
X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP, IETF (Myers,
Ankney, Malpani, Galperin, Adams), June 1999.
http://www.ietf.org/rfc/rfc2560.txt
RFC 3647
Internet X.509 PKI Certificate Policy and Certification Practices Framework, IETF (Chokhani,
Ford, Sabett, Merrill, and Wu), November 2003.
http://www.ietf.org/rfc/rfc3647.txt
RFC 5019
The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume
Environments, IETF (Deacon, Hurst), September 2007.
http://www.ietf.org/rfc/rfc5019.txt
RFC 5280
Internet X.509 PKI Certificate and Certification Revocation List (CRL) Profile, IETF (Cooper,
Santesson, Farrell, Boeyen, Housley, and Polk), May 2008.
http://www.ietf.org/rfc/rfc5280.txt
FIPS 140-2
Security Requirements for Cryptographic Modules, FIPS 140-2, May 25, 2001.
http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
Page - 47
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
11. Glossary
2
This specification uses the following terms:
Audit Requirements Guide
A document that sets forth the security and audit requirements and
practices for AeroMACS CAs.
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 that issued the certificate.
Certificate Applicant
An individual or organization that requests the issuance of a Certificate
by a CA.
Certificate Application
A request from a Certificate Applicant (or authorized agent of the
Certificate Applicant) to a CA for the issuance of a Certificate.
Certificate Chain
An ordered list of Certificates containing a Subscriber Certificate and
one or more CA Certificates, which terminates in a root Certificate.
Control Objectives
Criteria that an entity must meet in order to satisfy a Compliance
Audit.
Certificate Policy (CP)
The principal statement of policy governing the AeroMACS PKI.
Certificate Revocation List
(CRL)
A periodically (or exigently) issued list, digitally signed by a CA, of
identified Certificates that have been revoked prior to their expiration
dates. The list generally indicates the CRL issuer’s name, the date of
issue, the date of the next scheduled CRL issue, the revoked
Certificates’ serial numbers, and the specific times and reasons for
revocation.
Certificate Signing Request
(CSR)
A message conveying a request to have a Certificate issued.
Certification Authority (CA)
An entity authorized to issue, manage, revoke, and renew Certificates
in the AeroMACS PKI.
Certification Practice Statement A statement of the practices that a CA employs in approving or
rejecting Certificate Applications and issuing, managing, and revoking
(CPS)
Certificates.
Certificate Requesting Account
(CRA)
The online portal to assist Certificate Applicants in requesting
Certificates.
Compliance Audit
A periodic audit that a CA system undergoes to determine its
conformance with AeroMACS PKI requirements that apply to it.
Compromise
A violation of a security policy, in which an unauthorized disclosure
of, or loss of control over, sensitive information has occurred. With
respect to private keys, a Compromise is a loss, theft, disclosure,
modification, unauthorized use, or other compromise of the security of
such private key.
CRL Usage Agreement
An agreement setting forth the terms and conditions under which a
CRL or the information in it can be used.
Exigent Audit/Investigation
An audit or investigation by AeroMACS where AeroMACS has reason
to believe that an entity’s failure to meet PKI Standards, an incident or
Compromise relating to the entity, or an actual or potential threat to the
security of the PKI posed by the entity has occurred.
Elliptic Curve Cryptography
A public-key cryptography system based on the algebraic structure of
Page - 48
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
(ECC)
elliptic curves over finite fields.
Intellectual Property Rights
Rights under one or more of the following: copyright, patent, trade
secret, trademark, or any other intellectual property rights.
Key Generation Ceremony
A procedure whereby a CA’s key pair is generated, its private key is
backed up, and/or its public key is certified.
PKI Participant
An individual or organization that is one or more of the following
within the AeroMACS PKI: AeroMACS, a CA, a Subscriber, or a
Relying Party.
PKCS #10
Public-Key Cryptography Standard #10, developed by RSA Security
Inc., which defines a structure for a Certificate Signing Request.
PKCS #8
Public-Key Cryptography Standard #8, developed by RSA Security
Inc., which defines a secure means for the transfer of private keys.
Processing Center
A secure facility created by an appropriate organization (e.g.,
Symantec) that houses, among other things, the cryptographic modules
used for the issuance of Certificates.
Public Key Infrastructure (PKI) The architecture, organization, techniques, practices, and procedures
that collectively support the implementation and operation of a
Certificate-based public key cryptographic system.
Relying Party
An individual or organization that acts in reliance on a certificate
and/or a digital signature.
Secret Share
A portion of the activation data needed to operate the private key, held
by individuals called “Shareholders.” Some threshold number of Secret
Shares (n) out of the total number of Secret Shares (m) shall be
required to operate the private key.
Secret Sharing
The practice of splitting a CA private key or the activation data to
operate a CA private key in order to enforce multi-person control over
CA private key operations.
Security Repository
AeroMACS database of relevant security information accessible online.
Security Policy
The highest-level document describing AeroMACS security policies.
Sub domain
The portion of the AeroMACS PKI under control of an entity and all
entities subordinate to it within the AeroMACS PKI.
Sub domain Participants
An individual or organization that is one or more of the following
within the AeroMACS Subdomain: AeroMACS, a Subscriber, or a
Relying Party.
Subject
The holder of a private key corresponding to a public key. The term
“Subject” can, in the case of a Device Certificate, refer to the
Subscriber requesting the device certificate.
Subscriber
The entity who requests a Certificate (e.g., a manufacturer). The
Subscriber is capable of using, and is authorized to use, the private key
that corresponds to the public key listed in the Certificate.
Subscriber Agreement
An agreement used by a CA setting forth the terms and conditions
under which an individual or organization acts as a Subscriber.
Superior Entity
An entity above a certain entity within the AeroMACS PKI.
Trusted Person
An employee, contractor, or consultant of an entity within the
AeroMACS PKI responsible for managing infrastructural
trustworthiness of the entity, its products, its services, its facilities,
and/or its practices.
Trusted Position
The positions within the AeroMACS PKI entity that must be held by a
Page - 49
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
Trusted Person.
Trustworthy System
Computer hardware, software, and procedures that are reasonably
secure from intrusion and misuse; provide a reasonable level of
availability, reliability, and correct operation; are reasonably suited to
performing their intended functions; and enforce the applicable security
policy.
Validity Period
The period starting with the date and time a Certificate is issued (or on
a later date and time certain if stated in the Certificate) and ending with
the date and time on which the Certificate expires or is earlier revoked.
Page - 50
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-D
Attachment to AeroMACS PKI Certificate Policy
1
12. Abbreviations and Acronyms
2
This specification uses the following abbreviations:
CA
Certification Authority
CP
Certificate Policy
CPS
Certification Practice Statement
CRA
Certificate Requesting Account
CRL
Certificate Revocation List
CSR
Certificate Signing Request
DR
Demand Response
DRAS
Demand Response Automation Server
ECC
Elliptic Curve Cryptography
FIPS
Federal Information Processing Standards
id-at
X.500 attribute types. (OID value: 2.5.4)
id-ce
Object Identifier for Version 3 certificate extensions. (OID value: 2.5.29)
IETF
Internet Engineering Task Force
ISO
Independent System Operators
LSVA
Logical Security Vulnerability Assessment
MFG
Manufacturer
OID
PA
Object Identifier
Policy Authority
PKCS
Public-Key Cryptography Standard
PKI
Public Key Infrastructure
RFC
Request for comment
RSA
Rivest, Shamir, Adelman
SAS
Statement on Auditing Standards (promulgated by the American Institute of Certified Public
Accountants)
3
Page - 51
WiMAX FORUM PROPRIETARY