Certificate Policy (CP)

Document ID

A4E-PKI-CP-001

Version

1.0 — Production Release

Effective Date

2026-05-01

Review Date

2027-05-01

Classification

Public (Internal Network)

Policy Authority

Brian Vicente, Network Coordinator

OID Arc

1.3.6.1.4.1.65571

Hosted At

http://10.0.1.232/pki/docs/cp.html

1. Introduction

1.1 Overview

This Certificate Policy (CP) defines the rules, assurance levels, and obligations governing the Alliance for Empowerment Multi-Organization PKI. It covers all certificates issued to, or on behalf of, Alliance for Empowerment Inc. (Alliance), Able-2 Enhancing Potential Inc. (Able-2), and Capabilities Inc. (Capabilities). The PKI operates as a private, internal three-tier hierarchy. One offline Root CA serves as the single trust anchor. Three Enterprise Issuing CAs operate online, one per organization. step-ca instances serve as Registration Authorities (RAs) and hold no CA private keys.

1.2 Policy OID Identification

1.3 PKI Participants

1.4 Certificate Usage

2. Publication and Repository

• CRLs published within 24 hours of any revocation; Root CRL on 26-week schedule with 2-week overlap; issuing CA CRLs on 2-week schedule with 12-hour overlap
• CP/CPS documents updated within 30 days of any material policy change
• Availability target: 99.9% uptime for all HTTP endpoints on the-orc

3. Identification and Authentication

3.1 Distinguished Name Conventions

All certificates comply with RFC 5280 §4.1.2.6. SAN is mandatory for all TLS certificates per RFC 5280 §4.2.1.6 and CA/B Forum BR §7.1.4.2. CN alone is insufficient.

3.2 NameConstraints Permitted Subtrees

4. Certificate Lifecycle Requirements

5. Physical, Procedural, and Personnel Controls

• Root CA physical: PKI-ROOT is air-gapped; NIC disconnected at all times except signing ceremony; housed in locked server room; accessible only via XenCenter/Hyper-V console by PKI admin
• Key ceremony: Initiated by PKI administrator; all CSRs reviewed before submission; NIC attached only during ceremony; all events logged with timestamps and serial numbers; VM shut down after ceremony
• Issuing CAs: Online but hardened; RDP restricted to PKI admin; Atera RMM monitoring on certsvc; template objects on PKI-ALLIANCE, not on Root CA
• Personnel: PKI admin access exclusive to Network Coordinator; no shared credentials; all CA actions logged via Windows Security Event Log (Event IDs 4886/4887/4888/4890)

6. Technical Security Controls

7. Certificate and CRL Profiles

7.1 Root CA Profile

7.2 Issuing CA Profile

8. Compliance and Audit

9. Business and Legal Matters

• Policy authority: Brian Vicente, Network Coordinator, Alliance for Empowerment Inc., Pine City, New York
• Contact: pki-admin@wearealliance.org
• Inter-org responsibilities: Each issuing CA is operated by its respective org; Root CA is operated by Alliance on behalf of all three organizations
• Liability: This PKI is operated for internal organizational purposes only. No warranties are expressed or implied for relying parties outside the three organizations
• Privacy: Subject information is limited to what is operationally required; log data retained per organizational data retention policy
• Termination: CA decommissioning requires minimum 90-day advance notice, final CRL publication with extended NextUpdate, key destruction ceremony, and documented runbook entry

10. Post-Quantum Cryptographic Agility

11. Browser Compatibility and Public Trust Path

11.1 Future Public Trust Roadmap

1. Internal PKI stabilization — CRL/AIA/OCSP operational; step-ca RA live (current phase)
2. WebTrust / ETSI audit — Third-party audit of CA operations, key ceremony, CP/CPS
3. Mozilla Root Program — CA inclusion policy application; triggers Chrome/Apple/Microsoft consideration
4. Cross-certification (faster path) — Cross-cert from existing publicly trusted CA (DigiCert/Sectigo)
5. CT log submission — RFC 9162; step-ca supports CT logging natively for public TLS

12. OID Registry