AeroMACS PKI Certificate Policy



24515422311400026413527661523002286001716405WiMAX Forum? Network ArchitectureAeroMACS PKI Certificate Policy DOCPROPERTY Subject \* MERGEFORMAT DRAFT-T32-006-R010v01-DDraft Specification DOCPROPERTY Manager \* MERGEFORMAT (2015-11-23)00WiMAX Forum? Network ArchitectureAeroMACS PKI Certificate Policy DOCPROPERTY Subject \* MERGEFORMAT DRAFT-T32-006-R010v01-DDraft Specification DOCPROPERTY Manager \* MERGEFORMAT (2015-11-23)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 addedKey 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 _Toc436085893 \h i1.Introduction PAGEREF _Toc436085894 \h 81.1Overview PAGEREF _Toc436085895 \h 81.2Document Name and Identification PAGEREF _Toc436085896 \h 81.3PKI Participants PAGEREF _Toc436085897 \h 81.4Certificate Usage PAGEREF _Toc436085898 \h 81.5Policy Administration PAGEREF _Toc436085899 \h 81.6Definitions and Acronyms PAGEREF _Toc436085900 \h 82.Introduction PAGEREF _Toc436085901 \h 92.1Repositories PAGEREF _Toc436085902 \h 92.2Publication of Certification Information PAGEREF _Toc436085903 \h 92.3Time or Frequency of Publication PAGEREF _Toc436085904 \h 92.4Access Controls on Repositories PAGEREF _Toc436085905 \h 93.Identification and Authentication PAGEREF _Toc436085906 \h 103.1Naming PAGEREF _Toc436085907 \h 103.2Initial Identity Validation PAGEREF _Toc436085908 \h 103.3Identification and Authentication for Re-key Requests PAGEREF _Toc436085909 \h 103.4Identification and Authentication for Revocation Request PAGEREF _Toc436085910 \h 104.Certificate Life-cycle Operational Requirements PAGEREF _Toc436085911 \h 114.1Certificate Application PAGEREF _Toc436085912 \h 114.2Certificate Application Processing PAGEREF _Toc436085913 \h 114.3Certificate Issuance PAGEREF _Toc436085914 \h 114.4Certificate Acceptance PAGEREF _Toc436085915 \h 114.5Key Pair and Certificate Usage PAGEREF _Toc436085916 \h 114.6Certificate Renewal PAGEREF _Toc436085917 \h 114.7Certificate Re-key PAGEREF _Toc436085918 \h 114.8Certificate Modification PAGEREF _Toc436085919 \h 114.9Certificate Revocation and Suspension PAGEREF _Toc436085920 \h 114.10Certificate Status Services PAGEREF _Toc436085921 \h 114.11End of Subscription PAGEREF _Toc436085922 \h 114.12Key Escrow and Recovery PAGEREF _Toc436085923 \h 115.Facility, Management, and Operational Controls PAGEREF _Toc436085924 \h 125.1Physical Controls PAGEREF _Toc436085925 \h 125.1.1Site Location and Construction PAGEREF _Toc436085926 \h 125.1.2Physical Access for CA Equipment PAGEREF _Toc436085927 \h 125.1.3Power and Air Conditioning PAGEREF _Toc436085928 \h 135.1.4Water Exposures PAGEREF _Toc436085929 \h 135.1.5Fire Prevention and Protection PAGEREF _Toc436085930 \h 135.1.6Media Storage PAGEREF _Toc436085931 \h 135.1.7Waste Disposal PAGEREF _Toc436085932 \h 135.1.8Off-Site Backup PAGEREF _Toc436085933 \h 135.2Procedural Controls PAGEREF _Toc436085934 \h 135.2.1Trusted Roles PAGEREF _Toc436085935 \h 135.2.2Number of Persons Required per Task PAGEREF _Toc436085936 \h 145.2.3Identification and Authentication for Each Role PAGEREF _Toc436085937 \h 155.2.4Roles Requiring Separation of Duties PAGEREF _Toc436085938 \h 155.3Personnel Controls PAGEREF _Toc436085939 \h 155.3.1Qualifications, Experience, and Clearance Requirements PAGEREF _Toc436085940 \h 155.3.2Background Check Procedures PAGEREF _Toc436085941 \h 155.3.3Training Requirements PAGEREF _Toc436085942 \h 165.3.4Retraining Frequency and Requirements PAGEREF _Toc436085943 \h 165.3.5Job Rotation Frequency and Sequence PAGEREF _Toc436085944 \h 165.3.6Sanctions for Unauthorized Actions PAGEREF _Toc436085945 \h 165.3.7Independent Contractor Requirements PAGEREF _Toc436085946 \h 165.3.8Documentation Supplied to Personnel PAGEREF _Toc436085947 \h 175.4Audit Logging Procedures PAGEREF _Toc436085948 \h 175.4.1Types of Events Recorded PAGEREF _Toc436085949 \h 175.4.2Frequency of Processing Log PAGEREF _Toc436085950 \h 195.4.3Retention Period for Audit Log PAGEREF _Toc436085951 \h 195.4.4Protection of Audit Log PAGEREF _Toc436085952 \h 195.4.5Audit Log Backup Procedures PAGEREF _Toc436085953 \h 195.4.6Audit Collection System (Internal vs. External) PAGEREF _Toc436085954 \h 195.4.7Notification to Event-Causing Subject PAGEREF _Toc436085955 \h 205.4.8Vulnerability Assessments PAGEREF _Toc436085956 \h 205.5Records Archival PAGEREF _Toc436085957 \h 205.5.1Types of Events Archived PAGEREF _Toc436085958 \h 205.5.2Retention Period for Archive PAGEREF _Toc436085959 \h 205.5.3Protection of Archive PAGEREF _Toc436085960 \h 215.5.4Archive Backup Procedures PAGEREF _Toc436085961 \h 215.5.5Requirements for Time-Stamping of Records PAGEREF _Toc436085962 \h 215.5.6Archive Collection System (Internal or External) PAGEREF _Toc436085963 \h 215.5.7Procedures to Obtain and Verify Archive Information PAGEREF _Toc436085964 \h 215.6Key Changeover PAGEREF _Toc436085965 \h 215.7Compromise and disaster recovery PAGEREF _Toc436085966 \h 215.7.1Incident and Compromise Handling Procedures PAGEREF _Toc436085967 \h 215.7.2Computing Resources, Software, and/or Data Are Corrupted PAGEREF _Toc436085968 \h 225.7.3Entity (CA) Private Key Compromise Procedures PAGEREF _Toc436085969 \h 225.7.4Business Continuity Capabilities after a Disaster PAGEREF _Toc436085970 \h 225.8CA Termination PAGEREF _Toc436085971 \h 226.TECHNICAL SECURITY CONTROLS PAGEREF _Toc436085972 \h 236.1Key Pair Generation and Installation PAGEREF _Toc436085973 \h 236.1.1Key Pair Generation PAGEREF _Toc436085974 \h 236.1.2Private Key Delivery to Subscriber PAGEREF _Toc436085975 \h 236.1.3Public Key Delivery to Certificate Issuer PAGEREF _Toc436085976 \h 246.1.4CA Public Key Delivery to Relying Parties PAGEREF _Toc436085977 \h 246.1.5Key Sizes PAGEREF _Toc436085978 \h 246.1.6Public Key Parameters Generation and Quality Checking PAGEREF _Toc436085979 \h 246.1.7Key Usage Purposes (as per X.509 v3 Key Usage Field) PAGEREF _Toc436085980 \h 246.2Private Key Protection and Cryptographic Module Engineering Controls PAGEREF _Toc436085981 \h 276.2.1Cryptographic Module Standards and Controls PAGEREF _Toc436085982 \h 276.2.2Private Key (n out of m) Multi-Person Control PAGEREF _Toc436085983 \h 276.2.3Private Key Escrow PAGEREF _Toc436085984 \h 286.2.4Private Key Backup PAGEREF _Toc436085985 \h 286.2.5Private Key Archival PAGEREF _Toc436085986 \h 286.2.6Private Key Transfer into or from a Cryptographic Module PAGEREF _Toc436085987 \h 286.2.7Private Key Storage on Cryptographic Module PAGEREF _Toc436085988 \h 296.2.8Method of Activating Private Key PAGEREF _Toc436085989 \h 296.2.9Method of Deactivating Private Key PAGEREF _Toc436085990 \h 296.2.10Method of Destroying Private Key PAGEREF _Toc436085991 \h 306.2.11Cryptographic Module Rating PAGEREF _Toc436085992 \h 306.3Other Aspects of Key Pair Management PAGEREF _Toc436085993 \h 306.3.1Public Key Archival PAGEREF _Toc436085994 \h 306.3.2Certificate Operational Periods and Key Pair Usage Periods PAGEREF _Toc436085995 \h 306.4Activation data PAGEREF _Toc436085996 \h 306.4.1Activation Data Generation and Installation PAGEREF _Toc436085997 \h 306.4.2Activation Data Protection PAGEREF _Toc436085998 \h 316.4.3Other Aspects of Activation Data PAGEREF _Toc436085999 \h 316.5Computer security controls PAGEREF _Toc436086000 \h 316.5.1Specific Computer Security Technical Requirements PAGEREF _Toc436086001 \h 316.5.2Computer Security Rating PAGEREF _Toc436086002 \h 326.6Life Cycle Technical Controls PAGEREF _Toc436086003 \h 326.6.1System Development Controls PAGEREF _Toc436086004 \h 326.6.2Security Management Controls PAGEREF _Toc436086005 \h 336.6.3Life Cycle Security Controls PAGEREF _Toc436086006 \h 336.7Network Security Controls PAGEREF _Toc436086007 \h 336.8Time-Stamping PAGEREF _Toc436086008 \h 337.CERTIFICATE, CRL, AND OCSP PROFILES PAGEREF _Toc436086009 \h 347.1Certificate Profile PAGEREF _Toc436086017 \h 347.1.1Version Number(s) PAGEREF _Toc436086018 \h 347.1.2Certificate Extensions PAGEREF _Toc436086019 \h 357.1.3Algorithm Object Identifiers (OIDs) PAGEREF _Toc436086020 \h 387.1.4Name Forms PAGEREF _Toc436086021 \h 397.1.5Name Constraints PAGEREF _Toc436086022 \h 417.1.6Certificate Policy Object Identifier PAGEREF _Toc436086023 \h 417.1.7Usage of Policy Constraints Extension PAGEREF _Toc436086024 \h 417.1.8Policy Qualifiers Syntax and Semantics PAGEREF _Toc436086025 \h 417.1.9Processing Semantics for the Critical Certificate Policies Extension PAGEREF _Toc436086026 \h 417.2CRL Profile PAGEREF _Toc436086027 \h 417.2.1Version Number(s) PAGEREF _Toc436086028 \h 427.2.2CRL and CRL entry extensions PAGEREF _Toc436086029 \h 427.3OCSP Profile PAGEREF _Toc436086030 \h 427.3.1Version Number(s) PAGEREF _Toc436086031 \h 427.3.2OCSP Extensions PAGEREF _Toc436086032 \h pliance Audit and Other Assessments PAGEREF _Toc436086033 \h 448.1Frequency or Circumstances of Assessment PAGEREF _Toc436086034 \h 448.2Identity/Qualifications of Assessor PAGEREF _Toc436086035 \h 448.3Assessor's Relationship to Assessed Entity PAGEREF _Toc436086036 \h 448.4Topics Covered by Assessment PAGEREF _Toc436086037 \h 448.5Actions Taken as a Result of Deficiency PAGEREF _Toc436086038 \h 448.6Communication of Results PAGEREF _Toc436086039 \h 459.Other Business and Legal Matters PAGEREF _Toc436086040 \h 469.1Fees PAGEREF _Toc436086041 \h 469.2Financial Responsibility PAGEREF _Toc436086042 \h 469.3Confidentiality of business information PAGEREF _Toc436086043 \h 469.4Privacy of Personal Information PAGEREF _Toc436086044 \h 469.5Intellectual Property Rights PAGEREF _Toc436086045 \h 469.6Representations and Warranties PAGEREF _Toc436086046 \h 469.7Disclaimers of warranties PAGEREF _Toc436086047 \h 469.8Limitations of liability PAGEREF _Toc436086048 \h 469.9Indemnities PAGEREF _Toc436086049 \h 469.10Term and termination PAGEREF _Toc436086050 \h 469.11Individual notices and communications with participants PAGEREF _Toc436086051 \h 469.12Amendments PAGEREF _Toc436086052 \h 469.13Dispute Resolution Provisions PAGEREF _Toc436086053 \h 469.14Governing Law PAGEREF _Toc436086054 \h 469.15Compliance with Applicable Law PAGEREF _Toc436086055 \h 469.16Miscellaneous provisions PAGEREF _Toc436086056 \h 469.17Other Provisions PAGEREF _Toc436086057 \h 4610.References PAGEREF _Toc436086058 \h 4711.Glossary PAGEREF _Toc436086059 \h 4812.Abbreviations and Acronyms PAGEREF _Toc436086060 \h 51TABLE OF FIGURES (If applicable) TOC \h \z \c "Figure" TABLE OF TABLES TOC \c "Table" Table 1: Algorithm Type and Key Size PAGEREF _Toc436086061 \h 24Table 2: keyUsage Extension for all CA certificates PAGEREF _Toc436086062 \h 25Table 3: keyUsage Extension for all Subscriber Signature Certificates PAGEREF _Toc436086063 \h 25Table 4: keyUsage Extension for all Key Management Certificates PAGEREF _Toc436086064 \h 26Table 5: keyUsage Extension for all Server Certificates PAGEREF _Toc436086065 \h 27Table 6: Certificate Profile Basic Fields PAGEREF _Toc436086066 \h 34Table 7: Root CA Certificate Standard Extensions PAGEREF _Toc436086067 \h 35Table 8: Sub-CA Certificate Standard Extensions PAGEREF _Toc436086068 \h 35Table 9: Subscriber Certificate Standard Extensions PAGEREF _Toc436086069 \h 36Table 10: OCSP Certificate Standard Extensions PAGEREF _Toc436086070 \h 36Table 11: subjectKeyIdentifier Extension for AeroMACS CA Certificates PAGEREF _Toc436086071 \h 37Table 12: basicConstraints Extension for AeroMACS Root CA Certificates PAGEREF _Toc436086072 \h 37Table 13: basicConstraints Extension for AeroMACS Sub-CA Certificates PAGEREF _Toc436086073 \h 37Table 14: extKeyUsage Exstension for AeroMACS Server Certificates PAGEREF _Toc436086074 \h 38Table 15: extKeyUsage Exstension for AeroMACS Client Certificates PAGEREF _Toc436086075 \h 38Table 16: Signature OIDS for Certificates PAGEREF _Toc436086076 \h 38Table 17: subjectPublicKeyInfo for Certificate PAGEREF _Toc436086077 \h 39Table 18: Root CA Certificate issuer and subject Fields PAGEREF _Toc436086078 \h 39Table 19: Sub-CA Certificate subject Fields PAGEREF _Toc436086079 \h 40Table 20: Subscriber Certificate subject Fields PAGEREF _Toc436086080 \h 40Table 21: certificatePolicies Extension for AeroMACS Certificates PAGEREF _Toc436086081 \h 41Table 22: CRL Profile Basic Fields PAGEREF _Toc436086082 \h 41IntroductionOverviewDocument Name and IdentificationPKI ParticipantsCertificate UsagePolicy AdministrationDefinitions and AcronymsIntroductionRepositoriesPublication of Certification InformationTime or Frequency of PublicationAccess Controls on RepositoriesIdentification and AuthenticationNamingInitial Identity ValidationIdentification and Authentication for Re-key RequestsIdentification and Authentication for Revocation RequestCertificate Life-cycle Operational RequirementsCertificate ApplicationCertificate Application ProcessingCertificate IssuanceCertificate AcceptanceKey Pair and Certificate UsageCertificate RenewalCertificate Re-keyCertificate ModificationCertificate Revocation and SuspensionCertificate Status ServicesEnd of SubscriptionKey Escrow and RecoveryFacility, 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. Physical Access for CA EquipmentThe physical access controls for CA equipment, as well as remote workstations used to administer the CAs, shall be auditable and:Ensure that no unauthorized access to the hardware is permitted.Ensure that all removable media and paper containing sensitive plain-text information is stored in secure containers. Be manually or electronically monitored for unauthorized intrusion at all times. Ensure an access log is maintained and inspected periodically. Require two-person physical access control to both the cryptographic module and computer systems. Removable cryptographic modules shall be deactivated prior to storage. When not in use, removable cryptographic modules and the activation information used to access or enable cryptographic modules shall be placed in secure containers. Activation data shall be either memorized or recorded and stored in a manner commensurate with the security afforded the cryptographic module, and shall not be stored with the cryptographic module or removable hardware associated with remote workstations used to administer the CA.A security check of the facility housing the CA equipment or remote workstations used to administer the CAs shall occur if the facility is to be left unattended. At a minimum, the check shall verify the following: The equipment is in a state appropriate to the current mode of operation (e.g., that cryptographic modules are in place when “open,” and secured when “closed,” and for the CA, that all equipment other than the repository is shut down). 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.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 ControlsTrusted RolesA trusted role is one whose incumbent performs functions that can introduce security problems if not carried out properly, whether accidentally or maliciously. The people selected to fill these roles must be extraordinarily responsible, or the integrity of the CA will be weakened. The functions performed in these roles form the basis of 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 – authorized to install, configure, and maintain the CA; establish and maintain system accounts; configure audit parameters; and generate component keys.Officer – authorized to request or approve certificate issuance and revocations.Auditor – authorized to review, maintain, and archive audit logs.Operator – authorized to perform system backup and recovery.Administrators do not issue certificates to subscribers. The roles required for each level of assurance are identified in Section REF _Ref435533458 \r \h 5.2.4. These four roles are employed at the CA and Sub-CA locations as appropriate. Separation of duties shall comply with REF _Ref435533458 \r \h 5.2.4, and requirements for three person control with REF _Ref435521739 \r \h 5.2.2, regardless of the titles and numbers of Trusted Roles.AdministratorThe Administrator shall be responsible for:Installation, configuration, and maintenance of the CA.Establishing and maintaining CA system accounts.Configuring certificate profiles or templates and audit parameters.Generating and backing up CA keys.OfficerThe Officer shall be responsible for issuing certificates, that is:Registering new subscribers and requesting the issuance of certificates.Verifying the identity of subscribers and accuracy of information included in certificates.Approving and executing the issuance of certificates.Requesting, approving, and executing the revocation of certificates.Audit AdministratorThe Audit Administrator shall be responsible for:Reviewing, maintaining, and archiving audit logs.Performing or overseeing internal compliance audits to ensure that the CA is operating in accordance with the CPS.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.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 versaThree 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 _Ref435521692 \r \h \* MERGEFORMAT 5.2.1. 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.An individual in a trusted role shall authenticate to remote components of the PKI using a method commensurate with the strength of the PKI.Roles Requiring Separation of DutiesIndividuals may only assume one of the following roles: Officer, Administrator, and Auditor, but any individual may assume the Operator role. The CA and Sub-CA software and hardware shall identify and authenticate its users and shall ensure that no user identity can assume both the Administrator and Officer roles, assume both the Administrator and Auditor roles, or assume both the Auditor and Officer roles. No individual shall have more than one identity.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:Have successfully completed an appropriate training program.Have demonstrated the ability to perform their duties.Be trustworthy.Have no other duties that would interfere or conflict with their duties for the trusted role.Have not been previously relieved of duties for reasons of negligence or non-performance of duties.Have not been convicted of a felony offense.For PKIs operated at medium-software, medium-hardware, and/or high-hardware, each person filling a trusted role shall satisfy at least one of the following requirements:The person shall be a citizen of the country where the CA is located; orFor PKIs operated on behalf of multinational government organizations, the person shall be a citizen of one of the member countries; orFor PKIs 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.Background Check ProceduresCA personnel shall, at a minimum, pass a background investigation covering the following areas: Confirmation of previous employment; Confirmation of the highest or most relevant educational degree; Place of residence; Search of criminal records Check of referencesCheck of credit/financial recordsThe period of investigation must cover at least the last five years for each area, excepting the residence check which must cover at least the last three years. Regardless of the date of award, the highest educational degree shall be verified.Factors revealed in a background check that may be considered grounds for rejecting candidates for Trusted Positions or for taking action against an existing Trusted Person may include but is not limited to the following:Misrepresentations made by the candidate or Trusted PersonHighly unfavorable or unreliable personal referencesCertain criminal convictionsIndications of a lack of financial responsibilityThe results of these checks shall not be released except as required in Sections 9.3 and 9.4.If a formal clearance or other check is the basis for background check, the background refresh shall be in accordance with the corresponding formal clearance or other check. Otherwise, the background check shall be refreshed every ten years.Training RequirementsAll personnel performing duties with respect to the operation of the CA or Sub0CA shall receive comprehensive training. Training shall be conducted in the following areas:CA (or Sub-CA) security principles and mechanisms;All PKI software versions in use on the CA (or Sub-CA) system;All PKI duties they are expected to perform;Disaster recovery and business continuity procedures; andStipulations of this policy.Retraining Frequency and RequirementsAll individuals responsible for PKI roles shall be made aware of changes in the CA operation. Any significant change to the operations shall have a training (awareness) plan, and the execution of such plan shall be documented. Examples of such changes are CA software or hardware upgrade, changes in automated security systems, and relocation of equipment.Documentation shall be maintained identifying all personnel who received training and the level of training completed.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 Sub-CAs 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 PersonnelDocumentation sufficient to define duties and procedures for each role shall be provided to the personnel filling that role.Audit Logging ProceduresAudit log files shall be generated for all events relating to the security of the CA. Where possible, the security audit logs shall be automatically collected. Where this is not possible, a logbook, paper form, or other physical mechanism shall be used. All security audit logs, both electronic and non-electronic, shall be retained and made available during compliance audits. The security audit logs for each auditable event defined in this section shall be maintained in accordance with Section 5.5.2.Types of Events RecordedAll security auditing capabilities of CA operating system and CA applications required by this CP shall be enabled during installation. At a minimum, each audit record shall include the following (either recorded automatically or manually for each auditable event): The type of event; The date and time the event occurred; A success or failure indicator when executing the CA’s signing process; A success or failure indicator when performing certificate revocation; and The identity of the entity and/or operator that caused the event. A message from any source requesting an action by the CA is an auditable event; the corresponding audit record must also include message date and time, source, destination, and contents. The CA shall record the events identified in the list below. Where these events cannot be electronically logged, the CA shall supplement electronic audit logs with physical logs as necessary. SECURITY AUDIT: Any changes to the Audit parameters, e.g., audit frequency, type of event audited Any attempt to delete or modify the Audit logs Obtaining a third-party time-stamp IDENTIFICATION AND AUTHENTICATION: Successful and unsuccessful attempts to assume a role The value of maximum authentication attempts is changed Maximum authentication attempts unsuccessful authentication attempts occur during user login An Administrator unlocks an account that has been locked as a result of unsuccessful authentication attempts An Administrator changes the type of authentication, e.g., from a password to biometricLOCAL DATA ENTRY:All security-relevant data that is entered in the system REMOTE DATA ENTRY: All security-relevant messages that are received by the system DATA EXPORT AND OUTPUT: All successful and unsuccessful requests for confidential and security-relevant information KEY GENERATION: Whenever the Component generates a key. (Not mandatory for single session or one-time use symmetric keys) PRIVATE KEY LOAD AND STORAGE: The loading of Component private keys All access to certificate subject private keys retained within the CA for key recovery purposes TRUSTED PUBLIC KEY ENTRY, DELETION AND STORAGE: All changes to the trusted public keys, including additions and deletions SECRET KEY STORAGE: The manual entry of secret keys used for authentication PRIVATE AND SECRET KEY EXPORT: The export of private and secret keys (keys used for a single session or message are excluded) CERTIFICATE REGISTRATION: All certificate requests CERTIFICATE REVOCATION: All certificate revocation requests CERTIFICATE STATUS CHANGE APPROVAL: The approval or rejection of a certificate status change request CA CONFIGURATION: Any security-relevant changes to the configuration of the Component ACCOUNT ADMINISTRATION: Roles and users are added or deleted The access control privileges of a user account or a role are modified CERTIFICATE PROFILE MANAGEMENT: All changes to the certificate profile REVOCATION PROFILE MANAGEMENT: All changes to the revocation profile CERTIFICATE STATUS AUTHORITY MANAGEMENT: All changes to the OCSP profile MISCELLANEOUS: Appointment of an individual to a trusted role Designation of personnel for multiparty control Installation of the operating system Installation of the PKI Application Installing hardware cryptographic modules Removing hardware cryptographic modules Destruction of cryptographic modules System startup Logon attempts to PKI applications Receipt of hardware / software Attempts to set passwords Attempts to modify passwords Backing up CA internal database Restoring CA internal database Restoration from backup of the internal CA databaseFile manipulation (e.g., creation, renaming, moving) Posting of any material to a PKI repository Access to CA internal database All certificate compromise notification requests Loading tokens with certificates Shipment of tokens Zeroizing and destroying tokens Re-key of the Component Configuration changes: Hardware SoftwareOperating system Patches Security profiles PHYSICAL ACCESS / SITE SECURITY: Personnel access to room housing Component Access to the Component Known or suspected violations of physical security ANOMALIES: Software error conditions Software check integrity failures Receipt of improper messages Misrouted messages Network attacks (suspected or confirmed) Equipment failure Electrical power outages Uninterruptible power supply (UPS) failure Obvious and significant network service or access failures Violations of Certificate Policy Violations of Certification Practice Statement Resetting Operating System clock Frequency of Processing LogAudit logs shall be reviewed at least once every 30 days, unless the CA is off-line, in which case the audit logs shall be reviewed when the system is activated or every 30 days, whichever is later. Such reviews involve verifying that the log has not been tampered with and then briefly inspecting all log entries, with a more thorough investigation of any alerts or irregularities in the logs. A statistically significant portion of the security audit data generated by the CA since the last review shall be examined. This amount will be described in the CPS.All significant events shall be explained in an audit log summary. Actions taken as a result of these reviews shall be documented.Retention Period for Audit LogAudit logs shall be retained on-site until reviewed, in addition to being archived as described in section REF _Ref435705096 \r \h 5.5. The individual who removes audit logs from the CA system shall be an official different from the individuals who, in combination, command the CA signature key.Protection of Audit LogThe security audit data shall not be open for reading or modification by any human, or by any automated process, other than those that perform security audit processing. CA system configuration and procedures must be implemented together to ensure that only authorized people archive or delete security audit data. Procedures must be implemented to protect archived data from deletion or destruction before the end of the security audit data retention period (note that deletion requires modification access). Security audit data shall be moved to a safe, secure storage location separate from the location where the data was generated.Audit Log Backup ProceduresAudit logs and audit summaries shall be backed up at least monthly. A copy of the audit log shall be sent off-site on a monthly basis.Audit Collection System (Internal vs. External)The audit log collection system may or may not be external to the CA system. Automated audit processes shall be invoked at system or application startup, and cease only at system or application shutdown. Audit collection systems shall be configured such that security audit data is protected against loss (e.g., overwriting or overflow of automated log files). Should it become apparent that an automated audit system has failed, and the integrity of the system or confidentiality of the information protected by the system is at risk, operations shall be suspended until the problem has been remedied.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 AssessmentsThe CA shall perform routine self-assessments of security controls for vulnerabilities. Events in the audit process are logged, in part, to monitor system vulnerabilities. The assessments shall be performed following an examination of these monitored events. The assessments shall be based on real-time automated logging data and shall be performed at least on an annual basis as input into an entity’s annual Compliance Audit.The audit data should be reviewed by the security auditor for events such as repeated failed actions, requests for privileged information, attempted access of system files, and unauthenticated responses. Security auditors should check for continuity of the audit data.Records ArchivalTypes of Events ArchivedCA archive records shall be sufficiently detailed to determine the proper operation of the CA and the validity of any certificate (including those revoked or expired) issued by the CA. At a minimum, the following data shall be recorded for archive:Certificate policy Certification practice statement Contractual obligations and other agreements concerning operations of the CA System and equipment configuration Modifications and updates to system or configuration Certificate requests All certificates issued and/or published Record of CA re-key Revocation requests Subscriber identity authentication data as per section 3.2.3.Documentation of receipt and acceptance of certificates (if applicable) Subscriber agreements Documentation of receipt of tokens All CRLs issued and/or published Other data or applications to verify archive contents Compliance Auditor reports Any changes to the Audit parameters, e.g. audit frequency, type of event audited Any attempt to delete or modify the Audit logs Whenever the CA generates a key (Not mandatory for single session or one-time use symmetric keys) The export of private and secret keys (keys used for a single session or message are excluded) The approval or rejection of a certificate status change request Appointment of an individual to a Trusted Role Destruction of cryptographic modules All certificate compromise notifications Retention Period for ArchiveArchive records must be kept for a minimum of 10 years and 6 months.Protection of ArchiveNo unauthorized user shall be permitted to write to, modify, or delete the archive. For the CA, archived records may be moved to another medium. The contents of the archive shall not be released except in accordance with sections 9.3 and 9.4. Records of individual transactions may be released upon request of any subscribers involved in the transaction or their legally recognized agents. Archive media shall be stored in a safe, secure storage facility separate from the CA. Archive media shall be stored in a safe, secure storage facility separate from the PKI components with physical and procedural security controls equivalent or better than those of the PKI.Archive Backup ProceduresNo stipulation.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.Archive Collection System (Internal or External)No stipulation.Procedures to Obtain and Verify Archive InformationProcedures, detailing how to create, verify, package, transmit, and store the CA archive information, shall be published in the CPS.Key ChangeoverTo minimize risk from compromise of a CA’s private signing key, that key may be changed often. From that time on, only the new key will be used to sign CA and subscriber certificates. If the old private key is used to sign OCSP responder certificates or CRLs that cover certificates signed with that key, the old key must be retained and protected. The CA’s signing key shall have a validity period as described in section REF _Ref435707518 \r \h 6.3.2. When a CA updates its private signature key and thus generates a new public key, the CA shall notify all CAs, Sub-CAs, and subscribers that rely on the CA’s certificate that it has been changed. When a CA that distributes self-signed certificates updates its private signature key, the CA shall generate key rollover certificates, where the new public key is signed by the old private key, and vice versa. This permits acceptance of newly issued certificates and CRLs without distribution of the new self-signed certificate to current users. Key rollover certificates are optional for CAs that do not distribute self-signed certificates. Compromise and disaster recoveryIncident and Compromise Handling ProceduresEach organization operating an Entity PKI shall have a formal disaster recovery plan.The Policy Authority shall be notified if any CAs operating under this policy experience the following:suspected or detected compromise of the CA systems;suspected or detected compromise of a certificate status server (CSS) if (1) the CSS certificate has a lifetime of more than 72 hours and (2) the CSS certificate cannot be revoked (e.g., an OCSP responder certificate with the id-pkix-ocsp-nocheck extension);physical or electronic penetration of CA systems;successful denial of service attacks on CA components; orany incident preventing the CA from issuing a CRL within 48 hours of the issuance of the previous CRL.The Policy Authority will take appropriate steps to protect the integrity of the PKI.The CA’s Management Authority shall reestablish operational capabilities as quickly as possible in accordance with procedures set forth in the CA's 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 subscribers’’ interests as Relying Parties.If the ability to revoke certificates is inoperative or damaged, the CA shall reestablish revocation capabilities as quickly as possible in accordance with procedures set forth in the respective CPS. If the CA’s revocation capability cannot be established in a reasonable time-frame, the CA shall determine whether to request revocation of its certificate(s). If the CA is a Root CA, the CA shall determine whether to notify all subscribers that use the CA as a trust anchor to delete the trust anchor.Entity (CA) Private Key Compromise ProceduresIf a CA’s signature keys are compromised, lost, or suspected of compromise:All cross certified CAs shall be securely notified at the earliest feasible time (so that entities may issue CRLs revoking any cross-certificates issued to the CA);The CA must generate new keys in accordance with section REF _Ref435709282 \r \h 6.1.1.1.If the CA distributed the private key in a Trusted Certificate, the CA shall perform the following operations:Generate a new Trusted Certificate.Securely distribute the new Trusted Certificate as specified in section REF _Ref435709315 \r \h 6.1.4.Initiate procedures to notify subscribers of the compromise.Subscriber certificates may be renewed automatically by the CA under the new key pair (see section REF _Ref435709353 \r \h 4.6), or the CA may require subscribers to repeat the initial certificate application process.Business Continuity Capabilities after a DisasterIn the case of a disaster whereby the CA installation is physically damaged and all copies of the CA signature key are destroyed as a result, the CA shall request revocation of its certificates. Further, the CA shall re-establish operations by following the procedures for CA key loss or compromise detailed in Section REF _Ref435710944 \r \h 5.7.3 above.Relying parties may decide of their own volition whether to continue to use certificates signed with the destroyed private key pending reestablishment of CA operation with new certificates.CA TerminationWhen a CA operating under this policy terminates operations before all certificates have expired, the CA signing keys shall be surrendered to the Policy Authority.Prior to CA termination, the CA shall provide archived data as specified in the CPS. As soon as possible, the CA will advise all other organizations to which it has issued certificates of its termination, using an agreed-upon method of communication specified in the CPS.TECHNICAL SECURITY CONTROLSKey Pair Generation and InstallationKey Pair GenerationKey pair generation shall be performed using FIPS 140 approved cryptographic modules and processes that provide the required cryptographic strength of the generated keys and prevent the loss, disclosure, modification, or unauthorized use of private keys. Any pseudo-random numbers use and parameters for key generation material shall be generated by a FIPS-approved method.CA Key Pair GenerationCryptographic keying material used by CAs to sign certificates, CRLs, or status information shall be generated in FIPS 140 approved cryptographic modules that shall be at least FIPS 140 Level 3. Key pairs for Sub-CAs requesting a medium-assurance hardware Certificate under this CP must be generated in a hardware cryptographic module rated at least FIPS 140 Level 2.CA keys shall be generated in a Key Generation Ceremony using multi-person control for CA key pair generation, as specified in CP section 6.2.2. CA key pair generation must create a verifiable audit trail that the security requirements for procedures were followed. The documentation of the procedure must be detailed enough to show that appropriate role separation was used. An independent third party shall validate the execution of the key generation procedures either by witnessing the key generation or by examining the signed and documented record of the key generation.Subscriber Key Pair GenerationSubscriber key pair generation may be performed by the subscriber, CA, or Sub-CA. If the CA or Sub-CA generates subscriber key pairs, the requirements for key pair delivery specified in section REF _Ref435107078 \r \h 6.1.2 must also be met.Key pairs for subscribers requesting a medium-assurance hardware certificate must be generated in a hardware cryptographic module rated at least FIPS 140 Level 2.NOTE: The ATA Specification states subscriber private keys will only be generated by the subscriber and never by the CA. The Federal Bridge PKI CP allows end user key generation by the CA/RA. So this next section aligns with the Federal Bridge policy (more flexible) but can be removed to follow the ATA Specification if desired.Private Key Delivery to SubscriberSubscriber key pair generation may be performed by the Subscriber. In this case, the private key delivery to a Subscriber is unnecessary.When CAs generate key pairs on behalf of the Subscriber, the private keys must be delivered securely to the Subscriber and the following requirements must be met:The CA shall not retain any copy of the key after delivery of the private key to the subscriber.CAs shall use Trustworthy Systems to deliver private keys to Subscribers and shall secure such delivery through the use of a PKCS#8 package or, at the CAs sole discretion, any other comparably equivalent means (e.g., PKCS#12 package) in order to prevent the loss, disclosure, modification, or unauthorized use of such private keys.Where key pairs are pre-generated on hardware cryptographic modules, the entities distributing such modules shall use best efforts to provide physical security of the modules to prevent the loss, disclosure, modification, or unauthorized use of the private keys.The subscriber shall acknowledge receipt of the private key(s).Delivery shall be accomplished in a way that ensures that the certificates and associated private keys are provided to the correct subscribers. For hardware cryptographic modules, accountability for the location and state of the module must be maintained until the subscriber accepts possession of it. For electronic delivery of private keys, the key material shall be encrypted using a cryptographic algorithm and key size at least as strong as the private key. Activation data shall be delivered using a separate secure channel. Public Key Delivery to Certificate IssuerWhen a public key is transferred to the issuing CA to be certified, it shall be delivered through a mechanism validating the identity of the Subscriber and ensuring that the public key has not been altered during transit and that the Certificate Applicant possesses the private key corresponding to the transferred public key. The Certificate Applicant shall deliver the public key in a PKCS#10 Certificate Signing Request package or an equivalent method ensuring that the public key has not been altered during transit; and the Certificate Applicant possesses the private key corresponding to the transferred public key. CA Public Key Delivery to Relying PartiesCA public key certificates shall be delivered to relying parties in a secure fashion to preclude substitution attacks. Acceptable methods for certificate delivery are: Loading the CA certificate onto tokens delivered to relying parties via secure mechanisms.The CA Certificate is delivered as part of a subscriber’s certificate request. Secure distribution of CA certificates through secure out-of-band mechanisms.Downloading the CA certificates from trusted web sites (CA or PKI-PA web site).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 SEQ Table \* ARABIC 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) public key parameters shall be selected from the set specified in CP section 7.1.3.Key Usage Purposes (as per X.509 v3 Key Usage Field)The use of a specific key is constrained by the key usage extension in the X.509 certificate. All certificates shall include a critical key usage extension. 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 SEQ Table \* ARABIC 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 SetPublic keys that are bound into subscriber certificates shall be used only for signing or encrypting, but not both. REF _Ref346813873 \h Table 3 shows the specific keyUsage extension settings for AeroMACS Subscriber signature certificates that contain ECC public keys and specifies that all Subscriber certificates that contain ECC public keys: Shall include a keyUsage extensionShall set the criticality of the keyUsage extension to TRUEShall assert the digitalSignature bitShall assert the nonRepudiation bitTable SEQ Table \* ARABIC 3: keyUsage Extension for all Subscriber Signature CertificatesFieldFormatCriticalityValueCommentkeyUsageBIT STRINGTRUE{ id-ce 15 }Included in all Subscriber certificates digitalSignature(0)1Set nonRepudiation(1)1 Set keyEncipherment(2)0Not Set dataEncipherment(3)0 Not Set keyAgreement(4)0 Not Set keyCertSign(5)0Not Set cRLSign(6)0Not Set encipherOnly(7)0Not Set decipherOnly(8)0Not Set REF _Ref346817182 \h Table 4 shows the specific keyUsage extension settings for AeroMACS key management certificates that contain ECC public keys and specifies that all key management certificates that contain ECC public keys: Shall include a keyUsage extensionShall set the criticality of the keyUsage extension to TRUEShall assert the keyAgreement bitTable SEQ Table \* ARABIC 4: keyUsage Extension for all Key Management CertificatesFieldFormatCriticalityValueCommentkeyUsageBIT STRINGTRUE{ id-ce 15 }Included in all Subscriber certificates digitalSignature(0)0Not Set 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 Set REF _Ref346817182 \h Table 4 shows the specific keyUsage extension settings for AeroMACS Server certificates that contain ECC public keys and specifies that all Server certificates that contain ECC public keys: Shall include a keyUsage extensionShall set the criticality of the keyUsage extension to TRUEShall assert the digitalSignature bitShall assert the keyAgreement bitTable SEQ Table \* ARABIC 5: keyUsage Extension for all Server 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]. Root CAs shall perform all CA cryptographic operations on cryptographic modules approved at a minimum of FIPS 140-2 level 3 or higher. Sub-CAs shall use a FIPS 140-2 Level 2 or higher approved hardware cryptographic module. Subscribers with low- or medium-assurance software certificates shall use a FIPS 140-2 Level 1 or higher approved cryptographic module for their cryptographic operations.All other entities, including Subscribers with medium-assurance hardware certificates shall use a FIPS 140-2 Level 2 or higher approved cryptographic module for all private key operations.Servers should use a FIPS 140-2 Level 1 or higher approved cryptographic module for their cryptographic operations.Private Key (n out of m) Multi-Person ControlMulti-person control is enforced to protect the activation data needed to activate CA private keys so that a single person shall not be permitted to activate or access any cryptographic module that contains the complete CA private signing key. CA signature keys may be backed up only under multi-person control. Access to CA signing keys backed up for disaster recovery shall be under multi-person control. The names of the parties used for multi-person control shall be maintained on a list that shall be made available for inspection during compliance audits.CAs may use “Secret Sharing” to split the private key or activation data needed to operate the private key into separate parts called “Secret Shares” held by individuals called “Shareholders.” Some threshold number of Secret Shares (m) out of the total number of Secret Shares (n) shall be required to operate the private key. The minimum threshold number of shares (m) needed to sign a CA certificate shall be 3. The total number of shares (n) used shall be greater than the minimum threshold number of shares (m).CAs may also use Secret Sharing to protect the activation data needed to activate private keys located at their respective disaster recovery sites. The minimum threshold number of shares (m) needed to sign a CA certificate at a disaster recovery site shall be 3. The total number of shares (n) used shall be greater than the minimum threshold number of shares (m).Private Key EscrowCA private signature keys and Subscriber private signatures keys shall not be escrowed.If the CA retains subscriber private encryption keys for business continuity purposes, the CA shall escrow such subscriber private encryption keys to protect them from unauthorized modification or disclosure through physical and cryptographic means.Private Key BackupCAs shall back up their private keys, under the same multi-person control as the original signature key. The backups allow the CA to be able to recover from disasters and equipment malfunction. At least one copy of the private signature key shall be stored off-site. Private keys that are backed up shall be protected from unauthorized modification or disclosure through physical or cryptographic means. Backups, including all activation data needed to activate the cryptographic module containing the private key, shall be protected with a level of physical and cryptographic protection equal to or exceeding that for cryptographic modules within the CA site, such as at a disaster recovery site or at another secure off-site facility, such as a bank safe. All copies of the CA private signature key shall be accounted for and protected in the same manner as the original.Device private keys may be backed up or copied, but must be held under the control of the Subscriber or other authorized administrator. Backed up device private keys shall not be stored in plaintext form and storage must ensure security controls consistent with the security specifications the device is compliant with. Subscribers may have the option of using enhanced private key protection mechanisms available today including the use of smart cards, biometric access devices, and other hardware cryptographic modules to store private keys.Private Key ArchivalCA private signature keys and subscriber private signatures keys shall not be archived. If the CA retains subscriber private encryption keys for business continuity purposes, the CA shall archive such subscriber private keys, in accordance with CP section 5.5.Upon expiration of a CA Certificate, the key pair associated with the certificate will be securely retained for a period of at least 5 years using hardware cryptographic modules that meet the requirements of this CP. These CA key pairs shall not be used for any signing events after the expiration date of the corresponding CA Certificate, unless the CA Certificate has been renewed in terms of this CP.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. Processing Centers generating CA or Sub-CA private keys on one hardware cryptographic module and transferring them into another shall securely transfer such private keys into the second cryptographic module to the extent necessary to prevent loss, theft, modification, unauthorized disclosure, or unauthorized use of such private keys. Such transfers shall be limited to making backup copies of the private keys on tokens. CAs pre-generating private keys and transferring them into a hardware cryptographic module, for example transferring generated end-user Subscriber private keys into a smart card, shall securely transfer such private keys into the module to the extent necessary to prevent loss, theft, modification, unauthorized disclosure, or unauthorized use of such private keys.Private Key Storage on Cryptographic ModuleNo stipulation beyond that specified in FIPS 140-2.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.Subscriber Private KeysThe AeroMACS standards for protecting activation data for Subscribers’ private keys shall be in accordance with the specific obligations appearing in the applicable agreement executed between AeroMACS and the Subscriber.For device certificates, the device may be configured to activate its private key, provided that appropriate physical and logical access controls are implemented for the device. The strength of the security controls shall be commensurate with the level of threat in the device’s environment, and shall protect the device’s hardware, software, private keys and its activation data from compromise.Method of Deactivating Private KeyCryptographic modules that have been activated shall not be available to unauthorized access. After use, the cryptographic module shall be deactivated, e.g., via a manual logout procedure or automatically after a period of inactivity. CA cryptographic modules shall be stored securely when not in use.When an online CA is taken offline, the CA shall remove the token containing the private key from the reader in order to deactivate it.With respect to the private keys of offline CAs, after the completion of a Key Generation Ceremony, in which such private keys are used for private key operations, the CA shall remove the token containing the private keys from the reader in order to deactivate them. Once removed from the reader, tokens shall be securely stored.When an online CA is taken offline, the CA shall remove the token containing such CA’s private key from the reader in order to deactivate it.When deactivated, private keys shall be kept in encrypted form only.Method of Destroying Private KeyPrivate keys shall be destroyed in a way that prevents their theft, disclosure, or unauthorized use.Upon termination of the operations of a CA or Sub-CA, individuals in trusted roles shall decommission the CA/Sub-CA private signature keys by deleting it using functionality of the token containing such CA/Sub-CA’s private key so as to prevent its recovery following deletion, or the loss, theft, modification, disclosure, or unauthorized use of such private key. CA/Sub-CA private keys shall be destroyed in a manner that reasonably ensures that there are no residuals remains of the key that could lead to the reconstruction of the key.For Root CAs, PKI-PA security personnel shall witness this process.Subscribers may destroy their private signature keys when they are no longer needed or when the certificates to which they correspond expire or are revoked. Physical destruction of hardware is not required.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.Certificate Operational Periods and Key Pair Usage PeriodsThe certificate validity period (i.e., certificate and key pair usage period) shall be set to the time limits set forth as follows:Root CA certificates shall have a validity period of up to 30 yearsSub-CA certificates shall have a validity period of up to 20 yearsSubscriber certificates shall have a validity period of up to 10 years (e.g., 1 to 2 year server certs, 3 year aircraft certs, up to 10 years for long lived certs)Validity periods shall be nested such that the validity periods of issued certificates shall be contained within the validity period of the issuing CA.AeroMACS PKI Participants shall cease all use of their key pairs after their validity periods have expired.Activation dataActivation Data Generation and InstallationCAs shall generate and install activation data for their private keys and shall use methods that protect the activation data to the extent necessary to prevent the loss, theft, modification, disclosure, or unauthorized use of such activation data.To the extent passwords are used as activation data, CAs activation participants shall generate passwords that cannot easily be guessed or cracked by dictionary attacks. Participants may not need to generate activation data, for example if they use biometric access devices. Activation Data ProtectionCAs shall protect the activation data for their private keys using methods that protect against the loss, theft, modification, unauthorized disclosure, or unauthorized use of such private keys.CAs shall use multi-party control in accordance with CP section?6.2.2. CAs shall provide the procedures and means to enable Shareholders to take the precautions necessary to prevent the loss, theft, modification, disclosure, or unauthorized use of the Secret Shares that they possess. Shareholders shall not:Copy, disclose, or make the Secret Share available to a third party, or make any unauthorized use of it whatsoever; orDisclose their or any other person’s status as a Shareholder to any third party.The Secret Shares and any information disclosed to the Shareholder in connection with their duties as a Shareholder shall constitute Confidential/Private Information.CAs shall include in their disaster recovery plans provisions for making Secret Shares available at a disaster recovery site after a disaster (Note, the important aspect of disaster recovery vis-à-vis shares is that a process exists for making the necessary number of shares available, even if the requisite shareholders are not available.). CAs shall maintain an audit trail of Secret Shares, and Shareholders shall participate in the maintenance of an audit trail.Other Aspects of Activation DataActivation Data TransmissionTo the extent activation data for private keys are transmitted, Activation Data Participants shall protect the transmission using methods that protect against the loss, theft, modification, unauthorized disclosure, or unauthorized use of such private keys. To the extent desktop computer or network logon user name/password combination is used as activation data for an end-user Subscriber, the passwords transferred across a network shall be protected against access by unauthorized users. Activation Data DestructionActivation data for CA private keys shall be decommissioned using methods that protect against the loss, theft, modification, unauthorized disclosure, or unauthorized use of the private keys protected by such activation data. After the record retention periods in CP section 5.5.2 lapses, CAs shall decommission activation data by overwriting and/or physical puter security controlsSpecific Computer Security Technical RequirementsCAs shall ensure that the systems maintaining CA software and data files are Trustworthy Systems secure from unauthorized access, which can be demonstrated by compliance with audit criteria applicable under CP section 5.4.1. In addition, CAs shall limit access to production servers to those individuals with a valid business reason for access. General application users shall not have accounts on the production servers.CAs shall have production networks logically separated from other components. This separation prevents network access except through defined application processes. CAs shall use firewalls to protect the production network from internal and external intrusion and limit the nature and source of network activities that may access production systems.To the extent that passwords are used, CAs shall require the use of passwords with a minimum character length and a combination of alphanumeric and special characters, and shall require that passwords be changed on a periodic basis and whenever necessary. Direct access to a CA’s database maintaining the CA’s repository shall be limited to Trusted Persons having a valid business reason for such puter security controls are required to ensure CA operations are performed as specified in this policy. The following computer security functions may be provided by the operating system, or through a combination of operating system, software, and physical safeguards: Require authenticated logins Provide discretionary access control Provide a security audit capability Enforce access control for CA services and PKI roles Enforce separation of duties for PKI roles Require identification and authentication of PKI roles and associated identities Prohibit object reuse or require separation for CA random access memory Require use of cryptography for session communication and database security Archive CA history and audit data Require self-test security-related CA services Require a trusted path for identification of PKI roles and associated identities Require a recovery mechanism for keys and the CA system Enforce domain integrity boundaries for security-critical processes. For other CAs operating under this policy, the computer security functions listed below are required. These functions may be provided by the operating system, or through a combination of operating system, software, and physical safeguards. The CA and its ancillary parts shall include the following functionality:Authenticate the identity of users before permitting access to the system or applications; Manage privileges of users to limit users to their assigned roles; Generate and archive audit records for all transactions; (see CP section 5.4) Enforce domain integrity boundaries for security critical processes; and Support recovery from key or system failure. For certificate status servers operating under this policy, the computer security functions listed below are required: Authenticate the identity of users before permitting access to the system or applications; Manage privileges of users to limit users to their assigned roles; Enforce domain integrity boundaries for security critical processes; and Support recovery from key or system failure. For remote workstations used to administer the CAs, the computer security functions listed below are required:Authenticate the identity of users before permitting access to the system or applications; Manage privileges of users to limit users to their assigned roles; Generate and archive audit records for all transactions; (see CP section 5.4) Enforce domain integrity boundaries for security critical processes; and Support recovery from key or system failure. All communications between any PKI trusted role and the CA shall be authenticated and protected from puter Security RatingNo Stipulation.Life Cycle Technical ControlsSystem Development ControlsThe system development controls for the CA and Sub-CA are as follows: The CA shall use software that has been designed and developed under a formal, documented development methodology. Hardware and software procured to operate the CA shall be purchased in a fashion to reduce the likelihood that any particular component was tampered with (e.g., by ensuring the vendor cannot identify the PKI component that will be installed on a particular device).Hardware and software developed specifically for the CA shall be developed in a controlled environment, and the development process shall be defined and documented. This requirement does not apply to commercial off-the-shelf hardware or software. The CA hardware and software shall be dedicated to performing one task: the CA. There shall be no other applications, hardware devices, network connections, or component software installed that are not parts of the CA operation. Where the CA operation supports multiple CAs, the hardware platform may support multiple CAs. Proper care shall be taken to prevent malicious software from being loaded onto the CA equipment. All applications required to perform the operation of the CA shall be obtained from documented sources. Hardware and software updates shall be purchased or developed in the same manner as original equipment, and shall be installed by trusted and trained personnel in a defined manner.Security Management ControlsThe configuration of the CA system, in addition to any modifications and upgrades, shall be documented and controlled. There shall be a mechanism for detecting unauthorized modification to the software or configuration. The CA software, when first loaded, shall be verified as being that supplied from the vendor, with no modifications, and be the version intended for use.Life Cycle Security ControlsNo work Security ControlsA network guard, firewall, or filtering router must protect network access to CA equipment. The network guard, firewall, or filtering router shall limit services allowed to and from the CA equipment to those required to perform CA functions. Protection of CA equipment shall be provided against known network attacks. All unused network ports and services shall be turned off. Any network software present on the CA equipment shall be necessary to the functioning of the CA application. Any boundary control devices used to protect the network on which PKI equipment is hosted shall deny all but the necessary services to the PKI equipment. Repositories, certificate status servers, and remote workstations used to administer the CAs shall employ appropriate network security controls. Networking equipment shall turn off unused network ports and services. Any network software present shall be necessary to the functioning of the equipment. The CA shall establish connection with a remote workstation used to administer the CA only after successful authentication of the remote workstation at a level of assurance commensurate with that of the CA.Time-StampingCertificates, CRLs, and other revocation database entries shall contain time and date information. Such time information need not be cryptographic-based. Asserted times shall be accurate to within three minutes. Electronic or manual procedures may be used to maintain system time. Clock adjustments are auditable events (see CP section 5.4.1).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 _Ref347304371 \h Table 6).Table SEQ Table \* ARABIC 6: 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.3 See 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 7 shows the certificate extensions for all AeroMACS Root CA certificates.Table SEQ Table \* ARABIC 7: Root CA Certificate Standard ExtensionsFieldReferenced StandardSectionRequirement or RecommendationsubjectKeyIdentifier[RFC 5280]4.2.1.2See REF _Ref347308192 \h \* MERGEFORMAT Table 10.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 _Ref346820185 \h \* MERGEFORMAT Table 11. REF _Ref435449433 \h Table 8 shows the certificate extensions for all AeroMACS sub-CA certificates.Table SEQ Table \* ARABIC 8: Sub-CA Certificate Standard ExtensionsFieldReferenced StandardSectionRequirement or RecommendationauthorityKeyIdentifier[RFC 5280]4.2.1.1Shall be included in sub-CA certificates.Criticality shall be set to FALSE.subjectKeyIdentifier[RFC 5280]4.2.1.2See REF _Ref347308192 \h \* MERGEFORMAT Table 10.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 sub-CA certificates.Criticality shall be set to FALSE.basicConstraints[RFC 5280]4.2.1.9See REF _Ref346898413 \h \* MERGEFORMAT Table 12.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 9 shows the certificate extensions for all AeroMACS subscriber certificates.Table SEQ Table \* ARABIC 9: Subscriber Certificate Standard ExtensionsFieldReferenced StandardSectionRequirement or RecommendationauthorityKeyIdentifier[RFC 5280]4.2.1.1Shall be included in Subscriber 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 _Ref348459685 \h \* MERGEFORMAT Table 13 for server certificates.See REF _Ref348459853 \h \* MERGEFORMAT Table 14 for client certificates.crlDistributionPoints[RFC 5280]This extension must appear in all CA certificates and must contain at least one URI either HTTP or LDAP. The reasons and cRLIssuer Fields must be omitted. REF _Ref434911848 \h Table 10 shows the certificate extensions for all AeroMACS OCSP server certificates.Table SEQ Table \* ARABIC 10: 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 11 shows the subjectKeyIdentifier extension settings for AeroMACS CA certificates and specifies that all AeroMACS Root and sub-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 SEQ Table \* ARABIC 11: subjectKeyIdentifier Extension for AeroMACS CA CertificatesFieldFormatCriticalityValueCommentsubjectKeyIdentifier FALSE{ id-ce 14 }Included in all CA certificates keyIdentifierOCTET STRING <key identifier>Calculated per Method 1.Subscriber Certificates shall not include the subjectKeyIdentifier extension.Basic Constraints Extension REF _Ref435449240 \h Table 12 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 SEQ Table \* ARABIC 12: basicConstraints Extension for AeroMACS Root CA CertificatesFieldFormatCriticalityValueCommentbasicConstraintsTRUE{ id-ce 19 }Included in all Root certificates cABOOLEANTRUESet pathLenConstraintINTEGERNot Set REF _Ref435449252 \h Table 13 shows the basicConstraints extension settings for AeroMACS sub-CA certificates and specifies that all AeroMACS sub-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 SEQ Table \* ARABIC 13: basicConstraints Extension for AeroMACS Sub-CA CertificatesFieldFormatCriticalityValueCommentbasicConstraintsTRUE{ id-ce 19 }Included in all sub-CA certificates cABOOLEANTRUESet pathLenConstraintINTEGER0Subscriber 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 14 shows the extKeyUsage extension settings for AeroMACS Subscriber server certificates (e.g., VTN certificate) and specifies that all AeroMACS server certificates:May include the extKeyUsage extensionIf included, shall set the criticality of the extKeyUsage extension to FALSEShall set the keyPurposeId field of the extKeyUsage to id-kp-serverAuthTable SEQ Table \* ARABIC 14: extKeyUsage Exstension for AeroMACS Server CertificatesFieldFormatCriticalityValueCommentextKeyUsageFALSE{ id-ce 37 }May be included in Subscriber server certificates. keyPurposeIDOID1.3.6.1.5.5.7.3.1id-kp-serverAuth REF _Ref435449315 \h Table 15 shows the extKeyUsage extension settings for AeroMACS Subscriber client certificates and specifies that all AeroMACS client 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 15: extKeyUsage Exstension for AeroMACS Client CertificatesFieldFormatCriticalityValueCommentextKeyUsageFALSE{ id-ce 37 }May be included in Subscriber client 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 16).Table SEQ Table \* ARABIC 16: 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 17).Table SEQ Table \* ARABIC 17: subjectPublicKeyInfo for CertificateFieldFormatCriticalityValueCommentsubjectPublicKeyInfo algorithm algorithmIdentifier algorithmOID1.2.840.10045.2.1EC Public Key parametersANY1.2.840.10045.3.1.7secp256r11.3.132.0.34ansip384r1 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 SEQ Table \* ARABIC 18: 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)Sub-CAsThe following naming attributes shall be used to populate the sub-CA Certificate subject fields issued under this CP:Table SEQ Table \* ARABIC 19: Sub-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> Sub-CAShall contain a name that accurately identifies the CA. (e.g. CompanyA Sub CA)Subscriber CertificatesThe following naming attributes shall be used to populate the Subject in Subscriber Certificates issued under this CP: Table SEQ Table \* ARABIC 20: Subscriber Certificate subject FieldsNameFieldValueRequirement countryName(C=)<Country Name>Shall be the two-letter ISO 3166-1 country code for the country in which the Subscriber’s place of business is anizationName(O=)<Organization>Shall contain the Subscriber 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>Shall contain the device MAC Address 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 IdentifierThe certificate policy object identifier for this CP is defined in the ATA Specification section 1.2.2. REF _Ref435449366 \h Table 21 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 SEQ Table \* ARABIC 21: certificatePolicies Extension for AeroMACS CertificatesFieldFormatCriticalityValueCommentcertificatePoliciesFALSE{ id-ce 32 }May be included in all AeroMACS certificates policyInformation policyIdentifierOID<Certificate policy OID>See ATA Specification section REF _Ref347333576 \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 ExtensionCertificates issued under this policy shall not contain a critical certificate policies extension.CRL ProfileCRLs shall conform to [RFC 5280] and contain the basic fields and contents specified in the table below:Table SEQ Table \* ARABIC 22: 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 (Online Certificate Status Protocol) is a way to obtain timely information about the revocation status of a particular certificate. OCSP Responses must conform to [RFC5019] and must either be:Signed by the CA that issued the Certificates whose revocation status is being checked, or Signed by an OCSP Responder whose Certificate is signed by the CA that issued the Certificate whose revocation status is being checked. Such OCSP Responder signing Certificate shall contain the extension id-pkix-ocsp-nocheck as defined by [RFC2560]. 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 AssessmentCAs and Sub-CAs operating under this policy shall be subject to a periodic compliance audit at least once per year. Identity/Qualifications of AssessorThe compliance auditor must demonstrate competence in the field of compliance audits, and must be thoroughly familiar with the CA’s CPS and this CP. The compliance auditor must perform such compliance audits as a regular ongoing business activity. In addition to the previous requirements, the auditor must be a certified information system auditor (CISA) or IT security specialist, and a PKI subject matter specialist who can offer input regarding acceptable risks, mitigation strategies, and industry best practices.Assessor's Relationship to Assessed EntityThe compliance auditor shall either represent a firm, which is independent from the entity being audited, or it shall be sufficiently organizationally separated from that entity to provide an unbiased, independent evaluation. An example of the latter situation may be an organizational audit department provided it can demonstrate organizational separation and independence. To further insure independence and objectivity, the compliance auditor may not have served the entity in develo0ping or maintaining the entity’s PKI Facility, associated IT and network systems, or certificate practices statement. The Policy Authority shall determine whether a compliance auditor meets this requirement.In the event an entity chooses to engage compliance auditor services internal to its parent organization, it shall undergo an audit from an external third party audit firm every third year, at a 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 Policy Authority, and any additional MOAs between the PKI and other Entities. The compliance audit must include an assessment of the applicable CPS against the applicable CP, to determine that the CPS adequately addresses and implements the requirements of the CP.Actions Taken as a Result of DeficiencyWhen the compliance auditor finds a discrepancy between the requirements of this CP or the stipulations in the CPS and the design, operation, or maintenance of the PKI Authorities, the following actions shall be performed: The compliance auditor shall note the discrepancy; The compliance auditor shall notify the responsible party promptly; and The party responsible for correcting the discrepancy shall determine what further notifications or actions are necessary pursuant to the requirements of the applicable CP and the Agreement, and then proceed to make such notifications and take such actions without delay.Depending upon the nature and severity of the discrepancy, and how quickly it can be corrected, the Policy Authority may decide to temporarily halt operation of the CA or Sub-CA, to revoke a certificate issued to the CA or Sub-CA, or take other actions it deems appropriate. The Policy Authority will develop procedures for making and implementing such determinations. In accordance with section 8.1, a compliance audit may be required to confirm the implementation and effectiveness of the 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 Policy Authority as set forth in Section REF _Ref435452404 \r \h 8.1. This package shall be prepared in accordance with the Policy Authority and must include an assertion from the Entity PKI PMA that all PKI components have been audited – including any components that may be separately managed and operated. The package shall identify the versions of this CP and CPS used in the assessment. Additionally, where necessary, the results shall be communicated as set forth in Section 8.5 above.Other Business and Legal MattersFeesFinancial ResponsibilityConfidentiality of business informationPrivacy of Personal InformationIntellectual Property RightsRepresentations and WarrantiesDisclaimers of warrantiesLimitations of liabilityIndemnitiesTerm and terminationIndividual notices and communications with participantsAmendmentsDispute Resolution ProvisionsGoverning LawCompliance with Applicable LawMiscellaneous provisionsOther ProvisionsReferencesRFC 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:Audit Requirements GuideA document that sets forth the security and audit requirements and practices for AeroMACS CAs.CertificateA message that, at least, states a name or identifies the CA, identifies the Subscriber, contains the Subscriber’s public key, identifies the Certificate’s Validity Period, contains a Certificate serial number, and is digitally signed by the CA that issued the certificate.Certificate 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 Subscriber 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 Subscriber, 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 Subscriber, 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 Subscriber requesting the device certificate.SubscriberThe entity who requests a Certificate (e.g., a manufacturer). The Subscriber is capable of using, and is authorized to use, the private key that corresponds to the public key listed in the Certificate.Subscriber AgreementAn agreement used by a CA setting forth the terms and conditions under which an individual or organization acts as a Subscriber.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:CA Certification AuthorityCP Certificate PolicyCPSCertification Practice StatementCRACertificate Requesting AccountCRLCertificate Revocation ListCSRCertificate Signing RequestDRDemand 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 AssessmentMFGManufacturerOIDObject IdentifierPAPolicy AuthorityPKCSPublic-Key Cryptography StandardPKIPublic Key InfrastructureRFCRequest for commentRSARivest, Shamir, AdelmanSASStatement on Auditing Standards (promulgated by the American Institute of Certified Public Accountants) ................
................

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

Google Online Preview   Download