WiMAX Forum® Network Architecture
AeroMACS PKI Certificate Policy
DRAFT-T32-006-R010v01-H
Draft Specification
(2016-02-19)
WiMAX Forum Proprietary
Copyright © 2015 WiMAX Forum. All Rights Reserved.
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
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-H
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
3
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
E
2016-01-04
Section 4 added
F
2016-02-15
Section 1-3 added and
updated contents
G
2016-02-17
Changes Discussed in the PKI
Task Group teleconference.
Updated reference to server
certificates separate from
device certificates and added
Chp 9.
H
2016-02-19
Revisions in chapter 9 to
proposed standard language.
Clarification throughout
related to APPA
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.
Page - ii
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
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.
1
TABLE OF CONTENTS
2
WIMAX FORUM® NETWORK ARCHITECTURE ...............................................................................I
3
1.
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
1.2.1
1.2.2
1.3.1
1.3.2
1.3.3
1.3.4
1.3.5
1.3.6
1.3.7
1.4.1
1.4.2
1.5.1
1.5.2
1.5.3
1.5.4
2.
25
26
27
28
29
30
31
32
33
34
INTRODUCTION ......................................................................................................................... 11
PUBLICATION AND REPOSITORY RESPONSIBILITIES ................................................. 15
2.2.1
2.2.2
2.4.1
2.4.2
3.
Overview ...................................................................................................................................... 11
Identification ................................................................................................................................ 11
Certificate Policy Name ............................................................................................................... 11
OID ............................................................................................................................................... 11
PKI Participants............................................................................................................................ 12
AeroMACS PKI Policy Authority ............................................................................................... 12
Certification Authorities (CA)...................................................................................................... 12
Certificate Status Authority (CSA) .............................................................................................. 12
Registration Authorities (RA) ...................................................................................................... 12
Device Sponsors ........................................................................................................................... 13
Relying Parties ............................................................................................................................. 13
Other Participants ......................................................................................................................... 13
Certificate Usage .......................................................................................................................... 13
Appropriate Certificate Uses ........................................................................................................ 13
Prohibited Certificate Uses ........................................................................................................... 13
Policy Administration................................................................................................................... 13
Organization Administering the Document.................................................................................. 13
Contact Person.............................................................................................................................. 13
Person Determining CPS Suitability for the Policy ..................................................................... 14
CPS Approval Procedures ............................................................................................................ 14
Repositories .................................................................................................................................. 15
Publication of Certification Information ...................................................................................... 15
Publication of CA Information ..................................................................................................... 15
Availability of Information .......................................................................................................... 15
Time or Frequency of Publication ................................................................................................ 15
Access Controls on Repositories .................................................................................................. 15
Certificate Policy .......................................................................................................................... 15
Certificates and CRLs .................................................................................................................. 15
IDENTIFICATION AND AUTHENTICATION ....................................................................... 17
Naming ......................................................................................................................................... 17
Page - iii
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
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
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.1.6
3.2.1
3.2.2
3.2.3
3.2.4
3.2.5
3.3.1
3.3.2
4.
Types of Names ............................................................................................................................ 17
Need for Names to be Meaningful ............................................................................................... 17
Anonymity or Pseudonymity of Devices ..................................................................................... 17
Rules for Interpreting Various Name Forms ................................................................................ 17
Uniqueness of Names ................................................................................................................... 17
Recognition, Authentication, and Role of Trademarks ................................................................ 17
Initial Identity Validation ............................................................................................................. 18
Method to Prove Possession of Private Key................................................................................. 18
Authentication of Individual Identity ........................................................................................... 18
Non-verified Device Information ................................................................................................. 19
Validation of Authority ................................................................................................................ 19
Criteria for Interoperation ............................................................................................................ 19
Re-key Requests ........................................................................................................................... 20
Identification and Authentication for Routine Re-key ................................................................. 20
Identification and Authentication for Re-key after Revocation ................................................... 20
Identification and Authentication for Revocation Request .......................................................... 20
CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS ................................... 21
Certificate Application ................................................................................................................. 21
4.1.1 Who Can Submit a Certificate Application .................................................................................. 21
4.1.2 Enrollment Process and Responsibilities...................................................................................... 21
Certificate Application Processing ............................................................................................... 21
4.2.1 Performing Identification and Authentication Functions ............................................................. 21
4.2.2 Approval or Rejection of Certificate Applications ....................................................................... 22
4.2.3 Time to Process Certificate Applications ..................................................................................... 22
Certificate Issuance ...................................................................................................................... 22
4.3.1 CA Actions During Certificate Issuance ...................................................................................... 22
4.3.2 Notification to Device Sponsor by the CA of Issuance of Certificate.......................................... 23
Certificate Acceptance ................................................................................................................. 23
4.4.1 Conduct Constituting Certificate Acceptance .............................................................................. 23
4.4.2 Publication of the Certificate by the CA ...................................................................................... 23
4.4.3 Notification of Certificate Issuance by the CA to Other Entities ................................................. 23
Key Pair and Certificate Usage .................................................................................................... 23
4.5.1 Device Private Key and Certificate Usage ................................................................................... 23
4.5.2 Relying Party Public Key and Certificate Usage ......................................................................... 23
Certificate Renewal ...................................................................................................................... 24
4.6.1 Circumstance for Certificate Renewal.......................................................................................... 24
4.6.2 Who May Request Renewal ......................................................................................................... 24
4.6.3 Processing Certificate Renewal Requests .................................................................................... 24
4.6.4 Notification of new Certificate Issuance to Device ...................................................................... 24
4.6.5 Conduct Constituting Acceptance of a Renewal Certificate ........................................................ 24
4.6.6 Publication of the Renewal Certificate by the CA ....................................................................... 24
4.6.7 Notification of Certificate Issuance by the CA to Other Entities ................................................. 24
Certificate Re-key......................................................................................................................... 24
4.7.1 Circumstance for Certificate Re-key ............................................................................................ 24
4.7.2 Who May Request Certification of a New Public Key ................................................................ 25
4.7.3 Processing Certificate Re-keying Requests .................................................................................. 25
4.7.4 Notification of New Certificate Issuance to Device Sponsors ..................................................... 25
4.7.5 Conduct Constituting Acceptance of a Re-keyed Certificate ....................................................... 25
4.7.6 Publication of the Re-keyed Certificate by the CA ...................................................................... 25
Page - iv
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
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
4.7.7 Notification of Certificate Issuance by the CA to Other Entities ................................................. 25
Certificate Modification ............................................................................................................... 25
4.8.1 Circumstance for Certificate Modification ................................................................................... 25
4.8.2 Who May Request Certificate Modification ................................................................................ 25
4.8.3 Processing Certificate Modification Requests.............................................................................. 25
4.8.4 Notification of New Certificate Issuance to Device ..................................................................... 25
4.8.5 Conduct Constituting Acceptance of Modified Certificate .......................................................... 25
4.8.6 Publication of the Modified Certificate by the CA ...................................................................... 25
4.8.7 Notification of Certificate Issuance by the CA to Other Entities ................................................. 25
Certificate Revocation and Suspension ........................................................................................ 26
4.9.1 Circumstances for Revocation...................................................................................................... 26
4.9.2 Who can Request Revocation....................................................................................................... 26
4.9.3 Procedure for Revocation Request ............................................................................................... 26
4.9.4 Revocation Request Grace Period ................................................................................................ 27
4.9.5 Time within which CA Must Process the Revocation Request .................................................... 27
4.9.6 Revocation Checking Requirement for Relying Parties ............................................................... 27
4.9.7 CRL Issuance Frequency.............................................................................................................. 27
4.9.8 Maximum Latency for CRLs ....................................................................................................... 28
4.9.9 On-line Revocation/Status Checking Availability ....................................................................... 28
4.9.10 On-line Revocation Checking Requirements ............................................................................... 28
4.9.11 Other Forms of Revocation Advertisements Available................................................................ 28
4.9.12 Special Requirements Regarding Key Compromise .................................................................... 28
4.9.13 Circumstances for Suspension...................................................................................................... 28
4.9.14 Who can Request Suspension....................................................................................................... 28
4.9.15 Procedure for Suspension Request ............................................................................................... 28
4.9.16 Limits on Suspension Period ........................................................................................................ 28
Certificate Status Services ............................................................................................................ 28
4.10.1 Operational Characteristics .......................................................................................................... 28
4.10.2 Service Availability ...................................................................................................................... 29
4.10.3 Optional Features ......................................................................................................................... 29
End of Subscription ...................................................................................................................... 29
Key Escrow and Recovery ........................................................................................................... 29
4.12.1 Key Escrow and Recovery Policy and Practices .......................................................................... 29
4.12.2 Session Key Encapsulation and Recovery Policy and Practices .................................................. 29
5.
FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS ..................................... 30
5.1.1
5.1.2
5.1.3
5.1.4
5.1.5
5.1.6
5.1.7
5.1.8
5.2.1
5.2.2
5.2.3
5.2.4
Physical Controls.......................................................................................................................... 30
Site Location and Construction .................................................................................................... 30
Physical Access ............................................................................................................................ 30
Power and Air Conditioning......................................................................................................... 31
Water Exposures .......................................................................................................................... 31
Fire Prevention and Protection ..................................................................................................... 31
Media Storage .............................................................................................................................. 31
Waste Disposal ............................................................................................................................. 31
Off-Site Backup............................................................................................................................ 31
Procedural Controls ...................................................................................................................... 32
Corporate Controls ....................................................................................................................... 32
Trusted Roles................................................................................................................................ 32
Number of Persons Required per Task......................................................................................... 33
Identification and Authentication for Each Role .......................................................................... 33
Page - v
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
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.2.5 Roles Requiring Separation of Duties .......................................................................................... 33
Personnel Controls ....................................................................................................................... 34
5.3.1 Qualifications, Experience, and Clearance Requirements............................................................ 34
5.3.2 Background Check Procedures .................................................................................................... 34
5.3.3 Training Requirements ................................................................................................................. 35
5.3.4 Retraining Frequency and Requirements ..................................................................................... 35
5.3.5 Job Rotation Frequency and Sequence ......................................................................................... 35
5.3.6 Sanctions for Unauthorized Actions............................................................................................. 35
5.3.7 Independent Contractor Requirements ......................................................................................... 35
5.3.8 Documentation Supplied to Personnel ......................................................................................... 35
Audit Logging Procedures............................................................................................................ 35
5.4.1 Types of Events Recorded ............................................................................................................ 36
5.4.2 Frequency of Processing Log ....................................................................................................... 39
5.4.3 Retention Period for Audit Log .................................................................................................... 40
5.4.4 Protection of Audit Logs .............................................................................................................. 40
5.4.5 Audit Log Backup Procedures ..................................................................................................... 40
5.4.6 Audit Collection System (Internal vs. External) .......................................................................... 40
5.4.7 Notification to Event-Causing Subject ......................................................................................... 40
5.4.8 Vulnerability Assessments ........................................................................................................... 40
Records Archival .......................................................................................................................... 40
5.5.1 Types of Events Archived ............................................................................................................ 40
5.5.2 Retention Period for Archive ....................................................................................................... 41
5.5.3 Protection of Archive ................................................................................................................... 41
5.5.4 Archive Backup Procedures ......................................................................................................... 42
5.5.5 Requirements for Time-Stamping of Records.............................................................................. 42
5.5.6 Procedures to Obtain and Verify Archive Information ................................................................ 42
Key Changeover ........................................................................................................................... 42
Compromise and disaster recovery .............................................................................................. 42
5.7.1 Incident and Compromise Handling Procedures .......................................................................... 42
5.7.2 Computing Resources, Software, and/or Data Are Corrupted ..................................................... 42
5.7.3 Private Key Compromise Procedures........................................................................................... 43
5.7.4 Business Continuity Capabilities after a Disaster ........................................................................ 43
CA, CSA, or RA Termination ...................................................................................................... 43
6.
TECHNICAL SECURITY CONTROLS .................................................................................... 44
6.1.1
6.1.2
6.1.3
6.1.4
6.1.5
6.1.6
6.1.7
6.2.1
6.2.2
6.2.3
6.2.4
6.2.5
6.2.6
Key Pair Generation and Installation ........................................................................................... 44
Key Pair Generation ..................................................................................................................... 44
Private Key Delivery to Devices .................................................................................................. 44
Public Key Delivery to Certificate Issuer ..................................................................................... 45
CA Public Key Delivery to Relying Parties ................................................................................. 45
Key Sizes ...................................................................................................................................... 45
Public Key Parameters Generation and Quality Checking ........................................................... 46
Key Usage Purposes (as per X.509 v3 Key Usage Field) ............................................................ 46
Private Key Protection and Cryptographic Module Engineering Controls ................................. 47
Cryptographic Module Standards and Controls ........................................................................... 47
Private Key (n out of m) Multi-Person Control............................................................................ 47
Private Key Escrow ...................................................................................................................... 47
Private Key Backup ...................................................................................................................... 47
Private Key Archival .................................................................................................................... 48
Private Key Transfer into or from a Cryptographic Module ........................................................ 48
Page - vi
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
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
6.2.7 Private Key Storage on Cryptographic Module ........................................................................... 48
6.2.8 Method of Activating Private Key ............................................................................................... 48
6.2.9 Method of Deactivating Private Key ............................................................................................ 49
6.2.10 Method of Destroying Private Key .............................................................................................. 49
6.2.11 Cryptographic Module Rating ...................................................................................................... 49
Other Aspects of Key Pair Management ...................................................................................... 49
6.3.1 Public Key Archival ..................................................................................................................... 49
6.3.2 Certificate Operational Periods and Key Pair Usage Periods....................................................... 49
Activation data ............................................................................................................................. 50
6.4.1 Activation Data Generation and Installation ................................................................................ 50
6.4.2 Activation Data Protection ........................................................................................................... 50
6.4.3 Other Aspects of Activation Data ................................................................................................ 50
Computer security controls .......................................................................................................... 50
6.5.1 Specific Computer Security Technical Requirements .................................................................. 50
6.5.2 Computer Security Rating ............................................................................................................ 51
Life Cycle Technical Controls ..................................................................................................... 51
6.6.1 System Development Controls ..................................................................................................... 51
6.6.2 Security Management Controls .................................................................................................... 51
6.6.3 Life Cycle Security Controls ........................................................................................................ 51
Network Security Controls ........................................................................................................... 51
Time-Stamping ............................................................................................................................. 52
7.
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
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.
40
41
42
43
44
45
46
CERTIFICATE, CRL, AND OCSP PROFILES ........................................................................ 53
Certificate Profile ......................................................................................................................... 53
Version Number(s) ....................................................................................................................... 53
Certificate Extensions................................................................................................................... 54
Algorithm Object Identifiers (OIDs) ............................................................................................ 57
Name Forms ................................................................................................................................. 58
Name Constraints ......................................................................................................................... 59
Certificate Policy Object Identifier .............................................................................................. 59
Usage of Policy Constraints Extension ........................................................................................ 60
Policy Qualifiers Syntax and Semantics ...................................................................................... 60
Processing Semantics for the Critical Certificate Policies Extension .......................................... 60
CRL Profile .................................................................................................................................. 60
Version Number(s) ....................................................................................................................... 61
CRL and CRL entry extensions.................................................................................................... 61
OCSP Profile ................................................................................................................................ 61
Version Number(s) ....................................................................................................................... 61
OCSP Extensions ......................................................................................................................... 61
COMPLIANCE AUDIT AND OTHER ASSESSMENTS ......................................................... 62
Frequency or Circumstances of Assessment ................................................................................ 62
Identity and Qualifications of Assessor........................................................................................ 62
Assessor's Relationship to Assessed Entity .................................................................................. 62
Topics Covered by Assessment .................................................................................................... 62
Actions Taken as a Result of Deficiency ..................................................................................... 62
Communication of Results ........................................................................................................... 63
9.
OTHER BUSINESS AND LEGAL MATTERS ......................................................................... 64
Page - vii
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
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
Fees............................................................................................................................................... 64
Certificate Issuance or Renewal Fees ........................................................................................... 64
Certificate Access Fees ................................................................................................................ 64
Revocation or Statue Information Access Fees ............................................................................ 64
Fees for other Services ................................................................................................................. 64
Refund Policy ............................................................................................................................... 64
Financial Responsibility ............................................................................................................... 64
9.2.1 Insurance Coverage ...................................................................................................................... 64
9.2.2 Other Assets ................................................................................................................................. 64
9.2.3 Insurance or Warranty Coverage for End-Entities ....................................................................... 64
Confidentiality of Business Information ...................................................................................... 64
9.3.1 Scope of Confidential Information ............................................................................................... 65
9.3.2 Information not within the Scope of Confidential Information .................................................... 65
9.3.3 Responsibility to Protect Confidential Information ..................................................................... 65
Privacy of Personal Information................................................................................................... 65
9.4.1 Privacy Plan.................................................................................................................................. 65
9.4.2 Information Treated as Private ..................................................................................................... 65
9.4.3 Information not Deemed Private .................................................................................................. 65
9.4.4 Responsibility to Protect Private Information .............................................................................. 65
9.4.5 Notice and Consent to Use Private Information ........................................................................... 65
9.4.6 Disclosure Pursuant to Judicial or Administrative Process .......................................................... 65
9.4.7 Other Information Disclosure Circumstances .............................................................................. 66
Intellectual Property Rights .......................................................................................................... 66
Representations and Warranties ................................................................................................... 66
9.6.1 CA Representations and Warranties............................................................................................. 67
9.6.2 RA Representations and Warranties............................................................................................. 67
9.6.3 Device Representations and Warranties ....................................................................................... 67
9.6.4 Relying Parties Representations and Warranties .......................................................................... 67
9.6.5 Representations and Warranties of Other Participants ................................................................. 67
Disclaimers of Warranties ............................................................................................................ 67
Limitations of Liability ................................................................................................................ 68
Indemnities ................................................................................................................................... 68
Term and Termination .................................................................................................................. 68
9.10.1 Term ............................................................................................................................................. 68
9.10.2 Termination .................................................................................................................................. 68
9.10.3 Effect of Termination and Survival .............................................................................................. 68
Individual Notices and Communications with Participants ......................................................... 68
Amendments................................................................................................................................. 68
9.12.1 Procedure for Amendment ........................................................................................................... 68
9.12.2 Notification and Mechanism and Period ...................................................................................... 68
9.12.3 Circumstances under which OID must be Changed ..................................................................... 68
Dispute Resolution Provisions ..................................................................................................... 68
Governing Law ............................................................................................................................. 69
Compliance with Applicable Law ................................................................................................ 69
Miscellaneous Provisions ............................................................................................................. 69
9.16.1 Entire Agreement ......................................................................................................................... 69
9.16.2 Assignment ................................................................................................................................... 69
9.16.3 Severability................................................................................................................................... 69
9.16.4 Enforcement (Attorneys’ Fees and Waiver of Rights) ................................................................. 69
9.16.5 Force Majeure .............................................................................................................................. 69
Other Provisions ........................................................................................................................... 69
9.1.1
9.1.2
9.1.3
9.1.4
9.1.5
Page - viii
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
10.
REFERENCES .............................................................................................................................. 70
2
11.
GLOSSARY ................................................................................................................................... 71
3
12.
ABBREVIATIONS AND ACRONYMS ..................................................................................... 74
4
5
Page - ix
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
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
TABLE OF TABLES
TABLE 1: ALGORITHM TYPE AND KEY SIZE ................................................................................... 45
TABLE 2: KEYUSAGE EXTENSION FOR ALL CA CERTIFICATES ................................................. 46
TABLE 3: KEYUSAGE EXTENSION FOR ALL DEVICE CERTIFICATES ....................................... 46
TABLE 4: CERTIFICATE PROFILE BASIC FIELDS ............................................................................. 53
TABLE 5: ROOT CA CERTIFICATE STANDARD EXTENSIONS ...................................................... 54
TABLE 6: CA CERTIFICATE STANDARD EXTENSIONS .................................................................. 54
TABLE 7: DEVICE CERTIFICATE STANDARD EXTENSIONS ......................................................... 55
TABLE 8: OCSP CERTIFICATE STANDARD EXTENSIONS .............................................................. 55
TABLE 9: SUBJECTKEYIDENTIFIER EXTENSION FOR AEROMACS CA CERTIFICATES ......... 55
TABLE 10: BASICCONSTRAINTS EXTENSION FOR AEROMACS ROOT CA CERTIFICATES ... 56
TABLE 11: BASICCONSTRAINTS EXTENSION FOR AEROMACS CA CERTIFICATES ............... 56
TABLE 12: EXTKEYUSAGE EXTENSION FOR AEROMACS SERVER CERTIFICATES ................. 57
TABLE 13: SIGNATURE OIDS FOR CERTIFICATES .......................................................................... 57
TABLE 14: SUBJECTPUBLICKEYINFO FOR CERTIFICATES........................................................... 57
TABLE 15: ROOT CA CERTIFICATE ISSUER AND SUBJECT FIELDS ............................................ 58
TABLE 16: CA CERTIFICATE SUBJECT FIELDS ................................................................................ 58
TABLE 17: DEVICE CERTIFICATE SUBJECT FIELDS ....................................................................... 59
TABLE 18: CERTIFICATEPOLICIES EXTENSION FOR AEROMACS CERTIFICATES.................. 59
TABLE 19: CRL PROFILE BASIC FIELDS ............................................................................................ 60
Page - x
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
1. Introduction
2
Overview
3
4
5
6
AeroMACS (Aeronautical Mobile Airport Communications System) is the broadband wireless technology based on
WiMAX intended to support the transmission of safety and traffic control data for both fixed and mobile
applications on the airport surface. To support secure communication between end-points, AeroMACS requires
digital certificate based strong authentication across the AeroMACS system.
7
8
9
10
11
This Certificate Policy (CP) defines the procedural and operational requirements that AeroMACS requires entities to
adhere to when issuing and managing digital certificates within the AeroMACS Public Key Infrastructure (PKI).
AeroMACS’ certificates are control by the AeroMACS PKI Policy Authority (APPA) that determines how this CP
applies to Certificate Authorities (CAs), Registration Authorities (RAs), Certificate Status Authority (CSAs), Device
Sponsors, Relying Parties and other PKI entities that interoperate with or within the AeroMACS PKI.
12
13
14
15
A Certificate issued in accordance with this CP conveys within the Aerospace Community a level of digital identity
assurance associated with the Subject of the Certificate. Certificates created within this PKI will be mediumassurance certificates for devices with hardware cryptographic modules. In this document, the term “device” means
a non-person entity, i.e., a hardware device or software application.
16
A PKI that uses this CP will provide the following security management services:
17

Key generation and storage
18

Certificate generation, modification, re-key, and distribution
19

Certificate Revocation List (CRL) generation and distribution
20

Directory management of certificate related items
21

Certificate token initialization, programming, and management
22

System management functions to include security audit, configuration management, and archive
23
24
25
This policy establishes requirements for the secure distribution of self-signed root certificates for use as trust
anchors. These constraints apply only to CAs that chose to distribute self-signed certificates, such as a hierarchical
PKI’s root CA.
26
27
28
This CP is only one of several documents that govern the AeroMACS PKI. Other important documents include the
Certification Practice Statements (CPS), registration authority agreements, Subscriber Agreements, privacy policies,
and memoranda of agreement.
29
30
31
It is consistent with the Internet Engineering Task Force (IETF) Public Key Infrastructure X.509 (IETF PKIX) RFC
3647, Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practice Statement Framework as
well as the Aviation Industry Standards for Digital Information Security (ATA Spec 42).
Identification
32
33
1.2.1 Certificate Policy Name
34
35
36
This document shall be named the AeroMACS PKI Certificate Policy (CP). It shall furthermore have an assurancelevel designation, according to the OID from Section 1.2.2 under which this document is referenced. For example,
this document may be referenced as the AeroMACS Medium-Assurance Certificate Policy.
37
1.2.2 OID
38
39
Certificates issued in accordance with this Certificate Policy shall be known by the following OIDs, depending on
the level of assurance to be conveyed:
40

Medium-Assurance (Software):
Page - 11
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
2

{iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) AeroMACS (?????)
Medium(3) Software(1)}
PKI Participants
3
4
1.3.1 AeroMACS PKI Policy Authority
5
ICAO is the AeroMACS PKI Policy Authority (APPA). The APPA is responsible for:
6

Approving and Maintaining this CP,
7

Approving the CPS for each CA that issues certificates under this policy,
8

Approving the compliance audit report for each CA issuing certificates under this policy, and
9
10

Ensuring continued conformance of each CA that issues certificates under this policy with applicable
requirements as a condition for allowing continued participation.
11
1.3.2 Certification Authorities (CA)
12
13
14
Any Entity providing services, or wishing to provide services, to the global Air Transport or Aerospace
Communities may, with the authorization of the APPA, operate a CA and issue certificates in accordance with this
CP, provided all provisions of this CP are followed.
15
16
The CA is the collection of hardware, software and operating personnel that create, sign, and issue public key
certificates to devices. The CA is responsible for issuing and managing certificates including:
17

The certificate manufacturing process
18

Publication of certificates
19

Revocation of certificates
20

Generation and destruction of CA signing keys
21
22
23

Ensuring that all aspects of the CA services, operations, and infrastructure related to certificates issued
under this CP are performed in accordance with the requirements, representations, and warranties of this
CP.
24
1.3.3 Certificate Status Authority (CSA)
25
26
27
28
29
30
31
PKIs may optionally include an authority that provides status information about certificates on behalf of a CA
through on-line transactions. In particular, PKIs may include Online Certificate Status Protocol (OCSP) responders
to provide on-line status information. Such an authority is termed a certificate status authority (CSA). Where the
CSA is identified in certificates as an authoritative source for revocation information, the operations of that authority
are considered within the scope of this CP. A Certificate Status Authority shall assert all the policy OIDs for which
it is authoritative. Examples include OCSP servers that are identified in the authority information access (AIA)
extension. OCSP servers that are locally trusted, as described in RFC 2560, are not covered by this policy.
32
1.3.4 Registration Authorities (RA)
33
34
35
The registration authorities (RAs) collect and verify each device’s identity and information that is to be entered into
the device’s public key certificate. The RA performs its function in accordance with a CPS approved by the APPA.
The RA is responsible for:
36

Control over the registration process
37

The identification and authentication process
Page - 12
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
1.3.5 Device Sponsors
2
3
4
A device sponsor is a person who requests a certificate on behalf of a device within the AeroMACS ecosystem. The
device sponsor asserts that the device will use the key and certificate in accordance with the certificate policy
asserted in the certificate.
5
1.3.6 Relying Parties
6
7
8
9
10
11
A Relying Party is an entity that relies on the validity of the binding of the device's name to a Public Key. The
Relying Party is responsible for deciding whether or how to check the validity of the Certificate by checking the
appropriate certificate status information. The Relying Party can use the Certificate to verify the integrity of a
digitally signed message, to identify the creator of a message, or to negotiate session keys for the establishment of
confidential communications with the holder of the Certificate. A Relying Party may use information in the
Certificate (such as Certificate Policy identifiers) to determine the suitability of the Certificate for a particular use.
12
1.3.7 Other Participants
13
14
15
The CAs and RAs operating under this CP may require the services of other security, community, and application
authorities, such as compliance auditors and attribute authorities. The CPS will identify the parties responsible for
providing such services, and the mechanisms used to support these services.
Certificate Usage
16
17
1.4.1 Appropriate Certificate Uses
18
19
Medium- assurance certificates issued under this CP may be used for digital signature functions and encryption
between devices where a certain degree of trust is required.
20
1.4.2 Prohibited Certificate Uses
21
Prohibited applications include the following:
22

Any export, import, use or activity that contravenes any local or international laws or regulations
23

Any usage of Certificates in conjunction with illegal activities
24

Any usage of Certificates for personal use or purposes not related to the Community’s business
25

Any use of a Certificate after it has been revoked
26

Any use not expressly permitted in Section 1.4.1.
27
Policy Administration
28
1.5.1 Organization Administering the Document
29
This CP is administered by the WiMAX Forum Aviation Working Group (AWG).
30
1.5.2 Contact Person
31
The following individual is responsible for accepting comments on this CP on behalf of the group mentioned above:
32
WiMAX Forum Aviation Working Group
33
34
35
Richard Hawkins
Chief Operating Officer and Chairman, Technical Steering Committee
rich.hawkins@wimaxforum.org
36
Page - 13
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
1.5.3 Person Determining CPS Suitability for the Policy
2
3
4
5
A CPS may be approved as sufficient for fulfilling the obligations under this CP when such a CPS has been
reviewed by an auditor or compliance analyst competent in the operations of a PKI, and when said person
determines that the CPS is in fact in compliance with all aspects of this CP. The auditor or compliance analyst shall
be from a firm which is independent from the entity being audited.
6
1.5.4 CPS Approval Procedures
7
8
9
10
11
The term CPS is defined in the Internet RFC 3647, X.509 Public Key Infrastructure Certificate Policy and
Certification Practice Statement Framework as: “A statement of the practices, which a CA employs in issuing
certificates.” It is a comprehensive description of such details as the precise implementation of service offerings and
detailed procedures of certificate life-cycle management. It shall be more detailed than the corresponding CP
defined above.
Page - 14
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
2. Publication and Repository Responsibilities
Repositories
2
3
4
5
6
7
All CAs that issue certificates under this policy are obligated to post all CA certificates issued by or to the CA and
CRLs issued by the CA in a repository that is publicly accessible through all Uniform Resource Identifier (URI)
references asserted in valid certificates issued by that CA. To promote consistent access to certificates and CRLs, the
repository shall implement access controls and communication mechanisms to prevent unauthorized modification or
deletion of information.
Publication of Certification Information
8
9
10
11
2.2.1
Publication of CA Information
CAs issuing a Certificate in accordance with this CP shall make the following items publicly available in their
repositories:
12

This CP;
13

The CRL; and
14
15

All CA Certificates issued by the CA (including self-signed CA-Certificate and Cross-Certificates for
Cross-Certified CAs).
16
Signature and Identity Certificates need not be published in the PKI repository.
17
18
The CA shall notify device sponsors and Relying Parties of Certificate issuance by providing access to Certificates
and CRLs in a Certificate Repository.
19
20
When using LDAP as the repository access mechanism, the following object classes and attributes shall be
populated:
21
22
23

Repository entries that describe CAs shall be a member of the pkiCA and cpCPS auxiliary object classes
and populate the cACertificate, certificateRevocationList, cPCPS and crossCertificatePair attributes as
applicable.
24
2.2.2 Availability of Information
25
26
27
All information published in the Repository shall be available on a twenty-four (24) hours per day, seven (7) days
per week basis, save for periods of scheduled or unscheduled downtime, as negotiated between relevant parties as
part of a Commercial Contract.
28
29
30
31
32
Time or Frequency of Publication
The CA’s public information identified in Section 2.2.1 shall be published prior to the first Certificate being issued
in accordance with this CP. Certificate publication shall be done in accordance with Section 4.4.2. CRL publication
shall be done in accordance with Sections 4.9.7 and 4.9.12.
Access Controls on Repositories
33
2.4.1 Certificate Policy
34
There shall be no access controls to prevent the reading of this CP.
35
2.4.2 Certificates and CRLs
36
37
Only CAs shall be able to create, modify, or otherwise maintain Certificates or CRLs. These operations shall require
a password over SSL or stronger authentication mechanism. Read only access to both Certificates and CRL within
Page - 15
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
2
the Certificate Repository shall be granted to anonymous users (i.e.: authentication type “none”) of the Certificate
Repository.
Page - 16
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
3. Identification and Authentication
Naming
2
3
3.1.1 Types of Names
4
5
6
Each device shall have a clearly distinguishable and unique X.501 Distinguished Name (DN) in the Certificate
Subject name field and in accordance with RFC 5280. Certificates may include additional names via the
subjectAltName extension, provided it is marked noncritical, which shall be in accordance with RFC 5280.
7
8
9
10
For certificates issued to devices, the subjectAltName shall contain the Device Class that is defined in the Manuel on
Aeronautical Mobile Airport Communications System (AeroMACS) and be marked as critical. The Device Classes
include: Aircraft, Surface Vehicle, Video Sensor, Ground Critical, or Ground Default. The Common Name (CN)
portion of the DN shall contain the devices media access control (MAC) address.
11
3.1.2 Need for Names to be Meaningful
12
13
14
The certificates issued pursuant to this CP are meaningful only if the names that appear in the certificates can be
understood and used by Relying Parties. Names used in the certificates must identify the person or object to which
they are assigned in a meaningful way.
15
16
When DNs are used, it is preferable that the common name represents the device in a way that is easily
understandable for humans.
17

For Individuals, this will typically be a legal name.
18
19
20
21
22

For End-Entity equipment, this may be a model name and serial number, an application process (e.g.,
Organization X Mail List or Organization Y Multifunction Interpreter), or a fully qualified domain name
(www.example.com), or network address (on the Internet, an IP or IPv6 address in a recognizable standard
form), or another kind of name that is meaningful in the domain of application (e.g., for AMS entity name
as defined in Section 7.1.4)
23
3.1.3 Anonymity or Pseudonymity of Devices
24
CA certificates shall not contain anonymous or pseudonymous identities.
25
26
DNs in certificates issued to devices may contain a pseudonym to meet local privacy regulations as long as name
space uniqueness requirements are met and as long as such name is unique and traceable to the actual entity.
27
3.1.4 Rules for Interpreting Various Name Forms
28
29
Rules for interpreting distinguished name forms are specified in X.501. Rules for interpreting e-mail addresses are
specified in [RFC 2822].
30
3.1.5 Uniqueness of Names
31
32
Name uniqueness across the AeroMACS domains, including cross-certified domains shall be enforced. The CAs and
RAs shall enforce name uniqueness within the X.500 name space, which they have been authorized.
33
The APPA shall be responsible for ensuring name uniqueness in certificates issued by the AeroMACS CAs.
34
3.1.6 Recognition, Authentication, and Role of Trademarks
35
36
37
38
39
The CA reserves the right to make all decisions regarding device names in all assigned Certificates. Devices shall
not use names in their Certificate Applications that knowingly infringe upon the Intellectual Property Rights of
others. No CA operating under this CP shall be required to determine whether a device has Intellectual Property
Rights in the name appearing in a DN or to arbitrate, mediate, or otherwise resolve any dispute concerning the
ownership of any domain name, trade name, trademark, or service mark. A CA operating under this CP shall be
Page - 17
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
2
3
4
entitled, without liability to any device sponsor, to reject or suspend any Certificate because of such dispute.
Notwithstanding the above, if the CA opts to invoke Section 3.1.5 on a device’s name, then the CA shall indemnify
the Device Sponsor against any claims against that given name, except where the Device Sponsor acts in a negligent
and reckless manner.
Initial Identity Validation
5
6
3.2.1 Method to Prove Possession of Private Key
7
8
9
10
In all cases where the party named in a certificate generates its own keys that party shall be required to prove
possession of the private key, which corresponds to the public key in the certificate request. For signature keys, this
may be done by the entity using its private key to sign a value and providing that value to the issuing CA. The CA
shall then validate the signature using the party’s public key.
11
12
13
14
In the case of an aircraft avionics component which is not capable of generating its own keys (e.g.: for an AMS
Aircraft Entity Certificate), this may only be possible from a separate computer before the key is transferred into the
aircraft avionics component. Subsequent to proof of possession, the private key shall be distributed to the aircraft
avionics in a manner consistent with section 6.2.
15
3.2.2 Authentication of Individual Identity
16
3.2.2.1 Device Subjects
17
18
19
20
For purposes of accountability and responsibility, an application for a Certificate of this type for a server,
application, or device shall be made by an individual, and the Digital Signature of that server, application, or device
shall be attributable to that individual. The Applicant shall provide the following registration information
corresponding to the server, application, or device:
21
22
23

Equipment identification (e.g.: serial number) or service name (e.g.: DNS Fully Qualified Domain Name,
IP address, AMS Entity identifier per Section 7.1.4, or other network address) sufficient to uniquely
identify the Subject;
24

Equipment authorizations and attributes (if any are to be included in the Certificate); and
25

Contact information to enable the CA or RA to communicate with the Applicant when required.
26
27
28
The CA or RA shall keep a record of the type and details of authentication used. The registration information shall
be verified to an assurance level commensurate with the Certificate assurance level being requested. Acceptable
methods for performing this authentication and integrity checking include, but are not limited to:
29
30

Verification of digitally signed messages sent from the individual requesting the device Certificate (using
Certificates of equivalent or greater assurance than that being requested); or
31
32

In-person registration by the individual requesting the device Certificate, with the identity of the individual
confirmed in accordance with the requirements of section 3.2.2.2.
33
3.2.2.2 Individual Subjects
34
35
36
37
A CA shall ensure that the Applicant's identity information is verified and checked in accordance with the applicable
CP and CPS. The CA or an RA shall ensure that the Applicant's identity information and public key are properly
bound. Additionally, the CA or the RA shall record the process that was followed for issuance of each Certificate.
The process documentation and authentication requirements shall include the following:
Note: Personally identifiable information may be collected and stored to the extent permitted by applicable
law. CAs and RAs are responsible for ensuring that they are in compliance with all applicable laws when
collecting such information.
38

The identity of the person performing the identity verification;
Page - 18
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
2
3

A signed declaration by that person that he or she verified the identity of the Applicant as required by the
applicable CP which may be met by establishing how the Applicant is known to the verifier as required by
this CP;
4

The date and time of the verification;
5

For all assurance levels, the following information shall be recorded:
6
o
the full name, including surname and given name(s) of the Applicant;
7
8
o
the date and place of birth or other attribute(s) which may be used to uniquely identify the
Applicant;
9
o
the full name and legal status of the Device Sponsor's Employer;
10
o
a physical address or other suitable method of contact; and
11
12
o
a declaration signed by the Applicant indicating his acceptance of the privacy policy outlined in
Section 9.4.
13

For medium-assurance Certificates, the Applicant shall:
14
15
o
present one valid national government-issued photo ID, or two valid non-national government
IDs, one of which shall be a recent photo ID (e.g.: driver's license);
16
17
o
have recorded with the above information for all assurance levels, unique identifying numbers
from the Identifier (ID) of the verifier and from an ID of the Applicant; and
18
19
o
sign a declaration of identity using a handwritten signature. This shall be performed in the
presence of the person performing the identity authentication.
20
21
22
23
24
Identity shall be established by in-person proofing before the RA, Trusted Agent, or an entity certified by a state or
government entity as being authorized to confirm identities; information provided shall be verified to ensure
legitimacy. A trust relationship between the Trusted Agent and the Applicant which is based on an in-person
antecedent may suffice as meeting the in-person identity proofing requirement. Identity shall be established no more
than 30 days within the CA's signature on the subject Certificate.
25
3.2.3 Non-verified Device Information
26
Information that is not verified shall not be included in Certificates.
27
3.2.4 Validation of Authority
28
29
30
To obtain a medium-assurance Certificate, any prospective Device Sponsor whose employer is not the issuing CA
must present at the time of authentication a letter from their employer authorizing him or her to obtain a certificate
of this type.
31
32
NOTE: Various special purpose Certificates are subject to extra requirements concerning validation of authority, as
follows:
33
34
35

For certificates to be loaded in aircraft avionics, a document proving the Applicant's employer's status as an
airline or as another type of legitimate operator of the given aircraft, such as a copy of aircraft registration
papers, must be provided.
36
37
38

For certificates used by ground entities that communicate with aircraft avionics, a document proving the
Applicant's employer's status as an airline as above, or as a supplier of datalink service to an airline, such as
a signed contract to that effect, must be provided.
39
3.2.5 Criteria for Interoperation
40
Interoperating CAs shall adhere to the following requirements:
41

Complete a policy mapping with the Subject CA's CP with results satisfactory to both parties;
Page - 19
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
2

Operate a PKI that has undergone a successful compliance audit pursuant to section 8 of this CP and as set
forth in the Subject CA CP;
3
4

Issue Certificates compliant with the profiles described in this CP, and make Certificate status information
available in compliance with this CP; and
5

Provide CA Certificate and Certificate status information to the Relying Parties.
6
7
Re-key Requests
3.3.1 Identification and Authentication for Routine Re-key
8
9
10
11
12
A request for re-key may only be made by the Device Sponsor in whose name the device keys have been issued. All
requests for re-key shall be authenticated by the CA, and the subsequent response shall be authenticated by the
Device Sponsor. This may be done by an on-line method in accordance with RFC 4210. Alternatively, a Device
Sponsor requesting re-key may authenticate the request using its valid Digital Signature key pair. Where the key has
expired, the request for re-key shall be authenticated by the CA in the same manner as the initial registration.
13
Identity shall be verified at least once every nine years.
14
15
When the current Signing Key is used for identification and authentication purposes, the life of the new Certificate
shall not exceed the initial identity-proofing times specified in the paragraph above.
16
3.3.2 Identification and Authentication for Re-key after Revocation
17
18
19
20
After a Certificate has been revoked other than during a renewal or update action, the subject is required to go
through the initial registration process described in Section 3.2 to obtain a new Certificate, unless he/she can be
authenticated through the use of a valid public key certificate of equal or higher assurance, as specified in Section
3.3.1.
21
22
23
Identification and Authentication for Revocation Request
Revocation requests shall be authenticated. Requests to revoke a certificate may be authenticated using that
certificate's associated public key, regardless of whether or not the private key has been compromised.
24
Page - 20
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
4. Certificate Life-cycle Operational Requirements
Certificate Application
2
3
The Certificate application process must provide sufficient information to:
4
5

Establish the applicant’s authorization (by the employing or sponsoring agency) to obtain a certificate. (per
section 3.2.2)
6

Establish and record identity of the applicant. (per section 3.2.2)
7
8

Obtain the applicant’s public key and verify the applicant’s possession of the private key for each
certificate required. (per section 3.2.1)
9

Verify authorization information requested for inclusion in the certificate.
10
11
These steps may be performed in any order that is convenient for the PKI authorities and applicants that does not
defeat security, but all must be completed before certificate issuance.
12
4.1.1 Who Can Submit a Certificate Application
13
A Certificate Application may be submitted by any of the following:
14
15

any individual who will be the subject of an Individual Certificate, or who owns or operates a server,
device, or application that will be the subject of an End-Entity Certificate;
16

any authorized representative of an organization or Entity; and
17

any authorized representative of a CA; or any authorized representative of an RA.
18
4.1.2 Enrollment Process and Responsibilities
19
20
All Device Sponsors must agree to be bound by a relevant Subscriber Agreement that contains representations and
warranties described in Section 9.6 and to undergo an enrollment process consisting of the following:
21

completing a Certificate Application and providing true and correct information;
22
23

generating, or arranging to have generated, a key pair, in accordance with Section 6.1.1 of the present
document;
24

delivering his, her, or its public key, directly or through an RA, to the CA's facility; and
25

demonstrating possession of the private key corresponding to the public key as described in Section 3.2.1.
26
27
28
29
30
31
All communications among PKI authorities supporting the certificate application and issuance process shall be
authenticated and protected from modification; any electronic transmission of shared secrets shall be protected.
Communications may be electronic or out-of-band. Where electronic communications are used, cryptographic
mechanisms commensurate with the strength of the public/private key pair shall be used. Out-of-band
communications shall protect the confidentiality and integrity of the data.
Certificate Application Processing
32
33
Information in certificate applications must be verified as accurate before certificates are issued. PKI authorities
shall specify procedures to verify information in certificate applications.
34
4.2.1 Performing Identification and Authentication Functions
35
36
37
The application will be subject to identification and authentication checks as described in Section 3.2 and Section
3.3 of this CP. The APPA must identify the components of the PKI (e.g. CA or RA) that are responsible for
authenticating the Device Sponsor’s identity in each case.
Page - 21
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
2
Additionally, prior to Certificate issuance, a Device Sponsor shall be required to sign a document stating that the
Device Sponsor shall protect the Private Key and use the Certificate and Private Key for authorized purposes only.
3
4.2.2 Approval or Rejection of Certificate Applications
4
A Certificate application will be approved by the CA or RA if all of the following conditions are met:
5
6

successful identification and authentication of all required device information as described in Section 3.2;
and
7

payment (if applicable) has been received.
8
A Certificate application will be rejected by the CA or RA if any one or more of the following conditions arises:
9
10

identification and authentication of all required Device information as described in Section 3.2 cannot be
completed;
11

the Device Sponsor fails to furnish supporting documentation upon request;
12

the Device Sponsor fails to respond to notices within a specified time;
13

payment (if applicable) has not been received; or
14

the RA or CA believe that issuing a certificate to the Device may bring the CA into disrepute.
15
4.2.3 Time to Process Certificate Applications
16
17
The entire registration process (i.e.: from initial application to identity proofing to Certificate issuance) shall take no
more than 30 days.
Certificate Issuance
18
19
20
Upon receiving a request for a certificate, the CA or RA shall respond in accordance with the requirements set forth
in this CP and in its CPS.
21
22
The certificate request may optionally contain an already built ("to-be-signed") certificate. This certificate will not
be signed until the process set forth in the CP and CPS has been met.
23
24
25
26
27
28
While the Device Sponsor may do most of the data entry, it is still the responsibility of the CA and the RA to verify
that the information is correct and accurate. This may be accomplished through a system approach linking trusted
databases containing personnel information, through other equivalent authenticated mechanisms, or through
personal contact with the device’s sponsoring organization. If databases are used to confirm Device information,
then these databases must be protected from unauthorized modification to a level commensurate with the level of
assurance of the certificate being sought.
29
4.3.1 CA Actions During Certificate Issuance
30
31
A Certificate is created and issued following the approval of a Certificate Application by a CA or following receipt
of an RA's request to issue the Certificate. Upon receiving the request, the CAs/RAs shall
32

Verify the identity and authority of the requester;
33

Check to ensure that all fields and extensions are properly populated;
34
35

Build and sign a certificate if all certificate requirements have been met (in the case of an RA, have the CA
sign the certificate).
36
37

Make the certificate available to the device after confirming that the Device Sponsor has formally
acknowledged their obligations as described in Section 9.6.3.
Page - 22
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
4.3.2 Notification to Device Sponsor by the CA of Issuance of Certificate
2
3
CAs issuing Certificates to Devices shall, either directly or through an RA, notify Device Sponsors that they have
created such Certificates, and provide Device Sponsors with access to the Certificates.
Certificate Acceptance
4
5
6
Before a device can make effective use of its private key, a PKI Authority shall explain to the Device Sponsor its
responsibilities as defined in Section 9.6.3.
7
4.4.1 Conduct Constituting Certificate Acceptance
8
9
An issued Certificate shall be deemed to have been accepted when it has been downloaded, installed, or used by the
device, and the Device Sponsor has not objected to the Certificate or its contents.
10
4.4.2 Publication of the Certificate by the CA
11
As specified in 2.1, all CA certificates shall be published in repositories.
12
This policy makes no stipulation regarding publication of device certificates, except as noted in Section 9.4.3.
13
4.4.3 Notification of Certificate Issuance by the CA to Other Entities
14
The APPA must be notified whenever a CA operating under this policy issues a CA certificate.
Key Pair and Certificate Usage
15
16
4.5.1 Device Private Key and Certificate Usage
17
18
19
20
Use of the Private Key corresponding to the Public Key in the Certificate shall only be permitted once the Device
Sponsor has agreed to the Subscriber Agreement and accepted the Certificate. The Certificate shall be used lawfully
in accordance with the Subscriber Agreement and the terms of this CP. Certificate use must be consistent with the
keyUsage and extendedKeyUsage extensions, in the associated Certificate.
21
22
Devices shall protect their Private Keys from unauthorized use and shall discontinue use of the Private Key
following expiration or revocation of the Certificate.
23
4.5.2 Relying Party Public Key and Certificate Usage
24
25
Reliance on a certificate must be reasonable under the circumstances. If the circumstances indicate a need for
additional assurances, the Relying Party must obtain such assurances for such reliance to be deemed reasonable.
26
Before any act of reliance, Relying Parties shall independently assess the following:
27
28
29

the appropriateness of the use of a Certificate for any given purpose and determine that the Certificate will,
in fact, be used for an appropriate purpose that is not prohibited or otherwise restricted by Section 1.4.1 or
1.4.2. CAs and RAs are not responsible for assessing the appropriateness of the use of a Certificate;
30
31

that the Certificate is being used in accordance with the keyUsage and extendedKeyUsage extensions
included in the Certificate; and
32
33
34

the status of the Certificate and all the CAs in the chain that issued the Certificate. If any of the Certificates
in the Certificate Chain have been revoked, the Relying Party shall not rely on the device’s Certificate or
other revoked Certificate in the Certificate Chain.
35
36
37
Assuming that the use of the Certificate is appropriate, Relying Parties shall utilize the appropriate software and/or
hardware to perform digital signature verification or other cryptographic operations they wish to perform, as a
condition of relying on Certificates in connection with each such operation.
Page - 23
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
Certificate Renewal
2
3
4
Renewing a Certificate means creating a new Certificate with the same name, key, and other information as the old
one, but a new, extended validity period and a new serial number is created. Certificates may be renewed in order to
reduce the size of CRLs.
5
4.6.1 Circumstance for Certificate Renewal
6
7
8
9
A Certificate may be renewed if the Public Key has not reached the end of its validity period, the associated Private
Key has not been revoked or compromised, and the device name and attributes are unchanged. In addition, the
validity period of the Certificate must not exceed the remaining lifetime of the Private Key, as specified in Section
6.3.2. The identity proofing requirement listed in Section 3.3.2 shall also be met.
10
The CA may automatically renew certificates during recovery from a key compromise.
11
4.6.2 Who May Request Renewal
12
13
A device or its Device Sponsor or employer may request the renewal of a Certificate. A CA may also request
renewal of its device Certificates, for example when the CA re-keys.
14
4.6.3 Processing Certificate Renewal Requests
15
16
In all cases, it is required that the device provide proof of possession of the Private Key in order to renew the
Certificate. This can be achieved in the manner described in Section 3.2.1.
17
4.6.4 Notification of new Certificate Issuance to Device
18
Notification shall be given to the Device Sponsor in accordance with Section 4.3.2.
19
4.6.5 Conduct Constituting Acceptance of a Renewal Certificate
20
See Section 4.4.1.
21
4.6.6 Publication of the Renewal Certificate by the CA
22
Renewed certificates are published as in Section 4.4.2.
23
4.6.7 Notification of Certificate Issuance by the CA to Other Entities
24
See Section 4.4.3.
25
Certificate Re-key
26
27
28
29
30
31
The longer and more often a key is used, the more susceptible it is to loss or discovery. Therefore, it is important
that a device periodically obtains new keys and reestablishes its identity. Re-keying a Certificate means that a new
Certificate is created, having the same characteristics and level as the old one, except that the new Certificate has a
new, different, Public Key (corresponding to a new, different, Private Key) and a different serial number, and it may
be assigned a different validity period. The old certificate may or may not be revoked, but must not be further rekeyed, renewed, or modified.
32
Device Sponsors shall identify themselves for the purpose of re-keying as required in Section 3.3.
33
4.7.1 Circumstance for Certificate Re-key
34
35
36
A Certificate may be re-keyed after revocation, for example due to a compromised Private Key. A Certificate may
also be re-keyed before (to maintain continuity of Certificate usage) or after expiration of the Certificate and/or its
key pair. It may also be re-keyed due to the issuance of a new hardware token.
Page - 24
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
4.7.2 Who May Request Certification of a New Public Key
2
3
The Device Sponsor of a device may request certification of a new public key or CAs and RAs may request
certification of a new public key on behalf of a device.
4
4.7.3 Processing Certificate Re-keying Requests
5
6
7
In all cases, it is required that the device provide proof of possession of the newly generated key pair's Private Key
before a new Certificate will be generated. This can be achieved in the manner described in Section 3.2.1.
Alternatively, device re-key requests may be processed using the same process used for initial certificate issuance.
8
4.7.4 Notification of New Certificate Issuance to Device Sponsors
9
Notification shall be given to the Device Sponsors in accordance with Section 4.3.2.
10
4.7.5 Conduct Constituting Acceptance of a Re-keyed Certificate
11
See Section 4.4.1.
12
4.7.6 Publication of the Re-keyed Certificate by the CA
13
Re-keyed certificates are published as in Section 4.4.2.
14
4.7.7 Notification of Certificate Issuance by the CA to Other Entities
15
No specific requirement.
16
Certificate Modification
17
All requests for Certificate modification shall be treated as new Certificate applications.
18
4.8.1 Circumstance for Certificate Modification
19
Not supported.
20
4.8.2 Who May Request Certificate Modification
21
Not supported.
22
4.8.3 Processing Certificate Modification Requests
23
Not supported.
24
4.8.4 Notification of New Certificate Issuance to Device
25
Not supported.
26
4.8.5 Conduct Constituting Acceptance of Modified Certificate
27
Not supported.
28
4.8.6 Publication of the Modified Certificate by the CA
29
30
31
Not supported.
4.8.7 Notification of Certificate Issuance by the CA to Other Entities
Not supported.
Page - 25
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
Certificate Revocation and Suspension
1
2
3
CAs operating under this policy shall issue CRLs covering all unexpired certificates issued under this policy except
for OCSP responder certificates that include the id-pkix-ocsp-nocheck extension.
4
5
6
7
CAs operating under this policy shall make public a description of how to obtain revocation information for the
certificates they publish, and an explanation of the consequences of using dated revocation information. This
information shall be given to Device Sponsors during the certificate request or issuance, and shall be readily
available to any potential relying party.
8
9
Revocation requests must be authenticated. Requests to revoke a Certificate may be authenticated using that
Certificate's associated Public Key, regardless of whether the Private Key has been compromised.
10
4.9.1 Circumstances for Revocation
11
12
Revocation shall occur on decision of the CA when reasonable and credible evidence exists to establish at least one
of the following:
13

the Certificate has been delivered based upon wrong or falsified information;
14

the identifying information or affiliation components of any names in the Certificate become invalid;
15

the confidentiality of a Private Key is no longer ensured or has been compromised;
16

the media holding the Private Key is suspected or known to have been compromised;
17
18

the Certificate fees have not been paid according to the payment terms as indicated in the relevant
agreement;
19

the Device Sponsor can be shown to have violated one or more sections of this CP; or
20

the Device Sponsor or the Device Sponsor's Employer wishes to terminate their Subscription to the CA
21
22
23
Whenever any of the above circumstances occur, the associated Certificate shall be revoked and placed on the CRL.
Revoked Certificates shall be included on all new publications of the Certificate status information until the
Certificates expire.
24
4.9.2 Who can Request Revocation
25
The revocation of an individual or End-Entity Certificate may only be requested by one of the following:
26

the Device Sponsor responsible for the server, device, or application;
27

the Device Sponsor's Employer organization;
28

the personnel of the Issuing CA; or
29

the personnel of any RA associated with the issuing CA.
30
31
For CA Certificates, authorized individuals representing the CA operations may request revocation of Certificates.
A written notice and brief explanation for the revocation shall subsequently be provided to the Device Sponsor.
32
4.9.3 Procedure for Revocation Request
33
34
A request to revoke a Certificate shall identify the Certificate to be revoked, explain the reason for revocation, and
allow the request to be authenticated (e.g.: digitally or manually signed).
35
36
The CA shall ensure that all procedures and requirements for revocation of a Certificate of this type are documented
in the CPS. Where a Device's Certificate is revoked, the revocation shall be published in the appropriate CRL.
37
38
39
40
For Certificates whose operation involves the use of a cryptographic hardware token, a Device Sponsor ceasing its
relationship with an organization that sponsored the Certificate shall, prior to departure, surrender to the
organization (through any accountable mechanism) all such hardware tokens that were issued by or on behalf of the
sponsoring organization. The contents of the token, or the token itself, shall be destroyed in accordance with
Page - 26
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
2
Section 6.2.10 promptly upon surrender and shall be protected from malicious use between surrender and such
destruction of the key.
3
4
5
If a Device Sponsor leaves an organization and the hardware tokens cannot be obtained from the Device Sponsor,
then all device Certificates associated with the un-retrieved tokens shall be immediately revoked for the reason of
key compromise.
6
4.9.4 Revocation Request Grace Period
7
8
There is no revocation grace period. Responsible parties must request revocation as soon as they identify the need
for revocation.
9
4.9.5 Time within which CA Must Process the Revocation Request
10
Revocation request shall be processed within 18 hours of receipt of request.
11
4.9.6 Revocation Checking Requirement for Relying Parties
12
13
14
15
16
17
Use of revoked Certificates could have damaging or catastrophic consequences in certain applications. The matter
of how often new revocation data should be obtained is a determination to be made by the Relying Party and the
system accreditor. If it is temporarily infeasible to obtain revocation information, then the Relying Party must either
reject use of the Certificate, or make an informed decision to accept the risk, responsibility, and consequences for
using a Certificate whose authenticity cannot be guaranteed to the standards of this policy. Such use may
occasionally be necessary to meet urgent operational requirements.
18
4.9.7 CRL Issuance Frequency
19
20
21
22
CRLs shall be issued periodically, even if there are no changes to be made, to ensure timeliness of information.
Certificate status information may be issued more frequently than the issuance frequency described below. A CA
shall ensure that superseded Certificate status information is removed from the PKI Repository upon posting of the
latest Certificate status information.
23
24
25
26
Certificate status information shall be published no later than the next scheduled update. This will facilitate the local
caching of Certificate status information for off-line or remote (laptop) operation. PKI participants shall coordinate
with the PKI Repositories to which they post certificate status information to reduce latency between creation and
availability.
27
The following table provides CRL issuance frequency requirements.
Routine
At least once every 24 hours
Loss/Compromise of
Private Key
Within 18 hours of notification
CA Compromise
Immediately, but no later than within 18 hours of
notification
28
29
CRL issuance frequency requirements may be further constrained by applicable jurisdictional regulatory law.
30
31
32
The CAs that issue routine CRLs less frequently than the requirement for Emergency CRL issuance (i.e.: CRL
issuance for loss or compromise of key or for compromise of CA) shall meet the requirements specified above for
issuing Emergency CRLs.
Page - 27
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
4.9.8 Maximum Latency for CRLs
2
3
The maximum delay between the time a device Certificate revocation request is received by a CA and the time that
this revocation information is available to Relying Parties shall be no greater than 24 hours.
4
4.9.9 On-line Revocation/Status Checking Availability
5
6
In addition to CRLs, CAs and Relying Party client software may optionally support online status checking with
OCSP. Client software using online status checking need not obtain or process CRLs.
7
8
9
If online revocation/status checking is supported by a CA, the latency of Certificate status information distributed
online by the CA or its delegated status responders shall meet or exceed the requirements for CRL issuance stated in
Section 4.9.7.
10
11
Since some relying parties may not be able to accommodate on-line communications, all CAs will be required to
support CRLs.
12
4.9.10 On-line Revocation Checking Requirements
13
14
Relying parties client software may optionally support on-line status checking. Client software using on-line status
checking need not obtain or process CRLs.
15
4.9.11 Other Forms of Revocation Advertisements Available
16
17
Any alternate forms used to disseminate revocation information shall be implemented in a manner consistent with
the security and latency requirements for the implementation of CRLs and online revocation and status checking.
18
4.9.12 Special Requirements Regarding Key Compromise
19
20
21
In the event of compromise or suspected compromise of the CA signing key, Senior Management of the CA
Operator and any Cross Certified CAs shall be immediately notified. A CRL must be issued within 19 hours of
notification. The requirements of Section 4.9.7 also apply.
22
4.9.13 Circumstances for Suspension
23
Certificate suspension is not supported by this CP.
24
4.9.14 Who can Request Suspension
25
Certificate suspension is not supported by this CP.
26
4.9.15 Procedure for Suspension Request
27
Certificate suspension is not supported by this CP.
28
4.9.16 Limits on Suspension Period
29
Certificate suspension is not supported by this CP.
30
Certificate Status Services
31
4.10.1 Operational Characteristics
32
33
Certificate status can be ascertained by querying the CRL maintained and published in its repository by the CA, or
by querying an OCSP Responder operated by the CA, if present.
Page - 28
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
4.10.2 Service Availability
2
3
Relying Parties are bound to their obligations and the stipulations of this CP irrespective of the availability of the
Certificate status service.
4
5
The CRL shall be publicly available 24 hours a day, 7 days a week. Care shall be taken by the CA to ensure that the
public copy is replaced atomically when it is being updated.
6
4.10.3 Optional Features
7
No specific requirement.
8
9
10
11
End of Subscription
A Device Sponsor may terminate his subscription either by allowing the device Certificate to expire without
renewing or re-keying it, or by revoking the Certificate before expiry without applying for a replacement.
Key Escrow and Recovery
12
4.12.1 Key Escrow and Recovery Policy and Practices
13
14
Under no circumstances shall any CA, end-entity, individual, role, or organizational signature key be escrowed by a
third party.
15
4.12.2 Session Key Encapsulation and Recovery Policy and Practices
16
17
This CP neither requires nor prohibits the capability of recovering session keys. CAs that support session key
encapsulation and recovery shall identify the document describing the practices in the applicable CPS.
Page - 29
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
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
27
28
The workstation of remote administrators of the CA shall be located such that all accesses may be monitored, and
that there are reasonable expectations that it would be impossible for a determined unauthorized individual to gain
access to the workstation.
29
5.1.2 Physical Access
30
5.1.2.1 Physical Access for CA Equipment
31
32
CA equipment shall always be protected from unauthorized access. The physical access controls for CA equipment,
as well as remote workstations used to administer the CAs, shall be auditable and:
33
34
35
36
37
38
39
40
41
42
43
44






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.
Provide at least three layers of increasing security such as perimeter, building, and CA bunker.
Require two-person physical access control to both the cryptographic module and computer systems.
Removable cryptographic modules shall be deactivated prior to storage. When not in use, removable cryptographic
modules and the activation information used to access or enable cryptographic modules shall be placed in secure
containers. Activation data shall be either memorized or recorded and stored in a manner commensurate with the
security afforded the cryptographic module, and shall not be stored with the cryptographic module or removable
hardware associated with remote workstations used to administer the CA.
Page - 30
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
2
3
4
5
6
7
8
A security check of the facility housing the CA equipment or remote workstations used to administer the CAs shall
occur if the facility is to be left unattended. At a minimum, the check shall verify the following:




The equipment is in a state appropriate to the current mode of operation (e.g., that cryptographic modules
are in place when “open,” and secured when “closed,” and for the CA, that all equipment other than the
repository is shut down).
Any security containers are properly secured.
Physical security systems (e.g., door locks, vent covers) are functioning properly.
The area is secured against unauthorized access.
9
10
11
12
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.
13
5.1.2.2 Physical Access for RA Equipment
14
15
16
17
RA equipment shall be protected from unauthorized access while the RA cryptographic module is installed and
activated. The RA shall implement physical access controls to reduce the risk of equipment tampering even when
the cryptographic module is not installed and activated. These security mechanisms shall be commensurate with the
level of threat in the RA equipment environment.
18
5.1.3 Power and Air Conditioning
19
20
21
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.
22
23
24
25
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.
26
5.1.4 Water Exposures
27
CA equipment shall be installed such that it prevents damage from exposure to water.
28
29
Potential water damage from fire prevention and protection measures (e.g., sprinkler systems) are excluded from this
requirement.
30
5.1.5 Fire Prevention and Protection
31
32
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.
33
5.1.6 Media Storage
34
35
36
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.
37
5.1.7 Waste Disposal
38
39
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.
40
5.1.8 Off-Site Backup
41
42
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,
Page - 31
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
2
3
4
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.
5
Requirements for CA private key backup are specified in section 6.2.4.
6
Procedural Controls
7
5.2.1 Corporate Controls
8
9
10
11
The CA must maintain its status as a legal entity in accordance with the national law stated in Section 9.2 The CA
must maintain a system of quality assurance consistent with recognized standards for all of its Certificate
management operations. The CA management structure shall ensure that they are free from any commercial,
financial, or other pressures which may impact the CA’s status as an impartial and trustable entity.
12
5.2.2 Trusted Roles
13
14
15
The CA shall ensure a separation of duties into trusted roles for critical CA functions to prevent one CA staff
member from malicious using the CA system without detection. Each such trusted role’s system access is to be
limited to those actions which they are required to perform in fulfilling their responsibilities.
16
17
18
19
20
21
A trusted role is one whose incumbent performs functions that can introduce security problems if not carried out
properly, whether accidentally or maliciously. The people selected to fill these roles must be extraordinarily
responsible, or the integrity of the CA will be weakened. The functions performed in these roles form the basis of
trust for the entire PKI. Two approaches are taken to increase the likelihood that these roles can be successfully
carried out. The first ensures that the person filling the role is trustworthy and properly trained. The second
distributes the functions among more than one person, so that any malicious activity would require collusion.
22
The roles are defined as:
23
1.
Administrator
24
2.
Officer
25
3.
Auditor
26
4.
Operator
27
5.
Registration Authority
28
Administrators and operators do not issue certificates to devices.
29
30
31
The roles required for each level of assurance are identified in Section 5.2.4. These five roles are employed at the
CA and RA locations as appropriate. Separation of duties shall comply with 5.2.4, and requirements for two person
control with 5.2.3, regardless of titles and numbers of Trusted Roles.
32
5.2.2.1 Administrator
33
The Administrator shall be responsible for:
34
35
36
37
38
39
40
 Installation, configuration, and maintenance of the CA and CSA (where applicable).
 Establishing and maintaining CA and CSA system accounts.
 Configuring certificate profiles or templates and audit parameters.
 Configuring CA, RA, and CSA audit parameters
 Configuring CSA response profiles
 Generating and backing up CA and CSA keys.
Administrators do not issue certificates.
41
5.2.2.2 Officer
42
The Officer shall be responsible for issuing certificates, that is:
Page - 32
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
2
3
4




Registering new devices and requesting the issuance of certificates.
Verifying the identity of Device Sponsors and accuracy of information included in certificates.
Approving and executing the issuance of certificates.
Requesting, approving, and executing the revocation of certificates.
5
5.2.2.3 Audit Administrator
6
The Audit Administrator shall be responsible for:
7
8
9


Reviewing, maintaining, and archiving audit logs.
Performing or overseeing internal compliance audits to ensure that the CA, associated RA, and CSA (where
applicable) is operating in accordance with the CPS.
10
5.2.2.4 Operator
11
12
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.
13
5.2.2.5 Registration Authority
14
The Registration Authority shall be responsible for:
15
16
17
18




Verifying identity information.
Entering device information and verifying correctness.
Securely communicating requests to and from CA.
Receiving and distributing certificate to the Device Sponsor.
19
5.2.3 Number of Persons Required per Task
20
21
22
23
24
25
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
26
Two or more persons are required for the following tasks:
27
28
29



CA key generation;
CA signing key activation;
CA private key backup.
30
31
32
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.2. Multiparty control shall not be achieved using personnel that serve
in the Auditor trusted role.
33
5.2.4 Identification and Authentication for Each Role
34
35
An individual shall identify and authenticate him/herself before being permitted to perform any actions set forth
above for that role or identity.
36
5.2.5 Roles Requiring Separation of Duties
37
38
39
40
41
Individuals may only assume one of the following roles: Officer, Administrator, and Auditor, but any individual
may assume the Operator role. The CA and RA 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 in a trusted role shall
have more than one identity.
Page - 33
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
2
Role separation, when required as mentioned above, may be enforced by either the CA equipment, or procedurally,
or by both means.
Personnel Controls
3
4
5.3.1 Qualifications, Experience, and Clearance Requirements
5
6
7
8
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.
9
10
11
12
13
14
15
16
17
18
19
20
21
22
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:








Possess the expert knowledge, experience and qualifications necessary for the offered services and
appropriate job function.
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 serious crime or other offense which affects his/her suitability for the
position.
Been appointed in writing by the CA management.
For CAs issuing medium-assurance certificates each person filling a trusted role shall satisfy at least one of the
following requirements:


23
24
25
26
27
28
29
30
31
32
The person shall be a citizen of the country where the CA is located; or
For CAs operated on behalf of multinational government organizations, the person shall be a citizen of one
of the member countries; or
 For CAs 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.
For RAs and Trusted Agents, in addition to the above, the person may be a citizen of the country where the function
is located.
33
5.3.2
34
35
All persons filling trusted roles (including CA trusted roles and RA role) shall, at a minimum, pass a background
investigation covering the following areas:
36
37
38
39
40
41






Background Check Procedures
Confirmation of previous employment;
Confirmation of the highest or most relevant educational degree;
Place of residence;
Search of criminal records;
Check of references;
Check of credit/financial records.
42
43
44
The period of investigation must cover at least the last five years for each area, except 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.
45
46
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:
Page - 34
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
2
3
4




Misrepresentations made by the candidate or Trusted Person
Highly unfavorable or unreliable personal references
Certain criminal convictions
Indications of a lack of financial responsibility
5
5.3.3 Training Requirements
6
7
All personnel performing duties with respect to the operation of the CA or RA shall receive comprehensive training.
Training shall be conducted in the following areas:
8
9
10
11
12





CA (or RA) security principles and mechanisms;
All PKI software versions in use on the CA (or RA) system;
All PKI duties they are expected to perform;
Disaster recovery and business continuity procedures; and
Stipulations of this policy.
13
5.3.4 Retraining Frequency and Requirements
14
15
16
17
All individuals responsible for PKI roles shall be made aware of changes in the CA or RA 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.
18
19
Documentation shall be maintained identifying all personnel who received training and the level of training
completed.
20
5.3.5 Job Rotation Frequency and Sequence
21
No stipulation.
22
5.3.6 Sanctions for Unauthorized Actions
23
24
The CA shall take appropriate administrative and disciplinary actions against personnel who have performed actions
involving the CA or its RA that are not authorized in this CP, CPSs, or other published procedures.
25
5.3.7 Independent Contractor Requirements
26
Contractors fulfilling trusted roles are subject to all personnel requirements stipulated in this policy.
27
28
PKI vendors who provide any services shall establish procedures to ensure that any subcontractors perform in
accordance with this policy and the CPS.
29
5.3.8
30
31
32
The CA shall make available to its personnel the CP they support, the CPS, and any relevant statues, policies, or
contracts. Other technical, operations, and administrative documents (e.g.: Administrator Manual, User Manual,
etc.) shall be provided in order for the trusted personnel to perform their duties.
33
34
35
36
37
38
Documentation Supplied to Personnel
Audit Logging Procedures
Audit log files shall be generated for all events relating to the security of the CAs and RAs. 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.
Page - 35
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
5.4.1
2
3
4
All security auditing capabilities of the CA and RA operating system and the CA and RA 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):
5
6
7
8
9
10
11
12
13






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.
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.
The CA/RA shall record the events identified in the list below. Where these events cannot be electronically logged,
the CA/RA shall supplement electronic audit logs with physical logs as necessary.
Auditable Event
CA
CSA
RA
Any changes to the Audit parameters, e.g., audit frequency, type of event
audited
X
X
X
Any attempt to delete or modify the Audit logs
X
X
X
Successful and unsuccessful attempts to assume a role
X
X
X
The value of maximum authentication attempts is changed
X
X
X
The number of unsuccessful authentication attempts exceeds the maximum
authentication attempts during user login
X
X
X
An Administrator unlocks an account that has been locked as a result of
unsuccessful authentication attempts
X
X
X
An Administrator changes the type of authentication, e.g., from a password to
biometric
X
X
X
X
X
X
X
X
X
X
X
X
SECURITY AUDIT
IDENTIFICATION AND AUTHENTICATION
LOCAL DATA ENTRY
All security-relevant data that is entered in the system
REMOTE DATA ENTRY
All security-relevant messages that are received by the system
DATA EXPORT AND OUTPUT
All successful and unsuccessful requests for confidential and security-relevant
information
KEY GENERATION
Page - 36
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
Whenever the device generates a key. (Not mandatory for single session or
one-time use symmetric keys)
X
X
X
The loading of device private keys
X
X
X
All access to certificate subject private keys retained within the CA for key
recovery purposes
X
N/A
N/A
X
X
X
X
X
X
X
X
X
X
N/A
X
X
N/A
X
X
N/A
N/A
X
X
X
Roles and users are added or deleted
X
-
-
The access control privileges of a user account or a role are modified
X
-
-
X
N/A
N/A
N/A
X
N/A
PRIVATE KEY LOAD AND STORAGE
TRUSTED PUBLIC KEY ENTRY, DELETION AND STORAGE
All changes to the trusted public keys, including additions and deletions
SECRET KEY STORAGE
The manual entry of secret keys used for authentication
PRIVATE AND SECRET KEY EXPORT
The export of private and secret keys (keys used for a single session or
message are excluded)
CERTIFICATE REGISTRATION
All certificate requests
CERTIFICATE REVOCATION
All certificate revocation requests
CERTIFICATE STATUS CHANGE APPROVAL
The approval or rejection of a certificate status change request
CA CONFIGURATION
Any security-relevant changes to the configuration of the component
ACCOUNT ADMINISTRATION
CERTIFICATE PROFILE MANAGEMENT
All changes to the certificate profile
CERTIFICATE STATUS AUTHORITY MANAGEMENT
All Changes to the CSA profile (e.g. OCSP Profile)
Page - 37
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
REVOCATION PROFILE MANAGEMENT
All changes to the revocation profile
X
N/A
N/A
X
N/A
N/A
Appointment of an individual to a trusted role
X
X
X
Designation of personnel for multiparty control
X
-
N/A
Installation of the operating system
X
X
X
Installation of the PKI Application
X
X
X
Installing hardware cryptographic modules
X
X
X
Removing hardware cryptographic modules
X
X
X
Destruction of cryptographic modules
X
X
X
System startup
X
X
X
Logon attempts to PKI applications
X
X
X
Receipt of hardware / software
X
X
X
Attempts to set passwords
X
X
X
Attempts to modify passwords
X
X
X
Backing up CA internal database
X
-
-
Restoration from backup of the internal CA database
X
-
-
File manipulation (e.g., creation, renaming, moving)
X
-
-
Posting of any material to a PKI repository
X
-
-
Access to CA internal database
X
X
-
All certificate compromise notification requests
X
N/A
X
Re-key of the Component
X
X
X
X
X
-
CERTIFICATE REVOCATION LIST PROFILE MANAGEMENT
All changes to the Certificate Revocation List profile
MISCELLANEOUS
Configuration changes
Hardware
Page - 38
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
Software
X
X
X
Operating system
X
X
X
Patches
X
X
-
Security profiles
X
X
X
Personnel access to room housing Component
X
-
-
Access to the Component
X
X
-
Known or suspected violations of physical security
X
X
X
Software error conditions
X
X
X
Software check integrity failures
X
X
X
Receipt of improper messages
X
X
X
Misrouted messages
X
X
X
Network attacks (suspected or confirmed)
X
X
X
Equipment failure
X
-
-
Electrical power outages
X
-
-
Uninterruptible Power Supply (UPS) failure
X
-
-
Obvious and significant network service or access failure
X
-
-
Violations of Certificate Policy
X
X
X
Violations of Certificate Practice Statement
X
X
X
Resetting Operating System Clock
X
X
X
PHYSICAL ACCESS / SITE SECURITY
ANOMALIES
1
2
5.4.2
Frequency of Processing Log
3
4
5
6
7
8
9
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. Statistically significant samples of
security audit data generated by the CA, CSA, or RA since the last review shall be examined (where the confidence
intervals for each category of security audit data are determined by the security ramifications of the category and the
availability of tools to perform such a review), as well as a reasonable search for evidence of malicious activity. The
Audit Administrator shall explain all significant events in an audit log summary. Actions taken as a result of these
reviews shall be documented.
Page - 39
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
2
3
Such reviews involve verifying that the log has not been tampered with, there is no discontinuity or other loss of
audit data, and then briefly inspecting all log entries, with a more thorough investigation of any alerts or
irregularities in the logs.
4
5.4.3 Retention Period for Audit Log
5
6
7
8
Audit logs shall be retained onsite for at least sixty days and must be retained in the manner described below. For
the CA and CSA, the Audit Administrator shall be the only person managing the audit log (e.g., review, backup,
rotate, delete, etc.). For the RA, a system administrator other than the RA shall be responsible for managing the
audit log.
9
5.4.4 Protection of Audit Logs
10
11
12
13
System configuration and operational procedures shall be implemented together to ensure that:



Only authorized people have read access to the logs;
Only authorized people may archive audit logs; and
Audit logs are not modified.
14
15
16
The person performing audit log archive need not have modify access, but procedures must be implemented to
protect archived data from destruction prior to the end of the audit log retention period (note that deletion requires
modification access). Audit logs shall be moved to a safe, secure storage location separate from the CA equipment.
17
It is acceptable for the system to over-write audit logs after they have been backed up and archived.
18
5.4.5 Audit Log Backup Procedures
19
20
21
Audit logs and audit summaries shall be backed up at least monthly, unless the CA is offline, in which case audit
logs and audit summaries shall be backed up when the system is activated or every 30 days, whichever is later. A
copy of the audit log shall be sent off-site in accordance with the CPS following review.
22
5.4.6 Audit Collection System (Internal vs. External)
23
24
25
26
27
The audit log collection system may or may not be external to the CA, CSA, or RA system. Automated audit
processes shall be invoked at system or application startup, and cease only at system or application shutdown.
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, then the CA shall determine whether to suspend
CA operation until the problem is remedied.
28
5.4.7 Notification to Event-Causing Subject
29
30
There is no requirement to notify a subject that an event was audited. Real-time alerts are neither required nor
prohibited by this policy.
31
5.4.8 Vulnerability Assessments
32
No stipulation beyond Section 5.4.2.
33
Records Archival
34
5.5.1 Types of Events Archived
35
36
37
CA, CSA, and RA archive records shall be sufficiently detailed to determine the proper operation of the PKI 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:
CA
Data To Be Archived
Page - 40
WiMAX FORUM PROPRIETARY
CSA
RA
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
Certificate Policy
X
X
X
Certification Practice Statement
X
X
X
Contractual obligations
X
X
X
System and equipment configuration
X
X
-
Modifications and updates to system or configuration
X
X
-
Certificate requests
X
-
-
All certificates issued and/or published
X
N/A
N/A
Record of Component re-key
X
X
X
Revocation requests
X
-
-
Device Sponsor identity authentication data as per section 3.2.3.
X
N/A
X
Documentation of receipt and acceptance of certificates
X
N/A
X
Subscriber Agreements
X
N/A
X
Documentation of receipt of tokens
X
N/A
X
All CRLs issued and/or published
X
N/A
N/A
All Audit logs
X
X
X
Other data or applications to verify archive contents
X
X
X
Compliance Auditor reports
X
X
X
1
2
5.5.2 Retention Period for Archive
3
4
Archive records must be kept for a minimum of 10 years and 6 months, or as further required by applicable law or
industry regulation.
5
6
7
8
9
If the original media cannot retain the data for the required period, a mechanism to periodically transfer the archived
data to new media shall be defined by the archive site. Alternatively, an Entity may retain data using whatever
procedures have been approved by U.S. National Archives and Records Administration for that category of
documents. Applications required to process the archive data shall also be maintained for the minimum retention
period specified above.
10
5.5.3 Protection of Archive
11
12
The archive must be protected as specified by the privacy laws of the country where the device information was
collected.
13
14
15
No unauthorized user shall be permitted to write to, modify, or delete the archive. For the CA and CSA, the
authorized individuals are Audit Administrators. For the RA, authorized individuals are someone other than the RA
(e.g.: Information Assurance Officer or IAO). The contents of the archive shall not be released except as determined
Page - 41
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
2
3
4
by the CA, or as required by law. Records of individual transactions may be released upon request of any Device
Sponsors involved in the transaction or their legally recognized agents. Archive media shall be stored in a safe,
secure storage facility separate from the PKI components (CA, CSA, or RA) with physical and procedural security
controls equivalent or better than those for the PKI.
5
5.5.4 Archive Backup Procedures
6
7
The CPS or a referenced document shall describe how archive records are backed up, and how the archive backups
are managed.
8
5.5.5 Requirements for Time-Stamping of Records
9
10
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.
11
5.5.6 Procedures to Obtain and Verify Archive Information
12
13
Procedures, detailing how to create, verify, package, transmit, and store archive information, shall be described in
the applicable CPS.
14
15
16
Key Changeover
No specific Requirement
Compromise and disaster recovery
17
5.7.1 Incident and Compromise Handling Procedures
18
Each organization operating an Entity PKI shall have a formal disaster recovery plan.
19
20
21
If a CA or CSA detects a potential hacking attempt or other form of compromise, it shall perform an investigation in
order to determine the nature and the degree of damage. If the CA or CSA key is suspected of compromise, the
procedures outlined in Section Error! Reference source not found. shall be followed.
22
23
24
25
26
The APPA shall be notified if any CAs operating under this policy experiences the following:
 suspected or detected compromise of the CA systems;
 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.
27
The APPA will take appropriate steps to protect the integrity of the PKI.
28
29
The CA’s Management Authority shall reestablish operational capabilities as quickly as possible in accordance with
procedures set forth in the CA's CPS.
30
5.7.2 Computing Resources, Software, and/or Data Are Corrupted
31
32
33
34
35
36
37
38
39
40
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 Device Sponsors’ interests as Relying Parties.
Page - 42
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
2
3
4
5
6

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 Device Sponsors whose devices use the CA as a trust anchor to delete the trust anchor.
5.7.3 Private Key Compromise Procedures
7
8
9
10
11
12
13
14
15
16
17
If a CA’s signature keys are compromised, lost, or suspected of compromise:
1. All cross certificated CAs shall be securely notified at the earliest feasible time (so that entities may issue
CRLs revoking any cross-certificates issued to the CA);
2. A new CA key pair shall be generated by the CA in accordance with procedures set forth in the applicable
CPS;
3. New CA certificates shall be requested in accordance with the initial registration process described
elsewhere in this CP;
4. If the CA can obtain accurate information on the certificates it has issued and that are still valid (i.e. not
expired or revoked), the CA may re-issue (i.e., renew) those certificates with the notAfter date in the
certificate remaining the same as in original certificates; and
5. If the CA is a Root CA, it shall provide the Device Sponsors the new trust anchor using secure means.
18
19
The APPA shall also investigate what caused the compromise or loss, and what measures must be taken to preclude
recurrence.
20
21
22
23
If a CSA key is compromised, all certificates issued to the CSA shall be revoked, if applicable. The CSA will
generate a new key pair and request new certificate(s), if applicable. If the CSA is a trust anchor, the relying parties
will be provided the new trust anchor in a secure manner (so that the trust anchor integrity is maintained) to replace
the compromised trust anchor.
24
25
26
27
28
29
30
31
32
If RA signature keys are compromised, lost, or suspected of compromise:
1. The RA certificate shall be revoked immediately;
2. The new RA key pair shall be generated in accordance with procedures set forth in the applicable CPS;
3. A new RA certificate shall be requested in accordance with the initial registration process described
elsewhere in this CP;
4. All certificate registration requests approved by the RA since the date of the suspected compromise shall be
reviewed to determine which are legitimate;
5. For those certificate requests or approval whose legitimacy cannot be ascertained, the resultant certificates
shall be revoked and their subjects (Device Sponsor’s) shall be notified of revocation.
33
5.7.4 Business Continuity Capabilities after a Disaster
34
35
The CA Operator shall provide an alternate secure facility that conforms to all the provisions of the present
document for resumption of the CA following any CA service interruption.
36
CA, CSA, or RA Termination
37
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 APPA.
40
41
42
43
Prior to CA termination, the CA shall provide archived data to an archive facility 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.
Page - 43
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
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
Key pair generation shall be performed using FIPS 140 rated 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.
7
The following table provides the requirements for key pair generation for the various entities:
Hardware
Entity
FIPS 140-1/2 Level
Or
Software
Key Storage Restricted To the
Module on Which the Key
Was Generated
Root CA
3
Hardware
Yes
CA
2
Hardware
Yes
RA
2
Hardware
Yes
CSA
2
Hardware
Yes
Device
1
Software
No Requirement
8
9
10
Random numbers for medium-hardware assurance level keys shall be generated in FIPS 140 Level 2 approved
hardware cryptographic modules.
11
12
13
When private keys are not generated on the token to be used, originally generated private keys shall be destroyed
after they have been transferred to the token. This does not prohibit the key generating modules to act as the key
escrow module as well.
14
6.1.1.1 CA Key Pair Generation
15
16
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.
17
18
19
20
CA key pair generation must create a verifiable audit trail showing 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.
21
6.1.1.2 Device Key Pair Generation
22
23
Device key pair generation may be performed by the device, CA, or RA. If the CA or RA generates device key
pairs, the requirements for key pair delivery specified in section 6.1.2 must also be met.
24
6.1.2 Private Key Delivery to Devices
25
A CA shall generate its own key pair and therefore does not need private key delivery.
26
27
Device key pair generation may be performed by the device. In this case, the private key delivery to a device is
unnecessary.
Page - 44
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
2
3
4
5
6
7
8
9
10
11
12
13
14
When a CA or RA generates key pairs on behalf of a device, the private keys must be delivered securely to the
device and the following requirements must be met:




Anyone who generates a private signing key for a device shall not retain any copy of the key after delivery
of the private key to the device.
The private key shall be protected from activation, compromise, or modification during the delivery
process.
The Device Sponsor 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 devices.
o For hardware cryptographic modules, accountability for the location and state of the module must
be maintained until the device accepts possession of it.
o 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.
15
The CA or the RA shall maintain a record of the Device Sponsor acknowledgement of receipt of the token.
16
6.1.3 Public Key Delivery to Certificate Issuer
17
18
19
20
Where key pairs are generated by the device or RA, the public key and the device’s identity shall be delivered
securely to the CA for certificate issuance. The delivery mechanism shall bind the device’s verified identity to the
public key. If cryptography is used to achieve this binding, it shall be at least as strong as the CA keys used to sign
the certificate.
21
6.1.4 CA Public Key Delivery to Relying Parties
22
23
24
The public key of a trust anchor shall be provided to the devices acting as relying parties in a secure manner so that
the trust anchor is not vulnerable to modification or substitution. Acceptable methods for delivery of a trust anchor
include but are not limited to:
25
26
27
28
29
30
31
32




Loading a trust anchor onto tokens delivered to relying parties via secure mechanisms.
Secure distribution of trust anchor through secure out-of-band mechanisms.
Comparison of Certificate hash (fingerprint) against the trust anchor hash made available via authenticated
out-of-band sources (note that fingerprints or hashes posted in-band along with the Certificate are not
acceptable as an authentication mechanism.
Downloading a trust anchor from trusted web sites (CA or PKI-PA web site) secured with a currently valid
Certificate of equal or greater assurance level than the Certificate being downloaded and the trust anchor is
not in the certification chain for the web site Certificate.
33
34
Systems using cryptographic hardware tokens shall store trusted certificates such that unauthorized alteration or
replacement is readily detectable.
35
6.1.5 Key Sizes
36
37
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.
38
AeroMACS certificates shall meet the following requirements for algorithm type and key size:
Table 1: Algorithm Type and Key Size
39
Root CA
Sub-CA
Device Cert
Digest Algorithm
SHA-256
SHA-256
SHA-256
Elliptic Curve
P-256, 384
P-256, 384
P-256
Page - 45
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
Cryptography
1
2
6.1.6 Public Key Parameters Generation and Quality Checking
3
4
Elliptic Curve Cryptography (ECC) keys shall be generated in accordance with FIPS 186-2, and curves from FIPS
186-2 shall be used.
5
6.1.7 Key Usage Purposes (as per X.509 v3 Key Usage Field)
6
The use of a specific key is constrained by the keyUsage extension in the X.509 certificate.
7
8
9
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):
10
11
12



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
Table 2: keyUsage Extension for all CA certificates
13
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
14
15
16
17
18
19
20
21
Table 3 shows the specific keyUsage extension settings for AeroMACS Device and Server certificates and specifies
that all Device and Server certificates:




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
Table 3: keyUsage Extension for all Device Certificates
Page - 46
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
Field
keyUsage
1
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
6.2.1 Cryptographic Module Standards and Controls
5
6
7
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.
8
The relevant standard for cryptographic modules is Security Requirements for Cryptographic Modules [FIPS 140-2].
9
10
The table in Section 6.1.1 summarizes the minimum requirements for cryptographic modules; higher levels may be
used. In addition, private keys shall not exist outside the cryptographic module in plaintext form.
11
6.2.2 Private Key (n out of m) Multi-Person Control
12
13
14
15
A single person shall not be permitted to activate or access any cryptographic module that contains the complete CA
private signing key. CA signature keys may be backed up only under two-person control. Access to CA signing
keys backed up for disaster recovery shall be under at least two-person control. The names of the parties used for
two-person control shall be maintained on a list that shall be made available for inspection during compliance audits.
16
6.2.3 Private Key Escrow
17
CA private signature keys and Device private signatures keys shall not be escrowed.
18
19
If the CA retains the device private encryption keys for business continuity purposes, the CA shall escrow such keys
to protect them from unauthorized modification or disclosure through physical and cryptographic means.
20
6.2.4 Private Key Backup
21
22
The CA private signature keys shall be backed up under the same multi-person control as the original signature key.
At least one copy of the private signature key shall be stored off-site. All copies of the CA private signature key
Page - 47
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
2
shall be accounted for and protected in the same manner as the original. Backup procedures shall be included in the
CA’s CPS.
3
4
5
6
Device private keys may be backed up or copied, but must be held under the control of the device’s human sponsor
or other authorized administrator. Backed up device private keys shall not be stored in plaintext form outside the
cryptographic module. Storage must ensure security controls consistent with the protection provided by the device’s
cryptographic module.
7
6.2.5 Private Key Archival
8
9
10
11
12
CA private signature keys and device private signatures keys shall not be archived. 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.
13
14
15
For some applications (e.g. protected aircraft to ground communications), the device key may be archived, upon
crypto-period expiration and/or key replacement, to support recovery of protected messages, as necessary to comply
with regulatory requirements regarding data retention.
16
6.2.6 Private Key Transfer into or from a Cryptographic Module
17
18
19
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.
20
21
22
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.
23
Private or symmetric keys used to encrypt other private keys for transport must be protected from disclosure.
24
25
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.
26
6.2.7 Private Key Storage on Cryptographic Module
27
No stipulation beyond that specified in FIPS 140.
28
6.2.8 Method of Activating Private Key
29
30
All CAs shall protect the activation data for their private keys against loss, theft, modification, disclosure, or
unauthorized use.
31
CA Administrator Activation
32
Method of activating the CA system by a CA Administrator shall require:
33
34
35
36
37
38


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.
39
Offline CAs Private Key
40
41
42
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.
43
Online CAs Private Keys
Page - 48
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
2
3
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.
4
Device Private Keys
5
6
7
8
A 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.
9
6.2.9 Method of Deactivating Private Key
10
11
12
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.
13
14
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.
15
16
17
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.
18
19
20
When deactivated, private keys shall be kept in encrypted form only. They shall be cleared from memory before the
memory is de-allocated. Any disk space where Private Keys were stored shall be overwritten before the space is
released to the operating system.
21
6.2.10 Method of Destroying Private Key
22
23
24
25
Private signature keys shall be destroyed when they are no longer needed, or when the certificates to which they
correspond expire or are revoked. For software cryptographic modules, this can be accomplished by overwriting the
data. For hardware cryptographic modules, this will usually require a “zeroize” command. Physical destruction of
hardware is generally not required.
26
6.2.11 Cryptographic Module Rating
27
See CP section 6.2.1.
28
Other Aspects of Key Pair Management
29
6.3.1 Public Key Archival
30
31
The public key is archived as part of the certificate archival. The issuing CA shall retain all verification public keys
for a minimum of twenty (20) years or as further required by applicable law or industry regulation.
32
6.3.2 Certificate Operational Periods and Key Pair Usage Periods
33
34
The following table provides the life times for the private keys and certificates issued to the owner of the private
key.
Key
Private Key
Certificate
Self-signed Root CA
30 Years
30 Years
CA
20 Years
20 Years
CSA
10 Years
10 Years
Page - 49
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
Device
3-5 Years
3-5 Years
Server
1 Year
1 Year
1
2
3
Validity periods shall be nested such that the validity periods of issued certificates shall be contained within the
validity period of the issuing CA.
4
AeroMACS PKI Participants shall cease all use of their key pairs after their validity periods have expired.
5
Cross certificates shall not be valid for more than 10 years.
Activation data
6
7
6.4.1 Activation Data Generation and Installation
8
9
10
11
12
13
14
The activation data used to unlock private keys, in conjunction with any other access control, shall have an
appropriate level of strength for the keys or data to be protected and shall meet the applicable security policy
requirements of the cryptographic module used to store the keys. RA and device activation data may be userselected. The strength of the activation data shall meet or exceed the requirements for authentication mechanisms
stipulated for Level 2 in FIPS 140-2. For CAs, it shall either entail the use of biometric data or satisfy the policyenforced at/by the cryptographic module. If the activation data must be transmitted, it shall be via an appropriate
protected channel, and distinct in time and place from the associated cryptographic module.
15
16
17
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. These passwords shall be changed upon CA re-key.
18
6.4.2
19
20
21
22
23
24
Data used to unlock private keys shall be protected from disclosure by a combination of cryptographic and physical
access control mechanisms. Activation data should be either biometric in nature or memorized. If written down, it
shall be secured at the level of the data that the associated cryptographic module is used to protect, and shall not be
stored with the cryptographic module. In all cases, the protection mechanism shall include a facility to temporarily
lock the account, or terminate the application, after a predetermined number of failed login attempts as set forth in
the respective CP or CPS.
25
6.4.3 Other Aspects of Activation Data
26
CAs, CSAs, and RAs shall change the activation data whenever the token is re-keyed or returned for maintenance.
Activation Data Protection
Computer security controls
27
28
6.5.1 Specific Computer Security Technical Requirements
29
30
31
The following computer security functions may be provided by the operating system, or through a combination of
operating system, software, and physical safeguards. The CA, CSA and RA shall include the following
functionality:
32
33
34
35
36
37
38
39







Require authenticated logins
Provide Discretionary Access Control, including managing privileges of users to limit users to their
assigned roles
Provide a security audit capability (See Section 5.4)
Prohibit object re-use
Require use of cryptography for session communication and database security
Require a trusted path for identification and authentication
Provide domain isolation for processes
Page - 50
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
2
3



Provide self-protection for the operating system
Require self-test security related CA services (e.g., check the integrity of the audit logs)
Support recovery from key or system failure
4
5
The computer system shall be configured with the minimum of the required accounts and network services, and
shall not permit remote login.
6
The computer system hosting the CA must have been hardened against all known threats.
7
6.5.2 Computer Security Rating
8
No Stipulation.
9
Life Cycle Technical Controls
10
6.6.1 System Development Controls
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
The system development controls for the CA and CSA are as follows:
 Use software that has been designed and developed under a formal, documented development
methodology.
 Procured hardware and software shall be purchased in a fashion to reduce the likelihood that any particular
component was tampered with (e.g., by ensuring the equipment was randomly selected at time of
purchase).
 Specially-developed hardware and software shall be developed in a controlled environment, and the
development process shall be defined and documented. This requirement does not apply to commercial offthe-shelf hardware or software.
 All hardware must be shipped or delivered via controlled methods that provide a continuous chain of
accountability from the purchase location to the operations location.
 The hardware and software shall be dedicated to performing PKI activities. There shall be no other
applications; hardware devices, network connections, or component software installed which is not part of
the PKI operation.
 Proper care shall be taken to prevent malicious software from being loaded onto the equipment.
Applications required to perform PKI operations shall be obtained from sources authorized by local policy.
CA, CSA, and RA hardware and software shall be scanned for malicious code on first use and periodically
thereafter.
 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.
31
6.6.2 Security Management Controls
32
33
34
35
The configuration of the CA and CSA system, in addition to any modifications and upgrades, shall be documented
and controlled. The CA and CSA software, when first loaded, shall be verified as being that supplied from the
vendor, with no modifications, and be the version intended for use. The CA and CSA system shall provide a
mechanism to periodically verify the integrity of the software as specified in the CPS.
36
The CA shall also have mechanisms and policies in place to control and monitor the configuration of the CA system.
37
6.6.3 Life Cycle Security Controls
38
No Stipulation.
39
40
41
42
43
Network Security Controls
CAs, CSAs, and RAs shall employ appropriate security measures to ensure they are guarded against denial of
service and intrusion attacks. Such measures shall include the use of guards, firewalls and filtering routers. Unused
network ports and services shall be turned off. Any network software present shall be necessary to the functioning of
the Entity CA.
Page - 51
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
2
Any boundary control devices used to protect the network on which the PKI equipment is hosted shall deny all but
the necessary services to the PKI equipment even if those services are enabled for other devices on the network.
Time-Stamping
3
4
5
6
All CA and CSA components shall regularly synchronize with a time service such as National Institute of Standards
and Technology (NIST) Atomic Clock or NIST Network Time Protocol (NTP) Service. Time derived from the time
service shall be used for establishing the time of:
7

Initial validity type of a Device’s Certificate;
8

Revocation of a Device’s Certificate
9

Posting of CRL updates; and
10

OCSP or other CSA responses.
11
12
13
Certificates, CRLs, and other revocation database entries shall contain time and date information. 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).
14
Page - 52
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
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 Table 4).
Table 4: 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 - 53
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
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 5 shows the certificate extensions for all AeroMACS Root CA certificates.
Table 5: Root CA Certificate Standard Extensions
6
Field
7
Referenced
Standard
Section
Requirement or Recommendation
subjectKeyIdentifier
[RFC 5280]
4.2.1.2
See Table 9.
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 Table 10.
Table 6 shows the certificate extensions for all AeroMACS CA certificates.
Table 6: CA Certificate Standard Extensions
8
Field
Referenced
Standard
Section
Requirement or Recommendation
authorityKeyIdentifier
[RFC 5280]
4.2.1.1
Shall be included in CA certificates.
Criticality shall be set to FALSE.
subjectKeyIdentifier
[RFC 5280]
4.2.1.2
See Table 9.
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 CA certificates.
Criticality shall be set to FALSE.
See Table 11.
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 7 shows the certificate extensions for all AeroMACS device certificates.
Page - 54
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
Table 7: Device Certificate Standard Extensions
1
Field
2
Referenced
Standard
Section
Requirement or Recommendation
authorityKeyIdentifier
[RFC 5280]
4.2.1.1
Shall be included in Device 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
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 Table 12 for server certificates.
Table 8 shows the certificate extensions for all AeroMACS OCSP server certificates.
Table 8: 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 9 shows the subjectKeyIdentifier extension settings for AeroMACS CA certificates and specifies that all
AeroMACS Root and CA certificates:
8
9
10
11



Shall include the subjectKeyIdentifier extension
Shall set the criticality of the subjectKeyIdentifier extension to FALSE
Shall calculate the keyIdentifier of the subjectKeyIdentifier per Method 1
Table 9: subjectKeyIdentifier Extension for AeroMACS CA Certificates
Field
subjectKeyIdentifier
Format
Criticality
Value
FALSE
{ id-ce 14 }
Comment
Included in all CA certificates
Page - 55
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
keyIdentifier
OCTET
STRING
<key identifier>
Calculated per Method 1.
1
Device Certificates shall not include the subjectKeyIdentifier extension.
2
Basic Constraints Extension
3
4
Table 10 shows the basicConstraints extension settings for AeroMACS Root CA certificates and specifies that all
AeroMACS Root CA certificates:
5
6
7



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 10: basicConstraints Extension for AeroMACS Root CA Certificates
8
Field
Format
basicConstraints
cA
BOOLEAN
pathLenConstraint
INTEGER
Criticality
Value
TRUE
{ id-ce 19 }
TRUE
Comment
Included in all Root certificates
Set
Not Set
9
10
11
12
13
14
15
Table 11 shows the basicConstraints extension settings for AeroMACS CA certificates and specifies that all
AeroMACS 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 11: basicConstraints Extension for AeroMACS CA Certificates
16
Field
Format
basicConstraints
Criticality
Value
TRUE
{ id-ce 19 }
cA
BOOLEAN
TRUE
pathLenConstraint
INTEGER
0
Comment
Included in all CA certificates
Set
17
Device Certificates shall not include the basicConstraints extension.
18
19
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.
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.
22
Extended Key Usage
23
CA Certificates shall not include the extKeyUsage extension.
24
25
Table 12 shows the extKeyUsage extension settings for AeroMACS server certificates and specifies that all
AeroMACS server certificates:
Page - 56
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
2
3



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 and id-kp-clientAuth
Table 12: extKeyUsage Extension for AeroMACS Server Certificates
4
Field
Format
Criticality
Value
FALSE
{ id-ce 37 }
extKeyUsage
keyPurposeID
OID
Comment
May be included in device server
certificates.
1.3.6.1.5.5.7.3.1
id-kp-serverAuth
1.3.6.1.5.5.7.3.2
id-kp-clientAuth
5
6
7.1.3 Algorithm Object Identifiers (OIDs)
7
8
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 13).
Table 13: Signature OIDS for Certificates
9
Field
Format
Criticality
Value
Comment
signature
algorithmIdentifier
10
11
algorithm
OID
parameters
ANY
1.2.840.10045.4.3.2
ecdsa-with-Sha256
Absent
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 14).
Table 14: subjectPublicKeyInfo for Certificates
12
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
secp384r1
subjectPublicKey
BIT STRING
<subject public key>
Page - 57
WiMAX FORUM PROPRIETARY
EC Public Key
Modulus length.
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
See CP section 6.1.5.
1
2
7.1.4 Name Forms
3
Root CAs
4
5
The following naming attributes shall be used to populate the issuer and subject fields in Root CA Certificates
issued under this CP:
Table 15: Root CA Certificate Issuer and Subject Fields
6
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)
7
8
CAs
9
The following naming attributes shall be used to populate the CA Certificate subject fields issued under this CP:
Table 16: CA Certificate Subject Fields
10
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>
Shall contain the issuer organization name (or
abbreviation thereof), trademark, or other
meaningful identifier.
organizationalUnitName
(OU=)
<CA type>
CA<Id#>
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”.
Page - 58
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
commonName
(CN=)
<Name> CA
Shall contain a name that accurately identifies
the CA. (e.g. CompanyA CA)
1
2
Device Certificates
3
The following naming attributes shall be used to populate the Subject in Device Certificates issued under this CP:
Table 17: Device Certificate Subject Fields
4
Name
Field
Value
Requirement
countryName
(C=)
<Country
Name>
Shall be the two-letter ISO 3166-1 country code
for the country in which the device’s place of
business is located.
organizationName
(O=)
<Organization>
Shall contain the device 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>
For Device Certs: Shall contain the device
MAC Address that is bound into the certificate
that will bind the certificate’s public key to the
device.
For Server Certs: Shall contain the domain
name of Service Provider that is bound into the
certificate that will bind the certificate’s public
key to the device.
5
6
7.1.5 Name Constraints
7
The CAs shall not assert name constraints in AeroMACS certificates.
8
7.1.6 Certificate Policy Object Identifier
9
CA and device certificates issued under this CP shall assert the policy OID listed in Section 1.2.2 of this document.
10
11
12
13
Table 18 shows the certificatePolicies extension settings for AeroMACS certificates and specifies that all
AeroMACS certificates:


May include the certificatePolicies extension
If included, shall set the criticality of the certificatePolicies extension to FALSE
14
Table 18: certificatePolicies Extension for AeroMACS Certificates
15
Field
Format
Criticalit
y
Value
Page - 59
WiMAX FORUM PROPRIETARY
Comment
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
FALSE
certificatePolicies
{ id-ce 32 }
May be included in all
AeroMACS
certificates
policyInformation
policyIdentifier
OID
<Certificate policy
OID>
policyQualifiers
SEQUENCE
See Section 1.2.2
Not Set
1
2
7.1.7 Usage of Policy Constraints Extension
3
The CAs shall not assert policy constraints in CA certificates.
4
7.1.8 Policy Qualifiers Syntax and Semantics
5
Certificates issued under this CP shall not contain policy qualifiers.
6
7.1.9 Processing Semantics for the Critical Certificate Policies Extension
7
8
Processing semantics for the critical certificate policy extension shall conform to X.509 certification path processing
rules.
CRL Profile
9
10
CRLs shall conform to [RFC 5280] and contain the basic fields and contents specified in the table below:
Table 19: CRL Profile Basic Fields
11
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
Algorithm used to sign the CRL.
Page - 60
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
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.
1
2
7.2.1 Version Number(s)
3
4
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].
5
7.2.2 CRL and CRL entry extensions
6
Critical CRL extensions shall not be used.
OCSP Profile
7
8
9
10
11
12
13
OCSP 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].
14
7.3.1 Version Number(s)
15
OCSP responses shall support use of OCSP version 1 as defined by [RFC2560] and [RFC5019].
16
7.3.2 OCSP Extensions
17
Critical OCSP extensions shall not be used.
Page - 61
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
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
7
All CAs, RAs and CSAs operating under this policy shall be subject to a periodic compliance audit at least once per
year.
Identity and Qualifications of Assessor
8
9
10
11
12
The compliance auditor shall demonstrate competence in the field of compliance audits, and shall be thoroughly
familiar with requirements of the applicable CP. The compliance auditor must perform such compliance audits as a
primary responsibility. The applicable CPS shall identify the compliance auditor and justify the compliance auditor's
qualifications.
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 entities (CA or RA) 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 developing or maintaining the entity’s PKI Facility, associated
IT and network systems, or certificate practices statement. The APPA 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 APPA, 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 APPA may
decide to temporarily halt operation of the CA or RA, to revoke a certificate issued to the CA or RA, or take other
actions it deems appropriate. The APPA 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 - 62
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
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 APPA as set forth in Section 8.1. This package shall be prepared in accordance
with the APPA and must include an assertion from the Entity PKI Program Management Authority 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 - 63
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
2
9. Other Business and Legal Matters
Fees
3
Any fees must be approved by the APPA
4
9.1.1 Certificate Issuance or Renewal Fees
5
6
Section 2 of this policy requires that CA certificates be publicly available. CAs operating under this policy must not
charge additional fees for access to this information.
7
9.1.2 Certificate Access Fees
8
9
Section 2 of this policy requires that CA certificates be publicly available. CAs operating under this policy must not
charge additional fees for access to CRLs and OCSP status information.
10
9.1.3 Revocation or Statue Information Access Fees
11
CAs operating under this policy must not charge additional fees for access to CRLs and OCSP status information.
12
9.1.4 Fees for other Services
13
No stipulation.
14
9.1.5 Refund Policy
15
No stipulation.
16
Financial Responsibility
17
18
19
This CP contains no limits on the use of certificates issued by CAs under this policy. Rather, entities,
acting as relying parties, shall determine what financial limits, if any, they wish to impose for certificates
used to consummate a transaction.
20
9.2.1 Insurance Coverage
21
22
23
Root CA must obtain insurance coverage obtained from a reputable financially sound insurer with appropriate policy
limits that is equal to or exceeds industry norms. The WiMAX Forum and ICAO will be named as additional
insured. Insurance carrier and coverage must be acceptable to APPA.
24
9.2.2 Other Assets
25
No stipulation.
26
9.2.3 Insurance or Warranty Coverage for End-Entities
27
No stipulation.
28
29
30
31
32
Confidentiality of Business Information
CA information not requiring protection shall be made publicly available. Public access to organizational
information shall be determined by the respective organization. Written confidential information shall be
adequately marked in writing as confidential. Oral confidential information shall be identified as
confidential.
33
Page - 64
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
9.3.1 Scope of Confidential Information
2
3
4
Confidential Information means all information in written or oral form that the disclosing party identifies as
confidential, and any trade secret or other proprietary information that the recipient knows or reasonably ought to
know should be treated as confidential.
5
9.3.2 Information not within the Scope of Confidential Information
6
7
Information that is generally known to the public or properly known by the receiving party at the time of disclosure
and other typical exceptions.
8
9.3.3 Responsibility to Protect Confidential Information
9
No stipulation.
10
Privacy of Personal Information
11
12
13
14
15
It is the responsibility of all parties to ensure privacy of personal information under their control. No
personal information is registered or certified. Information about subordinate CA operators is retained by
the CA as part of certification request, which is subsequently logged and later archived. Manufacturer
point of contact information is also retained by the Root CAs. If a party collects, transmits or stores
personal information, its practices will comply with all applicable laws.
16
9.4.1 Privacy Plan
17
18
19
20
The APPA shall conduct a Privacy Impact Assessment. If deemed necessary, APPA shall have a Privacy Plan to
protect personally identifying information from unauthorized disclosure. For the Root CA, the APPA shall approve
the Privacy Plan. Privacy plans will be implemented in accordance with the requirements of the Privacy Act of
1974, as amended.
21
9.4.2 Information Treated as Private
22
23
24
25
Entities acquiring services under this policy shall protect all device sponsors personally identifying information from
unauthorized disclosure. Records of individual transactions may be released upon request of any device sponsors
involved in the transaction or their legally recognized agents. The contents of the archives maintained by CAs
operating under this policy shall not be released except as required by law.
26
9.4.3 Information not Deemed Private
27
Information included in certificates is not subject to protections outlined in section 9.4.2.
28
9.4.4 Responsibility to Protect Private Information
29
30
Sensitive information must be stored securely, and may be released only in accordance with other stipulations in
section 9.4.
31
9.4.5 Notice and Consent to Use Private Information
32
33
The APPA is not required to provide any notice or obtain the consent of the device sponsor in order to release
private information in accordance with other stipulations of section 9.4.
34
9.4.6 Disclosure Pursuant to Judicial or Administrative Process
35
36
The APPA shall not disclose private information to any third party unless authorized by this policy, required by law,
government rule or regulation, or order of a court of competent jurisdiction.
Page - 65
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
9.4.7 Other Information Disclosure Circumstances
2
3
4
Except as required for operation of the PKI system, as expressly permitted or required under the CP, or as required
by applicable law, no private information will be disclosed without the express written consent of the party to which
that private information pertains.
Intellectual Property Rights
5
6
The APPA will not knowingly violate intellectual property rights held by others.
7
The CP, CPS, each root certificate and all certificates issued under the root certificate are the property of the APPA.
8
9
No party will use any property of the APPA, including, without limitation, any trademark, copyright, trade secret or
other proprietary right of the APPA, unless the APPA has licensed that use.
10
11
No party will infringe the intellectual property rights of any third party or the APPA. Without limitation, except as
the APPA may expressly authorize in writing, it is prohibited to:
12
13
14

Reverse engineer, translate, disassemble, decompile the whole or any part of any software or system or any
part therefore or otherwise attempt to access any software source code embedded in or operating using any
1280 system;
15
16
17
18

Assign, transfer, sell, license, sub-license, lease, rent, charge or otherwise deal in or encumber, any
software or system or any part thereof or use same on behalf of or for the benefit of any third party, or
make available the same in any way whatsoever to any third party without the APPA’s prior written
consent;
19
20

Remove or alter any trademark or any copyright or other proprietary notice on any software, system or any
other materials;
21
22

Distribute, create derivative works of or modify the any materials, software or systems or any part thereof
in anyway, or use, copy, duplicate or display same on a commercial or development basis.
23
24

Provide any service using a certificate provided under this CP except as authorized and provided in this CP
and an approved CPS.
25
These restrictions shall not be construed in a manner that would violate any applicable law.
26
27
Representations and Warranties
28
The obligations described below pertain to the APPA.
29
The APPA shall—
30
31
32
33
34
35
36
37
38
39
40







Approve the CPS for each CA that issues certificates under this policy;
Review periodic compliance audits to ensure that CAs are operating in compliance with their approved
CPSs;
Review name space control procedures to ensure that distinguished names are uniquely assigned for all
certificates issued under this CP;
Revise this CP to maintain the level of assurance and operational practicality;
Publicly distribute this CP;
Coordinate modifications to this CP to ensure continued compliance by CAs operating under approved
CPSs; and
Review periodic compliance audits to ensure that RAs are operating in compliance with their approved
CPSs.
Page - 66
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
9.6.1 CA Representations and Warranties
2
3
4
CAs operating under this policy shall warrant that their procedures are implemented in accordance with this CP, and
that any certificates issued that assert the policy OIDs identified in this CP were issued in accordance with the
stipulations of this policy.
5
6
A CA that issues certificates that assert a policy defined in this document shall conform to the stipulations of this
document, including—
7
8
9
10
11
12
13
14
15
16






Providing to the APPA a CPS, as well as any subsequent changes, for conformance assessment.
Maintaining its operations in conformance to the stipulations of the approved CPS.
Ensuring that registration information is accepted only from approved RAs operating under an approved
CPS.
Including only valid and appropriate information in certificates, and maintaining evidence that due
diligence was exercised in validating the information contained in the certificates.
Revoking the certificates of devices whose device sponsor is found to have acted in a manner counter to
their obligations in accordance with section 9.6.3.
Operating or providing for the services of an on-line repository, and informing the repository service
provider of their obligations if applicable.
17
9.6.2 RA Representations and Warranties
18
19
20
21
An RA that performs registration functions as described in this policy shall comply with the stipulations of this
policy, and comply with a CPS approved by the APPA for use with this policy. An RA who is found to have acted
in a manner inconsistent with these obligations is subject to revocation of RA responsibilities. An RA supporting
this policy shall conform to the stipulations of this document, including—
22
23
24
25
26



Maintaining its operations in conformance to the stipulations of the approved CPS.
Including only valid and appropriate information in certificate requests, and maintaining evidence that due
diligence was exercised in validating the information contained in the certificate.
Ensuring that obligations are imposed on device sponsors in accordance with section 9.6.3, and that device
sponsors are informed of the consequences of not complying with those obligations.
27
9.6.3 Device Representations and Warranties
28
29
30
31
32
33
If the human sponsor for a device is not physically located near the sponsored device, and/or does not have
sufficient administrative privileges on the sponsored device to protect the device’s private key and ensure that the
device’s certificate is only used for authorized purposes, the device sponsor may delegate these responsibilities to an
authorized administrator for the device. The delegation shall be documented and signed by both the device sponsor
and the authorized administrator for the device. Delegation does not relieve the device sponsor of his or her
accountability for these responsibilities.
34
9.6.4 Relying Parties Representations and Warranties
35
36
37
38
This CP does not specify the steps a relying party should take to determine whether to rely upon a certificate. The
relying party decides, pursuant to its own policies, what steps to take. The CA merely provides the tools (i.e.,
certificates and CRLs) needed to perform the trust path creation, validation, and CP mappings that the relying party
may wish to employ in its determination.
39
9.6.5 Representations and Warranties of Other Participants
40
None
41
42
Disclaimers of Warranties
CAs operating under this policy may not disclaim any responsibilities described in this CP.
Page - 67
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
2
3
4
5
6
Limitations of Liability
ICAO and the WiMAX Forum shall not be liable to any party or as determined through a valid express written
contract between the ICAO, the WiMAX Forum and another party.
Indemnities
No stipulation.
Term and Termination
7
9.10.1 Term
8
This CP becomes effective when approved by the APPA. This CP has no specified term.
9
9.10.2 Termination
10
Termination of this CP is at the discretion of the APPA.
11
9.10.3 Effect of Termination and Survival
12
The requirements of this CP remain in effect through the end of the archive period for the last certificate issued.
13
Individual Notices and Communications with Participants
14
15
The APPA shall establish appropriate procedures for communications with CAs operating under this policy via
contracts or memoranda of agreement as applicable.
16
For all other communications, no stipulation.
17
Amendments
18
9.12.1 Procedure for Amendment
19
20
Changes to items within this CP shall be performed in accordance with the Change Request Procedure of the
Aviation Working Group.
21
22
23
24
The WiMAX Forum AWG shall review this CP at least once every year. Corrections, updates, or changes to this CP
shall be publicly available. Suggested changes to this CP shall be communicated to the contact in section 1.5.2; such
communication must include a description of the change, a change justification, and contact information for the
person requesting the change.
25
9.12.2 Notification and Mechanism and Period
26
Notification shall be performed in accordance with the Change Request procedure of the Aviation Working Group.
27
9.12.3 Circumstances under which OID must be Changed
28
29
Certificate Policy OIDs shall be changed if the CA determines that a change in the CP reduces the level of assurance
provided.
30
31
32
Dispute Resolution Provisions
The APPA shall facilitate the resolution between entities when conflicts arise as a result of the use of certificates
issued under this policy.
Page - 68
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
2
3
4
5
6
Governing Law
The construction, validity, performance and effect of certificates issued under this CP for all purposes shall be
governed by United States Federal law (statute, case law, or regulation).
Compliance with Applicable Law
All CAs operating under this policy are required to comply with applicable law.
Miscellaneous Provisions
7
9.16.1 Entire Agreement
8
No stipulation.
9
9.16.2 Assignment
10
No stipulation.
11
9.16.3 Severability
12
13
Should it be determined that one section of this CP is incorrect or invalid, the other sections of this CP shall remain
in effect until the CP is updated. The process for updating this CP is described in section 9.12.
14
9.16.4 Enforcement (Attorneys’ Fees and Waiver of Rights)
15
No stipulation.
16
9.16.5 Force Majeure
17
No stipulation.
18
19
Other Provisions
No stipulation.
20
Page - 69
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
10. References
NS4009
NSTISSI 4009, National Information Systems Security Glossary, January 1999.
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 - 70
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
11. Glossary
2
This specification uses the following terms:
Access
Ability to make use of any information system (IS) resource. [NS4009]
Access Control
Process of granting access to information system resources only to
authorized users, programs, processes, or other systems. [NS4009]
Activation Data
Private data, other than keys, that are required to access cryptographic
modules (i.e., unlock private keys for signing or decryption events).
Archive
Long-term, physically separate storage.
Audit Requirements Guide
A document that sets forth the security and audit requirements and
practices for AeroMACS CAs.
Authenticate
To confirm the identity of an entity when that identity is presented.
Authentication
Security measure designed to establish the validity of a transmission,
message, or originator, or a means of verifying an individual's
authorization to receive specific categories of information. [NS4009]
Certificate
A message that, at least, states a name or identifies the CA, identifies
the device, contains the device’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 device 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
Page - 71
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
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
(ECC)
A public-key cryptography system based on the algebraic structure of
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 Device Sponsor, 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 Device Sponsor, 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 Device
Sponsor requesting the device certificate.
Subscriber Agreement
An agreement used by a CA setting forth the terms and conditions
Page - 72
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
under which an individual or organization acts as a Device Sponsor.
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
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 - 73
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
1
12. Abbreviations and Acronyms
2
This specification uses the following abbreviations:
AIA
Authority Information Access
APPA
AeroMACS PKI Policy Authority
AWG
Aviation Working Group
CA
Certification Authority
CN
Common Name
CP
Certificate Policy
CPS
Certification Practice Statement
CRA
Certificate Requesting Account
CRL
Certificate Revocation List
CSR
Certificate Signing Request
CSA
Certificate Status Authority
CSS
Certificate Status Services
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
MAC
Media Access Control
MFG
Manufacturer
OCSP
Online Certificate Status Protocol
OID
Object Identifier
PA
Policy Authority
PKCS
Public-Key Cryptography Standard
PKI
Public Key Infrastructure
PKIX
Public Key Infrastructure X.509
RA
Registration Authority
RFC
Request for comment
RSA
Rivest, Shamir, Adelman
SAS
Statement on Auditing Standards (promulgated by the American Institute of Certified Public
Page - 74
WiMAX FORUM PROPRIETARY
WiMAX Forum® Network Architecture
DRAFT-T32-006-R010v01-H
AeroMACS PKI Certificate Policy
Accountants)
URI
Uniform Resource Identifier
1
Page - 75
WiMAX FORUM PROPRIETARY