Document WINNF-TS-0022
Version V1.5.0 17 November 2020
This document has been prepared by the SSC WG5 Certificate Authority Task Group to assist The Software Defined Radio Forum Inc. (or its successors or assigns, hereafter "the Forum"). It may be amended or withdrawn at a later time and it is not binding on any member of the Forum or of the SSC WG5 Certificate Authority Task Group.
Contributors to this document that have submitted copyrighted materials (the Submission) to the Forum for use in this document retain copyright ownership of their original work, while at the same time granting the Forum a non-exclusive, irrevocable, worldwide, perpetual, royalty-free license under the Submitter's copyrights in the Submission to reproduce, distribute, publish, display, perform, and create derivative works of the Submission based on that original work for the purpose of developing this document under the Forum's own copyright.
Permission is granted to the Forum's participants to copy any portion of this document for legitimate purposes of the Forum. Copying for monetary gain or for other non-Forum related purposes is prohibited.
THIS DOCUMENT IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NON-INFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE FORUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS DOCUMENT.
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.
This document was developed following the Forum's policy on restricted or controlled information (Policy 009) to ensure that that the document can be shared openly with other member organizations around the world. Additional Information on this policy can be found here: http://www.wirelessinnovation.org/page/Policies\_and\_Procedures
Although this document contains no restricted or controlled information, the specific implementation of concepts contain herein may be controlled under the laws of the country of origin for that implementation. Readers are encouraged, therefore, to consult with a cognizant authority prior to any further development.
Wireless Innovation Forum ™ and SDR Forum ™ are trademarks of the Software Defined Radio Forum Inc.
This document defines the certificate policy for the Public Key Infrastructure (PKI) which governs communications within the Citizens Broadband Radio Service (CBRS) ecosystem and provides authentication and authorization for messages exchanged within the SAS ecosystem as part of the protocols described in the SAS-CBSD Technical Report and the SAS-SAS Technical Report.
CBRS certificates are the basis for a number of security services including authentication, confidentiality, integrity, and non-repudiation. In order for a certificate to be in compliance with CBRS specifications, it shall comply with this Certificate Policy. This Policy assumes that the reader is generally familiar with Digital Signatures, PKIs and CBRS specifications.
This Certificate Policy is consistent with the Internet X.509 PKI Certificate Policy and Certification Practices Framework [RFC 3647]. It governs the certificate PKI operations of components by all individuals and entities within the CBRS PKI (collectively, "PKI Participants"). It provides the minimum requirements that PKI Participants are required to meet when issuing and managing Certification Authorities (CAs), digital certificates, and private keys related to the CBRS. In addition, it informs potential Relying Parties about what they need to know prior to relying on issued certificates.
This CP also defines the terms and conditions under which the CAs SHALL operate to issue certificates. Where "operate" includes certificate management (i.e., approve, issue, and revoke) of issued certificates and "issue" in this context refers to the process of digitally signing with the private key associated with its authority certificate a structured digital object conforming to the X.509, version 3 certificate format.
The following terms are used within this document and should be interpreted as described in RFC-2119:
The CP describes the overall business, legal, and technical infrastructure of the CBRS PKI. More specifically, it describes, among other things:
Appropriate applications for, and the assurance levels associated with the PKI certificates
Obligations of CAs
Minimum requirements for audit and related security and practices reviews
Methods to confirm the identity of Certificate Applicants
Operational procedures for certificate lifecycle services: certificate application, issuance, acceptance, revocation, and renewal
Operational security procedures for audit logging, records retention, and disaster recovery
Physical, personnel, key management, and logical security
Certificate Profile and Certificate Revocation List content
The CP is an integral part of the CBRS PKI documentation and sets the minimum standards for governing, administrating and operating the PKI. Ancillary security and operational documents may supplement the CP in setting more detailed requirements. Additionally, each CBRS PKI CA is governed by a Certification Practice Statement(s) (CPS), which describes how the applicable CP requirements are met by that particular CA. CAs operating in the CBRS PKI shall draft, implement, and maintain a CPS.
CBRS digital certificates provide assurances that the certificate Subscriber's distinguished name is unique and unambiguous within the CBRS CA's domain, and the identity of the Subscriber's organization is based on a comparison of information submitted by the Subscriber against information in business records or databases. These certificates can be used for digital signatures, encryption, and authentication for proof of identity of components that contain CBSD certificates and are compliant with CBRS specifications and this CP.
This document is the CBRS PKI Certificate Policy and was approved for publication on 16 May 2019 by the Wireless Innovation Forum (WInnForum).
The OID for WInnForum is iso (1) identified-organization (3) dod (6) internet (1) private (4) enterprise (1) The Wireless Innovation Forum (46609). WInnForum organizes its OID arcs for the Certificates described in this CP as follows:
Table 1 WInnForum OID Arcs
| Digitally Signed Object | Object Identifier (OID) |
|---|---|
| Policy Documents | 1.3.6.1.4.1.46609.2 |
| Certificates issued pursuant to CPS | 1.3.6.1.4.1.46609.2.1 |
| CBRS PKI Role OID Arc | 1.3.6.1.4.1.46609.1.1 |
| SAS | 1.3.6.1.4.1.46609.1.1.1 |
| INSTALLER | 1.3.6.1.4.1.46609.1.1.2 |
| CBSD | 1.3.6.1.4.1.46609.1.1.3 |
| OPERATOR (Domain Proxy) | 1.3.6.1.4.1.46609.1.1.4 |
| CA | 1.3.6.1.4.1.46609.1.1.5 |
| RESERVED | 1.3.6.1.4.1.46609.1.1.6 |
The CBRS PKI is a three-r four- tier infrastructure with CBRS Root CAs at tier 1 that issue intermediate CA certificates (i.e., sub-CAs) at tier 2. The tier 2 sub-CAs issue compliant end-entity Subscriber certificates or CBSD OEM CA certificates at tier 3. Tier 3 sub-CAs issue compliant end-entity CBSD Subscriber certificates (see Figure 1 ). There are up to 6 different CA chains anchored by a CBRS Root CA: SAS Provider, Domain Proxy, Professional Installer, , CBSD Mfr, and CBSD OEM. The WInnForum will make the list of approved Root CAs available to Subscribers.
The CBRS Root CA is the apex of its Root CA Domain. The Root CA will issue the sub-CA certificates to approved CA service providers. The sub-CAs will issue certificates to authorized Subscribers, which will embed the certificates in compliant devices. It is assumed that an Installer certificate will be installed in a device used by an authorized installer to manage/configure CBSDs
Subscribers should install all WInnForum authorized CBRS Root CA certificates in their device trust anchor stores to validate received certificates. The end-entity certificate, its private key, and all sub-CA certificates for a given CA chain should also be installed on the device. During the
TLS authentication messaging exchange, the end-entity and all sub-CA chain certificates should be sent to the other end point.
The following describes the relevant participant roles in the CBRS PKI.
The WInnForum and its members foster the development, adoption and compliance of the CBRS standard. The WInnForum has established the framework for the CBRS PKI and governs and oversees operation of the PKI. In particular, this CP was established under the authority of and with the approval of the WInnForum.
At the heart of the CBRS PKI are entities called "Certification Authorities" or "CAs." CA is an umbrella term that refers to the collection of hardware, software, and operating personnel that create, sign, and issue public key certificates to Subscribers or other CAs. The CAs are responsible for:
CBRS CAs fall into two categories: (1) Root CAs, which are operated by a designated CBRS Root CA service providers and issue sub-CA certificates; and (2) the sub-CAs which are operated by designated CBRS sub CA service providers and issue end-entity device certificates to Subscribers.
CAs may provide a secure method for the automated issuance of end-entity certificates from sub CAs. This could be supported onsite at a Subscriber's manufacturing facility using CA approved hardware and software components or using a remote API. These methods shall be complaint to the requirements of this CP.
Registration Authorities (RAs) are entities that enter into an agreement with a Certification Authority to collect and verify each Subscriber's identity and information to be entered into the Subscriber's certificates. The RA performs its function in accordance with this CP and its approved
CPS and will perform front-end functions of confirming the identity of the certificate applicant, approving or denying Certificate Applications, requesting revocation of certificates, and managing account renewals.
In order to improve the flexibility and logistics speed in the manufacturing system the manufacturer MAY implement its product certification solution in an automated fashion, without human involvement in certificate issuance. For this case the RA functionality MAY be a software and a hardware application which is technically part of the manufacturing system.
In the CBRS PKI, the Subscriber is the organization named in the Digital Certificate Subscriber Agreement (DCSA). An authorized representative of the Subscriber, acting as a Certificate Applicant, SHALL complete the certificate application process established by the RA. In response, the CA relies on the RA to confirm the identity of the Certificate Applicant and either approves or denies the application. If approved, the RA communicates to the CA, and the Subscriber can then request certificates.
The WInnForum requires that Subscribers adopt the appropriate CBRS certificate policy requirements and any additional certificate management practices to govern the Subscriber's practice for requesting certificates and handling the corresponding private keys. The Subscriber agrees to be bound by its obligations through execution of the DCSA between the Subscriber and the RA, and any other applicable agreements. This includes the case where the Subscriber has implemented an automated manufacturing process for requesting and issuing end-entity certificates for installation into devices (e.g. CBSD).
CAs, technically, are also Subscribers of certificates within a PKI, either as a Root CA issuing a self-signed Certificate to itself, or as a sub-CA. References to "Subscribers" in this CP, however, apply only to the organizations requesting device certificates, including those Subscribers who may have arranged to have a sub-CA operated onsite at their manufacturing facility.
The Relying Party is any entity that validates the binding of a public key to the Subscriber's name in a device certificate. The Relying Party is responsible for deciding whether or how to check the validity of the certificate by checking the appropriate certificate status information. The Relying Party can use the certificate to verify the integrity of a digitally signed message, to identify the initiator of a communication, or to establish confidential communications with the holder of the certificate. For instance, a SAS can use the device certificate embedded in a CBSD device to authenticate the device requesting services from the server.
The PKI participants operating under this CP MAY require the services of other security authorities, such as compliance auditors. The CA's CPS will identify the parties responsible for providing such services, and the mechanisms used to support these services.
This CP applies to all CBRS PKI Participants, including Subscribers and Relying Parties. This CP sets forth policies governing the use of CBRS PKI Certificates. Each Certificate is generally appropriate for use as set forth in this CP.
Certificates are suitable for authentication of devices and confidentiality encryption. The use of the certificates permits message integrity checks, confidentiality of communications, and support for Non-repudiation.
CBRS PKI Certificates are not designed, intended, or authorized for use or resale as control equipment in hazardous circumstances or for uses requiring fail-safe performance such as the operation of nuclear facilities, aircraft navigation systems, aircraft communication systems, air traffic control systems, or weapons control systems, where failure could lead directly to death, personal injury, or severe environmental damage.
The WInnForum is responsible for all aspects of this CP.
Inquiries regarding this CP shall be directed to the WInnForum.
The WInnForum SHALL approve the CPS for each CA that issues certificates under this policy, such approval not to be unreasonably withheld.
CAs and RAs operating under this CP are required to meet all facets of the policy. The WInnForum SHALL make the determination that a CPS complies with this policy. The CA and RA SHALL meet all requirements of an approved CPS before commencing operations.
This section enumerates the validation procedures a Certificate Authority (CA) shall follow before signing CBRS certificate requests. These procedures are in addition to those defined in section 3.2. All certificates signed shall follow the profiles defined section 7.
"Validation" in this context shall mean the CA's determination that a signature issuance requirement is met, the collection and retention of documentation records supporting the determination that the requirement was fulfilled by the requestor of the certificate throughout the lifetime of the certificate, and the ability of the CA to produce such records in response to a proper audit request. The validation may be processed by a Registration Authority (RA) which is authorized by the CA. In this case the CA may accept the certificate request without additional validation and the audit requirements on the validation are carried out by the RA. In addition, the CA may replace the content of static fields in the Certificate Request with predefined and prevalidated values without validating the requested values. The CA may not have connection to the manufacturing data of the equipment that needed for the certificate issuance. Automated RA at manufacturing site may perform the content validation and send the approved request to the CA. Similarly, the necessary checks for certificates issued to a human recipient (such as the proof of identity) may be processed by an RA operator.
Root of Trust Self-Signed Certificate Issuance Requirements
A CA shall sign a Self-Signed Certificate to be used as a CBRS PKI Root of Trust if and only if:
Sub-CA Certificate Issuance Requirements
A CA shall sign a Sub-CA request (SAS Provider CA, Domain Proxy CA, Professional Installer CA, Device Manufacturer CA) using a Root-of-Trust certificate if and only if:
CBSD OEM CA Certificate Issuance Requirements
A CA shall sign a CBSD OEM CA request using a CBSD Manufacturer CA certificate if and only if:
SAS Provider End Entity Certificate Issuance Guidelines
A CA shall sign a SAS Provider End Entity certificate request using a SAS Provider CA certificate if and only if:
Domain Proxy End Entity Certificate Issuance Guidelines
A CA shall sign a Domain Proxy End Entity certificate request using a Domain Proxy CA certificate if and only if:
Professional Installer End Entity Certificate Issuance Guidelines
A CA shall sign a Professional Installer End Entity certificate request using a Professional Installer CA certificate if and only if:
CBSD End Entity Certificate Issuance Guidelines
A CA shall sign a CBSD End Entity certificate request using a CBSD Manufacturer CA or a CBSD OEM CA certificate if and only if:
Domain Proxy End Entity Certificate Issuance Guidelines to SAS Administrator
A CA MAY sign a Domain Proxy End Entity certificate request from a SAS Administrator using a Domain Proxy CA certificate if and only if:
In the CBRS PKI, there is no separate entity providing repository services. Rather, each CA is responsible for their repository functions. All CAs that issue certificates under this policy SHALL post all CA certificates and CRLs issued by the CA in a repository that is publicly accessible on the Internet.
The CP and CA certificates shall be made publicly available, for example, on the WInnForum website. When Legacy Certificates are used, CRL URIs SHALL be made publicly available too. The CPS for the Root CAs will not be published; a redacted version of the CPS will be made publicly available upon request. There is no requirement for the publication of CPSs of sub-CAs that issue certificates under this policy. The CA SHALL protect information not intended for public dissemination.
Changes to this CP shall be made publicly available within thirty (30) business days of approval by the WInnForum. CA information shall be published promptly after it is made available to the CA.
CA certificates shall be made publicly available within three (3) business days after issuance. Publication requirements for CRLs are provided in CP § 4.9.7.
The CAs SHALL implement controls to prevent unauthorized addition, deletion, or modification of repository entries.
The CPS shall detail what information in the repository shall be exempt from automatic availability and to whom, and under which conditions the restricted information MAY be made available.
For certificates issued under this policy the CA SHALL assign X.501 distinguished names. The subject field in certificates SHALL be populated with a non-empty X.500 distinguished name as specified in CP § 7.1.4. The issuer field of certificates SHALL be populated with a non-empty X.500 Distinguished Name as specified in CP § 7.1.4.
Subscriber Certificates SHALL contain meaningful names with commonly understood semantics permitting the determination of the identity of the organization that is the Subject of the Certificate.
The subject name in CA certificates SHALL match the issuer name in certificates issued by the CA, as required by [RFC 5280].
CAs SHALL not issue anonymous or pseudonymous certificates.
Rules for interpreting Distinguished Name forms are specified in X.501.
Name uniqueness for certificates issued by CAs SHALL be enforced. Each CA SHALL enforce name uniqueness within the X.500 name space within its domain. Name uniqueness is not violated when multiple certificates are issued to the same Subscriber. Name uniqueness is enforced for the entire Subject Distinguished Name of the certificate rather than a particular attribute (e.g., the common name). The CA SHALL identify the method for checking uniqueness of Subject Distinguished Names within its domain. In the case of automated issuance of end-entity certificates this requirement MAY be fulfilled by the RA.
CAs operating under this policy SHALL not issue a certificate knowing that it infringes the trademark of another. Certificate Applicants SHALL not use names in their Certificate Applications that infringe upon the Intellectual Property Rights of others. Neither the WInnForum, nor any CA SHALL be required to determine whether a Certificate Applicant has Intellectual Property Rights in the name appearing in a Certificate Application or to arbitrate, mediate, or otherwise resolve any dispute concerning the ownership of any intellectual property rights, including, without limitation, rights in a domain name, trade name, trademark, or service mark, and WInnForum, and any CBSD CA SHALL be entitled, without liability to any Certificate Applicant, to reject or suspend any Certificate Application because of such dispute. The WInnForum SHALL resolve disputes involving names and trademarks.
If the Subscriber generates the certificate key pair, then the CA SHALL prove that the Subscriber possesses the private key by verifying the Subscriber's digital signature on the PKCS #10 Certificate Signing Request (CSR) with the public key in the CSR.
If the key pair is generated by the CA on behalf of a Subscriber; then in this case, proof of possession of the private key by the Subscriber is not required.
The WInnForum MAY approve other methods, including but not limited to the methods specified in section 1.5.5, to prove possession of a private key by a Subscriber.
The CA's certificate issuance process SHALL authenticate the identity of the organization named in the Digital Certificate Subscriber Agreement by confirming that the organization:
The CA's certificate issuance process SHALL authenticate the individual identity of the:
Non-verifiable information MAY be included in CBRS PKI certificates, such as:
The CA's certificate issuance process SHALL confirm that the:
CA and Subscriber certificate re-key shall follow the same procedures as initial certificate issuance. Identity MAY be established through the use of the device's current valid signature key.
If issuance of a new certificate is required due to certificate revocation, the Subscriber SHALL go through the initial identity validation process per CP § 3.2.
Revocation requests SHALL be authenticated and MAY be authenticated using that certificate's public key, regardless of whether or not the associated private key has been compromised.
The Certificate Application is a package consisting of the following:
A CA and RA SHALL include the processes, procedures, and requirements of their certificate application process in their CPS.
An application for a CA certificate SHALL be submitted by an authorized representative of the applicant CA.
An application for a Subscriber certificates SHALL be submitted by the Subscriber or an authorized representative of the Subscriber.
The enrollment process, for a Certificate Applicant, SHALL include the following:
Communication of information MAY be electronic or out-of-band.
The identification and authentication functions SHALL meet the requirements described in CP §§ 3.2 and 3.3.
A RA will approve a certificate application if all of the following criteria are met:
A RA will reject a certificate application for any of the following:
CAs SHALL begin processing certificate applications within a reasonable time of receipt. There is no time stipulation to complete the processing of an application unless otherwise indicated in the relevant Digital Certificate Subscriber Agreement or CPS.
To issue a certificate the CA SHALL receive the necessary information from an authorized RA which may include the Naming Document containing certificate profile details and a PKCS #10 certificate signing request (CSR). In the case where the Subscriber has implemented an automated manufacturing process for requesting and issuing end-entity certificates for installation into devices (e.g. CBSD) these actions between the CA and RA may also be automated.
CAs SHALL notify Subscribers that they have created the requested Certificate(s), and provide Subscribers with access to the Certificates by notifying them that their Certificates are available and the means for obtaining them. Certificates SHALL be made available to Subscribers, via download from the CA web site or via a Subscriber's CRA.
In the case where Subscribers have arranged to have a sub-CA operated onsite at their manufacturing facility, the CA is not required to notify the Subscriber of end-entity device certificate issuance and the certificate download requirement does not apply.
Before a Subscriber can make effective use of its private key, the CA SHALL explain to the Subscriber its responsibilities as defined in CP § 9.6.3.
In the case of the automated issuance of end entity certificates the Subscriber is the end entity. The manufacturer in this case SHALL ensure that these responsibilities are followed.
The following conduct constitutes certificate acceptance by the Subscriber:
CA certificates SHALL be published in a publicly available repository as specified in CP § 2.1.
This policy makes no stipulation regarding publication of Subscriber certificates.
The WInnForum SHALL be notified whenever a CA operating under this policy issues a CA certificate.
RAs MAY receive notification of the issuance of certificates they approve.
Subscriber private key usage SHALL be specified through the key usage extension in the associated certificate. Per the Digital Certificate Subscriber Agreement, Subscribers SHALL protect their private keys from unauthorized use and SHALL discontinue use of the private key following expiration or revocation of the certificate.
Certificate use SHALL be consistent with the key usage extensions included in the certificate.
Certificate renewal is the issuance of a new certificate for an existing key pair without changing any information in the certificate except the validity period and serial number.
Using a key pair beyond its intended lifetime can increase its vulnerability to attack. CA certificates SHALL NOT be renewed in this manner. End entity device certificates may be renewed as long as the Subject is notified of the security risks.
Device certificate renewal MAY be supported for certificates where the private key associated with the certificate has not been compromised. Device certificates MAY be renewed to maintain continuity of certificate usage
A device certificate MAY be renewed after expiration. The original certificate MAY be revoked, but SHALL NOT be further re-keyed, renewed, or modified.
The Subscriber of the certificate or an authorized representative of the Subscriber MAY request a certificate renewal.
For a certificate renewal request, the CA SHALL confirm the identity of the Subscriber in accordance with the requirements specified in CP § 3.2.
Notification of issuance of certificate renewal to the Subscriber SHALL be in accordance with CP § 4.3.2.
Conduct constituting Acceptance of a renewed certificate SHALL be in accordance with CP § 4.4.1.
Publication of a renewed certificate SHALL be in accordance with CP § 4.4.2.
Notification of the issuance of certificates SHALL be in accordance with CP § 4.4.3.
Certificate re-key consists of creating a new certificate for a different key pair (and serial number) but can retain the contents of the original certificate's subjectName. Certificate re-key does not violate the requirement for name uniqueness. The new certificate MAY be assigned a different validity period, key identifiers, and/or be signed with a different key.
A certificate MAY be re-keyed after expiration. The original certificate MAY be revoked, but SHALL NOT be further re-keyed, renewed, or modified.
The following may request a certificate re-key:
For certificate re-key, the CA SHALL confirm the identity of the Subscriber in accordance with the requirements specified in this CP § 3.2 for the authentication of an original Certificate Application.
CA certificate re-key SHALL be approved by the WInnForum.
Notification of issuance of a re-keyed certificate to the Subscriber SHALL be in accordance with CP § 4.3.2.
Conduct constituting Acceptance of a re-keyed certificate SHALL be in accordance with CP § 4.4.1.
Publication of a re-keyed certificate SHALL be in accordance with CP § 4.4.2.
Notification of the issuance of certificates SHALL be in accordance with CP § 4.4.3.
Modifying a certificate means creating a new certificate that contains a different X.509 serial number and that differs in one or more other fields from the original certificate except for the public key and validity period fields.
The original certificate MAY be revoked, but SHALL NOT be further re-keyed, renewed, or modified.
The following may request a certificate modification:
For certificate modification requests, the CA SHALL confirm the identity of the Subscriber in accordance with the requirements specified in this CP § 3.2 for the authentication of an initial Certificate Application.
CA certificate modification SHALL be approved by the WInnForum.
Notification of issuance of a new certificate to the Subscriber SHALL be in accordance with CP § 4.3.2.
Conduct constituting Acceptance of a modified certificate SHALL be in accordance with CP § 4.4.1.
Publication of a modified certificate SHALL be in accordance with CP § 4.4.2.
Notification of the issuance of certificates SHALL be in accordance with CP § 4.4.3.
Whenever any of the belowcircumstances occur, the associated certificate SHALL be revoked and placed on the CRL. Revoked certificates SHALL be included on all new publications of the certificate status information until the certificates expire.
Within the CBRS PKI, revocation requests MAY be made by:
A request to revoke a certificate SHALL identify the date of the request, the certificate to be revoked, the reason for revocation, and allow the requestor to be authenticated. The CA SHALL specify the steps involved in the process of requesting a certificate revocation in their CPS.
Prior to the revocation of a Subscriber Certificate, the CA SHALL authenticate the request. Acceptable procedures for authenticating revocation requests include:
CAs are entitled to request the revocation of Subscriber Certificates within the CA's Subdomain. CAs SHALL obtain approval from the WInnForum prior to performing the revocation functions except for revocations pursuant to CP § 4.9.1. The CA SHALL send a written notice and brief explanation for the revocation to the Subscriber. Notwithstanding anything to the contrary in this CP, CAs are authorized to take any action they deem necessary, under the circumstances and without liability to any party, to protect the security and integrity of the CA and/or the CBRS PKI.
The requests from CAs to revoke a CA Certificate SHALL be authenticated by the WInnForum.
Revocation requests SHOULD be submitted as promptly as possible within a reasonable time of becoming aware of a revocation circumstance listed in CP § 4.9.1.
CAs SHALL begin investigation of a Certificate revocation request within two (2) business days of receipt to decide whether revocation or other appropriate action is warranted based upon the circumstances of the request in CP § 4.9.1.
Relying Parties SHALL check the status of Certificates on which they wish to rely on by using one of the available means:
Relying parties find information on how to obtain CRLs from the CRL Distribution Point extension. For Legacy Certificates CRL distribution point URIs are provided along with the CA certificates as described in section 2.2.
CRLs SHALL be issued periodically, even if there are no changes to be made, to ensure timeliness of information. Certificate status information MAY be issued more frequently than the issuance frequency described below.
Online CBRS CAs SHALL update and reissue CRLs at least (i) once every two (2) months and (ii) within 24 hours after revoking a Certificate, with the value of the nextUpdate field not more than three (3) months beyond the value of the thisUpdate field. This ensures that a valid CRL is always available at the CRL distribution point URIs. Relying Parties should check for the availability of new revocation information according to the relevant security specifications.
Offline CBRS CAs SHALL update and reissue CRLs at least (i) once every twelve (12) months and (ii) within 24 hours after revoking a Certificate, with the value of the nextUpdate field not more than fourteen (14) months beyond the value of the thisUpdate field.
CRLs SHOULD be posted to the online repositories listed within the certificate CRL Distribution Point extension immediately and SHALL be posted within 24 hours of generation.
CAs SHALL provide Relying parties with the possibility to verify the revocation status of issued certificates. In particular, at minimum, CAs SHALL provide revocation information via CRLs and MAY provide revocation information via OCSP. CAs SHOULD provide Relying parties with the location of the revocation information directly within the certificate (via the relevant data and extensions) and MAY provide the location of revocation information by other means.
A Relying Party SHALL check the status of a certificate on which they wish to rely. Such a check SHOULD be made by using CRL. In lieu of CRL, a relying party MAY check certificate status by means of a valid OCSP response.
4.9.11 Other Forms of Revocation Advertisements Available
A CA may also use other methods to publicize the certificates it has revoked. Any alternative method SHALL meet the following requirements:
4.9.12 Special Requirements Regarding Key Compromise
No stipulation.
4.9.13 Circumstances for Suspension
The CBRS PKI does not offer suspension services for its Certificates.
4.9.14 Who can Request Suspension
No stipulation.
4.9.15 Procedure for Suspension Request
No stipulation.
4.9.16 Limits on Suspension Period
No stipulation.
CAs SHALL operate at least one CRL repository where the status of issued certificates can be queried. The repository SHALL be accessible via HTTP and MAY support also additional transfer protocols.
In Legacy Certificates, complying to the certificate of earlier versions of this document, the CRL Distribution Point extension was not set. Distribution points URIs for those certificates SHALL be provided along with the CA certificates as described in section 2.2.
Certificate Status Services SHALL be available 24 x 7. CRL and OCSP capability SHOULD provide a response time of ten (10) seconds or less under normal operating conditions.
4.10.3 Optional Features
CRLs MAY also be available via LDAP or other repositories.
Certificate Status MAY also be available through OCSP.
End of subscription SHALL be stipulated in the Digital Certificate Subscriber Agreement.
4.12.1 Key Escrow and Recovery Policy and Practices
No stipulation.
4.12.2 Session Key Encapsulation and Recovery Policy and Practices
No stipulation.
All entities performing CA functions SHALL implement and enforce the following physical, procedural, logical, and personnel security controls for a CA.
CA equipment SHALL be protected from unauthorized access while the cryptographic module is installed and activated. The CA SHALL implement physical access controls to reduce the risk of equipment tampering even when the cryptographic module is not installed and activated. CA cryptographic tokens SHALL be protected against theft, loss, and unauthorized use.
All the physical control requirements specified below apply equally to the Root CAs and subordinate CAs, and any remote workstations used to administer the CAs except where specifically noted.
All CA systems SHALL be located within a physically protected environment that deters, prevents, and detects unauthorized use of, access to, or disclosure of sensitive information and systems. The location and construction of the facility housing the CA equipment, as well as sites housing remote workstations used to administer the CAs, SHALL be consistent with facilities used to house highvalue, sensitive information. The site location and construction, when combined with other physical security protection mechanisms such as guards, high security locks, and intrusion sensors, SHALL provide robust protection against unauthorized access to the CA equipment and records.
Such requirements are based in part on the establishment of physical security tiers. A tier is a barrier such as a locked door, a closed gate, or an alarm system that provides mandatory access control for individuals and requires a positive response (e.g., door unlocks, gate opens, or alarm system is disarmed) for each individual to proceed to the next area. Each successive tier provides more restricted access and greater physical security against intrusion or unauthorized access.
DEPRECATED: Moreover, each physical security tier encapsulates the next inner tier, such that an inner tier SHALL be fully contained in an outside tier and cannot have a common outside wall with the outside tier, the outermost tier being the outside barrier of the building (e.g., a perimeter fence or outside wall).
DEPRECATED: CAs using Automated Administration SHALL place the Automated Administration server in Tier 4 or higher.
The CA SHALL describe the tiers of its physical security within its CPS*.* The CA SHALL perform validation of certificate information and issuance of certificates within a combination of physical and logical security levels that prohibits access to individuals not operating in a trusted role.
CAs SHALL protect offline cryptographic modules by placing them in a security tier that prohibits unauthenticated access when not in use.
Access to each tier of physical security, constructed in accordance with CP § 5.1.1, SHALL be auditable and controlled so that only authorized personnel can access each tier.
CAs SHALL control access to their CA facilities including:
Although not required, the use of biometric readers (e.g., hand geometry or iris scan) that provide two-factor authentication is recommended.
At a minimum, the physical access controls for CA equipment, as well as remote workstations used to administer the CAs, SHALL:
When not in use, removable cryptographic modules, activation information used to access or enable cryptographic modules SHALL be placed in secure containers. Activation data SHALL be either memorized or recorded and stored in a manner commensurate with the security afforded the cryptographic module, and SHALL NOT be stored with the cryptographic module or removable hardware associated with remote workstations used to administer the CA.
A security check of the facility housing the CA equipment or remote workstations used to administer the CAs SHALL occur if the facility is to be left unattended. At a minimum, the check SHALL verify the following:
A person or group of persons SHALL be made explicitly responsible for making such checks. When a group of persons is responsible, a log identifying the person performing a check at each instance SHALL be maintained. If the facility is not continuously attended, the last person to depart SHALL initial a sign-out sheet that indicates the date and time and asserts that all necessary physical protection mechanisms are in place and activated.
CA facilities SHALL be equipped with primary and backup power systems to ensure continuous, uninterrupted access to electric power. Also, these facilities SHALL be equipped with primary and backup heating/ventilation/air conditioning systems to control temperature and relative humidity.
The CA SHALL have backup capability sufficient to lock out input, finish any pending actions, and record the state of the equipment automatically before lack of power or air conditioning causes a shutdown.
DEPRECATED: The repositories (containing CA certificates and CRLs) SHALL be provided with uninterrupted power sufficient for a minimum of 6 hours operation in the absence of commercial power, to maintain availability and avoid denial of service.
CA facilities SHALL be constructed, equipped and installed, and procedures SHALL be implemented, to prevent floods or other damaging exposure to water. Potential water damage from fire prevention and protection measures (e.g., sprinkler systems) are excluded from this requirement.
CA facilities SHALL be constructed and equipped, and procedures SHALL be implemented, to prevent and extinguish fires or other damaging exposure to flame or smoke. These measures SHALL meet all local applicable safety regulations.
CAs SHALL protect the media holding back ups of critical system data or any other sensitive information from water, fire, or other environmental hazards, and SHALL use protective measures to deter, detect, and prevent the unauthorized use of, access to, or disclosure of such media.
CAs SHALL implement procedures for the disposal of waste (paper, media, or any other waste) to prevent the unauthorized use of, access to, or disclosure of waste containing Confidential/Private Information.
CA media and documentation that are no longer needed for operations SHALL be destroyed in a secure manner. For example, paper documentation SHALL be shredded, burned, or otherwise rendered unrecoverable.
CAs SHALL maintain backups of critical system data or any other sensitive information, including audit data, in a secure off-site facility. Full system backups sufficient to recover from system failure SHALL be made on a periodic schedule, and described in a CA's CPS. Backups are to be performed and stored off-site not less than once per week. At least one full backup copy SHALL be stored at an off-site location (separate from CA equipment). Only the latest full backup need be retained. The backup SHALL be stored at a site with physical and procedural controls commensurate to that of the operational CA. An active/active infrastructure, whereby data are synchronized between two sites and one site alone is capable of hosting the CBRS PKI in the event of a disaster at the other site, will meet the requirements of off-site backup.
Requirements for CA private key backup are specified in CP § 6.2.4.
Procedural controls are requirements on roles that perform functions that can introduce security problems if not carried out properly, whether accidentally or maliciously. The people selected to fill these roles SHALL be extraordinarily responsible, or the integrity of the CA will be weakened. The functions performed in these roles form the basis of trust for the entire PKI. Two approaches are taken to increase the likelihood that these roles can be successfully carried out. The first ensures that the person filling the role is trustworthy and properly trained. The second distributes the functions among more than one person, so that any malicious activity would require collusion.
Employees, contractors, and consultants that are designated to manage the CA's trustworthiness SHALL be considered to be "Trusted Persons" serving in "Trusted Positions." Persons seeking to become Trusted Persons SHALL meet the screening requirements of CP § 5.3.
CAs SHALL consider the categories of their personnel identified in this section as Trusted Persons having a Trusted Position. Trusted Persons include all employees, contractors, and consultants that have access to or control authentication or cryptographic operations that may materially affect:
Trusted Persons include, but are not limited to, customer service personnel, CA system administrators, designated engineering personnel, CA operators, auditor, and executives that are designated to manage infrastructural trustworthiness.
Multiparty control procedures are designed to ensure that at a minimum, two trusted personnel are required to have either physical or logical access to the CA. Access to CA cryptographic hardware SHALL be strictly enforced by multiple Trusted Persons throughout its lifecycle, from incoming receipt and inspection to final logical and/or physical destruction. Once a CA device is activated with operational keys, further access controls SHALL be invoked to maintain split control over both physical and logical access to the device. Persons with physical access to CA modules do not hold "Secret Shares" to activate the CA and vice versa.
Two or more persons are required for the following tasks:
Where multiparty control is required, at least one of the participants SHALL be an Administrator. All participants SHALL serve in a trusted role as defined in CP § 5.2.1. Multiparty control SHALL NOT be achieved using personnel that serve in the Auditor trusted role. CAs SHALL establish, maintain, and enforce rigorous control procedures to ensure the segregation of duties based on job responsibility and to ensure that multiple Trusted Persons are required to perform sensitive tasks.
Other manual operations such as the validation and issuance of Certificates, not issued by an automated validation and issuance system, require the participation of at least 2 Trusted Persons, or a combination of at least one trusted person and an automated validation and issuance process.
CAs SHALL confirm the identity and authorization of all personnel seeking to become Trusted Persons before such personnel are:
Authentication of identity SHALL include the personal (physical) presence of such personnel before Trusted Persons performing HR or security functions within an entity and a check of wellrecognized forms of identification, such as passports and driver's licenses. Identity SHALL be further confirmed through background checking procedures in CP § 5.3.
Roles requiring Separation of duties include (but are not limited to) the:
No individual SHALL have more than one trusted role. CA SHALL have in place procedure to identify and authenticate its users and SHALL ensure that no user identity can assume multiple roles.
CAs SHALL require that personnel assigned to Trusted roles have the requisite background, qualifications, and experience or be provided the training needed to perform their prospective job responsibilities competently and satisfactorily. The requirements governing the qualifications, selection and oversight of individuals who operate, manage, oversee, and audit the CA SHALL be set forth in the CPS.
CAs SHALL conduct background check procedures for personnel tasked become Trusted Persons. These procedures SHALL be subject to any limitations on background checks imposed by local law. To the extent one of the requirements imposed by this section cannot be met due to a prohibition or limitation in local law, the investigating entity SHALL utilize a substitute investigative technique permitted by law that provides substantially similar information, including but not limited to obtaining a background check performed by an applicable agency. Background investigations MAY include a:
Factors revealed in a background check that MAY be considered grounds for rejecting candidates for Trusted Positions or for taking action against an existing Trusted Person (all subject to and in accordance with applicable law) MAY include but is not limited to the following:
Background checks SHALL be repeated for personnel holding Trusted Positions at least every five (5) years.
CAs SHALL provide their personnel with the requisite on-the-job training needed for their personnel to perform their job responsibilities relating to CA operations competently and satisfactorily. They SHALL also periodically review their training programs, and their training SHALL address the elements relevant to functions performed by their personnel.
Training programs SHALL address the elements relevant to the particular environment of the person being trained, including, without limitation:
CAs SHALL provide refresher training and updates to their personnel to the extent and frequency required to ensure that such personnel maintain the required level of proficiency to perform their job responsibilities competently and satisfactorily.
All individuals responsible for PKI roles SHALL be made aware of changes in the CA operation. Any significant change to the operations SHALL have a training (awareness) plan, and the execution of such plan SHALL be documented. Examples of such changes are CA software or hardware upgrade, changes in automated security systems, and relocation of equipment.
Documentation SHALL be maintained identifying all personnel who received training and the level of training completed.
No stipulation.
CAs SHALL establish, maintain, and enforce policies for the discipline of personnel following unauthorized actions. Disciplinary actions MAY include measures up to and including termination and SHALL be commensurate with the frequency and severity of the unauthorized actions.
CAs SHALL permit independent contractors or consultants to become Trusted Persons only to the extent necessary to accommodate clearly defined outsourcing relationships. CAs SHOULD only use contractors or consultants as Trusted Persons if the CA does not have suitable employees available to fill the roles of Trusted Persons. Otherwise, independent contractors and consultants SHALL be escorted and directly supervised by Trusted Persons when they are given access to the CA and its secure facility.
Contractors fulfilling trusted roles are subject to all personnel requirements stipulated in this policy and SHALL establish procedures to ensure that any subcontractors perform in accordance with this policy.
CAs SHALL give their personnel the requisite training and documentation needed to perform their job responsibilities competently and satisfactorily.
Audit log files SHALL be generated for all events relating to the security of the CA. Where possible, the audit logs SHALL be automatically collected. Where this is not possible, a logbook, paper form, or other physical mechanism SHALL be used. All CA audit logs, both electronic and non-electronic, SHALL be retained and made available during compliance audits. In the case of
the automated issuance of end-entity certificates, the automated RA MAY perform the tasks mentioned in this section if delegated by the CA.
All auditing capabilities of the CA operating system and applications SHALL be enabled during installation. All audit logs, whether recorded automatically or manually, SHALL contain the date and time, the type of event, and the identity of the entity that caused the event.
CAs SHALL record in audit log files all events relating to the security of the CA system, including, without limitation:
CAs SHALL review their audit logs in response to alerts based on irregularities and incidents within their CA systems. Review of the audit log SHALL be required at least once every three months. CAs SHALL compare their audit logs with supporting manual and electronic logs when any action is deemed suspicious.
Audit log processing SHALL consist of a review of the audit logs and documenting the reason for all significant events in an audit log summary. Audit log reviews SHALL include a verification that the log has not been tampered with, a brief inspection of all log entries, and a more thorough investigation of any alerts or irregularities in the logs. Actions taken based on audit log reviews SHALL be documented.
Audit logs SHALL be retained onsite at least two (2) months after processing and thereafter archived in accordance with CP § 5.5. The individual who removes audit logs from the CA system SHALL be different from the individuals who, in combination, command the CA signature key.
Audit logs SHALL be protected from unauthorized viewing, modification, deletion, or other tampering. CA system configuration and procedures SHALL be implemented together to ensure that only authorized people archive or delete security audit data. Procedures SHALL be implemented to protect archived data from deletion or destruction before the end of the security audit data retention period (note that deletion requires modification access).
Incremental backups of audit logs SHALL be created frequently, at least monthly.
The audit log collection system MAY be external to the CA system. Automated audit processes SHALL be invoked at system or application startup and cease only at system or application shutdown. Audit collection systems SHALL be configured such that security audit data is protected against loss (e.g., overwriting or overflow of automated log files). Should it become apparent that an automated audit system has failed, and the integrity of the system or confidentiality of the information protected by the system is at risk, operations SHALL be suspended until the problem has been remedied.
Where an event is logged by the audit collection system, no notice is required to be given to the individual, organization, device, or application that caused the event.
The CA SHALL perform routine self-assessments of security controls for vulnerabilities. Events in the audit process are logged, in part, to monitor system vulnerabilities. The assessments SHALL be performed following an examination of these monitored events. The assessments SHALL be based on real-time automated logging data and SHALL be performed at least on an annual basis as input into an entity's annual Compliance Audit.
The audit data SHOULD be reviewed by the security auditor for events such as repeated failed actions, requests for privileged information, attempted access of system files, and unauthenticated responses. Security auditors SHOULD check for continuity of the audit data.
CA archive records SHALL be sufficiently detailed to determine the proper operation of the CA and the validity of any certificate (including those revoked or expired) issued by the CA. Records MAY be kept in the form of either computer-based messages or paper-based documents, provided their indexing, storage, preservation, and reproduction are accurate, reliable, and complete.
The CA records SHALL include all relevant evidence in the recording entity's possession, including, without limitation:
The RA records SHALL include all relevant evidence in the recording entity's possession, including, without limitation:
The following shall also be included in RA records only in the case of the automated issuance of end-entity certificates:
Archive records SHALL be kept for a minimum of 10 years without any loss of data.
An entity maintaining an archive of records SHALL protect the archive so that only the entity's authorized Trusted Persons are able to obtain access to the archive. The archive SHALL be protected against unauthorized viewing, modification, deletion, or other tampering. The archive media and the applications required to process the archive data SHALL be maintained to ensure that the archive data can be accessed for the time period set forth in CP § 5.5.2.
Entities compiling electronic information SHALL perform full backups on a weekly basis. Copies of paper-based records SHALL be maintained in an off-site secure facility.
CA archive records SHALL be automatically time-stamped as they are created. System clocks used for time-stamping SHALL be maintained in synchrony with an authoritative time standard.
Archive data may be collected in any expedient manner.
Only authorized Trusted Personnel are able to obtain access to the archive. The integrity of the information is verified as usable when it is restored.
When a CA certificate is rekeyed only the new key is used to sign certificates from that time on. If the old private key is used to sign OCSP responses, OCSP responder certificates or CRLs that cover certificates signed with that key, the old key SHALL be retained and protected.
A CA Certificate may be renewed if the CA's Superior Entity reconfirms the identity of the CA. Following such reconfirmation, the Superior Entity SHALL either approve or reject the renewal application.
When a CA updates its private signature key and thus generates a new public key, the CA SHALL notify all CAs, RAs, and Subscribers that rely on the CA's certificate that it has been changed.
The WInnForum SHALL be notified if any CAs operating under this policy experience the following:
The WInnForum will take appropriate steps to protect the integrity of the CBRS PKI.
The CA's Management Authority SHALL reestablish operational capabilities as quickly as possible in accordance with procedures set forth in the CA's CPS.
When computing resources, software, and/or data are corrupted, CAs operating under this policy SHALL respond as follows:
In the event of a CA private key compromise, the following operations SHALL be performed.
Entities operating CAs SHALL develop, test, and maintain a Disaster Recovery Plan designed to mitigate the effects of any kind of natural or man-made disaster. The Plan SHALL identify conditions for activating the recovery and what constitutes an acceptable system outage and recovery time for the restoration of information systems services and key business functions within a defined recovery time objective (RTO).
CAs SHALL have the capability of restoring or recovering essential operations within twenty-four (24) hours following a disaster with, at a minimum, support for the following functions: Certificate issuance, Certificate revocation, and publication of revocation information. The disaster recovery equipment SHALL have physical security protections comparable to the production CA system, which includes the enforcement of physical security tiers.
A CA's disaster recovery plan SHALL make provisions for full recovery within one week following a disaster at the primary site.
When a CA operating under this policy terminates operations before all certificates have expired, the CA signing keys SHALL be surrendered to the WInnForum. Prior to CA termination, the CA SHALL provide archived data to an archive facility as specified in the CPS. As soon as possible, the CA will advise all other organizations to which it has issued certificates of its termination, using an agreed-upon method of communication specified in the CPS.
CAs that have ceased issuing new certificates but are continuing to issue CRLs until all certificates have expired are required to continue to conform with all relevant aspects of this policy (e.g., audit logging and archives).
The termination of a CBRS CA SHALL be subject to the contract between the terminating CA and its Superior Entity. A terminating CA and its Superior Entity SHALL, in good faith, use commercially reasonable effort to agree on a termination plan that minimizes disruption to Subscribers and Relying Parties. The termination plan MAY cover issues such as:
Key pair generation SHALL be performed using FIPS 140 validated cryptographic modules and processes that provide the required cryptographic strength of the generated keys and prevent the loss, disclosure, modification, or unauthorized use of private keys. Any pseudo-random numbers use and parameters for key generation material SHALL be generated by a FIPS-approved method.
CA keys SHALL be generated in a Key Generation Ceremony using multi-person control for CA key pair generation, as specified in CP § 6.2.2.
CA key pair generation SHALL create a verifiable audit trail that the security requirements for procedures were followed. The documentation of the procedure SHALL be detailed enough to show that appropriate role separation was used. An independent third party SHALL validate the execution of the key generation procedures either by witnessing the key generation or by examining the signed and documented record of the key generation.
Subscriber key pair generation SHALL be performed by the Subscriber or CA. If the Subscribers themselves generate private keys, then private key delivery to a Subscriber is unnecessary.
When CAs generate key pairs on behalf of the Subscriber, the private key SHALL be delivered securely to the Subscriber. Private keys SHALL be delivered electronically or on a hardware cryptographic module. In all cases, the following requirements SHALL be met:
When a public key is transferred to the issuing CA to be certified, it SHALL be delivered through a mechanism validating the identity of the Subscriber and ensuring that the public key has not been altered during transit and that the Certificate Applicant possesses the private key corresponding to the transferred public key. The Certificate Applicant SHALL deliver the public key in a PKCS#10 CSR or an equivalent method ensuring that the public key has not been altered during transit; and with proof that the Certificate Applicant possesses the private key corresponding to the transferred public key. The Certificate Applicant will submit the CSR via their online Certificate Requesting Account, which employs two-factor authentication, e.g., a USB token with the account administrator's certificate and a PIN (this procedure is not applicable in the case of the automated issuance of end-entity certificates).
The Root CA public key certificate SHALL be delivered to Relying Parties in a secure fashion to preclude substitution attacks. Acceptable methods for certificate delivery are:
Elliptic Curve Cryptography (ECC) public key parameters SHALL be selected from the set specified in CP § 7.1.3.
Table 2 shows the specific keyUsage extension settings for CBRS CA certificates and specifies that all CA certificates (i.e., Root CAs, Sub-CAs):
Table 2: keyUsage Extension for all CA certificates
| Field | Format | Criticality | Value | Comment |
|---|---|---|---|---|
| keyUsage | BIT STRING | TRUE | { id-ce 15 } | Included in all CA certificates |
| (0) | 0 / 1 | Optional | ||
| digitalSignature | (1) | 0 | Not Set | |
| nonRepudiation | (2) | 0 | Not Set | |
| keyEncipherment | (3) | 0 | Not Set | |
| dataEncipherment | ||||
| keyAgreement | (4) | 0 | Not Set | |
| keyCertSign | (5) | 1 | Set | |
| cRLSign | (6) | 1 | Set | |
| encipherOnly | (7) | 0 | Not Set | |
| decipherOnly | (8) | 0 | Not Set |
Table 3 shows the specific keyUsage extension settings for CBRS Subscriber end-entity device certificates that contain RSA or ECC public keys and specifies that all Subscriber device certificates:
Table 3: keyUsage Extension for Subscriber Certificates with RSA Public Keys
| Field | Format | Criticality | Value | Comment |
|---|---|---|---|---|
| keyUsage | BIT STRING | TRUE | { id-ce 15 } | Included in all Subscriber certificates |
| (0) | 1 | Set | ||
| digitalSignature | ||||
| (1) | 0 | Not Set | ||
| nonRepudiation | ||||
| (2) | 1 | Set for RSA | ||
| keyEncipherment | ||||
| (3) | 0 | Not Set | ||
| dataEncipherment | ||||
| keyAgreement | (4) | 0 | Set for ECC | |
| keyCertSign | (5) | 0 | Not Set | |
| cRLSign | (6) | 0 | Not Set | |
| encipherOnly | (7) | 0 | Not Set | |
| decipherOnly | (8) | 0 | Not Set |
CA Private keys within the CBRS PKI SHALL be protected using FIPS 140-2 Level 3 systems. Private key holders SHALL take necessary precautions to prevent the loss, disclosure, modification, or unauthorized use of such Private Keys in accordance with this CP and contractual obligations specified in the appropriate WInnForum Agreement.
The relevant standard for cryptographic modules is Security Requirements for Cryptographic Modules [FIPS 140-2].
Root CAs SHALL perform all CA cryptographic operations on cryptographic modules rated at a minimum of FIPS 140-2 level 3 or higher.
Sub-CAs SHALL use a FIPS 140-2 Level 3 or higher validated hardware cryptographic module.
Subscribers SHOULD use a FIPS 140-2 Level 1 or higher validated cryptographic module for their cryptographic operations.
Subscribers of CBSD certificates SHALL secure keying material as defined in the WInnForum ComSec specification.
Multi-person control is enforced to protect the activation data needed to activate CA private keys so that a single person SHALL not be permitted to activate or access any cryptographic module that contains the complete CA private signing key.
CA signature keys SHOULD be backed up only under multi-person control. Access to CA signing keys backed up for disaster recovery SHALL be under multi-person control. The names of the parties used for multi-person control SHALL be maintained on a list that SHALL be made available for inspection during compliance audits.
CAs MAY use "Secret Sharing" to split the private key or activation data needed to operate the private key into separate parts called "Secret Shares" held by individuals called "Shareholders." Some threshold number of Secret Shares (m) out of the total number of Secret Shares (n) SHALL be required to operate the private key. The minimum threshold number of shares (m) needed to sign a CA certificate SHALL be 3. The total number of shares (n) used SHALL be greater than the minimum threshold number of shares (m).
CAs MAY also use Secret Sharing to protect the activation data needed to activate private keys located at their respective disaster recovery sites. The minimum threshold number of shares (m) needed to sign a CA certificate at a disaster recovery site SHALL be 3. The total number of shares (n) used SHALL be greater than the minimum threshold number of shares (m).
CA private keys and Subscriber private keys SHALL NOT be escrowed.
CAs SHALL back up their private keys, under the same multi-person control as the original signature key. The backups allow the CA to be able to recover from disasters and equipment malfunction. At least one copy of the private signature key SHALL be stored off-site. Private keys that are backed up SHALL be protected from unauthorized modification or disclosure through physical or cryptographic means. Backups, including all activation data needed to activate the cryptographic token containing the private key, SHALL be protected with a level of physical and cryptographic protection equal to or exceeding that for cryptographic modules within the CA site, such as at a disaster recovery site or at another secure off-site facility, such as a bank safe. All copies of the CA private signature key SHALL be accounted for and protected in the same manner as the original.
Device private keys MAY be backed up or copied, but SHALL be held under the control of the Subscriber or other authorized administrator. Backed up device private keys SHALL NOT be stored in plaintext form and storage SHALL ensure security controls consistent with the WInnForum security specifications the device is compliant with. Subscribers MAY have the
option of using enhanced private key protection mechanisms available today including the use of smart cards, biometric access devices, and other hardware tokens to store private keys.
CA private keys and Subscriber private keys SHALL NOT be archived. Upon expiration of a CA Certificate, the key pair associated with the certificate will be securely retained for a period of at least 5 years using hardware cryptographic modules that meet the requirements of this CP. These CA key pairs SHALL NOT be used for any signing events after the expiration date of the corresponding CA Certificate, unless the CA Certificate has been renewed in terms of this CP.
CA private keys MAY be exported from the cryptographic module only to perform CA key backup procedures as described in CP § 6.2.4. At no time shall the CA private key exist in plaintext outside the cryptographic module.
All other keys SHALL be generated by and in a cryptographic module. In the event that a private key is to be transported from one cryptographic module to another, the private key SHALL be encrypted during transport; private keys SHALL never exist in plaintext form outside the cryptographic module boundary.
Private or symmetric keys used to encrypt other private keys for transport SHALL be protected from disclosure.
Entry of a private key into a cryptographic module SHALL use mechanisms to prevent loss, theft, modification, unauthorized disclosure, or unauthorized use of such private key.
CA or RA private keys generated on one hardware cryptographic module and transferred into another device shall be securely transferred into the second cryptographic module in a manner that prevents loss, theft, modification, unauthorized disclosure, or unauthorized use of such private keys. Such transfers shall be limited to making backup copies of the private keys on tokens.
CAs pre-generating private keys and transferring them into a hardware token, for example transferring generated end-user Subscriber private keys into a smart card, SHALL securely transfer such private keys into the token in a manner that prevents the loss, theft, modification, unauthorized disclosure, or unauthorized use of such private keys.
No stipulation beyond that specified in FIPS 140-2.
All CAs SHALL protect the activation data for their private keys against loss, theft, modification, disclosure, or unauthorized use.
CA administrators SHALL be authenticated to the cryptographic token before the activation of the associated private key(s). Acceptable means of authentication include but are not limited to passphrases, PINs or biometrics. Entry of activation data SHALL be protected from disclosure (i.e., the data should not be displayed while it is entered).
For device certificates, the device MAY be configured to activate its private key, provided that appropriate physical and logical access controls are implemented for the device. The strength of the security controls SHALL be commensurate with the level of threat in the device's environment, and SHALL protect the device's hardware, software, private keys and its activation data from compromise.
CA Administrator Activation
Method of activating the CA system by a CA Administrator SHALL require:
Offline Root CAs Private Key
Once the CA system has been activated, a threshold number of Shareholders SHALL be required to supply their activation data in order to activate an offline CA's private key, as defined in CP § 6.2.2. Once the private key is activated, it SHALL be active until termination of the session.
Online Subordinate CAs Private Keys
An online CA's private key SHALL be activated by a threshold number of Shareholders, as defined in CP § 6.2.2, supplying their activation data (stored on secure media). Once the private key is activated, the private key may be active for an indefinite period until it is deactivated when the CA goes offline.
Subscriber Private Keys
The WInnForum standards for protecting activation data for Subscribers' private keys SHALL be in accordance with the specific obligations appearing in the applicable agreement executed between WInnForum and the Subscriber.
Cryptographic modules that have been activated SHALL NOT be available to unauthorized access. After use, the cryptographic module SHALL be deactivated, e.g., via a manual logout procedure
or automatically after a period of inactivity. CA cryptographic modules SHALL be stored securely when not in use.
When an online CA is taken offline, the CA SHALL remove the token containing the private key from the reader in order to deactivate it, or take similar action based upon the type of hardware used to store the private key.
With respect to the private keys of offline CAs, after the completion of a Key Generation Ceremony, in which such private keys are used for private key operations, the CA SHALL remove the token containing the private keys from the reader in order to deactivate them, or take similar action based upon the type of hardware used to store the private key. Once removed from the reader, tokens SHALL be securely stored.
When an online CA is taken offline, the CA SHALL remove the token containing such CA's private key from the reader in order to deactivate it.
When deactivated, private keys SHALL be kept in encrypted form only.
6.2.10 Method of Destroying Private Key
Private keys SHALL be destroyed in a way that prevents their theft, disclosure, or unauthorized use.
Upon termination of the operations of a CA, individuals in trusted roles SHALL decommission the CA private signature keys by deleting it using functionality of the token containing such CA's private key so as to prevent its recovery following deletion, or the loss, theft, modification, disclosure, or unauthorized use of such private key. CA private keys SHALL be destroyed in a manner that reasonably ensures that there are no residuals remains of the key that could lead to the reconstruction of the key.
For Root CAs, WInnForum security personnel SHALL witness this process.
Subscribers MAY destroy their private signature keys when they are no longer needed or when the certificates to which they correspond expire or are revoked. Physical destruction of hardware is not required.
6.2.11 Cryptographic Module Rating
See CP § 6.2.1.
6.3.1 Public Key Archival
CAs MAY archive their public keys in accordance with CP § 5.5.1.
The certificate validity period (i.e., certificate operational period and key pair usage period) SHALL be set to the time limits set forth as follows:
Validity periods SHALL be nested such that the validity periods of issued certificates SHALL be contained within the validity period of the issuing CA.
As necessary to ensure the continuity and security of the CBRS PKI, WInnForum SHALL commission new CAs.
If certificates are not renewed, CBRS PKI Participants SHALL cease all use of their private keys after their usage periods have expired.
CAs SHALL generate and install activation data for their private keys and SHALL use methods that protect the activation data to the extent necessary to prevent the loss, theft, modification, disclosure, or unauthorized use of such activation data.
To the extent passwords are used as activation data, CAs activation participants SHALL generate passwords that cannot easily be guessed or cracked by dictionary attacks. Participants may not need to generate activation data, for example if they use biometric access devices.
CAs SHALL protect the activation data for their private keys using methods that protect against the loss, theft, modification, unauthorized disclosure, or unauthorized use of such private keys.
CAs SHALL use multi-party control in accordance with CP § 6.2.2. CAs SHALL provide the procedures and means to enable Shareholders to take the precautions necessary to prevent the loss, theft, modification, disclosure, or unauthorized use of the Secret Shares that they possess. Shareholders SHALL not:
The Secret Shares and any information disclosed to the Shareholder in connection with their duties as a Shareholder SHALL constitute Confidential/Private Information.
CAs SHALL include in their disaster recovery plans provisions for making Secret Shares available at a disaster recovery site after a disaster (Note, the important aspect of disaster recovery vis-à-vis
shares is that a process exists for making the necessary number of shares available, even if the requisite shareholders are not available.). CAs SHALL maintain an audit trail of Secret Shares, and Shareholders SHALL participate in the maintenance of an audit trail.
Activation Data Transmission
To the extent activation data for their private keys are transmitted, Activation Data Participants SHALL protect the transmission using methods that protect against the loss, theft, modification, unauthorized disclosure, or unauthorized use of such private keys. To the extent desktop computer or network logon user name/password combination is used as activation data for an end-user Subscriber, the passwords transferred across a network SHALL be protected against access by unauthorized users.
Activation Data Destruction
Activation data for CA private keys SHALL be decommissioned using methods that protect against the loss, theft, modification, unauthorized disclosure, or unauthorized use of the private keys protected by such activation data. After the record retention periods in CP § 5.5.2 lapses, CAs SHALL decommission activation data by overwriting and/or physical destruction.
CAs SHALL ensure that the systems maintaining CA software and data files are Trustworthy Systems secure from unauthorized access, which can be demonstrated by compliance with audit criteria applicable under CP § 5.4.1. In addition, CAs SHALL limit access to production servers to those individuals with a valid business reason for access. General application users SHALL not have accounts on the production servers.
CAs SHALL have production networks logically separated from other components. This separation prevents network access except through defined application processes. CAs SHALL use firewalls to protect the production network from internal and external intrusion and limit the nature and source of network activities that may access production systems.
To the extent that passwords are used, CAs SHALL require the use of passwords with a minimum character length and a combination of alphanumeric and special characters, and SHALL require that passwords be changed on a periodic basis and whenever necessary. Direct access to a CA's database maintaining the CA's repository SHALL be limited to Trusted Persons having a valid business reason for such access.
Computer security controls are required to ensure CA operations are performed as specified in this policy. The following computer security functions MAY be provided by the operating system, or through a combination of operating system, software, and physical safeguards:
For other CAs operating under this policy, the computer security functions listed below are required. These functions MAY be provided by the operating system, or through a combination of operating system, software, and physical safeguards. The CA and its ancillary parts SHALL include the following functionality:
For certificate status servers operating under this policy, the computer security functions listed below are required:
For remote workstations used to administer the CAs, the computer security functions listed below are required:
All communications between any PKI trusted role and the CA SHALL be authenticated and protected from modification.
6.5.2 Computer Security Rating
No Stipulation.
The system development controls for the CA are as follows:
The configuration of the CA system, in addition to any modifications and upgrades, SHALL be documented and controlled. There SHALL be a mechanism for detecting unauthorized modification to the software or configuration. The CA software, when first loaded, SHALL be verified as being that supplied from the vendor, with no modifications, and be the version intended for use.
6.6.3 Life Cycle Security Controls
No Stipulation.
A network guard, firewall, or filtering router SHALL protect network access to CA equipment. The network guard, firewall, or filtering router SHALL limit services allowed to and from the CA equipment to those required to perform CA functions.
Protection of CA equipment SHALL be provided against known network attacks. All unused network ports and services SHALL be turned off. Any network software present on the CA equipment SHALL be necessary to the functioning of the CA application.
Any boundary control devices used to protect the network on which PKI equipment is hosted SHALL deny all but the necessary services to the PKI equipment.
Repositories, certificate status servers, and remote workstations used to administer the CAs SHALL employ appropriate network security controls. Networking equipment SHALL turn off unused network ports and services. Any network software present SHALL be necessary to the functioning of the equipment.
The CA SHALL establish connection with a remote workstation used to administer the CA only after successful authentication of the remote workstation at a level of assurance commensurate with that of the CA.
Certificates, CRLs, and other revocation database entries SHALL contain time and date information. Such time information need not be cryptographic-based. Asserted times SHALL be accurate to within three minutes. Electronic or manual procedures MAY be used to maintain system time. Clock adjustments are auditable events (see CP § 5.4.1).
CBRS PKI Certificates SHALL conform to [RFC 5280]: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, May 2008. Text fields are encoded using utf8String encoding.
CBRS PKI Certificates SHALL contain the identity and attribute data of a subject using the base certificate with applicable extensions. The base certificate SHALL contain the version number of the certificate, the certificate's identifying serial number, the signature algorithm used to sign the certificate, the issuer's distinguished name, the validity period of the certificate, the subject's distinguished name, information about the subject's public key, and extensions as defined in the following certificate profile tables.
CBRS PKI Certificates MAY be used in testing environments if they meet the following requirements for "Test Certificates". Test certificates SHALL contain the WInnForum Poison extension (OID 1.3.6.1.4.1.46609.1.999). If included in a certificate, the WInnForum Poison extension SHALL be marked Critical and its extnValue OCTET STRING SHALL contain only ASN.1 NULL data (0x05 0x00).
EDITOR NOTE: The WINNF document is very dense and complex at this point. Here we simplify for web display. The original remains authoritative.
📘Simplified PKI Specification (RSA + ECC Profiles)
Structured into clean tables and lists for onboarding and implementation
1. RSA Root CA Certificate Profile
Core Fields
| Field | Value / Constraints |
|---|---|
| Version | v3 |
| Serial Number | Unique positive integer, ≤20 octets |
| Issuer DN | C=US, O=WInnForum, OU=RSA Root CA<ID#> |
| Subject DN | Same as Issuer |
| Validity | 50 years |
| Signature Algorithm | SHA‑384 or SHA‑512 with RSA |
| Public Key | RSA 4096‑bit, params NULL |
Extensions
| Extension | Required | Critical | Notes |
|---|---|---|---|
| keyUsage | Mandatory | TRUE | keyCertSign, cRLSign; digitalSignature optional |
| basicConstraints | Mandatory | TRUE | cA=TRUE; no pathLenConstraint |
| subjectKeyIdentifier | Mandatory | FALSE | Calculated (Method 1) |
| subjectAltName | Optional | FALSE | Contains <ID#> |
2. RSA Sub‑CA Certificate Profile
Core Fields
| Field | Value / Constraints |
|---|---|
| Version | v3 |
| Serial Number | Unique, ≤20 octets |
| Issuer DN | RSA Root CA |
| Subject DN | Country, Org, OU = RSA <Sub‑CA Type> <ID#> |
| Validity | 30 years |
| Signature Algorithm | SHA‑384 or SHA‑512 with RSA |
| Public Key | RSA 4096‑bit |
Extensions
| Extension | Required | Critical | Notes |
|---|---|---|---|
| keyUsage | Mandatory | TRUE | keyCertSign, cRLSign; digitalSignature optional |
| basicConstraints | Mandatory | TRUE | cA=TRUE; pathLenConstraint depends on Sub‑CA type |
| subjectKeyIdentifier | Mandatory | FALSE | Calculated |
| authorityKeyIdentifier | Mandatory | FALSE | Calculated |
| subjectAltName | Optional | FALSE | <ID#> |
| certificatePolicies | Mandatory | FALSE | Includes WInnForum OIDs |
| cRLDistributionPoints | Mandatory | FALSE | URI of CRLs |
| authorityInfoAccess | Optional | FALSE | OCSP + issuer cert locations |
Sub‑CA Types
3. RSA Subscriber Certificate Profile
Core Fields
| Field | Value / Constraints |
|---|---|
| Version | v3 |
| Serial Number | Unique, ≤20 octets |
| Issuer DN | RSA Sub‑CA |
| Subject DN | Country, Org, OU = WInnForum <Device Type> |
| CN | Device Identifier |
| Validity | 5–10 years depending on device type |
| Signature Algorithm | SHA‑256/384/512 with RSA |
| Public Key | RSA 2048‑bit |
Extensions
| Extension | Required | Critical | Notes |
|---|---|---|---|
| keyUsage | Mandatory | TRUE | digitalSignature, keyEncipherment |
| subjectKeyIdentifier | Mandatory | FALSE | Calculated |
| authorityKeyIdentifier | Mandatory | FALSE | Calculated |
| subjectAltName | Optional | FALSE | Device identifiers, SAS FQDN, etc. |
| certificatePolicies | Mandatory | FALSE | WInnForum OIDs |
| cRLDistributionPoints | Mandatory | FALSE | URI of CRLs |
| authorityInfoAccess | Optional | FALSE | OCSP + issuer cert |
Device Types
Device Identifier Formats
<FCC ID>:<Serial><FRN>:<Unique ID>4. ECC Root CA Certificate Profile
Core Fields
| Field | Value / Constraints |
|---|---|
| Version | v3 |
| Serial Number | Unique, ≤20 octets |
| Issuer DN | ECC Root CA |
| Subject DN | Same as Issuer |
| Validity | 50 years |
| Signature Algorithm | ECDSA with SHA‑384 or SHA‑512 |
| Public Key | EC P‑384 or P‑521 |
Extensions
Same structure as RSA Root CA, but with EC keys.
5. ECC Sub‑CA Certificate Profile
Core Fields
| Field | Value / Constraints |
|---|---|
| Version | v3 |
| Serial Number | Unique, ≤20 octets |
| Issuer DN | ECC Root CA |
| Subject DN | Country, Org, OU = ECC <Sub‑CA Type> <ID#> |
| Validity | 30 years |
| Signature Algorithm | ECDSA SHA‑384/512 |
| Public Key | EC P‑384 or P‑521 |
Extensions
Same as RSA Sub‑CA, including:
6. ECC Subscriber Certificate Profile
Core Fields
| Field | Value / Constraints |
|---|---|
| Version | v3 |
| Serial Number | Unique, ≤20 octets |
| Issuer DN | ECC Sub‑CA |
| Subject DN | Country, Org, OU = WInnForum <Device Type> |
| CN | Device Identifier |
| Validity | 5–10 years |
| Signature Algorithm | ECDSA SHA‑256/384/512 |
| Public Key | EC P‑256/384/521 |
Extensions
Same as RSA Subscriber, but with EC keyUsage:
z*7. Common Notes Across All Profiles**
ID Numbers
<ID#> is assigned when the CA certificate is issuedCA0001, Root CA0001SAN OIDs
1.3.6.1.4.1.46609.1.41.3.6.1.4.1.46609.1.51.3.6.1.4.1.46609.1.61.3.6.1.4.1.46609.1.7Legacy Certificates
May omit:
May include older policy OIDs.
CRLs SHALL conform to [RFC 5280] and contain the basic fields and contents specified in the table below:
Table 10: CRL Profile Basic Fields
| Field | Referenced Standard | Section | Requirement or Recommendation |
|---|---|---|---|
| version | [RFC 5280] | 5.1.2.1 | See Section 7.2.1. |
| signature | [RFC 5280] | Algorithm used to sign the CRL. | |
| issuer | [RFC 5280] | 5.1.2.3 | Entity that has signed and issued the CRL. |
| thisUpdate | [RFC 5280] | 5.1.2.4 | Indicates the issue date of the CRL. CRLs are effective upon issuance. |
| nextUpdate | [RFC 5280] | 5.1.2.5 | Indicates the date by which the next CRL will be issued. |
| revokedCertificates | [RFC 5280] | 5.1.2.6 | Listing of revoked certificates, including the Serial Number of the revoked Certificate and the Revocation Date. |
| authoritKeyIdentifier | [RFC 5280] | 5.2.1 | Follows the guidance in RFC 5280. Criticality is FALSE. |
| cRLNumber | [RFC 5280] | 5.2.3 | A monotonically increasing sequence number for a given CRL scope and issuer. Criticality is FALSE. |
| signatureAlgorithm | [RFC 5280] | 5.1.1.2 | Follows the guidance in RFC 5280. |
| signature Value | [RFC 5280] | 5.1.1.3 | Follows the guidance in RFC 5280. |
The CAs SHALL support the issuance of X.509 Version two (2) CRLs. The CRL version number SHALL be set to the integer value of "1" for Version 2 [RFC 5280, section 5.1.2.1].
Critical CRL extensions SHALL NOT be used.
OCSP (Online Certificate Status Protocol) is optional but is a way to obtain timely information about the revocation status of a particular certificate. OCSP Responses SHALL conform to [RFC5019 or RFC 6960], SHALL either be:
and contain the basic fields and contents specified in the table below:
EDITOR NOTE: The WINNF document is very dense and complex at this point. Here we simplify for web display. The original remains authoritative.
1. OCSP Overview (Simplified)
Purpose
OCSP provides near‑real‑time revocation status for certificates.
Requirements
2. RSA OCSP Certificate Profile (Simplified Table)
| Field | Value / Constraints |
|---|---|
| Version | v3 |
| Serial Number | Unique positive integer, ≤20 octets |
| Issuer DN | Country, Org, OU = RSA Sub‑CA Type, ID#, CN = WInnForum RSA Sub‑CA |
| Subject DN | Country, Org, OU = WInnForum Device Type, CN = Device Identifier |
| Validity | 2 years |
| Signature Algorithm | SHA‑256/384/512 with RSA |
| Public Key | RSA 2048‑bit |
| keyUsage | digitalSignature, nonRepudiation, keyEncipherment (optional) |
| extendedKeyUsage | OCSPSigning (required), serverAuth (optional) |
| subjectKeyIdentifier | Present |
| authorityKeyIdentifier | Present; must reference issuing key |
| certificatePolicies | WInnForum policy OID |
| ocspNoCheck | Optional; value NULL |
| subjectAltName | dNSName = Device Identifier |
| Device Type | OCSP Responder |
| Device Identifier | FQDN of OCSP server |
3. ECC OCSP Certificate Profile (Simplified Table)
| Field | Value / Constraints |
|---|---|
| Version | v3 |
| Serial Number | Unique positive integer, ≤20 octets |
| Issuer DN | Country, Org, OU = ECC Sub‑CA Type, ID#, CN = WInnForum ECC Sub‑CA |
| Subject DN | Country, Org, OU = WInnForum Device Type, CN = Device Identifier |
| Validity | 2 years |
| Signature Algorithm | ECDSA SHA‑256/384/512 |
| Public Key | EC P‑256, P‑384, or P‑521 |
| keyUsage | digitalSignature, nonRepudiation, keyAgreement (optional) |
| extendedKeyUsage | OCSPSigning (required), serverAuth (optional) |
| subjectKeyIdentifier | Present |
| authorityKeyIdentifier | Present; must reference issuing key |
| certificatePolicies | WInnForum policy OID |
| ocspNoCheck | Optional; value NULL |
| subjectAltName | dNSName = Device Identifier |
| Device Type | OCSP Responder |
| Device Identifier | FQDN of OCSP server |
4. OCSP Response Version Requirements
5. Summary Lists
Required Extensions for OCSP Responder Certificates
Key Differences: RSA vs ECC OCSP Profiles
OCSP responses SHALL support use of OCSP version 1 as defined by [RFC2560] and may support [RFC5019] and [RFC 6960], and such future versions as may be adopted.
Critical OCSP extensions SHALL NOT be used.
CAs operating under this policy SHALL be subject to a periodic compliance audit at least once per year. Compliance Audits are conducted at the sole expense of the audited entity. The WInnForum MAY require a periodic compliance audit report of CAs operating under this policy as stated in CP § 8.4.
The CA MAY select an auditor, subject to the qualifications described herein. The auditor SHALL demonstrate competence in the field of compliance audits, and SHALL be thoroughly familiar with the CA's CPS and this CP. The auditor SHALL be a certified information system auditor (CISA), or IT security specialist, and a PKI subject matter specialist who can offer input regarding acceptable risks, mitigation strategies, and industry best practices.
Audits performed by an independent third party audit firm SHALL be performed by a certified public accounting firm with demonstrated expertise in computer security or by accredited computer security professionals employed by a competent security consultancy. Such firm SHALL also have demonstrated expertise in the performance of IT security and PKI compliance audits.
The qualified audit firm SHALL be bound by law, government regulation, or professional code of ethics and SHALL maintain Professional Liability/Errors & Omissions insurance with policy limits of at least one million US dollars in coverage.
The compliance auditor either SHALL be a private firm that is independent from the CA being audited, or it SHALL be sufficiently organizationally separated from those entities to provide an unbiased, independent evaluation. Compliance auditors SHALL not have a conflict of interest that hinders their ability to perform auditing services. To insure independence and objectivity, the compliance auditor may not have served the entity in developing or maintaining the entity's CA Facility or CPS. The WInnForum SHALL determine whether a compliance auditor meets this requirement.
CA's SHALL perform an annual compliance audit for "WebTrust Principles and Criteria for Certification Authorities applicable for the audit period no less than version 2.0" which includes: A Report of Policies and Procedures in Operation and Test of Operational Effectiveness. The purpose of the annual compliance audit shall be to verify that a CA has complied with all the mandatory requirements of the current versions of this CP and the CA's CPS across the period.
All aspects of the CA operation SHALL be subject to the compliance audit and SHOULD address the items listed below. A WebTrust for Certification Authorities or equivalent will satisfy this requirement.
In addition to compliance audits, if the WInnForum has a reasonable belief that a CA is not operating in conformance with this CP, the WInnForum SHALL be entitled, to perform other reviews and investigations, which include, but are not limited to:
The WInnForum SHALL be entitled to delegate the performance of these audits, reviews, and investigations to (a) the Superior Entity of the entity being audited, reviewed, or investigated or (b) a third-party audit firm. Entities that are subject to an audit, review, or investigation SHALL provide cooperation with WInnForum and the personnel performing the audit, review, or investigation.
When the compliance auditor finds a discrepancy between the requirements of this CP or the stipulations in the CPS and the design, operation, or maintenance of the PKI Authorities, the following actions SHALL be performed:
The compliance auditor SHALL note the discrepancy;
The compliance auditor SHALL notify the parties identified in CP § 8.6 of the discrepancy; and
The party responsible for correcting the discrepancy will propose a remedy, including expected time for completion, to the parties identified in CP § 8.6.
In the event the audited entity fails to develop a corrective action plan to be implemented in a timely manner, or if the report reveals exceptions or deficiencies that the WInnForum reasonably believes poses an immediate threat to the security or integrity of the CBRS PKI, then the WInnForum:
Following any Compliance Audit, the audited entity SHALL provide the WInnForum with the Audit Compliance Report and identification of corrective measures within 30 days of completion. A special compliance audit MAY be required to confirm the implementation and effectiveness of the remedy.
Subscribers MAY be charged a fee for the issuance, management, and renewal of certificates.
CAs SHALL not charge a fee as a condition of making a Certificate available in a repository or otherwise making Certificates available to Relying Parties.
CAs SHALL not charge a fee as a condition of making CRLs available in a repository or otherwise available to Relying Parties.
No stipulation.
Refund policies SHOULD be stipulated in the appropriate agreement (e.g., Subscriber Agreement).
CBRS PKI Participants SHOULD maintain a commercially reasonable level of insurance coverage for errors and omissions, either through an errors and omissions insurance program with an insurance carrier or a self-insured retention.
CAs SHALL have sufficient financial resources to maintain their operations and perform their duties, and they SHALL be reasonably able to bear the risk of liability to Subscribers and Relying Parties.
No stipulation.
The following Subscriber information SHALL be kept confidential and private:
CBRS PKI Participants acknowledge that Certificates, Certificate revocation and other status information, CBRS repositories, and information contained within them are not considered Confidential/Private Information. Information not expressly deemed Confidential/Private Information under CP § 9.3.1 SHALL be considered neither confidential nor private.
CBRS PKI Participants receiving private information SHALL secure it from compromise and disclosure to third parties.
CAs SHALL have a Privacy Plan to protect personally identifying information from unauthorized disclosure.
CAs acquiring services under this policy SHALL protect all Subscriber personally identifying information from unauthorized disclosure. Records of individual transactions MAY be released upon request of any subscribers involved in the transaction or their legally recognized agents. The contents of the archives maintained by CAs operating under this policy SHALL not be released except as required by law.
Information included in certificates is deemed pubic information and is not subject to protections outlined in section 9.4.2.
Sensitive information SHALL be stored securely, and MAY be released only in accordance with other stipulations in section 9.4.
CAs are not required to provide any notice or obtain the consent of the Subscriber in order to release private information in accordance with other stipulations in section 9.4.
The WInnForum or CBRS CAs SHALL not disclose private information to any third party unless authorized by this policy, required by law, government rule or regulation, or order of a court of competent jurisdiction.
No stipulations.
The WInnForum retains all Intellectual Property Rights in and to this CP.
CAs retain all Intellectual Property Rights in and to the Certificates and revocation information that they issue.
A Certificate Applicant retains all rights it has (if any) in any trademark, service mark, or trade name contained in any Certificate Application and distinguished name within any Certificate issued to such Certificate Applicant.
Private keys corresponding to Certificates of CAs and Subscribers are the property of the CAs and Subscribers that are the respective Subjects of these Certificates. Secret Shares of a CA's private key are the property of the CA, and the CA retains all Intellectual Property Right in and to such Secret Shares.
Without limiting the generality of the foregoing, WInnForum's root public keys and Certificates containing them, including all CA and Subscriber public keys and certificates containing them, are the property of the WInnForum. The WInnForum licenses software and hardware manufacturers to reproduce such public key Certificates to place copies in WInnForum compliant hardware devices or software.
Subscriber Agreements MAY include additional representations and warranties.
RAs that perform registration functions under this CP SHALL warrant that:
Subscriber Agreements MAY include additional representations and warranties.
Subscribers SHALL sign an agreement containing the requirements the Subscriber shall meet including protection of their private keys and use of the certificates before being issued the certificates. In addition, Subscribers SHALL warrant that:
Subscriber Agreements MAY include additional representations and warranties.
In the case of the automated process for issuance of device certificates the above duties are carried out by the person responsible of the device. For smooth manufacturing process, the tasks above are not mandatory upon acceptance of every certificate.
This CP does not specify the steps a Relying Party SHOULD take to determine whether to rely upon a certificate. The Relying Party decides, pursuant to its own policies, what steps to take. The CA merely provides the tools (i.e., certificates and CRLs) needed to perform the trust path creation, validation, and CP mappings that the Relying Party may wish to employ in its determination. Relying Parties acknowledge that they have sufficient information to make an informed decision as to the extent to which they choose to rely on the information in a Certificate, that they are solely responsible for deciding whether or not to rely on such information, and that they SHALL bear the legal consequences of their failure to perform the Relying Party obligations in terms of this CP.
No stipulations.
To the extent permitted by applicable law, Subscriber Agreements SHALL disclaim the WInnForum's and the applicable Affiliate's possible warranties, including any warranty of merchantability or fitness for a particular purpose.
The liability (and/or limitation thereof) of Subscribers SHALL be as set forth in the applicable Subscriber Agreements.
To the extent permitted by applicable law, Subscribers are required to indemnify CAs for:
The CP becomes effective when approved by the WInnForum. Amendments to this CP become effective upon publication. This CP has no specified term.
This CP as amended from time to time SHALL remain in force until it is replaced by a new version. Termination of this CP is at the discretion of the WInnForum.
Upon termination of this CP, CBRS PKI Participants are nevertheless bound by its terms for all certificates issued for the remainder of the validity periods of such certificates.
Unless otherwise specified by agreement between the parties, WInnForum participants SHALL use commercially reasonable methods to communicate with each other, taking into account the criticality and subject matter of the communication.
The WInnForum SHALL review this CP at least once every year. Corrections, updates, or changes to this CP SHALL be made available as per CP § 9.12.2. Suggested changes to this CP SHALL be communicated to the contact in CP §1.5.2; such communication SHALL include a description of the change, a change justification, and contact information for the person requesting the change.
The WInnForum reserves the right to amend the CP without notification for amendments that are not material, including without limitation corrections of typographical errors, changes to URLs, and changes to contact information. The WInnForum's decision to designate amendments as material or non-material SHALL be within the WInnForum's sole discretion.
Change notices to this CP SHALL be distributed electronically to CBRS PKI Participants and observers in accordance with the WInnForum document change procedures.
Object Identifiers (OIDs) will be changed if the WInnForum determines that a change in the CP reduces the level of assurance provided. If the WInnForum determines that a change is necessary in the OID corresponding to a Certificate policy, the amendment SHALL contain new object identifiers for the Certificate policies corresponding to each Class of Certificate. Otherwise, amendments shall not require a change in Certificate policy object identifier.
The WInnForum SHALL facilitate the resolution between entities when conflicts arise as a result of the use of certificates issued under this policy.
Subject to any limits appearing in applicable law, the laws of the State of Colorado, U.S.A., SHALL govern the enforceability, construction, interpretation, and validity of this CP, irrespective of contract or other choice of law provisions and without the requirement to establish a commercial nexus in Colorado, USA. This choice of law is made to ensure uniform procedures and interpretation for all WInnForum Participants, no matter where they are located.
This governing law provision applies only to this CP. Agreements incorporating the CP by reference MAY have their own governing law provisions, provided that this CP § 9.14 governs the enforceability, construction, interpretation, and validity of the terms of the CP separate and apart from the remaining provisions of any such agreements, subject to any limitations appearing in applicable law.
This CP is subject to applicable national, state, local, and foreign laws, rules, regulations, ordinances, decrees, and orders including, but not limited to, restrictions on exporting or importing software, hardware, or technical information. All CAs operating under this policy are required to comply with applicable law.
9.16.1 Entire Agreement
No Stipulation
9.16.2 Assignment
No stipulation
9.16.3 Severability
Should it be determined that one section of this CP is incorrect or invalid, the other sections of this CP shall remain in effect until the CP is updated. The process for updating this CP is described in CP § 9.12.
In the event that a clause or provision of this CP is held to be unenforceable by a court of law or other tribunal having authority, the remainder of the CP shall remain valid.
9.16.4 Enforcement (Attorneys' fees and waiver of rights)
No Stipulation
To the extent permitted by applicable law, the CBRS PKI agreement (e.g., Digital Certificate Subscriber Agreements) shall include a force majeure clause protecting WInnForum and the applicable Affiliate.
No Stipulation.
| RFC | Key Words for use in RFCs to Indicate Requirement Level, IETF (Bradner), |
|---|---|
| 2119 | March 1997. http://www.ietf.org/rfc/rfc2119.txt |
| RFC | X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP, IETF (Myers, Ankney, Malpani, Galperin, Adams), June 1999. |
| 2560 | http://www.ietf.org/rfc/rfc2560.txt |
| RFC | Internet X.509 PKI Certificate Policy and Certification Practices Framework, IETF (Chokhani, Ford, Sabett, Merrill, and Wu), November 2003. |
| 3647 | http://www.ietf.org/rfc/rfc3647.txt |
| RFC | The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments, IETF (Deacon, Hurst), September 2007. |
| 5019 | http://www.ietf.org/rfc/rfc5019.txt |
| RFC | Internet X.509 PKI Certificate and Certification Revocation List (CRL) Profile, IETF (Cooper, Santesson, Farrell, Boeyen, Housley, and Polk), May 2008. |
| 5280 | http://www.ietf.org/rfc/rfc5280.txt |
| RFC | X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP, IETF (Santesson, Myers, Ankney, Malpani, Galperin, Adams), June 2013. |
| 6960 | https://tools.ietf.org/rfc/rfc6960.txt |
| FIPS | Security Requirements for Cryptographic Modules, FIPS 140-2, May 25, 2001. |
| 140-2 | http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf |
| SSC-0014 | SAS Identifiers SSC-0014 |
This specification uses the following terms:
Audit Requirements Guide A document that sets forth the security and audit requirements and practices for CAs. Certificate A message that, at least, states a name or identifies the CA, identifies the Subscriber, contains the Subscriber's public key, identifies the Certificate's Validity Period, contains a Certificate serial number, and is digitally signed by the CA that issued the certificate. Legacy Certificate A Certificate issued under WInnForum Certificate Policy Specifications version 1.1.2 or earlier. Certificate Applicant An individual or organization that requests the issuance of a Certificate by a CA. Certificate Application A request from a Certificate Applicant (or authorized agent of the Certificate Applicant) to a CA for the issuance of a Certificate. Certificate Chain An ordered list of Certificates containing a Subscriber Certificate and one or more CA Certificates, which terminates in a root Certificate. Control Objectives Criteria that an entity SHALL meet in order to satisfy a Compliance Audit. Certificate Polikcy (CP) The principal statement of policy governing the PKI. Certificate Revocation List (CRL) A periodically (or exigently) issued list, digitally signed by a CA, of identified Certificates that have been revoked prior to their expiration dates. The list generally indicates the CRL issuer's name, the date of issue, the date of the next scheduled CRL issue, the revoked Certificates' serial numbers, and the specific times and reasons for revocation. Certificate Signing Request A message conveying a request to have a Certificate issued. (CSR) Certification Authority (CA) An entity authorized to issue, manage, revoke, and renew Certificates in the PKI. Certification Practice Statement (CPS) A statement of the practices that a CA employs in approving or rejecting Certificate Applications and issuing, managing, and revoking Certificates. Certificate Requesting Account (CRA) The online portal to assist Certificate Applicants in requesting Certificates. Compliance Audit A periodic audit that a CA system undergoes to determine its conformance with PKI requirements that apply to it. Compromise A violation of a security policy, in which an unauthorized disclosure of, or loss of control over, sensitive information has occurred. With respect to private keys, a Compromise is a loss, theft, disclosure, modification, unauthorized use, or other compromise of the security of such private key. CRL Usage Agreement An agreement setting forth the terms and conditions under which a CRL or the information in it can be used. Device Certificate An end-entity non-CA certificate of the PKI chain installed in CBRS devices such as SAS Provider, Domain Proxy, Installer and CBSD devices, Exigent Audit/Investigation An audit or investigation by where there is reason to believe that an entity's failure to meet PKI Standards, an incident or Compromise relating to the entity, or an actual or potential threat to the security of the PKI posed by the entity has occurred. Elliptic Curve Cryptography (ECC) A public-key cryptography system based on the algebraic structure of elliptic curves over finite fields. Intellectual Property Rights Rights under one or more of the following: copyright, patent, trade secret, trademark, or any other intellectual property rights. Key Generation Ceremony A procedure whereby a CA's key pair is generated, its private key is backed up, and/or its public key is certified. PKI Participant An individual or organization that is one or more of the following within the PKI: WInnForum, a CA, a Subscriber, or a Relying Party. PKCS #10 Public-Key Cryptography Standard #10, developed by RSA Security Inc., which defines a structure for a Certificate Signing Request. PKCS #8 Public-Key Cryptography Standard #8, developed by RSA Security Inc., which defines a secure means for the transfer of private keys. Processing Center A secure facility created by an appropriate organization (e.g., Symantec) that houses, among other things, the cryptographic modules used for the issuance of Certificates. Public Key Infrastructure (PKI) The architecture, organization, techniques, practices, and procedures that collectively support the implementation and operation of a Certificate-based public key cryptographic system. Relying Party An individual or organization that acts in reliance on a certificate and/or a digital signature. RSA (Algorithm) A public key cryptographic system invented by Rivest, Shamir, and Adelman. Secret Share A portion of the activation data needed to operate the private key, held by individuals called "Shareholders." Some threshold number of Secret Shares (n) out of the total number of Secret Shares (m) shall be required to operate the private key. Secret Sharing The practice of splitting a CA private key or the activation data to operate a CA private key in order to enforce multi- person control over CA private key operations. Security Repository Security Policy Sub domain Security Repository Database of relevant security information accessible on-line. Security Policy The highest-level document describing security policies. Sub domain The portion of the PKI under control of an entity and all entities subordinate to it within the hierarchy. Sub domain Participants An individual or organization that is one or more of the following within the Subdomain: WInnForum, a Subscriber, or a Relying Party. Subject The holder of a private key corresponding to a public key. The term "Subject" can, in the case of a Device Certificate, refer to the Subscriber requesting the device certificate. Subscriber The entity who requests one or more Certificates (e.g., a manufacturer) to be installed in one or more devices under its control. The Subscriber is capable of using, and is authorized to use, the private key that corresponds to the public key listed in the Certificate (s). Digital Certificate Subscriber Agreement An agreement used by a CA setting forth the terms and conditions under which an individual or organization acts as a Subscriber. Superior Entity An entity above a certain entity within the PKI. Trusted Person An employee, contractor, or consultant of an entity within the PKI responsible for managing infrastructural trustworthiness of the entity, its products, its services, its facilities, and/or its practices. Trusted Position The positions within the MFGH entity that SHALL be held by a Trusted Person. Trustworthy System Computer hardware, software, and procedures that are reasonably secure from intrusion and misuse; provide a reasonable level of availability, reliability, and correct operation; are reasonably suited to performing their intended functions; and enforce the applicable security policy. Validity Period The period starting with the date and time a Certificate is issued (or on a later date and time certain if stated in the Certificate) and ending with the date and time on which the Certificate expires or is earlier revoked.
This specification uses the following abbreviations:
CA Certification Authority
CP Certificate Policy
CPS Certification Practice Statement CRA Certificate Requesting Account CRL Certificate Revocation List CSR Certificate Signing Request
DR Demand Response
DRAS Demand Response Automation Server
ECC Elliptic Curve Cryptography
FIPS Federal Information Processing Standards id-at X.500 attribute types. (OID value: 2.5.4)
id-ce Object Identifier for Version 3 certificate extensions. (OID value: 2.5.29)
IETF Internet Engineering Task Force ISO Independent System Operators
MFG Manufacturer OID Object Identifier
WInnFor Wireless Innovation Forum
um
PA Policy Authority
PKCS Public-Key Cryptography Standard
PKI Public Key Infrastructure
RFC Request for comment
RSA Rivest, Shamir, Adelman
WInnForum wishes to thank everybody who participated directly or indirectly in the creation of this Certificate Policy.
Table 13 shows the Document Changes that have been incorporated into this CP.
Table 13: Document Changes
| Version | Author | Approval Date | Summary |
|---|---|---|---|
| 1.1.1 | Mohammad Khaled | 01/15/2018 | Fixing typo errors in the OID values of parameters Secp384r1 and Secp521r1 in Table 7, 8 and 9 in Section 7.1. |
| 1.1.2 | Lee Pucker | 6 Feb 2018 | Corrected document number issues. |
| 1.2.0 | Lee Pucker | 4 Feb 2019 | Various technical updates |
| 1.3.0 | Lee Pucker | 16 May 2019 | Various technical updates |
| 1.3.1 | Lee Pucker | 20 May 2019 | Editorial Corrections (broken links, etc.) |
| 1.4.0 | Virgil Cimpu | 25 June 2020 | Technical revision to remove the unused PAL certificates and align DP certificate use with other Release 1 standards |
| 1.5.0 | 17 Nov 2020 | Technical revision to allow DP certificate issuance to SAS administrators |
Pages