Certificate Policy

1. Scope of the Dyber Root CA

The Dyber Root CA is a self-signed ML-DSA-65 certificate that serves as the trust anchor for all Dyber hardware device attestation. It signs exactly one subordinate: the Dyber Device Intermediate CA.

The Root CA does not directly sign device certificates, code-signing certificates, TLS certificates, or any other end-entity certificate. It exists solely to anchor the device attestation hierarchy.

The Root CA private key is stored offline in a hardware security module (HSM) and is only brought online to sign or re-sign the Intermediate CA certificate or to sign a new CRL for the Root CA level. Access requires a quorum of key custodians.

2. Certificate Hierarchy

The PKI has three levels:

Level 0: Dyber Root CA (self-signed, ML-DSA-65, 20-year validity)
Level 1: Dyber Device Intermediate CA (signed by Root CA, ML-DSA-65, 10-year validity)
Level 2: Device EK Certificates (signed by Intermediate CA, ML-DSA-44 or ML-DSA-65, 10-year validity)

Each device receives exactly one EK certificate at manufacturing time. The EK private key is generated on-device and never leaves the device's secure element. The Intermediate CA signs the corresponding public key.

3. Device EK Provisioning

During manufacturing, each Dyber hardware device undergoes the following provisioning sequence:

The device generates an ML-DSA key pair internally, in its secure element or tamper-resistant storage. The private key never leaves the device.
The device exports the public key to the provisioning station over a physically secured interface.
The provisioning station constructs a Certificate Signing Request (CSR) containing the device serial number, model identifier, manufacturing batch, and firmware version hash.
The CSR is submitted to the Intermediate CA, which signs it and returns the EK certificate.
The EK certificate and the full chain (Intermediate CA + Root CA) are written to the device's certificate store.
The provisioning station verifies the stored chain by requesting a challenge-response signature from the device, then validating the signature against the EK certificate.

Provisioning occurs in an access-controlled facility. The provisioning station communicates with the Intermediate CA signing service over a mutually authenticated TLS channel. Audit logs of all provisioning events are retained.

4. What a Valid Certificate Attests To

A valid, unrevoked device EK certificate attests to the following:

Genuine hardware. The device was manufactured by Dyber, Inc. in an authorized facility and passed functional testing.
Authentic firmware. The firmware loaded on the device at provisioning time was produced by Dyber and had not been modified. The firmware version hash is recorded in the certificate's subject alternative name extension.
Tamper state at provisioning. The device's tamper detection mechanisms had not been triggered at the time the EK was provisioned.

The EK certificate does not attest to:

The current firmware version (firmware may have been updated after provisioning).
The current physical integrity of the device (tampering may have occurred after shipment).
The security of the environment in which the device is deployed.

For runtime firmware attestation and tamper state verification, use the device's secure boot log and the remote attestation protocol documented in the QuantaCore SDK.

5. How to Verify a Device Certificate Chain

To verify that a device EK certificate is genuine and unrevoked:

Obtain the Root CA and Intermediate CA certificates from https://dyber.org/pki/ or from the bundle shipped with the device.
Verify the SHA-256 fingerprints of both CA certificates against the values published on the PKI page or in the metadata.json endpoint.
Build the certificate chain: device EK → Intermediate CA → Root CA.
Validate the chain using an ML-DSA-capable verifier. Standard OpenSSL does not yet support ML-DSA; use oqs-provider or the QuantaCore SDK.
Check the device EK certificate against the current CRL (https://dyber.org/pki/crl.pem) or query the OCSP responder at https://ocsp.dyber.org.

Example: QuantaCore SDK

dyber-cli cert verify \
  --ca-bundle /path/to/bundle.pem \
  --cert /path/to/device-ek.pem \
  --check-crl /path/to/crl.pem

Example: oqs-provider + OpenSSL

openssl verify \
  -provider oqsprovider \
  -CAfile root-ca.pem \
  -untrusted intermediate-ca.pem \
  device-ek.pem

6. Revocation

A device EK certificate may be revoked for any of the following reasons:

The device is reported as compromised, stolen, or lost.
A manufacturing defect is discovered that affects the cryptographic integrity of a batch.
A firmware vulnerability requires key rotation for affected devices.
The device owner requests revocation.

Revoked certificates are added to the CRL published at https://dyber.org/pki/crl.pem. The OCSP responder at https://ocsp.dyber.org also reflects revocations in real time once operational.

7. CRL Update Frequency

The CRL is regenerated and published every 7 days, or sooner if an emergency revocation occurs. The CRL includes a nextUpdate field indicating when the next scheduled CRL will be published. Relying parties should fetch a new CRL before the nextUpdate time.

For airgapped environments, the CRL can be transferred via removable media. The bundle.zip download at /pki/bundle.zip includes the most recent CRL at the time of download.

8. OCSP Responder

The OCSP responder at https://ocsp.dyber.org provides real-time certificate status. It is the preferred method for revocation checking in online environments. The responder supports HTTP GET and POST methods per RFC 6960.

The OCSP responder is operational. Responses are signed by the Intermediate CA using ML-DSA-65. Each response includes a nonce, thisUpdate/nextUpdate timestamps, and the certificate status (good, revoked, or unknown). Responses are valid for 7 days.

9. Contact

Revocation: legal@dyber.org
Technical: support@dyber.org
PKI Page: https://dyber.org/pki/
Metadata: https://dyber.org/pki/metadata.json

10. Policy Changes

This policy may be updated as the PKI matures. Material changes (changes to what a certificate attests to, changes to the trust hierarchy, or changes to revocation procedures) will be announced via the Dyber news page at /news-and-updates/ and reflected in the metadata.json schema_version field.

Non-material clarifications and formatting changes may be made without notice.

Certificate Practice Statement (CPS) - Full RFC 3647 CPS covering key management, security controls, and compliance procedures.
Key Ceremony Documentation - Formal procedures for CA key generation, witness requirements, and audit trail.
PKI Home - Certificate downloads, CRL, OCSP endpoint, and metadata.
Machine-Readable Metadata - JSON endpoint for automated trust chain management.

Effective date: 2026-06-11. Dyber, Inc.