aeromacs pki certificate policy wg-s 8/wp3.1... · web view12/07/2015 12:14:00 title aeromacs pki...

WiMAX FORUM PROPRIETARY

WiMAX Forum® Network Architecture

AeroMACS PKI Certificate Policy

DRAFT-T32-006-R010v01-DDraft Specification

(2015-11-23)

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

1

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


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

Key to Document Status Codes:

Work in Progress An incomplete document, designed to guide discussion and generate feedback that may include several alternative requirements for consideration.

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

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

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

Page - ii


1

2

1

2

3

4



Page - iii


1

2



TABLE OF CONTENTS

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

1. INTRODUCTION............................................................................................................................8

1.1 Overview.........................................................................................................................................81.2 Document Name and Identification................................................................................................81.3 PKI Participants...............................................................................................................................81.4 Certificate Usage.............................................................................................................................81.5 Policy Administration.....................................................................................................................81.6 Definitions and Acronyms..............................................................................................................8

2. INTRODUCTION............................................................................................................................9

2.1 Repositories.....................................................................................................................................92.2 Publication of Certification Information.........................................................................................92.3 Time or Frequency of Publication...................................................................................................92.4 Access Controls on Repositories.....................................................................................................9

3. IDENTIFICATION AND AUTHENTICATION........................................................................10

3.1 Naming..........................................................................................................................................103.2 Initial Identity Validation..............................................................................................................103.3 Identification and Authentication for Re-key Requests................................................................103.4 Identification and Authentication for Revocation Request...........................................................10

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

4.1 Certificate Application..................................................................................................................114.2 Certificate Application Processing................................................................................................114.3 Certificate Issuance.......................................................................................................................114.4 Certificate Acceptance..................................................................................................................114.5 Key Pair and Certificate Usage.....................................................................................................114.6 Certificate Renewal.......................................................................................................................114.7 Certificate Re-key.........................................................................................................................114.8 Certificate Modification................................................................................................................114.9 Certificate Revocation and Suspension.........................................................................................114.10 Certificate Status Services.............................................................................................................114.11 End of Subscription.......................................................................................................................114.12 Key Escrow and Recovery............................................................................................................11

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

5.1 Physical Controls...........................................................................................................................125.1.1 Site Location and Construction.....................................................................................................125.1.2 Physical Access for CA Equipment..............................................................................................125.1.3 Power and Air Conditioning.........................................................................................................135.1.4 Water Exposures...........................................................................................................................135.1.5 Fire Prevention and Protection......................................................................................................135.1.6 Media Storage...............................................................................................................................135.1.7 Waste Disposal..............................................................................................................................135.1.8 Off-Site Backup.............................................................................................................................13

Page - iv


1

2

1

2

3

456789

10

11121314

15

16171819

20

212223242526272829303132

33

343536373839404142



5.2 Procedural Controls.......................................................................................................................135.2.1 Trusted Roles.................................................................................................................................135.2.2 Number of Persons Required per Task.........................................................................................145.2.3 Identification and Authentication for Each Role...........................................................................155.2.4 Roles Requiring Separation of Duties...........................................................................................155.3 Personnel Controls........................................................................................................................155.3.1 Qualifications, Experience, and Clearance Requirements............................................................155.3.2 Background Check Procedures.....................................................................................................155.3.3 Training Requirements..................................................................................................................165.3.4 Retraining Frequency and Requirements......................................................................................165.3.5 Job Rotation Frequency and Sequence..........................................................................................165.3.6 Sanctions for Unauthorized Actions.............................................................................................165.3.7 Independent Contractor Requirements..........................................................................................165.3.8 Documentation Supplied to Personnel..........................................................................................175.4 Audit Logging Procedures............................................................................................................175.4.1 Types of Events Recorded.............................................................................................................175.4.2 Frequency of Processing Log........................................................................................................195.4.3 Retention Period for Audit Log.....................................................................................................195.4.4 Protection of Audit Log.................................................................................................................195.4.5 Audit Log Backup Procedures......................................................................................................195.4.6 Audit Collection System (Internal vs. External)...........................................................................195.4.7 Notification to Event-Causing Subject..........................................................................................205.4.8 Vulnerability Assessments............................................................................................................205.5 Records Archival...........................................................................................................................205.5.1 Types of Events Archived.............................................................................................................205.5.2 Retention Period for Archive........................................................................................................205.5.3 Protection of Archive....................................................................................................................215.5.4 Archive Backup Procedures..........................................................................................................215.5.5 Requirements for Time-Stamping of Records..............................................................................215.5.6 Archive Collection System (Internal or External).........................................................................215.5.7 Procedures to Obtain and Verify Archive Information.................................................................215.6 Key Changeover............................................................................................................................215.7 Compromise and disaster recovery...............................................................................................215.7.1 Incident and Compromise Handling Procedures...........................................................................215.7.2 Computing Resources, Software, and/or Data Are Corrupted......................................................225.7.3 Entity (CA) Private Key Compromise Procedures.......................................................................225.7.4 Business Continuity Capabilities after a Disaster.........................................................................225.8 CA Termination.............................................................................................................................22

6. TECHNICAL SECURITY CONTROLS.....................................................................................23

6.1 Key Pair Generation and Installation............................................................................................236.1.1 Key Pair Generation......................................................................................................................236.1.2 Private Key Delivery to Subscriber...............................................................................................236.1.3 Public Key Delivery to Certificate Issuer.....................................................................................246.1.4 CA Public Key Delivery to Relying Parties..................................................................................246.1.5 Key Sizes.......................................................................................................................................246.1.6 Public Key Parameters Generation and Quality Checking...........................................................246.1.7 Key Usage Purposes (as per X.509 v3 Key Usage Field).............................................................246.2 Private Key Protection and Cryptographic Module Engineering Controls..................................276.2.1 Cryptographic Module Standards and Controls............................................................................27

Page - v


1

2

123456789

1011121314151617181920212223242526272829303132333435363738

39

40414243444546474849



6.2.2 Private Key (n out of m) Multi-Person Control............................................................................276.2.3 Private Key Escrow.......................................................................................................................286.2.4 Private Key Backup.......................................................................................................................286.2.5 Private Key Archival.....................................................................................................................286.2.6 Private Key Transfer into or from a Cryptographic Module.........................................................286.2.7 Private Key Storage on Cryptographic Module............................................................................296.2.8 Method of Activating Private Key................................................................................................296.2.9 Method of Deactivating Private Key.............................................................................................296.2.10 Method of Destroying Private Key...............................................................................................306.2.11 Cryptographic Module Rating.......................................................................................................306.3 Other Aspects of Key Pair Management.......................................................................................306.3.1 Public Key Archival......................................................................................................................306.3.2 Certificate Operational Periods and Key Pair Usage Periods.......................................................306.4 Activation data..............................................................................................................................306.4.1 Activation Data Generation and Installation.................................................................................306.4.2 Activation Data Protection............................................................................................................316.4.3 Other Aspects of Activation Data.................................................................................................316.5 Computer security controls...........................................................................................................316.5.1 Specific Computer Security Technical Requirements..................................................................316.5.2 Computer Security Rating.............................................................................................................326.6 Life Cycle Technical Controls......................................................................................................326.6.1 System Development Controls......................................................................................................326.6.2 Security Management Controls.....................................................................................................336.6.3 Life Cycle Security Controls.........................................................................................................336.7 Network Security Controls............................................................................................................336.8 Time-Stamping..............................................................................................................................33

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

7.1 Certificate Profile..........................................................................................................................347.1.1 Version Number(s)........................................................................................................................347.1.2 Certificate Extensions...................................................................................................................357.1.3 Algorithm Object Identifiers (OIDs).............................................................................................387.1.4 Name Forms..................................................................................................................................397.1.5 Name Constraints..........................................................................................................................417.1.6 Certificate Policy Object Identifier...............................................................................................417.1.7 Usage of Policy Constraints Extension.........................................................................................417.1.8 Policy Qualifiers Syntax and Semantics.......................................................................................417.1.9 Processing Semantics for the Critical Certificate Policies Extension...........................................417.2 CRL Profile...................................................................................................................................417.2.1 Version Number(s)........................................................................................................................427.2.2 CRL and CRL entry extensions....................................................................................................427.3 OCSP Profile.................................................................................................................................427.3.1 Version Number(s)........................................................................................................................427.3.2 OCSP Extensions..........................................................................................................................42

8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS..........................................................44

8.1 Frequency or Circumstances of Assessment.................................................................................448.2 Identity/Qualifications of Assessor...............................................................................................448.3 Assessor's Relationship to Assessed Entity...................................................................................448.4 Topics Covered by Assessment.....................................................................................................44

Page - vi


1

2

123456789

1011121314151617181920212223242526

27

28293031323334353637383940414243

44

45464748



8.5 Actions Taken as a Result of Deficiency......................................................................................448.6 Communication of Results............................................................................................................45

9. OTHER BUSINESS AND LEGAL MATTERS..........................................................................46

9.1 Fees................................................................................................................................................469.2 Financial Responsibility................................................................................................................469.3 Confidentiality of business information........................................................................................469.4 Privacy of Personal Information...................................................................................................469.5 Intellectual Property Rights...........................................................................................................469.6 Representations and Warranties....................................................................................................469.7 Disclaimers of warranties..............................................................................................................469.8 Limitations of liability...................................................................................................................469.9 Indemnities....................................................................................................................................469.10 Term and termination....................................................................................................................469.11 Individual notices and communications with participants............................................................469.12 Amendments..................................................................................................................................469.13 Dispute Resolution Provisions......................................................................................................469.14 Governing Law..............................................................................................................................469.15 Compliance with Applicable Law.................................................................................................469.16 Miscellaneous provisions..............................................................................................................469.17 Other Provisions............................................................................................................................46

10. REFERENCES...............................................................................................................................47

11. GLOSSARY....................................................................................................................................48

12. ABBREVIATIONS AND ACRONYMS......................................................................................51

TABLE OF FIGURES (If applicable)

TABLE OF TABLES

TABLE 1: ALGORITHM TYPE AND KEY SIZE....................................................................................24TABLE 2: KEYUSAGE EXTENSION FOR ALL CA CERTIFICATES..................................................25TABLE 3: KEYUSAGE EXTENSION FOR ALL SUBSCRIBER SIGNATURE CERTIFICATES.......25TABLE 4: KEYUSAGE EXTENSION FOR ALL KEY MANAGEMENT CERTIFICATES.................26TABLE 5: KEYUSAGE EXTENSION FOR ALL SERVER CERTIFICATES.......................................27TABLE 6: CERTIFICATE PROFILE BASIC FIELDS.............................................................................34TABLE 7: ROOT CA CERTIFICATE STANDARD EXTENSIONS.......................................................35TABLE 8: SUB-CA CERTIFICATE STANDARD EXTENSIONS..........................................................35TABLE 9: SUBSCRIBER CERTIFICATE STANDARD EXTENSIONS................................................36TABLE 10: OCSP CERTIFICATE STANDARD EXTENSIONS.............................................................36TABLE 11: SUBJECTKEYIDENTIFIER EXTENSION FOR AEROMACS CA CERTIFICATES........37TABLE 12: BASICCONSTRAINTS EXTENSION FOR AEROMACS ROOT CA CERTIFICATES....37

Page - vii


1

2

12

3

456789

1011121314151617181920

21

22

23

24

25

26

2728

29

30313233343536373839404142



TABLE 13: BASICCONSTRAINTS EXTENSION FOR AEROMACS SUB-CA CERTIFICATES......37TABLE 14: EXTKEYUSAGE EXSTENSION FOR AEROMACS SERVER CERTIFICATES................38TABLE 15: EXTKEYUSAGE EXSTENSION FOR AEROMACS CLIENT CERTIFICATES.................38TABLE 16: SIGNATURE OIDS FOR CERTIFICATES...........................................................................38TABLE 17: SUBJECTPUBLICKEYINFO FOR CERTIFICATE..............................................................39TABLE 18: ROOT CA CERTIFICATE ISSUER AND SUBJECT FIELDS.............................................39TABLE 19: SUB-CA CERTIFICATE SUBJECT FIELDS........................................................................40TABLE 20: SUBSCRIBER CERTIFICATE SUBJECT FIELDS..............................................................40TABLE 21: CERTIFICATEPOLICIES EXTENSION FOR AEROMACS CERTIFICATES..................41TABLE 22: CRL PROFILE BASIC FIELDS.............................................................................................41

Page - viii


1

2

123456789

10111213



1. Introduction1.1 Overview

1.2 Document Name and Identification

1.3 PKI Participants

1.4 Certificate Usage

1.5 Policy Administration

1.6 Definitions and Acronyms

Page - 9


1

2

1

2

3

4

5

6

7



2. Introduction2.1 Repositories

2.2 Publication of Certification Information

2.3 Time or Frequency of Publication

2.4 Access Controls on Repositories

Page - 10


1

2

1

2

3

4

5

6



3. Identification and Authentication3.1 Naming

3.2 Initial Identity Validation

3.3 Identification and Authentication for Re-key Requests

3.4 Identification and Authentication for Revocation Request

Page - 11


1

2

1

2

3

4

5

6



4. Certificate Life-cycle Operational Requirements4.1 Certificate Application

4.2 Certificate Application Processing

4.3 Certificate Issuance

4.4 Certificate Acceptance

4.5 Key Pair and Certificate Usage

4.6 Certificate Renewal

4.7 Certificate Re-key

4.8 Certificate Modification

4.9 Certificate Revocation and Suspension

4.10 Certificate Status Services

4.11 End of Subscription

4.12 Key Escrow and Recovery

Page - 12


1

2

1

2

3

4

5

6

7

8

9

10

11

12

13

14



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.

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

Ensure that no unauthorized access to the hardware is permitted. Ensure that all removable media and paper containing sensitive plain-text information is stored in secure

containers. Be manually or electronically monitored for unauthorized intrusion at all times. Ensure an access log is maintained and inspected periodically. Require two-person physical access control to both the cryptographic module and computer systems.

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

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

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

Page - 13


1

2

1

23

4

5678

910

11

121314151617181920

2122232425

26

2728

293031323334

3536373839

4041

424344



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.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, 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 Trusted RolesA 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

Page - 14


1

2

123

4567

8

91011

12131415

16

1718

19

2021

22

232425

26

2728

29

303132333435

36

37

38

394041



trust for the entire PKI. Two approaches are taken to increase the likelihood that these roles can be successfully carried out. The first ensures that the person filling the role is trustworthy and properly trained. The second distributes the functions among more than one person, so that any malicious activity would require collusion.

The roles are defined as:

1. Administrator – authorized to install, configure, and maintain the CA; establish and maintain system accounts; configure audit parameters; and generate component keys.

2. Officer – authorized to request or approve certificate issuance and revocations.

3. Auditor – authorized to review, maintain, and archive audit logs.

4. Operator – authorized to perform system backup and recovery.

Administrators do not issue certificates to subscribers.

The roles required for each level of assurance are identified in Section 5.2.4. These four roles are employed at the CA and Sub-CA locations as appropriate. Separation of duties shall comply with 5.2.4, and requirements for three person control with 5.2.2, regardless of the titles and numbers of Trusted Roles.

5.2.1.1 AdministratorThe Administrator shall be responsible for:

Installation, configuration, and maintenance of the CA. Establishing and maintaining CA system accounts. Configuring certificate profiles or templates and audit parameters. Generating and backing up CA keys.

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

Registering new subscribers and requesting the issuance of certificates. Verifying the identity of subscribers and accuracy of information included in certificates. Approving and executing the issuance of certificates. Requesting, approving, and executing the revocation of certificates.

5.2.1.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 is operating in accordance with

the CPS.

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

Three or more persons are required for the following tasks:

CA key generation;

Page - 15


1

2

123

4

56

7

8

9

10

111213

14

15

16171819

20

21

22232425

26

27

282930

31

3233

34

353637383940

41

42



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.1. Multiparty control shall not be achieved using personnel that serve in the Auditor trusted role.

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

An individual in a trusted role shall authenticate to remote components of the PKI using a method commensurate with the strength of the PKI.

5.2.4 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 Sub-CA software and hardware shall identify and authenticate its users and shall ensure that no user identity can assume both the Administrator and Officer roles, assume both the Administrator and Auditor roles, or assume both the Auditor and Officer roles. No individual shall have more than one identity.

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:

Have successfully completed an appropriate training program. Have demonstrated the ability to perform their duties. Be trustworthy. Have no other duties that would interfere or conflict with their duties for the trusted role. Have not been previously relieved of duties for reasons of negligence or non-performance of duties. Have not been convicted of a felony offense.

For PKIs operated at medium-software, medium-hardware, and/or high-hardware, each person filling a trusted role shall satisfy at least one of the following requirements:

The person shall be a citizen of the country where the CA is located; or For PKIs operated on behalf of multinational government organizations, the person shall be a citizen of one

of the member countries; or For PKIs located within the European Union, the person shall be a citizen of one of the member states of

the European Union; or The person shall have a security clearance equivalent to U.S. Secret or higher issued by a NATO member

nation or major non-NATO ally as defined by the International Traffic in Arms Regulation (ITAR) – 22 CFR 120.32.

5.3.2 Background Check ProceduresCA personnel 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;

Page - 16


1

2

12

345

6

78

910

11

1213141516

17

18

19202122

2324

252627282930

3132

3334353637383940

41

42

4344



Place of residence; Search of criminal records Check of references Check of credit/financial records

The period of investigation must cover at least the last five years for each area, excepting the residence check which must cover at least the last three years. Regardless of the date of award, the highest educational degree shall be verified.

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

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

The results of these checks shall not be released except as required in Sections 9.3 and 9.4.

If a formal clearance or other check is the basis for background check, the background refresh shall be in accordance with the corresponding formal clearance or other check. Otherwise, the background check shall be refreshed every ten years.

5.3.3 Training RequirementsAll personnel performing duties with respect to the operation of the CA or Sub0CA shall receive comprehensive training. Training shall be conducted in the following areas:

CA (or Sub-CA) security principles and mechanisms; All PKI software versions in use on the CA (or Sub-CA) system; All PKI duties they are expected to perform; Disaster recovery and business continuity procedures; and Stipulations of this policy.

5.3.4 Retraining Frequency and RequirementsAll individuals responsible for PKI roles shall be made aware of changes in the CA operation. Any significant change to the operations shall have a training (awareness) plan, and the execution of such plan shall be documented. Examples of such changes are CA software or hardware upgrade, changes in automated security systems, and relocation of equipment.

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

Page - 17


1

2

12345

678

910

11121314

15

161718

19

2021

2223242526

27

28293031

3233

34

35

36

3738

39

40

4142



5.3.8 Documentation Supplied to PersonnelDocumentation sufficient to define duties and procedures for each role shall be provided to the personnel filling that role.

5.4 Audit Logging ProceduresAudit log files shall be generated for all events relating to the security of the CA. Where possible, the security audit logs shall be automatically collected. Where this is not possible, a logbook, paper form, or other physical mechanism shall be used. All security audit logs, both electronic and non-electronic, shall be retained and made available during compliance audits. The security audit logs for each auditable event defined in this section shall be maintained in accordance with Section 5.5.2.

5.4.1 Types of Events RecordedAll security auditing capabilities of CA operating system and CA applications required by this CP shall be enabled during installation. At a minimum, each audit record shall include the following (either recorded automatically or manually for each auditable event):

The type of event; The date and time the event occurred; A success or failure indicator when executing the CA’s signing process; A success or failure indicator when performing certificate revocation; and The identity of the entity and/or operator that caused the event.

A message from any source requesting an action by the CA is an auditable event; the corresponding audit record must also include message date and time, source, destination, and contents.

The CA shall record the events identified in the list below. Where these events cannot be electronically logged, the CA shall supplement electronic audit logs with physical logs as necessary.

SECURITY AUDIT: o Any changes to the Audit parameters, e.g., audit frequency, type of event audited o Any attempt to delete or modify the Audit logs o Obtaining a third-party time-stamp

IDENTIFICATION AND AUTHENTICATION: o Successful and unsuccessful attempts to assume a role o The value of maximum authentication attempts is changed o Maximum authentication attempts unsuccessful authentication attempts occur during user login o An Administrator unlocks an account that has been locked as a result of unsuccessful

authentication attempts o An Administrator changes the type of authentication, e.g., from a password to biometric

LOCAL DATA ENTRY:o All security-relevant data that is entered in the system

REMOTE DATA ENTRY: o All security-relevant messages that are received by the system

DATA EXPORT AND OUTPUT: o All successful and unsuccessful requests for confidential and security-relevant information

KEY GENERATION: o Whenever the Component generates a key. (Not mandatory for single session or one-time use

symmetric keys) PRIVATE KEY LOAD AND STORAGE:

o The loading of Component private keys o All access to certificate subject private keys retained within the CA for key recovery purposes

TRUSTED PUBLIC KEY ENTRY, DELETION AND STORAGE: o All changes to the trusted public keys, including additions and deletions

SECRET KEY STORAGE:

Page - 18


1

2

1

23

4

56789

10

111213

1415161718

1920

2122

2324252627282930313233343536373839404142434445464748



o The manual entry of secret keys used for authentication PRIVATE AND SECRET KEY EXPORT:

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

o All certificate requests CERTIFICATE REVOCATION:

o All certificate revocation requests CERTIFICATE STATUS CHANGE APPROVAL:

o The approval or rejection of a certificate status change request CA CONFIGURATION:

o Any security-relevant changes to the configuration of the Component ACCOUNT ADMINISTRATION:

o Roles and users are added or deleted o The access control privileges of a user account or a role are modified

CERTIFICATE PROFILE MANAGEMENT: o All changes to the certificate profile

REVOCATION PROFILE MANAGEMENT: o All changes to the revocation profile

CERTIFICATE STATUS AUTHORITY MANAGEMENT: o All changes to the OCSP profile

MISCELLANEOUS: o Appointment of an individual to a trusted role o Designation of personnel for multiparty control o Installation of the operating system o Installation of the PKI Application o Installing hardware cryptographic modules o Removing hardware cryptographic modules o Destruction of cryptographic modules o System startup o Logon attempts to PKI applications o Receipt of hardware / software o Attempts to set passwords o Attempts to modify passwords o Backing up CA internal database o Restoring CA internal database o Restoration from backup of the internal CA databaseo File manipulation (e.g., creation, renaming, moving) o Posting of any material to a PKI repository o Access to CA internal database o All certificate compromise notification requests o Loading tokens with certificates o Shipment of tokens o Zeroizing and destroying tokens o Re-key of the Component o Configuration changes:

Hardware Software Operating system Patches Security profiles

PHYSICAL ACCESS / SITE SECURITY: o Personnel access to room housing Component o Access to the Component

Page - 19


1

2

123456789

1011121314151617181920212223242526272829303132333435363738394041424344454647484950515253



o Known or suspected violations of physical security ANOMALIES:

o Software error conditions o Software check integrity failures o Receipt of improper messages o Misrouted messages o Network attacks (suspected or confirmed) o Equipment failure o Electrical power outages o Uninterruptible power supply (UPS) failure o Obvious and significant network service or access failures o Violations of Certificate Policy o Violations of Certification Practice Statement o Resetting Operating System clock

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.

Such reviews involve verifying that the log has not been tampered with and then briefly inspecting all log entries, with a more thorough investigation of any alerts or irregularities in the logs. A statistically significant portion of the security audit data generated by the CA since the last review shall be examined. This amount will be described in the CPS.

All significant events shall be explained in an audit log summary. Actions taken as a result of these reviews shall be documented.

5.4.3 Retention Period for Audit LogAudit logs shall be retained on-site until reviewed, in addition to being archived as described in section 5.5. The individual who removes audit logs from the CA system shall be an official different from the individuals who, in combination, command the CA signature key.

5.4.4 Protection of Audit LogThe security audit data shall not be open for reading or modification by any human, or by any automated process, other than those that perform security audit processing. CA system configuration and procedures must be implemented together to ensure that only authorized people archive or delete security audit data. Procedures must be implemented to protect archived data from deletion or destruction before the end of the security audit data retention period (note that deletion requires modification access). Security audit data shall be moved to a safe, secure storage location separate from the location where the data was generated.

5.4.5 Audit Log Backup ProceduresAudit logs and audit summaries shall be backed up at least monthly. A copy of the audit log shall be sent off-site on a monthly basis.

5.4.6 Audit Collection System (Internal vs. External)The audit log collection system may or may not be external to the CA system. Automated audit processes shall be invoked at system or application startup, and cease only at system or application shutdown. Audit collection systems shall be configured such that security audit data is protected against loss (e.g., overwriting or overflow of automated log files). Should it become apparent that an automated audit system has failed, and the integrity of the system or confidentiality of the information protected by the system is at risk, operations shall be suspended until the problem has been remedied.

Page - 20


1

2

123456789

1011121314

15

1617

18192021

2223

24

252627

28

293031323334

35

3637

38

394041424344



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 AssessmentsThe CA shall perform routine self-assessments of security controls for vulnerabilities. Events in the audit process are logged, in part, to monitor system vulnerabilities. The assessments shall be performed following an examination of these monitored events. The assessments shall be based on real-time automated logging data and shall be performed at least on an annual basis as input into an entity’s annual Compliance Audit.

The audit data should be reviewed by the security auditor for events such as repeated failed actions, requests for privileged information, attempted access of system files, and unauthenticated responses. Security auditors should check for continuity of the audit data.

5.5 Records Archival

5.5.1 Types of Events ArchivedCA archive records shall be sufficiently detailed to determine the proper operation of the CA and the validity of any certificate (including those revoked or expired) issued by the CA. At a minimum, the following data shall be recorded for archive:

Certificate policy Certification practice statement Contractual obligations and other agreements concerning operations of the CA System and equipment configuration Modifications and updates to system or configuration Certificate requests All certificates issued and/or published Record of CA re-key Revocation requests Subscriber identity authentication data as per section 3.2.3. Documentation of receipt and acceptance of certificates (if applicable) Subscriber agreements Documentation of receipt of tokens All CRLs issued and/or published Other data or applications to verify archive contents Compliance Auditor reports Any changes to the Audit parameters, e.g. audit frequency, type of event audited Any attempt to delete or modify the Audit logs Whenever the CA generates a key (Not mandatory for single session or one-time use symmetric keys) The export of private and secret keys (keys used for a single session or message are excluded) The approval or rejection of a certificate status change request Appointment of an individual to a Trusted Role Destruction of cryptographic modules All certificate compromise notifications

5.5.2 Retention Period for ArchiveArchive records must be kept for a minimum of 10 years and 6 months.

5.5.3 Protection of ArchiveNo unauthorized user shall be permitted to write to, modify, or delete the archive. For the CA, archived records may be moved to another medium. The contents of the archive shall not be released except in accordance with sections 9.3 and 9.4. Records of individual transactions may be released upon request of any subscribers involved in the

Page - 21


1

2

1

23

4

5678

91011

12

13

141516

171819202122232425262728293031323334353637383940

41

42

43

444546



transaction or their legally recognized agents. Archive media shall be stored in a safe, secure storage facility separate from the CA. Archive media shall be stored in a safe, secure storage facility separate from the PKI components with physical and procedural security controls equivalent or better than those of the PKI.

5.5.4 Archive Backup ProceduresNo stipulation.

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 Archive Collection System (Internal or External)No stipulation.

5.5.7 Procedures to Obtain and Verify Archive InformationProcedures, detailing how to create, verify, package, transmit, and store the CA archive information, shall be published in the CPS.

5.6 Key ChangeoverTo minimize risk from compromise of a CA’s private signing key, that key may be changed often. From that time on, only the new key will be used to sign CA and subscriber certificates. If the old private key is used to sign OCSP responder certificates or CRLs that cover certificates signed with that key, the old key must be retained and protected.

The CA’s signing key shall have a validity period as described in section 6.3.2.

When a CA updates its private signature key and thus generates a new public key, the CA shall notify all CAs, Sub-CAs, and subscribers that rely on the CA’s certificate that it has been changed. When a CA that distributes self-signed certificates updates its private signature key, the CA shall generate key rollover certificates, where the new public key is signed by the old private key, and vice versa. This permits acceptance of newly issued certificates and CRLs without distribution of the new self-signed certificate to current users. Key rollover certificates are optional for CAs that do not distribute self-signed certificates.

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.

The Policy Authority shall be notified if any CAs operating under this policy experience the following: suspected or detected compromise of the CA systems; suspected or detected compromise of a certificate status server (CSS) if (1) the CSS certificate has a

lifetime of more than 72 hours and (2) the CSS certificate cannot be revoked (e.g., an OCSP responder certificate with the id-pkix-ocsp-nocheck extension);

physical or electronic penetration of CA systems; successful denial of service attacks on CA components; or any incident preventing the CA from issuing a CRL within 48 hours of the issuance of the previous CRL.

The Policy Authority 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.

Page - 22


1

2

123

4

5

6

78

9

10

11

1213

14

15161718

19

202122232425

26

27

28

2930313233343536

37

3839



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 subscribers’’ interests as Relying Parties.

If the ability to revoke certificates is inoperative or damaged, the CA shall reestablish revocation capabilities as quickly as possible in accordance with procedures set forth in the respective CPS. If the CA’s revocation capability cannot be established in a reasonable time-frame, the CA shall determine whether to request revocation of its certificate(s). If the CA is a Root CA, the CA shall determine whether to notify all subscribers that use the CA as a trust anchor to delete the trust anchor.

5.7.3 Entity (CA) Private Key Compromise ProceduresIf a CA’s signature keys are compromised, lost, or suspected of compromise:

All cross certified CAs shall be securely notified at the earliest feasible time (so that entities may issue CRLs revoking any cross-certificates issued to the CA);

The CA must generate new keys in accordance with section 6.1.1.1. If the CA distributed the private key in a Trusted Certificate, the CA shall perform the following

operations:o Generate a new Trusted Certificate.o Securely distribute the new Trusted Certificate as specified in section 6.1.4.o Initiate procedures to notify subscribers of the compromise.

Subscriber certificates may be renewed automatically by the CA under the new key pair (see section 4.6), or the CA may require subscribers to repeat the initial certificate application process.

5.7.4 Business Continuity Capabilities after a DisasterIn the case of a disaster whereby the CA installation is physically damaged and all copies of the CA signature key are destroyed as a result, the CA shall request revocation of its certificates. Further, the CA shall re-establish operations by following the procedures for CA key loss or compromise detailed in Section 5.7.3 above.

Relying parties may decide of their own volition whether to continue to use certificates signed with the destroyed private key pending reestablishment of CA operation with new certificates.

5.8 CA TerminationWhen a CA operating under this policy terminates operations before all certificates have expired, the CA signing keys shall be surrendered to the Policy Authority.

Prior to CA termination, the CA shall provide archived data as specified in the CPS. As soon as possible, the CA will advise all other organizations to which it has issued certificates of its termination, using an agreed-upon method of communication specified in the CPS.

Page - 23


1

2

1

23456789

10111213141516

17

181920212223242526

2728

29

303132

3334

35

3637

383940

41



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

6.1.1 Key Pair GenerationKey pair generation shall be performed using FIPS 140 approved cryptographic modules and processes that provide the required cryptographic strength of the generated keys and prevent the loss, disclosure, modification, or unauthorized use of private keys. Any pseudo-random numbers use and parameters for key generation material shall be generated by a FIPS-approved method.

6.1.1.1 CA Key Pair GenerationCryptographic keying material used by CAs to sign certificates, CRLs, or status information shall be generated in FIPS 140 approved cryptographic modules that shall be at least FIPS 140 Level 3. Key pairs for Sub-CAs requesting a medium-assurance hardware Certificate under this CP must be generated in a hardware cryptographic module rated at least FIPS 140 Level 2.

CA keys shall be generated in a Key Generation Ceremony using multi-person control for CA key pair generation, as specified in CP section 6.2.2.

CA key pair generation must create a verifiable audit trail that the security requirements for procedures were followed. The documentation of the procedure must be detailed enough to show that appropriate role separation was used. An independent third party shall validate the execution of the key generation procedures either by witnessing the key generation or by examining the signed and documented record of the key generation.

6.1.1.2 Subscriber Key Pair GenerationSubscriber key pair generation may be performed by the subscriber, CA, or Sub-CA. If the CA or Sub-CA generates subscriber key pairs, the requirements for key pair delivery specified in section 6.1.2 must also be met.

Key pairs for subscribers requesting a medium-assurance hardware certificate must be generated in a hardware cryptographic module rated at least FIPS 140 Level 2.

NOTE: The ATA Specification states subscriber private keys will only be generated by the subscriber and never by the CA. The Federal Bridge PKI CP allows end user key generation by the CA/RA. So this next section aligns with the Federal Bridge policy (more flexible) but can be removed to follow the ATA Specification if desired.

6.1.2 Private Key Delivery to SubscriberSubscriber key pair generation may be performed by the Subscriber. In this case, the private key delivery to a Subscriber is unnecessary.

When CAs generate key pairs on behalf of the Subscriber, the private keys must be delivered securely to the Subscriber and the following requirements must be met:

The CA shall not retain any copy of the key after delivery of the private key to the subscriber. CAs shall use Trustworthy Systems to deliver private keys to Subscribers and shall secure such delivery

through the use of a PKCS#8 package or, at the CAs sole discretion, any other comparably equivalent means (e.g., PKCS#12 package) in order to prevent the loss, disclosure, modification, or unauthorized use of such private keys.

Where key pairs are pre-generated on hardware cryptographic modules, the entities distributing such modules shall use best efforts to provide physical security of the modules to prevent the loss, disclosure, modification, or unauthorized use of the private keys.

The subscriber shall acknowledge receipt of the private key(s).

Page - 24


1

2

1

2

3

4567

8

9101112

1314

15161718

19

202122

2324

252627

28

2930

3132

333435363738394041



Delivery shall be accomplished in a way that ensures that the certificates and associated private keys are provided to the correct subscribers.

o For hardware cryptographic modules, accountability for the location and state of the module must be maintained until the subscriber 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.

6.1.3 Public Key Delivery to Certificate IssuerWhen a public key is transferred to the issuing CA to be certified, it shall be delivered through a mechanism validating the identity of the Subscriber and ensuring that the public key has not been altered during transit and that the Certificate Applicant possesses the private key corresponding to the transferred public key. The Certificate Applicant shall deliver the public key in a PKCS#10 Certificate Signing Request package or an equivalent method ensuring that the public key has not been altered during transit; and the Certificate Applicant possesses the private key corresponding to the transferred public key.

6.1.4 CA Public Key Delivery to Relying PartiesCA public key certificates shall be delivered to relying parties in a secure fashion to preclude substitution attacks. Acceptable methods for certificate delivery are:

Loading the CA certificate onto tokens delivered to relying parties via secure mechanisms. The CA Certificate is delivered as part of a subscriber’s certificate request. Secure distribution of CA certificates through secure out-of-band mechanisms. Downloading the CA certificates from trusted web sites (CA or PKI-PA web site).

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

Elliptic Curve Cryptography

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

6.1.6 Public Key Parameters Generation and Quality CheckingElliptic Curve Cryptography (ECC) public key parameters shall be selected from the set specified in CP section 7.1.3.

6.1.7 Key Usage Purposes (as per X.509 v3 Key Usage Field)The use of a specific key is constrained by the key usage extension in the X.509 certificate. All certificates shall include a critical key usage extension.

Page - 25


1

2

1234567

8

91011121314

15

1617

18192021

22

2324

25

26

27

28

2930

31

3233

34



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

Public keys that are bound into subscriber certificates shall be used only for signing or encrypting, but not both. Table 3 shows the specific keyUsage extension settings for AeroMACS Subscriber signature certificates that contain ECC public keys and specifies that all Subscriber certificates that contain ECC public keys:

Shall include a keyUsage extension Shall set the criticality of the keyUsage extension to TRUE Shall assert the digitalSignature bit Shall assert the nonRepudiation bit

Table 3: keyUsage Extension for all Subscriber Signature Certificates


keyUsage BIT STRING TRUE { id-ce 15 } Included in all Subscriber certificates

digitalSignature (0) 1 Set

nonRepudiation (1) 1 Set

Page - 26


1

2

123

456

7

8

9

101112

13141516

17





keyAgreement (4) 0 Not Set

keyCertSign (5) 0 Not Set

cRLSign (6) 0 Not Set



Table 4 shows the specific keyUsage extension settings for AeroMACS key management certificates that contain ECC public keys and specifies that all key management certificates that contain ECC public keys:

Shall include a keyUsage extension Shall set the criticality of the keyUsage extension to TRUE Shall assert the keyAgreement bit

Table 4: keyUsage Extension for all Key Management Certificates


keyUsage BIT STRING TRUE { id-ce 15 } Included in all Subscriber certificates

digitalSignature (0) 0 Not Set




keyAgreement (4) 1 Set





Table 4 shows the specific keyUsage extension settings for AeroMACS Server certificates that contain ECC public keys and specifies that all Server certificates that contain ECC public keys:

Shall include a keyUsage extension Shall set the criticality of the keyUsage extension to TRUE

Page - 27


1

2

1

23

456

7

8

910

1112



Shall assert the digitalSignature bit Shall assert the keyAgreement bit

Table 5: keyUsage Extension for all Server Certificates


keyUsage BIT STRING TRUE { id-ce 15 } Included in all Server certificates

digitalSignature (0) 1 Set




keyAgreement (4) 1 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].

Root CAs shall perform all CA cryptographic operations on cryptographic modules approved at a minimum of FIPS 140-2 level 3 or higher.

Sub-CAs shall use a FIPS 140-2 Level 2 or higher approved hardware cryptographic module. Subscribers with low- or medium-assurance software certificates shall use a FIPS 140-2 Level 1 or higher

approved cryptographic module for their cryptographic operations.

All other entities, including Subscribers with medium-assurance hardware certificates shall use a FIPS 140-2 Level 2 or higher approved cryptographic module for all private key operations.

Servers should use a FIPS 140-2 Level 1 or higher approved cryptographic module for their cryptographic operations.

6.2.2 Private Key (n out of m) Multi-Person ControlMulti-person control is enforced to protect the activation data needed to activate CA private keys so that a single person shall not be permitted to activate or access any cryptographic module that contains the complete CA private signing key.

Page - 28


1

2

12

3

45

6

7

89

10

11

1213141516

1718

1920

21

222324



CA signature keys may be backed up only under multi-person control. Access to CA signing keys backed up for disaster recovery shall be under multi-person control. The names of the parties used for multi-person control shall be maintained on a list that shall be made available for inspection during compliance audits.

CAs may use “Secret Sharing” to split the private key or activation data needed to operate the private key into separate parts called “Secret Shares” held by individuals called “Shareholders.” Some threshold number of Secret Shares (m) out of the total number of Secret Shares (n) shall be required to operate the private key. The minimum threshold number of shares (m) needed to sign a CA certificate shall be 3. The total number of shares (n) used shall be greater than the minimum threshold number of shares (m).

CAs may also use Secret Sharing to protect the activation data needed to activate private keys located at their respective disaster recovery sites. The minimum threshold number of shares (m) needed to sign a CA certificate at a disaster recovery site shall be 3. The total number of shares (n) used shall be greater than the minimum threshold number of shares (m).

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

If the CA retains subscriber private encryption keys for business continuity purposes, the CA shall escrow such subscriber private encryption keys to protect them from unauthorized modification or disclosure through physical and cryptographic means.

6.2.4 Private Key BackupCAs shall back up their private keys, under the same multi-person control as the original signature key. The backups allow the CA to be able to recover from disasters and equipment malfunction. At least one copy of the private signature key shall be stored off-site. Private keys that are backed up shall be protected from unauthorized modification or disclosure through physical or cryptographic means. Backups, including all activation data needed to activate the cryptographic module containing the private key, shall be protected with a level of physical and cryptographic protection equal to or exceeding that for cryptographic modules within the CA site, such as at a disaster recovery site or at another secure off-site facility, such as a bank safe. All copies of the CA private signature key shall be accounted for and protected in the same manner as the original.

Device private keys may be backed up or copied, but must be held under the control of the Subscriber or other authorized administrator. Backed up device private keys shall not be stored in plaintext form and storage must ensure security controls consistent with the security specifications the device is compliant with. Subscribers may have the option of using enhanced private key protection mechanisms available today including the use of smart cards, biometric access devices, and other hardware cryptographic modules to store private keys.

6.2.5 Private Key ArchivalCA private signature keys and subscriber private signatures keys shall not be archived. If the CA retains subscriber private encryption keys for business continuity purposes, the CA shall archive such subscriber private keys, in accordance with CP section 5.5.

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.

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.

Page - 29


1

2

123

45678

9101112

13

14

151617

18

1920212223242526

2728293031

32

333435

36373839

40

414243



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.

Processing Centers generating CA or Sub-CA private keys on one hardware cryptographic module and transferring them into another shall securely transfer such private keys into the second cryptographic module to the extent necessary to prevent loss, theft, modification, unauthorized disclosure, or unauthorized use of such private keys. Such transfers shall be limited to making backup copies of the private keys on tokens.

CAs pre-generating private keys and transferring them into a hardware cryptographic module, for example transferring generated end-user Subscriber private keys into a smart card, shall securely transfer such private keys into the module to the extent necessary to prevent loss, theft, modification, unauthorized disclosure, or unauthorized use of such private keys.

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

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

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.

Subscriber Private Keys

The AeroMACS standards for protecting activation data for Subscribers’ private keys shall be in accordance with the specific obligations appearing in the applicable agreement executed between AeroMACS and the Subscriber.

For device certificates, the device may be configured to activate its private key, provided that appropriate physical and logical access controls are implemented for the device. The strength of the security controls shall be commensurate with the level of threat in the device’s environment, and shall protect the device’s hardware, software, private keys and its activation data from compromise.

Page - 30


1

2

123

4

56

789

10

11121314

15

16

17

1819

20

21

222324252627

28

293031

32

333435

36

3738

39404142



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 an online CA is taken offline, the CA shall remove the token containing such CA’s private key from the reader in order to deactivate it.

When deactivated, private keys shall be kept in encrypted form only.

6.2.10 Method of Destroying Private KeyPrivate keys shall be destroyed in a way that prevents their theft, disclosure, or unauthorized use.

Upon termination of the operations of a CA or Sub-CA, individuals in trusted roles shall decommission the CA/Sub-CA private signature keys by deleting it using functionality of the token containing such CA/Sub-CA’s private key so as to prevent its recovery following deletion, or the loss, theft, modification, disclosure, or unauthorized use of such private key. CA/Sub-CA private keys shall be destroyed in a manner that reasonably ensures that there are no residuals remains of the key that could lead to the reconstruction of the key.

For Root CAs, PKI-PA security personnel shall witness this process.

Subscribers may destroy their private signature keys when they are no longer needed or when the certificates to which they correspond expire or are revoked. Physical destruction of hardware is not required.

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.

6.3.2 Certificate Operational Periods and Key Pair Usage PeriodsThe certificate validity period (i.e., certificate and key pair usage period) shall be set to the time limits set forth as follows:

Root CA certificates shall have a validity period of up to 30 years Sub-CA certificates shall have a validity period of up to 20 years Subscriber certificates shall have a validity period of up to 10 years (e.g., 1 to 2 year server certs, 3 year

aircraft certs, up to 10 years for long lived certs)

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.

Page - 31


1

2

1

234

56

789

1011

12

13

14

1516171819

20

2122

23

24

25

26

27

28

2930

31323334

3536

37

Oscar Marcia, 11/23/15,

Example usage periods. The range in usage periods allows for several types of certificates such as server and device certificate types with different usage periods.



6.4 Activation data

6.4.1 Activation Data Generation and InstallationCAs shall generate and install activation data for their private keys and shall use methods that protect the activation data to the extent necessary to prevent the loss, theft, modification, disclosure, or unauthorized use of such activation data.

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.

6.4.2 Activation Data ProtectionCAs shall protect the activation data for their private keys using methods that protect against the loss, theft, modification, unauthorized disclosure, or unauthorized use of such private keys.

CAs shall use multi-party control in accordance with CP section 6.2.2. CAs shall provide the procedures and means to enable Shareholders to take the precautions necessary to prevent the loss, theft, modification, disclosure, or unauthorized use of the Secret Shares that they possess. Shareholders shall not:

Copy, disclose, or make the Secret Share available to a third party, or make any unauthorized use of it whatsoever; or

Disclose their or any other person’s status as a Shareholder to any third party.

The Secret Shares and any information disclosed to the Shareholder in connection with their duties as a Shareholder shall constitute Confidential/Private Information.

CAs shall include in their disaster recovery plans provisions for making Secret Shares available at a disaster recovery site after a disaster (Note, the important aspect of disaster recovery vis-à-vis shares is that a process exists for making the necessary number of shares available, even if the requisite shareholders are not available.). CAs shall maintain an audit trail of Secret Shares, and Shareholders shall participate in the maintenance of an audit trail.

6.4.3 Other Aspects of Activation DataActivation Data Transmission

To the extent activation data for private keys are transmitted, Activation Data Participants shall protect the transmission using methods that protect against the loss, theft, modification, unauthorized disclosure, or unauthorized use of such private keys. To the extent desktop computer or network logon user name/password combination is used as activation data for an end-user Subscriber, the passwords transferred across a network shall be protected against access by unauthorized users.

Activation Data Destruction

Activation data for CA private keys shall be decommissioned using methods that protect against the loss, theft, modification, unauthorized disclosure, or unauthorized use of the private keys protected by such activation data. After the record retention periods in CP section 5.5.2 lapses, CAs shall decommission activation data by overwriting and/or physical destruction.

6.5 Computer security controls

6.5.1 Specific Computer Security Technical RequirementsCAs shall ensure that the systems maintaining CA software and data files are Trustworthy Systems secure from unauthorized access, which can be demonstrated by compliance with audit criteria applicable under CP section 5.4.1. In addition, CAs shall limit access to production servers to those individuals with a valid business reason for access. General application users shall not have accounts on the production servers.

Page - 32


1

2

1

2

345

678

9

1011

121314

151617

1819

20212223

24

25

2627282930

31

32333435

36

37

38394041



CAs shall have production networks logically separated from other components. This separation prevents network access except through defined application processes. CAs shall use firewalls to protect the production network from internal and external intrusion and limit the nature and source of network activities that may access production systems.

To the extent that passwords are used, CAs shall require the use of passwords with a minimum character length and a combination of alphanumeric and special characters, and shall require that passwords be changed on a periodic basis and whenever necessary. Direct access to a CA’s database maintaining the CA’s repository shall be limited to Trusted Persons having a valid business reason for such access.

Computer security controls are required to ensure CA operations are performed as specified in this policy. The following computer security functions may be provided by the operating system, or through a combination of operating system, software, and physical safeguards:

Require authenticated logins Provide discretionary access control Provide a security audit capability Enforce access control for CA services and PKI roles Enforce separation of duties for PKI roles Require identification and authentication of PKI roles and associated identities Prohibit object reuse or require separation for CA random access memory Require use of cryptography for session communication and database security Archive CA history and audit data Require self-test security-related CA services Require a trusted path for identification of PKI roles and associated identities Require a recovery mechanism for keys and the CA system Enforce domain integrity boundaries for security-critical processes.

For other CAs operating under this policy, the computer security functions listed below are required. These functions may be provided by the operating system, or through a combination of operating system, software, and physical safeguards. The CA and its ancillary parts shall include the following functionality:

Authenticate the identity of users before permitting access to the system or applications; Manage privileges of users to limit users to their assigned roles; Generate and archive audit records for all transactions; (see CP section 5.4) Enforce domain integrity boundaries for security critical processes; and Support recovery from key or system failure.

For certificate status servers operating under this policy, the computer security functions listed below are required:

Authenticate the identity of users before permitting access to the system or applications; Manage privileges of users to limit users to their assigned roles; Enforce domain integrity boundaries for security critical processes; and Support recovery from key or system failure.

For remote workstations used to administer the CAs, the computer security functions listed below are required:

Authenticate the identity of users before permitting access to the system or applications; Manage privileges of users to limit users to their assigned roles; Generate and archive audit records for all transactions; (see CP section 5.4) Enforce domain integrity boundaries for security critical processes; and Support recovery from key or system failure.

All communications between any PKI trusted role and the CA shall be authenticated and protected from modification.

6.5.2 Computer Security RatingNo Stipulation.

Page - 33


1

2

1234

5678

91011

12131415161718192021222324

252627

2829303132

33

34353637

38

3940414243

4445

46

47



6.6 Life Cycle Technical Controls

6.6.1 System Development ControlsThe system development controls for the CA and Sub-CA are as follows:

The CA shall use software that has been designed and developed under a formal, documented development methodology.

Hardware and software procured to operate the CA shall be purchased in a fashion to reduce the likelihood that any particular component was tampered with (e.g., by ensuring the vendor cannot identify the PKI component that will be installed on a particular device).

Hardware and software developed specifically for the CA shall be developed in a controlled environment, and the development process shall be defined and documented. This requirement does not apply to commercial off-the-shelf hardware or software.

The CA hardware and software shall be dedicated to performing one task: the CA. There shall be no other applications, hardware devices, network connections, or component software installed that are not parts of the CA operation. Where the CA operation supports multiple CAs, the hardware platform may support multiple CAs.

Proper care shall be taken to prevent malicious software from being loaded onto the CA equipment. All applications required to perform the operation of the CA shall be obtained from documented sources.

Hardware and software updates shall be purchased or developed in the same manner as original equipment, and shall be installed by trusted and trained personnel in a defined manner.

6.6.2 Security Management ControlsThe configuration of the CA system, in addition to any modifications and upgrades, shall be documented and controlled. There shall be a mechanism for detecting unauthorized modification to the software or configuration. The CA software, when first loaded, shall be verified as being that supplied from the vendor, with no modifications, and be the version intended for use.

6.6.3 Life Cycle Security ControlsNo Stipulation.

6.7 Network Security ControlsA network guard, firewall, or filtering router must protect network access to CA equipment. The network guard, firewall, or filtering router shall limit services allowed to and from the CA equipment to those required to perform CA functions.

Protection of CA equipment shall be provided against known network attacks. All unused network ports and services shall be turned off. Any network software present on the CA equipment shall be necessary to the functioning of the CA application.

Any boundary control devices used to protect the network on which PKI equipment is hosted shall deny all but the necessary services to the PKI equipment.

Repositories, certificate status servers, and remote workstations used to administer the CAs shall employ appropriate network security controls. Networking equipment shall turn off unused network ports and services. Any network software present shall be necessary to the functioning of the equipment.

The CA shall establish connection with a remote workstation used to administer the CA only after successful authentication of the remote workstation at a level of assurance commensurate with that of the CA.

6.8 Time-StampingCertificates, CRLs, and other revocation database entries shall contain time and date information. Such time information need not be cryptographic-based. Asserted times shall be accurate to within three minutes. Electronic or manual procedures may be used to maintain system time. Clock adjustments are auditable events (see CP section 5.4.1).

Page - 34


1

2

1

2

3456789

10111213141516171819

20

21222324

25

26

27

282930

313233

3435

363738

3940

41

42434445



Page - 35


1

2

1



7. CERTIFICATE, CRL, AND OCSP PROFILES5.

6.

7.

8.

9.

10.

11.

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 Error: Reference source not found).

Table 6: 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 - 36


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 7 shows the certificate extensions for all AeroMACS Root CA certificates.

Table 7: Root CA Certificate Standard Extensions

Field Referenced Standard

Section Requirement or Recommendation

subjectKeyIdentifier [RFC 5280] 4.2.1.2 See Error: Reference source not found.

keyUsage [RFC 5280] 4.2.1.3 See CP section 6.1.7.

certificatePolicies [RFC 5280] 4.2.1.4 (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 Error: Reference source not found.

Table 8 shows the certificate extensions for all AeroMACS sub-CA certificates.

Table 8: Sub-CA Certificate Standard Extensions



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

subjectKeyIdentifier [RFC 5280] 4.2.1.2 See Error: Reference source not found.


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

Page - 37


1

2

1

2

34

5

678

9

10

11

12

Susan Joseph, 11/19/15,

Do we want this to be an optional extension? Should we reference the ATA Spec for the certificate policies?



found.

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

basicConstraints [RFC 5280] 4.2.1.9 See Error: Reference source not found.

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 9 shows the certificate extensions for all AeroMACS subscriber certificates.

Table 9: Subscriber Certificate Standard Extensions



authorityKeyIdentifier [RFC 5280] 4.2.1.1 Shall be included in Subscriber 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 Error: Reference source not found for server certificates.See Error: Reference source not found for client certificates.

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 10 shows the certificate extensions for all AeroMACS OCSP server certificates.

Table 10: OCSP Certificate Standard Extensions



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

Page - 38


1

2

1

2

3

4

5



keyUsage [RFC 5280] 4.2.1.3 Only the digitalSignature bit shall be set. Criticality shall be set to TRUE.

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

subjectAltName [RFC 5280] 4.2.1.6 Shall be set to either the DNS name or the IP address of the subject.Criticality shall be set to FALSE.

Subject Key Identifier ExtensionTable 11 shows the subjectKeyIdentifier extension settings for AeroMACS CA certificates and specifies that all AeroMACS Root and sub-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 11: 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.

Subscriber Certificates shall not include the subjectKeyIdentifier extension.

Basic Constraints ExtensionTable 12 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 12: 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 13 shows the basicConstraints extension settings for AeroMACS sub-CA certificates and specifies that all AeroMACS sub-CA certificates:

Shall include the basicConstraints extension Shall set the criticality of the basicConstraints extension to TRUE

Page - 39


1

2

1

2

34

567

8

9

10

1112

131415

16

17

1819

2021



Shall set the cA field of the basicConstraints extension set to TRUE Shall set the pathLenConstraint field of the basicConstraints to “0” (zero)

Table 13: basicConstraints Extension for AeroMACS Sub-CA Certificates


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

cA BOOLEAN TRUE Set

pathLenConstraint INTEGER 0

Subscriber 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 14 shows the extKeyUsage extension settings for AeroMACS Subscriber server certificates (e.g., VTN certificate) 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

Table 14: extKeyUsage Exstension for AeroMACS Server Certificates


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

keyPurposeID OID 1.3.6.1.5.5.7.3.1 id-kp-serverAuth

Table 15 shows the extKeyUsage extension settings for AeroMACS Subscriber client certificates and specifies that all AeroMACS client certificates:

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

Table 15: extKeyUsage Exstension for AeroMACS Client Certificates


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

keyPurposeID OID 1.3.6.1.5.5.7.3.2 id-kp-clientAuth

Page - 40


1

2

12

3

4

5678

9

10

1112

131415

16

1718

192021

22



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

Table 16: Signature OIDS for Certificates


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

Table 17: subjectPublicKeyInfo for Certificate


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 ansip384r1

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

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

Page - 41


1

2

1

23

4

56

7

8

9

10

1112

13



CA’s service provider’s place of business is located.

organizationName (O=) <Organization> Shall contain the issuer organization name.

organizationalUnitName (OU=) Root CA<Id#> Shall contain a name that accurately identifies the Issuing CA. The “<Id#>” indicates the ID number of the Root and is populated when the Root CA certificate is issued. For Example, “Root CA001.”

commonName (CN=) <Name> Root CA Shall contain the common name that identifies the AeroMACS Root CA. (e.g. CompanyA Root CA)

Sub-CAs

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

Table 19: Sub-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> Sub-CA

Shall contain a name that accurately identifies the CA. (e.g. CompanyA Sub CA)

Subscriber Certificates

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

Page - 42


1

2

1

2

3

4

5

6

7

8

9

10

11

1213



Table 20: Subscriber Certificate subject Fields


countryName (C=) <Country Name>

Shall be the two-letter ISO 3166-1 country code for the country in which the Subscriber’s place of business is located.

organizationName (O=) <Organization> Shall contain the Subscriber organization name (or abbreviation thereof), trademark, or other meaningful identifier.

organizationalUnitName (OU=) <Addition Information>

(Optional) When included, one or more OUs shall contain additional identifying information.

commonName (CN=) <Device Id> Shall contain the device MAC Address that is bound into the certificate that will bind the certificate’s public key to the device.

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

7.1.6 Certificate Policy Object IdentifierThe certificate policy object identifier for this CP is defined in the ATA Specification section 1.2.2.

Table 21 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 21: certificatePolicies Extension for AeroMACS Certificates


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

policyInformation

policyIdentifier OID <Certificate policy OID>

See ATA Specification section 1.2.2.

policyQualifiers SEQUENCE

Not Set

Page - 43


1

2

1

2

3

4

5

6

78

910

11

12

13



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

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

7.1.9 Processing Semantics for the Critical Certificate Policies ExtensionCertificates issued under this policy shall not contain a critical certificate policies extension.

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

Table 22: 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].

Page - 44


1

2

1

2

3

4

5

6

7

8

9

10

11

1213



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

7.3 OCSP ProfileOCSP (Online Certificate Status Protocol) is a way to obtain timely information about the revocation status of a particular certificate. OCSP Responses must conform to [RFC5019] and must either be:

Signed by the CA that issued the Certificates whose revocation status is being checked, or Signed by an OCSP Responder whose Certificate is signed by the CA that issued the Certificate whose

revocation status is being checked. Such OCSP Responder signing Certificate shall contain the extension id-pkix-ocsp-nocheck as defined by [RFC2560].

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


1

2

1

2

3

45

6789

10

11

12

13

14



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 AssessmentCAs and Sub-CAs operating under this policy shall be subject to a periodic compliance audit at least once per year.

8.2 Identity/Qualifications of AssessorThe compliance auditor must demonstrate competence in the field of compliance audits, and must be thoroughly familiar with the CA’s CPS and this CP. The compliance auditor must perform such compliance audits as a regular ongoing business activity. In addition to the previous requirements, the auditor must be a certified information system auditor (CISA) or IT security specialist, and a PKI subject matter specialist who can offer input regarding acceptable risks, mitigation strategies, and industry best practices.

8.3 Assessor's Relationship to Assessed EntityThe compliance auditor shall either represent a firm, which is independent from the entity being audited, or it shall be sufficiently organizationally separated from that entity to provide an unbiased, independent evaluation. An example of the latter situation may be an organizational audit department provided it can demonstrate organizational separation and independence. To further insure independence and objectivity, the compliance auditor may not have served the entity in develo0ping or maintaining the entity’s PKI Facility, associated IT and network systems, or certificate practices statement. The Policy Authority shall determine whether a compliance auditor meets this requirement.

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 Policy Authority, and any additional MOAs between the PKI and other Entities. The compliance audit must include an assessment of the applicable CPS against the applicable CP, to determine that the CPS adequately addresses and implements the requirements of the CP.

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 Policy Authority may decide to temporarily halt operation of the CA or Sub-CA, to revoke a certificate issued to the CA or Sub-CA, or take other actions it deems appropriate. The Policy Authority will develop procedures for making and implementing such determinations. In accordance with section 8.1, a compliance audit may be required to confirm the implementation and effectiveness of the remedy.

Page - 46


1

2

1

23

4

5

6

7

89

101112

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 Policy Authority as set forth in Section 8.1. This package shall be prepared in accordance with the Policy Authority and must include an assertion from the Entity PKI PMA that all PKI components have been audited – including any components that may be separately managed and operated. The package shall identify the versions of this CP and CPS used in the assessment. Additionally, where necessary, the results shall be communicated as set forth in Section 8.5 above.

Page - 47


1

2

1

234567



9. Other Business and Legal Matters9.1 Fees

9.2 Financial Responsibility

9.3 Confidentiality of business information

9.4 Privacy of Personal Information

9.5 Intellectual Property Rights

9.6 Representations and Warranties

9.7 Disclaimers of warranties

9.8 Limitations of liability

9.9 Indemnities

9.10 Term and termination

9.11 Individual notices and communications with participants

9.12 Amendments

9.13 Dispute Resolution Provisions

9.14 Governing Law

9.15 Compliance with Applicable Law

9.16 Miscellaneous provisions

9.17 Other Provisions

Page - 48


1

2

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19



10. ReferencesRFC 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 - 49


1

2

1

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








11.GlossaryThis specification uses the following terms:

Audit Requirements Guide A document that sets forth the security and audit requirements and practices for AeroMACS CAs.

Certificate A message that, at least, states a name or identifies the CA, identifies the Subscriber, contains the Subscriber’s public key, identifies the Certificate’s Validity Period, contains a Certificate serial number, and is digitally signed by the CA that issued the certificate.

Certificate Applicant An individual or organization that requests the issuance of a Certificate by a CA.

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

Certificate Chain An ordered list of Certificates containing a Subscriber Certificate and one or more CA Certificates, which terminates in a root Certificate.

Control Objectives Criteria that an entity must meet in order to satisfy a Compliance Audit.

Certificate Policy (CP) The principal statement of policy governing the AeroMACS PKI.Certificate Revocation List (CRL)

A periodically (or exigently) issued list, digitally signed by a CA, of identified Certificates that have been revoked prior to their expiration dates. The list generally indicates the CRL issuer’s name, the date of issue, the date of the next scheduled CRL issue, the revoked Certificates’ serial numbers, and the specific times and reasons for revocation.

Certificate Signing Request (CSR)

A message conveying a request to have a Certificate issued.

Certification Authority (CA) An entity authorized to issue, manage, revoke, and renew Certificates in the AeroMACS PKI.

Certification Practice Statement (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 of, or loss of control over, sensitive information has occurred. With respect to private keys, a Compromise is a loss, theft, disclosure, modification, unauthorized use, or other compromise of the security of such private key.

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

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

Elliptic Curve Cryptography A public-key cryptography system based on the algebraic structure of

Page - 50


1

2

1

2



(ECC) elliptic curves over finite fields.Intellectual Property Rights Rights under one or more of the following: copyright, patent, trade

secret, trademark, or any other intellectual property rights.Key Generation Ceremony A procedure whereby a CA’s key pair is generated, its private key is

backed up, and/or its public key is certified.PKI Participant An individual or organization that is one or more of the following

within the AeroMACS PKI: AeroMACS, a CA, a Subscriber, or a Relying Party.

PKCS #10 Public-Key Cryptography Standard #10, developed by RSA Security Inc., which defines a structure for a Certificate Signing Request.

PKCS #8 Public-Key Cryptography Standard #8, developed by RSA Security Inc., which defines a secure means for the transfer of private keys.

Processing Center A secure facility created by an appropriate organization (e.g., Symantec) that houses, among other things, the cryptographic modules used for the issuance of Certificates.

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

Relying Party An individual or organization that acts in reliance on a certificate and/or a digital signature.

Secret Share A portion of the activation data needed to operate the private key, held by individuals called “Shareholders.” Some threshold number of Secret Shares (n) out of the total number of Secret Shares (m) shall be required to operate the private key.

Secret Sharing The practice of splitting a CA private key or the activation data to operate a CA private key in order to enforce multi-person control over CA private key operations.

Security Repository AeroMACS database of relevant security information accessible 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 Subscriber, or a Relying Party.

Subject The holder of a private key corresponding to a public key. The term “Subject” can, in the case of a Device Certificate, refer to the Subscriber requesting the device certificate.

Subscriber The entity who requests a Certificate (e.g., a manufacturer). The Subscriber is capable of using, and is authorized to use, the private key that corresponds to the public key listed in the Certificate.

Subscriber Agreement An agreement used by a CA setting forth the terms and conditions under which an individual or organization acts as a Subscriber.

Superior Entity An entity above a certain entity within the AeroMACS PKI.Trusted Person An employee, contractor, or consultant of an entity within the

AeroMACS PKI responsible for managing infrastructural trustworthiness of the entity, its products, its services, its facilities, and/or its practices.

Trusted Position The positions within the AeroMACS PKI entity that must be held by a

Page - 51


1

2



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


1

2



12. Abbreviations and AcronymsThis specification uses the following abbreviations:CA Certification Authority

CP Certificate Policy

CPS Certification Practice Statement

CRA Certificate Requesting Account

CRL Certificate Revocation List

CSR Certificate Signing Request

DR Demand Response

DRAS Demand Response Automation Server

ECC Elliptic Curve Cryptography

FIPS Federal Information Processing Standards

id-at X.500 attribute types. (OID value: 2.5.4)id-ce Object Identifier for Version 3 certificate extensions. (OID value: 2.5.29)IETF Internet Engineering Task ForceISO Independent System OperatorsLSVA Logical Security Vulnerability AssessmentMFG ManufacturerOID Object IdentifierPA Policy Authority

PKCS Public-Key Cryptography Standard

PKI Public Key Infrastructure

RFC Request for comment

RSA Rivest, Shamir, Adelman

SAS Statement on Auditing Standards (promulgated by the American Institute of Certified Public Accountants)

Page - 53


1

2

1

2

3

aeromacs pki certificate policy wg-s 8/wp3.1... · web view12/07/2015 12:14:00 title aeromacs pki...

Documents