WiMAX Forum Device PKI Certificate Policy Draft Specification

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.12468910WiMAX Forum DevicePKI Certificate PolicyDraft SpecificationVersion 1.0.1April 22 nd , 2008WiMAX Forum ProprietaryCopyright © 2008 WiMAX Forum. All Rights Reserved.WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.1111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455Copyright Notice, Use Restrictions, Disclaimer, and Limitation of Liability.Copyright 2007-2008 WiMAX Forum. All rights reserved.The WiMAX Forum ® owns the copyright in this document and reserves all rights herein. This document is available fordownload from the WiMAX Forum and may be duplicated for internal use, provided that all copies contain all proprietary noticesand disclaimers included herein. Except for the foregoing, this document may not be duplicated, in whole or in part, ordistributed 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 acceptanceof the following terms and conditions:THIS DOCUMENT IS PROVIDED “AS IS” AND WITHOUT WARRANTY OF ANY KIND. TO THE GREATESTEXTENT PERMITTED BY LAW, THE WiMAX FORUM DISCLAIMS ALL EXPRESS, IMPLIED ANDSTATUTORY WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF TITLE,NONINFRINGEMENT, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE WiMAXFORUM DOES NOT WARRANT THAT THIS DOCUMENT IS COMPLETE OR WITHOUT ERROR ANDDISCLAIMS ANY WARRANTIES TO THE CONTRARY.Any products or services provided using technology described in or implemented in connection with this document may besubject to various regulatory controls under the laws and regulations of various governments worldwide. The user is solelyresponsible for the compliance of its products and/or services with any such laws and regulations and for obtaining any and allrequired authorizations, permits, or licenses for its products and/or services as a result of such regulations within the applicablejurisdiction.NOTHING IN THIS DOCUMENT CREATES ANY WARRANTIES WHATSOEVER REGARDING THEAPPLICABILITY OR NON-APPLICABILITY OF ANY SUCH LAWS OR REGULATIONS OR THE SUITABILITYOR NON-SUITABILITY OF ANY SUCH PRODUCT OR SERVICE FOR USE IN ANY JURISDICTION.NOTHING IN THIS DOCUMENT CREATES ANY WARRANTIES WHATSOEVER REGARDING THESUITABILITY OR NON-SUITABILITY OF A PRODUCT OR A SERVICE FOR CERTIFICATION UNDER ANYCERTIFICATION PROGRAM OF THE WiMAX FORUM OR ANY THIRD PARTY.The WiMAX Forum has not investigated or made an independent determination regarding title or noninfringement ofanytechnologies that may be incorporated, described or referenced in this document. Use of this document or implementation ofany technologies described or referenced herein may therefore infringe undisclosed third-party patent rights or other intellectualproperty 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 WITHRESPECT TO ANY TECHNOLOGIES, STANDARDS OR SPECIFICATIONS REFERENCED OR INCORPORATEDINTO THIS DOCUMENT.IN NO EVENT SHALL THE WiMAX FORUM OR ANY MEMBER BE LIABLE TO THE USER OR TO A THIRDPARTY 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 INTELLECTUALPROPERTY RIGHTS OR THAT IT FAILS TO COMPLY WITH APPLICABLE LAWS OR REGULATIONS. BYUSE OF THIS DOCUMENT, THE USER WAIVES ANY SUCH CLAIM AGAINST THE WiMAX FORUM AND ITSMEMBERS 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 issolely 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,” theWiMAX Forum logo and the WiMAX Forum Certified logo are trademarks of the WiMAX Forum. Third-party trademarkscontained in this document are the property of their respective owners.Page - iiWiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.15657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106TABLE OF CONTENTS1. INTRODUCTION ..............................................................................................................................................11.1 OVERVIEW ..................................................................................................................................................11.2 DOCUMENT NAME AND IDENTIFICATION.....................................................................................................11.3 PKI PARTICIPANTS......................................................................................................................................11.3.1 Policy Authority.....................................................................................................................................11.3.2 Certification Authorities ........................................................................................................................11.3.3 Registration Authority............................................................................................................................31.3.4 Certificate Subjects................................................................................................................................31.3.5 Relying Parties.......................................................................................................................................31.3.6 OCSP Responder ...................................................................................................................................41.3.7 Other Participants .................................................................................................................................41.4 CERTIFICATE USAGE ...................................................................................................................................41.5 POLICY ADMINISTRATION ...........................................................................................................................41.6 DEFINITIONS AND ACRONYMS.....................................................................................................................52. PUBLICATION AND REPOSITORY RESPONSIBILITIES.......................................................................72.1 REPOSITORIES .............................................................................................................................................72.2 PUBLICATION OF CERTIFICATION INFORMATION.........................................................................................72.3 TIME OR FREQUENCY OF PUBLICATION.......................................................................................................72.4 ACCESS CONTROLS ON REPOSITORIES.........................................................................................................73. IDENTIFICATION AND AUTHENTICATION ............................................................................................83.1 NAMING ......................................................................................................................................................83.1.1 Types of Names......................................................................................................................................83.1.2 Meaningfulness......................................................................................................................................83.1.3 Anonymity or Pseudonymity of Certificate Subjects ..............................................................................83.1.4 Rules for Interpreting Various Name Forms .........................................................................................93.1.5 Uniqueness of Names.............................................................................................................................93.1.6 Recognition, Authentication, and Role of Trademarks ..........................................................................93.2 INITIAL IDENTITY VALIDATION ...................................................................................................................93.2.1 Method to Prove Possession of Private Key ..........................................................................................93.2.2 Authentication of Organization Identity ................................................................................................93.2.3 Authentication of Individual Identity ...................................................................................................103.2.4 Non-verified Certificate Subject Information ......................................................................................103.2.5 Validation of Authority ........................................................................................................................103.2.6 Criteria for Interoperation...................................................................................................................103.3 IDENTIFICATION AND AUTHENTICATION FOR RE-KEY REQUESTS..............................................................103.3.1 Identification and Authentication of Re-Key and Renewal Requests...................................................103.3.2 Identification and Authentication of Re-Key and Renewal After Revocation ......................................103.4 IDENTIFICATION AND AUTHENTICATION FOR REVOCATION REQUEST.......................................................114. CERTIFICATE LIFE-CYCLE.......................................................................................................................124.1 CERTIFICATE APPLICATION.......................................................................................................................124.1.1 Who Can Submit a Certificate Application..........................................................................................124.1.2 Enrollment Process and Responsibilities.............................................................................................124.2 CERTIFICATE APPLICATION PROCESSING ..................................................................................................124.2.1 Performing Identification and Authentication Functions ....................................................................124.2.2 Approval or Rejection of Certificate Applications...............................................................................124.2.3 Time to Process Certificate Applications.............................................................................................124.3 CERTIFICATE ISSUANCE.............................................................................................................................124.3.1 CA Actions During Certificate Issuance..............................................................................................124.3.2 Notification to Certificate Subject of Certificate Issuance...................................................................13Page - iiiWiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.11631641651661671681691701711721731741751761771781791801811821831841851861871881891901911921931941951961971981992002012022032042052062072082092102112122132142152165. MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS .......................................................195.1 PHYSICAL CONTROLS................................................................................................................................195.1.1 Site Location and Construction ...........................................................................................................195.1.2 Physical Access....................................................................................................................................195.1.3 Power and Air Conditioning................................................................................................................195.1.4 Water Exposures..................................................................................................................................205.1.5 Fire Prevention and Protection ...........................................................................................................205.1.6 Media Storage......................................................................................................................................205.1.7 Waste Disposal ....................................................................................................................................205.1.8 Off-Site backup ....................................................................................................................................205.2 PROCEDURAL CONTROLS ..........................................................................................................................205.2.1 Trusted Roles .......................................................................................................................................205.2.2 Number of Persons Required Per Task................................................................................................215.2.3 Identification and Authentication for Each Role .................................................................................215.2.4 Roles Requiring Separation of Duties..................................................................................................215.3 PERSONNEL CONTROLS .............................................................................................................................215.3.1 Qualifications, Experience, and Clearance Requirements ..................................................................215.3.2 Background Check Procedures............................................................................................................215.3.3 Training Requirements ........................................................................................................................215.3.4 Retraining Frequency and Requirements ............................................................................................215.3.5 Job Rotation Frequency and Sequence................................................................................................215.3.6 Sanctions for Unauthorized Actions ....................................................................................................225.3.7 Independent Contractor Requirements ................................................................................................225.3.8 Documentation Supplied to Personnel.................................................................................................225.4 AUDIT LOGGING PROCEDURES..................................................................................................................225.4.1 Types of Events Recorded ....................................................................................................................225.4.2 Frequency of Processing Log ..............................................................................................................235.4.3 Retention Period for Audit Log............................................................................................................235.4.4 Protection of Audit Log........................................................................................................................235.4.5 Audit Log Backup Procedures .............................................................................................................235.4.6 Audit Collection System (Internal vs. External)...................................................................................235.4.7 Notification to Event-Causing Subject.................................................................................................235.4.8 Vulnerability Assessments....................................................................................................................235.5 RECORDS ARCHIVE ...................................................................................................................................245.5.1 Types of Events Archived.....................................................................................................................245.5.2 Retention Period for Archive ...............................................................................................................245.5.3 Protection of Archive...........................................................................................................................245.5.4 Archive Backup Procedures.................................................................................................................245.5.5 Requirements for Time-Stamping of Records ......................................................................................245.5.6 Archive Collection System (Internal or External)................................................................................245.5.7 Procedures to Obtain and Verify Archive Information........................................................................245.6 KEY CHANGEOVER....................................................................................................................................255.7 COMPROMISE AND DISASTER RECOVERY..................................................................................................255.7.1 Incident and Compromise Handling Procedures.................................................................................255.7.2 Computing Resources, Software, and/or Data Are Corrupted ............................................................255.7.3 CA Private Key Compromise Procedures............................................................................................255.7.4 Business Continuity Capabilities After a Disaster...............................................................................255.8 CA AND RA TERMINATION .......................................................................................................................256. TECHNICAL SECURITY CONTROLS .......................................................................................................266.1 KEY PAIR GENERATION AND INSTALLATION.............................................................................................266.1.1 Key Pair Generation............................................................................................................................266.1.2 Private Key Delivery to Certificate Subject.........................................................................................266.1.3 Public Key Delivery to Certificate Issuer ............................................................................................266.1.4 CA Public Key Delivery to Relying Parties .........................................................................................26Page - vWiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.12172182192202212222232242252262272282292302312322332342352362372382392402412422432442452462472482492502512522532542552562572582592602612622632642652666.1.5 Key Sizes..............................................................................................................................................266.1.6 Public Key Parameters Generation and Quality Checking .................................................................266.1.7 Key Usage Purposes (as per X.509v3 key usage field)........................................................................266.2 PRIVATE KEY PROTECTION AND CRYPTOGRAPHIC MODULE ENGINEERING CONTROLS............................276.2.1 Cryptographic Module Standards and Controls..................................................................................276.2.2 Private Key Multi-Person Control.......................................................................................................276.2.3 Private Key Escrow .............................................................................................................................276.2.4 Private Key Backup .............................................................................................................................276.2.5 Private Key Archival............................................................................................................................276.2.6 Private Key Transfer into or from a Cryptographic Module...............................................................276.2.7 Private Key Storage on Cryptographic Module...................................................................................276.2.8 Method of Activating Private Keys ......................................................................................................276.2.9 Methods of Deactivating Private Keys.................................................................................................286.2.10 Method of Destroying Private Key..................................................................................................286.2.11 Cryptographic Module Rating ........................................................................................................286.3 OTHER ASPECTS OF KEY MANAGEMENT...................................................................................................286.3.1 Public Key Archival.............................................................................................................................286.3.2 Certificate Operational Periods/Key Usage Periods...........................................................................286.4 ACTIVATION DATA....................................................................................................................................286.4.1 Activation Data Generation and Installation.......................................................................................286.4.2 Activation Data Protection ..................................................................................................................286.4.3 Other Aspects of Activation Data ........................................................................................................286.5 COMPUTER SECURITY CONTROLS .............................................................................................................296.5.1 Specific Computer Security Technical Requirements ..........................................................................296.5.2 Computer Security Rating....................................................................................................................296.6 LIFE-CYCLE SECURITY CONTROLS............................................................................................................306.6.1 System Development Controls .............................................................................................................306.6.2 Security Management Controls............................................................................................................306.6.3 Life Cycle Security Ratings..................................................................................................................306.7 NETWORK SECURITY CONTROLS...............................................................................................................306.8 TIME STAMPING ........................................................................................................................................317. CERTIFICATE, CARL/CRL, AND OCSP PROFILES FORMAT ............................................................327.1 CERTIFICATE PROFILE...............................................................................................................................327.2 CRL PROFILE ............................................................................................................................................327.3 OCSP PROFILE..........................................................................................................................................327.4 SCVP PROFILE..........................................................................................................................................328. COMPLIANCE AUDIT AND OTHER ASSESSMENTS ............................................................................338.1 FREQUENCY OF AUDIT OR ASSESSMENTS..................................................................................................338.2 IDENTITY & QUALIFICATIONS OF ASSESSOR .............................................................................................338.3 ASSESSOR’S RELATIONSHIP TO ASSESSED ENTITY....................................................................................338.4 TOPICS COVERED BY ASSESSMENT...........................................................................................................338.5 ACTIONS TAKEN AS A RESULT OF DEFICIENCY ........................................................................................338.6 COMMUNICATION OF RESULTS..................................................................................................................339. OTHER BUSINESS AND LEGAL MATTERS ............................................................................................349.1 FEES ..........................................................................................................................................................349.1.1 Certificate Issuance/Renewal Fees......................................................................................................349.1.2 Certificate Access Fees........................................................................................................................349.1.3 Revocation or Status Information Access Fee .....................................................................................349.1.4 Fees for other Services ........................................................................................................................349.1.5 Refund Policy.......................................................................................................................................34Page - viWiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.1321322323TABLE OF FIGURESFigure 1 - Device PKI....................................................................................................................................................2Figure 2 - Server PKI.....................................................................................................................................................3Page - viiiWiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.13243253263273283291. IntroductionThis chapter identifies and introduces the set of provisions, and indicates the types of entities and applications forwhich the WiMAX Certificate Policy (CP) is targeted.The WiMAX CP is written for WiMAX Forum® products.The WiMAX CP is consistent with the Internet Engineering Task Force (IETF) Public Key Infrastructure X.509(PKIX) Certificate Policy and Certification Practices Framework as described in RFC 3647.3303313323333343351.1 OverviewThe WiMAX CP is written for WiMAX Forum® products. The WiMAX CP defines the policy under which theWiMAX Public Key Infrastructure (PKI) issues Public Key Certificates (PKCs) to Manufacturer CAs, their DeviceSub-CAs, and finally Devices. This CP also addresses PKCs issued to support Server CAs and Server certificates.The WiMAX PKI enables mutual authentication of devices and networks via EAP. Digital signatures as well asencryption are employed.3363373381.2 Document Name and IdentificationThis CP is known as the “WiMAX Device CP.” The Device PKI will use the OID { 1.3.6.1.4.1.24757.1.1 } toindicate the certificates issued under this CP.3393403413423433443453463473483493503513523533541.3 PKI ParticipantsThe following are roles relevant to the administration and operation of the WiMAX PKI.1.3.1 Policy AuthorityThe Policy Authority (PA) is the entity that approves this device certificate policy. The PA is the WiMAX ForumBoard.The WiMAX PA also approves all agreements (i.e., CP, Certification Practice Statement (CPS), relying partyagreements, and Certificate Subject agreements) that affect the Server PKI (see sections 1.3.2, 1.3.4, and 1.3.5).The WiMAX PA MAY delegate these functions to a committee or a specific individual or individuals.1.3.2 Certification AuthoritiesThe CA is responsible for all aspects of the issuance and management of a PKC including:• Registration,• Identification and authentication,• Issuance, and• Ensuring that all aspects of the CA services and CA operations and infrastructure related to PKCs issuedunder the WiMAX CP are performed in accordance with the requirements, representations, and warrantiesof their WiMAX CPS.Page - 1WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.1355356357358359360361362363364365366367368369370CAs that support WiMAX can be divided into two categories:• Device CAs are those that are part of the Certification Path that issues Device PKCs (see Figure 1):o Device Root CA is the entity that creates, signs, and issues PKCs to Manufacturer CAs. DeviceRoot CAs are identified by the WiMAX PA, and there MAY be more than one Device Root CA.o Device Manufacturer CAs are entities that create, sign, and issue PKCs to Devices. ManufacturerCAs can also create, sign, and issue PKCs to Device Sub-CAs.o (optional) Device Sub-CA, when they are used, are entities that create, sign, and issue PKCs toDevices.• Server CAs are those that are part of the Certification Path that issues Server PKCs (see Figure 2):o Server Root CA is the entity that creates, signs, and issues PKCs to Server CAs. There will be atleast one Server Root CA.o Server CAs are the entities that create, sign, and issue PKCs to Servers. Server CAs can alsocreate, sign, and issue PKCs to server Sub-CAs.o (optional) Server Sub-CA, when they are used, are entities that create, sign, and issue PKCs toServers.Server CAs SHALL NOT issue Device PKCs. Device CAs and Device Sub-CAs SHALL NOT issue Server PKCs.Length 4 Chain3 Level CA TreeLength 3 Chain2 Level CA Tree371372Figure 1 - Device PKIPage - 2WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.1Server Certificate ChainServer RootCA CertificateServerCA CertificateServerCertificateLength 3 Chain2 Level CA TreeIssueIssue373Length 4 Chain3LevelCATreeServer RootCA CertificateIssueServerCA CertificateIssueServer Sub-CA CertificateIssueServerCertificate374375376377378379380381382383384385386387388389390391392393394395396397398399400Figure 2 - Server PKIIn the remainder of this document, the term CA only applies to Device CAs and it does not apply to Server CAs.Distinction between Device Root CA, Device Manufacturer CA, and Device Sub-CA is only made when therequirements are different for a type of CA.Agreements (i.e., CP, CPS, relying party agreements, and Certificate Subject agreements) that apply to Device CAsMUST be approved by the WiMAX PA. The approved CP will be publicly available by the WiMAX Forum PA.The CPS may be kept private or made publicly available at the discretion of WiMAX Forum PA.1.3.3 Registration AuthorityNo stipulation. If procedures and practices make use of a Registration Authority (RA), then the CPS MUST specifythe manner in which the RA is used.1.3.4 Certificate SubjectsA Certificate Subject is the entity’s whose name appears in the subject in a PKC and who asserts that the PKC andthe keying material will be used in accordance with the WiMAX CP. Like the CAs, they are categorized in one oftwo ways:• Devices are issued PKCs from the Device PKI to gain access to Servers following device authentication viaEAP-TLS or EAP-TTLS methods as specified in [NWG Rel 1.0 Stage 3 Specification].• Servers are issued PKCs from the Server PKI to grant access to Devices via EAP-TLS or EAP-TTLSmethods as specified in [NWG Rel 1.0 Stage 3 Specification].In this CP, none of the various types of CAs or OCSP responders is referred to as Certificate Subjects. Only endentitycertificate holders are referred to as Certificate Subjects. In the remainder of this document, the termCertificate Subject refers to Devices.Agreements (i.e., CP, CPS, relying party agreements, and Certificate Subject agreements) that apply to a Server’sPKC MUST be approved by the WiMAX PA.1.3.5 Relying PartiesIn WiMAX environment, Servers are Relying Parties of the Device PKI, and Devices are Relying Parties of theServer PKI. In the remainder of this document, the term Relying Parties only applies to Servers that validatecertificates issued to Devices in conformance with this certificate policy.Page - 3WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.1401402403404405406407408409Agreements (i.e., CP, CPS, relying party agreements, and Certificate Subject agreements) that apply to a Server’sPKC MUST be approved by the WiMAX PA.1.3.6 OCSP ResponderThe CA operator runs the OCSP responder or arranges for a third party to do so on its behalf. OCSP responders acton behalf of CAs for a single purpose - signing OCSP response. Therefore, in the remainder of this document,OCSP responders are not addresses as separate entities from the CAs that they support unless the requirementsdiffer.1.3.7 Other ParticipantsNo stipulation.4104114124134144154164174184191.4 Certificate UsageThe WiMAX CP object identifier (OID) defined in this document (see Section 1.2) SHALL only be used for thefollowing purposes:• WiMAX Device Manufacturer CAs and Device Sub-CAs SHALL issue PKCs only to support WiMAXDevices, to issue revocation information, and to issue OCSP responder certificates. All other uses ofWiMAX Device Manufacturer CA PKCs or Device Sub-CA PKCs are expressly prohibited.• WiMAX Devices SHALL use their PKC only to establish a connection with WiMAX Servers. All otheruses of a WiMAX Device PKC are expressly prohibited.• WiMAX OCSP responders SHALL use their PKC only to generate OCSP responses for WiMAX Devicesand/or Servers.4204214224234244254261.5 Policy AdministrationThe WiMAX Forum is responsible for all aspects of this CP and approval of all Server PKI related agreements. Oneimportant aspect of this policy administration will be the identification of Device Root CAs.All communications regarding this CP should be directed to:WiMAX Forum2495 Leghorn StreetMountain View, CA 94043Page - 4WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.14274284294304314324334344354364374384394404414424434444454464474481.6 Definitions and AcronymsABADSGCACPCPSCRLDNEAPEAP-TLSI&AIETFOCSPOIDPAPKCPKIRPRASCVPSPTLSArchiveAdministratorAuditAuditorAudit DataBackupCertification Authority (CA)Certificate (or Public KeyCertificate)Cryptographic ModuleDeviceAmerican Bar Association Digital Signature GuidelinesCertification AuthorityCertificate PolicyCertification Practice StatementCertificate Revocation ListDistinguished NameExtensible Authentication ProtocolExtensible Authentication Protocol - Transport Layer SecurityIdentification and AuthenticationInternet Engineering Task ForceOnline Certificate Status ProtocolObject IdentifierPolicy AuthorityPublic Key CertificatePublic Key InfrastructureRelying PartyRegistration AuthorityServer-based Certificate Verification ProtocolService PartyTransport Layer SecurityLong-term, physically separate storage.A trusted role that installs, configures, and maintains the CA.Independent review and examination of records and activities to assess theadequacy of system controls, to ensure compliance with established policies andoperational procedures, and to recommend necessary changes in controls, policies,or procedures.A trusted role that performs the Audit.Chronological record of system activities to enable the reconstruction andexamination of the sequence of events and changes in an event.Copy of files and programs made to facilitate recovery if necessary.The CA is responsible for all aspects of the issuance and management of a PKCincluding: registration, identification and authentication, issuance, and ensuringthat all aspects of the CA services and CA operations and infrastructure related toPKCs issued under the WiMAX CP are performed in accordance with therequirements, representations, and warranties of their WiMAX CPS.A digital representation of information which at least (1) identifies the certificationauthority issuing it, (2) names or identifies its Certificate Subject, (3) contains theCertificate Subject's public key, (4) identifies its operational period, and (5) isdigitally signed by the certification authority issuing it [ABADSG].The set of hardware, software, firmware, or some combination thereof thatimplements cryptographic logic or processes, including cryptographic algorithms,and is contained within the cryptographic boundary of the module [FIPS140].An entity that uses EAP with a Server for authentication prior to gaining networkaccess.Page - 5WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.1Extensible AuthenticationProtocol - Transport LayerSecurityPKC holderNational Archive and RecordsAdministration (NARA)ServerThe Extensible Authentication Protocol (EAP) provides a standard mechanism forsupport of multiple authentication methods. The use of EAP allows support for anumber of authentication schemes. The WiMAX Forum plans to use EAP-TLS,EAP-TTLS and IEEE 802.16, as specified in [NWG Rel 1.0 Stage 3Specification].An entity that is control of the private key associated with a PKC.US Federal Agency responsible for identifying federal records management andretention policies.An entity that uses EAP to grant a Device network access.Page - 6WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.14494502. Publication and Repository ResponsibilitiesThis chapter specifies requirements for publication of PKCs and CRLs in a repository.4514524534544554564574582.1 RepositoriesServer accessible repositories MUST be maintained. Device CA and Device Sub-CA PKCs and their revocationinformation are published in this repository.2.2 Publication of Certification InformationDevice CA and Device Sub-CA PKCs MUST be published in the repository. No stipulation for Device PKCs.Revocation information SHALL be published in a Certificate Revocation List (CRL) and SHALL also be availablevia the Online-Certificate Status Protocol (OCSP). 1 It MAY also be available via the Server-based CertificateVerification Protocol (SCVP). 24594604614624634642.3 Time or Frequency of PublicationCAs SHALL promptly publish Device CA and Device Sub-CA PKCs after they are generated. No stipulation forDevice PKCs.CAs SHALL promptly publish CRLs after they are generated. In the absence of a revocation event, update CRLsSHALL be published at least quarterly by Device Root CAs and Manufacturer CAs and at least monthly by DeviceSub-CAs.4654662.4 Access Controls on RepositoriesNo stipulation.1 Profiles for WiMAX Forum CRLs and OCSP requests and responses are in section 7.2 Profiles for WiMAX Forum SCVP requests and responses are in section 7.Page - 7WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.14674684693. Identification and AuthenticationThis chapter specifies the requirements for Identification and Authentication (I&A) of the Certificate Subject andCA.4703.1 Naming4714724734744754764774784794804814824834844854864874884894904914924934944954964974984995005015025035043.1.1 Types of NamesWithin the Device PKI, the Certificate Subject Name MUST be an X.501 Distinguished Name (DN) carried in thePKC. The following SHALL be the name forms:• Device Root CA: C=US, O=WiMAX Forum(R), CN=WiMAX Forum(R) Device Root-CA• Device Manufacturer CA: C=, O=, OU=WiMAX Forum(R) Devices,CN=• Device Sub-CA: C=, O=, OU=WiMAX Forum(R) Devices, OU=, CN=orDevice Sub-CA: C=, O=, OU=WiMAX Forum(R) Devices, L=, CN=• Device: C=, O=, OU=WiMAX Forum(R) Devices,CN=o The following optional naming elements MAY be included between the OU=WiMAX Forum(R)Devices and CN= naming elements. They MAY appear in any order: OU=chipsetID: ,OU=modelIndex:, OU=revision:, OU=sku:,OU=productID:, OU=prodManufacturer:.• OCSP Responder:o For Root CAs: C=US, O=WiMAX Forum(R), CN=Device OCSP Responder-o For Device Manufacturer CAs: C=, O=, OU=WiMAX Forum(R)Devices, CN=OCSP Responder-When the naming element is DirectoryString (i.e., O=, OU=, and L=) either PrintableString or UTF8String MUSTbe used. The following determines which choice is used:• PrintableString only if it is limited to the following subset of US ASCII characters (as required by ASN.1):A, B, …, Za, b, …, z0, 1, …9,(space) ‘ ( ) + , - . / : = ?• UTF8String for all other cases, e.g., subject name attributes with any other characters or for internationalcharacter sets.3.1.2 MeaningfulnessNames SHALL be meaningful and unambiguously identify all entities with PKCs.3.1.3 Anonymity or Pseudonymity of Certificate SubjectsNames SHALL NOT be anonymous or be a pseudonym.Page - 8WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.15055065075085095105115125135145155165175185195205213.1.4 Rules for Interpreting Various Name FormsSee Section 3.1.1.3.1.5 Uniqueness of NamesNames SHALL be unique across the whole WiMAX Device PKI.3.1.6 Recognition, Authentication, and Role of TrademarksCAs SHALL NOT knowingly issue a PKC with a name that a court of competent jurisdiction has determinedinfringes on the trademark of another.Device Root CAs, Manufacturer Device CAs, Sub-CAs, and Device PKCs all include the string “WiMAX Forum(R)” in their name. A written agreement with the WiMAX Forum is needed to obtain authorization to use thistrademark-protected string.Device Root CAs issue PKCs to Device Manufacturer CAs that includes trademark-protected names, namely, themanufacturer’s name. The Device Root CAs MUST verify that applicant is authorized to request on behalf of themanufacturer.Device Manufacturer CAs MAY issue PKCs to Device Sub-CAs that include trademark-protected names; however,Device Manufacturer CAs SHALL only issue PKCs with subject names that use the same organization as the devicemanufacturer's CA name.. If the Device Manufacturer CAs includes a second organizational unit name that istrademarked, then the trademark MUST be owned by the Device Manufacturer.5223.2 Initial Identity Validation5235245255265275285295305315325335345355365375385395405415425433.2.1 Method to Prove Possession of Private KeyCAs SHALL generate their own keys. They MUST prove to the issuing CA that they possess the private keys thatcorresponds to the public keys in PKC requests.Devices MAY or MAY NOT generate their own keys:• If a Device generates its own key, then they MUST prove that they possess the private key that correspondsto the public key in PKC requests.• If a Device does not generate its own private key, then the key generation process and distribution processMUST be explained in the CPS. These processes MUST ensure that the private key is provided to theproper Device Manufacturer in a manner that protects the key from unauthorized disclosure andmodification. The Device Manufacturer MUST ensure that the proper key and certificate is installed in thecorresponding Device in a manner that protects the key from unauthorized disclosure and modification.The Device Manufacturer process MUST be documented.3.2.2 Authentication of Organization IdentityConfirm that the organization has authorized the application and that the person submitting the application isauthorized to do so. At a minimum, a letter from the manufacturer’s Chief Legal Officer (or other authorizedrepresentative recognized by WiMAX Forum's PA) required for authorization. At a minimum, the following MUSToccur:• Use a third party to confirm the organization exists; and• Confirm that the organization has authorized the application and that the person submitting the applicationis authorized to do so. At a minimum, a letter from the manufacturer’s Chief Legal Officer (or otherauthorized legal representative recognized by the WiMAX Forum) is required for authorization.Page - 9WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.1544545546547548549550551552553554555556557558559560561562563564565Manufacturer CAs that issue PKCs to Device Sub-CAs and Devices are exempt from these rules only when theyissue PKCs to Device Sub-CAs they control and Devices they manufacture.3.2.3 Authentication of Individual IdentityIssuing CA SHALL validate at least the identity in the "Manufacturer" field of device certificate issued. CA namesSHALL be validated by the issuing CA.3.2.4 Non-verified Certificate Subject InformationAll information SHALL be verified. Non-verified information SHALL NOT be included in PKCs.3.2.5 Validation of AuthorityDevice Root CAs SHALL verify that the manufacturer is a WiMAX Forum's PA's recognized manufacturer, and theletter from the manufacturer’s Chief Legal Officer (or other authorized representative recognized by WiMAXForum's PA) is valid. The Root CA SHALL have access to a list of approved Manufacturer maintained by theWiMAX Forum. This list SHALL be consulted prior to issuing a Device Manufacturer CA’s PKC.All the CAs in the device certificate chain SHALL take steps to ensure (and explain in their CPS) that there is onlyone valid device certificate for a particular MAC address. The Manufacturer MUST assert that it has ownership forthe MAC address.This section also applies to Manufacturer CA issuing sub-CA certificates outside of their control.3.2.6 Criteria for InteroperationWiMAX Device Manufacturer CAs and Device Sub-CAs SHALL issue PKCs only to support WiMAX Devices,issue revocation information, and to issue OCSP responder certificates. All other uses of WiMAX DeviceManufacturer CA PKCs or Device Sub-CA PKCs are expressly prohibited.WiMAX Devices SHALL use their PKC only to establish a connection with WiMAX Servers. All other uses of aWiMAX Device PKC are expressly prohibited.5665675685695705715725735745755765775785795803.3 Identification and Authentication for Re-key RequestsPrior to the expiration of an existing PKC, it is necessary to re-key or renew the PKC to maintain continuity of PKCusage. An overlap period is recommended to ensure continuity. This continuity is supported for DeviceManufacturer CAs and Sub-CAs with re-key (see Section 4.7).3.3.1 Identification and Authentication of Re-Key and Renewal RequestsThe superior CA SHALL be responsible for authentication a request for re-key. Re-key procedures ensure the entityrequesting the re-key is in fact the entity that is named in the PKC.The procedures for a re-key procedures are the same those for the original certificate.3.3.2 Identification and Authentication of Re-Key and Renewal After RevocationRe-key after revocation is not permitted if the revocation occurred for any of the following reasons:• The PKC was issued to an entity other than the one named as the Subject of the PKC.• The PKC was issued without the authorization of the entity named as the Subject of the PKC.• The entity approving the PKC application has reason to believe that a material fact in the PKC applicationis false.• The PKC was deemed by the WiMAX PA to be harmful to the WiMAX Forum.Page - 10WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.1581582Subject to the above bullets, re-key following revocation of the PKC is permissible as long as re-key proceduresensures that the entity seeking re-key is in fact the entity named in the PKC.5835845855865875883.4 Identification and Authentication for Revocation RequestWiMAX Forum PA, or recognized representative, or an authorized process from the manufacturer can requestrevocation and SHALL use their credentials to authenticate the request. The form of credential accepted by therevoking CA is based on CA CPS. A revocation request authentication MUST be properly verified before anapproval decision is made.The revocation of any CA require authorization from the WiMAX PA. See 4.9 for more information revocation.Page - 11WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.15895904. Certificate Life-CycleThis chapter specifies the requirements for PKC life-cycle management by all entities in the PKI.5914.1 Certificate Application5925935945955965975985996006016026036046054.1.1 Who Can Submit a Certificate ApplicationAll applications for a PKC from the Device PKI MUST come from WiMAX Forum Members. A recognizedmanufacturer representative can submit CA PKC applications. An authorized manufacturer representative, anauthorized manufacturer process, or a Device can submit Device PKC applications.4.1.2 Enrollment Process and ResponsibilitiesA recognized Device Manufacturer CAs SHALL provide their credentials to Device Root CAs to demonstrate theiridentity, to demonstrate their authority, and to provide contact information. Device Manufacturers receive andapprove requests from a recognized Device Sub-CAs representative and from an authorized manufacturerrepresentative, an authorized manufacturer process, or a Device.A recognized Device Sub-CAs representative SHALL provide their credentials to Device Manufacturer CAs todemonstrate their identity, to demonstrate their authority, and to provide contact information. Device Sub-CAsreceive and approve enrollments from an authorized manufacturer representative, an authorized manufacturerprocess, or a Device.There is no stipulation for Devices.6064.2 Certificate Application Processing6076086096106116126136146154.2.1 Performing Identification and Authentication FunctionsCAs SHALL verify and authenticate the identity of each applicant, as described in Section 3.2.4.2.2 Approval or Rejection of Certificate ApplicationsThe CA MAY approve or reject a certification request. Approval is granted if the applicant’s identity has beenauthenticated as described in Section 3.2, and payment, if required, has been received. Rejection is based inabilityto successfully authenticate the applicant, not receiving required information from the applicant, not paying for PKC(if required).4.2.3 Time to Process Certificate ApplicationsPKC requests SHALL be processed in a timely manner.6164.3 Certificate Issuance6176186196204.3.1 CA Actions During Certificate IssuanceThe CA SHALL verify and authenticate the source of each PKC request, ensure that the public key is bound to thecorrect applicant, obtain a proof of possession of the private key, generate a properly formed PKC, and provide thePKC to the applicant.Page - 12WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.16216226234.3.2 Notification to Certificate Subject of Certificate IssuanceThe CA SHALL Notify the applicant of PKC issuance by returning the PKC (and the corresponding private key, ifthe key was generated by the CA) to the applicant.6244.4 Certificate Acceptance6256266276286296306314.4.1 Conduct Constituting Certificate AcceptanceFailure to object to the PKC or its contents prior to use constitutes acceptance of the PKC.4.4.2 Publication of the Certificate by the CADevice Manufacturer CA and Device Sub-CA PKCs are published in a Server available repository.No stipulation for Device PKCs.4.4.3 Notification of Certificate Issuance by the CA to Other EntitiesNo stipulation.6324.5 Key Pair and Certificate Usage6336346356366376386396404.5.1 Certificate Subject Private Key and Certificate UsageCertificates and private keys SHALL be stored in Certificate Subjects in a secure manner. Only the Certificatesubject SHALL have the Certificate Subject private key. Certificate Subjects SHALL be responsible for andSHALL protect their private keys from access by other parties.Certificate Subjects SHALL only use private keys for purposes identified in Section 1.4.4.5.2 Relying Party Public Key and Certificate UsageRelying parties SHALL ensure that the public key in a PKC is used only for appropriate purposes as identified incritical certificate extensions (See Section 7).6416426436446456466476486494.6 Certificate RenewalPKC renewal is the issuance of a new PKC without changing the public key or any other information other than thevalidity dates and serial number in the PKC. PKC renewal is not supported.4.6.1 Circumstance for Certificate RenewalNo stipulation.4.6.2 Who May Request RenewalNo stipulation.4.6.3 Processing Certificate Renewal RequestsNo stipulation.Page - 13WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.16506516526536546556566574.6.4 Notification of New Certificate Issuance to Certificate SubjectNo stipulation.4.6.5 Conduct Constituting Acceptance of a Renewal CertificateNo stipulation.4.6.6 Publication of the Renewal Certificate by the CANo stipulation.4.6.7 Notification of Certificate Issuance by the CA to Other EntitiesNo stipulation.6586596606616626636646656666676686696706716726736746756766776786796806816824.7 Certificate Re-KeyPKC re-key is the application for the issuance of a new PKC that certifies a new public key. PKC re-key issupported for Device Manufacturer CAs and Device Sub-CAs. Device PKC rekeys are not supported.4.7.1 Circumstance for Certificate Re-keyWhen a Device Manufacturer CA PKC re-key is desired, it is necessary for the re-key to take place prior to theexpiration of an existing Device Manufacturer CA’s PKC to maintain continuity of PKC usage. An overlap period isrecommended to ensure continuity.When a Device Sub-CA PKC re-key is desired, it is necessary for the re-key to take place prior to the expiration ofan existing Device Sub-CA’s PKC to maintain continuity of PKC usage. An overlap period is recommended toensure continuity.Device Manufacturer CA PKCs and Device Sub-CA PKCs MAY also be rekeyed after expiration.4.7.2 Who May Request Certification of a New Public KeyAll requests for PKC re-keys MUST come from WiMAX Forum Members.A recognized manufacturer representative can submit Device Manufacturer CA and Device Sub-CA PKC re-keyrequests. This is a multiparty procedure as specified in Section 5.2.2 and requires a "Key Ceremony" as specified inSection 6.1.1.Device PKC rekeys are not supported.4.7.3 Processing Certificate Re-keying RequestsIn accordance with Section 4.2.4.7.4 Notification of New Certificate Issuance to Certificate SubjectIn accordance with Section 4.3.2.4.7.5 Conduct Constituting Acceptance of a Re-keyed CertificateIn accordance with Section 4.4.1.4.7.6 Publication of the Re-keyed Certificate by the CAIn accordance with Section 4.4.2.Page - 14WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.16836844.7.7 Notification of Certificate Issuance by the CA to Other EntitiesNo stipulation.6854.8 Modification6866876886896906916926936946956966976986994.8.1 Circumstance for Certificate ModificationPKC Modification is prohibited.4.8.2 Who May Request Certificate ModificationNo stipulation.4.8.3 Processing Certificate Modification RequestsNo stipulation.4.8.4 Notification of New Certificate Issuance to Certificate SubjectNo stipulation.4.8.5 Conduct Constituting Acceptance of Modified CertificateNo stipulation.4.8.6 Publication of the Modified Certificate by the CANo stipulation.4.8.7 Notification of Certificate Issuance by the CA to Other EntitiesNo stipulation.7007017027037047057067077087097107117127137147157167174.9 Certificate Revocation and SuspensionIn an event when certificate’s further use is deemed detrimental (e.g. when private key is lost or compromised), thecertificate can be declared invalid, or revoked. This section begins with a brief informative overview of revocation,and then formally describes corresponding operational procedures.PKC revocation information must be authenticated by the issuing CA to prevent DoS attacks, since inappropriatePKC revocation prevents the PKC owner from connecting to the network. The choice of the method ofdissemination of revocation information to relying parties is only the matter of efficiency. The WiMAX Forum usestwo of the most popular methods -- CRL and OCSP protocols. CRL is a CA-signed dated list of revoked certificateswhich is published regularly. OCSP is a protocol that relies on an online OCSP server, which provides signed datedstatements indicating whether a particular PKC is revoked. CRL and OCSP response are signed objects. Relyingparties can verify the signature on the CRL/OCSP response to determine whether it is valid.Because of connectivity and hardware specifics, device revocation information is more efficiently distributed byCRL. Indeed, servers have large storage and a fast persistent Internet connection. At the same time, server talks tomany devices, and much of the information included in the CRL is actually used. On the other hand, any particulardevice might usually connect to only a few servers. Moreover, the device’s network connectivity is achieved via theserver, and is slow. Downloading a potentially large CRL is often less efficient than a short OCSP message, withwhich the device is convinced that the server is not revoked. In the WiMAX Forum environment, both OCSP andCRLs are needed. When OCSP is used, the OCSP message may be periodically obtained by the server, andPage - 15WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.1718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755forwarded to the device as part of EAP. In this case, the Device need not ever interact with the OCSP server.However, direct interaction with the OCSP responder is also allowed. When OCSP is not used, the Device obtainsthe CRL via an unspecified method.There are many ways to implement OCSP. One example of a typical sequence of events following a decision torevoke a server’s PKC would be as follows. CA includes the PKC in the next CRL update, and updates its OCSPserver within the timeframe specified in the CA’s CPS. From that point on, the revoked server would not be able toobtain a new OCSP response that indicates the certificate is valid. The server would still be able to use the old oneuntil it expires (expiry periods will be specified in the CA’s CPS). After the OCSP response expiry, devices will notaccept the old OCSP response, and will reject EAP-(T)TLS sessions.Another example, a typical sequence of events following a decision to revoke a device’s PKC would be as follows.CA includes the PKC in the next CRL update, posted at its CRL URL. This update is downloaded by a serveraccording to its update schedule. From that point on, the servers will be aware that the PKC is revoked, and willreject EAP-(T)TLS session attempts.The following specifies formal operational requirements of PKC revocation procedures.4.9.1 Circumstances for RevocationA PKC SHALL be revoked when the binding between the subject and the subject’s public key within the PKC is nolonger considered valid (e.g., loss or comprise of the private key). PKCs will be revoked when the PA requests thata PKC be revoked, when the PKC holder submits an authenticated revocation request, and when the CA determinesa situation has occurred that MAY affect the integrity of the PKCs.4.9.2 Who Can Request RevocationAny PKC can be revoked upon the direction of the PA. Additionally:• Device Manufacturer operators MAY request revocation of their Device Manufacturer CA PKCs, DeviceSub-CA PKCs they issued, and Device PKCs they issued.• Device Sub-CA operators MAY request revocation of their Device Sub-CA PKCs and the Device PKCsthey issued.• Device PKCs MAY be revoked at the request of the Device Sub-CA operator when a situation has occurredthat MAY affect the integrity of the PKCs.• Certificate Subject PKCs MAY be revoked at the request of the PA, issuing CA, or certificate holder.4.9.3 Procedure for Revocation RequestPKCs SHALL be revoked upon receipt of sufficient evidence of compromise or loss of the corresponding privatekey. A request to revoke a PKC SHALL identify the PKC to be revoked, explain the reason for revocation, andallow the request to be authenticated (e.g., manually signed).Prior to revocation of Device CA or Device Sub-CA the WiMAX PA MUST authorize the revocation.4.9.4 Revocation Request Grace PeriodThe revocation request grace period is the time available to the PKC holder within which the PKC holder MUSTmake a revocation request after reasons for revocation have been identified.4.9.5 Time within which CA Must Process the Revocation RequestCAs MUST process revocation requests in a timely manner.Page - 16WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.17567577587597607617627637647657667677687697707717727737747757767777784.9.6 Revocation Checking Requirements for Relying PartiesIf the device is checking revocation of server certificate, it SHOULD use OCSP. If the server is checking revocationof device certificate, it MAY use OCSP.4.9.7 CRL Issuance FrequencyCRLs to be issued as described in Section 2.3.4.9.8 Maximum Latency for CRLsNo stipulation.4.9.9 On-line Revocation/Status Checking AvailabilityAn OCSP responder MUST be available 24x7 with minimal scheduled interruptions.4.9.10 On-line Revocation Checking RequirementsNo stipulation.4.9.11 Other Forms of Revocation Advertisements AvailableNo stipulation.4.9.12 Special Requirements Re Key CompromiseNo stipulation.4.9.13 Circumstances for SuspensionPKC suspension is prohibited.4.9.14 Who can Request SuspensionNo stipulation.4.9.15 Procedure for Suspension RequestNo stipulation.4.9.16 Limits on Suspension PeriodNo stipulation.7794.10 Certificate Status Services7807817827837844.10.1 Operational CharacteristicsThe status of PKCs is available via CRL through a Server available online repository. Server available OCSPresponders MUST also be provided.4.10.2 Service AvailabilityAn OCSP responder MUST be available 24x7 with scheduled interruptions.Page - 17WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.17857864.10.3 Optional FeaturesAn SCVP responder MAY be provided.7877884.11 End of SubscriptionSubscriptions SHALL end when a PKC is revoked or the PKC expiry time passes.7894.12 Key Escrow and Recovery7907914.12.1 Key Escrow and Recovery Policy and PracticesNo stipulation.7927934.12.2 Session Key Encapsulation and Recovery Policy and PracticesNo stipulation.Page - 18WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.17947957965. Management, Operational, and Physical ControlsThis chapter specifies the requirements for non-technical security controls used by the CA to securely perform thefunctions of key generation, subject authentication, PKC issuance, and PKC revocation.7975.1 Physical Controls7987998008018028038048058068078088098108118128138148158168178188198208218228238248258268278288298308315.1.1 Site Location and ConstructionThe location and construction of the facility that will house CA equipment and operations SHALL be in accordancewith that afforded the most sensitive business and financial information. CA operations SHALL be conducted withina physically protected environment that deters, prevents, and detects unauthorized use of, access to, or disclosure ofsensitive information and systems.5.1.2 Physical AccessThe physical security requirements pertaining to CAs are:• Ensure no unauthorized access to the hardware is permitted;• Ensure manual or electronic monitoring for unauthorized intrusion at all times;• Ensure an access log is maintained and inspected periodically; and,• Require two person physical access control to both the cryptographic module and computer system.When not in use:• Paper containing sensitive plain-text information SHALL be stored in secure containers;• Media storing Device Root CA private key material SHALL be deactivated. The media and the activationinformation (see Section 6.4) for the Device Root CA private keys SHALL be stored in a secure container.Activation data SHALL either be memorized, or recorded and stored in a manner commensurate with thesecurity afforded the cryptographic module, and SHALL NOT be stored with the cryptographic module.• Media storing CA private key material SHALL be deactivated. The media SHALL be encrypted. Theactivation information (see Section 6.4) for the CA private key SHALL be stored in a secure container.Activation data SHALL either be memorized, or recorded and stored in a manner commensurate with thesecurity afforded the cryptographic module, and SHALL NOT be stored with the cryptographic module.If the facility is not continuously attended, the last person to depart SHALL initial a sign-out sheet that indicates thedate and time, and asserts that all necessary physical protection mechanisms are in place and activated. A securitycheck of the facility housing the CA equipment 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 modulesare in place when “open”, and secured when “closed”; and for the CA, that all equipment other than therepository is shut down);• Any security containers are properly secured;• Physical security systems (e.g., door locks, vent covers) are functioning properly; and,• The area is secured against unauthorized access.5.1.3 Power and Air ConditioningThe facility that houses the CA equipment SHALL be supplied with power and air conditioning sufficient to create areliable operating environment.Page - 19WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.18328338348358368378388398408418428438448458468478488498508518528538548555.1.4 Water ExposuresFacilities that house CAs SHALL be installed such that it is not in danger of exposure to water (e.g., on tables orelevated floors). Moisture detectors SHALL be installed in areas susceptible to flooding. CA operators who havesprinklers for fire control SHALL have a contingency plan for recovery should the sprinklers malfunction, or causewater damage outside of the fire area.5.1.5 Fire Prevention and ProtectionFacilities that house CAs SHALL be constructed and equipped, and procedures SHALL be implemented, to preventand extinguish fires or other damaging exposure to flame or smoke. These measures SHALL meet all localapplicable safety regulations. A description of the CMA’s approach for recovery from a fire disaster SHALL beincluded in the Disaster Recovery Plan as specified in Section 5.7.4.5.1.6 Media StorageWhen not in operation, the cryptographic modules storing the Device Root CA private key SHALL be stored in asecure container. When not in operation, the cryptographic modules storing the CA private key SHALL be stored ina secure room in encrypted form. Media that contains security audit and backup information SHALL be stored in aseparate location from the CA equipment.5.1.7 Waste DisposalCAs SHALL implement procedures for the disposal of waste (paper, media, or any other waste) to prevent theunauthorized use of, access to, or disclosure of waste containing Confidential/Private Information.5.1.8 Off-Site backupSystem backups, sufficient to recover from system failure, SHALL be made on a periodic schedule. BackupsSHALL be performed and stored off-site not less than quarterly or when the CA is operational, whichever is lessfrequent. At least one backup copy SHALL be stored at an offsite location (separate from the CA equipment). Onlythe latest backup need be retained. The backup SHALL be stored at a site with physical and procedural controlscommensurate to that of the operational CA system.8565.2 Procedural Controls8578588598608618628638648658668678688698705.2.1 Trusted RolesA trusted role is one whose incumbent performs functions that can introduce security problems if not carried outproperly, whether accidentally or maliciously. The people selected to fill these roles MUST be extraordinarilyresponsible or the integrity of the CA is weakened. The functions performed in these roles form the basis of trust forall uses of the CA. Two approaches are taken to increase the likelihood that these roles can be successfully carriedout. The first ensures that the person filling the role is trustworthy and properly trained. The second distributes thefunctions among more than one person, so that any malicious activity would require collusion.The following are the trusted Roles within the PKI:• CA Administrator: installs, configures, and maintains the CA; configures PKC profiles and parameters;generates and performs backup of CA keys;• CA Officer: approves/rejects certification requests and PKC revocations;• Auditor: maintains and reviews audit logs; and,• Backup Operator: performs routine system backup and recovery.Multi-Person control requirements are specified in Section 6.2.2.Page - 20WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.18718728738748758768778788798808818828838848858868878885.2.2 Number of Persons Required Per TaskCA private key actions require at least “two-party” control:• Generation of CA keys;• Access to CA keys;• Backup of CA keys; and,• Access to backup CA keys.Where multiparty control is required, at least one of the participants SHALL be an Administrator. All participantsMUST serve in a trusted role as defined in Section 5.2.1. Multiparty control SHALL NOT be achieved usingpersonnel that serve in the Auditor Trusted Role.5.2.3 Identification and Authentication for Each RoleA person occupying a trusted role SHALL have their identity and authorization verified, before being permitted toperform any action for that role or identity.5.2.4 Roles Requiring Separation of DutiesIndividuals MAY only assume one of the Officer, Administrator, and Auditor roles, but any individual MAYassume the Operator role. The CA software and hardware SHALL identify and authenticate its users and SHALLensure that no user identity can assume both an Administrator and an Officer role, assume both the Administratorand Auditor roles, and assume both the Auditor and Officer roles. No individual SHALL have more than oneidentity.8895.3 Personnel Controls8908918928938948958968978988999009019025.3.1 Qualifications, Experience, and Clearance RequirementsPersonnel engaged in the PKI SHALL be suitable qualified and experienced.5.3.2 Background Check ProceduresVetting process used for trusted personnel engaged in the PKI SHALL be described in the CPS.5.3.3 Training RequirementsPrior to operation of the CA, the CA operator SHALL be appropriately trained. Topics SHALL include theoperation of the CMA software and hardware, operational and security procedures, and the stipulations of this policyand local guidance.5.3.4 Retraining Frequency and RequirementsRefresher training will be provided to the extent and frequency required to ensure the required level of proficiencyto perform job responsibilities competently.5.3.5 Job Rotation Frequency and SequenceNo stipulation.Page - 21WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.19039049059069079089099109119125.3.6 Sanctions for Unauthorized ActionsIf an unauthorized action takes place than an appropriate action SHALL be taken to ensure disciplinary or otherappropriate action is taken. In cases where an unauthorized action brings into question the security of the system,then recovery procedures will be followed (see Section 5.7).5.3.7 Independent Contractor RequirementsContractor personnel employed to perform functions pertaining to the CA SHALL meet the personnel requirementsset forth in this CP.5.3.8 Documentation Supplied to PersonnelDocumentation sufficient to define duties and procedures for each role SHALL be provided to their personnel fillingthat role.9135.4 Audit Logging Procedures9149159169179189199209219229239249259269279289299309319329339349359369379385.4.1 Types of Events RecordedAny security auditing capabilities of the underlying CA equipment operating system SHALL be enabled duringinstallation and operation.At a minimum, the following events SHALL be recorded:• CA equipment access;• Operating system logon/logoff;• CA application access;• CA private key generation;• CA private key use;• Certification request;• PKC issuance;• PKC revocation request;• PKC revocation;• Software and/or configuration updates to CA and account management;• Clock Adjustments;• Anomalies, error conditions, software integrity check failures, receipt of improper or misrouted messages;and,• Any known or suspected violations of physical security, suspected or known attempts to attack the CAequipment via network attacks, equipment failures, power outages, network failures, or violations of thiscertificate policy.At a minimum, for each auditable event the record SHALL include:• The type of event;• The time the event occurred;• A success or failure indication for signing;• The identity of the equipment operator who initiated the action; and,Page - 22WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.1939940941942943944945946947948949950951952953954955956957958959960961962963Audit logs SHALL be generated automatically and periodically backed up.5.4.2 Frequency of Processing LogOffline CA audit logs SHALL be reviewed at least annually or any time the CA is brought online. Online CA auditlogs SHALL be reviewed quarterly.The review is to include searches for anomalous patterns. Action taken as a result of this review SHALL bedocumented.Audit log reviews SHALL also be conducted when requested by the PA.5.4.3 Retention Period for Audit LogThe information generated on the CA equipment SHALL be kept on the CA equipment until the information ismoved to an appropriate archive facility. Audit logs SHALL be available for three months, at a minimum, thenoffsite as archive records (See Section 5.5).5.4.4 Protection of Audit LogOnly personnel assigned to a trusted role have read access to the logs. Only authorized personnel MAY archiveaudit logs. Audit logs MUST be protected against unauthorized viewing, modification, and deletion. Audit logsSHALL only be deleted from a system after it has been archived.5.4.5 Audit Log Backup ProceduresAudit logs SHALL be backed up. A copy of the audit log SHALL be stored at a separate facility from the activeaudit log as required.5.4.6 Audit Collection System (Internal vs. External)Automated audit processes SHALL be invoked at system (or application) startup, and cease only at system (orapplication) shutdown.5.4.7 Notification to Event-Causing SubjectNo stipulation.5.4.8 Vulnerability AssessmentsTrusted Roles SHALL routinely asses the CA system and its components for malicious activity.Page - 23WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.19645.5 Records Archive9659669679689699709719729739749759769779789799809819829839849859869879889899909919929939945.5.1 Types of Events ArchivedCA archive records SHALL be detailed enough to establish the validity of a signature and of the operation of thePKI. The following MUST be recorded at a minimum:• CA accreditation;• CPS;• System equipment configuration;• Modification and updates to system or configuration;• Contractual obligations;• Key Signing Ceremony video footage;• Certificate Subject identity authentication data from 3.1.9;• Documentation of receipt and acceptance of certificates;• Audit logs from Section 5.4.1;• All PKCs issued;• Other data or applications to verify archive contents; and,• Documentation required by compliance auditors.5.5.2 Retention Period for ArchiveArchive data SHALL be maintained for a minimum of the period of validity of all Certificates issued by CA plusseven (7) years or such longer period as MAY be required by National Archive and Records Administration(NARA).5.5.3 Protection of ArchiveArchive data SHALL be protected to ensure there is no unauthorized disclosure or modification. Archive mediaSHALL be stored in a safe, secure storage facility separate from the CA itself.5.5.4 Archive Backup ProceduresArchive facility SHALL support backups.5.5.5 Requirements for Time-Stamping of RecordsArchive data SHALL indicate the date on which the archive was created.5.5.6 Archive Collection System (Internal or External)No stipulation.5.5.7 Procedures to Obtain and Verify Archive InformationWiMAX PA or designated representative MUST be granted timely access to archive information when requested.Page - 24WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.1995996997998999100010015.6 Key ChangeoverDevice Manufacturer CAs and Device Sub-CAs MAY be renewed (Section 4.6) or re-keyed (Section 4.7) if thesuperior CA reconfirms the identity of the CA, which the superior CA either accepts or rejects.Re-keying is a multiparty procedure as specified in Section 5.2.2 and requires a "Key Ceremony" as specified inSection 6.1.1.New Device Manufacturer CA PKCs and Device Sub-CA PKCs SHALL be published in accordance with Section4.2.2.10025.7 Compromise and Disaster Recovery100310041005100610071008100910101011101210131014101510161017101810195.7.1 Incident and Compromise Handling ProceduresIn the event of suspected compromise of a CA, it SHALL be investigated in order to determine the nature and thedegree of damage. If the CA PKC is compromised and the CA PKC is revoked, a new CA PKC MUST be issuedand the old CA PKC in RP trust stores MUST be replaced with a newly issued CA PKC. Device Root CA PKCswill be distributed via secure out-of-band mechanism.5.7.2 Computing Resources, Software, and/or Data Are CorruptedBackup or Archived data MUST be used when computing resources, software, and data are corrupted.5.7.3 CA Private Key Compromise ProceduresCompromised CA private keys MUST be revoked. Compromised CA private keys MUST NOT be used to sign newPKCs. CA with compromised private keys MUST generate new private keys. Follow procedures in Section 5.3.6 ifthe CA operator is suspected of compromising the CA’s public key.5.7.4 Business Continuity Capabilities After a DisasterIn the case of a disaster in which the CA equipment is damaged and inoperative:• The Device Root CA operations SHALL be established as quickly as possible, giving priority to the abilityto issue CA PKCs.• The CA operations SHALL be reestablished as quickly as possible, giving priority to the ability to issueCertificate Subject PKCs.10201021102210231024102510265.8 CA and RA TerminationIn the event a Root CA terminates, or ceases operation, the Root CA ships its HSM, which contains the Root CA’sprivate key, and any backup copies and archival copies to the WiMAX PA.In the event a Manufacturer or Manufacturer Sub CA terminates, or ceases operation, the CA ships its HSM, whichcontains the CA’s private key, and any backup copies and archival copies to the parent CA and the parent CAMUST only use this key to issue CRLs.There is no stipulation for RAs.Page - 25WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.11027102810296. Technical Security ControlsThis chapter specifies the requirements for technical security controls to securely perform the functions of keygeneration, subject authentication, PKC issuance, and PKC revocation.10306.1 Key Pair Generation and Installation10311032103310341035103610371038103910401041104210431044104510461047104810491050105110521053105410556.1.1 Key Pair GenerationCA keys are generated in FIPS 140-2 validated cryptographic module. Modules SHALL meet security level 2 orabove and keys are generated as part of a multiparty operation. If the keys are generated outside the module, thenthey SHALL be loaded into the module during a key ceremony. Any unencrypted copies of the keys SHALL bedestroyed after the key ceremony, while encrypted backups MAY exist at secured locations.Subscriber keys are generated in a FIPS 140-2 level 1 or higher module. The module MAY be implemented in eitherhardware or software. When the keys are handled they MUST be protected from unauthorized disclosure andmodification.6.1.2 Private Key Delivery to Certificate SubjectDevice certificates and private keys SHALL be inserted and stored in devices in a secure manner. Only theCertificate subject device SHALL have the Certificate Subject private key. If the Device does not generate itsprivate key, then the private key MUST be delivered to the Device in a manner that protects the private key fromunauthorized disclosure and modification. See Section 3.2.1 and 6.2.1.6.1.3 Public Key Delivery to Certificate IssuerA Certificate Subject’s public key and identity SHALL be delivered securely to the CA in certification request.6.1.4 CA Public Key Delivery to Relying PartiesCA public keys SHALL be delivered to the RP as part of the certification response.The self-signed Root CA PKC SHALL be conveyed to relying parties in a secure fashion to preclude substitutionattacks.6.1.5 Key SizesKeys MUST be 2048 bits or longer. Shorter keys MUST NOT be used to certify PKCs that contain longer keys.6.1.6 Public Key Parameters Generation and Quality CheckingSee PKCS #1 for key generation requirements.6.1.7 Key Usage Purposes (as per X.509v3 key usage field)See Section 7.Page - 26WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.110566.2 Private Key Protection and Cryptographic Module Engineering Controls10571058105910601061106210631064106510661067106810691070107110721073107410751076107710781079108010811082108310841085108610871088108910906.2.1 Cryptographic Module Standards and ControlsThe relevant standard for cryptographic modules is FIPS PUB 140-2, Security Requirements for CryptographicModules.6.2.2 Private Key Multi-Person ControlUse of CA private keys requires action by multiple persons as set forth in Section 5.2.2 of this CP.There is no stipulation for Certificate Subject private keys.6.2.3 Private Key EscrowNo stipulation.6.2.4 Private Key BackupCA private keys SHALL be backed up under multi-person control, as required in Section 5.2.2. No more than asingle copy of the signature key SHALL be stored at the CA’s location (i.e., only the operational and backup keyMAY be stored at the CA’s location). Additional copies MAY exist off-site provided that accountability for them ismaintained. This does not preclude the ability of the operator of a CA to explain in the CPS and get explicitapproval for a secure high-availability high-throughput system which parallelizes the operation among severalmachines.Certificate Subject private keys SHALL NOT be backed up. If a copy of the Certificate Subject private key iscreated, the copy SHALL be encrypted such that only the subject device can decrypt it, and the copy SHALL NOTbe usable in any other device. If a copy of the Certificate Subject private key is created by the CA to facilitatedelivery from the CA to the device, this SHALL be in accordance with sections 3.2.1 and 6.1.2 and such copiesSHALL be destroyed as soon as the delivery of the private keys and certificates from the CA to the requestingorganization is considered complete.6.2.5 Private Key ArchivalNo stipulation.6.2.6 Private Key Transfer into or from a Cryptographic ModuleCA private keys never leave the cryptographic module.Certificate Subject private keys that are not generated by the Certificate Subject MUST be transferred to CertificateSubject in a manner that protects the key from unauthorized disclosure and modification. See Section 3.2.1.6.2.7 Private Key Storage on Cryptographic ModuleCA private keys SHALL be encrypted on removable memory storage devices.There is no stipulation for Certificate Subject private keys.6.2.8 Method of Activating Private KeysActivation of the CA signing key requires multiparty control, as specified in Section 5.2.2. The CA private keymedia SHALL NOT be left unattended when active.There is no stipulation for activation of Certificate Subject private keys.Page - 27WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.1109110921093109410951096109710981099110011016.2.9 Methods of Deactivating Private KeysRoot CA private keys SHALL be deactivated and the media holding the Root CA private key SHALL be stored in asecure container (see Section 5.1.6). CA private keys SHALL be deactivated and stored in encrypted form in asecure room when not in use (see Section 5.1.6). These actions requires multiparty control, as specified in Section 52.2. The Root CA and CA private key media SHALL NOT be left unattended when not in use.There is no stipulation for deactivation of Certificate Subject private keys.6.2.10 Method of Destroying Private KeyPrivate keys SHALL be destroyed when they are no longer needed or when the PKC to which they correspondsexpires or is revoked.6.2.11 Cryptographic Module RatingSee Section 6.2.1.11026.3 Other Aspects of Key Management110311041105110611076.3.1 Public Key ArchivalPublic keys SHALL be archived as part of the PKC archival.6.3.2 Certificate Operational Periods/Key Usage PeriodsDevice Root CA, Device Certificate Manufacturer, Device Sub-CA, and Device certificates shall be limited toDecember 31st, 2049. 311086.4 Activation Data11091110111111121113111411151116111711181119112011216.4.1 Activation Data Generation and InstallationActivation data generation and installation for CA private keys SHALL use methods that protect the activation datato the extent necessary to prevent the loss, theft, modification, unauthorized disclosure, or unauthorized use of suchprivate keys.There is no stipulation for Certificate Subject private keys.6.4.2 Activation Data ProtectionActivation data to invoke private keys SHALL be protected from disclosure by a combination of cryptographic andphysical access control mechanisms. The protection mechanism SHALL include a facility to temporarily lock theaccount, or terminate the application, after 3 failed login attempts.6.4.3 Other Aspects of Activation DataBefore the Root CA private key activation data MAY be enter, the media storing the Root CA’s private key MUSTbe retrieved from the locked container.No stipulation for Device Manufacturer CAs, Device Sub-CAs, or Certificate Subjects.3 It is expected that this policy will need to be modified once the standards for dates beyond 2049 are widelyimplemented.Page - 28WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.111226.5 Computer Security Controls11231124112511261127112811291130113111321133113411351136113711386.5.1 Specific Computer Security Technical RequirementsFor the CA, the computer security functions listed below are required. These functions MAY be provided by theoperating system, or through a combination of operating system, software, and physical safeguards. The CA and itsancillary parts SHALL include the following functionality:• Require authenticated logins;• Provide Discretionary Access Control;• Provide a security audit capability;• Restrict access control to Trusted Roles;• Enforce separation of Trusted Roles;• Require identification and authentication;• Restrict CA application to be the only application running on computer;• Require use of cryptography for session communications and database security;• Archive CA history and audit data; and,• Require a recovery mechanism for keys, CA system, and CA application.6.5.2 Computer Security RatingNo Stipulation.Page - 29WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.111396.6 Life-Cycle Security Controls11401141114211431144114511461147114811491150115111521153115411551156115711581159116011611162116311641165116611676.6.1 System Development ControlsThe System Development Controls for the CA are as follows:• For commercial off-the-shelf software, the software SHALL be designed and developed under a formal,documented development methodology.• For hardware and software developed specifically for a particular CA, the applicant SHALL demonstratethat security requirements were achieved through a combination of software verification & validation,structure.• Where open source software has been utilized, the applicant SHALL demonstrate that securityrequirements were achieved through software verification & validation and structured development/lifecyclemanagement.• Hardware and software procured to operate the CA SHALL be purchased and shipped in a fashion toreduce the likelihood that any particular component was tampered with (e.g., by ensuring the equipmentwas randomly selected at time of purchase).• The CA software SHALL be dedicated to performing one task: the CA. There SHALL be no otherapplications; hardware devices, network connections, or component software installed which are not part ofthe CA operation.• Proper care SHALL be taken to prevent malicious software from being loaded onto the CA equipment.Hardware and software SHALL be scanned for malicious code on first use and periodically thereafter.• Hardware and software updates SHALL be purchased or developed in the same manner as originalequipment, and be installed by trusted and trained personnel in a defined manner.• Any code return to open source community does not disclose security relevant information.6.6.2 Security Management ControlsThe configuration of the CA system as well as any modifications and upgrades SHALL be documented andcontrolled. There SHALL be a mechanism for detecting unauthorized modification to the CA software orconfiguration. A formal configuration management methodology SHALL be used for installation and ongoingmaintenance of the CA system.6.6.3 Life Cycle Security RatingsNo stipulation.1168116911701171117211736.7 Network Security ControlsCAs SHALL be protected prevent unauthorized access, tampering, and denial-of-service. Communications ofsensitive information SHALL be protected using point-to-point encryption for confidentiality and digital signaturesfor non-repudiation and authentication.Server Root CAs SHOULD be offline. Permanently online Server Root CAs will need to explain why they arealways online in their CPS.Page - 30WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.111741175117611776.8 Time StampingTimes asserted in PKCs SHALL be accurate to within three minutes. Electronic or manual procedures MAY beused to maintain system time. Clock adjustments are auditable events (See Section 5.4.1).There is no trusted time source.Page - 31WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.1117811797. Certificate, CARL/CRL, and OCSP Profiles FormatThis Chapter specifies the requirements for the PKC, CRL, and OCSP format.118011817.1 Certificate ProfileSee WiMAX Forum PKC Profile Release 1.0.118211837.2 CRL ProfileSee WiMAX Forum CRL Profile Release 1.0.118411857.3 OCSP ProfileSee WiMAX Forum OCSP Profile Release 1.0.118611877.4 SCVP ProfileA WiMAX SCVP profile will be developed when the need arises.Page - 32WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.1118811898. Compliance Audit and Other AssessmentsThis chapter specifies the requirements for audits.119011918.1 Frequency of Audit or AssessmentsCAs are subject to a compliance audit at least once per year.1192119311948.2 Identity & Qualifications of AssessorThe auditor MUST demonstrate competence in the field of compliance audits. The PA SHALL identify thecompliance auditor for the CA.11951196119711988.3 Assessor’s Relationship to Assessed EntityThe compliance auditor either SHALL be a private firm, that is independent from the entity being audited, or itSHALL be sufficiently organizationally separated from that entity to provide an unbiased, independent evaluation.The PA SHALL determine whether a compliance auditor meets this requirement.1199120012018.4 Topics Covered By AssessmentThe compliance audit of the CA SHALL verify that the CA is implementing all provisions of a CP approved by thePA.1202120312048.5 Actions Taken As A Result of DeficiencyAny discrepancies between how the CA is designed to or is being operated or maintained and the requirements ofthis CP will result in the compliance auditor documenting the discrepancy.1205120612078.6 Communication of ResultsUpon completion, the audit compliance report will be returned to the PA. The report SHALL be treated as companyconfidential. The report SHALL identify the versions of the CP used in the assessment.Page - 33WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.1120812099. Other Business and Legal MattersThis chapter specifies requirements on general business and legal matters.1210121112121213121412151216121712181219122012219.1 FeesAny fees MUST be approved by the WiMAX PA.9.1.1 Certificate Issuance/Renewal FeesAny fees MUST be approved by the WiMAX PA.9.1.2 Certificate Access FeesAny fees MUST be approved by the WiMAX PA.9.1.3 Revocation or Status Information Access FeeAny fees MUST be approved by the WiMAX PA.9.1.4 Fees for other ServicesAny fees MUST be approved by the WiMAX PA.9.1.5 Refund PolicyAny refund policy MUST be approved by the WiMAX PA.12221223122412251226122712281229123012311232123312349.2 Financial ResponsibilityCA MUST have assets and resources that ensure an ability to provide meet all operational requirements as a CA onan uninterrupted basis and to pay damages that could reasonably occur as a result of CA operations. Levels MUSTbe reasonably acceptable to WiMAX PA.9.2.1 Insurance CoverageDevice Root CA must obtain insurance coverage obtained from a reputable financially sound insurer withappropriate policy limits that is equal to or exceeds industry norms. The WiMAX Forum will be named as anadditional insured. Insurance carrier and coverage MUST be acceptable to WiMAX PA.No stipulation regarding insurance requirements for Device Manufacturer CA and Device Sub-CA.9.2.2 Other AssetsNo stipulation.9.2.3 Insurance/warranty Coverage for End-EntitiesNo stipulation.Page - 34WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.112351236123712381239124012411242124312441245124612479.3 Confidentiality of Business InformationSensitive and confidential information will be exchanged and provided under this CP. Written confidentialinformation SHALL be adequately marked in writing as confidential. Oral confidential information SHALL beidentified as confidential.9.3.1 Scope of Confidential InformationConfidential Information means all information in written or oral form that the disclosing party identifies asconfidential, and any trade secret or other proprietary information that the recipient knows or reasonably ought toknow should be treated as confidential.9.3.2 Information Not Within the Scope of Confidential InformationInformation that is generally known to the public or properly known by the receiving party at the time of disclosureand other typical exceptions.9.3.3 Responsibility to Protect Confidential InformationThe PA and CAs MUST protect confidential information from unauthorized disclosure.12481249125012511252125312541255125612571258125912601261126212631264126512669.4 Privacy of Personal InformationIt is the responsibility of all parties to ensure privacy of personal information under their control. No personalinformation is registered or certified. Information about subordinate CA operators is retained by the CA as part ofcertification request, which is subsequently logged and later archived. Manufacturer point of contact information isalso retained by the Root CAs. If a party collects, transmits or stores personal information, its practices will complywith all applicable laws.9.4.1 Privacy PlanA privacy plan SHALL manage relevant information. Sponsor contact information SHALL be stored in a securecontainer.9.4.2 Information Treated as PrivateCA operator’s name, organizational affiliation, and phone number and other information within that definition.9.4.3 Information Not Deemed PrivateCP, CPS, PKCs, and revocation information are not considered private information.9.4.4 Responsibility to Protect Private InformationAll parties will protect private information when it is within their control.9.4.5 Notice and Consent to use Private InformationNotice and consent practices regarding private information MUST comply with any applicable law..9.4.6 Disclosure Pursuant to Judicial/Administrative ProcessDisclosure in response to a valid judicial or administrative order MUST be permitted.Page - 35WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.112671268126912709.4.7 Other Information Disclosure CircumstancesExcept as required for operation of the PKI system, as expressly permitted or required under the CP, or as requiredby applicable law, no private information will be disclosed without the express written consent of the party to whichthat private information pertains.1271127212731274127512761277127812791280128112821283128412851286128712881289129012919.5 Intellectual Property RightsThe CP, CPS, each root certificate and all certificates issued under the root certificate are the property of theWiMAX Forum.No party will use any property of the WiMAX Forum, including, without limitation, any trademark, copyright, tradesecret or other proprietary right of the WiMAX Forum, unless the WiMAX Forum has licensed that use.No party will infringe the intellectual property rights of any third party or the WiMAX Forum. Without limitation,except as the WiMAX Forum MAY expressly authorize in writing, it is prohibited to:• Reverse engineer, translate, disassemble, decompile the whole or any part of any software or system or anypart therefore or otherwise attempt to access any software source code embedded in or operating using anysystem;• Assign, transfer, sell, license, sub-license, lease, rent, charge or otherwise deal in or encumber, anysoftware or system or any part thereof or use same on behalf of or for the benefit of any third party, ormake available the same in any way whatsoever to any third party without the WiMAX Forum’s priorwritten consent;• Remove or alter any trademark or any copyright or other proprietary notice on any software, system or anyother materials;• Distribute, create derivative works of or modify the any materials, software or systems or any part thereofin anyway, or use, copy, duplicate or display same on a commercial or development basis.• Provide any service using a certificate provided under this CP except as authorized and provided in this CPand an approved CPS.These restrictions SHALL NOT be construed in a manner that would violate any applicable law.1292129312941295129612979.6 Representations and WarrantiesThe obligations described below pertain to the WiMAX PKI Participants. The obligations applying to CAs pertainto their activities as issuers of PKCs.9.6.1 PA / WiMAX ForumThe WiMAX Forum and the PA make no representations and disclaim all warranties, however characterized, to themaximum extent permitted by law. The CP notice and disclaimer terms on page [i] above.Page - 36WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.112981299130013011302130313041305130613071308130913101311131213131314131513161317131813199.6.2 Generally Applicable Representations and WarrantiesAgreements involving CA’s, RA’s, Subcribers, and Relying Parties will include standard representations andwarranties:• It has full right, power and authority to enter into the agreement and there is nothing that would prevent itfrom performing its obligations under the terms and conditions imposed on it by the agreement.• The agreement has been duly authorized by all necessary corporate action and constitutes a valid andbinding obligation on it, enforceable in accordance with the terms hereof (except to the extent of any reliefthat MAY be afforded under the laws of bankruptcy or under general principles of equity).• If it is an entity: It is a [corporation] duly organized and validly existing and in good standing under thelaws of its jurisdiction of incorporation and is duly qualified and authorized to do business wherever thenature of its activities or properties requires such qualification or authorization.• No registration with or approval of any government agency or commission of any jurisdiction is necessaryfor the execution, delivery or performance by it of any of the terms of the agreement, or for the validity andenforceability hereof or with respect to its obligations under the agreement.• There is no provision in its company or corporate charter, articles of incorporation, Bylaws or equivalentgoverning documents, and no provision in any existing mortgage, indenture, contract or agreement bindingon it, which would be contravened by the execution, delivery or performance by it of the agreement.• No consent of any third party or holder of any of its indebtedness is or SHALL be required as a condition tothe validity of the agreement.• Neither its execution nor its delivery of the agreement nor its fulfillment of or compliance with the termsand provisions hereof SHALL contravene any provision of the laws of any jurisdiction including, withoutlimitation, any statute, rule, regulation, judgment, decree, order, franchise or permit applicable to it.1320132113221323132413251326132713281329133013319.6.3 CA Representations and WarrantiesCAs warrant that:• There are no material misrepresentations of fact in the PKC known to or originating from the entitiesapproving the Certificate Application or issuing the Certificate,• There are no errors in the information in the PKC that were introduced by the entities approving theCertificate Application or issuing the PKC as a result of a failure to exercise reasonable care in managingthe Certificate Application or creating the PKC,• Their PKCs meet all material requirements of this CP and the applicable CPS, and• Revocation services and use of a repository conform to all material requirements of this CP and theapplicable CPS in all material aspects.• It will perform all services in a professional and workmanlike manner and in conformity with standards thatequal or exceed industry norms for the services that it is providing.1332133313349.6.4 RA Representations and WarrantiesIn addition to the generally applicable representations and warranties in Section 9.6.2, RA’s MUST make the samewarranties as CA’s with respect to any service that is delegated from the CA.Page - 37WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.11335133613371338133913401341134213439.6.5 Certificate Subject Representations and WarrantiesCertificate Subjects SHALL:• Use their private key and PKC for uses, in accordance with this CP (see Section 1.4).• Protect the confidentiality of their private keys at all times, in accordance with this CP.9.6.6 Relying Parties Representations and WarrantiesRelying Parties SHALL:• Use the PKC for uses, in accordance with this CP (see Section 1.4).9.6.7 Representations and Warranties of Other ParticipantsNo stipulation.134413459.7 Disclaimers of WarrantiesDisclaimers of implied warranties MAY be included. No disclaimer MAY contradict a required express warranty.13469.8 Limitations of Liability13471348134913501351135213539.8.1 PA / WiMAX ForumIn no event is the PA or WiMAX Forum liable for any losses, liabilities, or damages, whether direct or indirect andhowever characterized.9.8.2 Other Participants.Mutual limitations of liability that exclude liability for special, indirect, incidental and consequential damages MAYbe included. An agreement MAY NOT impose a specific liability limit such as, for example, limiting a party’sliability to the value of the fees paid or some multiple thereof.13549.9 Indemnities13551356135713581359136013619.9.1 PA / WiMAX ForumThe WiMAX will not indemnify any party. The WiMAX Forum will be indemnified against third-party claimsarising from or relating to use of the PKI system and any related services, systems, software or materials.9.9.2 Other Participants.The agreements MUST have standard commercial indemnities covering the breach of the CP or an applicable CPS,infringement of third-party proprietary rights, breaches of nondisclosure obligations, and damages resulting from aparty’s breach of a representation, warranty, or material obligation under the agreementPage - 38WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.113629.10 Term and Termination1363136413651366136713681369137013711372137313741375137613771378137913801381138213831384138513869.10.1 Term9.10.1.1 CP TermThe CP becomes effective when the PA approves it and SHALL continue until the PA terminates it.9.10.1.2 Other AgreementsNo stipulation provided that the term is reasonable for the services to be provided. The WiMAX PA will resolveany disagreement.9.10.2 Termination9.10.2.1 CP TerminationTermination of the CP is at the discretion of the PA. The CP remains in force until such time as WiMAX PAterminates it.9.10.2.2 Other AgreementsTermination for material breach, bankruptcy or insolvency, and upon expiration of a fixed term is permitted. Aservice provider MAY NOT terminate for convenience.Termination of this CP is at the discretion of the PA. The CP remains in force until such time as it is replaced by anew version or it is terminated by the WiMAX PA.9.10.3 Effect of Termination and Survival9.10.3.1 CPUpon termination of this CP, WiMAX PKI participants are nevertheless bound by the terms of the CP for all PKCsissued for the remainder of the validity periods of such PKCs.9.10.3.2 Other AgreementsNo stipulation except that provisions relating to the following CP provisions MUST survive: 9.3, 9.4, 9.5, 9.7, 9.8,9.9, and 9.10.3.1.Upon termination of this CP, WiMAX PKI participants are participants are nevertheless bound by the terms of thisCP for all PKCs issued for the remainder of the validity periods of such PKCs.138713889.11 Individual Notices & Communications with participantsNo stipulation.13899.12 Amendments13901391139213939.12.1 Procedure for Amendment9.12.1.1 CPThe WiMAX PA MAY amend the CP in its sole discretion. The WiMAX PA MAY issue amendments,clarifications, or an update.Page - 39WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.11394139513961397139813991400140114029.12.1.2 CPS and Participant Agreements.Other participants will amend the CPS, which is provided by the CA operator, and other agreements to conformthem to amendments to the CP.9.12.2 Notification Mechanism and PeriodThe CP and any subsequent changes SHALL be made available the WiMAX PKI participants via the publicallyavailable repository.9.12.3 Circumstances Under which OID Must Be ChangedThe object identifier representing the CP will be changed if significant changes are made to the CP portions of thisdocument.1403140414059.13 Dispute Resolution ProvisionsAny dispute arising with respect to this policy or PKCs issued under this policy is addressed by the PA. Alldeterminations of the PA are final.140614079.14 Governing LawAll parties SHALL comply with all laws, rules, regulations and orders that are applicable to them.140814099.15 Compliance with Applicable LawThis CP SHALL comply with the laws of the State of California Law and the United States of America.14109.16 Miscellaneous Provisions1411141214131414141514161417141814191420142114221423142414259.16.1 Document Incorporated into CPThe following documents also apply:• NWG Rel 1.0 Stage 3 Specification: http://www.wimaxforum.org/technology/documents/WiMAX_End-to-End_Network_Systems_Architecture_Stage_2-3_Release_1.1.0.zip• RFC 3647 Internet X.509 Public Key Infrastructure Certificate Policy and Certification PracticesFramework http://www.ietf.org/rfc/rfc3647.txt• FIPS 140-2 SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULEShttp://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf• IEEE 802.16e-2005 March 2006, Physical and Medium Access Control Layers for Combined Fixed andMobile Operation in Licensed Bands• WiMAX Forum Device Certificate Profile Version 1.0.0• WiMAX Forum CRL Profile Version 1.0.0• WiMAX Forum OCSP Profile Version 1.0.09.16.2 Entire agreementNo stipulation.Page - 40WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE

WiMAX Forum Network Architecture – WiMAX Forum Device PKI Certificate Policy Draft Specification.Version 1.0.114261427142814291430143114321433143414351436143714389.16.3 AssignmentThe CPS and any agreement to provide services MAY NOT be assigned (including through a merger, acquisition orother corporate transaction that results in an effective change of control of a participant) or delegated without theprior written consent of the WiMAX PA.9.16.4 SeverabilityNo stipulation.9.16.5 WaiverNo stipulation.9.16.6 Attorneys’ FeesParticipants SHALL reimburse the WiMAX Forum for all fees, expenses, and costs that it incurs in enforcing theterms of the CP.9.16.7 Force MajeureOptional. If included, force majeure period should not exceed 60 days.143914409.17 Other ProvisionsNo stipulationPage - 41WiMAX FORUM PROPRIETARY AND CONFIDENTIAL – SUBJECT TO CHANGE WITHOUT NOTICE