# Encypher Verified Organizations List: Inclusion Policy **Status:** Draft v1 **Operator:** Encypher Corp. **Canonical policy URL:** https://trust.encypher.com/inclusion-policy This policy governs the Encypher Verified Organizations List, a CAWG X.509 trust list that Encypher publishes for C2PA and CAWG content provenance. The list is published in IPTC-compatible form at three artifacts: - https://trust.encypher.com/anchor-list.pem - https://trust.encypher.com/end-entity-list.pem - https://trust.encypher.com/trust-list.json The JSON manifest carries the full listing with per-entry status and metadata. The two PEM bundles carry only the certificates that are currently in force. ## 1. Purpose and Scope The list binds a verified organization, or a sponsor-validated individual acting for an organization, to an X.509 credential used in CAWG identity assertions. A validator that trusts this list can render a named-actor identity for content whose CAWG assertion chains to a listed certificate. The list covers all content sectors, including AI platforms, brands, agencies, and public-sector bodies. It is not limited to news publishers. The IPTC Origin Verified News Publishers list covers only news publishers; this list covers the organizational and sponsored-individual segments that the news-only list does not. The list attests identity and authorization. It does not attest that any particular piece of content is accurate, lawful, or free of AI generation. Those are content claims carried inside the C2PA manifest, not properties of the trust list. ## 2. Roles Two functions govern every listing. Encypher operates both today. The functions are documented as separable so that the record shows which function made which decision, and so that a Certificate Authority function could later be operated by a distinct entity without changing this policy. - **Registration Authority (RA) function.** Validates the applicant's identity and authorization against the requirements in Section 4. Produces a signed validation record. Does not hold or use any signing key. - **Certificate Authority (CA) function.** Issues the X.509 certificate only against a passing RA validation record for the exact applicant. Operates the key hierarchy, OCSP responder, and CRL. Separating the two functions is the primary mitigation for self-dealing. Neither function can list an organization on its own: the RA cannot issue a certificate, and the CA will not issue without an RA record bound to the same applicant. ## 3. Eligibility An applicant is one of the following organization types, recorded in the `organizationType` field of its registry entry: - `ai_platform` - a provider of generative or content-modifying AI systems. - `news_publisher` - a news or editorial organization. - `brand` - a commercial brand publishing its own content. - `agency` - an agency acting for named clients. - `individual` - a sponsor-validated individual (see `sponsor_iv_ov` below). - `public_sector` - a government or public body. ## 4. Validation Requirements Each entry records its assurance in the `validationLevel` field. Two levels are defined. - **`ov` (organization validation).** Encypher confirms the legal-entity existence of the organization against an official companies or business registry in the stated jurisdiction, and verifies that an authorized officer of that entity requested and authorized the listing. The `jurisdiction` field records the registry basis. - **`sponsor_iv_ov` (sponsored individual, organization-validated).** Encypher verifies the identity of a named individual and confirms that an `ov`-level organization has authorized that individual to act under its identity. This is the "journalist at this organization" profile: the individual's identity plus a standing organizational authorization. Every listing requires a passing RA validation record before the CA function issues. Validation evidence is captured as an immutable record and is re-checked before any renewal. ## 5. Key Handling Encypher requires and prefers subscriber keys held in a KMS or HSM as non-exportable key material. The preferred posture is that the private key never exists in exportable form outside the cryptographic boundary. A subscriber that must, for a stated operational reason, handle a key outside this posture is under a mandatory notification obligation: it must notify Encypher of the out-of-policy key handling. Notification triggers revocation of the affected certificate. Failure to notify is itself grounds for revocation and delisting. These requirements mirror the published IPTC eligible-CA criteria (key-handling policy with a revocation trigger). This policy is therefore usable directly as Encypher's IPTC eligible-CA application evidence. ## 6. Certificate Profile Certificates listed here conform to the CAWG Identity 1.2 X.509 credential model. - **Key:** ECDSA on P-384 (secp384r1). - **Extended Key Usage:** exactly one of - `id-kp-documentSigning` (OID 1.3.6.1.5.5.7.3.36), or - `id-kp-emailProtection` (OID 1.3.6.1.5.5.7.3.4), used for the CAWG interim S/MIME path whose generation cutoff is 31 March 2027. - **Validity:** maximum 366 days. - **Revocation:** an OCSP responder and a CRL are published for every issuing CA. Relying parties should check status through either. Anchor entries (`role: anchor`) are CA certificates. End-entity entries (`role: end_entity`) are non-CA certificates. ## 7. Listing Lifecycle Each entry carries a `status` of `active`, `suspended`, or `revoked`. - **Add.** A new entry starts `active` after a passing RA record and CA issuance. `addedAt` records the timestamp. - **Suspend.** An entry is set `suspended` when its standing is under review or its authorization is temporarily withdrawn. A suspended certificate is excluded from the PEM bundles. - **Revoke.** An entry is set `revoked` on key compromise, loss of authorization, out-of-policy key handling, or delisting. `revokedAt` records the timestamp. On confirmed key compromise the revocation SLA is 24 hours: the OCSP and CRL status change and the PEM bundle exclusion are published within 24 hours of confirmation. Revoked and suspended entries stay in `trust-list.json` with their status and timestamps for auditability. They are excluded from `anchor-list.pem` and `end-entity-list.pem`, and from the DER tuples validators build from those bundles. A revoked certificate is never silently deleted from the record. ## 8. List Change Control - Every change to the registry is a reviewed pull request. No entry is added, suspended, or revoked outside that review. - The registry file's git history is append-only: entries are edited in place for status transitions, but history is never rewritten, so the full listing and delisting record is auditable from version control. - Each published release includes `sha256sums` covering `trust-list.json`, `anchor-list.pem`, and `end-entity-list.pem`, so a downstream consumer can confirm it fetched the exact released bytes. ## 9. Distribution The published artifacts are: - https://trust.encypher.com/trust-list.json - https://trust.encypher.com/anchor-list.pem - https://trust.encypher.com/end-entity-list.pem - https://trust.encypher.com/inclusion-policy **Canonicalization.** `trust-list.json` is published in a canonical serialization (sorted keys, no insignificant whitespace, trailing newline). Its ETag is the SHA-256 of the canonical bytes, so a validator can revalidate with a conditional request. **Refresh cadence.** Validators should refresh the artifacts on a 24-hour cadence, and always before treating a stale copy older than 24 hours as current. **Pinning guidance.** A validator that requires byte-level assurance should pin the SHA-256 of the artifact it fetched against the published `sha256sums` for that release, and refuse a bundle whose digest does not match. Pinning is recommended for high-assurance deployments and is compatible with the 24-hour refresh: on refresh, re-read the release `sha256sums` and re-pin.