╔══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╗ ║ SYS SPACE SERVICES PKI · PROFILES · Node 1 ║ ╚══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╝
╔══════════════════════════════════════╗ ║ PKI · Node 1 ║ ╚══════════════════════════════════════╝
[ESC] Main menu · [1] Policy [2] Profiles [3] Architecture [4] Markdown
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
────────────────────────────────────────
Certificate and CRL Profiles
Normative field-by-field profiles. Modeled on DoD PKI NIPRNet Certificate and CRL Profiles v6.0 (11 Jun 2025), adapted for the root set in architecture.md §2.
This is deliberately a separate document from the Certificate Policy. The CP says what assurance means; this says what bytes go in the certificate. They change on different cadences and are approved by different people: profiles by the engineering working group, the CP by the PMA.
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
────────────────────────────────────────
──────────────────────────────────────────────────── 1. Conventions ────────────────────────────────────────────────────
──────────── 1. Conventions ────────────
▪ c=yes / c=no: the extension's criticality bit.
▪ Angle brackets <…> are variables; {…} are OIDs; | separates alternatives.
▪ Certificates shall not contain any critical extension not listed in these profiles.
▪ Values not explicitly prohibited are permitted; the profile lists an unambiguous combination of required / optional / prohibited.
▪ Only certificates issued after this document's effective date need to comply.
1.1 Naming
All DNs carry the fixed prefix:
C=<CC>, O=<Organization>, OU=<Program>, OU=PKI
Entity │ Form ───────────────┼─────────────────────────────────────────── CA │ <prefix>, CN=<CA Name> OCSP responder │ <prefix>, CN=<Responder Name> End entity │ <prefix>, OU=<Business Unit>, CN=<EE Name>
▪ One attribute value per RDN. No multi-valued RDNs.
▪ PrintableString for all directoryString attributes. UTF8String for CN only when PrintableString cannot encode it.
▪ Human CN: Last First MI [Gen] <unique-id>. The <unique-id> is mandatory and immutable.
▪ Device CN: FQDN | IP address | <model>-<serial> | application name.
▪ Wildcards: least-significant label only, and only when the certificate genuinely covers that entire namespace.
▪ Subject and issuer DNs must match their repository/directory entries exactly.
1.2 Algorithms
Policy strength │ Signature │ Subject key │ Hash ──────────────────────────────────────┼─────────────────────────┼─────────────┼──────── Policy OID │ Signature │ Subject key │ Hash <org>-hardware-112 │ sha256WithRSAEncryption │ RSA 2048 │ SHA-256 <org>-hardware-128 / <org>-device-128 │ ecdsa-with-SHA256 │ EC P-256 │ SHA-256 <org>-hardware-192 │ ecdsa-with-SHA384 │ EC P-384 │ SHA-384 <org>-medium-128 (RSA fallback) │ sha256WithRSAEncryption │ RSA 3072 │ SHA-256 PQ (phase 2) │ id-ml-dsa-65 │ ML-DSA-65 │ -
A certificate is signed with strength at least that of the highest policy OID it asserts. CRLs use the same signature algorithm, key size, and hash as the issuing CA's certificates.
1.2b Token capability selects the policy OID
The DoD Token Platform Utilization and Variation Matrix v2.11 (4 Apr 2025) lists every current platform, both CAC and Alternate Token, as RSA EE 2048 with SHA256. No current DoD token does ECC. That includes both ALT platforms:
Platform │ Type │ Chip │ Comms │ CAC Applet Pkg │ Crypto ──────────────────────────────────┼─────────────────┼──────┼──────────┼────────────────┼─────────────────── IDEMIA Cosmo V8.0 │ Alternate Token │ 128k │ T=1 │ V2.7.4 │ RSA 2048 / SHA-256 G+D Sm@rtCafe Expert v7.0 144K DI │ Alternate Token │ 144k │ T=1 │ V2.7.5 │ RSA 2048 / SHA-256 G+D Sm@rtCafe Expert v7.0 144K DI │ CAC │ 144k │ T=0/T=CL │ V2.7.5 │ RSA 2048 / SHA-256 Gemalto TOP DL V2.1 144K FIPS │ CAC │ 144k │ T=0/T=CL │ V2.7.4 │ RSA 2048 / SHA-256 IDEMIA ID-one 125 V8.0D │ CAC │ 128k │ T=0/T=CL │ V2.7.4 │ RSA 2048 / SHA-256
ECC-capable tokens are also in scope. The fleet is therefore mixed, and the profile does not branch; the policy OID does. The token's capability selects which OID the credential asserts:
Token capability │ Policy OID │ Subject key │ Encryption cert keyUsage ────────────────────────────┼────────────────────┼─────────────┼───────────────────────── DoD CAC / ALT stock (above) │ <org>-hardware-112 │ RSA 2048 │ keyEncipherment ECC token, P-256 │ <org>-hardware-128 │ EC P-256 │ keyAgreement ECC token, P-384 │ <org>-hardware-192 │ EC P-384 │ keyAgreement
This is the DoD pattern from architecture.md §5 working as designed: strength is a dimension of the OID, so a relying party that requires 128-bit expresses it as a policy OID set and RFC 5280 path validation does the rest. No custom certificate parsing, and no second profile document.
Three consequences:
1. keyUsage on the encryption certificate is key-type dependent: keyEncipherment for RSA, keyAgreement for ECC. This is the only field in the human profiles that varies by algorithm, and it is exactly the split DoD's own Table 19 makes. Get it wrong and S/MIME silently fails.
2. The 2030-12-31 sunset binds only the RSA-2048 population. No RSA-2048 certificate may be valid past that date, so a 3-year credential on DoD stock is issuable only until 2027-12-31, then shrinks month-for-month. ECC tokens are unaffected, which is a concrete argument for moving the fleet to them rather than re-carding on RSA.
3. CA keys stay EC P-384 regardless. An RSA-2048 subject key under a P-384 CA is correct: §1.2's rule is that the signature be at least as strong as the highest policy OID asserted, and -112 is the ceiling for a card-bound certificate on DoD stock.
1.2c Container mapping: DoD does not use standard PIV slots
Per the DoD Implementation Guide for CAC PIV End-Point v2.1.1 §5.3.1 and §4, DoD implements only these PIV containers: CCC, CHUID, Security Object, Fingerprints, Facial Image, and the PIV Authentication certificate (0x0101): "the only PIV mandatory certificate."
The PIV Digital Signature Key and Key Management Key containers are not separately implemented: "The functionality of these optional PIV certificates (containers) is available through the existing CAC certificates." Signature and encryption live in the CAC applet, not in PIV slots 9C/9D. The PIV Card Authentication Key was originally not implemented; the 2025 matrix records an asymmetric card authentication key (aCAK) added later for physical access.
So the naive 9A / 9C / 9D mapping is wrong for DoD-style card stock:
Credential │ DoD CAC PIV End-Point location │ Naive PIV assumption ────────────────────────────┼───────────────────────────────────────────┼───────────────────── Authentication │ PIV Authentication cert, container 0x0101 │ 9A Signature (non-repudiation) │ CAC applet PKI Digital Signature key │ ~~9C~~ Encryption (escrowed) │ CAC applet PKI Encryption key │ ~~9D~~ Card authentication │ aCAK (later addition) │ 9E
Also note the UPN differs between the PIV Authentication certificate and the CAC Signature certificate (endpoint guide §5.3.1 fn.17); they are not interchangeable for logon.
Which applet your token actually answers on is testable, and must be tested before profiles are frozen: opensc-tool -n, then piv-tool -n, with the reader attached.
1.3 Universal rules
▪ AuthorityKeyIdentifier: c=no, keyIdentifier octet string only. The issuerDN + serialNumber tuple form is prohibited: it breaks path building.
▪ SubjectKeyIdentifier: c=no, octet string.
▪ First entry of AIA.caIssuers and of CRLDistributionPoints must be an HTTP URL reachable from the public Internet. Additional LDAP or internal entries may follow.
▪ CRLDistributionPoints: distributionPoint field only. The reasons and cRLIssuer fields and the nameRelativeToCRLIssuer CHOICE are prohibited.
▪ Serial numbers: unique per issuer, and ≥ 64 bits of CSPRNG output (unpredictability is a hash-collision defence; the DoD documents predate this requirement; add it).
▪ Dates: UTCTime through 2049-12-31, GeneralizedTime from 2050-01-01. Always Z.
▪ No end-entity certificate may assert anyExtendedKeyUsage {2.5.29.37.0}.
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
────────────────────────────────────────
──────────────────────────────────────────────────── 2. CA profiles ────────────────────────────────────────────────────
──────────── 2. CA profiles ────────────
2.1 Root CA (self-signed)
Field │ Value ───────────┼────────────────────────────────────────── Version │ v3 (2) Serial │ unique, ≥64 bits random Issuer DN │ <prefix>, CN=<Root CA Name> Subject DN │ same as issuer Validity │ ≤ 25 years SPKI │ P-384 (R1/R3), P-256 (R2), ML-DSA-65 (R4)
Extension │ Value ─────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────── subjectKeyIdentifier │ c=no; octet string keyUsage │ c=yes; keyCertSign, cRLSign. Optional: digitalSignature. Prohibited: all others basicConstraints │ c=yes; cA=TRUE; pathLenConstraint absent subjectInfoAccess │ c=no (optional); id-ad-caRepository {1.3.6.1.5.5.7.48.5} → HTTP URL of the .p7c bundle of CAs │ issued by this root
No AIA, no CRLDP on a self-signed root.
2.2 Issuing CA
Field │ Value ───────────┼─────────────────────────────── Validity │ ≤ 6 years Issuer DN │ <prefix>, CN=<Root CA Name> Subject DN │ <prefix>, CN=<Issuing CA Name>
Extension │ Value ───────────────────────────┼────────────────────────────────────────────────────────────────────────────────────────── authorityKeyIdentifier │ c=no; keyIdentifier only subjectKeyIdentifier │ c=no; as in the PKCS#10 request keyUsage │ c=yes; keyCertSign, cRLSign. Prohibited: all others certificatePolicies │ c=no; exactly the policy OIDs this CA is authorized to issue under, no more basicConstraints │ c=yes; cA=TRUE; pathLenConstraint = 0 policyConstraints │ c=yes; requireExplicitPolicy: skipCerts = 0. RFC 5280 §4.2.1.11: conforming CAs MUST mark │ this extension critical. DoD Table 5 says c=no; we diverge, because a non-critical │ policyConstraints may be ignored by a validator that does not recognise it, and this is │ the control the whole policy model rests on extendedKeyUsage │ c=no (optional but recommended); EKU-constrain the CA to the EKUs it may issue authorityInformationAccess │ c=no; id-ad-caIssuers → HTTP URL for certs issued to this CA; id-ad-ocsp → HTTP URL of │ the root's responder CRLDistributionPoints │ c=no; HTTP → full and complete root CRL
Enforcement rule: an issuing CA shall not assert a policy OID in a subject certificate if its own certificate does not carry that OID. Roots are exempt. Enforce this in the issuance software, not only in the CPS.
2.3 Cross-certificate issued by the Interoperability Root
Field │ Value ───────────┼─────────────────────────────────────────────────────────────── Validity │ ≤ 3 years Subject DN │ exactly as supplied in the partner's PKCS#10; do not normalize
Extension │ Value ───────────────────────────┼────────────────────────────────────────────────────────────────────────────────────────── keyUsage │ c=yes; keyCertSign, cRLSign. Prohibited: all others certificatePolicies │ c=no; only the OIDs named in the cross-certification agreement policyMappings │ c=no; only the mappings named in the agreement. Omit entirely if the partner asserts our │ OIDs directly policyConstraints │ c=yes; requireExplicitPolicy: skipCerts=0; inhibitPolicyMapping: skipCerts=0 unless │ transitive trust is deliberately intended basicConstraints │ c=yes; cA=TRUE; pathLenConstraint per the agreement nameConstraints │ c=yes, REQUIRED; permitted and/or excluded subtrees for directoryName, rfc822Name, │ dNSName, uniformResourceIdentifier, and UPN otherName. Never an empty SEQUENCE.<br>UPN │ constraints are asserted but never relied on alone: RFC 5280 §4.2.1.10 defines subtree │ matching only for dNSName, rfc822Name, uniformResourceIdentifier, directoryName and │ iPAddress: there is no matching rule for otherName, so a UPN excludedSubtree is silently │ unenforced on OpenSSL, NSS, Java and Go. Assert directoryName and rfc822Name constraints │ that independently achieve the same containment authorityInformationAccess │ c=no; caIssuers HTTP + id-ad-ocsp HTTP CRLDistributionPoints │ c=no; HTTP → full and complete CRL
RDN and directoryString encoding follow the partner's naming scheme, not ours.
2.4 OCSP responder (delegated)
Field │ Value ───────────┼──────────────────────────────────────────────────────────────────────── Issuer │ The same CA key that signed the certificates this responder answers for Validity │ ≤ 45 days from issuance (private key ≤ 3 years) Subject DN │ <prefix>, CN=<Responder Name>
Extension │ Value ─────────────────────┼───────────────────────────────────────────────────────────────────────── keyUsage │ c=yes; digitalSignature. Prohibited: all others extendedKeyUsage │ c=yes; id-kp-OCSPSigning {1.3.6.1.5.5.7.3.9}. Prohibited: all others certificatePolicies │ c=no; all policy OIDs the issuing CA issues under subjectAltName │ c=no; HTTP URL or DNS name of the responder id-pkix-ocsp-nocheck │ c=no; present {1.3.6.1.5.5.7.48.1.5}; prevents infinite status recursion
A CA-hosted responder (collocated in the CA enclave with key protection equivalent to the CA signing key) may instead be valid for the life of the issuing CA.
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
────────────────────────────────────────
──────────────────────────────────────────────── 3. End-entity profiles ────────────────────────────────────────────────
──────── 3. End-entity profiles ────────
Common to all: authorityKeyIdentifier (keyIdentifier only), subjectKeyIdentifier, certificatePolicies (c=no), authorityInformationAccess (caIssuers HTTP + ocsp HTTP), CRLDistributionPoints (HTTP, full and complete).
3.1 Human: Authentication
Validity │ ≤ 3 years │ │ ─────────────────┼───────────────────────────────────────────────────────┼────────┼─────────────────────────────────── Subject DN │ <prefix>, OU=<BU>, CN=Last First MI <unique-id> │ │ keyUsage │ c=yes; digitalSignature │ │ extendedKeyUsage │ c=no; id-kp-clientAuth {…3.2}; optional id-ms- │ │ │ smartcard-logon {1.3.6.1.4.1.311.20.2.2} │ │ subjectAltName │ c=no; otherName = UPN. Optional: rfc822Name │ │ Policy │ <org>-hardware-112 \ │ -128 \ │ -192, per token capability (§1.2b) Key storage │ FIPS 140-3 Level 2 hardware token │ │
3.2 Human: Signature (non-repudiation)
Validity │ ≤ 3 years │ │ ─────────────────┼────────────────────────────────────────────────────┼────────┼─────────────────────────────────── keyUsage │ c=yes; nonRepudiation (and digitalSignature) │ │ extendedKeyUsage │ c=no; id-kp-emailProtection {…3.4} │ │ subjectAltName │ c=no; rfc822Name │ │ Policy │ <org>-hardware-112 \ │ -128 \ │ -192, per token capability (§1.2b) Escrow │ Never. This key is never backed up, never escrowed │ │
3.3 Human: Encryption
Validity │ ≤ 3 years │ ─────────────────┼───────────────────────────────────────────────────────────────────────────────┼──────────────────── keyUsage │ c=yes; keyEncipherment (RSA) \ │ keyAgreement (ECDH) extendedKeyUsage │ c=no; id-kp-emailProtection │ subjectAltName │ c=no; rfc822Name │ Policy │ <org>-hardware-112 (§1.2b) │ Escrow │ Yes: this is the only escrowed key type. Two-person control on third-party │ │ recovery │
Three separate key pairs per human subscriber. Collapsing them forfeits either non-repudiation or data recovery.
3.4 TLS server
Validity │ ≤ 90 days, ACME-automated (DoD permits 3 years; do not copy that) ─────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────── Subject DN │ <prefix>, OU=<BU>, CN=<primary FQDN> keyUsage │ c=yes; digitalSignature (+ keyEncipherment for RSA) extendedKeyUsage │ c=no; id-kp-serverAuth {…3.1}, id-kp-clientAuth {…3.2}. Prohibited: anyExtendedKeyUsage, │ emailProtection, codeSigning, OCSPSigning subjectAltName │ c=no; dNSName (one per name; multiple permitted). Optional iPAddress Policy │ <org>-device-128
subjectAltName is authoritative. CN is legacy decoration: populate it, never match on it.
3.5 Workload / device (NPE)
Validity │ ≤ 24 hours (workload) / ≤ 1 year (physical │ │ │ device) │ │ ─────────────────┼──────────────────────────────────────────────┼──────────────┼────────────────────────────────────── Subject DN │ <prefix>, OU=<BU>, CN=<FQDN │ model-serial │ app name> keyUsage │ c=yes; digitalSignature (+ keyEncipherment │ │ │ for RSA) │ │ extendedKeyUsage │ c=no; id-kp-clientAuth, optionally id-kp- │ │ │ serverAuth │ │ subjectAltName │ c=no; dNSName \ │ iPAddress \ │ uniformResourceIdentifier (SPIFFE ID) Policy │ <org>-device-128 or <org>-internal- │ │ │ device-128 │ │ Activation data │ May be activated without a PIN/passphrase │ │ │ (this is the assurance carve-out that │ │ │ requires the separate R2 root) │ │ Sponsor │ A named PKI Sponsor holds subscriber │ │ │ obligations │ │
3.6 Code signing
Certificate validity │ ≤ 6 years; private key usage ≤ 13 months ─────────────────────┼─────────────────────────────────────────────────────────────────────────── keyUsage │ c=yes; digitalSignature extendedKeyUsage │ c=yes; id-kp-codeSigning {…3.3}. Prohibited: all others Policy │ <org>-hardware-192 Key storage │ FIPS 140-3 Level 2 hardware, minimum Timestamping │ Signatures must be RFC 3161 timestamped so they survive certificate expiry
Issued only by a dedicated code-signing CA that carries no other policy OID.
3.7 Time Stamp Authority
Validity │ ≤ 6 years ─────────────────┼───────────────────────────────────────────────────────── keyUsage │ c=yes; digitalSignature, nonRepudiation extendedKeyUsage │ c=yes; id-kp-timeStamping {…3.8}. Prohibited: all others
Critical EKU with nothing else is what makes a TSA certificate unusable for anything else.
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
────────────────────────────────────────
──────────────────────────────────────────────────── 4. CRL profile ────────────────────────────────────────────────────
──────────── 4. CRL profile ────────────
Field │ Value ────────────────────┼───────────────────────────────────────────────────────────────────── Version │ v2 (1) Signature algorithm │ same as the issuing CA's certificate signature algorithm Issuer │ CA's DN, byte-identical to its certificate's subject thisUpdate │ time of generation nextUpdate │ per the cadence table below; required Revoked certs │ userCertificate (serial), revocationDate, and reasonCode where known
Extension │ Value ─────────────────────────┼───────────────────────────────────────────────────────────────── authorityKeyIdentifier │ c=no; keyIdentifier only cRLNumber │ c=no; monotonically increasing, never reused, never reset issuingDistributionPoint │ c=yes only if the CRL is partitioned; omit for full-and-complete Entry: reasonCode │ c=no Entry: invalidityDate │ c=no, optional
4.0 Encoding
CRLs published at an HTTP CRLDistributionPoints URL shall be DER, served as Content-Type: application/pkix-crl. PEM is not acceptable.
This is not pedantry. openssl auto-detects PEM, so a PEM CRL passes every openssl-based check while NSS (and therefore Dogtag's own client, Firefox, and anything built on NSS) rejects it with SEC_ERROR_CRL_INVALID, cannot obtain the issuer's revocation status, and reports the chain as revoked. A misencoded CRL fails closed and looks like a revocation.
4.1 Cadence
CA class │ Normal periodicity │ Max latency, key/CA compromise ───────────────────┼────────────────────┼─────────────────────────────── Root CA (offline) │ ≥ every 28 days │ within 6 hours of notification Issuing CA │ ≥ daily │ within 18 hours Internal device CA │ ≥ every 90 days │ within 18 hours
▪ Issue on schedule even when nothing changed.
▪ Publish within 4 hours of generation, and never later than the previous CRL's nextUpdate.
▪ Remove the superseded CRL on publication of its successor.
▪ nextUpdate includes slack past the nominal period so a fetch failure does not immediately fail closed, but not so much that a stale CRL is indistinguishable from a current one.
4.2 Certificate removal from the CRL
An entry may be dropped only after the certificate's own notAfter has passed and the CRL covering that period has been archived. Never shrink a CRL by dropping live entries.
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
────────────────────────────────────────
─────────────────────────────────────── 5. Prohibited in end-entity certificates ───────────────────────────────────────
────────────────────────────────────────
▪ anyExtendedKeyUsage {2.5.29.37.0}
▪ basicConstraints with cA=TRUE
▪ keyUsage including keyCertSign or cRLSign
▪ id-kp-OCSPSigning outside a responder certificate
▪ authorityKeyIdentifier in issuerDN + serial form
▪ nameConstraints (CA-only extension)
▪ any critical extension not named in this document
▪ subjectAltName with an empty GeneralNames SEQUENCE
▪ deprecated / retired policy OIDs (see the CP's deprecation table)
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
────────────────────────────────────────
─────────────────────────────────────────────────── 6. Test vectors ────────────────────────────────────────────────────
─────────── 6. Test vectors ────────────
Every profile in this document must have a corresponding fixture in test/profiles/, and CI must fail if an issued certificate deviates. Validate paths against the NIST PKI Test Suite (PKITS) before any cross-certificate goes live: the policy-mapping and name-constraint test cases are exactly the ones that break real deployments.
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
────────────────────────────────────────
[ESC] Main menu · [1] Policy [2] Profiles [3] Architecture [4] Markdown
╔══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╗ ║ (c) 2026 SYS SPACE SERVICES · certificate policy ║ ╚══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╝
──────────────────────────────────────── (c) 2026 SYS SPACE SERVICES certificate policy