AeroMACS PKI Certificate Policy



24515422311400026413527661523002286001716405WiMAX Forum? Network ArchitectureAeroMACS PKI Certificate PolicyDRAFT-T32-006-R010v01-HDraft Specification DOCPROPERTY Manager \* MERGEFORMAT (2016-02-19)00WiMAX Forum? Network ArchitectureAeroMACS PKI Certificate PolicyDRAFT-T32-006-R010v01-HDraft Specification DOCPROPERTY Manager \* MERGEFORMAT (2016-02-19)7588256076950WiMAX Forum ProprietaryCopyright ? 2015 WiMAX Forum. All Rights Reserved.00WiMAX Forum ProprietaryCopyright ? 2015 WiMAX Forum. All Rights Reserved. Copyright Notice, Use Restrictions, Disclaimer, and Limitation of LiabilityCopyright 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.Document StatusWiMAX Forum Document ID:T32-006-R010-v01Document Title:AeroMACS PKI Certificate PolicyStatus:Work in ProgressDraftIssuedClosedDistribution Restrictions:Author OnlyAeroMACS/ MemberAeroMACS/ Member/VendorPublicRevision HistoryRevisionDateRemarksA 2015-10-13Initial Draft to propose structure and outline certificate profiles in section 7B2015-10-14Outline of all future sections added for contextC2015-11-10Section 6 added and Section 7 updated D2015-11-24Section 5 and 8 addedE2016-01-04Section 4 addedF2016-02-15Section 1-3 added and updated contentsG2016-02-17Changes Discussed in the PKI Task Group teleconference. Updated reference to server certificates separate from device certificates and added Chp 9.H2016-02-19Revisions in chapter 9 to proposed standard language. Clarification throughout related to APPAKey to Document Status Codes:Work in ProgressAn incomplete document, designed to guide discussion and generate feedback that may include several alternative requirements for consideration.DraftA document in specification format considered largely complete, but lacking review by Members. Drafts are susceptible to substantial change during the review process.IssuedA stable document, which has undergone rigorous review and is suitable for publication.ClosedA static document, reviewed, tested, validated, and closed to further documentation change requests.TABLE OF CONTENTS TOC \o "1-3" \h \z \u WiMAX Forum? Network Architecture PAGEREF _Toc443476971 \h i1.Introduction PAGEREF _Toc443476972 \h 111.1Overview PAGEREF _Toc443476973 \h 111.2Identification PAGEREF _Toc443476974 \h 111.2.1Certificate Policy Name PAGEREF _Toc443476975 \h 111.2.2OID PAGEREF _Toc443476976 \h 111.3PKI Participants PAGEREF _Toc443476977 \h 121.3.1AeroMACS PKI Policy Authority PAGEREF _Toc443476978 \h 121.3.2Certification Authorities (CA) PAGEREF _Toc443476979 \h 121.3.3Certificate Status Authority (CSA) PAGEREF _Toc443476980 \h 121.3.4Registration Authorities (RA) PAGEREF _Toc443476981 \h 121.3.5Device Sponsors PAGEREF _Toc443476982 \h 131.3.6Relying Parties PAGEREF _Toc443476983 \h 131.3.7Other Participants PAGEREF _Toc443476984 \h 131.4Certificate Usage PAGEREF _Toc443476985 \h 131.4.1Appropriate Certificate Uses PAGEREF _Toc443476986 \h 131.4.2Prohibited Certificate Uses PAGEREF _Toc443476987 \h 131.5Policy Administration PAGEREF _Toc443476988 \h 131.5.1Organization Administering the Document PAGEREF _Toc443476989 \h 131.5.2Contact Person PAGEREF _Toc443476990 \h 131.5.3Person Determining CPS Suitability for the Policy PAGEREF _Toc443476991 \h 141.5.4CPS Approval Procedures PAGEREF _Toc443477011 \h 142.Publication and Repository Responsibilities PAGEREF _Toc443477012 \h 152.1Repositories PAGEREF _Toc443477013 \h 152.2Publication of Certification Information PAGEREF _Toc443477014 \h 152.2.1Publication of CA Information PAGEREF _Toc443477015 \h 152.2.2Availability of Information PAGEREF _Toc443477016 \h 152.3Time or Frequency of Publication PAGEREF _Toc443477017 \h 152.4Access Controls on Repositories PAGEREF _Toc443477018 \h 152.4.1Certificate Policy PAGEREF _Toc443477019 \h 152.4.2Certificates and CRLs PAGEREF _Toc443477020 \h 153.Identification and Authentication PAGEREF _Toc443477021 \h 173.1Naming PAGEREF _Toc443477022 \h 173.1.1Types of Names PAGEREF _Toc443477023 \h 173.1.2Need for Names to be Meaningful PAGEREF _Toc443477024 \h 173.1.3Anonymity or Pseudonymity of Devices PAGEREF _Toc443477025 \h 173.1.4Rules for Interpreting Various Name Forms PAGEREF _Toc443477026 \h 173.1.5Uniqueness of Names PAGEREF _Toc443477027 \h 173.1.6Recognition, Authentication, and Role of Trademarks PAGEREF _Toc443477028 \h 173.2Initial Identity Validation PAGEREF _Toc443477029 \h 183.2.1Method to Prove Possession of Private Key PAGEREF _Toc443477030 \h 183.2.2Authentication of Individual Identity PAGEREF _Toc443477031 \h 183.2.3Non-verified Device Information PAGEREF _Toc443477032 \h 193.2.4Validation of Authority PAGEREF _Toc443477033 \h 193.2.5Criteria for Interoperation PAGEREF _Toc443477034 \h 193.3Re-key Requests PAGEREF _Toc443477035 \h 203.3.1Identification and Authentication for Routine Re-key PAGEREF _Toc443477036 \h 203.3.2Identification and Authentication for Re-key after Revocation PAGEREF _Toc443477037 \h 203.4Identification and Authentication for Revocation Request PAGEREF _Toc443477038 \h 204.Certificate Life-cycle Operational Requirements PAGEREF _Toc443477039 \h 214.1Certificate Application PAGEREF _Toc443477040 \h 214.1.1Who Can Submit a Certificate Application PAGEREF _Toc443477041 \h 214.1.2Enrollment Process and Responsibilities PAGEREF _Toc443477042 \h 214.2Certificate Application Processing PAGEREF _Toc443477043 \h 214.2.1Performing Identification and Authentication Functions PAGEREF _Toc443477044 \h 214.2.2Approval or Rejection of Certificate Applications PAGEREF _Toc443477045 \h 224.2.3Time to Process Certificate Applications PAGEREF _Toc443477046 \h 224.3Certificate Issuance PAGEREF _Toc443477047 \h 224.3.1CA Actions During Certificate Issuance PAGEREF _Toc443477048 \h 224.3.2Notification to Device Sponsor by the CA of Issuance of Certificate PAGEREF _Toc443477049 \h 234.4Certificate Acceptance PAGEREF _Toc443477050 \h 234.4.1Conduct Constituting Certificate Acceptance PAGEREF _Toc443477051 \h 234.4.2Publication of the Certificate by the CA PAGEREF _Toc443477052 \h 234.4.3Notification of Certificate Issuance by the CA to Other Entities PAGEREF _Toc443477053 \h 234.5Key Pair and Certificate Usage PAGEREF _Toc443477054 \h 234.5.1Device Private Key and Certificate Usage PAGEREF _Toc443477055 \h 234.5.2Relying Party Public Key and Certificate Usage PAGEREF _Toc443477056 \h 234.6Certificate Renewal PAGEREF _Toc443477057 \h 244.6.1Circumstance for Certificate Renewal PAGEREF _Toc443477058 \h 244.6.2Who May Request Renewal PAGEREF _Toc443477059 \h 244.6.3Processing Certificate Renewal Requests PAGEREF _Toc443477060 \h 244.6.4Notification of new Certificate Issuance to Device PAGEREF _Toc443477061 \h 244.6.5Conduct Constituting Acceptance of a Renewal Certificate PAGEREF _Toc443477062 \h 244.6.6Publication of the Renewal Certificate by the CA PAGEREF _Toc443477063 \h 244.6.7Notification of Certificate Issuance by the CA to Other Entities PAGEREF _Toc443477064 \h 244.7Certificate Re-key PAGEREF _Toc443477065 \h 244.7.1Circumstance for Certificate Re-key PAGEREF _Toc443477066 \h 244.7.2Who May Request Certification of a New Public Key PAGEREF _Toc443477067 \h 254.7.3Processing Certificate Re-keying Requests PAGEREF _Toc443477068 \h 254.7.4Notification of New Certificate Issuance to Device Sponsors PAGEREF _Toc443477069 \h 254.7.5Conduct Constituting Acceptance of a Re-keyed Certificate PAGEREF _Toc443477070 \h 254.7.6Publication of the Re-keyed Certificate by the CA PAGEREF _Toc443477071 \h 254.7.7Notification of Certificate Issuance by the CA to Other Entities PAGEREF _Toc443477072 \h 254.8Certificate Modification PAGEREF _Toc443477073 \h 254.8.1Circumstance for Certificate Modification PAGEREF _Toc443477074 \h 254.8.2Who May Request Certificate Modification PAGEREF _Toc443477075 \h 254.8.3Processing Certificate Modification Requests PAGEREF _Toc443477076 \h 254.8.4Notification of New Certificate Issuance to Device PAGEREF _Toc443477077 \h 254.8.5Conduct Constituting Acceptance of Modified Certificate PAGEREF _Toc443477078 \h 254.8.6Publication of the Modified Certificate by the CA PAGEREF _Toc443477079 \h 254.8.7Notification of Certificate Issuance by the CA to Other Entities PAGEREF _Toc443477080 \h 254.9Certificate Revocation and Suspension PAGEREF _Toc443477081 \h 264.9.1Circumstances for Revocation PAGEREF _Toc443477082 \h 264.9.2Who can Request Revocation PAGEREF _Toc443477083 \h 264.9.3Procedure for Revocation Request PAGEREF _Toc443477084 \h 264.9.4Revocation Request Grace Period PAGEREF _Toc443477085 \h 274.9.5Time within which CA Must Process the Revocation Request PAGEREF _Toc443477086 \h 274.9.6Revocation Checking Requirement for Relying Parties PAGEREF _Toc443477087 \h 274.9.7CRL Issuance Frequency PAGEREF _Toc443477088 \h 274.9.8Maximum Latency for CRLs PAGEREF _Toc443477089 \h 284.9.9On-line Revocation/Status Checking Availability PAGEREF _Toc443477090 \h 284.9.10On-line Revocation Checking Requirements PAGEREF _Toc443477091 \h 284.9.11Other Forms of Revocation Advertisements Available PAGEREF _Toc443477092 \h 284.9.12Special Requirements Regarding Key Compromise PAGEREF _Toc443477093 \h 284.9.13Circumstances for Suspension PAGEREF _Toc443477094 \h 284.9.14Who can Request Suspension PAGEREF _Toc443477095 \h 284.9.15Procedure for Suspension Request PAGEREF _Toc443477096 \h 284.9.16Limits on Suspension Period PAGEREF _Toc443477097 \h 284.10Certificate Status Services PAGEREF _Toc443477098 \h 284.10.1Operational Characteristics PAGEREF _Toc443477099 \h 284.10.2Service Availability PAGEREF _Toc443477100 \h 294.10.3Optional Features PAGEREF _Toc443477101 \h 294.11End of Subscription PAGEREF _Toc443477102 \h 294.12Key Escrow and Recovery PAGEREF _Toc443477103 \h 294.12.1Key Escrow and Recovery Policy and Practices PAGEREF _Toc443477104 \h 294.12.2Session Key Encapsulation and Recovery Policy and Practices PAGEREF _Toc443477105 \h 295.Facility, Management, and Operational Controls PAGEREF _Toc443477106 \h 305.1Physical Controls PAGEREF _Toc443477107 \h 305.1.1Site Location and Construction PAGEREF _Toc443477108 \h 305.1.2Physical Access PAGEREF _Toc443477109 \h 305.1.3Power and Air Conditioning PAGEREF _Toc443477110 \h 315.1.4Water Exposures PAGEREF _Toc443477111 \h 315.1.5Fire Prevention and Protection PAGEREF _Toc443477112 \h 315.1.6Media Storage PAGEREF _Toc443477113 \h 315.1.7Waste Disposal PAGEREF _Toc443477114 \h 315.1.8Off-Site Backup PAGEREF _Toc443477115 \h 315.2Procedural Controls PAGEREF _Toc443477116 \h 325.2.1Corporate Controls PAGEREF _Toc443477117 \h 325.2.2Trusted Roles PAGEREF _Toc443477118 \h 325.2.3Number of Persons Required per Task PAGEREF _Toc443477119 \h 335.2.4Identification and Authentication for Each Role PAGEREF _Toc443477120 \h 335.2.5Roles Requiring Separation of Duties PAGEREF _Toc443477121 \h 335.3Personnel Controls PAGEREF _Toc443477122 \h 345.3.1Qualifications, Experience, and Clearance Requirements PAGEREF _Toc443477123 \h 345.3.2Background Check Procedures PAGEREF _Toc443477124 \h 345.3.3Training Requirements PAGEREF _Toc443477125 \h 355.3.4Retraining Frequency and Requirements PAGEREF _Toc443477126 \h 355.3.5Job Rotation Frequency and Sequence PAGEREF _Toc443477127 \h 355.3.6Sanctions for Unauthorized Actions PAGEREF _Toc443477128 \h 355.3.7Independent Contractor Requirements PAGEREF _Toc443477129 \h 355.3.8Documentation Supplied to Personnel PAGEREF _Toc443477130 \h 355.4Audit Logging Procedures PAGEREF _Toc443477131 \h 355.4.1Types of Events Recorded PAGEREF _Toc443477132 \h 365.4.2Frequency of Processing Log PAGEREF _Toc443477133 \h 395.4.3Retention Period for Audit Log PAGEREF _Toc443477134 \h 405.4.4Protection of Audit Logs PAGEREF _Toc443477135 \h 405.4.5Audit Log Backup Procedures PAGEREF _Toc443477136 \h 405.4.6Audit Collection System (Internal vs. External) PAGEREF _Toc443477137 \h 405.4.7Notification to Event-Causing Subject PAGEREF _Toc443477138 \h 405.4.8Vulnerability Assessments PAGEREF _Toc443477139 \h 405.5Records Archival PAGEREF _Toc443477140 \h 405.5.1Types of Events Archived PAGEREF _Toc443477141 \h 405.5.2Retention Period for Archive PAGEREF _Toc443477142 \h 415.5.3Protection of Archive PAGEREF _Toc443477143 \h 415.5.4Archive Backup Procedures PAGEREF _Toc443477144 \h 425.5.5Requirements for Time-Stamping of Records PAGEREF _Toc443477145 \h 425.5.6Procedures to Obtain and Verify Archive Information PAGEREF _Toc443477146 \h 425.6Key Changeover PAGEREF _Toc443477147 \h 425.7Compromise and disaster recovery PAGEREF _Toc443477148 \h 425.7.1Incident and Compromise Handling Procedures PAGEREF _Toc443477149 \h 425.7.2Computing Resources, Software, and/or Data Are Corrupted PAGEREF _Toc443477150 \h 425.7.3Private Key Compromise Procedures PAGEREF _Toc443477151 \h 435.7.4Business Continuity Capabilities after a Disaster PAGEREF _Toc443477152 \h 435.8CA, CSA, or RA Termination PAGEREF _Toc443477153 \h 436.TECHNICAL SECURITY CONTROLS PAGEREF _Toc443477154 \h 446.1Key Pair Generation and Installation PAGEREF _Toc443477155 \h 446.1.1Key Pair Generation PAGEREF _Toc443477156 \h 446.1.2Private Key Delivery to Devices PAGEREF _Toc443477157 \h 446.1.3Public Key Delivery to Certificate Issuer PAGEREF _Toc443477158 \h 456.1.4CA Public Key Delivery to Relying Parties PAGEREF _Toc443477159 \h 456.1.5Key Sizes PAGEREF _Toc443477160 \h 456.1.6Public Key Parameters Generation and Quality Checking PAGEREF _Toc443477161 \h 466.1.7Key Usage Purposes (as per X.509 v3 Key Usage Field) PAGEREF _Toc443477162 \h 466.2Private Key Protection and Cryptographic Module Engineering Controls PAGEREF _Toc443477163 \h 476.2.1Cryptographic Module Standards and Controls PAGEREF _Toc443477164 \h 476.2.2Private Key (n out of m) Multi-Person Control PAGEREF _Toc443477165 \h 476.2.3Private Key Escrow PAGEREF _Toc443477166 \h 476.2.4Private Key Backup PAGEREF _Toc443477167 \h 476.2.5Private Key Archival PAGEREF _Toc443477168 \h 486.2.6Private Key Transfer into or from a Cryptographic Module PAGEREF _Toc443477169 \h 486.2.7Private Key Storage on Cryptographic Module PAGEREF _Toc443477170 \h 486.2.8Method of Activating Private Key PAGEREF _Toc443477171 \h 486.2.9Method of Deactivating Private Key PAGEREF _Toc443477172 \h 496.2.10Method of Destroying Private Key PAGEREF _Toc443477173 \h 496.2.11Cryptographic Module Rating PAGEREF _Toc443477174 \h 496.3Other Aspects of Key Pair Management PAGEREF _Toc443477175 \h 496.3.1Public Key Archival PAGEREF _Toc443477176 \h 496.3.2Certificate Operational Periods and Key Pair Usage Periods PAGEREF _Toc443477177 \h 496.4Activation data PAGEREF _Toc443477178 \h 506.4.1Activation Data Generation and Installation PAGEREF _Toc443477179 \h 506.4.2Activation Data Protection PAGEREF _Toc443477180 \h 506.4.3Other Aspects of Activation Data PAGEREF _Toc443477181 \h 506.5Computer security controls PAGEREF _Toc443477182 \h 506.5.1Specific Computer Security Technical Requirements PAGEREF _Toc443477183 \h 506.5.2Computer Security Rating PAGEREF _Toc443477184 \h 516.6Life Cycle Technical Controls PAGEREF _Toc443477185 \h 516.6.1System Development Controls PAGEREF _Toc443477186 \h 516.6.2Security Management Controls PAGEREF _Toc443477187 \h 516.6.3Life Cycle Security Controls PAGEREF _Toc443477188 \h 516.7Network Security Controls PAGEREF _Toc443477189 \h 516.8Time-Stamping PAGEREF _Toc443477190 \h 527.CERTIFICATE, CRL, AND OCSP PROFILES PAGEREF _Toc443477191 \h 537.1Certificate Profile PAGEREF _Toc443477199 \h 537.1.1Version Number(s) PAGEREF _Toc443477200 \h 537.1.2Certificate Extensions PAGEREF _Toc443477201 \h 547.1.3Algorithm Object Identifiers (OIDs) PAGEREF _Toc443477225 \h 577.1.4Name Forms PAGEREF _Toc443477226 \h 587.1.5Name Constraints PAGEREF _Toc443477227 \h 597.1.6Certificate Policy Object Identifier PAGEREF _Toc443477228 \h 597.1.7Usage of Policy Constraints Extension PAGEREF _Toc443477229 \h 607.1.8Policy Qualifiers Syntax and Semantics PAGEREF _Toc443477230 \h 607.1.9Processing Semantics for the Critical Certificate Policies Extension PAGEREF _Toc443477231 \h 607.2CRL Profile PAGEREF _Toc443477232 \h 607.2.1Version Number(s) PAGEREF _Toc443477233 \h 617.2.2CRL and CRL entry extensions PAGEREF _Toc443477234 \h 617.3OCSP Profile PAGEREF _Toc443477235 \h 617.3.1Version Number(s) PAGEREF _Toc443477236 \h 617.3.2OCSP Extensions PAGEREF _Toc443477237 \h pliance Audit and Other Assessments PAGEREF _Toc443477238 \h 628.1Frequency or Circumstances of Assessment PAGEREF _Toc443477239 \h 628.2Identity and Qualifications of Assessor PAGEREF _Toc443477240 \h 628.3Assessor's Relationship to Assessed Entity PAGEREF _Toc443477241 \h 628.4Topics Covered by Assessment PAGEREF _Toc443477242 \h 628.5Actions Taken as a Result of Deficiency PAGEREF _Toc443477243 \h 628.6Communication of Results PAGEREF _Toc443477244 \h 639.Other Business and Legal Matters PAGEREF _Toc443477245 \h 649.1Fees PAGEREF _Toc443477246 \h 649.1.1Certificate Issuance or Renewal Fees PAGEREF _Toc443477247 \h 649.1.2Certificate Access Fees PAGEREF _Toc443477248 \h 649.1.3Revocation or Statue Information Access Fees PAGEREF _Toc443477249 \h 649.1.4Fees for other Services PAGEREF _Toc443477250 \h 649.1.5Refund Policy PAGEREF _Toc443477251 \h 649.2Financial Responsibility PAGEREF _Toc443477252 \h 649.2.1Insurance Coverage PAGEREF _Toc443477253 \h 649.2.2Other Assets PAGEREF _Toc443477254 \h 649.2.3Insurance or Warranty Coverage for End-Entities PAGEREF _Toc443477255 \h 649.3Confidentiality of Business Information PAGEREF _Toc443477256 \h 649.3.1Scope of Confidential Information PAGEREF _Toc443477257 \h 649.3.2Information not within the Scope of Confidential Information PAGEREF _Toc443477258 \h 659.3.3Responsibility to Protect Confidential Information PAGEREF _Toc443477259 \h 659.4Privacy of Personal Information PAGEREF _Toc443477260 \h 659.4.1Privacy Plan PAGEREF _Toc443477261 \h 659.4.2Information Treated as Private PAGEREF _Toc443477262 \h 659.4.3Information not Deemed Private PAGEREF _Toc443477263 \h 659.4.4Responsibility to Protect Private Information PAGEREF _Toc443477264 \h 659.4.5Notice and Consent to Use Private Information PAGEREF _Toc443477265 \h 659.4.6Disclosure Pursuant to Judicial or Administrative Process PAGEREF _Toc443477266 \h 659.4.7Other Information Disclosure Circumstances PAGEREF _Toc443477267 \h 659.5Intellectual Property Rights PAGEREF _Toc443477268 \h 659.6Representations and Warranties PAGEREF _Toc443477269 \h 659.6.1CA Representations and Warranties PAGEREF _Toc443477270 \h 669.6.2RA Representations and Warranties PAGEREF _Toc443477271 \h 669.6.3Device Representations and Warranties PAGEREF _Toc443477272 \h 669.6.4Relying Parties Representations and Warranties PAGEREF _Toc443477273 \h 669.6.5Representations and Warranties of Other Participants PAGEREF _Toc443477274 \h 679.7Disclaimers of Warranties PAGEREF _Toc443477275 \h 679.8Limitations of Liability PAGEREF _Toc443477276 \h 679.9Indemnities PAGEREF _Toc443477277 \h 679.10Term and Termination PAGEREF _Toc443477278 \h 679.10.1Term PAGEREF _Toc443477279 \h 679.10.2Termination PAGEREF _Toc443477280 \h 679.10.3Effect of Termination and Survival PAGEREF _Toc443477281 \h 679.11Individual Notices and Communications with Participants PAGEREF _Toc443477282 \h 679.12Amendments PAGEREF _Toc443477283 \h 679.12.1Procedure for Amendment PAGEREF _Toc443477284 \h 679.12.2Notification and Mechanism and Period PAGEREF _Toc443477285 \h 679.12.3Circumstances under which OID must be Changed PAGEREF _Toc443477286 \h 679.13Dispute Resolution Provisions PAGEREF _Toc443477287 \h 689.14Governing Law PAGEREF _Toc443477288 \h 689.15Compliance with Applicable Law PAGEREF _Toc443477289 \h 689.16Miscellaneous Provisions PAGEREF _Toc443477290 \h 689.16.1Entire Agreement PAGEREF _Toc443477291 \h 689.16.2Assignment PAGEREF _Toc443477292 \h 689.16.3Severability PAGEREF _Toc443477293 \h 689.16.4Enforcement (Attorneys’ Fees and Waiver of Rights) PAGEREF _Toc443477294 \h 689.16.5Force Majeure PAGEREF _Toc443477295 \h 689.17Other Provisions PAGEREF _Toc443477296 \h 6810.References PAGEREF _Toc443477297 \h 6911.Glossary PAGEREF _Toc443477298 \h 7012.Abbreviations and Acronyms PAGEREF _Toc443477299 \h 73TABLE OF TABLES TOC \c "Table" Table 1: Algorithm Type and Key Size PAGEREF _Toc443476992 \h 45Table 2: keyUsage Extension for all CA certificates PAGEREF _Toc443476993 \h 46Table 3: keyUsage Extension for all Device Certificates PAGEREF _Toc443476994 \h 46Table 4: Certificate Profile Basic Fields PAGEREF _Toc443476995 \h 53Table 5: Root CA Certificate Standard Extensions PAGEREF _Toc443476996 \h 54Table 6: CA Certificate Standard Extensions PAGEREF _Toc443476997 \h 54Table 7: Device Certificate Standard Extensions PAGEREF _Toc443476998 \h 55Table 8: OCSP Certificate Standard Extensions PAGEREF _Toc443476999 \h 55Table 9: subjectKeyIdentifier Extension for AeroMACS CA Certificates PAGEREF _Toc443477000 \h 55Table 10: basicConstraints Extension for AeroMACS Root CA Certificates PAGEREF _Toc443477001 \h 56Table 11: basicConstraints Extension for AeroMACS CA Certificates PAGEREF _Toc443477002 \h 56Table 12: extKeyUsage Extension for AeroMACS Server Certificates PAGEREF _Toc443477003 \h 57Table 13: Signature OIDS for Certificates PAGEREF _Toc443477004 \h 57Table 14: subjectPublicKeyInfo for Certificates PAGEREF _Toc443477005 \h 57Table 15: Root CA Certificate Issuer and Subject Fields PAGEREF _Toc443477006 \h 58Table 16: CA Certificate Subject Fields PAGEREF _Toc443477007 \h 58Table 17: Device Certificate Subject Fields PAGEREF _Toc443477008 \h 59Table 18: certificatePolicies Extension for AeroMACS Certificates PAGEREF _Toc443477009 \h 59Table 19: CRL Profile Basic Fields PAGEREF _Toc443477010 \h 60IntroductionOverviewAeroMACS (Aeronautical Mobile Airport Communications System) is the broadband wireless technology based on WiMAX intended to support the transmission of safety and traffic control data for both fixed and mobile applications on the airport surface. To support secure communication between end-points, AeroMACS requires digital certificate based strong authentication across the AeroMACS system.This Certificate Policy (CP) defines the procedural and operational requirements that AeroMACS requires entities to adhere to when issuing and managing digital certificates within the AeroMACS Public Key Infrastructure (PKI). AeroMACS’ certificates are control by the AeroMACS PKI Policy Authority (APPA) that determines how this CP applies to Certificate Authorities (CAs), Registration Authorities (RAs), Certificate Status Authority (CSAs), Device Sponsors, Relying Parties and other PKI entities that interoperate with or within the AeroMACS PKI. A Certificate issued in accordance with this CP conveys within the Aerospace Community a level of digital identity assurance associated with the Subject of the Certificate. Certificates created within this PKI will be medium-assurance certificates for devices with hardware cryptographic modules. In this document, the term “device” means a non-person entity, i.e., a hardware device or software application.A PKI that uses this CP will provide the following security management services:Key generation and storageCertificate generation, modification, re-key, and distributionCertificate Revocation List (CRL) generation and distributionDirectory management of certificate related itemsCertificate token initialization, programming, and managementSystem management functions to include security audit, configuration management, and archiveThis policy establishes requirements for the secure distribution of self-signed root certificates for use as trust anchors. These constraints apply only to CAs that chose to distribute self-signed certificates, such as a hierarchical PKI’s root CA.This CP is only one of several documents that govern the AeroMACS PKI. Other important documents include the Certification Practice Statements (CPS), registration authority agreements, Subscriber Agreements, privacy policies, and memoranda of agreement.It is consistent with the Internet Engineering Task Force (IETF) Public Key Infrastructure X.509 (IETF PKIX) RFC 3647, Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practice Statement Framework as well as the Aviation Industry Standards for Digital Information Security (ATA Spec 42).IdentificationCertificate Policy NameThis document shall be named the AeroMACS PKI Certificate Policy (CP). It shall furthermore have an assurance-level designation, according to the OID from Section REF _Ref442877419 \r \h \* MERGEFORMAT 1.2.2 under which this document is referenced. For example, this document may be referenced as the AeroMACS Medium-Assurance Certificate Policy. OIDCertificates issued in accordance with this Certificate Policy shall be known by the following OIDs, depending on the level of assurance to be conveyed:Medium-Assurance (Software):{iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) AeroMACS (?????) Medium(3) Software(1)}PKI ParticipantsAeroMACS PKI Policy AuthorityICAO is the AeroMACS PKI Policy Authority (APPA). The APPA is responsible for:Approving and Maintaining this CP,Approving the CPS for each CA that issues certificates under this policy,Approving the compliance audit report for each CA issuing certificates under this policy, andEnsuring continued conformance of each CA that issues certificates under this policy with applicable requirements as a condition for allowing continued participation.Certification Authorities (CA)Any Entity providing services, or wishing to provide services, to the global Air Transport or Aerospace Communities may, with the authorization of the APPA, operate a CA and issue certificates in accordance with this CP, provided all provisions of this CP are followed.The CA is the collection of hardware, software and operating personnel that create, sign, and issue public key certificates to devices. The CA is responsible for issuing and managing certificates including: The certificate manufacturing process Publication of certificates Revocation of certificates Generation and destruction of CA signing keys Ensuring that all aspects of the CA services, operations, and infrastructure related to certificates issued under this CP are performed in accordance with the requirements, representations, and warranties of this CP.Certificate Status Authority (CSA)PKIs may optionally include an authority that provides status information about certificates on behalf of a CA through on-line transactions. In particular, PKIs may include Online Certificate Status Protocol (OCSP) responders to provide on-line status information. Such an authority is termed a certificate status authority (CSA). Where the CSA is identified in certificates as an authoritative source for revocation information, the operations of that authority are considered within the scope of this CP. A Certificate Status Authority shall assert all the policy OIDs for which it is authoritative. Examples include OCSP servers that are identified in the authority information access (AIA) extension. OCSP servers that are locally trusted, as described in RFC 2560, are not covered by this policy. Registration Authorities (RA)The registration authorities (RAs) collect and verify each device’s identity and information that is to be entered into the device’s public key certificate. The RA performs its function in accordance with a CPS approved by the APPA. The RA is responsible for: Control over the registration process The identification and authentication processDevice SponsorsA device sponsor is a person who requests a certificate on behalf of a device within the AeroMACS ecosystem. The device sponsor asserts that the device will use the key and certificate in accordance with the certificate policy asserted in the certificate. Relying PartiesA Relying Party is an entity that relies on the validity of the binding of the device's name to a Public Key. The Relying Party is responsible for deciding whether or how to check the validity of the Certificate by checking the appropriate certificate status information. The Relying Party can use the Certificate to verify the integrity of a digitally signed message, to identify the creator of a message, or to negotiate session keys for the establishment of confidential communications with the holder of the Certificate. A Relying Party may use information in the Certificate (such as Certificate Policy identifiers) to determine the suitability of the Certificate for a particular use.Other Participants The CAs and RAs operating under this CP may require the services of other security, community, and application authorities, such as compliance auditors and attribute authorities. The CPS will identify the parties responsible for providing such services, and the mechanisms used to support these services. Certificate UsageAppropriate Certificate UsesMedium- assurance certificates issued under this CP may be used for digital signature functions and encryption between devices where a certain degree of trust is required.Prohibited Certificate UsesProhibited applications include the following:Any export, import, use or activity that contravenes any local or international laws or regulationsAny usage of Certificates in conjunction with illegal activitiesAny usage of Certificates for personal use or purposes not related to the Community’s businessAny use of a Certificate after it has been revokedAny use not expressly permitted in Section REF _Ref442886010 \r \h \* MERGEFORMAT 1.4.1.Policy AdministrationOrganization Administering the DocumentThis CP is administered by the WiMAX Forum Aviation Working Group (AWG).Contact PersonThe following individual is responsible for accepting comments on this CP on behalf of the group mentioned above:WiMAX Forum Aviation Working GroupRichard HawkinsChief Operating Officer and Chairman, Technical Steering Committeerich.hawkins@Person Determining CPS Suitability for the PolicyA CPS may be approved as sufficient for fulfilling the obligations under this CP when such a CPS has been reviewed by an auditor or compliance analyst competent in the operations of a PKI, and when said person determines that the CPS is in fact in compliance with all aspects of this CP. The auditor or compliance analyst shall be from a firm which is independent from the entity being audited. CPS Approval ProceduresThe term CPS is defined in the Internet RFC 3647, X.509 Public Key Infrastructure Certificate Policy and Certification Practice Statement Framework as: “A statement of the practices, which a CA employs in issuing certificates.” It is a comprehensive description of such details as the precise implementation of service offerings and detailed procedures of certificate life-cycle management. It shall be more detailed than the corresponding CP defined above.Publication and Repository ResponsibilitiesRepositoriesAll CAs that issue certificates under this policy are obligated to post all CA certificates issued by or to the CA and CRLs issued by the CA in a repository that is publicly accessible through all Uniform Resource Identifier (URI) references asserted in valid certificates issued by that CA. To promote consistent access to certificates and CRLs, the repository shall implement access controls and communication mechanisms to prevent unauthorized modification or deletion of information.Publication of Certification InformationPublication of CA InformationCAs issuing a Certificate in accordance with this CP shall make the following items publicly available in their repositories:This CP;The CRL; andAll CA Certificates issued by the CA (including self-signed CA-Certificate and Cross-Certificates for Cross-Certified CAs).Signature and Identity Certificates need not be published in the PKI repository.The CA shall notify device sponsors and Relying Parties of Certificate issuance by providing access to Certificates and CRLs in a Certificate Repository.When using LDAP as the repository access mechanism, the following object classes and attributes shall be populated:Repository entries that describe CAs shall be a member of the pkiCA and cpCPS auxiliary object classes and populate the cACertificate, certificateRevocationList, cPCPS and crossCertificatePair attributes as applicable.Availability of InformationAll information published in the Repository shall be available on a twenty-four (24) hours per day, seven (7) days per week basis, save for periods of scheduled or unscheduled downtime, as negotiated between relevant parties as part of a Commercial Contract.Time or Frequency of PublicationThe CA’s public information identified in Section REF _Ref441154730 \r \h \* MERGEFORMAT 2.2.1 shall be published prior to the first Certificate being issued in accordance with this CP. Certificate publication shall be done in accordance with Section REF _Ref439070779 \r \h \* MERGEFORMAT 4.4.2. CRL publication shall be done in accordance with Sections REF _Ref439072061 \r \h \* MERGEFORMAT 4.9.7 and REF _Ref441154289 \r \h \* MERGEFORMAT 4.9.12.Access Controls on RepositoriesCertificate PolicyThere shall be no access controls to prevent the reading of this CP.Certificates and CRLsOnly CAs shall be able to create, modify, or otherwise maintain Certificates or CRLs. These operations shall require a password over SSL or stronger authentication mechanism. Read only access to both Certificates and CRL within the Certificate Repository shall be granted to anonymous users (i.e.: authentication type “none”) of the Certificate Repository. Identification and AuthenticationNamingTypes of NamesEach device shall have a clearly distinguishable and unique X.501 Distinguished Name (DN) in the Certificate Subject name field and in accordance with RFC 5280. Certificates may include additional names via the subjectAltName extension, provided it is marked noncritical, which shall be in accordance with RFC 5280.For certificates issued to devices, the subjectAltName shall contain the Device Class that is defined in the Manuel on Aeronautical Mobile Airport Communications System (AeroMACS) and be marked as critical. The Device Classes include: Aircraft, Surface Vehicle, Video Sensor, Ground Critical, or Ground Default. The Common Name (CN) portion of the DN shall contain the devices media access control (MAC) address.Need for Names to be MeaningfulThe certificates issued pursuant to this CP are meaningful only if the names that appear in the certificates can be understood and used by Relying Parties. Names used in the certificates must identify the person or object to which they are assigned in a meaningful way.When DNs are used, it is preferable that the common name represents the device in a way that is easily understandable for humans.For Individuals, this will typically be a legal name.For End-Entity equipment, this may be a model name and serial number, an application process (e.g., Organization X Mail List or Organization Y Multifunction Interpreter), or a fully qualified domain name (), or network address (on the Internet, an IP or IPv6 address in a recognizable standard form), or another kind of name that is meaningful in the domain of application (e.g., for AMS entity name as defined in Section REF _Ref441156529 \r \h \* MERGEFORMAT 7.1.4)Anonymity or Pseudonymity of DevicesCA certificates shall not contain anonymous or pseudonymous identities.DNs in certificates issued to devices may contain a pseudonym to meet local privacy regulations as long as name space uniqueness requirements are met and as long as such name is unique and traceable to the actual entity.Rules for Interpreting Various Name FormsRules for interpreting distinguished name forms are specified in X.501. Rules for interpreting e-mail addresses are specified in [RFC 2822].Uniqueness of NamesName uniqueness across the AeroMACS domains, including cross-certified domains shall be enforced. The CAs and RAs shall enforce name uniqueness within the X.500 name space, which they have been authorized.The APPA shall be responsible for ensuring name uniqueness in certificates issued by the AeroMACS CAs.Recognition, Authentication, and Role of TrademarksThe CA reserves the right to make all decisions regarding device names in all assigned Certificates. Devices shall not use names in their Certificate Applications that knowingly infringe upon the Intellectual Property Rights of others. No CA operating under this CP shall be required to determine whether a device has Intellectual Property Rights in the name appearing in a DN or to arbitrate, mediate, or otherwise resolve any dispute concerning the ownership of any domain name, trade name, trademark, or service mark. A CA operating under this CP shall be entitled, without liability to any device sponsor, to reject or suspend any Certificate because of such dispute. Notwithstanding the above, if the CA opts to invoke Section REF _Ref441161148 \r \h \* MERGEFORMAT 3.1.5 on a device’s name, then the CA shall indemnify the Device Sponsor against any claims against that given name, except where the Device Sponsor acts in a negligent and reckless manner.Initial Identity ValidationMethod to Prove Possession of Private KeyIn all cases where the party named in a certificate generates its own keys that party shall be required to prove possession of the private key, which corresponds to the public key in the certificate request. For signature keys, this may be done by the entity using its private key to sign a value and providing that value to the issuing CA. The CA shall then validate the signature using the party’s public key. In the case of an aircraft avionics component which is not capable of generating its own keys (e.g.: for an AMS Aircraft Entity Certificate), this may only be possible from a separate computer before the key is transferred into the aircraft avionics component. Subsequent to proof of possession, the private key shall be distributed to the aircraft avionics in a manner consistent with section REF _Ref441161777 \r \h \* MERGEFORMAT 6.2.Authentication of Individual IdentityDevice SubjectsFor purposes of accountability and responsibility, an application for a Certificate of this type for a server, application, or device shall be made by an individual, and the Digital Signature of that server, application, or device shall be attributable to that individual. The Applicant shall provide the following registration information corresponding to the server, application, or device:Equipment identification (e.g.: serial number) or service name (e.g.: DNS Fully Qualified Domain Name, IP address, AMS Entity identifier per Section REF _Ref441218250 \r \h \* MERGEFORMAT 7.1.4, or other network address) sufficient to uniquely identify the Subject;Equipment authorizations and attributes (if any are to be included in the Certificate); and Contact information to enable the CA or RA to communicate with the Applicant when required.The CA or RA shall keep a record of the type and details of authentication used. The registration information shall be verified to an assurance level commensurate with the Certificate assurance level being requested. Acceptable methods for performing this authentication and integrity checking include, but are not limited to:Verification of digitally signed messages sent from the individual requesting the device Certificate (using Certificates of equivalent or greater assurance than that being requested); orIn-person registration by the individual requesting the device Certificate, with the identity of the individual confirmed in accordance with the requirements of section REF _Ref441217746 \r \h \* MERGEFORMAT 3.2.3.2.Individual SubjectsA CA shall ensure that the Applicant's identity information is verified and checked in accordance with the applicable CP and CPS. The CA or an RA shall ensure that the Applicant's identity information and public key are properly bound. Additionally, the CA or the RA shall record the process that was followed for issuance of each Certificate. The process documentation and authentication requirements shall include the following:Note: Personally identifiable information may be collected and stored to the extent permitted by applicable law. CAs and RAs are responsible for ensuring that they are in compliance with all applicable laws when collecting such information.The identity of the person performing the identity verification;A signed declaration by that person that he or she verified the identity of the Applicant as required by the applicable CP which may be met by establishing how the Applicant is known to the verifier as required by this CP;The date and time of the verification;For all assurance levels, the following information shall be recorded:the full name, including surname and given name(s) of the Applicant;the date and place of birth or other attribute(s) which may be used to uniquely identify the Applicant;the full name and legal status of the Device Sponsor's Employer;a physical address or other suitable method of contact; anda declaration signed by the Applicant indicating his acceptance of the privacy policy outlined in Section REF _Ref441217997 \r \h \* MERGEFORMAT 9.4.For medium-assurance Certificates, the Applicant shall:present one valid national government-issued photo ID, or two valid non-national government IDs, one of which shall be a recent photo ID (e.g.: driver's license);have recorded with the above information for all assurance levels, unique identifying numbers from the Identifier (ID) of the verifier and from an ID of the Applicant; andsign a declaration of identity using a handwritten signature. This shall be performed in the presence of the person performing the identity authentication.Identity shall be established by in-person proofing before the RA, Trusted Agent, or an entity certified by a state or government entity as being authorized to confirm identities; information provided shall be verified to ensure legitimacy. A trust relationship between the Trusted Agent and the Applicant which is based on an in-person antecedent may suffice as meeting the in-person identity proofing requirement. Identity shall be established no more than 30 days within the CA's signature on the subject Certificate.Non-verified Device InformationInformation that is not verified shall not be included in Certificates.Validation of AuthorityTo obtain a medium-assurance Certificate, any prospective Device Sponsor whose employer is not the issuing CA must present at the time of authentication a letter from their employer authorizing him or her to obtain a certificate of this type. NOTE: Various special purpose Certificates are subject to extra requirements concerning validation of authority, as follows:For certificates to be loaded in aircraft avionics, a document proving the Applicant's employer's status as an airline or as another type of legitimate operator of the given aircraft, such as a copy of aircraft registration papers, must be provided.For certificates used by ground entities that communicate with aircraft avionics, a document proving the Applicant's employer's status as an airline as above, or as a supplier of datalink service to an airline, such as a signed contract to that effect, must be provided.Criteria for InteroperationInteroperating CAs shall adhere to the following requirements:Complete a policy mapping with the Subject CA's CP with results satisfactory to both parties;Operate a PKI that has undergone a successful compliance audit pursuant to section 8 of this CP and as set forth in the Subject CA CP;Issue Certificates compliant with the profiles described in this CP, and make Certificate status information available in compliance with this CP; andProvide CA Certificate and Certificate status information to the Relying Parties.Re-key RequestsIdentification and Authentication for Routine Re-keyA request for re-key may only be made by the Device Sponsor in whose name the device keys have been issued. All requests for re-key shall be authenticated by the CA, and the subsequent response shall be authenticated by the Device Sponsor. This may be done by an on-line method in accordance with RFC 4210. Alternatively, a Device Sponsor requesting re-key may authenticate the request using its valid Digital Signature key pair. Where the key has expired, the request for re-key shall be authenticated by the CA in the same manner as the initial registration. Identity shall be verified at least once every nine years. When the current Signing Key is used for identification and authentication purposes, the life of the new Certificate shall not exceed the initial identity-proofing times specified in the paragraph above.Identification and Authentication for Re-key after RevocationAfter a Certificate has been revoked other than during a renewal or update action, the subject is required to go through the initial registration process described in Section REF _Ref340590027 \r \h \* MERGEFORMAT 3.2 to obtain a new Certificate, unless he/she can be authenticated through the use of a valid public key certificate of equal or higher assurance, as specified in Section REF _Ref441239103 \r \h \* MERGEFORMAT 3.3.1.Identification and Authentication for Revocation RequestRevocation requests shall be authenticated. Requests to revoke a certificate may be authenticated using that certificate's associated public key, regardless of whether or not the private key has been compromised.Certificate Life-cycle Operational RequirementsCertificate ApplicationThe Certificate application process must provide sufficient information to: Establish the applicant’s authorization (by the employing or sponsoring agency) to obtain a certificate. (per section REF _Ref440028617 \r \h 3.2.3) Establish and record identity of the applicant. (per section REF _Ref440028618 \r \h 3.2.3) Obtain the applicant’s public key and verify the applicant’s possession of the private key for each certificate required. (per section REF _Ref440028620 \r \h 3.2.1) Verify authorization information requested for inclusion in the certificate. These steps may be performed in any order that is convenient for the PKI authorities and applicants that does not defeat security, but all must be completed before certificate issuance. Who Can Submit a Certificate ApplicationA Certificate Application may be submitted by any of the following: any individual who will be the subject of an Individual Certificate, or who owns or operates a server, device, or application that will be the subject of an End-Entity Certificate; any authorized representative of an organization or Entity; andany authorized representative of a CA; or any authorized representative of an RA. Enrollment Process and ResponsibilitiesAll Device Sponsors must agree to be bound by a relevant Subscriber Agreement that contains representations and warranties described in Section REF _Ref439066468 \r \h 9.6 and to undergo an enrollment process consisting of the following: completing a Certificate Application and providing true and correct information; generating, or arranging to have generated, a key pair, in accordance with Section REF _Ref438647731 \r \h 6.1.1 of the present document; delivering his, her, or its public key, directly or through an RA, to the CA's facility; and demonstrating possession of the private key corresponding to the public key as described in Section REF _Ref440028657 \r \h 3.2.1.All communications among PKI authorities supporting the certificate application and issuance process shall be authenticated and protected from modification; any electronic transmission of shared secrets shall be protected. Communications may be electronic or out-of-band. Where electronic communications are used, cryptographic mechanisms commensurate with the strength of the public/private key pair shall be used. Out-of-band communications shall protect the confidentiality and integrity of the data.Certificate Application ProcessingInformation in certificate applications must be verified as accurate before certificates are issued. PKI authorities shall specify procedures to verify information in certificate applications.Performing Identification and Authentication FunctionsThe application will be subject to identification and authentication checks as described in Section REF _Ref340590027 \r \h 3.2 and Section REF _Ref440028710 \r \h 3.3 of this CP. The APPA must identify the components of the PKI (e.g. CA or RA) that are responsible for authenticating the Device Sponsor’s identity in each case.Additionally, prior to Certificate issuance, a Device Sponsor shall be required to sign a document stating that the Device Sponsor shall protect the Private Key and use the Certificate and Private Key for authorized purposes only.Approval or Rejection of Certificate ApplicationsA Certificate application will be approved by the CA or RA if all of the following conditions are met: successful identification and authentication of all required device information as described in Section REF _Ref340590027 \r \h 3.2; and payment (if applicable) has been received. A Certificate application will be rejected by the CA or RA if any one or more of the following conditions arises: identification and authentication of all required Device information as described in Section REF _Ref340590027 \r \h 3.2 cannot be completed; the Device Sponsor fails to furnish supporting documentation upon request; the Device Sponsor fails to respond to notices within a specified time; payment (if applicable) has not been received; or the RA or CA believe that issuing a certificate to the Device may bring the CA into disrepute. Time to Process Certificate Applications The entire registration process (i.e.: from initial application to identity proofing to Certificate issuance) shall take no more than 30 days. Certificate Issuance Upon receiving a request for a certificate, the CA or RA shall respond in accordance with the requirements set forth in this CP and in its CPS. The certificate request may optionally contain an already built ("to-be-signed") certificate. This certificate will not be signed until the process set forth in the CP and CPS has been met. While the Device Sponsor may do most of the data entry, it is still the responsibility of the CA and the RA to verify that the information is correct and accurate. This may be accomplished through a system approach linking trusted databases containing personnel information, through other equivalent authenticated mechanisms, or through personal contact with the device’s sponsoring organization. If databases are used to confirm Device information, then these databases must be protected from unauthorized modification to a level commensurate with the level of assurance of the certificate being sought. CA Actions During Certificate Issuance A Certificate is created and issued following the approval of a Certificate Application by a CA or following receipt of an RA's request to issue the Certificate. Upon receiving the request, the CAs/RAs shall Verify the identity and authority of the requester;Check to ensure that all fields and extensions are properly populated;Build and sign a certificate if all certificate requirements have been met (in the case of an RA, have the CA sign the certificate). Make the certificate available to the device after confirming that the Device Sponsor has formally acknowledged their obligations as described in Section REF _Ref440029894 \r \h 9.6.3.Notification to Device Sponsor by the CA of Issuance of Certificate CAs issuing Certificates to Devices shall, either directly or through an RA, notify Device Sponsors that they have created such Certificates, and provide Device Sponsors with access to the Certificates. Certificate AcceptanceBefore a device can make effective use of its private key, a PKI Authority shall explain to the Device Sponsor its responsibilities as defined in Section REF _Ref440029895 \r \h 9.6.3.Conduct Constituting Certificate Acceptance An issued Certificate shall be deemed to have been accepted when it has been downloaded, installed, or used by the device, and the Device Sponsor has not objected to the Certificate or its contents. Publication of the Certificate by the CA As specified in 2.1, all CA certificates shall be published in repositories. This policy makes no stipulation regarding publication of device certificates, except as noted in Section REF _Ref440029896 \r \h 9.4.3.Notification of Certificate Issuance by the CA to Other Entities The APPA must be notified whenever a CA operating under this policy issues a CA certificate.Key Pair and Certificate UsageDevice Private Key and Certificate Usage Use of the Private Key corresponding to the Public Key in the Certificate shall only be permitted once the Device Sponsor has agreed to the Subscriber Agreement and accepted the Certificate. The Certificate shall be used lawfully in accordance with the Subscriber Agreement and the terms of this CP. Certificate use must be consistent with the keyUsage and extendedKeyUsage extensions, in the associated Certificate. Devices shall protect their Private Keys from unauthorized use and shall discontinue use of the Private Key following expiration or revocation of the Certificate. Relying Party Public Key and Certificate Usage Reliance on a certificate must be reasonable under the circumstances. If the circumstances indicate a need for additional assurances, the Relying Party must obtain such assurances for such reliance to be deemed reasonable. Before any act of reliance, Relying Parties shall independently assess the following: the appropriateness of the use of a Certificate for any given purpose and determine that the Certificate will, in fact, be used for an appropriate purpose that is not prohibited or otherwise restricted by Section REF _Ref442886010 \r \h 1.4.1 or REF _Ref442958272 \r \h 1.4.2. CAs and RAs are not responsible for assessing the appropriateness of the use of a Certificate; that the Certificate is being used in accordance with the keyUsage and extendedKeyUsage extensions included in the Certificate; and the status of the Certificate and all the CAs in the chain that issued the Certificate. If any of the Certificates in the Certificate Chain have been revoked, the Relying Party shall not rely on the device’s Certificate or other revoked Certificate in the Certificate Chain. Assuming that the use of the Certificate is appropriate, Relying Parties shall utilize the appropriate software and/or hardware to perform digital signature verification or other cryptographic operations they wish to perform, as a condition of relying on Certificates in connection with each such operation. Certificate RenewalRenewing a Certificate means creating a new Certificate with the same name, key, and other information as the old one, but a new, extended validity period and a new serial number is created. Certificates may be renewed in order to reduce the size of CRLs. Circumstance for Certificate Renewal A Certificate may be renewed if the Public Key has not reached the end of its validity period, the associated Private Key has not been revoked or compromised, and the device name and attributes are unchanged. In addition, the validity period of the Certificate must not exceed the remaining lifetime of the Private Key, as specified in Section REF _Ref440030242 \r \h 6.3.2. The identity proofing requirement listed in Section REF _Ref440030076 \r \h 3.3.1 shall also be met. The CA may automatically renew certificates during recovery from a key compromise.Who May Request Renewal A device or its Device Sponsor or employer may request the renewal of a Certificate. A CA may also request renewal of its device Certificates, for example when the CA re-keys. Processing Certificate Renewal Requests In all cases, it is required that the device provide proof of possession of the Private Key in order to renew the Certificate. This can be achieved in the manner described in Section REF _Ref440028620 \r \h 3.2.1. Notification of new Certificate Issuance to Device Notification shall be given to the Device Sponsor in accordance with Section REF _Ref439070703 \r \h 4.3.2. Conduct Constituting Acceptance of a Renewal Certificate See Section REF _Ref439070739 \r \h 4.4.1.Publication of the Renewal Certificate by the CA Renewed certificates are published as in Section REF _Ref439070779 \r \h 4.4.2.Notification of Certificate Issuance by the CA to Other Entities See Section REF _Ref440030468 \r \h 4.4.3.Certificate Re-keyThe longer and more often a key is used, the more susceptible it is to loss or discovery. Therefore, it is important that a device periodically obtains new keys and reestablishes its identity. Re-keying a Certificate means that a new Certificate is created, having the same characteristics and level as the old one, except that the new Certificate has a new, different, Public Key (corresponding to a new, different, Private Key) and a different serial number, and it may be assigned a different validity period. The old certificate may or may not be revoked, but must not be further re-keyed, renewed, or modified.Device Sponsors shall identify themselves for the purpose of re-keying as required in Section REF _Ref439073756 \r \h 3.3.Circumstance for Certificate Re-key A Certificate may be re-keyed after revocation, for example due to a compromised Private Key. A Certificate may also be re-keyed before (to maintain continuity of Certificate usage) or after expiration of the Certificate and/or its key pair. It may also be re-keyed due to the issuance of a new hardware token.Who May Request Certification of a New Public Key The Device Sponsor of a device may request certification of a new public key or CAs and RAs may request certification of a new public key on behalf of a device. Processing Certificate Re-keying Requests In all cases, it is required that the device provide proof of possession of the newly generated key pair's Private Key before a new Certificate will be generated. This can be achieved in the manner described in Section REF _Ref440028620 \r \h 3.2.1. Alternatively, device re-key requests may be processed using the same process used for initial certificate issuance.Notification of New Certificate Issuance to Device Sponsors Notification shall be given to the Device Sponsors in accordance with Section REF _Ref439070703 \r \h 4.3.2.Conduct Constituting Acceptance of a Re-keyed Certificate See Section REF _Ref439070739 \r \h 4.4.1.Publication of the Re-keyed Certificate by the CA Re-keyed certificates are published as in Section REF _Ref439070779 \r \h 4.4.2. Notification of Certificate Issuance by the CA to Other Entities No specific requirement. Certificate ModificationAll requests for Certificate modification shall be treated as new Certificate applications. Circumstance for Certificate ModificationNot supported. Who May Request Certificate Modification Not supported. Processing Certificate Modification Requests Not supported. Notification of New Certificate Issuance to Device Not supported. Conduct Constituting Acceptance of Modified Certificate Not supported. Publication of the Modified Certificate by the CA Not supported. Notification of Certificate Issuance by the CA to Other Entities Not supported. Certificate Revocation and SuspensionCAs operating under this policy shall issue CRLs covering all unexpired certificates issued under this policy except for OCSP responder certificates that include the id-pkix-ocsp-nocheck extension.CAs operating under this policy shall make public a description of how to obtain revocation information for the certificates they publish, and an explanation of the consequences of using dated revocation information. This information shall be given to Device Sponsors during the certificate request or issuance, and shall be readily available to any potential relying party.Revocation requests must be authenticated. Requests to revoke a Certificate may be authenticated using that Certificate's associated Public Key, regardless of whether the Private Key has been compromised. Circumstances for Revocation Revocation shall occur on decision of the CA when reasonable and credible evidence exists to establish at least one of the following: the Certificate has been delivered based upon wrong or falsified information; the identifying information or affiliation components of any names in the Certificate become invalid; the confidentiality of a Private Key is no longer ensured or has been compromised; the media holding the Private Key is suspected or known to have been compromised; the Certificate fees have not been paid according to the payment terms as indicated in the relevant agreement; the Device Sponsor can be shown to have violated one or more sections of this CP; or the Device Sponsor or the Device Sponsor's Employer wishes to terminate their Subscription to the CA Whenever any of the above circumstances occur, the associated Certificate shall be revoked and placed on the CRL. Revoked Certificates shall be included on all new publications of the Certificate status information until the Certificates expire. Who can Request Revocation The revocation of an individual or End-Entity Certificate may only be requested by one of the following: the Device Sponsor responsible for the server, device, or application; the Device Sponsor's Employer organization; the personnel of the Issuing CA; or the personnel of any RA associated with the issuing CA. For CA Certificates, authorized individuals representing the CA operations may request revocation of Certificates. A written notice and brief explanation for the revocation shall subsequently be provided to the Device Sponsor.Procedure for Revocation Request A request to revoke a Certificate shall identify the Certificate to be revoked, explain the reason for revocation, and allow the request to be authenticated (e.g.: digitally or manually signed). The CA shall ensure that all procedures and requirements for revocation of a Certificate of this type are documented in the CPS. Where a Device's Certificate is revoked, the revocation shall be published in the appropriate CRL. For Certificates whose operation involves the use of a cryptographic hardware token, a Device Sponsor ceasing its relationship with an organization that sponsored the Certificate shall, prior to departure, surrender to the organization (through any accountable mechanism) all such hardware tokens that were issued by or on behalf of the sponsoring organization. The contents of the token, or the token itself, shall be destroyed in accordance with Section REF _Ref439071447 \r \h 6.2.10 promptly upon surrender and shall be protected from malicious use between surrender and such destruction of the key. If a Device Sponsor leaves an organization and the hardware tokens cannot be obtained from the Device Sponsor, then all device Certificates associated with the un-retrieved tokens shall be immediately revoked for the reason of key compromise. Revocation Request Grace Period There is no revocation grace period. Responsible parties must request revocation as soon as they identify the need for revocation. Time within which CA Must Process the Revocation Request Revocation request shall be processed within 18 hours of receipt of request. Revocation Checking Requirement for Relying Parties Use of revoked Certificates could have damaging or catastrophic consequences in certain applications. The matter of how often new revocation data should be obtained is a determination to be made by the Relying Party and the system accreditor. If it is temporarily infeasible to obtain revocation information, then the Relying Party must either reject use of the Certificate, or make an informed decision to accept the risk, responsibility, and consequences for using a Certificate whose authenticity cannot be guaranteed to the standards of this policy. Such use may occasionally be necessary to meet urgent operational requirements. CRL Issuance Frequency CRLs shall be issued periodically, even if there are no changes to be made, to ensure timeliness of information. Certificate status information may be issued more frequently than the issuance frequency described below. A CA shall ensure that superseded Certificate status information is removed from the PKI Repository upon posting of the latest Certificate status information. Certificate status information shall be published no later than the next scheduled update. This will facilitate the local caching of Certificate status information for off-line or remote (laptop) operation. PKI participants shall coordinate with the PKI Repositories to which they post certificate status information to reduce latency between creation and availability. The following table provides CRL issuance frequency requirements. Routine At least once every 24 hours Loss/Compromise of Private Key Within 18 hours of notification CA Compromise Immediately, but no later than within 18 hours of notification CRL issuance frequency requirements may be further constrained by applicable jurisdictional regulatory law. The CAs that issue routine CRLs less frequently than the requirement for Emergency CRL issuance (i.e.: CRL issuance for loss or compromise of key or for compromise of CA) shall meet the requirements specified above for issuing Emergency CRLs. Maximum Latency for CRLs The maximum delay between the time a device Certificate revocation request is received by a CA and the time that this revocation information is available to Relying Parties shall be no greater than 24 hours. On-line Revocation/Status Checking Availability In addition to CRLs, CAs and Relying Party client software may optionally support online status checking with OCSP. Client software using online status checking need not obtain or process CRLs. If online revocation/status checking is supported by a CA, the latency of Certificate status information distributed online by the CA or its delegated status responders shall meet or exceed the requirements for CRL issuance stated in Section REF _Ref439072061 \r \h 4.9.7.Since some relying parties may not be able to accommodate on-line communications, all CAs will be required to support CRLs.On-line Revocation Checking Requirements Relying parties client software may optionally support on-line status checking. Client software using on-line status checking need not obtain or process CRLs.Other Forms of Revocation Advertisements Available Any alternate forms used to disseminate revocation information shall be implemented in a manner consistent with the security and latency requirements for the implementation of CRLs and online revocation and status checking. Special Requirements Regarding Key Compromise In the event of compromise or suspected compromise of the CA signing key, Senior Management of the CA Operator and any Cross Certified CAs shall be immediately notified. A CRL must be issued within 19 hours of notification. The requirements of Section REF _Ref439072061 \r \h 4.9.7 also apply. Circumstances for Suspension Certificate suspension is not supported by this CP. Who can Request Suspension Certificate suspension is not supported by this CP. Procedure for Suspension Request Certificate suspension is not supported by this CP. Limits on Suspension Period Certificate suspension is not supported by this CP. Certificate Status ServicesOperational Characteristics Certificate status can be ascertained by querying the CRL maintained and published in its repository by the CA, or by querying an OCSP Responder operated by the CA, if present. Service Availability Relying Parties are bound to their obligations and the stipulations of this CP irrespective of the availability of the Certificate status service. The CRL shall be publicly available 24 hours a day, 7 days a week. Care shall be taken by the CA to ensure that the public copy is replaced atomically when it is being updated. Optional Features No specific requirement. End of SubscriptionA Device Sponsor may terminate his subscription either by allowing the device Certificate to expire without renewing or re-keying it, or by revoking the Certificate before expiry without applying for a replacement. Key Escrow and RecoveryKey Escrow and Recovery Policy and Practices Under no circumstances shall any CA, end-entity, individual, role, or organizational signature key be escrowed by a third party. Session Key Encapsulation and Recovery Policy and Practices This CP neither requires nor prohibits the capability of recovering session keys. CAs that support session key encapsulation and recovery shall identify the document describing the practices in the applicable CPS. 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.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.Site Location and ConstructionAll CA operations shall be conducted within a physically protected environment that deters, prevents, and detects unauthorized use of, access to, or disclosure of sensitive information and systems. Such environments are based in part on the establishment of physical security tiers. A tier is a barrier such as a locked door or closed gate that provides mandatory access control for individuals and requires a positive response (e.g., door unlocks or gate opens) for each individual to proceed to the next area. Each successive tier provides more restricted access and greater physical security against intrusion or unauthorized access. Moreover, each physical security tier encapsulates the next inner tier, such that an inner tier must be fully contained in an outside tier and cannot have a common outside wall with the outside tier, the outermost tier being the outside barrier of the building (e.g., a perimeter fence or outside wall).The location and construction of the facility housing the CA equipment, as well as sites housing remote workstations used to administer the CAs, shall be consistent with facilities used to house high-value, sensitive information. The site location and construction, when combined with other physical security protection mechanisms such as guards, high security locks, and intrusion sensors, shall provide robust multi-tier protection against unauthorized access to the CA equipment and records. The workstation of remote administrators of the CA shall be located such that all accesses may be monitored, and that there are reasonable expectations that it would be impossible for a determined unauthorized individual to gain access to the workstation.Physical AccessPhysical Access for CA EquipmentCA equipment shall always be protected from unauthorized access. The physical access controls for CA equipment, as well as remote workstations used to administer the CAs, shall be auditable and:Ensure that no unauthorized access to the hardware is permitted.Ensure that all removable media and paper containing sensitive plain-text information is stored in secure containers. Be manually or electronically monitored for unauthorized intrusion at all times. Ensure an access log is maintained and inspected periodically. Provide at least three layers of increasing security such as perimeter, building, and CA bunker.Require two-person physical access control to both the cryptographic module and computer systems. Removable cryptographic modules shall be deactivated prior to storage. When not in use, removable cryptographic modules and the activation information used to access or enable cryptographic modules shall be placed in secure containers. Activation data shall be either memorized or recorded and stored in a manner commensurate with the security afforded the cryptographic module, and shall not be stored with the cryptographic module or removable hardware associated with remote workstations used to administer the CA.A security check of the facility housing the CA equipment or remote workstations used to administer the CAs shall occur if the facility is to be left unattended. At a minimum, the check shall verify the following: The equipment is in a state appropriate to the current mode of operation (e.g., that cryptographic modules are in place when “open,” and secured when “closed,” and for the CA, that all equipment other than the repository is shut down). Any security containers are properly secured. Physical security systems (e.g., door locks, vent covers) are functioning properly. The area is secured against unauthorized access. A person or group of persons shall be made explicitly responsible for making such checks. When a group of persons is responsible, a log identifying the person performing a check at each instance shall be maintained. If the facility is not continuously attended, the last person to depart shall initial a sign-out sheet that indicates the date and time and asserts that all necessary physical protection mechanisms are in place and activated.Physical Access for RA EquipmentRA equipment shall be protected from unauthorized access while the RA cryptographic module is installed and activated. The RA shall implement physical access controls to reduce the risk of equipment tampering even when the cryptographic module is not installed and activated. These security mechanisms shall be commensurate with the level of threat in the RA equipment environment.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.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.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.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.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.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 REF _Ref435519863 \r \h 6.2.4.Procedural ControlsCorporate ControlsThe CA must maintain its status as a legal entity in accordance with the national law stated in Section REF _Ref437530032 \r \h \* MERGEFORMAT 9.2 The CA must maintain a system of quality assurance consistent with recognized standards for all of its Certificate management operations. The CA management structure shall ensure that they are free from any commercial, financial, or other pressures which may impact the CA’s status as an impartial and trustable entity.Trusted RolesThe CA shall ensure a separation of duties into trusted roles for critical CA functions to prevent one CA staff member from malicious using the CA system without detection. Each such trusted role’s system access is to be limited to those actions which they are required to perform in fulfilling their responsibilities.A trusted role is one whose incumbent performs functions that can introduce security problems if not carried out properly, whether accidentally or maliciously. The people selected to fill these roles must be extraordinarily responsible, or the integrity of the CA will be weakened. The functions performed in these roles form the basis of trust for the entire PKI. Two approaches are taken to increase the likelihood that these roles can be successfully carried out. The first ensures that the person filling the role is trustworthy and properly trained. The second distributes the functions among more than one person, so that any malicious activity would require collusion. The roles are defined as: Administrator Officer Auditor Operator Registration AuthorityAdministrators and operators do not issue certificates to devices. The roles required for each level of assurance are identified in Section REF _Ref440032677 \r \h 5.2.4. These five roles are employed at the CA and RA locations as appropriate. Separation of duties shall comply with REF _Ref440032729 \r \h 5.2.4, and requirements for two person control with REF _Ref440033051 \r \h 5.2.3, regardless of titles and numbers of Trusted Roles.AdministratorThe Administrator shall be responsible for:Installation, configuration, and maintenance of the CA and CSA (where applicable).Establishing and maintaining CA and CSA system accounts.Configuring certificate profiles or templates and audit parameters.Configuring CA, RA, and CSA audit parametersConfiguring CSA response profilesGenerating and backing up CA and CSA keys.Administrators do not issue certificates.OfficerThe Officer shall be responsible for issuing certificates, that is:Registering new devices and requesting the issuance of certificates.Verifying the identity of Device Sponsors and accuracy of information included in certificates.Approving and executing the issuance of certificates.Requesting, approving, and executing the revocation of certificates.Audit AdministratorThe Audit Administrator shall be responsible for:Reviewing, maintaining, and archiving audit logs.Performing or overseeing internal compliance audits to ensure that the CA, associated RA, and CSA (where applicable) is operating in accordance with the CPS.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.Registration AuthorityThe Registration Authority shall be responsible for:Verifying identity information.Entering device information and verifying correctness.Securely communicating requests to and from CA.Receiving and distributing certificate to the Device Sponsor.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 versaTwo or more persons are required for the following tasks: CA key generation; CA signing key activation; CA private key backup. Where multiparty control is required, at least one of the participants shall be an Administrator. All participants must serve in a trusted role as defined in Section REF _Ref440033265 \r \h 5.2.2. Multiparty control shall not be achieved using personnel that serve in the Auditor trusted role.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.Roles Requiring Separation of DutiesIndividuals may only assume one of the following roles: Officer, Administrator, and Auditor, but any individual may assume the Operator role. The CA and RA software and hardware shall identify and authenticate its users and shall ensure that no user identity can assume both the Administrator and Officer roles, assume both the Administrator and Auditor roles, or assume both the Auditor and Officer roles. No individual in a trusted role shall have more than one identity.Role separation, when required as mentioned above, may be enforced by either the CA equipment, or procedurally, or by both means.Personnel ControlsQualifications, Experience, and Clearance RequirementsCAs shall require that personnel assigned to trusted roles have the requisite background, qualifications, and experience or be provided the training needed to perform their prospective job responsibilities competently and satisfactorily. The requirements governing the qualifications, selection and oversight of individuals who operate, manage, oversee, and audit the CA shall be set forth in the CPS.All persons filling trusted roles shall be selected on the basis of loyalty, trustworthiness, and integrity, and shall be subject to a background investigation. Personnel appointed to trusted roles shall:Possess the expert knowledge, experience and qualifications necessary for the offered services and appropriate job function.Have successfully completed an appropriate training program.Have demonstrated the ability to perform their duties.Be trustworthy.Have no other duties that would interfere or conflict with their duties for the trusted role.Have not been previously relieved of duties for reasons of negligence or non-performance of duties.Have not been convicted of a serious crime or other offense which affects his/her suitability for the position.Been appointed in writing by the CA management.For CAs issuing medium-assurance certificates each person filling a trusted role shall satisfy at least one of the following requirements:The person shall be a citizen of the country where the CA is located; orFor CAs operated on behalf of multinational government organizations, the person shall be a citizen of one of the member countries; orFor CAs located within the European Union, the person shall be a citizen of one of the member states of the European Union; orThe person shall have a security clearance equivalent to U.S. Secret or higher issued by a NATO member nation or major non-NATO ally as defined by the International Traffic in Arms Regulation (ITAR) – 22 CFR 120.32.For RAs and Trusted Agents, in addition to the above, the person may be a citizen of the country where the function is located.Background Check ProceduresAll persons filling trusted roles (including CA trusted roles and RA role) shall, at a minimum, pass a background investigation covering the following areas: Confirmation of previous employment; Confirmation of the highest or most relevant educational degree; Place of residence; Search of criminal records; Check of references;Check of credit/financial records.The period of investigation must cover at least the last five years for each area, except the residence check which must cover at least the last three years. Regardless of the date of award, the highest educational degree shall be verified.Factors revealed in a background check that may be considered grounds for rejecting candidates for Trusted Positions or for taking action against an existing Trusted Person may include but is not limited to the following:Misrepresentations made by the candidate or Trusted PersonHighly unfavorable or unreliable personal referencesCertain criminal convictionsIndications of a lack of financial responsibility Training RequirementsAll personnel performing duties with respect to the operation of the CA or RA shall receive comprehensive training. Training shall be conducted in the following areas:CA (or RA) security principles and mechanisms;All PKI software versions in use on the CA (or RA) system;All PKI duties they are expected to perform;Disaster recovery and business continuity procedures; andStipulations of this policy.Retraining Frequency and RequirementsAll individuals responsible for PKI roles shall be made aware of changes in the CA or RA operation. Any significant change to the operations shall have a training (awareness) plan, and the execution of such plan shall be documented. Examples of such changes are CA software or hardware upgrade, changes in automated security systems, and relocation of equipment.Documentation shall be maintained identifying all personnel who received training and the level of training completed.Job Rotation Frequency and SequenceNo stipulation.Sanctions for Unauthorized ActionsThe CA shall take appropriate administrative and disciplinary actions against personnel who have performed actions involving the CA or its RA that are not authorized in this CP, CPSs, or other published procedures.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.Documentation Supplied to PersonnelThe CA shall make available to its personnel the CP they support, the CPS, and any relevant statues, policies, or contracts. Other technical, operations, and administrative documents (e.g.: Administrator Manual, User Manual, etc.) shall be provided in order for the trusted personnel to perform their duties.Audit Logging ProceduresAudit log files shall be generated for all events relating to the security of the CAs and RAs. Where possible, the security audit logs shall be automatically collected. Where this is not possible, a logbook, paper form, or other physical mechanism shall be used. All security audit logs, both electronic and non-electronic, shall be retained and made available during compliance audits. The security audit logs for each auditable event defined in this section shall be maintained in accordance with Section 5.5.2.Types of Events RecordedAll security auditing capabilities of the CA and RA operating system and the CA and RA applications required by this CP shall be enabled during installation. At a minimum, each audit record shall include the following (either recorded automatically or manually for each auditable event): The type of event; The date and time the event occurred; A success or failure indicator when executing the CA’s signing process; A success or failure indicator when performing certificate revocation; and The identity of the entity and/or operator that caused the event. A message from any source requesting an action by the CA is an auditable event; the corresponding audit record must also include message date and time, source, destination, and contents. The CA/RA shall record the events identified in the list below. Where these events cannot be electronically logged, the CA/RA shall supplement electronic audit logs with physical logs as necessary. Auditable EventCACSARASECURITY AUDITAny changes to the Audit parameters, e.g., audit frequency, type of event auditedXXXAny attempt to delete or modify the Audit logsXXXIDENTIFICATION AND AUTHENTICATIONSuccessful and unsuccessful attempts to assume a role XXXThe value of maximum authentication attempts is changed XXXThe number of unsuccessful authentication attempts exceeds the maximum authentication attempts during user login XXXAn Administrator unlocks an account that has been locked as a result of unsuccessful authentication attempts XXXAn Administrator changes the type of authentication, e.g., from a password to biometricXXXLOCAL DATA ENTRYAll security-relevant data that is entered in the system XXXREMOTE DATA ENTRYAll security-relevant messages that are received by the system XXXDATA EXPORT AND OUTPUTAll successful and unsuccessful requests for confidential and security-relevant information XXXKEY GENERATIONWhenever the device generates a key. (Not mandatory for single session or one-time use symmetric keys) XXXPRIVATE KEY LOAD AND STORAGEThe loading of device private keys XXXAll access to certificate subject private keys retained within the CA for key recovery purposes XN/AN/ATRUSTED PUBLIC KEY ENTRY, DELETION AND STORAGEAll changes to the trusted public keys, including additions and deletions XXXSECRET KEY STORAGEThe manual entry of secret keys used for authentication XXXPRIVATE AND SECRET KEY EXPORTThe export of private and secret keys (keys used for a single session or message are excluded) XXXCERTIFICATE REGISTRATIONAll certificate requests XN/AXCERTIFICATE REVOCATIONAll certificate revocation requests XN/AXCERTIFICATE STATUS CHANGE APPROVALThe approval or rejection of a certificate status change request XN/AN/ACA CONFIGURATIONAny security-relevant changes to the configuration of the componentXXXACCOUNT ADMINISTRATIONRoles and users are added or deleted X--The access control privileges of a user account or a role are modified X--CERTIFICATE PROFILE MANAGEMENTAll changes to the certificate profile XN/AN/ACERTIFICATE STATUS AUTHORITY MANAGEMENTAll Changes to the CSA profile (e.g. OCSP Profile)N/AXN/AREVOCATION PROFILE MANAGEMENTAll changes to the revocation profile XN/AN/ACERTIFICATE REVOCATION LIST PROFILE MANAGEMENTAll changes to the Certificate Revocation List profile XN/AN/AMISCELLANEOUSAppointment of an individual to a trusted role XXXDesignation of personnel for multiparty control X-N/AInstallation of the operating system XXXInstallation of the PKI Application XXXInstalling hardware cryptographic modules XXXRemoving hardware cryptographic modules XXXDestruction of cryptographic modules XXXSystem startup XXXLogon attempts to PKI applications XXXReceipt of hardware / software XXXAttempts to set passwords XXXAttempts to modify passwords XXXBacking up CA internal database X--Restoration from backup of the internal CA databaseX--File manipulation (e.g., creation, renaming, moving) X--Posting of any material to a PKI repository X--Access to CA internal database XX-All certificate compromise notification requests XN/AXRe-key of the Component XXXConfiguration changesHardware XX-SoftwareXXXOperating system XXXPatches XX-Security profiles XXXPHYSICAL ACCESS / SITE SECURITYPersonnel access to room housing Component X--Access to the Component XX-Known or suspected violations of physical security XXXANOMALIESSoftware error conditions XXXSoftware check integrity failures XXXReceipt of improper messages XXXMisrouted messages XXXNetwork attacks (suspected or confirmed) XXXEquipment failure X--Electrical power outages X--Uninterruptible Power Supply (UPS) failureX--Obvious and significant network service or access failureX--Violations of Certificate PolicyXXXViolations of Certificate Practice StatementXXXResetting Operating System ClockXXXFrequency of Processing LogAudit logs shall be reviewed at least once every 30 days, unless the CA is off-line, in which case the audit logs shall be reviewed when the system is activated or every 30 days, whichever is later. Statistically significant samples of security audit data generated by the CA, CSA, or RA since the last review shall be examined (where the confidence intervals for each category of security audit data are determined by the security ramifications of the category and the availability of tools to perform such a review), as well as a reasonable search for evidence of malicious activity. The Audit Administrator shall explain all significant events in an audit log summary. Actions taken as a result of these reviews shall be documented.Such reviews involve verifying that the log has not been tampered with, there is no discontinuity or other loss of audit data, and then briefly inspecting all log entries, with a more thorough investigation of any alerts or irregularities in the logs. Retention Period for Audit LogAudit logs shall be retained onsite for at least sixty days and must be retained in the manner described below. For the CA and CSA, the Audit Administrator shall be the only person managing the audit log (e.g., review, backup, rotate, delete, etc.). For the RA, a system administrator other than the RA shall be responsible for managing the audit log.Protection of Audit LogsSystem configuration and operational procedures shall be implemented together to ensure that:Only authorized people have read access to the logs;Only authorized people may archive audit logs; andAudit logs are not modified.The person performing audit log archive need not have modify access, but procedures must be implemented to protect archived data from destruction prior to the end of the audit log retention period (note that deletion requires modification access). Audit logs shall be moved to a safe, secure storage location separate from the CA equipment.It is acceptable for the system to over-write audit logs after they have been backed up and archived.Audit Log Backup ProceduresAudit logs and audit summaries shall be backed up at least monthly, unless the CA is offline, in which case audit logs and audit summaries shall be backed up when the system is activated or every 30 days, whichever is later. A copy of the audit log shall be sent off-site in accordance with the CPS following review.Audit Collection System (Internal vs. External)The audit log collection system may or may not be external to the CA, CSA, or RA system. Automated audit processes shall be invoked at system or application startup, and cease only at system or application shutdown. Should it become apparent that an automated audit system has failed, and the integrity of the system or confidentiality of the information protected by the system is at risk, then the CA shall determine whether to suspend CA operation until the problem is remedied.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.Vulnerability AssessmentsNo stipulation beyond Section REF _Ref440366527 \r \h 5.4.2.Records ArchivalTypes of Events ArchivedCA, CSA, and RA archive records shall be sufficiently detailed to determine the proper operation of the PKI and the validity of any certificate (including those revoked or expired) issued by the CA. At a minimum, the following data shall be recorded for archive:Data To Be ArchivedCACSARACertificate Policy XXXCertification Practice Statement XXXContractual obligations XXXSystem and equipment configuration XX-Modifications and updates to system or configuration XX-Certificate requests X--All certificates issued and/or published XN/AN/ARecord of Component re-key XXXRevocation requests X--Device Sponsor identity authentication data as per section 3.2.3.XN/AXDocumentation of receipt and acceptance of certificatesXN/AXSubscriber Agreements XN/AXDocumentation of receipt of tokens XN/AXAll CRLs issued and/or published XN/AN/AAll Audit logsXXXOther data or applications to verify archive contents XXXCompliance Auditor reports XXXRetention Period for ArchiveArchive records must be kept for a minimum of 10 years and 6 months, or as further required by applicable law or industry regulation.If the original media cannot retain the data for the required period, a mechanism to periodically transfer the archived data to new media shall be defined by the archive site. Alternatively, an Entity may retain data using whatever procedures have been approved by U.S. National Archives and Records Administration for that category of documents. Applications required to process the archive data shall also be maintained for the minimum retention period specified above.Protection of ArchiveThe archive must be protected as specified by the privacy laws of the country where the device information was collected.No unauthorized user shall be permitted to write to, modify, or delete the archive. For the CA and CSA, the authorized individuals are Audit Administrators. For the RA, authorized individuals are someone other than the RA (e.g.: Information Assurance Officer or IAO). The contents of the archive shall not be released except as determined by the CA, or as required by law. Records of individual transactions may be released upon request of any Device Sponsors involved in the transaction or their legally recognized agents. Archive media shall be stored in a safe, secure storage facility separate from the PKI components (CA, CSA, or RA) with physical and procedural security controls equivalent or better than those for the PKI. Archive Backup ProceduresThe CPS or a referenced document shall describe how archive records are backed up, and how the archive backups are managed.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.Procedures to Obtain and Verify Archive InformationProcedures, detailing how to create, verify, package, transmit, and store archive information, shall be described in the applicable CPS.Key ChangeoverNo specific Requirement Compromise and disaster recoveryIncident and Compromise Handling ProceduresEach organization operating an Entity PKI shall have a formal disaster recovery plan.If a CA or CSA detects a potential hacking attempt or other form of compromise, it shall perform an investigation in order to determine the nature and the degree of damage. If the CA or CSA key is suspected of compromise, the procedures outlined in Section REF _Ref440369012 \r \h 5.7.4 shall be followed.The APPA shall be notified if any CAs operating under this policy experiences the following:suspected or detected compromise of the CA systems;physical or electronic penetration of CA systems;successful denial of service attacks on CA components; orany incident preventing the CA from issuing a CRL within 48 hours of the issuance of the previous CRL.The APPA will take appropriate steps to protect the integrity of the PKI.The CA’s Management Authority shall reestablish operational capabilities as quickly as possible in accordance with procedures set forth in the CA's puting 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 REF _Ref435707906 \r \h 4.9. If the CA signature keys are destroyed, CA operation shall be reestablished as quickly as possible, giving priority to the generation of a new CA key pair.If a CA cannot issue a CRL prior to the time specified in the next update field of its currently valid CRL, then all CAs that have been issued certificates by the CA shall be securely notified immediately. This will allow other CAs to protect their Device Sponsors’ interests as Relying Parties.If the ability to revoke certificates is inoperative or damaged, the CA shall reestablish revocation capabilities as quickly as possible in accordance with procedures set forth in the respective CPS. If the CA’s revocation capability cannot be established in a reasonable time-frame, the CA shall determine whether to request revocation of its certificate(s). If the CA is a Root CA, the CA shall determine whether to notify all Device Sponsors whose devices use the CA as a trust anchor to delete the trust anchor.Private Key Compromise ProceduresIf a CA’s signature keys are compromised, lost, or suspected of compromise:All cross certificated CAs shall be securely notified at the earliest feasible time (so that entities may issue CRLs revoking any cross-certificates issued to the CA);A new CA key pair shall be generated by the CA in accordance with procedures set forth in the applicable CPS;New CA certificates shall be requested in accordance with the initial registration process described elsewhere in this CP;If the CA can obtain accurate information on the certificates it has issued and that are still valid (i.e. not expired or revoked), the CA may re-issue (i.e., renew) those certificates with the notAfter date in the certificate remaining the same as in original certificates; andIf the CA is a Root CA, it shall provide the Device Sponsors the new trust anchor using secure means.The APPA shall also investigate what caused the compromise or loss, and what measures must be taken to preclude recurrence.If a CSA key is compromised, all certificates issued to the CSA shall be revoked, if applicable. The CSA will generate a new key pair and request new certificate(s), if applicable. If the CSA is a trust anchor, the relying parties will be provided the new trust anchor in a secure manner (so that the trust anchor integrity is maintained) to replace the compromised trust anchor.If RA signature keys are compromised, lost, or suspected of compromise:The RA certificate shall be revoked immediately;The new RA key pair shall be generated in accordance with procedures set forth in the applicable CPS;A new RA certificate shall be requested in accordance with the initial registration process described elsewhere in this CP;All certificate registration requests approved by the RA since the date of the suspected compromise shall be reviewed to determine which are legitimate;For those certificate requests or approval whose legitimacy cannot be ascertained, the resultant certificates shall be revoked and their subjects (Device Sponsor’s) shall be notified of revocation.Business Continuity Capabilities after a DisasterThe CA Operator shall provide an alternate secure facility that conforms to all the provisions of the present document for resumption of the CA following any CA service interruption.CA, CSA, or RA TerminationWhen a CA operating under this policy terminates operations before all certificates have expired, the CA signing keys shall be surrendered to the APPA. Prior to CA termination, the CA shall provide archived data to an archive facility as specified in the CPS. As soon as possible, the CA will advise all other organizations to which it has issued certificates of its termination, using an agreed-upon method of communication specified in the CPS. TECHNICAL SECURITY CONTROLSKey Pair Generation and InstallationKey Pair GenerationKey pair generation shall be performed using FIPS 140 rated cryptographic modules and processes that provide the required cryptographic strength of the generated keys and prevent the loss, disclosure, modification, or unauthorized use of private keys. The following table provides the requirements for key pair generation for the various entities:EntityFIPS 140-1/2 LevelHardwareOrSoftwareKey Storage Restricted To the Module on Which the Key Was GeneratedRoot CA3HardwareYesCA2HardwareYesRA2HardwareYesCSA2HardwareYesDevice1SoftwareNo RequirementRandom numbers for medium-hardware assurance level keys shall be generated in FIPS 140 Level 2 approved hardware cryptographic modules.When private keys are not generated on the token to be used, originally generated private keys shall be destroyed after they have been transferred to the token. This does not prohibit the key generating modules to act as the key escrow module as well.CA Key Pair GenerationCA keys shall be generated in a Key Generation Ceremony using multi-person control for CA key pair generation, as specified in CP section 6.2.2. CA key pair generation must create a verifiable audit trail showing that the security requirements for procedures were followed. The documentation of the procedure must be detailed enough to show that appropriate role separation was used. An independent third party shall validate the execution of the key generation procedures either by witnessing the key generation or by examining the signed and documented record of the key generation.Device Key Pair GenerationDevice key pair generation may be performed by the device, CA, or RA. If the CA or RA generates device key pairs, the requirements for key pair delivery specified in section REF _Ref435107078 \r \h \* MERGEFORMAT 6.1.2 must also be met.Private Key Delivery to DevicesA CA shall generate its own key pair and therefore does not need private key delivery.Device key pair generation may be performed by the device. In this case, the private key delivery to a device is unnecessary.When a CA or RA generates key pairs on behalf of a device, the private keys must be delivered securely to the device and the following requirements must be met:Anyone who generates a private signing key for a device shall not retain any copy of the key after delivery of the private key to the device.The private key shall be protected from activation, compromise, or modification during the delivery process.The Device Sponsor shall acknowledge receipt of the private key(s).Delivery shall be accomplished in a way that ensures that the certificates and associated private keys are provided to the correct devices. For hardware cryptographic modules, accountability for the location and state of the module must be maintained until the device accepts possession of it. For electronic delivery of private keys, the key material shall be encrypted using a cryptographic algorithm and key size at least as strong as the private key. Activation data shall be delivered using a separate secure channel. The CA or the RA shall maintain a record of the Device Sponsor acknowledgement of receipt of the token.Public Key Delivery to Certificate IssuerWhere key pairs are generated by the device or RA, the public key and the device’s identity shall be delivered securely to the CA for certificate issuance. The delivery mechanism shall bind the device’s verified identity to the public key. If cryptography is used to achieve this binding, it shall be at least as strong as the CA keys used to sign the certificate.CA Public Key Delivery to Relying PartiesThe public key of a trust anchor shall be provided to the devices acting as relying parties in a secure manner so that the trust anchor is not vulnerable to modification or substitution. Acceptable methods for delivery of a trust anchor include but are not limited to: Loading a trust anchor onto tokens delivered to relying parties via secure mechanisms.Secure distribution of trust anchor through secure out-of-band parison of Certificate hash (fingerprint) against the trust anchor hash made available via authenticated out-of-band sources (note that fingerprints or hashes posted in-band along with the Certificate are not acceptable as an authentication mechanism.Downloading a trust anchor from trusted web sites (CA or PKI-PA web site) secured with a currently valid Certificate of equal or greater assurance level than the Certificate being downloaded and the trust anchor is not in the certification chain for the web site Certificate.Systems using cryptographic hardware tokens shall store trusted certificates such that unauthorized alteration or replacement is readily detectable.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 SizeRoot CASub-CADevice CertDigest AlgorithmSHA-256SHA-256SHA-256Elliptic Curve CryptographyP-256, 384P-256, 384P-256Public Key Parameters Generation and Quality CheckingElliptic Curve Cryptography (ECC) keys shall be generated in accordance with FIPS 186-2, and curves from FIPS 186-2 shall be used.Key Usage Purposes (as per X.509 v3 Key Usage Field)The use of a specific key is constrained by the keyUsage extension in the X.509 certificate. Public keys that are bound into CA certificates shall be used for signing certificates and status information (e.g., CRLs). REF _Ref346811484 \h 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 extensionShall set the criticality of the keyUsage extension to TRUEShall assert the keyCertSign bit and the cRLSign bit in the key usage extensionTable 2: keyUsage Extension for all CA certificatesFieldFormatCriticalityValueCommentkeyUsageBIT STRINGTRUE{ id-ce 15 }Included in all CA certificates digitalSignature(0)0Not Set nonRepudiation(1)0Not Set keyEncipherment(2)0 Not Set dataEncipherment(3)0 Not Set keyAgreement(4)0 Not Set keyCertSign(5)1Set cRLSign(6)1Set encipherOnly(7)0Not Set decipherOnly(8)0Not Set REF _Ref443032745 \h Table 3 shows the specific keyUsage extension settings for AeroMACS Device and Sserver certificates and specifies that all Device and Sserver certificates: Shall include a keyUsage extensionShall set the criticality of the keyUsage extension to TRUEShall assert the digitalSignature bitShall assert the keyAgreement bitTable 3: keyUsage Extension for all Device CertificatesFieldFormatCriticalityValueCommentkeyUsageBIT STRINGTRUE{ id-ce 15 }Included in all Server certificates digitalSignature(0)1Set nonRepudiation(1)0 Not Set keyEncipherment(2)0Not Set dataEncipherment(3)0 Not Set keyAgreement(4)1Set keyCertSign(5)0Not Set cRLSign(6)0Not Set encipherOnly(7)0Not Set decipherOnly(8)0Not SetThe dataEncipherment, encipherOnly, and decipherOnly bits shall not be asserted in certificates issued under this policy.Private Key Protection and Cryptographic Module Engineering ControlsCryptographic Module Standards and ControlsPrivate keys within the AeroMACS PKI shall be protected using Trustworthy Systems. Private Key holders shall take necessary precautions to prevent the loss, disclosure, modification, or unauthorized use of such Private Keys in accordance with this CP and contractual obligations specified in the appropriate AeroMACS Agreement.The relevant standard for cryptographic modules is Security Requirements for Cryptographic Modules [FIPS 140-2]. The table in Section REF _Ref438647731 \r \h 6.1.1 summarizes the minimum requirements for cryptographic modules; higher levels may be used. In addition, private keys shall not exist outside the cryptographic module in plaintext form.Private Key (n out of m) Multi-Person ControlA single person shall not be permitted to activate or access any cryptographic module that contains the complete CA private signing key. CA signature keys may be backed up only under two-person control. Access to CA signing keys backed up for disaster recovery shall be under at least two-person control. The names of the parties used for two-person control shall be maintained on a list that shall be made available for inspection during compliance audits.Private Key EscrowCA private signature keys and Device private signatures keys shall not be escrowed.If the CA retains the device private encryption keys for business continuity purposes, the CA shall escrow such keys to protect them from unauthorized modification or disclosure through physical and cryptographic means.Private Key BackupThe CA private signature keys shall be backed up under the same multi-person control as the original signature key. At least one copy of the private signature key shall be stored off-site. All copies of the CA private signature key shall be accounted for and protected in the same manner as the original. Backup procedures shall be included in the CA’s CPS.Device private keys may be backed up or copied, but must be held under the control of the device’s human sponsor or other authorized administrator. Backed up device private keys shall not be stored in plaintext form outside the cryptographic module. Storage must ensure security controls consistent with the protection provided by the device’s cryptographic module.Private Key ArchivalCA private signature keys and device private signatures keys shall not be archived. Upon expiration of a CA Certificate, the key pair associated with the certificate will be securely retained for a period of at least 5 years using hardware cryptographic modules that meet the requirements of this CP. These CA key pairs shall not be used for any signing events after the expiration date of the corresponding CA Certificate, unless the CA Certificate has been renewed in terms of this CP.For some applications (e.g. protected aircraft to ground communications), the device key may be archived, upon crypto-period expiration and/or key replacement, to support recovery of protected messages, as necessary to comply with regulatory requirements regarding data retention.Private Key Transfer into or from a Cryptographic ModuleCA private keys may be exported from the cryptographic module only to perform CA key backup procedures as described in CP section 6.2.4. At no time shall the CA private key exist in plaintext outside the cryptographic module.All other keys shall be generated by and in a cryptographic module. In the event that a private key is to be transported from one cryptographic module to another, the private key must be encrypted during transport; private keys must never exist in plaintext form outside the cryptographic module boundary. Private or symmetric keys used to encrypt other private keys for transport must be protected from disclosure.Entry of a private key into a cryptographic module shall use mechanisms to prevent loss, theft, modification, unauthorized disclosure, or unauthorized use of such private key. Private Key Storage on Cryptographic ModuleNo stipulation beyond that specified in FIPS 140.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 ActivationMethod 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 KeyOnce 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 KeysAn online CA’s private key shall be activated by a threshold number of Shareholders, as defined in CP section 6.2.2, supplying their activation data (stored on secure media). Once the private key is activated, the private key may be active for an indefinite period until it is deactivated when the CA goes offline.Device Private KeysA 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.Method of Deactivating Private KeyCryptographic modules that have been activated shall not be available to unauthorized access. After use, the cryptographic module shall be deactivated, e.g., via a manual logout procedure or automatically after a period of inactivity. CA cryptographic modules shall be stored securely when not in use.When an online CA is taken offline, the CA shall remove the token containing the private key from the reader in order to deactivate it.With respect to the private keys of offline CAs, after the completion of a Key Generation Ceremony, in which such private keys are used for private key operations, the CA shall remove the token containing the private keys from the reader in order to deactivate them. Once removed from the reader, tokens shall be securely stored.When deactivated, private keys shall be kept in encrypted form only. They shall be cleared from memory before the memory is de-allocated. Any disk space where Private Keys were stored shall be overwritten before the space is released to the operating system. Method of Destroying Private KeyPrivate signature keys shall be destroyed when they are no longer needed, or when the certificates to which they correspond expire or are revoked. For software cryptographic modules, this can be accomplished by overwriting the data. For hardware cryptographic modules, this will usually require a “zeroize” command. Physical destruction of hardware is generally not required.Cryptographic Module RatingSee CP section 6.2.1.Other Aspects of Key Pair ManagementPublic Key ArchivalThe public key is archived as part of the certificate archival. The issuing CA shall retain all verification public keys for a minimum of twenty (20) years or as further required by applicable law or industry regulation.Certificate Operational Periods and Key Pair Usage PeriodsThe following table provides the life times for the private keys and certificates issued to the owner of the private key.KeyPrivate KeyCertificateSelf-signed Root CA30 Years30 YearsCA20 Years20 YearsCSA10 Years10 YearsDevice3-5 Years3-5 YearsServer1 Year1 YearValidity periods shall be nested such that the validity periods of issued certificates shall be contained within the validity period of the issuing CA.AeroMACS PKI Participants shall cease all use of their key pairs after their validity periods have expired.Cross certificates shall not be valid for more than 10 years.Activation dataActivation Data Generation and InstallationThe activation data used to unlock private keys, in conjunction with any other access control, shall have an appropriate level of strength for the keys or data to be protected and shall meet the applicable security policy requirements of the cryptographic module used to store the keys. RA and device activation data may be user-selected. The strength of the activation data shall meet or exceed the requirements for authentication mechanisms stipulated for Level 2 in FIPS 140-2. For CAs, it shall either entail the use of biometric data or satisfy the policy-enforced at/by the cryptographic module. If the activation data must be transmitted, it shall be via an appropriate protected channel, and distinct in time and place from the associated cryptographic module.To the extent passwords are used as activation data, CAs activation participants shall generate passwords that cannot easily be guessed or cracked by dictionary attacks. Participants may not need to generate activation data, for example if they use biometric access devices. These passwords shall be changed upon CA re-key. Activation Data ProtectionData used to unlock private keys shall be protected from disclosure by a combination of cryptographic and physical access control mechanisms. Activation data should be either biometric in nature or memorized. If written down, it shall be secured at the level of the data that the associated cryptographic module is used to protect, and shall not be stored with the cryptographic module. In all cases, the protection mechanism shall include a facility to temporarily lock the account, or terminate the application, after a predetermined number of failed login attempts as set forth in the respective CP or CPS.Other Aspects of Activation DataCAs, CSAs, and RAs shall change the activation data whenever the token is re-keyed or returned for puter security controlsSpecific Computer Security Technical RequirementsThe following computer security functions may be provided by the operating system, or through a combination of operating system, software, and physical safeguards. The CA, CSA and RA shall include the following functionality:Require authenticated loginsProvide Discretionary Access Control, including managing privileges of users to limit users to their assigned rolesProvide a security audit capability (See Section REF _Ref443037714 \r \h 5.4)Prohibit object re-useRequire use of cryptography for session communication and database securityRequire a trusted path for identification and authenticationProvide domain isolation for processesProvide self-protection for the operating systemRequire self-test security related CA services (e.g., check the integrity of the audit logs)Support recovery from key or system failureThe computer system shall be configured with the minimum of the required accounts and network services, and shall not permit remote login.The computer system hosting the CA must have been hardened against all known puter Security RatingNo Stipulation.Life Cycle Technical ControlsSystem Development ControlsThe system development controls for the CA and CSA are as follows: Use software that has been designed and developed under a formal, documented development methodology. Procured hardware and software shall be purchased in a fashion to reduce the likelihood that any particular component was tampered with (e.g., by ensuring the equipment was randomly selected at time of purchase). Specially-developed hardware and software shall be developed in a controlled environment, and the development process shall be defined and documented. This requirement does not apply to commercial off-the-shelf hardware or software. All hardware must be shipped or delivered via controlled methods that provide a continuous chain of accountability from the purchase location to the operations location. The hardware and software shall be dedicated to performing PKI activities. There shall be no other applications; hardware devices, network connections, or component software installed which is not part of the PKI operation. Proper care shall be taken to prevent malicious software from being loaded onto the equipment. Applications required to perform PKI operations shall be obtained from sources authorized by local policy. CA, CSA, and RA hardware and software shall be scanned for malicious code on first use and periodically thereafter. Hardware and software updates shall be purchased or developed in the same manner as original equipment, and shall be installed by trusted and trained personnel in a defined manner. Security Management ControlsThe configuration of the CA and CSA system, in addition to any modifications and upgrades, shall be documented and controlled. The CA and CSA software, when first loaded, shall be verified as being that supplied from the vendor, with no modifications, and be the version intended for use. The CA and CSA system shall provide a mechanism to periodically verify the integrity of the software as specified in the CPS.The CA shall also have mechanisms and policies in place to control and monitor the configuration of the CA system.Life Cycle Security ControlsNo work Security ControlsCAs, CSAs, and RAs shall employ appropriate security measures to ensure they are guarded against denial of service and intrusion attacks. Such measures shall include the use of guards, firewalls and filtering routers. Unused network ports and services shall be turned off. Any network software present shall be necessary to the functioning of the Entity CA. Any boundary control devices used to protect the network on which the PKI equipment is hosted shall deny all but the necessary services to the PKI equipment even if those services are enabled for other devices on the network.Time-StampingAll CA and CSA components shall regularly synchronize with a time service such as National Institute of Standards and Technology (NIST) Atomic Clock or NIST Network Time Protocol (NTP) Service. Time derived from the time service shall be used for establishing the time of:Initial validity type of a Device’s Certificate;Revocation of a Device’s CertificatePosting of CRL updates; andOCSP or other CSA responses.Certificates, CRLs, and other revocation database entries shall contain time and date information. Asserted times shall be accurate to within three minutes. Electronic or manual procedures may be used to maintain system time. Clock adjustments are auditable events (see CP section REF _Ref443039188 \r \h 5.4.1).CERTIFICATE, CRL, AND OCSP PROFILESCertificate 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 REF _Ref443047796 \h Table 4).Table 4: Certificate Profile Basic FieldsField[RFC5280] SectionRequirement or RecommendationtbsCertificate4.1.1.1Follows [RFC 5280] guidance version4.1.2.1See CP section 7.1.1. serialNumber4.1.2.2Shall be a unique positive integer assigned by the CA and shall not be longer than 20 octets. signature4.1.2.3See CP section 7.1.3. issuer4.1.2.4See CP section 7.1.4. validity4.1.2.5See CP section 6.3.2. subject4.1.2.6See CP section 7.1.4. subjectPublicKeyInfo4.1.2.7See CP section REF _Ref347304850 \r \h \* MERGEFORMAT 1.1.1. extensions4.1.2.9See CP section 7.1.2.signatureAlgorithm4.1.1.2Follows [RFC 5280] guidance algorithmIdentifier4.1.1.2 algorithm4.1.1.2See CP section 7.1.3. parameters4.1.1.2See CP section 7.1.3.signatureValue4.1.1.3Follows [RFC 5280] guidanceVersion 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.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. REF _Ref435449424 \h Table 5 shows the certificate extensions for all AeroMACS Root CA certificates.Table 5: Root CA Certificate Standard ExtensionsFieldReferenced StandardSectionRequirement or RecommendationsubjectKeyIdentifier[RFC 5280]4.2.1.2See REF _Ref435449226 \h Table 9.keyUsage[RFC 5280]4.2.1.3See CP section REF _Ref347333115 \r \h \* MERGEFORMAT 6.1.7. certificatePolicies[RFC 5280]4.2.1.4(Optional Extension) See CP section REF _Ref347333450 \r \h \* MERGEFORMAT 1.1.4.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.9See REF _Ref435449240 \h Table 10. REF _Ref435449433 \h Table 6 shows the certificate extensions for all AeroMACS CA certificates.Table 6: CA Certificate Standard ExtensionsFieldReferenced StandardSectionRequirement or RecommendationauthorityKeyIdentifier[RFC 5280]4.2.1.1Shall be included in CA certificates.Criticality shall be set to FALSE.subjectKeyIdentifier[RFC 5280]4.2.1.2See REF _Ref435449226 \h Table 9.keyUsage[RFC 5280]4.2.1.3See CP section REF _Ref347385422 \r \h \* MERGEFORMAT 6.1.7. certificatePolicies[RFC 5280]4.2.1.4See CP section REF _Ref347385441 \r \h \* MERGEFORMAT 1.1.4.subjectAlternativeName[RFC 5280]4.2.1.6(Optional Extension) May be included in CA certificates.Criticality shall be set to FALSE.basicConstraints[RFC 5280]4.2.1.9See REF _Ref435449252 \h Table 11.crlDistributionPoints[RFC 5280]This extension must appear in all CA certificates and must contain at least one URI either HTTP or LDAP. The reasons and cRLIssuer Fields must be omitted. REF _Ref435449446 \h Table 7 shows the certificate extensions for all AeroMACS device certificates.Table 7: Device Certificate Standard ExtensionsFieldReferenced StandardSectionRequirement or RecommendationauthorityKeyIdentifier[RFC 5280]4.2.1.1Shall be included in Device certificates.Criticality shall be set to FALSE.keyUsage[RFC 5280]4.2.1.3See CP section REF _Ref347385422 \r \h 6.1.7. certificatePolicies[RFC 5280]4.2.1.4See CP section REF _Ref347385441 \r \h 1.1.4.subjectAltName[RFC 5280]4.2.1.6Set 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 REF _Ref435449308 \h Table 12 for server certificates.See REF _Ref435449315 \h Table 13 for device certificates.. REF _Ref435449315 \h REF _Ref434911848 \h Table 8 shows the certificate extensions for all AeroMACS OCSP server certificates.Table 8: OCSP Certificate Standard ExtensionsFieldReferenced StandardSectionRequirement or RecommendationauthorityKeyIdentifier[RFC 5280]4.2.1.1Shall be included in OCSP certificates.Criticality shall be set to FALSE.keyUsage[RFC 5280]4.2.1.3Only the digitalSignature bit shall be set. Criticality shall be set to TRUE. certificatePolicies[RFC 5280]4.2.1.4See CP section REF _Ref347385441 \r \h 1.1.4.subjectAltName[RFC 5280]4.2.1.6Shall be set to either the DNS name or the IP address of the subject. Criticality shall be set to FALSE.Subject Key Identifier Extension REF _Ref435449226 \h Table 9 shows the subjectKeyIdentifier extension settings for AeroMACS CA certificates and specifies that all AeroMACS Root and CA certificates: Shall include the subjectKeyIdentifier extensionShall set the criticality of the subjectKeyIdentifier extension to FALSEShall calculate the keyIdentifier of the subjectKeyIdentifier per Method 1Table 9: subjectKeyIdentifier Extension for AeroMACS CA CertificatesFieldFormatCriticalityValueCommentsubjectKeyIdentifier FALSE{ id-ce 14 }Included in all CA certificates keyIdentifierOCTET STRING <key identifier>Calculated per Method 1.Device Certificates shall not include the subjectKeyIdentifier extension.Basic Constraints Extension REF _Ref435449240 \h Table 10 shows the basicConstraints extension settings for AeroMACS Root CA certificates and specifies that all AeroMACS Root CA certificates: Shall include the basicConstraints extensionShall set the criticality of the basicConstraints extension to TRUEShall set the cA field of the basicConstraints extension to TRUETable 10: basicConstraints Extension for AeroMACS Root CA CertificatesFieldFormatCriticalityValueCommentbasicConstraintsTRUE{ id-ce 19 }Included in all Root certificates cABOOLEANTRUESet pathLenConstraintINTEGERNot Set REF _Ref435449252 \h Table 11 shows the basicConstraints extension settings for AeroMACS CA certificates and specifies that all AeroMACS CA certificates:Shall include the basicConstraints extensionShall set the criticality of the basicConstraints extension to TRUEShall set the cA field of the basicConstraints extension set to TRUEShall set the pathLenConstraint field of the basicConstraints to “0” (zero)Table 11: basicConstraints Extension for AeroMACS CA CertificatesFieldFormatCriticalityValueCommentbasicConstraintsTRUE{ id-ce 19 }Included in all CA certificates cABOOLEANTRUESet pathLenConstraintINTEGER0Device 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. REF _Ref435449308 \h Table 12 shows the extKeyUsage extension settings for AeroMACS server certificates and specifies that all AeroMACS server certificates:May include the extKeyUsage extensionIf included, shall set the criticality of the extKeyUsage extension to FALSEShall set the keyPurposeId field of the extKeyUsage to id-kp-serverAuth and id-kp-clientAuthTable 12: extKeyUsage Extension for AeroMACS Server CertificatesFieldFormatCriticalityValueCommentextKeyUsageFALSE{ id-ce 37 }May be included in device server certificates. keyPurposeIDOID1.3.6.1.5.5.7.3.1 1.3.6.1.5.5.7.3.2id-kp-serverAuthid-kp-clientAuth REF _Ref435449315 \h Table 13 shows the extKeyUsage extension settings for AeroMACS Device certificates and specifies that all AeroMACS device certificates:May include the extKeyUsage extensionIf included, shall set the criticality of the extKeyUsage extension to FALSEShall set the keyPurposeId field of the extKeyUsage to id-kp-clientAuthTable SEQ Table \* ARABIC 13: extKeyUsage Extension for AeroMACS Device CertificatesFieldFormatCriticalityValueCommentextKeyUsageFALSE{ id-ce 37 }May be included in device certificates. keyPurposeIDOID1.3.6.1.5.5.7.3.2id-kp-clientAuthAlgorithm 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 REF _Ref435449336 \h Table 13).Table 13: Signature OIDS for CertificatesFieldFormatCriticalityValueCommentsignature algorithmIdentifier algorithmOID1.2.840.10045.4.3.2ecdsa-with-Sha256 parametersANYAbsentCertificates 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 REF _Ref435449344 \h Table 14).Table 14: subjectPublicKeyInfo for CertificatesFieldFormatCriticalityValueCommentsubjectPublicKeyInfo algorithm algorithmIdentifier algorithmOID1.2.840.10045.2.1EC Public Key parametersANY1.2.840.10045.3.1.7secp256r11.3.132.0.34secp384r1 subjectPublicKeyBIT STRING<subject public key>Modulus length. See CP section 6.1.5. Name FormsRoot CAsThe following naming attributes shall be used to populate the issuer and subject fields in Root CA Certificates issued under this CP: Table 15: Root CA Certificate Issuer and Subject FieldsNameFieldValueRequirement countryName(C=)<Country Code>Shall be the two-letter ISO 3166-1 country code for the country in which the Root CA’s service provider’s place of business is anizationName(O=)<Organization>Shall contain the issuer organization anizationalUnitName(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 CAShall contain the common name that identifies the AeroMACS Root CA. (e.g. CompanyA Root CA)CAsThe following naming attributes shall be used to populate the CA Certificate subject fields issued under this CP:Table 16: CA Certificate Subject FieldsNameFieldValueRequirement 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 anizationName(O=)<Organization>Shall contain the issuer organization name (or abbreviation thereof), trademark, or other meaningful anizationalUnitName(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> CAShall contain a name that accurately identifies the CA. (e.g. CompanyA CA)Device CertificatesThe following naming attributes shall be used to populate the Subject in Device Certificates issued under this CP: Table 17: Device Certificate Subject FieldsNameFieldValueRequirement countryName(C=)<Country Name>Shall be the two-letter ISO 3166-1 country code for the country in which the device’s place of business is anizationName(O=)<Organization>Shall contain the device organization name (or abbreviation thereof), trademark, or other meaningful anizationalUnitName(OU=)<Addition Information>(Optional) When included, one or more OUs shall contain additional identifying monName(CN=)<Device Id>For Device Certs: Shall contain the device MAC Address that is bound into the certificate that will bind the certificate’s public key to the device.For Server Certs: Shall contain the domain name of Service Provider that is bound into the certificate that will bind the certificate’s public key to the device.Name ConstraintsThe CAs shall not assert name constraints in AeroMACS certificates.Certificate Policy Object IdentifierCA and device certificates issued under this CP shall assert the policy OID listed in Section REF _Ref442877419 \r \h 1.2.2 of this document. REF _Ref435449366 \h Table 18 shows the certificatePolicies extension settings for AeroMACS certificates and specifies that all AeroMACS certificates:May include the certificatePolicies extensionIf included, shall set the criticality of the certificatePolicies extension to FALSETable 18: certificatePolicies Extension for AeroMACS CertificatesFieldFormatCriticalityValueCommentcertificatePoliciesFALSE{ id-ce 32 }May be included in all AeroMACS certificates policyInformation policyIdentifierOID<Certificate policy OID>See Section REF _Ref442877419 \r \h 1.2.2 policyQualifiersSEQUENCENot SetUsage of Policy Constraints ExtensionThe CAs shall not assert policy constraints in CA certificates.Policy Qualifiers Syntax and SemanticsCertificates issued under this CP shall not contain policy qualifiers.Processing Semantics for the Critical Certificate Policies ExtensionProcessing semantics for the critical certificate policy extension shall conform to X.509 certification path processing rules. CRL ProfileCRLs shall conform to [RFC 5280] and contain the basic fields and contents specified in the table below:Table 19: CRL Profile Basic FieldsFieldReferenced StandardSectionRequirement or Recommendationversion [RFC 5280]5.1.2.1See Section 7.2.1.signature[RFC 5280]Algorithm used to sign the CRL.issuer [RFC 5280]5.1.2.3Entity that has signed and issued the CRL. thisUpdate[RFC 5280]5.1.2.4Indicates the issue date of the CRL. CRLs are effective upon issuance. nextUpdate [RFC 5280]5.1.2.5Indicates the date by which the next CRL will be issued.revokedCertificates [RFC 5280]5.1.2.6Listing of revoked certificates, including the Serial Number of the revoked Certificate and the Revocation Date. authoritKeyIdentifier[RFC 5280]5.2.1Follows the guidance in RFC 5280. Criticality is FALSE.cRLNumber[RFC 5280]5.2.3A monotonically increasing sequence number for a given CRL scope and issuer. Criticality is FALSE.signatureAlgorithm[RFC 5280]5.1.1.2Follows the guidance in RFC 5280.signatureValue[RFC 5280]5.1.1.3Follows the guidance in RFC 5280.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].CRL and CRL entry extensionsCritical CRL extensions shall not be used.OCSP ProfileOCSP is a way to obtain timely information about the revocation status of a particular certificate. OCSP Responses must conform to [RFC5019] and must either be: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]. Version Number(s)OCSP responses shall support use of OCSP version 1 as defined by [RFC2560] and [RFC5019].OCSP ExtensionsCritical OCSP extensions shall not be pliance 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.Frequency or Circumstances of AssessmentAll CAs, RAs and CSAs operating under this policy shall be subject to a periodic compliance audit at least once per year. Identity and Qualifications of AssessorThe compliance auditor shall demonstrate competence in the field of compliance audits, and shall be thoroughly familiar with requirements of the applicable CP. The compliance auditor must perform such compliance audits as a primary responsibility. The applicable CPS shall identify the compliance auditor and justify the compliance auditor's qualifications.Assessor's Relationship to Assessed EntityThe compliance auditor shall either represent a firm, which is independent from the entities (CA or RA) being audited, or it shall be sufficiently organizationally separated from that entity to provide an unbiased, independent evaluation. An example of the latter situation may be an organizational audit department provided it can demonstrate organizational separation and independence. To further insure independence and objectivity, the compliance auditor may not have served the entity in developing or maintaining the entity’s PKI Facility, associated IT and network systems, or certificate practices statement. The APPA shall determine whether a compliance auditor meets this requirement.In the event an entity chooses to engage compliance auditor services internal to its parent organization, it shall undergo an audit from an external third party audit firm every third year, at a ics Covered by AssessmentThe purpose of a compliance audit shall be to verify that a component operates in accordance with the applicable CP, CPS, the agreement between the PKI and the APPA, and any additional MOAs between the PKI and other Entities. The compliance audit must include an assessment of the applicable CPS against the applicable CP, to determine that the CPS adequately addresses and implements the requirements of the CP.Actions Taken as a Result of DeficiencyWhen the compliance auditor finds a discrepancy between the requirements of this CP or the stipulations in the CPS and the design, operation, or maintenance of the PKI Authorities, the following actions shall be performed: The compliance auditor shall note the discrepancy; The compliance auditor shall notify the responsible party promptly; and The party responsible for correcting the discrepancy shall determine what further notifications or actions are necessary pursuant to the requirements of the applicable CP and the Agreement, and then proceed to make such notifications and take such actions without delay.Depending upon the nature and severity of the discrepancy, and how quickly it can be corrected, the APPA may decide to temporarily halt operation of the CA or RA, to revoke a certificate issued to the CA or RA, or take other actions it deems appropriate. The APPA will develop procedures for making and implementing such determinations. In accordance with section 8.1, a compliance audit may be required to confirm the implementation and effectiveness of the munication of ResultsAn Audit Compliance Report package, including identification of corrective measures taken or being taken by the Entity PKI, shall be provided to the APPA as set forth in Section REF _Ref435452404 \r \h 8.1. This package shall be prepared in accordance with the APPA and must include an assertion from the Entity PKI Program Management Authority that all PKI components have been audited – including any components that may be separately managed and operated. The package shall identify the versions of this CP and CPS used in the assessment. Additionally, where necessary, the results shall be communicated as set forth in Section 8.5 above.Other Business and Legal MattersFeesAny fees must be approved by the APPACertificate Issuance or Renewal FeesSection 2 of this policy requires that CA certificates be publicly available. CAs operating under this policy must not charge additional fees for access to this information.Certificate Access FeesSection 2 of this policy requires that CA certificates be publicly available. CAs operating under this policy must not charge additional fees for access to CRLs and OCSP status information.Revocation or Statue Information Access FeesCAs operating under this policy must not charge additional fees for access to CRLs and OCSP status information.Fees for other ServicesNo stipulation.Refund PolicyNo stipulation.Financial ResponsibilityThis CP contains no limits on the use of certificates issued by CAs under this policy. Rather, entities, acting as relying parties, shall determine what financial limits, if any, they wish to impose for certificates used to consummate a transaction.Insurance CoverageRoot CA must obtain insurance coverage obtained from a reputable financially sound insurer with appropriate policy limits that is equal to or exceeds industry norms. The WiMAX Forum and ICAO will be named as additional insured. Insurance carrier and coverage must be acceptable to APPA.Other AssetsNo stipulation.Insurance or Warranty Coverage for End-EntitiesNo stipulation.Confidentiality of Business Information CA information not requiring protection shall be made publicly available. Public access to organizational information shall be determined by the respective organization. Written confidential information shall be adequately marked in writing as confidential. Oral confidential information shall be identified as confidential.Scope of Confidential InformationConfidential Information means all information in written or oral form that the disclosing party identifies as confidential, and any trade secret or other proprietary information that the recipient knows or reasonably ought to know should be treated as rmation not within the Scope of Confidential InformationInformation that is generally known to the public or properly known by the receiving party at the time of disclosure and other typical exceptions.Responsibility to Protect Confidential InformationNo stipulation.Privacy of Personal InformationIt is the responsibility of all parties to ensure privacy of personal information under their control. No personal information is registered or certified. Information about subordinate CA operators is retained by the CA as part of certification request, which is subsequently logged and later archived. Manufacturer point of contact information is also retained by the Root CAs. If a party collects, transmits or stores personal information, its practices will comply with all applicable laws.Privacy PlanThe APPA shall conduct a Privacy Impact Assessment. If deemed necessary, APPA shall have a Privacy Plan to protect personally identifying information from unauthorized disclosure. For the Root CA, the APPA shall approve the Privacy Plan. Privacy plans will be implemented in accordance with the requirements of the Privacy Act of 1974, as rmation Treated as PrivateEntities acquiring services under this policy shall protect all device sponsors personally identifying information from unauthorized disclosure. Records of individual transactions may be released upon request of any device sponsors involved in the transaction or their legally recognized agents. The contents of the archives maintained by CAs operating under this policy shall not be released except as required by rmation not Deemed PrivateInformation included in certificates is not subject to protections outlined in section REF _Ref443475942 \r \h 9.4.2.Responsibility to Protect Private InformationSensitive information must be stored securely, and may be released only in accordance with other stipulations in section REF _Ref443475911 \r \h 9.4.Notice and Consent to Use Private InformationThe APPA is not required to provide any notice or obtain the consent of the device sponsor in order to release private information in accordance with other stipulations of section REF _Ref443475885 \r \h 9.4.Disclosure Pursuant to Judicial or Administrative ProcessThe APPA shall not disclose private information to any third party unless authorized by this policy, required by law, government rule or regulation, or order of a court of competent jurisdiction. Other Information Disclosure CircumstancesExcept as required for operation of the PKI system, as expressly permitted or required under the CP, or as required by applicable law, no private information will be disclosed without the express written consent of the party to which that private information pertains.Intellectual Property RightsThe APPA will not knowingly violate intellectual property rights held by others.The CP, CPS, each root certificate and all certificates issued under the root certificate are the property of the APPA. No party will use any property of the APPA, including, without limitation, any trademark, copyright, trade secret or other proprietary right of the APPA, unless the APPA has licensed that use. No party will infringe the intellectual property rights of any third party or the APPA. Without limitation, except as the APPA may expressly authorize in writing, it is prohibited to: Reverse engineer, translate, disassemble, decompile the whole or any part of any software or system or any part therefore or otherwise attempt to access any software source code embedded in or operating using any 1280 system; Assign, transfer, sell, license, sub-license, lease, rent, charge or otherwise deal in or encumber, any software or system or any part thereof or use same on behalf of or for the benefit of any third party, or make available the same in any way whatsoever to any third party without the APPA’s prior written consent; Remove or alter any trademark or any copyright or other proprietary notice on any software, system or any other materials; Distribute, create derivative works of or modify the any materials, software or systems or any part thereof in anyway, or use, copy, duplicate or display same on a commercial or development basis. Provide any service using a certificate provided under this CP except as authorized and provided in this CP and an approved CPS. These restrictions shall not be construed in a manner that would violate any applicable law.Representations and WarrantiesThe obligations described below pertain to the APPA.The APPA shall—Approve the CPS for each CA that issues certificates under this policy;Review periodic compliance audits to ensure that CAs are operating in compliance with their approved CPSs;Review name space control procedures to ensure that distinguished names are uniquely assigned for all certificates issued under this CP;Revise this CP to maintain the level of assurance and operational practicality;Publicly distribute this CP;Coordinate modifications to this CP to ensure continued compliance by CAs operating under approved CPSs; andReview periodic compliance audits to ensure that RAs are operating in compliance with their approved CPSs.CA Representations and WarrantiesCAs operating under this policy shall warrant that their procedures are implemented in accordance with this CP, and that any certificates issued that assert the policy OIDs identified in this CP were issued in accordance with the stipulations of this policy.A CA that issues certificates that assert a policy defined in this document shall conform to the stipulations of this document, including—Providing to the APPA a CPS, as well as any subsequent changes, for conformance assessment.Maintaining its operations in conformance to the stipulations of the approved CPS.Ensuring that registration information is accepted only from approved RAs operating under an approved CPS.Including only valid and appropriate information in certificates, and maintaining evidence that due diligence was exercised in validating the information contained in the certificates.Revoking the certificates of devices whose device sponsor is found to have acted in a manner counter to their obligations in accordance with section REF _Ref440029894 \r \h 9.6.3.Operating or providing for the services of an on-line repository, and informing the repository service provider of their obligations if applicable.RA Representations and WarrantiesAn RA that performs registration functions as described in this policy shall comply with the stipulations of this policy, and comply with a CPS approved by the APPA for use with this policy. An RA who is found to have acted in a manner inconsistent with these obligations is subject to revocation of RA responsibilities. An RA supporting this policy shall conform to the stipulations of this document, including—Maintaining its operations in conformance to the stipulations of the approved CPS.Including only valid and appropriate information in certificate requests, and maintaining evidence that due diligence was exercised in validating the information contained in the certificate.Ensuring that obligations are imposed on device sponsors in accordance with section REF _Ref440029894 \r \h 9.6.3, and that device sponsors are informed of the consequences of not complying with those obligations.Device Representations and WarrantiesIf the human sponsor for a device is not physically located near the sponsored device, and/or does not have sufficient administrative privileges on the sponsored device to protect the device’s private key and ensure that the device’s certificate is only used for authorized purposes, the device sponsor may delegate these responsibilities to an authorized administrator for the device. The delegation shall be documented and signed by both the device sponsor and the authorized administrator for the device. Delegation does not relieve the device sponsor of his or her accountability for these responsibilities.Relying Parties Representations and WarrantiesThis CP does not specify the steps a relying party should take to determine whether to rely upon a certificate. The relying party decides, pursuant to its own policies, what steps to take. The CA merely provides the tools (i.e., certificates and CRLs) needed to perform the trust path creation, validation, and CP mappings that the relying party may wish to employ in its determination.Representations and Warranties of Other ParticipantsNoneDisclaimers of WarrantiesCAs operating under this policy may not disclaim any responsibilities described in this CP.Limitations of LiabilityICAO and the WiMAX Forum shall not be liable to any party or as determined through a valid express written contract between the ICAO, the WiMAX Forum and another party.IndemnitiesNo stipulation.Term and TerminationTermThis CP becomes effective when approved by the APPA. This CP has no specified term.TerminationTermination of this CP is at the discretion of the APPA.Effect of Termination and SurvivalThe requirements of this CP remain in effect through the end of the archive period for the last certificate issued.Individual Notices and Communications with ParticipantsThe APPA shall establish appropriate procedures for communications with CAs operating under this policy via contracts or memoranda of agreement as applicable.For all other communications, no stipulation.AmendmentsProcedure for AmendmentChanges to items within this CP shall be performed in accordance with the Change Request Procedure of the Aviation Working Group.The WiMAX Forum AWG shall review this CP at least once every year. Corrections, updates, or changes to this CP shall be publicly available. Suggested changes to this CP shall be communicated to the contact in section REF _Ref443475166 \r \h 1.5.2; such communication must include a description of the change, a change justification, and contact information for the person requesting the change.Notification and Mechanism and PeriodNotification shall be performed in accordance with the Change Request procedure of the Aviation Working Group.Circumstances under which OID must be ChangedCertificate Policy OIDs shall be changed if the CA determines that a change in the CP reduces the level of assurance provided.Dispute Resolution ProvisionsThe APPA shall facilitate the resolution between entities when conflicts arise as a result of the use of certificates issued under this policy. Governing LawThe construction, validity, performance and effect of certificates issued under this CP for all purposes shall be governed by United States Federal law (statute, case law, or regulation).Compliance with Applicable LawAll CAs operating under this policy are required to comply with applicable law.Miscellaneous ProvisionsEntire AgreementNo stipulation.AssignmentNo stipulation.SeverabilityShould it be determined that one section of this CP is incorrect or invalid, the other sections of this CP shall remain in effect until the CP is updated. The process for updating this CP is described in section REF _Ref443466257 \r \h \* MERGEFORMAT 9.12.Enforcement (Attorneys’ Fees and Waiver of Rights)No stipulation.Force MajeureNo stipulation.Other ProvisionsNo stipulation.ReferencesNS4009 NSTISSI 4009, National Information Systems Security Glossary, January 1999. RFC 2119Key Words for use in RFCs to Indicate Requirement Level, IETF (Bradner), March 1997. 2560X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP, IETF (Myers, Ankney, Malpani, Galperin, Adams), June 1999. 3647Internet X.509 PKI Certificate Policy and Certification Practices Framework, IETF (Chokhani, Ford, Sabett, Merrill, and Wu), November 2003. 5019The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments, IETF (Deacon, Hurst), September 2007. 5280Internet X.509 PKI Certificate and Certification Revocation List (CRL) Profile, IETF (Cooper, Santesson, Farrell, Boeyen, Housley, and Polk), May 2008. 140-2Security Requirements for Cryptographic Modules, FIPS 140-2, May 25, 2001. specification uses the following terms:Access Ability to make use of any information system (IS) resource. [NS4009] Access Control Process of granting access to information system resources only to authorized users, programs, processes, or other systems. [NS4009] Activation Data Private data, other than keys, that are required to access cryptographic modules (i.e., unlock private keys for signing or decryption events). Archive Long-term, physically separate storage. Audit Requirements GuideA document that sets forth the security and audit requirements and practices for AeroMACS CAs.Authenticate To confirm the identity of an entity when that identity is presented. Authentication Security measure designed to establish the validity of a transmission, message, or originator, or a means of verifying an individual's authorization to receive specific categories of information. [NS4009] CertificateA message that, at least, states a name or identifies the CA, identifies the device, contains the device’s public key, identifies the Certificate’s Validity Period, contains a Certificate serial number, and is digitally signed by the CA that issued the certificate.Certificate ApplicantAn individual or organization that requests the issuance of a Certificate by a CA.Certificate ApplicationA request from a Certificate Applicant (or authorized agent of the Certificate Applicant) to a CA for the issuance of a Certificate.Certificate ChainAn ordered list of Certificates containing a device Certificate and one or more CA Certificates, which terminates in a root Certificate.Control ObjectivesCriteria 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 pliance AuditA periodic audit that a CA system undergoes to determine its conformance with AeroMACS PKI requirements that apply to promiseA 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 AgreementAn agreement setting forth the terms and conditions under which a CRL or the information in it can be used.Exigent Audit/InvestigationAn audit or investigation by AeroMACS where AeroMACS has reason to believe that an entity’s failure to meet PKI Standards, an incident or Compromise relating to the entity, or an actual or potential threat to the security of the PKI posed by the entity has occurred.Elliptic Curve Cryptography (ECC)A public-key cryptography system based on the algebraic structure of elliptic curves over finite fields.Intellectual Property RightsRights under one or more of the following: copyright, patent, trade secret, trademark, or any other intellectual property rights.Key Generation CeremonyA procedure whereby a CA’s key pair is generated, its private key is backed up, and/or its public key is certified.PKI ParticipantAn individual or organization that is one or more of the following within the AeroMACS PKI: AeroMACS, a CA, a Device Sponsor, or a Relying Party.PKCS #10Public-Key Cryptography Standard #10, developed by RSA Security Inc., which defines a structure for a Certificate Signing Request.PKCS #8Public-Key Cryptography Standard #8, developed by RSA Security Inc., which defines a secure means for the transfer of private keys.Processing CenterA 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 PartyAn individual or organization that acts in reliance on a certificate and/or a digital signature.Secret ShareA 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 SharingThe 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 RepositoryAeroMACS database of relevant security information accessible on-line.Security PolicyThe highest-level document describing AeroMACS security policies.Sub domainThe portion of the AeroMACS PKI under control of an entity and all entities subordinate to it within the AeroMACS PKI.Sub domain Participants An individual or organization that is one or more of the following within the AeroMACS Subdomain: AeroMACS, a Device Sponsor, or a Relying Party.SubjectThe holder of a private key corresponding to a public key. The term “Subject” can, in the case of a Device Certificate, refer to the Device Sponsor requesting the device certificate.Subscriber AgreementAn agreement used by a CA setting forth the terms and conditions under which an individual or organization acts as a Device Sponsor.Superior EntityAn entity above a certain entity within the AeroMACS PKI.Trusted PersonAn 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 PositionThe positions within the AeroMACS PKI entity that must be held by a Trusted Person.Trustworthy SystemComputer 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 PeriodThe 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.Abbreviations and AcronymsThis specification uses the following abbreviations:AIAAuthority Information AccessAPPAAeroMACS PKI Policy AuthorityAWGAviation Working GroupCACertification AuthorityCNCommon NameCPCertificate PolicyCPSCertification Practice StatementCRACertificate Requesting AccountCRLCertificate Revocation ListCSRCertificate Signing RequestCSACertificate Status AuthorityCSSCertificate Status ServicesDRDemand ResponseDRASDemand Response Automation ServerECCElliptic Curve CryptographyFIPSFederal Information Processing Standardsid-atX.500 attribute types. (OID value: 2.5.4)id-ceObject Identifier for Version 3 certificate extensions. (OID value: 2.5.29)IETFInternet Engineering Task ForceISOIndependent System OperatorsLSVALogical Security Vulnerability AssessmentMACMedia Access ControlMFGManufacturerOCSPOnline Certificate Status ProtocolOIDObject IdentifierPAPolicy AuthorityPKCSPublic-Key Cryptography StandardPKIPublic Key InfrastructurePKIXPublic Key Infrastructure X.509RARegistration AuthorityRFCRequest for commentRSARivest, Shamir, AdelmanSASStatement on Auditing Standards (promulgated by the American Institute of Certified Public Accountants)URIUniform Resource Identifier ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download