Z&D CA Certificate Policy and Certification Practice Statement

Document control

This document is the combined Certificate Policy (CP) and Certification Practice Statement (CPS) for Z&D CA, structured per RFC 3647, with a Time-Stamp Policy (section 8) based on RFC 3628 and a PKI Disclosure Statement (Appendix A).

Changes are made by editing the published copy, which is always the one in force.

1. Introduction

Z&D CA is a small, personally operated certification authority. Its trust model is simple: relying parties trust it because they know and trust the people who run it.

1.1 Overview and scope

Z&D CA operates the Z&D Medical LLC hierarchy (root CN "Z&D Medical LLC", Dover, PA) and acts as CA operator for Pleasant Hill. It may operate CAs for other organizations in future; each is covered by this document unless a separate addendum says otherwise.

1.2 Participants

1.3 Certificate uses

Certificates are issued for TLS servers, mutual TLS (mTLS) clients, Wi-Fi (802.1X) access, personal identity and document signing (including ZEDsign), and timestamping. Any other use is outside this policy.

1.4 Definitions

• Retired CA: an issuing CA whose validity has ended, whose private key is destroyed, and whose certificate stays published.
• Hold period: time after a CA stops issuing during which it remains valid so its certificates can run out their lives.
• Notary-style verification: identity proofing equivalent to what a notary public does before a signing (section 3).

2. Publication and repository

All CA certificates, CRLs and this policy are published openly, and certificates of retired CAs are never removed.

CRLs are published for each active issuing CA. Once a CA is retired, its CRL and OCSP responses may stop being published; relying parties should rely on a trusted timestamp to show a signature was made while the CA was valid (section 5.4).

Access to the repository is public and read-only. No access controls apply other than those protecting the integrity of the published files.

3. Identification and authentication

Z&D CA issues a certificate to anyone who asks, provided an operator has verified their identity to the standard a notary public would apply before a signing.

3.1 Naming

Subject names identify the person, organization or host the certificate is for. Names must be meaningful and must not mislead. Server certificates name only domains the applicant controls.

3.2 Initial identity validation

• People: an operator checks a current government-issued photo ID in person, or over a live video call with the ID shown on camera, and confirms the applicant matches it. Personal knowledge of the applicant by an operator may supplement, but not replace, the ID check.
• Organizations: the individual requesting on the organization's behalf is verified as above, and their authority to act for it is confirmed.
• Servers: control of each domain is confirmed by a DNS or HTTP challenge, or the host is operated by Z&D CA itself.
• Devices (Wi-Fi, mTLS): issued to a verified person or organization, who is responsible for the device.
• Pleasant Hill mTLS users: issued at the direction of Pleasant Hill IT, which confirms the subscriber is an authorized user of Pleasant Hill systems and asks Z&D CA to issue. Z&D CA verifies that the request came from Pleasant Hill IT; Pleasant Hill IT is responsible for the subscriber's identity and for requesting revocation when access ends. These certificates carry policy OID 1.3.6.1.4.1.67323.1.1.2.1 (section 9.8).

ID numbers are not recorded; the operator records that verification took place, the method, the date and who performed it.

3.3 Renewal and re-key

A subscriber verified within the last year may renew without a new ID check, provided the subject details are unchanged. Otherwise section 3.2 applies again.

3.4 Revocation requests

A revocation request is accepted from the subscriber (authenticated by the same channel they used to apply, or by proving possession of the private key) or from an operator.

4. Certificate lifecycle

Certificates are requested through https://enroll.sshlab.net or in person, issued after verification, and revoked as soon as practical when a valid request arrives.

4.1 Application and issuance

1. The applicant completes the form at https://enroll.sshlab.net or contacts an operator directly.
2. An operator verifies identity (section 3.2).
3. The key pair is generated by the subscriber where possible; the operator may generate it and deliver it securely (for example a password-protected PKCS#12 file with the password sent separately).
4. The certificate is issued from the current issuing CA for its type and delivered to the subscriber.

Issuance is at the operators' discretion; a request may be declined without giving a reason.

4.2 Acceptance and use

The subscriber accepts a certificate by using it. Subscribers must protect their private key, use the certificate only for its stated purpose, and request revocation promptly if the key is lost or compromised or the certificate details become wrong.

4.3 Renewal

Certificates are not extended. Renewal means a new certificate, normally with a new key, issued from the CA current at that time. Annual certificates for the next year are issued from December 1 (section 5.4).

4.4 Revocation

Grounds for revocation:

• key compromise or suspected compromise
• subscriber request
• details in the certificate are wrong or no longer true
• misuse, or breach of this policy
• any other reason an operator considers valid

Revocation is acted on as soon as practical, in good faith, and appears in the next CRL and in OCSP responses. Suspension is not used. Retiring a CA is not a revocation (section 5.4).

4.5 End of subscription

A subscription ends when the certificate expires or is revoked. Expired certificates are not revoked.

5. Operational controls

Z&D CA is run by two named people, keeps records on a best-effort basis, and rotates issuing CAs on a fixed calendar so no CA outlives the certificates it issued by more than a short margin.

5.1 Physical and logical security

CA systems run on infrastructure controlled by the operators. The certificate management system is protected by two-factor authentication and other access controls. The root key is held on a hardware security module (section 6.2).

5.2 Personnel

The operators are Zach and Dezirae. Their identities are public in this document because the trust model depends on relying parties knowing who runs the CA.

5.3 Records and audit logs

Z&D CA keeps issuance, revocation and identity-verification records, and TSA logs, on a best-effort basis, normally for the life of the related signing certificate. They may be kept longer or shorter; no retention period is guaranteed. No independent audit is performed; the operators review this policy and their practices yearly.

5.4 CA rotation and retirement

Issuing CAs rotate on a fixed schedule:

• Annual CAs (Wi-Fi, mTLS, ID/signing): one CA per calendar year. All certificates it issues expire December 31. The next year's CA begins issuing December 1, and each CA itself expires January 14 of the following year.
• Server CA and TSA intermediate: each issues for 3 months, then holds for 2 months while its certificates run out, then expires. Server certificates (45 days) fit well inside the hold.

A CA is never revoked to retire it. At the end of its life it expires, its certificate moves to the trust store, its private key is destroyed, and its certificate remains published at https://sshlab.net/pki. After retirement its CRL and OCSP may no longer be available; a signature or timestamp is treated as valid if a trusted timestamp shows it was made while the certificate and its CA were valid.

5.5 Compromise and disaster recovery

If a CA key is compromised, that CA is revoked by its issuer, its certificates are revoked, affected subscribers are told, and a notice is posted at https://sshlab.net/pki/policy. If the root is compromised, all relying parties are notified and a new hierarchy is created.

5.6 Termination

If Z&D CA stops operating, it will give subscribers reasonable notice, stop issuing, keep CA certificates published for as long as practical, and destroy CA keys.

6. Technical controls

The root key lives on an HSM and signs only intermediates; every end-entity certificate comes from a short-lived issuing CA. Root recovery material is stored on a FIPS-validated encrypted drive or under multiple layers of RSA-based encryption.

6.1 Hierarchy

• Root: Z&D Medical LLC (offline use only; signs issuing CAs)
• Issuing CAs: Server CA (quarterly), TSA intermediate (quarterly, e.g. OICA-26-Q4), Wi-Fi CA, mTLS CA and ID CA (yearly)
• Pleasant Hill and future clients: separate hierarchies operated under this policy

6.2 Key protection

• The root private key is held on a hardware security module (FIPS 140-2 Level 3) or in multi-layer RSA-encrypted form.
• Issuing CA keys are held by the certificate management system and destroyed at retirement.
• There is currently no multi-person key ceremony; the root is operated by a single operator. Root operations are logged.
• Subscriber keys are the subscriber's responsibility.

6.3 Validity periods

6.4 Algorithms

Current key types are below; they may change without notice. Signatures use SHA-256 or stronger.

6.5 Computer and network security

CA systems are patched, administered only by the operators, and kept on networks the operators control. Time on CA and TSA systems comes from NIST- and USNO-traceable sources (section 8).

7. Certificate, CRL and OCSP profiles

Certificates follow RFC 5280 (X.509 v3); each one carries the extensions a relying party needs to build and check its chain.

CRLs are X.509 v2, issued per active issuing CA, and reissued before the previous one expires. OCSP, where offered, follows RFC 6960. Neither is guaranteed for a CA after it is retired.

8. Time-Stamp Policy

The Z&D Timestamping Authority issues RFC 3161 timestamps at https://ca.sshlab.net/tsa, accurate to within 100 ms of UTC, with time traceable to NIST and USNO.

8.1 Service

8.2 Obligations

The TSA puts the full certificate chain in every token so a timestamp can be checked without contacting Z&D CA. If the TSA clock loses synchronization with its time sources, or its worst-case error to UTC (root distance) exceeds 100 ms, the operators suspend the TSA until it is back within 100 ms; monitoring alerts them when synchronization is lost. If the operators learn the TSA clock was outside its accuracy while issuing, they publish a notice giving the affected period. Relying parties must check the token's signature, the chain, and that the hashed data matches.

8.3 Key and rotation

The TSA signing key rotates: 3 months issuing, 2 months hold, then retirement as in section 5.4. A timestamp stays verifiable after its TSA certificate expires, because its own time proves it was signed while the certificate was valid.

8.4 Logs

Timestamp requests are logged (time, serial, hash) to the extent the TSA software does so by default, and kept on a best-effort basis (section 5.3).

9. Legal and business matters

Z&D CA is an as-is, good-faith service with no fees and no liability: a Z&D certificate or timestamp is the formal equivalent of a handshake.

9.1 Fees

No fees are charged.

9.2 Warranties and disclaimer

The operators make a good-faith effort to verify identities and run the CA as this document describes. All certificates, timestamps, CRLs, OCSP responses and related services are provided as is, without warranty of any kind, express or implied, including fitness for a particular purpose.

9.3 Limitation of liability

To the fullest extent the law allows, Z&D CA, its operators and Z&D Medical LLC accept no liability for any loss arising from issuing, using, relying on, or failing to revoke a certificate or timestamp, or from the service being unavailable.

9.4 Subscriber and relying party obligations

Subscribers must give true information and protect their keys. Relying parties decide for themselves how much to rely on a certificate and must check its validity, chain and revocation status (or a trusted timestamp, for retired CAs) before relying on it.

9.5 Privacy

Only the information needed to verify identity and issue a certificate is collected. Information placed in a certificate is public. Other records are kept private and retained as described in section 5.3. ID document numbers and images are not kept.

9.6 Term, amendment and notice

This document takes effect when published. The operators may change it at any time by editing the published copy; it is not versioned. Notices go to ca@sshlab.net, which is monitored on a best-effort basis.

9.7 Nature of the service

Z&D CA is a hobby-level project built on personal trust and good faith. It is not a commercial or independently audited CA.

9.8 Object identifiers

IANA assigned Z&D Private Enterprise Number 67323 in October 2026, giving it the OID arc 1.3.6.1.4.1.67323. Certificates and timestamps issued before then carry no Z&D policy OID. OIDs under the arc are used as below; a number is never reused for a different meaning.

67323 is listed in the IANA Private Enterprise Numbers registry: https://www.iana.org/assignments/enterprise-numbers

Appendix A: PKI Disclosure Statement

This is the short, plain-language version of this policy for anyone who receives a Z&D certificate, signature or timestamp.