aeromacs pki certificate policy - international civil … wg-s 9/wp05.1... · web viewprocessing...

WiMAX FORUM PROPRIETARY

WiMAX Forum® Network Architecture

AeroMACS PKI Certificate Policy

DRAFT-T32-006-R010v01-HDraft Specification

(2016-02-19)

WiMAX Forum ProprietaryCopyright © 2015 WiMAX Forum. All Rights Reserved.

1

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


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.

Page - i


1

2

1

23456789

10111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758

59



Document Status

WiMAX Forum Document ID: T32-006-R010-v01

Document Title: AeroMACS PKI Certificate Policy

Status: Work in Progress

Draft Issued Closed

Distribution Restrictions: Author Only AeroMACS/ Member

AeroMACS/ Member/Vendor

Public

Revision History

Revision Date Remarks

A 2015-10-13 Initial Draft to propose structure and outline certificate profiles in section 7

B 2015-10-14 Outline of all future sections added for context

C 2015-11-10 Section 6 added and Section 7 updated

D 2015-11-24 Section 5 and 8 added

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


1

2

1

2

3



Draft A document in specification format considered largely complete, but lacking review by Members. Drafts are susceptible to substantial change during the review process.

Issued A stable document, which has undergone rigorous review and is suitable for publication.

Closed A static document, reviewed, tested, validated, and closed to further documentation change requests.

Page - iii


1

2



TABLE OF CONTENTS

WIMAX FORUM® NETWORK ARCHITECTURE...............................................................................I

1. INTRODUCTION..........................................................................................................................11

1.1 Overview.......................................................................................................................................111.2 Identification.................................................................................................................................111.2.1 Certificate Policy Name................................................................................................................111.2.2 OID................................................................................................................................................111.3 PKI Participants.............................................................................................................................121.3.1 AeroMACS PKI Policy Authority................................................................................................121.3.2 Certification Authorities (CA)......................................................................................................121.3.3 Certificate Status Authority (CSA)...............................................................................................121.3.4 Registration Authorities (RA).......................................................................................................121.3.5 Device Sponsors............................................................................................................................131.3.6 Relying Parties..............................................................................................................................131.3.7 Other Participants..........................................................................................................................131.4 Certificate Usage...........................................................................................................................131.4.1 Appropriate Certificate Uses.........................................................................................................131.4.2 Prohibited Certificate Uses............................................................................................................131.5 Policy Administration...................................................................................................................131.5.1 Organization Administering the Document..................................................................................131.5.2 Contact Person...............................................................................................................................131.5.3 Person Determining CPS Suitability for the Policy......................................................................141.5.4 CPS Approval Procedures.............................................................................................................14

2. PUBLICATION AND REPOSITORY RESPONSIBILITIES..................................................15

2.1 Repositories...................................................................................................................................152.2 Publication of Certification Information.......................................................................................152.2.1 Publication of CA Information......................................................................................................152.2.2 Availability of Information...........................................................................................................152.3 Time or Frequency of Publication.................................................................................................152.4 Access Controls on Repositories...................................................................................................152.4.1 Certificate Policy...........................................................................................................................152.4.2 Certificates and CRLs...................................................................................................................15

3. IDENTIFICATION AND AUTHENTICATION........................................................................17

3.1 Naming..........................................................................................................................................173.1.1 Types of Names.............................................................................................................................173.1.2 Need for Names to be Meaningful................................................................................................173.1.3 Anonymity or Pseudonymity of Devices......................................................................................173.1.4 Rules for Interpreting Various Name Forms.................................................................................173.1.5 Uniqueness of Names....................................................................................................................173.1.6 Recognition, Authentication, and Role of Trademarks.................................................................173.2 Initial Identity Validation..............................................................................................................183.2.1 Method to Prove Possession of Private Key.................................................................................183.2.2 Authentication of Individual Identity............................................................................................183.2.3 Non-verified Device Information..................................................................................................19

Page - iv


1

2

1

2

3

456789

1011121314151617181920212223

24

2526272829303132

33

3435363738394041424344



3.2.4 Validation of Authority.................................................................................................................193.2.5 Criteria for Interoperation.............................................................................................................193.3 Re-key Requests............................................................................................................................203.3.1 Identification and Authentication for Routine Re-key..................................................................203.3.2 Identification and Authentication for Re-key after Revocation....................................................203.4 Identification and Authentication for Revocation Request...........................................................20

4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS....................................21

4.1 Certificate Application..................................................................................................................214.1.1 Who Can Submit a Certificate Application...................................................................................214.1.2 Enrollment Process and Responsibilities......................................................................................214.2 Certificate Application Processing................................................................................................214.2.1 Performing Identification and Authentication Functions..............................................................214.2.2 Approval or Rejection of Certificate Applications.......................................................................224.2.3 Time to Process Certificate Applications......................................................................................224.3 Certificate Issuance.......................................................................................................................224.3.1 CA Actions During Certificate Issuance.......................................................................................224.3.2 Notification to Device Sponsor by the CA of Issuance of Certificate..........................................234.4 Certificate Acceptance..................................................................................................................234.4.1 Conduct Constituting Certificate Acceptance...............................................................................234.4.2 Publication of the Certificate by the CA.......................................................................................234.4.3 Notification of Certificate Issuance by the CA to Other Entities..................................................234.5 Key Pair and Certificate Usage.....................................................................................................234.5.1 Device Private Key and Certificate Usage....................................................................................234.5.2 Relying Party Public Key and Certificate Usage..........................................................................234.6 Certificate Renewal.......................................................................................................................244.6.1 Circumstance for Certificate Renewal..........................................................................................244.6.2 Who May Request Renewal..........................................................................................................244.6.3 Processing Certificate Renewal Requests.....................................................................................244.6.4 Notification of new Certificate Issuance to Device......................................................................244.6.5 Conduct Constituting Acceptance of a Renewal Certificate.........................................................244.6.6 Publication of the Renewal Certificate by the CA........................................................................244.6.7 Notification of Certificate Issuance by the CA to Other Entities..................................................244.7 Certificate Re-key.........................................................................................................................244.7.1 Circumstance for Certificate Re-key.............................................................................................244.7.2 Who May Request Certification of a New Public Key.................................................................254.7.3 Processing Certificate Re-keying Requests...................................................................................254.7.4 Notification of New Certificate Issuance to Device Sponsors......................................................254.7.5 Conduct Constituting Acceptance of a Re-keyed Certificate........................................................254.7.6 Publication of the Re-keyed Certificate by the CA.......................................................................254.7.7 Notification of Certificate Issuance by the CA to Other Entities..................................................254.8 Certificate Modification................................................................................................................254.8.1 Circumstance for Certificate Modification...................................................................................254.8.2 Who May Request Certificate Modification.................................................................................254.8.3 Processing Certificate Modification Requests..............................................................................254.8.4 Notification of New Certificate Issuance to Device......................................................................254.8.5 Conduct Constituting Acceptance of Modified Certificate...........................................................254.8.6 Publication of the Modified Certificate by the CA.......................................................................254.8.7 Notification of Certificate Issuance by the CA to Other Entities..................................................254.9 Certificate Revocation and Suspension.........................................................................................26

Page - v


1

2

123456

7

89

10111213141516171819202122232425262728293031323334353637383940414243444546474849



4.9.1 Circumstances for Revocation......................................................................................................264.9.2 Who can Request Revocation.......................................................................................................264.9.3 Procedure for Revocation Request................................................................................................264.9.4 Revocation Request Grace Period.................................................................................................274.9.5 Time within which CA Must Process the Revocation Request....................................................274.9.6 Revocation Checking Requirement for Relying Parties...............................................................274.9.7 CRL Issuance Frequency..............................................................................................................274.9.8 Maximum Latency for CRLs........................................................................................................284.9.9 On-line Revocation/Status Checking Availability........................................................................284.9.10 On-line Revocation Checking Requirements................................................................................284.9.11 Other Forms of Revocation Advertisements Available................................................................284.9.12 Special Requirements Regarding Key Compromise.....................................................................284.9.13 Circumstances for Suspension......................................................................................................284.9.14 Who can Request Suspension.......................................................................................................284.9.15 Procedure for Suspension Request................................................................................................284.9.16 Limits on Suspension Period.........................................................................................................284.10 Certificate Status Services.............................................................................................................284.10.1 Operational Characteristics...........................................................................................................284.10.2 Service Availability.......................................................................................................................294.10.3 Optional Features..........................................................................................................................294.11 End of Subscription.......................................................................................................................294.12 Key Escrow and Recovery............................................................................................................294.12.1 Key Escrow and Recovery Policy and Practices...........................................................................294.12.2 Session Key Encapsulation and Recovery Policy and Practices...................................................29

5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS......................................30

5.1 Physical Controls...........................................................................................................................305.1.1 Site Location and Construction.....................................................................................................305.1.2 Physical Access.............................................................................................................................305.1.3 Power and Air Conditioning.........................................................................................................315.1.4 Water Exposures...........................................................................................................................315.1.5 Fire Prevention and Protection......................................................................................................315.1.6 Media Storage...............................................................................................................................315.1.7 Waste Disposal..............................................................................................................................315.1.8 Off-Site Backup.............................................................................................................................315.2 Procedural Controls.......................................................................................................................325.2.1 Corporate Controls........................................................................................................................325.2.2 Trusted Roles.................................................................................................................................325.2.3 Number of Persons Required per Task.........................................................................................335.2.4 Identification and Authentication for Each Role...........................................................................335.2.5 Roles Requiring Separation of Duties...........................................................................................335.3 Personnel Controls........................................................................................................................345.3.1 Qualifications, Experience, and Clearance Requirements............................................................345.3.2 Background Check Procedures.....................................................................................................345.3.3 Training Requirements..................................................................................................................355.3.4 Retraining Frequency and Requirements......................................................................................355.3.5 Job Rotation Frequency and Sequence..........................................................................................355.3.6 Sanctions for Unauthorized Actions.............................................................................................355.3.7 Independent Contractor Requirements..........................................................................................355.3.8 Documentation Supplied to Personnel..........................................................................................35

Page - vi


1

2

123456789

101112131415161718192021222324

25

262728293031323334353637383940414243444546474849



5.4 Audit Logging Procedures............................................................................................................355.4.1 Types of Events Recorded.............................................................................................................365.4.2 Frequency of Processing Log........................................................................................................395.4.3 Retention Period for Audit Log.....................................................................................................405.4.4 Protection of Audit Logs...............................................................................................................405.4.5 Audit Log Backup Procedures......................................................................................................405.4.6 Audit Collection System (Internal vs. External)...........................................................................405.4.7 Notification to Event-Causing Subject..........................................................................................405.4.8 Vulnerability Assessments............................................................................................................405.5 Records Archival...........................................................................................................................405.5.1 Types of Events Archived.............................................................................................................405.5.2 Retention Period for Archive........................................................................................................415.5.3 Protection of Archive....................................................................................................................415.5.4 Archive Backup Procedures..........................................................................................................425.5.5 Requirements for Time-Stamping of Records..............................................................................425.5.6 Procedures to Obtain and Verify Archive Information.................................................................425.6 Key Changeover............................................................................................................................425.7 Compromise and disaster recovery...............................................................................................425.7.1 Incident and Compromise Handling Procedures...........................................................................425.7.2 Computing Resources, Software, and/or Data Are Corrupted......................................................425.7.3 Private Key Compromise Procedures...........................................................................................435.7.4 Business Continuity Capabilities after a Disaster.........................................................................435.8 CA, CSA, or RA Termination.......................................................................................................43

6. TECHNICAL SECURITY CONTROLS.....................................................................................44

6.1 Key Pair Generation and Installation............................................................................................446.1.1 Key Pair Generation......................................................................................................................446.1.2 Private Key Delivery to Devices...................................................................................................446.1.3 Public Key Delivery to Certificate Issuer.....................................................................................456.1.4 CA Public Key Delivery to Relying Parties..................................................................................456.1.5 Key Sizes.......................................................................................................................................456.1.6 Public Key Parameters Generation and Quality Checking...........................................................466.1.7 Key Usage Purposes (as per X.509 v3 Key Usage Field).............................................................466.2 Private Key Protection and Cryptographic Module Engineering Controls..................................476.2.1 Cryptographic Module Standards and Controls............................................................................476.2.2 Private Key (n out of m) Multi-Person Control............................................................................476.2.3 Private Key Escrow.......................................................................................................................476.2.4 Private Key Backup.......................................................................................................................476.2.5 Private Key Archival.....................................................................................................................486.2.6 Private Key Transfer into or from a Cryptographic Module.........................................................486.2.7 Private Key Storage on Cryptographic Module............................................................................486.2.8 Method of Activating Private Key................................................................................................486.2.9 Method of Deactivating Private Key.............................................................................................496.2.10 Method of Destroying Private Key...............................................................................................496.2.11 Cryptographic Module Rating.......................................................................................................496.3 Other Aspects of Key Pair Management.......................................................................................496.3.1 Public Key Archival......................................................................................................................496.3.2 Certificate Operational Periods and Key Pair Usage Periods.......................................................496.4 Activation data..............................................................................................................................506.4.1 Activation Data Generation and Installation.................................................................................50

Page - vii


1

2

123456789

1011121314151617181920212223

24

25262728293031323334353637383940414243444546474849



6.4.2 Activation Data Protection............................................................................................................506.4.3 Other Aspects of Activation Data.................................................................................................506.5 Computer security controls...........................................................................................................506.5.1 Specific Computer Security Technical Requirements..................................................................506.5.2 Computer Security Rating.............................................................................................................516.6 Life Cycle Technical Controls......................................................................................................516.6.1 System Development Controls......................................................................................................516.6.2 Security Management Controls.....................................................................................................516.6.3 Life Cycle Security Controls.........................................................................................................516.7 Network Security Controls............................................................................................................516.8 Time-Stamping..............................................................................................................................52

7. CERTIFICATE, CRL, AND OCSP PROFILES.........................................................................53

7.1 Certificate Profile..........................................................................................................................537.1.1 Version Number(s)........................................................................................................................537.1.2 Certificate Extensions...................................................................................................................547.1.3 Algorithm Object Identifiers (OIDs).............................................................................................577.1.4 Name Forms..................................................................................................................................587.1.5 Name Constraints..........................................................................................................................597.1.6 Certificate Policy Object Identifier...............................................................................................597.1.7 Usage of Policy Constraints Extension.........................................................................................607.1.8 Policy Qualifiers Syntax and Semantics.......................................................................................607.1.9 Processing Semantics for the Critical Certificate Policies Extension...........................................607.2 CRL Profile...................................................................................................................................607.2.1 Version Number(s)........................................................................................................................617.2.2 CRL and CRL entry extensions....................................................................................................617.3 OCSP Profile.................................................................................................................................617.3.1 Version Number(s)........................................................................................................................617.3.2 OCSP Extensions..........................................................................................................................61

8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS..........................................................62

8.1 Frequency or Circumstances of Assessment.................................................................................628.2 Identity and Qualifications of Assessor........................................................................................628.3 Assessor's Relationship to Assessed Entity...................................................................................628.4 Topics Covered by Assessment.....................................................................................................628.5 Actions Taken as a Result of Deficiency......................................................................................628.6 Communication of Results............................................................................................................63

9. OTHER BUSINESS AND LEGAL MATTERS..........................................................................64

9.1 Fees................................................................................................................................................649.1.1 Certificate Issuance or Renewal Fees............................................................................................649.1.2 Certificate Access Fees.................................................................................................................649.1.3 Revocation or Statue Information Access Fees.............................................................................649.1.4 Fees for other Services..................................................................................................................649.1.5 Refund Policy................................................................................................................................649.2 Financial Responsibility................................................................................................................649.2.1 Insurance Coverage.......................................................................................................................649.2.2 Other Assets..................................................................................................................................649.2.3 Insurance or Warranty Coverage for End-Entities........................................................................64

Page - viii


1

2

123456789

1011

12

13141516171819202122232425262728

29

303132333435

36

37383940414243444546



9.3 Confidentiality of Business Information.......................................................................................649.3.1 Scope of Confidential Information................................................................................................649.3.2 Information not within the Scope of Confidential Information....................................................659.3.3 Responsibility to Protect Confidential Information......................................................................659.4 Privacy of Personal Information...................................................................................................659.4.1 Privacy Plan...................................................................................................................................659.4.2 Information Treated as Private......................................................................................................659.4.3 Information not Deemed Private...................................................................................................659.4.4 Responsibility to Protect Private Information...............................................................................659.4.5 Notice and Consent to Use Private Information............................................................................659.4.6 Disclosure Pursuant to Judicial or Administrative Process...........................................................659.4.7 Other Information Disclosure Circumstances...............................................................................659.5 Intellectual Property Rights...........................................................................................................659.6 Representations and Warranties....................................................................................................659.6.1 CA Representations and Warranties.............................................................................................669.6.2 RA Representations and Warranties.............................................................................................669.6.3 Device Representations and Warranties........................................................................................669.6.4 Relying Parties Representations and Warranties..........................................................................669.6.5 Representations and Warranties of Other Participants..................................................................679.7 Disclaimers of Warranties.............................................................................................................679.8 Limitations of Liability.................................................................................................................679.9 Indemnities....................................................................................................................................679.10 Term and Termination...................................................................................................................679.10.1 Term..............................................................................................................................................679.10.2 Termination...................................................................................................................................679.10.3 Effect of Termination and Survival...............................................................................................679.11 Individual Notices and Communications with Participants..........................................................679.12 Amendments..................................................................................................................................679.12.1 Procedure for Amendment............................................................................................................679.12.2 Notification and Mechanism and Period.......................................................................................679.12.3 Circumstances under which OID must be Changed......................................................................679.13 Dispute Resolution Provisions......................................................................................................689.14 Governing Law..............................................................................................................................689.15 Compliance with Applicable Law.................................................................................................689.16 Miscellaneous Provisions..............................................................................................................689.16.1 Entire Agreement..........................................................................................................................689.16.2 Assignment....................................................................................................................................689.16.3 Severability....................................................................................................................................689.16.4 Enforcement (Attorneys’ Fees and Waiver of Rights)..................................................................689.16.5 Force Majeure...............................................................................................................................689.17 Other Provisions............................................................................................................................68

10. REFERENCES...............................................................................................................................69

11. GLOSSARY....................................................................................................................................70

12. ABBREVIATIONS AND ACRONYMS......................................................................................73

Page - ix


1

2

123456789

1011121314151617181920212223242526272829303132333435363738394041

42

43

44

45

46



TABLE OF TABLES TABLE 1: ALGORITHM TYPE AND KEY SIZE....................................................................................45TABLE 2: KEYUSAGE EXTENSION FOR ALL CA CERTIFICATES..................................................46TABLE 3: KEYUSAGE EXTENSION FOR ALL DEVICE CERTIFICATES........................................46TABLE 4: CERTIFICATE PROFILE BASIC FIELDS.............................................................................53TABLE 5: ROOT CA CERTIFICATE STANDARD EXTENSIONS.......................................................54TABLE 6: CA CERTIFICATE STANDARD EXTENSIONS...................................................................54TABLE 7: DEVICE CERTIFICATE STANDARD EXTENSIONS..........................................................55TABLE 8: OCSP CERTIFICATE STANDARD EXTENSIONS...............................................................55TABLE 9: SUBJECTKEYIDENTIFIER EXTENSION FOR AEROMACS CA CERTIFICATES..........55TABLE 10: BASICCONSTRAINTS EXTENSION FOR AEROMACS ROOT CA CERTIFICATES....56TABLE 11: BASICCONSTRAINTS EXTENSION FOR AEROMACS CA CERTIFICATES...............56TABLE 12: EXTKEYUSAGE EXTENSION FOR AEROMACS SERVER CERTIFICATES..................57TABLE 13: SIGNATURE OIDS FOR CERTIFICATES...........................................................................57TABLE 14: SUBJECTPUBLICKEYINFO FOR CERTIFICATES...........................................................57TABLE 15: ROOT CA CERTIFICATE ISSUER AND SUBJECT FIELDS.............................................58TABLE 16: CA CERTIFICATE SUBJECT FIELDS.................................................................................58TABLE 17: DEVICE CERTIFICATE SUBJECT FIELDS........................................................................59TABLE 18: CERTIFICATEPOLICIES EXTENSION FOR AEROMACS CERTIFICATES..................59TABLE 19: CRL PROFILE BASIC FIELDS.............................................................................................60

Page - x


1

2

1

23456789

101112131415161718192021



1. Introduction1.1 OverviewAeroMACS (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.

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.

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 medium-assurance 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.

A PKI that uses this CP will provide the following security management services:

Key generation and storage

Certificate generation, modification, re-key, and distribution

Certificate Revocation List (CRL) generation and distribution

Directory management of certificate related items

Certificate token initialization, programming, and management

System management functions to include security audit, configuration management, and archive

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.

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.

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).

1.2 Identification

1.2.1 Certificate Policy NameThis document shall be named the AeroMACS PKI Certificate Policy (CP). It shall furthermore have an assurance-level 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.

1.2.2 OIDCertificates issued in accordance with this Certificate Policy shall be known by the following OIDs, depending on the level of assurance to be conveyed:

Medium-Assurance (Software):

Page - 11


1

2

1

2

3456

789

1011

12131415

16

17

18

19

20

21

22

232425

262728

293031

32

33

343536

37

3839

40



{iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) AeroMACS (?????) Medium(3) Software(1)}

1.3 PKI Participants

1.3.1 AeroMACS PKI Policy AuthorityICAO is the AeroMACS PKI Policy Authority (APPA). The APPA is responsible for:

Approving and Maintaining this CP,

Approving the CPS for each CA that issues certificates under this policy,

Approving the compliance audit report for each CA issuing certificates under this policy, and

Ensuring continued conformance of each CA that issues certificates under this policy with applicable requirements as a condition for allowing continued participation.

1.3.2 Certification Authorities (CA)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.

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:

The certificate manufacturing process

Publication of certificates

Revocation of certificates

Generation and destruction of CA signing keys

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.

1.3.3 Certificate Status Authority (CSA)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.

1.3.4 Registration Authorities (RA)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:

Control over the registration process

The identification and authentication process

Page - 12


1

2

12

3

4

5

6

7

8

910

11

121314

1516

17

18

19

20

212223

24

25262728293031

32

333435

36

37

Susan Joseph, 02/10/16,

We will need to apply for an OID for this CP.



1.3.5 Device SponsorsA 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.

1.3.6 Relying PartiesA 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.

1.3.7 Other Participants 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.

1.4 Certificate Usage

1.4.1 Appropriate Certificate UsesMedium- 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.

1.4.2 Prohibited Certificate UsesProhibited applications include the following:

Any export, import, use or activity that contravenes any local or international laws or regulations

Any usage of Certificates in conjunction with illegal activities

Any usage of Certificates for personal use or purposes not related to the Community’s business

Any use of a Certificate after it has been revoked

Any use not expressly permitted in Section 1.4.1.

1.5 Policy Administration

1.5.1 Organization Administering the DocumentThis CP is administered by the WiMAX Forum Aviation Working Group (AWG).

1.5.2 Contact PersonThe following individual is responsible for accepting comments on this CP on behalf of the group mentioned above:

WiMAX Forum Aviation Working Group

Richard HawkinsChief Operating Officer and Chairman, Technical Steering [email protected]

Page - 13


1

2

1

234

5

6789

1011

12

131415

16

17

1819

20

21

22

23

24

25

26

27

28

29

30

31

32

333435

36

mailto:[email protected]



1.5.3 Person Determining CPS Suitability for the PolicyA 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.

1.5.4 CPS Approval ProceduresThe 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


1

2

1

2345

6

789

1011



2. Publication and Repository Responsibilities2.1 RepositoriesAll 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.

2.2 Publication of Certification Information

2.2.1 Publication of CA InformationCAs issuing a Certificate in accordance with this CP shall make the following items publicly available in their repositories:

This CP;

The CRL; and

All CA Certificates issued by the CA (including self-signed CA-Certificate and Cross-Certificates for Cross-Certified CAs).

Signature and Identity Certificates need not be published in the PKI repository.

The CA shall notify device sponsors and Relying Parties of Certificate issuance by providing access to Certificates and CRLs in a Certificate Repository.

When using LDAP as the repository access mechanism, the following object classes and attributes shall be populated:

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.

2.2.2 Availability of InformationAll 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.

2.3 Time or Frequency of PublicationThe 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.

2.4 Access Controls on Repositories

2.4.1 Certificate PolicyThere shall be no access controls to prevent the reading of this CP.

2.4.2 Certificates and CRLsOnly 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


1

2

1

2

34567

8

9

1011

12

13

1415

16

1718

1920

212223

24

252627

28

293031

32

33

34

35

3637



the Certificate Repository shall be granted to anonymous users (i.e.: authentication type “none”) of the Certificate Repository.

Page - 16


1

2

12



3. Identification and Authentication3.1 Naming

3.1.1 Types of NamesEach 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.

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.

3.1.2 Need for Names to be MeaningfulThe 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.

When DNs are used, it is preferable that the common name represents the device in a way that is easily understandable for humans.

For Individuals, this will typically be a legal name.

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)

3.1.3 Anonymity or Pseudonymity of DevicesCA certificates shall not contain anonymous or pseudonymous identities.

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.

3.1.4 Rules for Interpreting Various Name FormsRules for interpreting distinguished name forms are specified in X.501. Rules for interpreting e-mail addresses are specified in [RFC 2822].

3.1.5 Uniqueness of NamesName 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.

The APPA shall be responsible for ensuring name uniqueness in certificates issued by the AeroMACS CAs.

3.1.6 Recognition, Authentication, and Role of TrademarksThe 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


1

2

1

2

3

456

789

10

11

121314

1516

17

1819202122

23

24

2526

27

2829

30

3132

33

34

3536373839



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.

3.2 Initial Identity Validation

3.2.1 Method to Prove Possession of Private KeyIn 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.

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.

3.2.2 Authentication of Individual Identity

3.2.2.1 Device SubjectsFor 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:

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;

Equipment authorizations and attributes (if any are to be included in the Certificate); and

Contact information to enable the CA or RA to communicate with the Applicant when required.

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:

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

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.

3.2.2.2 Individual SubjectsA 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.

The identity of the person performing the identity verification;

Page - 18


1

2

1234

5

6

789

10

11121314

15

16

17181920

212223

24

25

262728

2930

3132

33

34353637

38



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;

The date and time of the verification;

For all assurance levels, the following information shall be recorded:

o the full name, including surname and given name(s) of the Applicant;

o the date and place of birth or other attribute(s) which may be used to uniquely identify the Applicant;

o the full name and legal status of the Device Sponsor's Employer;

o a physical address or other suitable method of contact; and

o a declaration signed by the Applicant indicating his acceptance of the privacy policy outlined in Section 9.4.

For medium-assurance Certificates, the Applicant shall:

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);

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

o sign a declaration of identity using a handwritten signature. This shall be performed in the presence of the person performing the identity authentication.

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.

3.2.3 Non-verified Device InformationInformation that is not verified shall not be included in Certificates.

3.2.4 Validation of AuthorityTo 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.

NOTE: Various special purpose Certificates are subject to extra requirements concerning validation of authority, as follows:

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.

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.

3.2.5 Criteria for InteroperationInteroperating CAs shall adhere to the following requirements:

Complete a policy mapping with the Subject CA's CP with results satisfactory to both parties;

Page - 19


1

2

123

4

5

6

78

9

10

1112

13

1415

1617

1819

2021222324

25

26

27

282930

3132

333435

363738

39

40

41



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;

Issue Certificates compliant with the profiles described in this CP, and make Certificate status information available in compliance with this CP; and

Provide CA Certificate and Certificate status information to the Relying Parties.

3.3 Re-key Requests

3.3.1 Identification and Authentication for Routine Re-keyA 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.

Identity shall be verified at least once every nine years.

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.

3.3.2 Identification and Authentication for Re-key after RevocationAfter 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.

3.4 Identification and Authentication for Revocation RequestRevocation 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.

Page - 20


1

2

12

34

5

6

7

89

101112

13

1415

16

17181920

21

2223

24



4. Certificate Life-cycle Operational Requirements4.1 Certificate ApplicationThe Certificate application process must provide sufficient information to:

Establish the applicant’s authorization (by the employing or sponsoring agency) to obtain a certificate. (per section 3.2.2)

Establish and record identity of the applicant. (per section 3.2.2)

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)

Verify authorization information requested for inclusion in the certificate.

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.

4.1.1 Who Can Submit a Certificate ApplicationA Certificate Application may be submitted by any of the following:

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;

any authorized representative of an organization or Entity; and

any authorized representative of a CA; or any authorized representative of an RA.

4.1.2 Enrollment Process and ResponsibilitiesAll 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:

completing a Certificate Application and providing true and correct information;

generating, or arranging to have generated, a key pair, in accordance with Section 6.1.1 of the present document;

delivering his, her, or its public key, directly or through an RA, to the CA's facility; and

demonstrating possession of the private key corresponding to the public key as described in Section 3.2.1.

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.

4.2 Certificate Application ProcessingInformation in certificate applications must be verified as accurate before certificates are issued. PKI authorities shall specify procedures to verify information in certificate applications.

4.2.1 Performing Identification and Authentication FunctionsThe 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


1

2

1

2

3

45

6

78

9

1011

12

13

1415

16

17

18

1920

21

2223

24

25

2627282930

31

3233

34

353637



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.

4.2.2 Approval or Rejection of Certificate ApplicationsA Certificate application will be approved by the CA or RA if all of the following conditions are met:

successful identification and authentication of all required device information as described in Section 3.2; and

payment (if applicable) has been received.

A Certificate application will be rejected by the CA or RA if any one or more of the following conditions arises:

identification and authentication of all required Device information as described in Section 3.2 cannot be completed;

the Device Sponsor fails to furnish supporting documentation upon request;

the Device Sponsor fails to respond to notices within a specified time;

payment (if applicable) has not been received; or

the RA or CA believe that issuing a certificate to the Device may bring the CA into disrepute.

4.2.3 Time to Process Certificate Applications The entire registration process (i.e.: from initial application to identity proofing to Certificate issuance) shall take no more than 30 days.

4.3 Certificate Issuance 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.

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.

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.

4.3.1 CA Actions During Certificate Issuance 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

Verify the identity and authority of the requester;

Check to ensure that all fields and extensions are properly populated;

Build and sign a certificate if all certificate requirements have been met (in the case of an RA, have the CA sign the certificate).

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.

4.3.2 Notification to Device Sponsor by the CA of Issuance of Certificate 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.

Page - 22


1

2

12

3

4

56

7

8

910

11

12

13

14

15

1617

18

1920

2122

232425262728

29

3031

32

33

3435

3637

38

3940



4.4 Certificate AcceptanceBefore 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.

4.4.1 Conduct Constituting Certificate Acceptance 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.

4.4.2 Publication of the Certificate by the CA As specified in 2.1, all CA certificates shall be published in repositories.

This policy makes no stipulation regarding publication of device certificates, except as noted in Section 9.4.3.

4.4.3 Notification of Certificate Issuance by the CA to Other Entities The APPA must be notified whenever a CA operating under this policy issues a CA certificate.

4.5 Key Pair and Certificate Usage

4.5.1 Device Private Key and Certificate Usage 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.

Devices shall protect their Private Keys from unauthorized use and shall discontinue use of the Private Key following expiration or revocation of the Certificate.

4.5.2 Relying Party Public Key and Certificate Usage 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.

Before any act of reliance, Relying Parties shall independently assess the following:

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;

that the Certificate is being used in accordance with the keyUsage and extendedKeyUsage extensions included in the Certificate; and

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.

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.

4.6 Certificate RenewalRenewing 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.

Page - 23


1

2

1

23

4

56

7

8

9

10

11

12

13

14151617

1819

20

2122

23

242526

2728

293031

323334

35

363738



4.6.1 Circumstance for Certificate Renewal 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.

The CA may automatically renew certificates during recovery from a key compromise.

4.6.2 Who May Request Renewal 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.

4.6.3 Processing Certificate Renewal Requests 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.

4.6.4 Notification of new Certificate Issuance to Device Notification shall be given to the Device Sponsor in accordance with Section 4.3.2.

4.6.5 Conduct Constituting Acceptance of a Renewal Certificate See Section 4.4.1.

4.6.6 Publication of the Renewal Certificate by the CA Renewed certificates are published as in Section 4.4.2.

4.6.7 Notification of Certificate Issuance by the CA to Other Entities See Section 4.4.3.

4.7 Certificate Re-keyThe 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 re-keyed, renewed, or modified.

Device Sponsors shall identify themselves for the purpose of re-keying as required in Section 3.3.

4.7.1 Circumstance for Certificate Re-key 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.

4.7.2 Who May Request Certification of a New Public Key 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.

Page - 24


1

2

1

2345

6

7

89

10

1112

13

14

15

16

17

18

19

20

21

222324252627

28

29

303132

33

3435



4.7.3 Processing Certificate Re-keying Requests 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.

4.7.4 Notification of New Certificate Issuance to Device Sponsors Notification shall be given to the Device Sponsors in accordance with Section 4.3.2.

4.7.5 Conduct Constituting Acceptance of a Re-keyed Certificate See Section 4.4.1.

4.7.6 Publication of the Re-keyed Certificate by the CA Re-keyed certificates are published as in Section 4.4.2.

4.7.7 Notification of Certificate Issuance by the CA to Other Entities No specific requirement.

4.8 Certificate ModificationAll requests for Certificate modification shall be treated as new Certificate applications.

4.8.1 Circumstance for Certificate ModificationNot supported.

4.8.2 Who May Request Certificate Modification Not supported.

4.8.3 Processing Certificate Modification Requests Not supported.

4.8.4 Notification of New Certificate Issuance to Device Not supported.

4.8.5 Conduct Constituting Acceptance of Modified Certificate Not supported.

4.8.6 Publication of the Modified Certificate by the CA Not supported.

4.8.7 Notification of Certificate Issuance by the CA to Other Entities Not supported.

4.9 Certificate Revocation and SuspensionCAs 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.

Page - 25


1

2

1

234

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

3031



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.

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.

4.9.1 Circumstances for Revocation Revocation shall occur on decision of the CA when reasonable and credible evidence exists to establish at least one of the following:

the Certificate has been delivered based upon wrong or falsified information;

the identifying information or affiliation components of any names in the Certificate become invalid;

the confidentiality of a Private Key is no longer ensured or has been compromised;

the media holding the Private Key is suspected or known to have been compromised;

the Certificate fees have not been paid according to the payment terms as indicated in the relevant agreement;

the Device Sponsor can be shown to have violated one or more sections of this CP; or

the Device Sponsor or the Device Sponsor's Employer wishes to terminate their Subscription to the CA

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.

4.9.2 Who can Request Revocation The revocation of an individual or End-Entity Certificate may only be requested by one of the following:

the Device Sponsor responsible for the server, device, or application;

the Device Sponsor's Employer organization;

the personnel of the Issuing CA; or

the personnel of any RA associated with the issuing CA.

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.

4.9.3 Procedure for Revocation Request 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).

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.

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 Section 6.2.10 promptly upon surrender and shall be protected from malicious use between surrender and such destruction of the key.

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.

Page - 26


1

2

1234

56

7

89

10

11

12

13

1415

16

17

181920

21

22

23

24

25

26

2728

29

3031

3233

343536373839

404142



4.9.4 Revocation Request Grace Period There is no revocation grace period. Responsible parties must request revocation as soon as they identify the need for revocation.

4.9.5 Time within which CA Must Process the Revocation Request Revocation request shall be processed within 18 hours of receipt of request.

4.9.6 Revocation Checking Requirement for Relying Parties 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.

4.9.7 CRL Issuance Frequency 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.

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.

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

CRL issuance frequency requirements may be further constrained by applicable jurisdictional regulatory law.

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.

4.9.8 Maximum Latency for CRLs 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.9.9 On-line Revocation/Status Checking Availability 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.

Page - 27


1

2

1

23

4

5

6

789

101112

13

14151617

18192021

22

23

24

252627

28

2930

31

3233



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.

Since some relying parties may not be able to accommodate on-line communications, all CAs will be required to support CRLs.

4.9.10 On-line Revocation Checking Requirements Relying parties client software may optionally support on-line status checking. Client software using on-line status checking need not obtain or process CRLs.

4.9.11 Other Forms of Revocation Advertisements Available 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.

4.9.12 Special Requirements Regarding Key Compromise 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.

4.9.13 Circumstances for Suspension Certificate suspension is not supported by this CP.

4.9.14 Who can Request Suspension Certificate suspension is not supported by this CP.

4.9.15 Procedure for Suspension Request Certificate suspension is not supported by this CP.

4.9.16 Limits on Suspension Period Certificate suspension is not supported by this CP.

4.10 Certificate Status Services

4.10.1 Operational Characteristics 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.

4.10.2 Service Availability Relying Parties are bound to their obligations and the stipulations of this CP irrespective of the availability of the Certificate status service.

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.

4.10.3 Optional Features No specific requirement.

Page - 28


1

2

123

45

6

78

9

1011

12

131415

16

17

18

19

20

21

22

23

24

25

2627

28

2930

3132

33

34



4.11 End of SubscriptionA 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.

4.12 Key Escrow and Recovery

4.12.1 Key Escrow and Recovery Policy and Practices Under no circumstances shall any CA, end-entity, individual, role, or organizational signature key be escrowed by a third party.

4.12.2 Session Key Encapsulation and Recovery Policy and Practices 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


1

2

1

23

4

5

67

8

910



5. Facility, Management, and Operational ControlsAll entities performing CA functions shall implement and enforce the following physical, procedural, logical, and personnel security controls for a CA.

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

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

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

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

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.

5.1.2 Physical Access

5.1.2.1 Physical Access for CA EquipmentCA 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:

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


1

2

1

23

4

5678

910

11

121314151617181920

2122232425

262728

29

30

3132

33343536373839

4041424344



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

The equipment is in a state appropriate to the current mode of operation (e.g., that cryptographic modules are in place when “open,” and secured when “closed,” and for the CA, that all equipment other than the repository is shut down).

Any security containers are properly secured. Physical security systems (e.g., door locks, vent covers) are functioning properly. The area is secured against unauthorized access.

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

5.1.2.2 Physical Access for RA EquipmentRA 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.

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

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

5.1.4 Water ExposuresCA equipment shall be installed such that it prevents damage from exposure to water.

Potential water damage from fire prevention and protection measures (e.g., sprinkler systems) are excluded from this requirement.

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

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

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

5.1.8 Off-Site BackupFull 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


1

2

12

345678

9101112

13

14151617

18

192021

22232425

26

27

2829

30

3132

33

343536

37

3839

40

4142



in which case, it shall be backed up whenever it is activated or every 7 days, whichever is later. At least one full backup copy shall be stored at an off-site location (separate from CA equipment). Only the latest full backup need be retained. The backup shall be stored at a site with physical and procedural controls commensurate to that of the operational CA.

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

5.2 Procedural Controls

5.2.1 Corporate ControlsThe 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.

5.2.2 Trusted RolesThe 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.

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

The roles are defined as:

1. Administrator

2. Officer

3. Auditor

4. Operator

5. Registration Authority

Administrators and operators do not issue certificates to devices.

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.

5.2.2.1 AdministratorThe Administrator shall be responsible for:

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.

5.2.2.2 OfficerThe Officer shall be responsible for issuing certificates, that is:

Page - 32


1

2

1234

5

6

7

89

1011

12

131415

161718192021

22

23

24

25

26

27

28

293031

32

33

34353637383940

41

42



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.2.2.3 Audit AdministratorThe Audit Administrator shall be responsible for:

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.

5.2.2.4 OperatorThe operator shall be responsible for the routine operation of the CA equipment and operations such as system backups and recovery or changing recording media.

5.2.2.5 Registration AuthorityThe Registration Authority shall be responsible for:

Verifying identity information. Entering device information and verifying correctness. Securely communicating requests to and from CA. Receiving and distributing certificate to the Device Sponsor.

5.2.3 Number of Persons Required per TaskMultiparty 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

Two or more persons are required for the following tasks:

CA key generation; CA signing key activation; CA private key backup.

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.

5.2.4 Identification and Authentication for Each RoleAn individual shall identify and authenticate him/herself before being permitted to perform any actions set forth above for that role or identity.

5.2.5 Roles Requiring Separation of DutiesIndividuals 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.

Role separation, when required as mentioned above, may be enforced by either the CA equipment, or procedurally, or by both means.

Page - 33


1

2

1234

5

6

789

10

1112

13

14

15161718

19

202122232425

26

272829

303132

33

3435

36

3738394041

4243



5.3 Personnel Controls

5.3.1 Qualifications, Experience, and Clearance RequirementsCAs 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.

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:

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.

5.3.2 Background Check ProceduresAll persons filling trusted roles (including CA trusted roles and RA role) shall, at a minimum, pass a background investigation covering the following areas:

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.

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.

Factors revealed in a background check that may be considered grounds for rejecting candidates for Trusted Positions or for taking action against an existing Trusted Person may include but is not limited to the following:

Misrepresentations made by the candidate or Trusted Person Highly unfavorable or unreliable personal references Certain criminal convictions Indications of a lack of financial responsibility

Page - 34


1

2

1

2

3456

78

9101112131415161718

1920

21222324252627282930

31

3233

343536373839

404142

4344

45464748



5.3.3 Training RequirementsAll 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:

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.

5.3.4 Retraining Frequency and RequirementsAll 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.

Documentation shall be maintained identifying all personnel who received training and the level of training completed.

5.3.5 Job Rotation Frequency and SequenceNo stipulation.

5.3.6 Sanctions for Unauthorized ActionsThe 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.

5.3.7 Independent Contractor RequirementsContractors fulfilling trusted roles are subject to all personnel requirements stipulated in this policy.

PKI vendors who provide any services shall establish procedures to ensure that any subcontractors perform in accordance with this policy and the CPS.

5.3.8 Documentation Supplied to PersonnelThe 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.

5.4 Audit Logging ProceduresAudit 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.

5.4.1 Types of Events RecordedAll 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):

The type of event; The date and time the event occurred; A success or failure indicator when executing the CA’s signing process;

Page - 35


1

2

1

23

45678

9

10111213

1415

16

17

18

1920

21

22

2324

25

262728

29

3031323334

35

363738

394041



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

SECURITY AUDIT

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

IDENTIFICATION AND AUTHENTICATION

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

LOCAL DATA ENTRY

All security-relevant data that is entered in the system X X X

REMOTE DATA ENTRY

All security-relevant messages that are received by the system X X X

DATA EXPORT AND OUTPUT

All successful and unsuccessful requests for confidential and security-relevant information

X X X

KEY GENERATION

Whenever the device generates a key. (Not mandatory for single session or one-time use symmetric keys)

X X X

PRIVATE KEY LOAD AND STORAGE

The loading of device private keys X X X

Page - 36


1

2

1234

56



All access to certificate subject private keys retained within the CA for key recovery purposes

X N/A N/A

TRUSTED PUBLIC KEY ENTRY, DELETION AND STORAGE

All changes to the trusted public keys, including additions and deletions X X X

SECRET KEY STORAGE

The manual entry of secret keys used for authentication X X X

PRIVATE AND SECRET KEY EXPORT

The export of private and secret keys (keys used for a single session or message are excluded)

X X X

CERTIFICATE REGISTRATION

All certificate requests X N/A X

CERTIFICATE REVOCATION

All certificate revocation requests X N/A X

CERTIFICATE STATUS CHANGE APPROVAL

The approval or rejection of a certificate status change request X N/A N/A

CA CONFIGURATION

Any security-relevant changes to the configuration of the component X X X

ACCOUNT ADMINISTRATION

Roles and users are added or deleted X - -

The access control privileges of a user account or a role are modified X - -

CERTIFICATE PROFILE MANAGEMENT

All changes to the certificate profile X N/A N/A

CERTIFICATE STATUS AUTHORITY MANAGEMENT

All Changes to the CSA profile (e.g. OCSP Profile) N/A X N/A

REVOCATION PROFILE MANAGEMENT

All changes to the revocation profile X N/A N/A

CERTIFICATE REVOCATION LIST PROFILE MANAGEMENT

All changes to the Certificate Revocation List profile X N/A N/A

Page - 37


1

2



MISCELLANEOUS

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

Configuration changes

Hardware X X -

Software X X X

Operating system X X X

Patches X X -

Security profiles X X X

Page - 38


1

2



PHYSICAL ACCESS / SITE SECURITY

Personnel access to room housing Component X - -

Access to the Component X X -

Known or suspected violations of physical security X X X

ANOMALIES

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

5.4.2 Frequency of Processing LogAudit 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.

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.

Page - 39


1

2

1

2

3456789

101112



5.4.3 Retention Period for Audit LogAudit 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.

5.4.4 Protection of Audit LogsSystem 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.

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.

It is acceptable for the system to over-write audit logs after they have been backed up and archived.

5.4.5 Audit Log Backup ProceduresAudit 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.

5.4.6 Audit Collection System (Internal vs. External)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.

5.4.7 Notification to Event-Causing SubjectThere is no requirement to notify a subject that an event was audited. Real-time alerts are neither required nor prohibited by this policy.

5.4.8 Vulnerability AssessmentsNo stipulation beyond Section 5.4.2.

5.5 Records Archival

5.5.1 Types of Events ArchivedCA, 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:

Data To Be Archived CA CSA RA

Certificate Policy X X X

Certification Practice Statement X X X

Page - 40


1

2

1

2345

6

7

89

10

111213

14

15

161718

19

2021222324

25

2627

28

29

30

31

323334



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

5.5.2 Retention Period for ArchiveArchive records must be kept for a minimum of 10 years and 6 months, or as further required by applicable law or industry regulation.

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.

5.5.3 Protection of ArchiveThe archive must be protected as specified by the privacy laws of the country where the device information was collected.

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 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.

Page - 41


1

2

1

2

34

56789

10

1112

13141516171819



5.5.4 Archive Backup ProceduresThe CPS or a referenced document shall describe how archive records are backed up, and how the archive backups are managed.

5.5.5 Requirements for Time-Stamping of RecordsCA 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.

5.5.6 Procedures to Obtain and Verify Archive InformationProcedures, detailing how to create, verify, package, transmit, and store archive information, shall be described in the applicable CPS.

5.6 Key ChangeoverNo specific Requirement

5.7 Compromise and disaster recovery

5.7.1 Incident and Compromise Handling ProceduresEach organization operating an Entity PKI shall have a formal disaster recovery plan.

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.

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.

The APPA will take appropriate steps to protect the integrity of the PKI.

The CA’s Management Authority shall reestablish operational capabilities as quickly as possible in accordance with procedures set forth in the CA's CPS.

5.7.2 Computing Resources, Software, and/or Data Are Corrupted 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.

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.

Page - 42


1

2

1

23

4

56

7

89

10

11

12

13

14

151617

1819202122

23

2425

26

272829303132333435363738394041



5.7.3 Private Key Compromise ProceduresIf 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.

The APPA shall also investigate what caused the compromise or loss, and what measures must be taken to preclude recurrence.

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.

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.

5.7.4 Business Continuity Capabilities after a DisasterThe 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.

5.8 CA, CSA, or RA Termination

When a CA operating under this policy terminates operations before all certificates have expired, the CA signing keys shall be surrendered to the APPA.

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


1

2

1

23456789

101112

1314

15161718

192021222324252627

28

2930

31

32

3334

35

363738



6. TECHNICAL SECURITY CONTROLS6.1 Key Pair Generation and Installation

6.1.1 Key Pair GenerationKey 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.

The following table provides the requirements for key pair generation for the various entities:

Entity FIPS 140-1/2 Level

Hardware

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

Random numbers for medium-hardware assurance level keys shall be generated in FIPS 140 Level 2 approved hardware cryptographic modules.

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.

6.1.1.1 CA Key Pair GenerationCA 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.

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.

6.1.1.2 Device Key Pair GenerationDevice 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.

6.1.2 Private Key Delivery to DevicesA CA shall generate its own key pair and therefore does not need private key delivery.

Device key pair generation may be performed by the device. In this case, the private key delivery to a device is unnecessary.

Page - 44


1

2

1

2

3

456

7

8

910

111213

14

1516

17181920

21

2223

24

25

2627



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.

The CA or the RA shall maintain a record of the Device Sponsor acknowledgement of receipt of the token.

6.1.3 Public Key Delivery to Certificate IssuerWhere 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.

6.1.4 CA Public Key Delivery to Relying PartiesThe 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:

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.

Systems using cryptographic hardware tokens shall store trusted certificates such that unauthorized alteration or replacement is readily detectable.

6.1.5 Key SizesKey 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.

AeroMACS certificates shall meet the following requirements for algorithm type and key size:

Table 1: Algorithm Type and Key Size

Root CA Sub-CA Device Cert

Digest Algorithm SHA-256 SHA-256 SHA-256

Page - 45


1

2

12

3456789

1011121314

15

16

17181920

21

222324

2526272829303132

3334

35

3637

38

39



Elliptic Curve Cryptography

P-256, 384 P-256, 384 P-256

6.1.6 Public Key Parameters Generation and Quality CheckingElliptic Curve Cryptography (ECC) keys shall be generated in accordance with FIPS 186-2, and curves from FIPS 186-2 shall be used.

6.1.7 Key Usage Purposes (as per X.509 v3 Key Usage Field)The use of a specific key is constrained by the keyUsage extension in the X.509 certificate.

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):

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

Field Format Criticality Value Comment

keyUsage BIT STRING TRUE { id-ce 15 } 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

Table 3 shows the specific keyUsage extension settings for AeroMACS Device and Sserver certificates and specifies that all Device and Sserver 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

Page - 46


1

2

1

2

34

5

6

789

101112

13

14

1516

17181920



Table 3: keyUsage Extension for all Device Certificates


keyUsage BIT STRING TRUE { id-ce 15 } 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.

6.2 Private Key Protection and Cryptographic Module Engineering Controls

6.2.1 Cryptographic Module Standards and ControlsPrivate 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.

The relevant standard for cryptographic modules is Security Requirements for Cryptographic Modules [FIPS 140-2].

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.

6.2.2 Private Key (n out of m) Multi-Person ControlA 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.

6.2.3 Private Key EscrowCA private signature keys and Device private signatures keys shall not be escrowed.

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.

Page - 47


1

2

1

23

4

5

678

9

1011

12

13141516

17

18

1920



6.2.4 Private Key BackupThe 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 shall be accounted for and protected in the same manner as the original. Backup procedures shall be included in the CA’s CPS.

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.

6.2.5 Private Key ArchivalCA 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.

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.

6.2.6 Private Key Transfer into or from a Cryptographic ModuleCA 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.

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.

Private or symmetric keys used to encrypt other private keys for transport must be protected from disclosure.

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.

6.2.7 Private Key Storage on Cryptographic ModuleNo stipulation beyond that specified in FIPS 140.

6.2.8 Method of Activating Private KeyAll CAs shall protect the activation data for their private keys against loss, theft, modification, disclosure, or unauthorized use.

CA Administrator Activation

Method of activating the CA system by a CA Administrator shall require:

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.

Offline CAs Private Key

Page - 48


1

2

1

2345

6789

10

1112131415

161718

19

202122

232425

26

2728

29

30

31

3233

34

35

363738394041

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.

Online CAs Private Keys

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.

Device Private Keys

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.

6.2.9 Method of Deactivating Private KeyCryptographic 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.

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.

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.

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.

6.2.10 Method of Destroying Private KeyPrivate 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.

6.2.11 Cryptographic Module RatingSee CP section 6.2.1.

6.3 Other Aspects of Key Pair Management

6.3.1 Public Key ArchivalThe 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.

6.3.2 Certificate Operational Periods and Key Pair Usage PeriodsThe 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

Page - 49


1

2

123

4

567

8

9101112

13

141516

1718

192021

222324

25

26272829

30

31

32

33

3435

36

3738



CA 20 Years 20 Years

CSA 10 Years 10 Years

Device 3-5 Years 3-5 Years

Server 1 Year 1 Year

Validity periods shall be nested such that the validity periods of issued certificates shall be contained within the validity period of the issuing CA.

AeroMACS PKI Participants shall cease all use of their key pairs after their validity periods have expired.

Cross certificates shall not be valid for more than 10 years.

6.4 Activation data

6.4.1 Activation Data Generation and InstallationThe 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 user-selected. 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 policy-enforced 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.

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.

6.4.2 Activation Data ProtectionData 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.

6.4.3 Other Aspects of Activation DataCAs, CSAs, and RAs shall change the activation data whenever the token is re-keyed or returned for maintenance.

6.5 Computer security controls

6.5.1 Specific Computer Security Technical RequirementsThe 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:

Require authenticated logins

Page - 50


1

2

1

23

4

5

6

7

89

1011121314

151617

18

192021222324

25

26

27

28

293031

32



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 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

The computer system shall be configured with the minimum of the required accounts and network services, and shall not permit remote login.

The computer system hosting the CA must have been hardened against all known threats.

6.5.2 Computer Security RatingNo Stipulation.

6.6 Life Cycle Technical Controls

6.6.1 System Development ControlsThe 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 off-the-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.

6.6.2 Security Management ControlsThe 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.

The CA shall also have mechanisms and policies in place to control and monitor the configuration of the CA system.

6.6.3 Life Cycle Security ControlsNo Stipulation.

Page - 51


1

2

123456789

10

1112

13

14

15

16

17

1819202122232425262728293031323334353637

38

39404142

43

44

45



6.7 Network Security ControlsCAs, 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.

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.

6.8 Time-StampingAll 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:

Initial validity type of a Device’s Certificate;

Revocation of a Device’s Certificate

Posting of CRL updates; and

OCSP or other CSA responses.

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).

Page - 52


1

2

1

2345

67

8

91011

12

13

14

15

161718

19



7. CERTIFICATE, CRL, AND OCSP PROFILES6.

7.

8.

9.

10.

11.

12.

7.1 Certificate ProfileAeroMACS Certificates shall conform to [RFC 5280]: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, May 2008.

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

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.

signatureAlgorithm 4.1.1.2 Follows [RFC 5280] guidance

Page - 53


1

2

1

2

3

4

5

6

7

8

9

1011

1213141516

17



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.

signatureValue 4.1.1.3 Follows [RFC 5280] guidance

7.1.1 Version Number(s)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.

7.1.2 Certificate ExtensionsAeroMACS 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.

Table 5 shows the certificate extensions for all AeroMACS Root CA certificates.

Table 5: Root CA Certificate Standard Extensions

Field 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 (Optional Extension)See CP section Error: Reference source not found.

subjectAlternativeName [RFC 5280] 4.2.1.6 (Optional Extension)May be included in Root CA certificate.Criticality shall be set to FALSE.

basicConstraints [RFC 5280] 4.2.1.9 See Table 10.

Table 6 shows the certificate extensions for all AeroMACS CA certificates.

Table 6: CA Certificate Standard Extensions



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.


certificatePolicies [RFC 5280] 4.2.1.4 See CP section Error: Reference source not

Page - 54


1

2

1

2

34

5

678

9

10

11

12



found.

subjectAlternativeName [RFC 5280] 4.2.1.6 (Optional Extension)May be included in CA certificates.Criticality shall be set to FALSE.

basicConstraints [RFC 5280] 4.2.1.9 See Table 11.

crlDistributionPoints [RFC 5280] This extension must appear in all CA certificates and must contain at least one URI either HTTP or LDAP. The reasons and cRLIssuer Fields must be omitted.

Table 7 shows the certificate extensions for all AeroMACS device certificates.

Table 7: Device Certificate Standard Extensions



authorityKeyIdentifier [RFC 5280] 4.2.1.1 Shall be included in Device certificates.Criticality shall be set to FALSE.


certificatePolicies [RFC 5280] 4.2.1.4 See CP section Error: Reference source not found.

subjectAltName [RFC 5280] 4.2.1.6 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.

extKeyUsage [RFC 5280] 4.2.1.12 (Optional Extension)See Table 12 for server certificates.See Table 13 for device certificates..Table 13

Table 8 shows the certificate extensions for all AeroMACS OCSP server certificates.

Table 8: OCSP Certificate Standard Extensions



authorityKeyIdentifier [RFC 5280] 4.2.1.1 Shall be included in OCSP certificates.Criticality shall be set to FALSE.

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.

Page - 55


1

2

1

2

3

4

5



Criticality shall be set to FALSE.

Subject Key Identifier ExtensionTable 9 shows the subjectKeyIdentifier extension settings for AeroMACS CA certificates and specifies that all AeroMACS Root and CA certificates:

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


subjectKeyIdentifier FALSE { id-ce 14 } Included in all CA certificates

keyIdentifier OCTET STRING

<key identifier> Calculated per Method 1.

Device Certificates shall not include the subjectKeyIdentifier extension.

Basic Constraints ExtensionTable 10 shows the basicConstraints extension settings for AeroMACS Root CA certificates and specifies that all AeroMACS Root 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 to TRUE

Table 10: basicConstraints Extension for AeroMACS Root CA Certificates


basicConstraints TRUE { id-ce 19 } Included in all Root certificates

cA BOOLEAN TRUE Set

pathLenConstraint INTEGER Not Set

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


basicConstraints TRUE { id-ce 19 } Included in all CA certificates

Page - 56


1

2

6

1

23

456

7

8

9

1011

121314

15

16

1718

19202122

23



cA BOOLEAN TRUE Set

pathLenConstraint INTEGER 0

Device Certificates shall not include the basicConstraints extension.

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.

Extended Key Usage CA Certificates shall not include the extKeyUsage extension.

Table 12 shows the extKeyUsage extension settings for AeroMACS server certificates and specifies that all AeroMACS server certificates:

May include the extKeyUsage extension If included, shall set the criticality of the extKeyUsage extension to FALSE Shall set the keyPurposeId field of the extKeyUsage to id-kp-serverAuth and id-kp-clientAuth

Table 12: extKeyUsage Extension for AeroMACS Server Certificates


extKeyUsage FALSE { id-ce 37 } May be included in device server certificates.

keyPurposeID OID 1.3.6.1.5.5.7.3.1

1.3.6.1.5.5.7.3.2

id-kp-serverAuth

id-kp-clientAuth

Table 13 shows the extKeyUsage extension settings for AeroMACS Device certificates and specifies that all AeroMACS device certificates:

May include the extKeyUsage extension If included, shall set the criticality of the extKeyUsage extension to FALSE Shall set the keyPurposeId field of the extKeyUsage to id-kp-clientAuth

Table 13: extKeyUsage Extension for AeroMACS Device Certificates


extKeyUsage FALSE { id-ce 37 } May be included in device certificates.

keyPurposeID OID 1.3.6.1.5.5.7.3.2 id-kp-clientAuth

[7.1.3] Algorithm Object Identifiers (OIDs)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 14).

Table 14: Signature OIDS for Certificates


Page - 57


1

2

1

2345

6

7

89

101112

13

1415

161718

19

20

2122

23



signature

algorithmIdentifier

algorithm OID 1.2.840.10045.4.3.2 ecdsa-with-Sha256

parameters ANY 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 15).

Table 15: subjectPublicKeyInfo for Certificates


subjectPublicKeyInfo

algorithm

algorithmIdentifier

algorithm OID 1.2.840.10045.2.1 EC Public Key

parameters ANY 1.2.840.10045.3.1.7 secp256r1

1.3.132.0.34 secp384r1

subjectPublicKey BIT STRING <subject public key> Modulus length. See CP section 6.1.5.

7.1.3[7.1.4] Name FormsRoot CAs

The following naming attributes shall be used to populate the issuer and subject fields in Root CA Certificates issued under this CP:

Table 16: Root CA Certificate Issuer and Subject Fields

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#>”

Page - 58


1

2

12

3

4

5

6

78

9



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)

CAs

The following naming attributes shall be used to populate the CA Certificate subject fields issued under this CP:

Table 17: CA Certificate Subject Fields


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”.

commonName (CN=) <Name> CA Shall contain a name that accurately identifies the CA. (e.g. CompanyA CA)

Device Certificates

The following naming attributes shall be used to populate the Subject in Device Certificates issued under this CP:

Table 18: Device Certificate Subject Fields


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 (Optional) When included, one or more OUs

Page - 59


1

2

1

2

3

4

5

6

7

8



Information> 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.

7.1.4[7.1.5] Name ConstraintsThe CAs shall not assert name constraints in AeroMACS certificates.

7.1.5[7.1.6] Certificate Policy Object IdentifierCA and device certificates issued under this CP shall assert the policy OID listed in Section 1.2.2 of this document.

Table 19 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

Table 19: certificatePolicies Extension for AeroMACS Certificates

Field Format Criticality

Value Comment

certificatePolicies FALSE { id-ce 32 } May be included in all AeroMACS certificates

policyInformation

policyIdentifier OID <Certificate policy OID>

See Section 1.2.2

policyQualifiers SEQUENCE Not Set

7.1.6[7.1.7] Usage of Policy Constraints ExtensionThe CAs shall not assert policy constraints in CA certificates.

7.1.7[7.1.8] Policy Qualifiers Syntax and SemanticsCertificates issued under this CP shall not contain policy qualifiers.

Page - 60


1

2

1

2

3

4

5

67

89

10

11

12

13

14

15

16



7.1.8[7.1.9] Processing Semantics for the Critical Certificate Policies ExtensionProcessing semantics for the critical certificate policy extension shall conform to X.509 certification path processing rules.

7.2 CRL ProfileCRLs shall conform to [RFC 5280] and contain the basic fields and contents specified in the table below:

Table 20: CRL Profile Basic Fields



version [RFC 5280] 5.1.2.1 See Section 7.2.1.

signature [RFC 5280] Algorithm used to sign the CRL.

issuer [RFC 5280] 5.1.2.3 Entity that has signed and issued the CRL.

thisUpdate [RFC 5280] 5.1.2.4 Indicates the issue date of the CRL. CRLs are effective upon issuance.

nextUpdate [RFC 5280] 5.1.2.5 Indicates the date by which the next CRL will be issued.

revokedCertificates [RFC 5280] 5.1.2.6 Listing of revoked certificates, including the Serial Number of the revoked Certificate and the Revocation Date.

authoritKeyIdentifier [RFC 5280] 5.2.1 Follows the guidance in RFC 5280. Criticality is FALSE.

cRLNumber [RFC 5280] 5.2.3 A monotonically increasing sequence number for a given CRL scope and issuer. Criticality is FALSE.

signatureAlgorithm [RFC 5280] 5.1.1.2 Follows the guidance in RFC 5280.

signatureValue [RFC 5280] 5.1.1.3 Follows the guidance in RFC 5280.

7.2.1 Version Number(s)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].

7.2.2 CRL and CRL entry extensionsCritical CRL extensions shall not be used.

7.3 OCSP ProfileOCSP 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:

Page - 61


1

2

1

23

4

5

6

7

8

910

11

12

13

1415



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].

7.3.1 Version Number(s)OCSP responses shall support use of OCSP version 1 as defined by [RFC2560] and [RFC5019].

7.3.2 OCSP ExtensionsCritical OCSP extensions shall not be used.

Page - 62


1

2

1234

5

6

7

8



8. Compliance Audit and Other AssessmentsCAs 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.

This specification does not impose a requirement for any particular assessment methodology.

8.1 Frequency or Circumstances of AssessmentAll CAs, RAs and CSAs operating under this policy shall be subject to a periodic compliance audit at least once per year.

8.2 Identity and Qualifications of AssessorThe 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.

8.3 Assessor's Relationship to Assessed EntityThe 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.

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.

8.4 Topics Covered by AssessmentThe 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.

8.5 Actions Taken as a Result of DeficiencyWhen 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 - 63


1

2

1

23

4

5

67

8

9101112

13

14151617181920

2122

23

24252627

28

2930

3132333435

3637383940



8.6 Communication of ResultsAn 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 - 64


1

2

1

234567



9. Other Business and Legal Matters9.1 FeesAny fees must be approved by the APPA

9.1.1 Certificate Issuance or Renewal FeesSection 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.

9.1.2 Certificate Access FeesSection 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.

9.1.3 Revocation or Statue Information Access FeesCAs operating under this policy must not charge additional fees for access to CRLs and OCSP status information.

9.1.4 Fees for other ServicesNo stipulation.

9.1.5 Refund PolicyNo stipulation.

9.2 Financial ResponsibilityThis 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.

9.2.1 Insurance Coverage

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.

9.2.2 Other AssetsNo stipulation.

9.2.3 Insurance or Warranty Coverage for End-EntitiesNo stipulation.

9.3 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.

Page - 65


1

2

1

2

3

4

56

7

89

10

11

12

13

14

15

16

171819

20

212223

24

25

26

27

28

29303132



9.3.1 Scope of Confidential InformationConfidential 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.

9.3.2 Information not within the Scope of Confidential InformationInformation that is generally known to the public or properly known by the receiving party at the time of disclosure and other typical exceptions.

9.3.3 Responsibility to Protect Confidential InformationNo stipulation.

9.4 Privacy of Personal InformationIt 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.

9.4.1 Privacy PlanThe 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.

9.4.2 Information Treated as PrivateEntities 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.

9.4.3 Information not Deemed PrivateInformation included in certificates is not subject to protections outlined in section 9.4.2.

9.4.4 Responsibility to Protect Private InformationSensitive information must be stored securely, and may be released only in accordance with other stipulations in section 9.4.

9.4.5 Notice and Consent to Use Private InformationThe 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.

9.4.6 Disclosure Pursuant to Judicial or Administrative ProcessThe 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 - 66


1

2

1

2

345

6

78

9

10

11

1213141516

17

18192021

22

23242526

27

28

29

3031

32

3334

35

3637



9.4.7 Other Information Disclosure CircumstancesExcept 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.

9.5 Intellectual Property RightsThe APPA will not knowingly violate intellectual property rights held by others.

The CP, CPS, each root certificate and all certificates issued under the root certificate are the property of the APPA.

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.

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:

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;

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;

Remove or alter any trademark or any copyright or other proprietary notice on any software, system or any other materials;

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.

Provide any service using a certificate provided under this CP except as authorized and provided in this CP and an approved CPS.

These restrictions shall not be construed in a manner that would violate any applicable law.

9.6 Representations and WarrantiesThe obligations described below pertain to the APPA.

The APPA shall—

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 - 67


1

2

1

234

5

6

7

89

1011

121314

15161718

1920

2122

2324

25

26

27

28

29

3031323334353637383940



9.6.1 CA Representations and WarrantiesCAs 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.

A CA that issues certificates that assert a policy defined in this document shall conform to the stipulations of this document, including—

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.

9.6.2 RA Representations and WarrantiesAn 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—

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.

9.6.3 Device Representations and WarrantiesIf 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.

9.6.4 Relying Parties Representations and WarrantiesThis 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.

9.6.5 Representations and Warranties of Other ParticipantsNone

9.7 Disclaimers of WarrantiesCAs operating under this policy may not disclaim any responsibilities described in this CP.

Page - 68


1

2

1

234

56

789

10111213141516

17

18192021

2223242526

27

282930313233

34

35363738

39

40

41

42



9.8 Limitations of LiabilityICAO 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.

9.9 IndemnitiesNo stipulation.

9.10 Term and Termination

9.10.1 TermThis CP becomes effective when approved by the APPA. This CP has no specified term.

9.10.2 TerminationTermination of this CP is at the discretion of the APPA.

9.10.3 Effect of Termination and SurvivalThe requirements of this CP remain in effect through the end of the archive period for the last certificate issued.

9.11 Individual Notices and Communications with ParticipantsThe APPA shall establish appropriate procedures for communications with CAs operating under this policy via contracts or memoranda of agreement as applicable.

For all other communications, no stipulation.

9.12 Amendments

9.12.1 Procedure for AmendmentChanges to items within this CP shall be performed in accordance with the Change Request Procedure of the Aviation Working Group.

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.

9.12.2 Notification and Mechanism and PeriodNotification shall be performed in accordance with the Change Request procedure of the Aviation Working Group.

9.12.3 Circumstances under which OID must be ChangedCertificate Policy OIDs shall be changed if the CA determines that a change in the CP reduces the level of assurance provided.

9.13 Dispute Resolution ProvisionsThe APPA shall facilitate the resolution between entities when conflicts arise as a result of the use of certificates issued under this policy.

Page - 69


1

2

1

23

4

5

6

7

8

9

10

11

12

13

1415

16

17

18

1920

21222324

25

26

27

2829

30

3132



9.14 Governing LawThe 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).

9.15 Compliance with Applicable LawAll CAs operating under this policy are required to comply with applicable law.

9.16 Miscellaneous Provisions

9.16.1 Entire AgreementNo stipulation.

9.16.2 AssignmentNo stipulation.

9.16.3 SeverabilityShould 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.

9.16.4 Enforcement (Attorneys’ Fees and Waiver of Rights)No stipulation.

9.16.5 Force MajeureNo stipulation.

9.17 Other ProvisionsNo stipulation.

Page - 70


1

2

1

23

4

5

6

7

8

9

10

11

1213

14

15

16

17

18

19

20

Susan Joseph, 02/17/16,

This will have to be changed.



10. ReferencesNS4009 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 - 71


1

2

1

http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf

http://www.ietf.org/rfc/rfc5280.txt







11.GlossaryThis 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 (CPS)

A statement of the practices that a CA employs in approving or rejecting Certificate Applications and issuing, managing, and revoking 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

Page - 72


1

2

1

2



of, or loss of control over, sensitive information has occurred. With respect to private keys, a Compromise is a loss, theft, disclosure, modification, unauthorized use, or other compromise of the security of such private key.

CRL Usage Agreement An agreement setting forth the terms and conditions under which a CRL or the information in it can be used.

Exigent Audit/Investigation An audit or investigation by AeroMACS where AeroMACS has reason to believe that an entity’s failure to meet PKI Standards, an incident or Compromise relating to the entity, or an actual or potential threat to the security of the PKI posed by the entity has occurred.

Elliptic Curve Cryptography (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 on-line.

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.

Page - 73


1

2



Subscriber Agreement An agreement used by a CA setting forth the terms and conditions 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 - 74


1

2



12. Abbreviations and AcronymsThis 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 - 75


1

2

1

2



Accountants)

URI Uniform Resource Identifier

Page - 76


1

2

1

aeromacs pki certificate policy - international civil … wg-s 9/wp05.1... · web viewprocessing...

Documents