GridPass PKI Certificate Practice Statement
PrecisionX Ventures Internal Public Key Infrastructure | RFC 3647 Draft
Document ID: GP-CPS-001
Version: 0.2 Draft
Date: June 27, 2026
Owner: GridPass Policy Authority, PrecisionX Ventures
Status: Draft for internal review; not effective until approved
Primary Repository: https://gridpass.pki.pxvi.net
Public CPS URL: https://gridpass.pki.pxvi.net/cps
Certificate Repository: https://gridpass.pki.pxvi.net/repository
Draft status This CPS is written as a production-ready baseline for the GridPass PKI, but it must be reviewed by counsel, the GridPass Policy Authority, CA operations, information security, and affected relying-party owners before it is declared effective. |
|---|
0. Document Control
Field | Value |
|---|---|
Document name | GridPass PKI Certificate Practice Statement |
Applies to | GridPass PKI for PrecisionX Ventures and approved affiliated entities |
Framework | RFC 3647 Certificate Policy and Certification Practices Framework |
Classification | Internal / Confidential unless a CPS Summary is approved for external publication |
Review cadence | At least annually and after material changes to CA hierarchy, cryptographic standards, relying-party scope, law, or risk |
Approval authority | GridPass Policy Authority |
Enterprise OID root | 1.3.6.1.4.1.61660 (IANA Private Enterprise Number 61660) |
GridPass PKI arc | 1.3.6.1.4.1.61660.1 |
0.1. Manual Contents
1 Introduction
2 Publication and Repository Responsibilities
3 Identification and Authentication
4 Certificate Life-Cycle Operational Requirements
5 Facility, Management, and Operational Controls
6 Technical Security Controls
7 Certificate, CRL, and OCSP Profiles
8 Compliance Audit and Other Assessments
9 Other Business and Legal Matters
Appendix A Certificate Profile Matrix
Appendix B Enrollment Workstation and Credential Issuance Ceremony
Appendix C Relying-Party Integration Practices
Appendix D Open Implementation Decisions
0.2. Executive Operating Model
GridPass is the internal PKI and credential trust service for PrecisionX Ventures. It is intended to support Windows smart card logon, physical access integrations, remote access, Keycloak and application authentication, S/MIME, file encryption, device authentication, Wi-Fi and network access control, server TLS, mutual TLS, code signing, and privileged operator workflows.
The PKI is operated as an enterprise trust system, not as a public WebTrust CA. Publicly trusted browser TLS certificates are out of scope unless a separate public trust program is created. Certificates issued under this CPS are intended for internal, customer-controlled, project-controlled, or contractually approved relying parties that have accepted GridPass trust terms.
GridPass distinguishes between standard contactless credentials that do not contain private keys and high-security smart card credentials that contain non-exportable private keys. Only the latter are certificates under this CPS. Standard credentials may be linked to identity records and access-control workflows, but they must not be treated as proof-of-possession PKI credentials.
1. Introduction
1.1. Overview
This Certificate Practice Statement describes the practices used by the GridPass PKI in issuing, managing, renewing, re-keying, revoking, and publishing status information for certificates. It is organized using the RFC 3647 framework and is intended to be read together with the GridPass Certificate Policy, subscriber agreements, relying-party agreements, credential standards, certificate profiles, and security operations procedures.
The GridPass PKI provides a common trust anchor across physical security, workstation authentication, logical access, remote access, cryptographic protection of files and email, device identity, service identity, and administrative approval workflows. The design objective is that a single governed identity proofing and credential lifecycle can be reused by many systems rather than leaving each system to make independent authentication decisions.
The expected CA hierarchy consists of an offline root CA, one or more online issuing CAs separated by function and risk, and dedicated status services for CRL and OCSP publication. CA private keys are protected by hardware security modules or equivalent approved cryptographic modules according to the assurance level of the CA.
Component | Practice statement |
|---|---|
Offline Root CA | Maintained offline, used only to issue or revoke subordinate CA certificates and publish root CRLs. |
Enterprise Identity Issuing CA | Issues user authentication, smart card logon, S/MIME, VPN, and enrollment agent certificates. |
Infrastructure Issuing CA | Issues device, server TLS, Wi-Fi, network equipment, service, and mTLS certificates. |
Code Signing Issuing CA | Issues approved code signing certificates under elevated approval and private key protection requirements. |
Repository and status services | Publish CA certificates, CRLs, CPS materials, certificate status, and related relying-party information at GridPass repository URLs. |
1.2. Document Name and Identification
This document is the GridPass PKI Certificate Practice Statement, document identifier GP-CPS-001. The authoritative repository location for the current effective version, public summary version, certificate repository information, CRL distribution points, and OCSP responder information is https://gridpass.pki.pxvi.net.
GridPass certificate policies use PrecisionX IANA Private Enterprise Number 61660, enterprise OID root 1.3.6.1.4.1.61660. GridPass PKI is allocated 1.3.6.1.4.1.61660.1; certificate policies are allocated under 1.3.6.1.4.1.61660.1.1. The enterprise root itself must not be encoded as a certificate policy OID.
Policy | Assurance intent | Certificate policy OID |
|---|---|---|
GP-1 Standard | Routine enterprise certificates where software or platform-protected private keys are acceptable. | 1.3.6.1.4.1.61660.1.1.1 |
GP-2 Managed | Managed workstations, devices, VPN, and service identity where TPM or managed key storage is expected. | 1.3.6.1.4.1.61660.1.1.2 |
GP-3 High Security | Smart card or hardware-token credentials for strong user authentication, physical access integration, and remote administration. | 1.3.6.1.4.1.61660.1.1.3 |
GP-4 Critical Infrastructure | CA administrators, domain administrators, HSM operators, break-glass identities, and other roles requiring FIPS-validated hardware protection and enhanced ceremonies. | 1.3.6.1.4.1.61660.1.1.4 |
1.3. PKI Participants
PKI participants include the GridPass Policy Authority, Certification Authorities, Registration Authorities, Enrollment Agents, Subscribers, Subjects, Relying Parties, repository operators, security operations personnel, auditors, and approved external service providers. Participation is limited to entities approved by PrecisionX Ventures or by written agreement with an approved affiliated entity or customer program.
Participant | Responsibilities |
|---|---|
GridPass Policy Authority | Approves CP, CPS, certificate profiles, assurance levels, exceptions, audits, and major CA lifecycle events. |
Certification Authority | Signs certificates, publishes certificate status, protects CA private keys, and operates in accordance with this CPS. |
Registration Authority | Performs or approves identity validation, enrollment authorization, revocation requests, and subscriber lifecycle changes. |
Enrollment Agent | Uses an approved enrollment agent certificate and workstation to submit approved certificate requests on behalf of subscribers. |
Subscriber | Accepts certificates, protects private keys and activation data, reports compromise, and uses certificates only for approved purposes. |
Relying Party | Validates certification paths, certificate policy, key usage, EKU, certificate status, and relying-party terms before relying on a certificate. |
Repository Operator | Publishes CA certificates, CRLs, OCSP responses, CPS materials, and other repository information. |
Auditor | Assesses compliance with this CPS, approved policies, ceremonies, and operational controls. |
1.4. Certificate Usage
Certificates may be used only for the key usages, extended key usages, relying-party systems, assurance levels, and validity periods approved in the applicable certificate profile. A relying party must not infer a broader authorization merely because a certificate chains to GridPass. Authorization remains the responsibility of the relying application, access-control system, or workflow owner.
Use class | Approved examples | Prohibited or restricted uses |
|---|---|---|
User authentication | Windows smart card logon, Keycloak certificate authentication, VPN, administrative portals, GuardStation operator login. | Password sharing, unattended session unlock, generic account use, or authentication after subscriber separation. |
Physical access integration | Smart card proof-of-possession challenge, high-security area check-in, credential elevation workflow, ACS authorization token issuance. | Treating a printed badge, UID-only NFC card, or copied identifier as equivalent to a private-key credential. |
Encryption | S/MIME encryption, file encryption, approved data recovery workflows. | Escrow of authentication or signing private keys; use after revocation or expiration. |
Digital signatures | Document signing, operator approvals, code signing, change authorization. | Repudiation-prone shared signing credentials or automated signing outside approved controls. |
Infrastructure identity | Internal TLS, mTLS APIs, Wi-Fi, device authentication, switch/router management. | Public browser trust unless separately approved under a public trust program. |
1.4.1. Assurance Classes
Class | Private key storage | Identity proofing | Typical uses |
|---|---|---|---|
GP-1 Standard | Software key permitted; managed endpoint required where feasible. | Directory, HR, asset, or service-owner approval. | Wi-Fi, standard users, internal server TLS, routine device certificates. |
GP-2 Managed | TPM, secure enclave, or centrally managed non-exportable storage preferred. | Manager or system-owner approval plus authoritative record check. | Managed workstations, VPN, device authentication, API clients. |
GP-3 High Security | Hardware smart card or equivalent non-exportable hardware token required. | In-person or supervised remote proofing, authoritative record match, issuance ceremony, PIN initialization. | Smart card logon, high-security physical access, remote administration, Keycloak MFA. |
GP-4 Critical Infrastructure | FIPS-validated hardware token/HSM; dual-control enrollment or issuance. | Enhanced proofing, trusted-role approval, background and role validation as applicable. | CA administrators, HSM officers, domain admins, break-glass credentials, disaster recovery. |
1.5. Policy Administration
The GridPass Policy Authority owns this CPS and is responsible for interpreting it, approving amendments, resolving conflicts between this CPS and subordinate procedures, and approving exceptions. The CA Operations Lead owns technical implementation. The Security Officer owns operational security controls. Legal counsel reviews contractual and liability provisions before the CPS is made effective.
Administrative item | Practice |
|---|---|
Contact | GridPass Policy Authority via the internal governance channel and repository contact instructions at https://gridpass.pki.pxvi.net/contact. |
Suitability determination | A certificate profile or relying-party use is suitable only if approved by the Policy Authority and documented in a profile, agreement, or integration record. |
Approval procedure | Material changes require documented review by Policy Authority, CA Operations, Information Security, and Legal where legal terms are affected. |
Emergency changes | Emergency revocation, algorithm retirement, or repository changes may be approved by the Security Officer and CA Operations Lead, then ratified by the Policy Authority. |
1.6. Definitions and Acronyms
Term | Meaning |
|---|---|
ACS | Access control system used for physical access decisions and event logging. |
CA | Certification Authority. |
CP | Certificate Policy. |
CPS | Certificate Practice Statement. |
CRL | Certificate Revocation List. |
EKU | Extended Key Usage extension. |
Enrollment Workstation | Dedicated, managed workstation used for approved identity proofing, card initialization, certificate enrollment, and credential issuance. |
GP-1 through GP-4 | GridPass certificate assurance classes from Standard through Critical Infrastructure. |
HSM | Hardware Security Module. |
OCSP | Online Certificate Status Protocol. |
RA | Registration Authority. |
Relying Party | Entity or system that relies on a GridPass certificate after validating chain, status, policy, and authorized use. |
Subscriber | Entity to whom a certificate is issued and who controls the corresponding private key, except where the subject is a device controlled by an organization. |
OID / PEN | Object Identifier / Private Enterprise Number. PrecisionX PEN 61660 corresponds to enterprise OID root 1.3.6.1.4.1.61660; GridPass PKI uses 1.3.6.1.4.1.61660.1. |
2. Publication and Repository Responsibilities
2.1. Repositories
GridPass shall maintain one or more repositories reachable from https://gridpass.pki.pxvi.net. Repository services may include public web publication, internal authenticated repository paths, OCSP responders, CRL distribution points, directory publication, and backup repository endpoints. Repository availability objectives must be aligned to relying-party criticality and documented in the operations runbook.
Repository object | Canonical location |
|---|---|
CPS and CPS Summary | https://gridpass.pki.pxvi.net/cps |
Certificate Policy | https://gridpass.pki.pxvi.net/cp |
CA certificates | https://gridpass.pki.pxvi.net/repository/certs |
CRLs | https://gridpass.pki.pxvi.net/repository/crl |
OCSP | https://gridpass.pki.pxvi.net/ocsp |
Relying-party notices | https://gridpass.pki.pxvi.net/notices |
2.2. Publication of Certification Information
The repository shall publish current CA certificates, subordinate CA certificates, applicable CRLs, OCSP responder certificates where used, CPS or CPS Summary documents approved for publication, policy documents approved for publication, and notices materially affecting reliance. Subscriber certificates may be published to directories or repositories only where required by the relying-party use case and privacy rules.
The full internal CPS may be restricted. A CPS Summary or PKI Disclosure Statement may be published externally to communicate trust terms without exposing sensitive operational details.
2.3. Time or Frequency of Publication
CA certificates and CPS materials shall be published promptly after approval or issuance. CRLs shall be published according to the CRL profile and no later than their nextUpdate values. Emergency CRLs shall be published as soon as practicable after a CA or high-impact subscriber revocation decision. OCSP responses shall be refreshed within the validity interval defined in the OCSP profile.
Object | Publication expectation |
|---|---|
Root CA certificate | Before or contemporaneous with subordinate CA publication. |
Subordinate CA certificate | Before certificates chaining to that CA are accepted by relying parties. |
Root CRL | At least every 6 months and after any subordinate CA revocation. |
Issuing CA CRL | At least daily for identity and infrastructure CAs unless the profile defines a shorter interval. |
OCSP response | Continuously available for profiles requiring online status; refreshed before expiration. |
CPS amendments | Published or made available after approval and before effective date unless emergency action is required. |
2.4. Access Controls on Repositories
Read access to public trust information may be unauthenticated. Write, delete, and administrative access to repository systems shall be restricted to authorized repository operators using strong authentication, administrative logging, change control, and separation of duties. Repository content shall be integrity protected by system controls, change management, and monitoring.
Repository outages affecting certificate status checking for critical relying parties shall be treated as security-impacting incidents. Relying-party systems must define fail-open or fail-closed behavior based on risk and continuity requirements; high-security physical and logical access should fail closed unless an approved break-glass workflow is invoked.
3. Identification and Authentication
3.1. Naming
Certificate subjects shall use names that are meaningful to the relying-party context and traceable to authoritative records. Names may include directory distinguished names, user principal names, email addresses, DNS names, URI identifiers, device serials, asset identifiers, role identifiers, or service names as permitted by the certificate profile. Anonymous or pseudonymous certificates are not permitted unless specifically approved by the Policy Authority.
Subject type | Approved naming sources |
|---|---|
Employee or contractor | Authoritative identity record, HR/personnel record, directory account, approved legal or preferred name policy. |
Privileged operator | Authoritative identity record plus role assignment and privileged access approval. |
Visitor or temporary worker | GuardStation or visitor-management record, sponsor approval, expiration date, credential type, and access-zone approval. |
Device or workstation | Asset inventory, endpoint management system, serial number, hostname, owner, and network assignment. |
Server or service | Service catalog, DNS ownership, environment owner approval, and configuration management record. |
Physical access credential | Credential management record, card serial/token serial, certificate serial, assigned person, expiration, and access-zone mapping. |
3.1.1. Types of Names
X.500 distinguished names may be used for CA and subscriber certificate subjects. Subject Alternative Name values shall be used when required by relying-party software, including UPN for Windows smart card logon, rfc822Name for S/MIME, dNSName for TLS server certificates, uniformResourceIdentifier for service identity where approved, and otherName values only where documented in the applicable certificate profile.
3.1.2. Need for Names to Be Meaningful
Names shall be sufficiently meaningful to permit relying parties, auditors, and incident responders to identify the subscriber, subject, device, service, or role. Role certificates may identify the role, but the issuance record must identify the accountable individual or system owner.
3.1.3. Anonymity or Pseudonymity of Subscribers
GridPass does not issue anonymous end-entity certificates under this CPS. Pseudonymous or role certificates require Policy Authority approval, documented business justification, accountable owner mapping, and relying-party restrictions.
3.1.4. Rules for Interpreting Various Name Forms
Name interpretation rules shall be documented in certificate profiles and relying-party integration records. UPN values shall map to approved directory accounts. Email addresses shall map to approved mail identities. DNS names shall map to domains controlled by PrecisionX Ventures or an approved relying-party/customer environment. Device names shall map to asset inventory records.
3.1.5. Uniqueness of Names
Subject names and subject alternative names shall be unique within the applicable namespace for the validity period of the certificate. Reuse of names after a person, device, or service is retired must account for audit record retention and collision risk.
3.1.6. Recognition, Authentication, and Role of Trademarks
GridPass shall not knowingly issue certificates containing names that infringe trademarks or misrepresent organizational affiliation. Approval of a certificate name does not confer trademark rights. Disputes shall be referred to the Policy Authority and legal counsel.
3.2. Initial Identity Validation
Identity validation shall be commensurate with assurance class. The RA or Enrollment Agent must verify that the applicant exists in an authoritative record, is eligible for the requested certificate, controls or is assigned the relevant account/device/service, and has completed required approvals. For GP-3 and GP-4 credentials, issuance must include proof-of-possession, secure PIN or activation-data initialization, and binding of the physical token serial to the identity record.
Assurance class | Minimum validation |
|---|---|
GP-1 | Authoritative account, device, service, or asset record; automated or owner-approved request; proof-of-possession of private key. |
GP-2 | GP-1 plus managed endpoint or owner attestation, device posture or TPM evidence where available, and manager/system-owner approval. |
GP-3 | GP-2 plus supervised proofing, hardware token assignment, non-exportable key generation, PIN initialization, and issuance record with token serial. |
GP-4 | GP-3 plus trusted-role approval, dual control where required, enhanced personnel screening where applicable, and ceremony evidence. |
3.2.1. Method to Prove Possession of Private Key
For end-entity certificates, proof-of-possession shall be established through a valid certificate signing request, smart card enrollment transaction, attestation mechanism, challenge signing operation, or other approved cryptographic method. For smart cards and hardware tokens, the private key shall be generated on the token or imported only if an approved secure key injection process exists; authentication and signing private keys are expected to be non-exportable.
3.2.2. Authentication of Organization Identity
Organizational identity shall be verified through approved corporate records, contracts, customer onboarding records, directory tenants, project governance records, or other authoritative sources. External customer or partner namespaces require written authorization and an integration record defining relying-party scope.
3.2.3. Authentication of Individual Identity
Individual identity shall be validated against HR, contractor, visitor, or customer records. GP-3 and GP-4 issuance requires supervised enrollment, government-issued identification or equivalent approved proofing where appropriate, and confirmation that the certificate subject matches the individual authorized for the credential.
3.2.4. Non-Verified Subscriber Information
Unverified subscriber information shall not be included in certificate subject or subject alternative name fields. Operational metadata not verified for reliance may be retained in internal enrollment records but must not be represented to relying parties as validated identity information.
3.2.5. Validation of Authority
Requests for certificates associated with privileged roles, services, devices, DNS names, physical access zones, code signing, and enrollment agents require approval from the accountable business, system, data, or facility owner. The RA must verify that the approver is authorized to grant the requested certificate or access use.
3.2.6. Criteria for Interoperation
GridPass may interoperate with external PKIs only under written agreement, documented path validation rules, approved certificate policies, and technical constraints. Cross-certification, bridge trust, or external trust store distribution requires Policy Authority approval and legal review.
3.3. Identification and Authentication for Re-Key Requests
Re-key requires authentication of the subscriber or accountable owner and confirmation that the certificate remains authorized. For GP-1 and GP-2, authenticated self-service or managed enrollment may be used where risk permits. For GP-3 and GP-4, re-key generally requires the hardware token to be present, the subscriber to authenticate with activation data, and the RA to confirm continuing eligibility. Re-key after suspected compromise requires new identity validation at the assurance level of the certificate.
3.4. Identification and Authentication for Revocation Requests
Revocation requests may be authenticated through subscriber authentication, manager or system-owner approval, RA approval, security incident process, HR/personnel termination records, device management records, or CA Operations action. Emergency revocation may be initiated by the Security Officer or CA Operations Lead and ratified afterward. The requester identity, authority, time, reason, and evidence must be logged.
4. Certificate Life-Cycle Operational Requirements
4.1. Certificate Application
Certificate applications may be submitted through approved enrollment portals, endpoint management systems, directory auto-enrollment, MDM/EDR workflows, RA work queues, or dedicated enrollment workstations. The application must identify the requested certificate profile, subject, subscriber or accountable owner, approval authority, key storage method, and requested validity period.
For smart card issuance, the application must include credential type, token serial, reader or enrollment station identifier, subscriber identity, access-zone requirements, and whether the credential will be used for Windows logon, Keycloak, VPN, physical access, S/MIME, file encryption, digital signature, or administrative workflows.
4.2. Certificate Application Processing
The RA or automated policy engine shall validate the request against the applicable certificate profile, assurance class, subscriber eligibility, approver authority, proof-of-possession, and issuance constraints. Requests failing validation shall be rejected or held for manual review. The CA shall not issue a certificate solely because a technically valid CSR was submitted.
4.3. Certificate Issuance
Certificates shall be issued only by approved CAs using approved profiles. Issuance events must be logged with request identifier, certificate serial number, issuer, subject, profile, requester, approver, enrollment method, and timestamp. For high-security credentials, issuance records must also bind the certificate serial to token serial, cardholder, issuance officer, and credential activation status.
4.4. Certificate Acceptance
A certificate is accepted when the subscriber or responsible owner uses the certificate, installs it, acknowledges issuance, successfully completes enrollment, or fails to object within the notice period defined by the enrollment workflow. Acceptance obligates the subscriber to protect the private key and activation data, use the certificate only for authorized purposes, and report suspected compromise promptly.
4.5. Key Pair and Certificate Usage
Subscribers must use private keys only for the purposes permitted by certificate key usage, EKU, certificate policy, and relying-party agreement. Relying parties must validate the certificate chain, validity period, policy, name constraints where applicable, key usage, EKU, revocation status, and local authorization before granting access or accepting a signature.
Credential/event | Required relying-party behavior |
|---|---|
Windows smart card logon | Validate chain to GridPass trust anchor, UPN mapping, smart card logon EKU, revocation status, and account authorization. |
Physical access challenge | Validate signed nonce or approved proof-of-possession, GridPass status response, credential assurance, cardholder identity, and zone authorization. |
Keycloak or application authentication | Validate client certificate or signed assertion, certificate policy, subject mapping, revocation status, and application authorization. |
VPN access | Validate client auth EKU, policy, device or user authorization, and current status before tunnel authorization. |
S/MIME or file encryption | Use only current encryption certificates for new encryption; retain recovery procedures for historical encrypted data. |
4.6. Certificate Renewal
Renewal without key change is permitted only where the certificate profile allows it and the underlying key remains within its approved cryptoperiod. GP-3 and GP-4 credentials should generally re-key rather than renew at the end of the certificate validity period unless token lifecycle and security review support renewal. Renewal must confirm continuing subscriber eligibility.
4.7. Certificate Re-Key
Re-key is required when the key reaches the end of its cryptoperiod, when the certificate profile requires key rollover, when the certificate is modified in a way requiring a new key, when compromise is suspected, or when a token is replaced. Re-key requires proof-of-possession of the new private key and revocation or retirement of the prior certificate according to profile rules.
4.8. Certificate Modification
Certificate modification includes changes to subject name, SAN, role, email address, access scope, device assignment, service owner, or certificate profile. Modification shall be implemented by issuing a new certificate and revoking or allowing expiration of the prior certificate as appropriate. Name changes and role changes require authoritative source validation.
4.9. Certificate Revocation and Suspension
GridPass supports revocation. Suspension may be supported only if the CA platform and relying-party integrations can enforce it reliably; absent such support, temporary loss of eligibility shall be handled through revocation, access disablement, or relying-party authorization controls. Revocation is mandatory when key compromise is known or suspected, subscriber eligibility ends, certificate information becomes materially inaccurate, or the certificate was issued in violation of this CPS.
Revocation reason | Examples |
|---|---|
Key compromise | Lost smart card with suspected PIN disclosure, malware on key-hosting endpoint, HSM compromise, unauthorized key export. |
Affiliation changed | Employment termination, contractor offboarding, visitor expiration, role removal, project departure. |
Privilege removed | Loss of high-security area access, admin role removal, VPN authorization removed. |
Certificate superseded | Name change, service rename, device reassignment, re-key, template correction. |
CA operation issue | Mis-issuance, profile error, policy violation, audit finding requiring revocation. |
4.9.1. Who Can Request Revocation
Revocation may be requested by the subscriber, manager, sponsor, system owner, data owner, facility security owner, RA, Security Officer, HR/personnel authority, CA Operations, or an incident response authority. Relying-party systems may request revocation through documented incident channels but shall not directly revoke certificates unless delegated authority is approved.
4.9.2. Procedure for Revocation Request
The request must identify the certificate or subscriber, reason, urgency, requester identity, and supporting evidence. Emergency revocation may proceed before complete evidence collection when delay materially increases risk. The RA or CA Operations shall record the decision, update certificate status, publish revocation information, notify affected relying-party owners where appropriate, and retain records.
4.9.3. Revocation Request Grace Period
Subscribers must report suspected compromise, loss of token, PIN disclosure, unauthorized use, or identity data error immediately and no later than the end of the same business day. Security-impacting revocations should be processed without intentional delay. Administrative revocations should be processed according to offboarding and change-management service levels.
4.9.4. Time Within Which CA Must Process Revocation Request
Known or suspected key compromise for GP-3 or GP-4 credentials shall be processed as an emergency. The target is immediate action during staffed operations and no later than four hours from validated notice unless a shorter contractual or regulatory requirement applies. Routine affiliation or certificate supersession revocations should be processed within one business day or as defined by the relying-party integration.
4.9.5. Revocation Checking Requirement for Relying Parties
Relying parties must check revocation status using OCSP, CRL, directory status, or an approved GridPass validation service before relying on a certificate where the use case is authentication, physical access, remote access, privileged operation, code signing, or transaction approval. Cached status must not exceed the validity interval defined for the certificate profile and risk class.
4.9.6. CRL Issuance Frequency
Issuing CA CRLs shall be issued at least daily for online CAs unless a certificate profile or risk decision requires a shorter interval. Root CA CRLs shall be issued at least every six months and after subordinate CA revocation. Delta CRLs may be used where supported and tested.
4.9.7. Maximum Latency for CRLs
CRLs shall be published to repositories promptly after generation. Repository monitoring shall alert on missing, stale, or malformed CRLs before nextUpdate. Relying-party fail behavior must be defined according to risk.
4.9.8. Online Revocation/Status Checking Availability
OCSP or equivalent online validation should be available for high-security authentication, physical access challenge flows, VPN, code signing validation, and other time-sensitive relying-party decisions. Critical access systems should be designed with redundant validation paths or approved local policy caches.
4.9.9. Special Requirements for Key Compromise
Key compromise triggers immediate revocation, incident response, impact assessment, relying-party notification where appropriate, investigation of enrollment and key storage controls, and determination of whether related credentials or issuing CAs are affected. CA key compromise procedures are addressed in Section 5.7.
4.9.10. Circumstances for Suspension
Certificate suspension is not a default GridPass practice. Where temporary access removal is required, relying-party authorization should be disabled or the certificate revoked. Suspension may be introduced only after Policy Authority approval and technical validation across relying parties.
4.10. Certificate Status Services
GridPass shall provide CRL publication and may provide OCSP or validation APIs. Status services shall be monitored for availability, freshness, integrity, and correctness. The OCSP responder private key, if used, shall be protected according to its profile and delegated only for OCSP signing.
4.11. End of Subscription
Subscription ends when the subscriber is no longer affiliated, the device or service is retired, the credential expires and is not renewed, the certificate is revoked, the applicable agreement terminates, or the Policy Authority terminates the use case. End of subscription requires return or destruction of tokens where feasible, removal of relying-party authorization, and archival of records.
4.12. Key Escrow and Recovery
Authentication and signing private keys shall not be escrowed. Encryption private keys may be archived or recovered only under approved key recovery policies, dual control, audit logging, and legal or business authorization. S/MIME and file-encryption recovery must be designed so that recovery of historical data does not enable impersonation or unauthorized signing.
5. Facility, Management, and Operational Controls
5.1. Physical Security Controls
CA facilities, HSM storage locations, enrollment workstations, token inventory, and backup media shall be protected according to the sensitivity of the CA or credential function. Offline root CA material shall be stored in a secure facility with access logging, dual control, tamper-evident storage, and environmental protections. Issuing CA systems shall be operated in secured administrative environments with restricted access.
Enrollment workstations are trusted issuance points. They shall be dedicated or strongly managed systems, placed in controlled areas, configured with least privilege, equipped with approved readers, monitored, and used only by authorized enrollment personnel. Where two readers are used, the operator login token and the subscriber enrollment token must be logically distinguished by the enrollment workflow. Removal of the operator credential shall lock or terminate the enrollment session; removal of the subscriber card shall abort or pause that subscriber transaction.
Asset/control point | Minimum control |
|---|---|
Root CA media and HSM material | Offline, dual control, tamper-evident storage, inventory, ceremony access log. |
Issuing CA hosts | Secured server environment, administrative network isolation, HSM integration, monitored access. |
Enrollment workstations | Managed baseline, restricted software, dual-reader support where needed, screen lock, camera/badge integration if used. |
Blank smart cards/tokens | Inventory control, locked storage, chain-of-custody, reconciliation, destruction of defective tokens. |
Printed badges | Printer access control, spoilage tracking, visual credential standard, separation of standard and high-security credentials. |
5.2. Procedural Controls
Trusted roles shall be defined, assigned, reviewed, and separated. No single person should be able to complete high-risk CA lifecycle actions without review or dual control. Root CA ceremonies, subordinate CA issuance, CA key generation, CA key backup, recovery operations, code signing profile changes, and GP-4 enrollment require documented procedures and evidence retention.
Trusted role | Examples of duties |
|---|---|
CA Administrator | CA configuration, issuance service operation, CA software maintenance. |
Security Officer | Approves high-risk security actions, monitors compliance, leads incident response. |
RA Officer | Identity proofing, enrollment approval, revocation approval, subscriber lifecycle records. |
Enrollment Agent | Conducts approved enrollment transactions using an enrollment agent certificate. |
HSM Officer/Crypto Officer | HSM initialization, key ceremonies, activation, backup, and recovery under dual control. |
Auditor | Reviews logs, ceremonies, access, and CPS compliance; does not perform CA operations being audited. |
5.3. Personnel Controls
Personnel in trusted roles must be identity-proofed, trained, authorized, and subject to background or contractual controls appropriate to their role and applicable law. Access to CA systems shall be removed promptly when personnel leave a trusted role. Training shall cover this CPS, certificate profiles, issuance procedures, incident reporting, privacy, physical security, and relying-party impact.
5.4. Audit Logging Procedures
Security-relevant events shall be logged, protected from unauthorized modification, reviewed, and retained. Logs shall include CA and RA administration, certificate requests, approvals, issuance, revocation, key ceremonies, HSM operations, repository publication, enrollment station activity, token inventory changes, privileged access, security alerts, and changes to certificate profiles or policy.
Log source | Examples |
|---|---|
CA platform | Issuance, revocation, template changes, service start/stop, administrative changes. |
HSM | Authentication, key use, key generation, backup, restore, tamper events. |
RA/enrollment | Applicant, approver, token serial, reader/station, certificate serial, photos or proofing metadata where approved. |
Repository/status | CRL publication, OCSP health, failed publication, unauthorized access attempts. |
Relying-party connectors | Validation requests, physical access authorization responses, Keycloak/VPN login decisions. |
5.5. Records Archival
Archive records shall be retained for a period sufficient to support audits, dispute resolution, incident response, and legal requirements. Records include this CPS and versions, certificate profiles, approvals, issuance and revocation records, identity proofing evidence, ceremonies, token inventory, audit findings, key recovery records, repository publication records, and security incidents. Archive integrity and confidentiality shall be protected.
5.6. Key Changeover
CA key changeover shall be planned, approved, tested, and communicated to relying-party owners before new issuing CA keys are introduced. The old CA may continue to publish CRLs and status information until all certificates issued under the old key have expired or been revoked. Trust store updates must be coordinated across Windows, Linux, Keycloak, VPN, ACS connectors, network devices, and application stacks.
5.7. Compromise and Disaster Recovery
GridPass shall maintain incident response and disaster recovery procedures for CA system corruption, repository outage, HSM failure, CA key compromise, RA compromise, enrollment workstation compromise, token inventory loss, and relying-party validation failures. Recovery plans must prioritize preservation of trust evidence, prompt revocation, continuity of status services, and controlled re-establishment of issuance capability.
Scenario | Required response |
|---|---|
Subscriber key compromise | Revoke affected certificate, investigate, issue replacement after validation, update relying-party access if required. |
Enrollment workstation compromise | Suspend enrollment use, review logs and issued certificates, rotate enrollment agent certificate, reimage or replace workstation. |
Issuing CA compromise | Cease issuance, revoke or distrust CA as required, publish emergency CRL, notify relying parties, rebuild from clean state. |
Offline root compromise | Invoke executive incident process, distrust hierarchy, publish notifications, establish replacement trust anchors under counsel and security direction. |
Repository outage | Restore publication, verify freshness, notify critical relying parties, use approved continuity cache where configured. |
5.8. CA or RA Termination
Termination of a CA or RA requires Policy Authority approval, impact analysis, relying-party notification, cessation of issuance, certificate and CRL archival, revocation or expiration plan, private key destruction or archival as appropriate, repository continuity, and final audit. RA termination requires revocation of RA and enrollment agent certificates and removal of delegated privileges.
6. Technical Security Controls
6.1. Key Pair Generation and Installation
6.1.1. Key Pair Generation
CA key pairs shall be generated in approved HSMs or equivalent approved cryptographic modules during documented ceremonies. Subscriber authentication and signing keys for GP-3 and GP-4 credentials shall be generated on smart cards or hardware tokens when supported. Device and service keys shall be generated by approved endpoint, server, HSM, TPM, or certificate management tooling.
6.1.2. Private Key Delivery to Subscriber
Private keys should not be delivered to subscribers when generated on the subscriber device, TPM, smart card, or HSM. If key delivery is approved for an encryption or service use case, it must use encrypted transport, strong access control, logging, and documented destruction of temporary key material. Authentication and signing keys for high-security credentials shall be non-exportable.
6.1.3. Public Key Delivery to Certificate Issuer
Public keys shall be delivered to the CA through authenticated enrollment protocols, CSR submission, smart card enrollment, MDM/SCEP/EST/ACME where approved, or RA-mediated enrollment. The CA or RA must validate proof-of-possession before issuance.
6.1.4. CA Public Key Delivery to Relying Parties
CA public keys shall be distributed through the GridPass repository, managed trust stores, endpoint management, directory group policy, mobile device management, Linux configuration management, application trust bundles, or manually verified ceremony outputs. Relying parties must verify fingerprints or repository integrity before trust installation.
6.1.5. Key Sizes
Key type | Minimum |
|---|---|
Offline root CA RSA | RSA 4096 with SHA-384 or stronger, or approved ECC alternative. |
Issuing CA RSA | RSA 3072 minimum; RSA 4096 preferred for long-lived issuing CAs. |
End-entity RSA | RSA 3072 preferred; RSA 2048 only by compatibility exception and shorter validity. |
ECC | NIST P-384 preferred for high assurance; P-256 permitted for compatibility where approved. |
Symmetric protection | AES-256 or equivalent approved cryptographic strength. |
6.1.6. Public Key Parameters Generation and Quality Checking
Public key parameters shall be generated by approved cryptographic modules and checked by the CA or relying tooling where feasible. Weak keys, unsupported curves, malformed CSRs, duplicate public keys, and disallowed algorithms shall be rejected.
6.1.7. Key Usage Purposes
Key usage and EKU extensions shall be set according to certificate profile and must constrain use. Authentication, signing, encryption, code signing, OCSP signing, CA signing, CRL signing, server authentication, client authentication, smart card logon, and document-signing profiles shall not be combined unless the profile explicitly permits it and risk has been accepted.
6.2. Private Key Protection and Cryptographic Module Engineering Controls
Private keys shall be protected according to their assurance class and impact. CA private keys require HSM protection. GP-3 and GP-4 subscriber keys require smart card, hardware token, TPM, secure enclave, or equivalent non-exportable protection as specified by profile. Activation data shall be distinct from the private key and protected against disclosure.
6.2.1. Cryptographic Module Standards and Controls
Cryptographic modules used for root CA, issuing CA, OCSP responder signing, code signing, and GP-4 credentials should be FIPS 140-3 validated, or FIPS 140-2 validated while transition is accepted, at a level appropriate to the role. Exceptions require Policy Authority approval and documented compensating controls.
6.2.2. Private Key Multi-Person Control
Root CA activation, CA key generation, CA key backup, CA key restore, HSM initialization, and GP-4 recovery actions require multi-person control. Split knowledge or quorum mechanisms shall be used for HSM officer credentials, backup keys, or recovery shares.
6.2.3. Private Key Escrow
CA, authentication, code signing, and digital signature private keys shall not be escrowed for subscriber impersonation. Encryption private keys may be archived under Section 4.12. HSM backup is not considered subscriber escrow when used solely for CA disaster recovery under dual control.
6.2.4. Private Key Backup
CA private key backups shall be encrypted, integrity protected, inventoried, access controlled, and recoverable only through approved ceremony. Subscriber authentication and signing keys should not be backed up. Service private key backups require profile approval and secure storage.
6.2.5. Private Key Archival
Private key archival is limited to approved encryption key recovery or CA continuity requirements. Archived keys shall be protected at least as strongly as active keys and access shall be logged under dual control where sensitive.
6.2.6. Private Key Transfer Into or From a Cryptographic Module
Transfer of private keys into or from cryptographic modules is prohibited except for approved HSM backup/restore, approved service key migration, or approved encryption recovery processes. Transfers must be encrypted, authenticated, logged, and conducted by trusted personnel.
6.2.7. Private Key Storage on Cryptographic Module
CA and high-assurance keys shall be stored in modules that prevent plaintext key export. Token and HSM inventory shall record serial numbers, firmware versions, owners, assignments, and lifecycle status.
6.2.8. Method of Activating Private Key
Subscriber private keys are activated by PIN, passphrase, biometric unlock where approved, smart card middleware, TPM policy, HSM quorum, or service account control as defined by the profile. GP-3 and GP-4 credentials must require user presence or activation data except where an approved unattended service design is documented.
6.2.9. Method of Deactivating Private Key
Private keys shall be deactivated by token removal, session logout, timeout, workstation lock, HSM logout, service shutdown, or middleware policy. Smart card removal for operator workstations shall lock the operator session when the operator credential is removed.
6.2.10. Method of Destroying Private Key
Private keys shall be destroyed by approved token reset, cryptographic erasure, HSM key deletion ceremony, media destruction, endpoint wipe, or other approved process. Destruction must be logged for CA keys, GP-4 credentials, code signing keys, enrollment agent keys, and token inventory events.
6.2.11. Cryptographic Module Rating
Target cryptographic module rating is FIPS 140-3 Level 3 for root and issuing CA HSMs, or FIPS 140-2 Level 3 where transition is accepted. Lower levels may be approved for GP-1 or GP-2 subscriber use based on risk and relying-party requirements.
6.3. Other Aspects of Key Pair Management
Certificate and key lifetimes shall be set to balance operational continuity, cryptographic risk, token lifecycle, and relying-party constraints. Shorter validity periods are required for higher-risk or harder-to-revoke environments. Historical public keys and certificates shall be archived to support validation of signatures and encrypted data recovery.
Certificate type | Target validity |
|---|---|
Offline root CA | 10 to 20 years, with controlled key rollover planning. |
Issuing CA | 5 to 10 years, not exceeding root validity and profile risk tolerance. |
User authentication / smart card | 1 to 3 years, shorter for temporary or high-risk roles. |
Visitor / temporary credential | Hours to days, not to exceed approved visit or engagement period. |
Device / workstation | 90 days to 2 years depending on automation and revocation reliability. |
Server TLS / service mTLS | 90 days to 397 days unless internal automation supports shorter. |
Code signing | 1 year or shorter with timestamping; private key in approved hardware. |
6.4. Activation Data
Activation data includes PINs, passphrases, HSM officer credentials, recovery shares, smart card unblock keys, and other secrets required to use private keys. Activation data must be generated, distributed, stored, changed, and destroyed securely. Default PINs must be changed during issuance. PIN retry limits and unblock procedures must be documented for each token type.
Activation data type | Practice |
|---|---|
Smart card PIN | Initialized during issuance, known only to subscriber after handoff, retry limit enabled, unblock workflow logged. |
HSM quorum credential | Assigned to trusted personnel, stored separately, never shared, activated only during approved ceremonies. |
Service key passphrase | Stored in approved secrets manager or HSM; access logged and least privilege. |
Recovery share | Split knowledge, sealed storage, inventory, periodic verification, dual-control use. |
6.5. Computer Security Controls
CA, RA, repository, and enrollment systems shall run hardened configurations, endpoint protection, vulnerability management, access control, administrative logging, secure backup, time synchronization, and change control. CA administration shall occur from dedicated administrative workstations or privileged access workstations, not general-purpose user endpoints.
6.6. Life Cycle Technical Controls
CA software, certificate management tooling, enrollment applications, relying-party connectors, and validation services shall follow controlled development, testing, deployment, and change management. Changes to profiles, templates, policy OIDs, EKUs, issuance authorization, or revocation behavior require pre-production testing and rollback planning.
6.7. Network Security Controls
CA and RA systems shall be segmented from general enterprise networks. Administrative access shall require strong authentication, least privilege, logging, and restricted network paths. Repository and OCSP services exposed to relying parties shall be protected against unauthorized modification and denial-of-service risks. The offline root CA shall not be connected to production networks.
6.8. Time-Stamping
CA, RA, repository, HSM, enrollment, and relying-party validation logs shall use synchronized time sources. Code signing and long-term document signing should use approved timestamping so signatures can be validated after certificate expiration. Time source changes and significant clock drift shall be logged and investigated.
7. Certificate, CRL, and OCSP Profiles
7.1. Certificate Profile
GridPass certificates shall be X.509 version 3 certificates and shall include extensions appropriate to the profile. Profiles shall be implemented as CA templates or certificate management policies and controlled through change management. Certificate content must not contain unverified information.
Profile element | Practice |
|---|---|
Version | X.509 v3 for CA and end-entity certificates. |
Serial number | Unique per issuer, generated with sufficient entropy and non-predictability. |
Signature algorithm | SHA-384 with RSA or ECDSA preferred; SHA-256 permitted for compatibility; SHA-1 prohibited for new issuance. |
Subject | Meaningful DN or approved profile-specific subject; empty subject only when SAN is critical and profile permits. |
SAN | Required for TLS DNS names, UPN smart card logon, email/S/MIME, and service identities where software requires SAN. |
AIA | Issuer certificate URL and OCSP URL where online status is required. |
CDP | CRL distribution point URL for all certificates except where profile and relying-party validation design explicitly permit otherwise. |
Certificate Policies | Applicable GridPass certificate policy OID under 1.3.6.1.4.1.61660.1.1; CPS qualifier may point to https://gridpass.pki.pxvi.net/cps. |
7.1.1. Version Numbers
All GridPass CA and end-entity certificates shall use X.509 version 3. Legacy formats are not permitted for new issuance.
7.1.2. Certificate Extensions
CA certificates shall include Basic Constraints, Key Usage, Subject Key Identifier, Authority Key Identifier, Certificate Policies where approved, AIA, and CDP as appropriate. End-entity certificates shall include Key Usage, EKU, Subject Alternative Name where required, SKI, AKI, AIA, CDP, and Certificate Policies according to profile. Criticality shall follow interoperability testing and standards expectations.
7.1.3. Algorithm Object Identifiers
Approved algorithm OIDs shall correspond to RSA or ECDSA signature algorithms with SHA-256 or SHA-384, and approved public key algorithms for RSA or named elliptic curves. MD5 and SHA-1 signatures are prohibited for new issuance. Algorithm updates shall be handled through profile change management.
7.1.4. Name Forms
Name forms shall be profile-specific. Windows smart card logon certificates shall contain UPN otherName or other approved mapping fields. S/MIME certificates shall contain rfc822Name. TLS certificates shall contain dNSName. Device certificates may contain DNS, URI, serial number, or directory attributes as approved.
7.1.5. Name Constraints
Name constraints may be applied to subordinate CAs when needed to limit namespaces, especially for customer, project, or delegated issuing CAs. Name constraints must be tested against relying-party software before production deployment.
7.1.6. Certificate Policy Object Identifier
Certificates shall include the applicable GridPass certificate policy OID under 1.3.6.1.4.1.61660.1.1 when a profile requires policy assertion. GP-1 Standard uses 1.3.6.1.4.1.61660.1.1.1; GP-2 Managed uses 1.3.6.1.4.1.61660.1.1.2; GP-3 High Security uses 1.3.6.1.4.1.61660.1.1.3; and GP-4 Critical Infrastructure uses 1.3.6.1.4.1.61660.1.1.4. The PrecisionX enterprise root 1.3.6.1.4.1.61660 is an allocation root, not an end certificate policy identifier.
7.1.7. Usage of Policy Constraints Extension
Policy constraints are not required for ordinary end-entity certificates. They may be used for subordinate CAs, cross-certification, or delegated trust where explicit policy mapping or path constraints are necessary.
7.1.8. Policy Qualifiers Syntax and Semantics
A CPS URI qualifier may point to https://gridpass.pki.pxvi.net/cps. User notices may be used only if approved by Legal and the Policy Authority. Relying parties should not rely on user notice text as the only expression of legal terms.
7.1.9. Processing Semantics for Critical Certificate Policies Extension
Certificate Policies should generally be non-critical unless a profile requires critical processing and relying-party testing confirms compatibility. Critical policy extensions may cause relying-party failures and therefore require explicit approval.
7.2. CRL Profile
CRLs shall be X.509 version 2 CRLs signed by the issuing CA or an approved delegated CRL signer where supported. CRLs shall include issuer, thisUpdate, nextUpdate, signature algorithm, CRL number, authority key identifier, and revoked certificate entries with revocation date and reason code where available. Delta CRLs may be used where supported by relying parties.
CRL item | Practice |
|---|---|
Root CRL | Longer interval, offline generation, emergency publication after subordinate CA revocation. |
Issuing CA CRL | At least daily; shorter for high-security relying parties if required. |
Reason codes | Used where supported for keyCompromise, affiliationChanged, superseded, cessationOfOperation, privilegeWithdrawn, and certificateHold if suspension is approved. |
Distribution | Published at https://gridpass.pki.pxvi.net/repository/crl and any additional CDP locations encoded in certificates. |
7.3. OCSP Profile
OCSP responders, where deployed, shall use responder certificates containing id-kp-OCSPSigning and appropriate key usage. OCSP responses shall be signed, time-bounded, and monitored. The responder may return good, revoked, or unknown according to RFC-compliant OCSP behavior and GridPass status records. OCSP responder keys shall be protected commensurate with their ability to affect relying-party decisions.
OCSP item | Practice |
|---|---|
Responder certificate | Issued by the CA being checked or otherwise authorized according to profile; EKU id-kp-OCSPSigning. |
Response validity | Short enough to limit stale-status risk; profile-specific target normally minutes to hours for high-security uses. |
Nonce support | Supported where relying-party software and performance requirements permit. |
Availability | Monitored; redundant for critical authentication and physical access use cases. |
8. Compliance Audit and Other Assessments
8.1. Frequency or Circumstances of Assessment
GridPass shall be assessed at least annually and after material changes, major incidents, CA key ceremonies, new issuing CA deployment, new high-risk relying-party integrations, or significant audit findings. GP-4 and CA operations may require more frequent internal reviews.
8.2. Identity and Qualifications of Assessor
Assessors shall have PKI, security, audit, or compliance competence appropriate to the assessment scope. External assessors should be independent and qualified for the relevant framework. Internal assessors must be independent from the operation being assessed to the extent practicable.
8.3. Assessor Relationship to Assessed Entity
The assessor must disclose conflicts of interest. Personnel who administer the CA should not be the sole assessor of their own controls. External audits, if required by customer contract or trust program, shall be performed by an approved independent assessor.
8.4. Topics Covered by Assessment
Assessments may cover CPS compliance, certificate profiles, identity proofing, RA practices, enrollment workstation controls, CA configuration, HSM controls, key ceremonies, repository publication, revocation timeliness, audit logs, personnel access, change management, disaster recovery, token inventory, and relying-party validation behavior.
8.5. Actions Taken as a Result of Deficiency
Deficiencies shall be risk-ranked, assigned an owner, tracked to remediation, and reported to the Policy Authority. Severe deficiencies may require suspension of issuance, certificate revocation, profile changes, relying-party notification, incident response, or external disclosure where legally or contractually required.
8.6. Communication of Results
Audit results are confidential unless release is approved by the Policy Authority and Legal. Summaries may be provided to customers, relying parties, insurers, auditors, or regulators under appropriate confidentiality terms. Material issues affecting reliance shall be communicated to affected relying-party owners.
9. Other Business and Legal Matters
9.1. Fees
GridPass may charge internal cost allocations or external customer fees for certificate issuance, managed PKI service, smart cards, tokens, enrollment, replacement, recovery, custom integrations, repository services, and audit support. Fees do not expand warranty or reliance rights unless a written agreement says so.
9.2. Financial Responsibility
Financial responsibility, insurance, liability caps, and customer-specific obligations shall be governed by applicable agreements. This CPS does not create unlimited liability or financial guarantees.
9.3. Confidentiality of Business Information
Confidential information includes non-public CA architecture, security procedures, vulnerability information, subscriber records, identity proofing evidence, token inventory, incident data, private repository paths, audit details, and customer integration data. Confidential information shall be protected according to PrecisionX Ventures policy and applicable agreements.
9.4. Privacy of Personal Information
GridPass shall collect, use, retain, and disclose personal information only as needed for identity proofing, certificate lifecycle operations, physical and logical access, audit, security, legal compliance, and approved business purposes. Personal data in certificates shall be minimized because certificates and status data may be visible to relying parties.
9.5. Intellectual Property Rights
PrecisionX Ventures retains rights in GridPass policies, CPS materials, certificate profiles, trust marks, repository materials, and associated documentation except where third-party rights apply. Subscribers and relying parties receive only the rights necessary to use certificates and repository information for approved purposes.
9.6. Representations and Warranties
GridPass represents that it will operate the CA materially in accordance with the effective CPS, approved certificate profiles, and applicable agreements. Subscribers represent that enrollment information is accurate, private keys and activation data will be protected, and suspected compromise will be reported promptly. Relying parties represent that they will validate certificates and use them only for approved purposes.
9.7. Disclaimers of Warranties
Except as expressly provided in an applicable written agreement, GridPass disclaims warranties not stated in this CPS or applicable agreement, including implied warranties of merchantability, fitness for a particular purpose, non-infringement, or uninterrupted availability. This draft language requires legal review before adoption.
9.8. Limitations of Liability
Liability limitations shall be governed by applicable agreements and law. Reliance on a GridPass certificate outside its approved use, without revocation checking, after expiration or revocation, or by an unapproved relying party is at the relying party's risk unless otherwise agreed in writing. This draft language requires legal review before adoption.
9.9. Indemnities
Subscriber, relying-party, customer, and service-provider indemnity obligations shall be defined in applicable agreements. Indemnity may apply to misuse of certificates, false enrollment information, failure to protect private keys, unauthorized reliance, or violation of integration terms.
9.10. Term and Termination
This CPS becomes effective when approved by the GridPass Policy Authority and remains effective until superseded or terminated. Termination of the CPS or a CA service shall not eliminate obligations needed to validate historical signatures, preserve records, publish final status information, or support lawful recovery.
9.11. Individual Notices and Communications with Participants
Notices may be delivered through repository publication, email, service portal, ticketing system, directory notification, customer contact, or other approved channel. Emergency notices affecting reliance may be distributed directly to relying-party owners and security operations contacts.
9.12. Amendments
Amendments require version control, impact assessment, approval, publication, and effective date. Material amendments affecting reliance should provide notice before becoming effective unless emergency risk requires immediate action. Historical versions shall be archived.
9.13. Dispute Resolution Procedures
Disputes regarding certificates, reliance, subscriber obligations, or PKI operation shall be escalated to the GridPass Policy Authority and handled under applicable agreements. Legal disputes shall follow the dispute resolution provisions of the controlling contract.
9.14. Governing Law
Governing law shall be stated in applicable PrecisionX Ventures agreements. If no agreement applies, governing law must be determined by Legal before this CPS is made externally binding. This draft does not make a final governing-law election.
9.15. Compliance with Applicable Law
GridPass operations shall comply with applicable law, regulation, contractual obligations, export controls, privacy requirements, labor and employment rules, security licensing obligations where relevant, and customer-specific requirements. Legal review is required for external relying-party commitments and regulated-sector uses.
9.16. Miscellaneous Provisions
No waiver, assignment, severability, merger, force majeure, or third-party beneficiary term is created by this draft except as stated in an applicable agreement. If any provision conflicts with law or a controlling agreement, the Policy Authority and Legal shall resolve the conflict and amend the CPS if needed.
9.17. Other Provisions
Certificates used for physical access, high-security area access, operator approval, or remote infrastructure administration are security controls, not standalone authorization grants. The relying-party system must perform authorization using current policy, role, zone, account, device posture, and status information. A valid certificate proves possession and binding within its policy; it does not automatically grant access.
GridPass may support customer or project PKI enclaves, but each enclave must define trust anchors, relying parties, data retention, privacy boundaries, support responsibilities, and termination procedures. Cross-environment trust must not be assumed merely because multiple environments are operated by PrecisionX Ventures.
A. Certificate Profile Matrix
This appendix summarizes intended GridPass certificate profiles. Final implementation shall be maintained in a controlled certificate profile standard and CA template repository.
Profile | Assurance | Key usage | EKU | Key storage | Target validity |
|---|---|---|---|---|---|
Offline Root CA | CA | keyCertSign, cRLSign | None | HSM offline | 10-20 years |
Enterprise Issuing CA | CA | keyCertSign, cRLSign | None | HSM online | 5-10 years |
Infrastructure Issuing CA | CA | keyCertSign, cRLSign | None | HSM online | 5-10 years |
Smart Card Logon | GP-3/GP-4 | digitalSignature | Client Auth, Smart Card Logon | Smart card token | 1-3 years |
PIV Authentication | GP-3/GP-4 | digitalSignature | Client Auth | Smart card token | 1-3 years |
Digital Signature | GP-3/GP-4 | digitalSignature, nonRepudiation/contentCommitment where profile permits | Document Signing or Client Auth as approved | Smart card/token | 1-3 years |
Key Management / Encryption | GP-2/GP-3 | keyEncipherment or keyAgreement | Email Protection as applicable | Token, TPM, or archived encryption key | 1-3 years |
S/MIME Signing | GP-2/GP-3 | digitalSignature | Email Protection | Token or managed store | 1-3 years |
S/MIME Encryption | GP-2/GP-3 | keyEncipherment/keyAgreement | Email Protection | Recoverable key store if approved | 1-3 years |
VPN Client | GP-2/GP-3 | digitalSignature | Client Auth | TPM or smart card | 1-2 years |
TLS Server | GP-1/GP-2 | digitalSignature, keyEncipherment as algorithm requires | Server Auth | Server/HSM/managed secret | 90-397 days target |
mTLS Service Client | GP-2 | digitalSignature | Client Auth | Service key store/HSM | 90 days-1 year |
Device / Wi-Fi 802.1X | GP-1/GP-2 | digitalSignature | Client Auth | TPM or managed endpoint | 90 days-2 years |
Code Signing | GP-4 | digitalSignature | Code Signing | FIPS token/HSM | 1 year or less |
Enrollment Agent | GP-4 | digitalSignature | Certificate Request Agent / Enrollment Agent | Smart card/token | 1 year or less |
OCSP Responder | Service | digitalSignature | OCSP Signing | HSM or protected service key | Short-lived, profile-specific |
B. Enrollment Workstation and Credential Issuance Ceremony
The following baseline ceremony applies to GP-3 and GP-4 smart card issuance. The detailed procedure may be maintained as a separate SOP, but deviations from these controls require documented approval.
- Verify that the enrollment workstation is in a controlled area, fully patched, healthy, time-synchronized, and signed into by an authorized Enrollment Agent using the operator credential.
- Confirm that the operator reader and subscriber/card reader are identified by the enrollment application and that card serial numbers can be recorded accurately.
- Retrieve the approved enrollment request and verify subject identity, sponsor or manager approval, assurance level, certificate profiles, and physical/logical access requirements.
- Validate the applicant using the proofing method required for the assurance class; record proofing evidence according to privacy and retention policy.
- Select a blank or reassigned smart card from controlled inventory, record token serial, and verify that the token is not already assigned to another active subscriber.
- Initialize or reset the token using approved middleware; set management keys, PIN policies, retry limits, and unblock rules according to token standard.
- Generate certificate key pairs on-card where supported. Submit certificate requests through the approved enrollment agent workflow and verify proof-of-possession.
- Verify issued certificate chain, policy, EKU, UPN/email/name fields, revocation pointers, and certificate serials before handoff.
- Initialize subscriber PIN in a manner that prevents disclosure to the Enrollment Agent after handoff; require subscriber acknowledgement of credential responsibilities.
- Bind token serial, certificate serials, cardholder identity, badge number if applicable, access zones, expiration, and issuance officer to the credential management record.
- If a badge is printed, verify visual identity, expiration, access markings, and front/back layout. Spoiled badges must be destroyed and logged.
- Test required relying-party flows in a controlled manner, such as Windows logon, Keycloak, VPN, GuardStation check-in, or physical access challenge, without granting unauthorized production access.
- Close the issuance transaction, store logs, reconcile token inventory, and ensure the operator session locks when the operator smart card is removed.
Enrollment reader behavior The enrollment application and procedure must distinguish the operator credential from the subscriber credential. The workstation operating system may lock on removal of the operator logon smart card; subscriber card insertion or removal must be handled by the enrollment application as a separate transaction event. |
|---|
C. Relying-Party Integration Practices
This appendix states baseline practices for major relying-party integrations. Each production integration should have a separate integration record that maps certificate profiles, policy OIDs, trust stores, revocation behavior, authorization mapping, logging, and break-glass handling.
Relying party | Integration practice |
|---|---|
Microsoft Active Directory / Windows | Use smart card logon certificates with UPN mapping, domain controller trust in GridPass CA chain, revocation checking, and account authorization. Removal behavior should lock workstations where required by security policy. |
Keycloak | Use mTLS, certificate authentication, or signed challenge validation with explicit subject mapping, policy validation, revocation checking, and realm-level authorization. |
VPN / Remote Access | Require client authentication EKU, current revocation status, user/device authorization, and conditional access or posture checks where available. |
GuardStation | Treat GridPass as the high-security credential authority for check-in, zone elevation, visitor expiration, operator authentication, and event audit correlation. |
UniFi Access / ACS connectors | Where native ACS cannot perform certificate validation, use an approved connector or middleware that validates signed challenges and then sends a narrowly scoped authorization decision or credential mapping to the ACS. |
Physical high-security areas | Require proof-of-possession of a high-security credential plus current access-zone authorization. UID-only cards may open standard areas only where risk accepts that assurance level. |
S/MIME and file encryption | Publish or discover current encryption certificates; recover historical encryption keys only through approved recovery process; never use encryption recovery to impersonate signatures. |
Code signing | Require hardware-protected keys, named accountable signer, timestamping, build/release approval, malware scanning, and revocation response plan. |
Wi-Fi / 802.1X | Use device or user certificates with current status, endpoint management correlation, and network authorization policy. |
API / mTLS | Validate service identity, certificate policy, SAN/URI mapping, client authorization, and short-lived service certificate rotation. |
D. Open Implementation Decisions
The following decisions remain open, require owner assignment, or require final implementation confirmation before the CPS is declared effective or certificates are issued in production.
Decision | Current draft position |
|---|---|
OID registry governance | PrecisionX PEN 61660 is allocated as enterprise OID root 1.3.6.1.4.1.61660. GridPass PKI uses 1.3.6.1.4.1.61660.1 and certificate policies use 1.3.6.1.4.1.61660.1.1.x. Assign an owner and change-control process for future OID allocations. |
Final CA hierarchy names | Confirm CA common names, separation between identity, infrastructure, code signing, and any customer/project CAs. |
HSM selection | Select root and issuing CA HSMs, validation level, backup process, and ceremony materials. |
Token standard | Choose supported smart card/token models, middleware, PIN policy, unblock policy, and card lifecycle process. |
Certificate profiles | Finalize EKUs, KUs, SAN rules, validity periods, algorithms, criticality, and issuance authorization for each profile. |
Legal terms | Legal review of warranties, liability, governing law, privacy, relying-party terms, and external publication language. |
Repository architecture | Confirm public/internal URLs, CRL/OCSP availability target, monitoring, and failover. |
Physical access connector | Define exact GuardStation/ACS proof-of-possession flow, logging correlation, fail behavior, and emergency override. |
Key recovery | Define whether S/MIME/file encryption recovery is offered, who can approve it, and how recovery evidence is retained. |
Audit baseline | Select internal audit checklist and determine whether external assessment is required by customers or certifications. |
E. References
RFC 3647, Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework, RFC Editor, November 2003.
NIST, FIPS 140-3 and FIPS 140-2 cryptographic module validation references, as applicable to selected HSMs and tokens.
Microsoft smart card logon, certificate mapping, and Active Directory Certificate Services documentation, as applicable to the final Windows implementation.
Applicable PrecisionX Ventures security policies, access control policies, privacy policies, incident response procedures, and customer or relying-party agreements.