Encypher CAWG Organizational Identity Certificate Policy and Certification Practice Statement

Version: 1.0.1 Status: Approved by the owner (Erik Svilich, Encypher Corporation) on 2026-10-03; in force on publication at the CPS location. Version 1.0.1 (2026-10-05) fills in the values the witnessed issuing-CA operation of 2026-10-05 produced; it changes no practice. Effective Date: Date of publication Policy OID: 1.3.6.1.4.1.67057.1.1 (under Encypher's IANA Private Enterprise Number 67057; allocations in docs/ca/oid-allocations.md) CPS location: https://identity-ca.encypher.com/repository/cps Operator: Encypher Corporation Design source: PRDs/CURRENT/PRD_CAWG_Org_Onboarding_Automation.md (Draft 7, decisions D1 to D7 and section 9)

The owner approved every point the design source left open as written in this version; Appendix B records those decisions and the values the witnessed issuing-CA operation produced.

1. Introduction

1.1 Overview

An organization that holds a certificate under this policy can sign CAWG identity assertions that carry its exact registered legal name, its registration identifier and its country. A relying party can check that name against a government or GLEIF record, because Encypher copies every subject value from such a record and from nowhere else.

This document is a combined Certificate Policy (CP) and Certification Practice Statement (CPS) for the Encypher CAWG organizational identity hierarchy. It follows the section order of RFC 3647. The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY and OPTIONAL are to be interpreted as described in RFC 2119 when they appear in capitals.

Scope:

• This document governs only the CAWG organizational identity hierarchy described in Section 1.3.1 and the certificates it issues.
• This document does not alter the Encypher C2PA Certificate Policy (docs/ca/certificate-policy.md, v2.1), the Encypher C2PA Certification Practice Statement (docs/ca/certification-practice-statement.md, v2.1) or the Encypher C2PA Certificate Subscriber Agreement (docs/ca/subscriber-agreement.md, v1.4). Those documents continue to govern the C2PA claim-signing and timestamp hierarchies.
• The two hierarchies are separate. A certificate issued under this policy MUST NOT sign the outer C2PA claim. C2PA claim-signing trust MUST NOT confer CAWG identity trust, and a C2PA certificate MUST NOT enter a CAWG trust configuration because Encypher issued it (enterprise_api/docs/CAWG_IDENTITY_KMS.md).

Section 3.2 uses the subsection numbering of the CA/Browser Forum Baseline Requirements for S/MIME certificates (S/MIME BR), which inserts mailbox validation at 3.2.2. That keeps references such as "3.2.3" and "3.2.6" aligned with the S/MIME BR rules Encypher adopts. Every other section follows RFC 3647 numbering.

Relationship to the S/MIME BR. Encypher adopts the organization-validation rules of S/MIME BR sections 3.2.3, 3.2.6 and 4.2.1 as its own policy (PRD D1). Encypher does not issue S/MIME certificates under this policy, does not claim conformance to the S/MIME BR, and has no WebTrust or other external audit (Section 8).

Relationship to the IPTC Verified News Publisher program. This policy meets three of the four IPTC requirements: the certificate O equals the exact registered legal name; the organization is registered and current in a supported jurisdiction; certificates last at most one year and the subscriber has a duty to report changes (Section 9.6.3). The fourth requirement, an authorized officer whose authority is confirmed, is met in part: the automatic methods of Section 3.2.6 confirm that someone reachable through a channel that a registry or a public CA vouches for approved the request; they do not confirm that the person holds an officer post. Exception review MAY require officer evidence.

1.2 Document Name and Identification

• Title: Encypher CAWG Organizational Identity Certificate Policy and Certification Practice Statement
• Version: 1.0.1
• Policy OID: 1.3.6.1.4.1.67057.1.1, allocated under Encypher's IANA Private Enterprise Number 67057 (assigned 2026-10-03 to Encypher Corporation; registry: https://www.iana.org/assignments/enterprise-numbers/). The allocation is recorded in docs/ca/oid-allocations.md.
• Runtime setting: the policy OID is supplied to issuance through CAWG_IDENTITY_CP_OID. Production issuance MUST refuse to start while that setting is absent (PRD D1).

The policy OID sits under Encypher's IANA PEN rather than the UUID-derived arc 2.25.206386351481933665400977926149279815678, which keeps its existing TSA and clearance allocations (docs/ca/oid-allocations.md).

1.3 PKI Participants

1.3.1 Certification Authorities

Encypher Corporation operates the following hierarchy. All CA keys are P-384 keys generated and held in Google Cloud KMS at the HSM protection level (Section 6).

Encypher Organizational Identity Root CA 2026        (root, ceremony r2, 2026-07-27)
  +-- Encypher CAWG Organization Issuing CA 2026     (new; EKU id-kp-documentSigning)
        +-- organization leaves                      (EKU id-kp-documentSigning only)

• Encypher Organizational Identity Root CA 2026. Self-signed root, O=Encypher Corporation, serial 2901a912541609c0273f2aaeab76816ae73251ee, created in re-run ceremony r2 on 2026-07-27 and recorded in commit 9c81dc5e5 (enterprise_api/data/cawg_registry/anchors/encypher-corporation-identity-root-ca-2026.pem). Its key is used only in witnessed operations (Section 5.2.3). Profile: Section 7.1.2.
• Revoked earlier root certificate. An earlier certificate over the same root key, serial 392e0e9a3041733397513f08a9639cb4cb7bd284, misnamed the organization as O=Encypher Inc.. It was revoked on 2026-07-27 and is marked revoked in the Encypher Verified Organizations List (enterprise_api/data/cawg_registry/registry.json). It MUST NOT be configured as a trust anchor.
• Encypher CAWG Organization Issuing CA 2026. The only CA that issues certificates under this policy. It has its own HSM P-384 KMS key and its own CRL, and it is signed once by the root key in a witnessed operation (Section 5.2.3). Serial 42d16bd3dd374b72b252fb41aeb3d351eb4e2876, SHA-256 fingerprint 98b887bd26ca36452f570dbf894e2d4bdf95ef148bb591be401a41800a2aca76, signed on 2026-10-05. Profile: Section 7.1.3.
• Prior emailProtection issuing CA ("Encypher CAWG Identity Issuing CA 2026"). The S/MIME-profile issuer used before this policy. In every environment it is revocation-only: it issues nothing new, keeps publishing its CRL and answering OCSP until its own notAfter, and publishes a final CRL at that time (PRD D1). It is not a CA under this policy and is described only so relying parties can interpret its status responses (Section 7.1.6).
• Delegated OCSP responders. OCSP for issuing-CA status is answered by the root-authorized responder. OCSP for leaf status under the new issuing CA is described in Section 7.3.

1.3.2 Registration Authorities

Encypher performs all registration authority functions itself. There are two RA roles:

• Automated RA. A deterministic predicate, running as the machine principal urn:encypher:ca:ra:automated-cawg-org, evaluates every application against the evidence rules of Sections 3 and 4 and is the only RA that can move an application to issuance (Section 4.3).
• Human RA for exception review. A trained Encypher employee in the RA trusted role (Section 5.2.1) decides the exception cases listed in Section 3.2.3.6. The human RA never approves a certificate. Its only outputs are a manual registry record, a standing-representative record with method exception, or a refusal. The automated RA then evaluates the application with that evidence like any other.

No third party performs RA functions. The data sources and delivery subcontractors of Section 1.3.5 supply evidence or carry messages; they make no validation decision.

1.3.3 Subscribers

A Subscriber is a legal entity that appears in a registry accepted under Section 3.2.3.2 and holds an Encypher organization account. A Subscriber applies through an owner or administrator of that account (Section 4.1).

This version issues organization-level certificates only. Certificates for individuals, subsidiaries and brands are not issued under this policy: individual actors are out of scope, and subsidiary and brand issuance stays disabled in every environment until a later version migrates them to this profile (PRD D1, section 5).

1.3.4 Relying Parties

A Relying Party is any person or system that validates a CAWG identity assertion signed with a certificate issued under this policy. CAWG Identity 1.2 section 8.2.4 requires validators to accept id-kp-documentSigning (1.3.6.1.5.5.7.3.36). Whether a validator trusts this hierarchy depends on whether it configures the Encypher root as a CAWG trust anchor. At launch the trust program recorded in the launch approval artifact is encypher; Encypher does not claim IPTC or Mozilla acceptance (PRD D6).

1.3.5 Other Participants

1.4 Certificate Usage

1.4.1 Appropriate Certificate Uses

A leaf certificate issued under this policy MAY be used only to sign CAWG identity assertions (cawg.identity COSE_Sign1 signatures) that name the Subscriber as the named actor, through the Encypher signing path and under a signing grant (Section 4.4.1).

1.4.2 Prohibited Certificate Uses

A certificate issued under this policy MUST NOT be used:

• to sign an outer C2PA claim;
• for TLS client or server authentication;
• for S/MIME signing or encryption, or any email use;
• for code signing or time-stamping;
• for any document signing outside CAWG identity assertions;
• for any purpose after expiry or revocation.

1.5 Policy Administration

1.5.1 Organization Administering the Document

Encypher Corporation Legal address: 850 New Burton Road, Dover, DE 19904, USA Mailing address: 2093 Philadelphia Pike #6262, Claymont, DE 19703, USA

1.5.2 Contact Person

CA operations, ca@encypher.com. Revocation requests, key-handling reports and reports of unauthorized requests go to the same address (Section 4.9.3).

1.5.3 Person Determining CPS Suitability for the Policy

The Encypher owner who approves this document determines that the practices stated here satisfy the policy stated here. Because this document combines both, one approval covers both.

1.5.4 CP/CPS Approval Procedures

A version of this document comes into force only when the owner approves it and Encypher publishes it at the CPS location. The production launch approval artifact binds the approved version and its SHA-256 digest (enterprise_api/app/ca/cawg_launch_approval.py). Each new version gets a new version number. A change that alters a subscriber obligation also requires a new Subscriber Agreement version, and pending applications return to needs_info until an owner or administrator accepts it (Section 4.2.2).

1.6 Definitions and Acronyms

1.6.1 Definitions

• Actor. The Encypher record that represents the Subscriber as a CAWG named actor. Each actor has its own KMS CryptoKey and exactly one active signing certificate at a time.
• Applicant. The organization on whose behalf an application is made.
• Applicant Representative. The authenticated Encypher dashboard user, an owner or administrator of the Applicant's account with recent multi-factor authentication, who requested the certificate. Every authority method confirms that this user may act for the Applicant (Section 3.2.6.1).
• Authorization Domain Name (ADN). The verified host pruned to its registrable domain using a Public Suffix List snapshot.
• Comparison normalizer. The single function Encypher uses for every name comparison (Section 3.1.4.1). It never sets a subject value.
• Entity key set. Every identifier a registry record can produce, in organizationIdentifier form, extended by one GLEIF cross-lookup (Section 3.2.3.3).
• Evidence packet. The immutable set of evidence an evaluation relied on, stored with its SHA-256 digest and bound to the issuance attempt.
• Exception review. Decision of an application by the human RA (Section 3.2.3.7, Section 3.2.6.4).
• Manual record. A registry record produced by exception review (provider='manual-ra').
• Provider record. A registry record fetched from an accepted registry provider.
• Registry record. A provider record or a manual record. The only source of subject values.
• Role addresses. admin@, administrator@, webmaster@, hostmaster@ and postmaster@ on the ADN (the set in TLS BR 3.2.2.4.4).
• Standing representative. The recorded result of a successful authority confirmation (Section 3.2.6.6).
• Standing renewal authorization. An optional authorization, given under the current Subscriber Agreement version, that lets Encypher submit a renewal application on the Subscriber's behalf (Section 4.6).
• Verified host. The exact host whose control the Applicant proved through the Encypher Auth service (Section 3.2.2).

1.6.2 Acronyms

ADN (Authorization Domain Name); BR (Baseline Requirements); CA (Certification Authority); CAWG (Creator Assertions Working Group); CRL (Certificate Revocation List); CSRF (Cross-Site Request Forgery); CSPRNG (cryptographically secure pseudo-random number generator); EKU (Extended Key Usage); EV (Extended Validation); HSM (Hardware Security Module); KMS (Key Management Service); KU (Key Usage); LEI (Legal Entity Identifier); OCSP (Online Certificate Status Protocol); OV (Organization Validated); DV (Domain Validated); PEN (Private Enterprise Number); RA (Registration Authority); SAN (Subject Alternative Name); TBS (to-be-signed certificate).

2. Publication and Repository Responsibilities

2.1 Repositories

Encypher operates the repository for this hierarchy. No third party operates it.

2.2 Publication of Certification Information

Encypher publishes:

The URLs above are the constants in packages/encypher-pki/src/encypher_pki/cawg_identity.py, the issuer settings and enterprise_api/data/cawg_registry/registry.json. Before production enablement Encypher confirms that each URL serves the production artifact (Launch Readiness gate 2.6).

2.3 Time or Frequency of Publication

• This CP/CPS: on approval of each version.
• CA certificates: on creation.
• CRLs: Section 4.9.7.
• OCSP: responses are generated on request and are valid for 24 hours (Section 7.3).

2.4 Access Controls on Repositories

Every published item is readable without authentication. Only Encypher CA operations can change repository content, through the authenticated publication path; CRLs are accepted for publication only when issuer-valid, signature-valid and not regressing in CRL number.

3. Identification and Authentication

3.1 Naming

3.1.1 Types of Names

Every certificate carries a non-empty X.501 Distinguished Name in the subject. A leaf subject contains exactly these attributes, in this order: countryName (C), organizationName (O), organizationIdentifier (2.5.4.97), commonName (CN). A leaf carries a Subject Alternative Name with exactly one uniformResourceIdentifier and no other name form.

3.1.2 Need for Names to be Meaningful

Every leaf subject value has one source, the registry record:

• O is the record's legal name, character for character, subject only to the abbreviation rule of Section 3.1.4.2.
• C is the record's jurisdiction country (ISO 3166-1 alpha-2). For an LEIXG- identifier, C is the entity's legal jurisdiction country while the identifier uses XG (S/MIME BR 7.1.4.2.2(d) Note 1).
• organizationIdentifier is built from the record under Section 7.1.5.
• CN equals O.
• The SAN URI is https://<verified host>.

No value typed by the Applicant, no account display name and no reviewer free text is ever written into a subject. A leaf carries no mailbox address, no street address, no locality, no state attribute, no serialNumber attribute and no personal name, so no S/MIME mailbox-control obligation arises.

3.1.3 Anonymity or Pseudonymity of Subscribers

Not permitted.

3.1.4 Rules for Interpreting Various Name Forms

3.1.4.1 Comparison Normalizer

Encypher uses one comparison normalizer for every name comparison in this policy: registry record against EV certificate, record against record, and application against record. The normalizer is used only to decide whether two names match. It never produces a subject value. Given a name, it:

1. applies Unicode full case folding;
2. replaces every run of whitespace with one space and removes leading and trailing whitespace;
3. replaces a legal-form designation found in the abbreviation table (Section 3.1.4.2) with its abbreviation, so that the long and short forms compare equal.

Two names match when their normalized forms are identical. No other transformation applies: punctuation, diacritics, "&" against "and", and word order remain significant.

Owner decision (approved 2026-10-03): the design source lists the three steps above and is silent on punctuation (for example "Ltd." against "Ltd"), Unicode compatibility normalization and where in a name a legal form may appear. The approved option is that punctuation and diacritics are significant, no compatibility normalization is applied, and step 3 applies only to a legal-form designation at the end of the name.

3.1.4.2 Legal-Form Abbreviation Table and the 64-Character Rule

X.520 limits organizationName and commonName to 64 characters. When a record's legal name is longer than 64 characters, Encypher replaces its legal-form designation using this table, which is the same table the normalizer uses:

The table entries apply to the native spelling recorded by the registry. This document is ASCII-only, so "beschraenkter" and "Societe" above are transliterations of the native spellings with a-umlaut and e-acute.

If the name is still longer than 64 characters after abbreviation, the application goes to exception review. Encypher never truncates a name.

Owner decision (approved 2026-10-03): the design source does not say what exception review may do with a name that still exceeds 64 characters. The approved option is that the reviewer MUST refuse the application, because the reviewer cannot set a subject value that differs from the registry record.

3.1.5 Uniqueness of Names

The organizationIdentifier, together with the entity key set behind it, identifies one legal entity. An entity key MAY be held by at most one tenant at a time (Section 3.2.6.7). Two different legal entities with the same legal name receive certificates that differ in organizationIdentifier and, where jurisdictions differ, in C.

3.1.6 Recognition, Authentication, and Role of Trademarks

Encypher does not adjudicate trademark rights. The registered legal name governs. A trademark or brand name is never placed in a certificate under this policy.

3.2 Initial Identity Validation

3.2.1 Method to Prove Possession of Private Key

Encypher generates each actor key itself, inside the Google Cloud KMS HSM boundary, under Encypher's exclusive service-account control. The key is non-exportable and the Subscriber never holds it. Possession is established by custody:

• when the actor is created, Encypher resolves the actor key's exact version through the KMS versions API, validates its purpose (asymmetric signing), algorithm (EC P-384 with SHA-384), protection level (HSM) and state (enabled), and persists that version on the actor;
• before issuance and before each signing activation, Encypher reads the public key of that exact version and confirms it equals the public key in the TBS certificate or the issued certificate.

Encypher never reads CryptoKey.primary to select a version.

3.2.2 Validation of Domain Control

A leaf carries no mailbox address, so S/MIME BR mailbox-control validation does not apply. Encypher instead requires control of the host named in the SAN URI:

• Domain control is mandatory for every application. No path bypasses it.
• Control is proven through the Encypher Auth service by a DNS TXT record or an HTTPS .well-known token, and the .well-known fetch runs through Encypher's safe-fetch boundary.
• At every evaluation, Encypher asks Auth to re-run the claim's check at that moment (POST /api/v1/organizations/internal/{org_id}/domain-claims/{claim_id}/revalidate, audience auth_service.domain_claim.revalidate) and stores the returned method, validation time, evidence digest, claim and host in the evidence packet.
• Legacy CDN domain claims do not count.
• A removed, reassigned or unrevalidatable claim returns the application to awaiting_domain. An Auth outage is retried and is never a denial.

Domain control proves control of the host. It does not prove organization identity or authority.

3.2.3 Authentication of Organization Identity

3.2.3.1 Registry Records

Every subject value comes from a registry record: a provider record fetched from a source in Section 3.2.3.2, or a manual record produced by exception review (Section 3.2.3.7). The Applicant Representative picks the record from search results. Encypher never selects the top search result automatically. Registry search is rate-limited per tenant and per user, and responses are cached for at most 10 minutes; a cached search result is used only to display choices and never as verification evidence.

A provider record stores the entity key set, legal name, country, subdivision, register scheme and number, status, registered address with any dispute or undeliverable flags, source URL, raw response bytes, their SHA-256 digest, the fetch time and the provider.

3.2.3.2 Accepted Sources and Status Rules

Owner decision (approved 2026-10-03): the design source does not list which Companies House statuses other than active are acceptable. The approved option accepts only active; every other status (for example dissolved, liquidation, administration, receivership, voluntary-arrangement, insolvency-proceedings) is not verifying evidence and returns the application to awaiting_registry with the reason.

OpenCorporates is not a source. Encypher rejected it for cost, for a revocable licence that conflicts with evidence retention, and because some of its data is not from government sources. No source not listed in this table is accepted.

3.2.3.3 Entity Key Set and GLEIF Cross-Lookup

A record yields a canonical entity key set: every identifier it can produce (NTR<country>[+<subdivision>]-<number> from a national record, LEIXG-<LEI> from an LEI), extended by one cross-lookup:

• a Companies House record queries GLEIF by registeredAs and jurisdiction for an LEI;
• a GLEIF record adds the national key derived through the register-mapping whitelist.

A manual record carries the identifiers the reviewer verified. Two records describe the same organization when their entity key sets intersect. The cross-lookup runs when the record is picked and, after an outage, on its own retry schedule; its result, including "no LEI", is recorded in the evidence packet. Evaluation reads the recorded result and never runs the cross-lookup itself.

3.2.3.4 Freshness

At every evaluation, including renewals, Encypher re-fetches a provider record from its source and verifies it again. A provider outage leaves the application unchanged with a retry time; an unavailable source is never treated as verified. A record that has changed so that it contradicts the evidence (for example the picked company is now dissolved, or its number changed) returns the application to awaiting_registry with the reason.

3.2.3.5 Subject Construction

Encypher builds the subject from the verified record under Section 3.1.2, the abbreviation rule of Section 3.1.4.2 and the identifier grammar of Section 7.1.5. The pre-issuance lint (Section 7.1.7) rejects any subject value whose source is not the record.

3.2.3.6 Exception Conditions

An application goes to exception review when:

• the registry flags the registered address as disputed or undeliverable;
• the legal name exceeds 64 characters after abbreviation;
• the record's register is not in the register-mapping whitelist and the entity has no accepted LEI;
• no supported provider covers the entity (including every US entity without an accepted LEI);
• the entity keys intersect an active key held by another tenant (Section 3.2.6.7);
• the Applicant asks for exception review of authority (Section 3.2.6.4);
• a superseding issuance attempt budget is exhausted (Section 4.3.1).

3.2.3.7 Manual Records from Exception Review

The human RA MAY produce a manual record carrying the legal name, jurisdiction, register number, identifier, registered address, the SHA-256 digest of the accepted legal-entity evidence, and the reviewer principal. The reviewer MUST NOT be a member of the Applicant's tenant. The legal name, identifier and registered address in a manual record MUST be the values shown by the official register; the identifier MUST satisfy the grammar of Section 7.1.5. The registered address is where an authority letter (Section 3.2.6.3) is sent, so it MUST never come from a document or form supplied by the Applicant.

Accepted legal-existence evidence. The reviewer MUST confirm the entity's existence and current good standing with the official register itself, by one of: (a) the register's official online record, captured with its retrieval time; or (b) a certificate of good standing, or the jurisdiction's equivalent certificate of status, issued by the register no more than 90 days before the review, whose authenticity the reviewer confirms with the issuing register (for Delaware, the Division of Corporations validation service at https://corp.delaware.gov/authver, using the entity file number and the certificate's authentication number) and whose entity details match the register's online record. Articles of incorporation and other formation documents show only that the entity was formed; they MUST NOT be accepted as evidence of current existence, and no document supplied only by the Applicant is sufficient without confirmation from the register.

3.2.4 Authentication of Individual Identity

Not performed for organization certificates. No personal identity check is required, because no personal name or personal attribute appears in the certificate. Personal identity validation remains required for individual actors, which are outside this policy.

3.2.5 Non-Verified Subscriber Information

None. Every certificate field is verified or set by Encypher under this policy.

3.2.6 Validation of Authority

3.2.6.1 Applicant Representative

The Applicant Representative is always the authenticated Encypher dashboard user who requested the certificate: an owner or administrator of the Applicant's organization account, with recent multi-factor authentication under require_verified_identity_mutation. An authority method confirms that this specific user may act for the Applicant. A confirmation for one user never authorizes another user.

A registry officer list combined with a mailbox on the Applicant's own verified domain does not prove authority (S/MIME BR 1.6.1, 3.2.6). OV and DV TLS certificates never qualify as authority evidence: their C may be inferred from IP, ccTLD or registrar data and their O may be a common variation (TLS BR 3.2.2.3, 7.1.4.2.2), so a same-name entity in another country can hold a matching OV certificate.

Encypher accepts three methods.

3.2.6.2 Method 1: EV-Linked Domain

1. Encypher opens a TLS connection to the verified host through the safe-fetch boundary (validated-IP pinning, SNI, connect and read deadlines, a size cap) and captures the presented certificate chain. Intermediates missing from the handshake are not fetched.
2. The chain MUST validate for the exact host against the Mozilla TLS root store as shipped by certifi, MUST be current, MUST be unrevoked (CRL distribution point fetched through safe-fetch; OCSP when present) and MUST be EV (policy 2.23.140.1.1). The chain and the revocation responses are stored as evidence.
3. The EV subject serialNumber MUST equal the record's national registration number under the whitelisted register mapping, and jurisdictionCountryName, plus jurisdictionStateOrProvinceName mapped through an ISO 3166-2 table when the register is subnational, MUST equal the record's jurisdiction. Comparison uses the normalizer of Section 3.1.4.1.
4. The EV certificate MUST also cover the ADN.
5. The link establishes only the channel. Encypher then sends an approval email to each role address on the ADN. The email names the organization, the requesting user and exactly what approval grants. The link opens a page that shows the organization, the requester and the scope; approving or declining is an explicit POST with CSRF protection and is never a GET, so a mail scanner that prefetches links changes nothing. The approval token is valid for 24 hours.

A missing, non-EV, mismatching or unreachable certificate is not a denial. The application stays in awaiting_authority and the letter method is offered.

3.2.6.3 Method 2: Registered-Office Letter

1. Encypher posts a one-time code to the registered office in the verified record. The address is never one the Applicant types. An address the registry flags as disputed or undeliverable sends the application to exception review.
2. The letter names the organization, the requesting user, what entering the code authorizes, and how to decline or report abuse.
3. Lob prints and mails the letter as Encypher's subcontractor (Section 9.6.5). Lob prints in the United States and sends international letters by USPS First Class. Expected delivery is 3 to 7 business days in the US (up to 10 where a registered agent forwards mail) and 8 to 14 business days for the UK and other non-US addresses.
4. Entering the correct code confirms authority. A delivery callback from Lob is evidence of delivery only and never of authority.

Owner decision (approved 2026-10-03): the design source says the letter names "the requesting user" without saying which attributes. The approved option is the user's name as recorded in the Encypher account, without the email address.

3.2.6.4 Method 3: Exception Review

Any other evidence of authority is decided by the human RA in the review queue. Examples are an IPTC credential, a letter from an attorney or accountant, or evidence that the requester holds an officer post. A lookup in a public list never confirms authority by itself. The reviewer's output is a standing-representative record with method exception and its evidence, which the automated RA consumes. The reviewer never approves a certificate.

Owner decision (approved 2026-10-03): the design source does not set acceptance rules for professional letters. The approved option is that the reviewer MUST verify the author's professional licence with the issuing body and MUST confirm the letter by a contact channel the reviewer finds independently of the Applicant.

3.2.6.5 Challenge Contract

Letter codes and approval tokens follow one contract:

• generated from CSPRNG output; letter codes are 10 characters of Crockford base32 (50 bits); approval tokens are 32 bytes;
• stored only as HMAC-SHA256 under CAWG_AUTHORITY_CODE_KEY, with the key id recorded per challenge so that key rotation does not invalidate outstanding challenges;
• compared in constant time and usable once;
• bound to the tenant, the application revision, the registry record digest, the address or domain digest, and the requesting user;
• a letter code expires after 45 days and locks after 5 failed attempts; the attempt counter is decremented atomically under the application row lock;
• issuing a replacement invalidates the previous challenge; after expiry or lock, a resend is available after a 24-hour cooldown, or the Applicant may switch method;
• aggregate send and attempt limits apply per organization, per user and per IP address;
• each send carries a provider idempotency key;
• a code or token never appears in an API response, log, analytics event or preview.

3.2.6.6 Standing Representative

A successful confirmation creates a standing representative that records the user, the method and the evidence. It is valid for up to 825 days from confirmation (S/MIME BR 4.2.1) and claims the organization's entity keys in the active-entity-key table, which the representative references.

A standing representative ends when:

• the organization withdraws it;
• a role-address recipient or the registered office explicitly declines;
• the registry record's status, name or number changes;
• the user stops being an owner or administrator, is disabled, or loses an active membership;
• 825 days have passed since confirmation, or a certificate it supported is revoked actor-wide for a trust-breaking reason (Section 4.9.1.1), which also sends any open or later application for those entity keys to exception review.

Encypher checks role, user status and membership live through get_organization_membership_authorization at every evaluation, renewals included, and again after the final re-lock before signing. When a representative ends for loss of role or membership, the signing grant created by the onboarding finish action (Section 4.4.1) ends with it, and the remaining owners are told which grants onboarding created. A renewal never extends a standing representative.

3.2.6.7 Cross-Tenant Claims

An entity key is unique across tenants in the active-entity-key table. A claim whose entity keys intersect an active key held by another tenant goes to exception review, and the representative of the tenant that holds the key is notified.

3.2.6.8 Residual Risk

The automatic methods prove control of a channel that a registry or a public CA vouches for. They do not prove that the person who approved holds an office. Anyone inside the Applicant who can read a role mailbox on the ADN, or who receives post at the registered office, can approve a request made by an owner or administrator of the Applicant's Encypher account. Encypher accepts this risk and limits it by: requiring the approver to act through an explicit POST or a single-use code; naming the requesting user and the scope in every approval email and letter; giving every recipient a decline and abuse-report path, which ends the standing representative and triggers revocation (Section 4.9.1.1); and allowing at most one tenant to hold an entity key.

3.2.7 Criteria for Interoperation

None. Encypher does not cross-certify with any other CA. Each validator decides whether to trust the Encypher root for CAWG identity.

3.2.8 Reliability of Verification Sources

• GLEIF records are accepted only at FULLY_CORROBORATED, where the LEI issuer has checked the record against an authoritative source.
• Companies House is the statutory UK register.
• EV evidence relies on publicly trusted TLS CAs as represented by the Mozilla root store shipped by certifi, and only on the EV policy, whose subject fields are validated against government registers.
• Manual records rely on the official registers the human RA consults under Section 3.2.3.7.

3.3 Identification and Authentication for Re-key Requests

3.3.1 Routine Re-key

Re-key happens only through a new actor (Section 4.7), which requires the full validation of Section 3.2.

3.3.2 Re-key After Revocation

An application after an actor-wide revocation (Section 4.9.1.1) creates a new actor with its own CryptoKey and requires the full validation of Section 3.2. The superseded revocation of a replaced predecessor (Section 4.8) does not end the actor.

Renewal with the same key is covered in Section 4.6. It requires a complete evaluation, as in Section 4.3.

3.4 Identification and Authentication for Revocation Requests

Encypher accepts a revocation request from:

• an authenticated owner or administrator of the Subscriber's organization account, through the dashboard or API;
• any person by email to ca@encypher.com. Encypher acts on such a request after confirming it through the Subscriber's account contacts or after finding a revocation reason under Section 4.9.1 on its own investigation.

A decline or abuse report through the approval page or the letter's decline path is authenticated by the channel itself (Section 4.9.1.1).

4. Certificate Life-Cycle Operational Requirements

4.1 Certificate Application

4.1.1 Who Can Submit a Certificate Application

An owner or administrator of the Applicant's Encypher organization account, with recent multi-factor authentication. Encypher MAY also submit a renewal application on the Subscriber's behalf under a standing renewal authorization (Section 4.6).

4.1.2 Enrollment Process and Responsibilities

Submission requires an active entitlement and acceptance of the current version of the Encypher CAWG Organizational Identity Subscriber Agreement (version 1.0 at https://encypher.com/trust/documents/cawg-subscriber-agreement). The acceptance record binds the agreement version and its SHA-256. The agreement includes the duty to report changes (Section 9.6.3) and the optional standing renewal authorization.

Each organization MAY have at most one non-terminal application at a time. A draft application never advances except by submit.

4.2 Certificate Application Processing

4.2.1 Performing Identification and Authentication Functions

Encypher re-uses evidence only within these limits:

Owner decision (approved 2026-10-03): the design source does not say whether a renewal re-runs the GLEIF cross-lookup. The approved option is that a renewal application re-runs it when the renewal is submitted, before evaluation.

4.2.2 Approval or Rejection of Certificate Applications

The automated RA moves each application through these states: draft, awaiting_registry, awaiting_domain, awaiting_authority, in_review (exception review), needs_info, issuing, reconciling, issued, rejected.

• After submit, the application waits in the first unmet state among awaiting_registry, awaiting_domain and awaiting_authority, and is evaluated once all evidence is present.
• Missing evidence returns it to the matching awaiting_* state.
• A provider, GLEIF cross-lookup or Auth outage leaves it unchanged with an exponential-backoff retry time. An outage is never a denial.
• An exception condition (Section 3.2.3.6) moves it to in_review.
• An ended entitlement or a changed agreement version moves it to needs_info, which resumes when the entitlement returns or an owner or administrator accepts the new version.
• Only a human RA refusal in exception review moves an application to rejected.

Every write that can change readiness records a due retry time in the same transaction as its evidence, so that a crash after commit leaves due work that the periodic sweep picks up. An application in awaiting_domain also re-reads Auth's verified-domain projection on a capped backoff from 15 minutes to 6 hours.

4.2.3 Time to Process Certificate Applications

Encypher sets no processing deadline. An application whose evidence is complete is evaluated without human action. Expected end-to-end times are: the same session for Method 1; the letter delivery times of Section 3.2.6.3 for Method 2; no committed time for exception review.

4.2.4 Certification Authority Authorization (CAA)

Encypher does not check DNS CAA records for certificates under this policy. RFC 8659 defines the issue and issuewild properties, which govern TLS server certificates. RFC 9495 defines the issuemail property, which governs certificates with id-kp-emailProtection. Neither applies to an id-kp-documentSigning certificate, and no CAA property for document-signing certificates exists.

4.3 Certificate Issuance

4.3.1 CA Actions During Certificate Issuance

Evaluation runs in two stages, then the automated RA decides.

Stage one holds a row lock on the application and makes only internal calls. It checks:

1. the entitlement is active;
2. the current Subscriber Agreement version is accepted;
3. a current standing representative exists for these entity keys and this user, and the user's role, status and membership pass the live check;
4. no entity key intersects an active key held by another tenant, using the recorded cross-lookup result.

Stage one records the application revision and retry time and releases the lock. The fetch stage then runs without the lock: it re-fetches and verifies the provider record (or confirms that a manual record's evidence is at most 825 days old) and asks Auth to revalidate the domain.

Encypher then re-locks the application and proceeds only if the revision and retry time are unchanged. It re-reads the standing representative and the membership result, so that a withdrawal or demotion during the fetch stage is caught before signing. The automated RA predicate then decides. It requires a clean pre-issuance lint (Section 7.1.7).

Issuance additionally requires:

• the policy OID configured in CAWG_IDENTITY_CP_OID (production refuses to start without it);
• a valid production launch approval artifact that lists the new issuing CA's fingerprint for this profile and records the witnessed issuing-CA operation (Section 5.2.3);
• the actor's persisted KMS key version, validated under Section 3.2.1.

The issuance service then:

• reserves the serial number and writes an outcome journal entry;
• takes a fenced lease on the attempt; the sweep acts on an issuing attempt only after its lease expires, so it never races a live KMS call;
• binds the attempt to the tenant, application revision, actor, exact KMS key version, issuer and profile, evidence-packet digest and TBS digest;
• signs the TBS certificate with the issuing CA key in Cloud KMS;
• re-evaluates every predicate after KMS returns and before activation.

Outcomes:

• All predicates hold after signing: the certificate is recorded and the application becomes issued.
• A predicate fails after signing: the serial is blocked, the attempt counts against the retry budget, and the application returns to the matching awaiting_* state. A blocked serial is published in the next CRL.
• The KMS outcome is unknown or the lease expires: the attempt enters reconciling. A duplicate delivery returns the recorded result or enters reconciling; it never signs again.
• A signed_unrecorded attempt MAY be abandoned by the machine principal only after its serial appears in a published CRL. A superseding attempt with a new serial follows, at most 3 per application; after that the application goes to in_review.

A human RA can never cause a signature directly. Its outputs re-enter this same evaluation.

4.3.2 Notification to Subscriber by the CA of Issuance of Certificate

Encypher notifies the organization's owners and administrators by email and in the dashboard. The notice states that the certificate is issued and what to do next; it does not state that signing is enabled, because a certificate is not a signing grant (Section 4.4.1).

4.4 Certificate Acceptance

4.4.1 Conduct Constituting Certificate Acceptance

Issuance makes the certificate available to the actor; it does not enable signing. The onboarding finish screen offers one confirmed action that creates, through the existing grant service and audit events, a signing grant for the Applicant Representative with role cawg.publisher, no asset, product or domain restriction, no expiry date, and provenance onboarding_representative. At signing time, a grant with that provenance additionally requires the user to be an owner or administrator; on the first failure Encypher ends the grant and notifies the owners. Other users, roles and deadlines are added through the grant interface. Signing always requires an active certificate on the actor.

The Subscriber MUST review each new certificate and report any error to ca@encypher.com within 7 days of issuance.

4.4.2 Publication of the Certificate by the CA

Encypher does not publish leaf certificates in a directory. If the Subscriber opted in, Encypher adds the organization to the Encypher Verified Organizations List when the certificate is activated.

4.4.3 Notification of Certificate Issuance by the CA to Other Entities

None.

4.5 Key Pair and Certificate Usage

4.5.1 Subscriber Private Key and Certificate Usage

The actor private key stays in the Encypher HSM. Encypher uses it only to compute CAWG identity signatures requested by a principal holding a valid signing grant for that actor, under Section 1.4.1. The Subscriber controls use of the key through its grants and MUST keep them limited to people and systems it authorizes.

4.5.2 Relying Party Public Key and Certificate Usage

A Relying Party SHOULD:

• build a path to a CAWG trust anchor it has chosen to configure;
• require id-kp-documentSigning (1.3.6.1.5.5.7.3.36) in the leaf;
• check revocation status through the CRL or OCSP locations in the certificate;
• evaluate validity at the time proved by the assertion's RFC 3161 timestamp;
• treat the certificate as a statement about the organization's identity, not about the accuracy or lawfulness of any signed content.

4.6 Certificate Renewal

Renewal issues a new certificate over the same actor key version.

• When. A periodic sweep finds every active, unrevoked organization certificate within 30 days of its notAfter that has no open renewal. If the Subscriber gave a standing renewal authorization under the current agreement version and its standing representative is current (with the live owner or administrator check), Encypher submits the renewal application. Otherwise Encypher sends the owners one notice per certificate and an owner or administrator submits.
• Stalls. If a system-submitted renewal leaves the path to issuance (needs_info, any awaiting_*, or in_review), Encypher notifies the owners with the next action, and again 7 days before notAfter if it is still unresolved.
• Validation. A renewal is evaluated like a new application (Section 4.3): the registry record is re-fetched, the domain is revalidated, and a current standing representative is required. A renewal never extends a standing representative.
• Same actor, same key. When the entity keys are unchanged, the renewal keeps the same actor, its grants and its persisted KMS key version. Encypher switches the actor's active signing certificate to the new certificate atomically, so a failed or stalled renewal leaves the still-valid certificate untouched. Grant deadlines set by people are left as they are.
• After expiry. A renewal MAY also be submitted after a plain expiry, while the actor has not been ended (Section 4.9.1.1).
• Changed entity keys create a new actor, which suspends the prior actor's grants.

4.7 Certificate Re-key

A certificate over a new key is issued only to a new actor, with its own CryptoKey, after the full validation of Section 3.2. This happens after any actor-wide revocation (Section 4.9.1.1) and whenever the entity keys change; the superseded revocation of a replaced predecessor (Section 4.8) does not end the actor. This policy sets no maximum operational period for an actor key version beyond the life of its actor.

Owner decision (approved 2026-10-03): whether to cap the lifetime of an actor key version, for example at the 825-day authority window. Design source draft 7 removed per-renewal key rotation because it broke the active key binding during renewal; a cap therefore needs a rotation design before it can be adopted. The approved option is no cap, as stated.

4.8 Certificate Modification

When the registered legal name changes but the entity keys do not, the next issuance on the actor (a renewal under Section 4.6, which the Subscriber MAY submit at once) carries the new O and CN, and the actor's legal name is updated. The certificate with the old name becomes inaccurate and is revoked within the period of Section 4.9.1.1. If the replacement is already active on the same actor, the old certificate alone is revoked with reason superseded. Otherwise the revocation is actor-wide (Section 4.9.1.1) and the replacement is issued to a new actor.

4.9 Certificate Revocation and Suspension

4.9.1 Circumstances for Revocation

4.9.1.1 Reasons for Revoking a Subscriber Certificate

Encypher revokes a leaf certificate within 24 hours after it learns that:

1. the Subscriber requests revocation;
2. the Subscriber, a role-address recipient or the registered office explicitly declines, or reports that the original request was not authorized;
3. the actor key, or any key or credential that controls its use, has been compromised or handled out of policy (Section 6.2.11), including on notification from the Subscriber, a third party or Encypher's own monitoring;
4. the authority or registry evidence the issuance relied on cannot be relied upon (for example forged evidence in exception review).

Encypher revokes a leaf certificate within 5 days after it learns that:

5. the registry record's status is no longer accepted under Section 3.2.3.2 (for example the entity is dissolved or struck off);
6. the registry record's legal name has changed (Section 4.8), or its registration number has changed;
7. the Subscriber no longer controls the host in the SAN URI;
8. the certificate does not conform to Section 7.1, or was otherwise issued in breach of this document;
9. the Subscriber has breached the Subscriber Agreement or this document, or has misused the certificate;
10. Encypher ceases operating this hierarchy without arranging continued status services.

Owner decision (approved 2026-10-03): the design source names these triggers but not their deadlines. The approved option adopts as Encypher policy the 24-hour and 5-day leaf deadlines of S/MIME BR 4.9.1.1, the 7-day issuing CA deadline of S/MIME BR 4.9.1.2 (Section 4.9.1.2) and the 24-hour preliminary response of S/MIME BR 4.9.5 (Section 4.9.3), and treats a decline received after issuance as a 24-hour trigger. A Subscriber whose certificate is revoked after a disputed decline MAY re-apply through exception review.

Owner decision (approved 2026-10-03): the design source defines no periodic post-issuance re-check of registry records or domains; Encypher learns of reasons 5 to 7 from Subscriber reports (Section 9.6.3), renewal evaluations and third-party reports. The approved option adds no periodic re-check in this version; the owner may require one.

The end of a standing representative for loss of the user's role or membership does not by itself revoke the certificate, because the certificate identifies the organization and not the user. It ends the onboarding signing grant (Section 3.2.6.6). Scope of a leaf revocation: under reason 6, when the replacement for a legal-name change is already active on the same actor, only the old certificate is revoked, with reason superseded (Section 4.8). Every other revocation under this section is actor-wide: Encypher revokes every unexpired certificate over the actor's key version, committing every revocation and attempt block in one transaction and then publishing each affected issuer's CRL, retrying any publication that fails; it blocks every unresolved issuance attempt on that key, ends the actor and disables the key version (Section 4.11). When the reason is trust-breaking (reason 2, 4 or 9, or reason 3 when the compromised credential is the representative's own account), Encypher also ends every standing representative for those entity keys and invalidates every manual record the revoked certificates relied on, so any open or later application for those entity keys goes to exception review. An open application whose actor was ended for any other reason continues on a new actor.

4.9.1.2 Reasons for Revoking an Issuing CA Certificate

Encypher revokes the issuing CA certificate, through a root CRL signed in a witnessed operation, within 7 days after it learns that the issuing CA key is compromised or was handled out of policy, that the issuing CA certificate was issued in breach of this document, or that Encypher is terminating the hierarchy. On revocation of the issuing CA, Encypher also revokes every unexpired leaf it issued.

4.9.2 Who Can Request Revocation

• An owner or administrator of the Subscriber's organization account.
• A role-address recipient or the registered office, through the decline path of the approval page or letter.
• Encypher CA operations.
• Any person who reports key compromise, misuse or inaccurate certificate content to ca@encypher.com. Encypher investigates every such report.

4.9.3 Procedure for Revocation Request

Subscribers revoke through the dashboard or API, or by email to ca@encypher.com. Encypher commits the status, reason and time to the CA database, updates OCSP, and publishes a new CRL within the period in Section 4.9.7. Encypher acknowledges every report sent to ca@encypher.com and begins investigation within 24 hours.

4.9.4 Revocation Request Grace Period

None.

4.9.5 Time Within Which CA Must Process the Revocation Request

The periods stated in Section 4.9.1.

4.9.6 Revocation Checking Requirement for Relying Parties

Relying parties SHOULD check status through the CRL or OCSP locations in each certificate (Section 4.5.2).

4.9.7 CRL Issuance Frequency

• New issuing CA CRL: at least every 7 days with nextUpdate no more than 10 days after thisUpdate, and within 24 hours after any revocation or serial block.
• Prior emailProtection issuing CA CRL: the same cadence until that CA's notAfter, then one final CRL.
• Root CA CRL: at least annually with nextUpdate no more than 400 days after thisUpdate, and within 24 hours after revocation of an issuing CA certificate. Every root CRL is signed in a witnessed operation (Section 5.2.3).

These values match the publication constants in enterprise_api/app/ca/crl_service.py and enterprise_api/app/ca/crl_publisher.py.

Owner decision (approved 2026-10-03): every use of the root key, including the routine annual root CRL, follows Section 5.2.3: the CA operator performs it and an independent reviewer attests to it afterwards from the durable evidence.

4.9.8 Maximum Latency for CRLs

Encypher publishes each CRL immediately after generation. CRL numbers are allocated monotonically per issuer, and the repository accepts only non-regressing, signature-valid, unexpired CRLs.

4.9.9 On-Line Revocation/Status Checking Availability

Encypher provides OCSP under RFC 6960 at http://identity-ca.encypher.com/ocsp for every configured issuer: leaf status under each issuing CA, and issuing CA status under the root (Section 7.3).

4.9.10 On-Line Revocation Checking Requirements

None beyond Section 4.9.6.

4.9.11 Other Forms of Revocation Advertisements Available

None.

4.9.12 Special Requirements Related to Key Compromise

Compromise or out-of-policy handling of an actor key is an actor-wide revocation under Section 4.9.1.1; any new certificate is issued to a new actor with a new CryptoKey. Compromise of the representative's own account is also trust-breaking under that section.

4.9.13 Circumstances for Suspension

Suspension is not supported. Sections 4.9.14 to 4.9.16 do not apply.

4.10 Certificate Status Services

4.10.1 Operational Characteristics

CRLs and OCSP responses are publicly available without authentication. A revoked serial is never removed from a CRL before the certificate's notAfter.

4.10.2 Service Availability

Encypher operates status services continuously and treats an outage as an incident. Encypher MAY serve the last valid CRL during a publication outage only until its nextUpdate.

4.10.3 Optional Features

None.

4.11 End of Subscription

A subscription ends when the last certificate of the Subscriber's actor expires without renewal or is revoked. After any actor-wide revocation (Section 4.9.1.1), Encypher disables the actor key version in KMS. A superseded revocation of a replaced predecessor (Section 4.8) leaves the key enabled for the replacement certificate. After a plain expiry, the key version stays enabled so that a renewal can use it (Section 4.6); the signing path refuses to sign with it while the actor has no active certificate. Encypher MAY schedule destruction of a disabled key version.

4.12 Key Escrow and Recovery

Not supported. Private keys are non-exportable and are never escrowed.

5. Facility, Management, and Operational Controls

5.1 Physical Controls

Encypher operates no physical CA facility. Every CA and actor private key is generated, held and used inside Google Cloud KMS at the HSM protection level (FIPS 140-2 Level 3), whose physical controls Google operates. The CAWG hierarchy uses a Google Cloud project or key ring that no C2PA signing service can access (enterprise_api/docs/CAWG_IDENTITY_KMS.md).

5.2 Procedural Controls

5.2.1 Trusted Roles

• CA operator: runs CA operations, including root-key operations.
• Registration authority (RA): performs exception review. The RA has no part in CA key operations.
• Independent reviewer (witness): a person who did not control the operator's actions; reviews the evidence of a root-key operation and signs the witness attestation.
• KMS administrator: manages KMS key rings, keys and IAM bindings.

5.2.2 Separation of Duties

• A root-key operation is performed by the CA operator and attested by an independent reviewer who is not the operator. The production launch approval check refuses a ceremony without an independent review by a person other than the operator, dated after the ceremony, bound to the signed attestation by its SHA-256 (enterprise_api/app/ca/cawg_launch_approval.py). Observers and a session recording MAY be added and are then recorded.
• A human RA MUST NOT review an application from a tenant of which that RA is a member.
• The runtime signing principal has no permission to use the root key.

5.2.3 Witnessed CA Operations

Every use of the root key follows the evidence model Encypher used for its C2PA CA ceremony (C2PA Certificate Policy, Section 6.1.1: a defined ceremony script; HSM keys; participant sign-off; deviations noted; witnessed by an independent party and/or recorded). The CA operator performs the operation from the published runbook. An independent reviewer, who did not control the operator's actions, then reviews the durable evidence and signs a witness attestation. The Cloud KMS Data Access audit log is the control that makes this review meaningful: it records every signature made with the root key, so the reviewer confirms that the root key signed exactly the certificates in the ceremony records and nothing else. The operation that signs the new issuing CA certificate proceeds as follows:

1. The CA operator prepares the TBS certificate locally from the issuing CA profile (Section 7.1.3) and the new issuing CA key's public key read from KMS.
2. The operation is first rehearsed: the TBS is prepared read-only from the production public keys and reviewed, and the full signing path is exercised against software keys in the ceremony test suite. When the staging hierarchy is available, the operation is also run as a dry run against staging keys.
3. In production, the operator confirms the TBS content and the root key version against the prepared values, with Cloud KMS Data Access audit logging enabled for the key ring.
4. The TBS certificate is signed once with the root KMS key version.
5. The operator verifies the signature and the profile, and computes the certificate's serial and SHA-256 fingerprint.
6. The signed ceremony record (schema encypher.cawg-issuing-ca-signing.v1, whose SHA-256 the launch approval binds) captures the operator and the operator's sign-off that the runbook was followed, any observers and session recording digest, any deviations, timestamps, KMS key version names, the TBS digest, the certificate serial and fingerprint, and the per-environment count of certificates and attempts under the prior issuer.
7. After the session, the operator exports the Cloud KMS audit log entries for the root key over the session window. The independent reviewer reviews the runbook, the ceremony records, the certificates and their lint results, the KMS key-version evidence and the audit log excerpt, and signs the witness attestation; its SHA-256 is bound into the launch approval.

Production enablement fails by design without this record and the signed attestation. The operation was performed on 2026-10-05 between 02:37:59 and 02:42:41 UTC (ceremony records cawg_issuing_ca_20261005_024130_19c5d3b7 for the issuing CA and cawg_root_ocsp_20261005_024231_a091d923 for the root-authorized OCSP responder); the Cloud KMS audit log for that window shows exactly two root-key signatures, one per record. The launch approval binds the issuing CA record and the signed attestation of the independent review.

5.3 Personnel Controls

Trusted roles are held only by Encypher employees or contractors whom Encypher has authorized for the role. Background checks follow Encypher's standard hiring practice. A human RA MUST complete training on Sections 3.2 and 4.9 of this document before deciding exception cases, and Encypher keeps a record of that training.

Owner decision (approved 2026-10-03): training content, refresher frequency and who certifies an RA are not defined in the design source. The approved option is annual retraining, certified by the owner.

5.4 Audit Logging Procedures

Encypher logs, with time, principal and outcome:

• application state changes and every automated RA decision, with the evidence-packet digest;
• registry fetches, cross-lookups and Auth revalidations (digests, not codes);
• challenge creation, send, attempt, lock, expiry, approval and decline events, never the code or token;
• Lob send requests and delivery events;
• human RA actions in exception review;
• issuance attempts, leases, KMS calls, serial reservations, blocks and supersessions;
• revocations, CRL generation and publication;
• grant creation and ending;
• KMS administrative and signing activity, through Google Cloud audit logs;
• witnessed operation records.

5.5 Records Archival

Encypher retains certificates, CRLs, CA operation records and audit logs for the life of the hierarchy plus 7 years, matching the Encypher C2PA CP.

Owner decision (approved 2026-10-03): retention of validation evidence (registry responses, EV chains, exception-review documents, challenge records). The design source assumes at least two years of evidence retention; S/MIME BR 5.5.2 uses 7 years. The approved option retains validation evidence for 7 years after the last certificate that relied on it expires or is revoked.

5.6 Key Changeover

The new issuing CA replaces the prior emailProtection issuing CA for all new issuance. The prior issuer keeps its CRL and OCSP until its own notAfter, then publishes a final CRL. A future issuing CA changeover follows Section 5.2.3 and runs both issuers in parallel until every leaf of the old issuer has expired or been revoked.

The authority code key (CAWG_AUTHORITY_CODE_KEY, Section 3.2.6.5) is rotated by installing a new key under a new key id (CAWG_AUTHORITY_CODE_KEY_ID) and moving the old key, under its id, to CAWG_AUTHORITY_RETIRED_CODE_KEYS until every challenge recorded under it has been used or has expired (a letter code lasts 45 days). Outstanding letter codes and approval tokens keep verifying through the key id recorded with each challenge. The CSRF value on an approval or letter-decline page is derived from the current key only, so a rotation invalidates it on every page already open: a decision posted from such a page is refused and changes nothing, and the person reloads the page and decides again.

5.7 Compromise and Disaster Recovery

• Issuing CA key compromise or out-of-policy handling: stop issuance, revoke the issuing CA (Section 4.9.1.2) and its leaves, create a new issuing CA in a witnessed operation, and notify Subscribers and the validators that configure the Encypher anchor.
• Root key compromise: stop all operations, notify validators to remove the anchor, and run a new root ceremony.
• Service loss: keys are held in KMS with Google's durability; status data and CRL artifacts restore from the CA database. Issuance stays stopped until CRL and OCSP for every configured issuer are serving.

5.8 CA or RA Termination

Encypher notifies Subscribers and the validators that configure the Encypher anchor as early as it can before termination, stops issuance, keeps CRL publication running until every issued certificate has expired or been revoked, and retains records under Section 5.5.

6. Technical Security Controls

6.1 Key Pair Generation and Installation

6.1.1 Key Pair Generation

All keys are generated by the Cloud KMS HSM when the key is created:

Each actor key is created with purpose asymmetric signing, algorithm ec-sign-p384-sha384 and protection level HSM.

6.1.2 Private Key Delivery to Subscriber

None. Private keys never leave the HSM.

6.1.3 Public Key Delivery to Certificate Issuer

The issuing service reads the actor key version's public key from KMS (Section 3.2.1).

6.1.4 CA Public Key Delivery to Relying Parties

Through the repository (Section 2.2) and through validator trust configurations that choose to include the root.

6.1.5 Key Sizes

ECDSA on P-384 (secp384r1) for every key.

6.1.6 Public Key Parameters Generation and Quality Checking

The HSM generates the parameters. Encypher rejects any public key that is not on P-384.

6.1.7 Key Usage Purposes

As stated in the KU and EKU fields of Section 7.1.

6.2 Private Key Protection and Cryptographic Module Engineering Controls

6.2.1 Cryptographic Module Standards and Controls

Google Cloud KMS at the HSM protection level, FIPS 140-2 Level 3.

6.2.2 Private Key (n out of m) Multi-Person Control

Root-key use requires the operation and independent review of Section 5.2.3. Issuing CA and actor keys are used by the runtime signing principal without multi-person control.

6.2.3 Private Key Escrow

None.

6.2.4 Private Key Backup

None outside KMS. KMS provides key durability.

6.2.5 Private Key Archival

None.

6.2.6 Private Key Transfer Into or From a Cryptographic Module

Not possible. Keys are non-exportable.

6.2.7 Private Key Storage on Cryptographic Module

Inside the KMS HSM.

6.2.8 Method of Activating Private Key

A key is usable only by principals granted signing permission on that key through Google Cloud IAM.

6.2.9 Method of Deactivating Private Key

Removing the IAM binding or disabling the key version.

6.2.10 Method of Destroying Private Key

Scheduling destruction of the key version in KMS, after the retention period of Section 5.5.

6.2.11 Out-of-Policy Key Handling

Out-of-policy key handling means any of the following for a root, issuing CA or actor key:

• a signature computed for a request not authorized under this document (for example signing by a principal without a valid grant for that actor);
• an IAM binding that grants signing or key-administration permission to a principal not authorized under Section 5.2;
• a key version created, enabled, disabled or scheduled for destruction outside a documented procedure;
• compromise of a credential that can cause signing with the key, including a Subscriber's account or API credential that holds a signing grant.

A notification of out-of-policy key handling, from any source, is a revocation trigger under Section 4.9.1.1 (reason 3) or Section 4.9.1.2.

6.3 Other Aspects of Key Pair Management

6.3.1 Public Key Archival

Every issued certificate is archived under Section 5.5.

6.3.2 Certificate Operational Periods and Key Pair Usage Periods

6.4 Activation Data

No passphrases or activation data exist outside Google Cloud IAM. Human access to the CAWG KMS project is granted only through Google Cloud IAM to people holding a trusted role (Section 5.2.1).

6.5 Computer Security Controls

• Dedicated service principals: the runtime signing principal can sign with the issuing CA key and actor keys only; the ceremony principal is the only one that can sign with the root key.
• Internal service calls (Auth revalidation and membership) require internal credentials with a named audience.
• Every outbound fetch to an Applicant-influenced host runs through the safe-fetch boundary.

6.6 Life Cycle Technical Controls

Changes to RA, issuance, CRL and OCSP code follow Encypher's reviewed change process and the local CI gate. Changes that alter key handling are high-risk and need explicit human approval before merge.

6.7 Network Security Controls

All Encypher service endpoints use TLS. Outbound fetches for EV probes, CRL and OCSP retrieval and .well-known checks use validated-IP pinning, connect and read deadlines and response-size caps.

6.8 Time-Stamping

Every CAWG identity assertion signed with a certificate under this policy MUST carry a trusted RFC 3161 timestamp, so that it can be validated after the leaf expires.

7. Certificate, CRL, and OCSP Profiles

7.1 Certificate Profile

7.1.1 Extended Key Usage OID Warning

Two different OIDs are called "document signing".

• This hierarchy uses only id-kp-documentSigning, 1.3.6.1.5.5.7.3.36 (RFC 9336). CAWG Identity 1.2 section 8.2.4 requires validators to accept it.
• Encypher's C2PA claim-signing leaves carry Adobe's 1.2.840.113583.1.1.5, which docs/ca/certificate-policy.md also labels id-kp-documentSigning. That OID MUST NOT appear in any certificate under this policy.
• id-kp-emailProtection (1.3.6.1.5.5.7.3.4), c2pa-kp-claimSigning (1.3.6.1.4.1.62558.2.1) and anyExtendedKeyUsage MUST NOT appear in any certificate under this policy.

The pre-issuance lint (Section 7.1.7) rejects a TBS certificate whose EKU differs from the single OID 1.3.6.1.5.5.7.3.36.

7.1.2 Root CA Certificate (existing, ceremony r2)

Values below are read from enterprise_api/data/cawg_registry/anchors/encypher-corporation-identity-root-ca-2026.pem.

The root's Certificate Policies extension carries the S/MIME BR organization-validated strict policy OID, 2.23.140.1.5.2.3, set by the builder default at ceremony r2. RFC 5280 path validation does not process a trust anchor's own extensions, so this value does not constrain the path to leaves under this policy. Encypher does not claim S/MIME BR conformance for this hierarchy (Section 1.1).

Owner decision (approved 2026-10-03): accept the root as issued with the disclosure above (the approved option, because the design source fixes r2 as the only root), or replace it in a new root ceremony with a root whose Certificate Policies extension carries the CAWG policy OID or is absent.

7.1.3 New Issuing CA Certificate

7.1.4 Organization Leaf Certificate

7.1.5 Name Forms and organizationIdentifier Grammar

The organizationIdentifier attribute (2.5.4.97) is mandatory and follows S/MIME BR 7.1.4.2.2(d):

If neither a whitelisted national identifier nor an accepted LEI exists, the application goes to exception review.

7.1.6 Prior emailProtection Issuing CA (Revocation-Only)

The prior issuing CA "Encypher CAWG Identity Issuing CA 2026" carries EKU id-kp-emailProtection and policy 2.23.140.1.5.2.3, and its leaves carry an rfc822Name SAN. It issues no certificate after this policy takes effect. Its CRL continues until its notAfter. OCSP for its leaves is answered through its delegated OCSP responder where one is configured; production has none, so its OCSP answers tryLater and the CRL is the status source. Certificates and attempts under the prior issuer, counted 2026-10-02: production 1 certificate (Encypher's own demonstration certificate, notAfter 2027-01-01) and 0 attempts; staging 0 and 0.

7.1.7 Pre-Issuance Lint

Before signing, Encypher lints every TBS leaf and refuses to sign unless:

• every subject value equals the value derived from the registry record in the evidence packet;
• O and CN are at most 64 characters and CN equals O;
• organizationIdentifier satisfies Section 7.1.5;
• the EKU is exactly 1.3.6.1.5.5.7.3.36 and the KU is exactly digitalSignature;
• the Certificate Policies extension carries the configured CAWG policy OID;
• the SAN is exactly one URI whose host is the revalidated verified host;
• the validity is at most 366 days;
• the public key equals the actor's persisted KMS key version.

7.2 CRL Profile

7.3 OCSP Profile

Responses follow RFC 6960, are available by GET and POST, and are valid for 24 hours. Requests naming an unknown issuer are refused. Issuing CA status is answered by the root-authorized delegated responder. Leaf status under the prior issuing CA is answered by its delegated responder where one is configured, until its notAfter.

The root-authorized delegated responder certificate is signed by the root key in the same witnessed session as the new issuing CA, under the same controls (Section 5.2.3), with its own signed record (schema encypher.cawg-root-ocsp-responder-signing.v1). Profile: subject CN=Encypher CAWG Identity Root OCSP Responder 2026 under the root's O and C; key cawg-identity-ocsp-signing-key (HSM P-384), never the root key; validity at most 366 days; EKU id-kp-OCSPSigning only; id-pkix-ocsp-nocheck; Certificate Policies the CAWG policy OID; Authority Key Identifier the root's Subject Key Identifier. Its renewal is a witnessed root operation. The responder certificate signed on 2026-10-05 has serial 4688e133e785370a6b7d3041a1210c152eb32a49 and SHA-256 fingerprint 610e0d66eb76a38d01ba18f31089e9944050bf8c523b1dd7171555ae1683011a, and is valid until 2027-10-06 02:40:48 UTC.

The new issuing CA signs OCSP responses for its own leaves directly with its own key, so its Key Usage includes digitalSignature (Section 7.1.3). A delegated responder is not used there, because a certificate carrying id-kp-OCSPSigning under an issuing CA restricted to 1.3.6.1.5.5.7.3.36 is rejected by some validators.

8. Compliance Audit and Other Assessments

8.1 Frequency or Circumstances of Assessment

Encypher assesses its own compliance with this document before approval of each version. This version has no external audit: WebTrust audits, Mozilla inclusion and other external trust programs are outside its scope.

8.2 Identity and Qualifications of Assessor

Encypher engineering and policy staff who do not operate the function they assess.

8.3 Assessor's Relationship to Assessed Entity

Internal.

8.4 Topics Covered by Assessment

Conformance of issued certificates to Section 7, of validation records to Sections 3 and 4, and of key operations to Sections 5 and 6.

8.5 Actions Taken as a Result of Deficiency

Encypher records each deficiency, fixes it, and revokes any certificate issued in breach of this document under Section 4.9.1.1.

8.6 Communication of Results

Results are internal. Encypher MAY share them with a validator or trust program that requests them.

9. Other Business and Legal Matters

9.1 Fees

Issuance requires an active Encypher entitlement. Fees, if any, are stated in the applicable order form.

9.2 Financial Responsibility

Financial responsibility is limited as stated in Section 9.8 and the Subscriber Agreement.

9.3 Confidentiality of Business Information

Validation evidence, exception-review documents, challenge records and audit logs are confidential. Certificates, CRLs, OCSP responses, this document and the Encypher Verified Organizations List entries of Subscribers who opted in are not confidential.

9.4 Privacy of Personal Information

9.4.1 Scope

This section covers only personal information collected for onboarding and certificate issuance under this policy. The Encypher Privacy Policy governs all other processing.

9.4.2 Information Collected

A certificate under this policy contains no personal data.

9.4.3 Sharing and Transfers

• Lob receives the data listed in Section 1.3.5 to print and mail each letter. Lob prints in the United States, so data about non-US Applicants is transferred to the United States.
• Encypher's outbound email service receives role addresses and approval links.
• Registry providers receive the search terms and identifiers that Encypher queries.
• Google Cloud and Railway process data as Encypher's infrastructure providers.

Encypher does not sell onboarding data and does not use it for marketing.

9.4.4 Retention

Section 5.5. Codes and tokens are never stored in clear.

9.4.5 Responsibility to Protect Private Information

Access to exception-review documents is limited to the RA role and CA operations.

9.4.6 Notice and Consent

Before submission, the dashboard MUST tell the Applicant which data is collected and that Lob receives the registered-office address and the requesting user's name. The dashboard shows this notice in the agreement step, before the acceptance control, and names Zoho as the email delivery provider. The Encypher Privacy Policy states the legal basis and data subject rights.

9.4.7 Disclosure Pursuant to Legal Process

Encypher discloses personal information only as required by law or valid legal process.

9.5 Intellectual Property Rights

Encypher owns this document, the certificates it issues, CRLs and OCSP responses. Subscribers retain ownership of their names and marks and grant Encypher a licence to use them to validate, issue, list (when opted in) and revoke certificates.

9.6 Representations and Warranties

9.6.1 CA Representations and Warranties

For the validity period of each certificate, Encypher warrants to the Subscriber and to Relying Parties that, at issuance:

• O, C and organizationIdentifier matched a registry record verified under Section 3.2.3;
• a standing representative confirmed under Section 3.2.6 authorized the request;
• the Subscriber controlled the host named in the SAN URI under Section 3.2.2;
• the certificate conformed to Section 7.1;
• Encypher maintained revocation status under Section 4.9.

Encypher warrants nothing about the content an assertion signs.

9.6.2 RA Representations and Warranties

Encypher is the only RA. Section 9.6.1 covers its warranties.

9.6.3 Subscriber Representations and Warranties

The Subscriber, through the Subscriber Agreement, represents and warrants that the information it provides is accurate and that the requesting user may act for it. The Subscriber MUST:

1. tell Encypher within 5 business days of any change in its legal name, registration number, registry status (including dissolution, strike-off, liquidation or administration), registered office, or control of the verified host;
2. tell Encypher within 24 hours of any suspected out-of-policy key handling (Section 6.2.11), including compromise of an account or API credential that holds a signing grant, or any signature it did not authorize;
3. request revocation if any certificate content becomes inaccurate;
4. keep signing grants limited to people and systems it authorizes, and end grants when people leave;
5. protect the credentials and multi-factor authentication of its owners and administrators;
6. use certificates only under Section 1.4.1;
7. stop requesting signatures with a certificate once it is expired or revoked;
8. review each new certificate and report errors within 7 days (Section 4.4.1);
9. respond to Encypher's reasonable requests for information about its registration or about a report under Section 4.9.2.

9.6.4 Relying Party Representations and Warranties

A Relying Party is responsible for its own trust decision and SHOULD follow Section 4.5.2.

9.6.5 Representations and Warranties of Other Participants

Lob acts as Encypher's subcontractor for letter delivery only, and Zoho acts as Encypher's subcontractor for email delivery only. Encypher remains responsible to Subscribers for their handling of letter and email content, including one-time codes and approval links. A code or link exposed through either cannot be used without an authenticated owner or administrator session in the Applicant's own tenant for codes, or without the CSRF-bound decision step for approval links (Section 3.2.6.5). Encypher's Lob account is on a paid plan with a live key; test-mode letters to a UK and a US registered office went through the production sending code on 2026-10-03.

9.7 Disclaimers of Warranties

Except as stated in Section 9.6.1, Encypher disclaims all warranties to the extent permitted by law.

9.8 Limitations of Liability

Encypher's liability is limited as stated in the Subscriber Agreement.

Owner decision (approved 2026-10-03): the liability cap for this hierarchy. The approved option mirrors the Encypher C2PA Subscriber Agreement v1.4, Section 15: an aggregate cap of USD 100 shared across the Subscriber and all Relying Parties, unless an order form invokes a higher enterprise cap.

9.9 Indemnities

As stated in the Subscriber Agreement.

9.10 Term and Termination

9.10.1 Term

Each version is in force from its approval and publication until a later version replaces it.

9.10.2 Termination

Section 5.8.

9.10.3 Effect of Termination and Survival

Obligations concerning issued certificates survive until those certificates expire or are revoked; records obligations survive for the period of Section 5.5.

9.11 Individual Notices and Communications with Participants

Notices to Encypher go to ca@encypher.com and, for legal notices, to Encypher Corporation, 850 New Burton Road, Dover, DE 19904, USA. Written correspondence MAY be sent to 2093 Philadelphia Pike #6262, Claymont, DE 19703, USA. Notices to Subscribers go to the owners of the organization account.

9.12 Amendments

9.12.1 Procedure for Amendment

Section 1.5.4.

9.12.2 Notification Mechanism and Period

Encypher publishes each new version at the CPS location and notifies owners of Subscriber accounts before a version that adds Subscriber obligations takes effect. Such a version requires a new Subscriber Agreement acceptance under Section 1.5.4.

9.12.3 Circumstances Under Which OID Must Be Changed

A change that alters the validation standard a Relying Party relies on (Section 3.2) requires a new policy OID.

9.13 Dispute Resolution Provisions

Disputes are resolved in the state and federal courts located in Delaware.

9.14 Governing Law

The laws of the State of Delaware, United States, without regard to conflict-of-laws principles.

9.15 Compliance with Applicable Law

Encypher and Subscribers comply with the laws that apply to them, including export control and sanctions law.

9.16 Miscellaneous Provisions

9.16.1 Entire Agreement

This document, the Subscriber Agreement version the Subscriber accepted, and any order form form the agreement between Encypher and the Subscriber about these certificates.

9.16.2 Assignment

A Subscriber MUST NOT assign a certificate. Encypher MAY assign its rights to a successor that continues the hierarchy under this document.

9.16.3 Severability

An unenforceable provision is enforced to the extent permitted, and the rest of this document stays in effect.

9.16.4 Enforcement

A waiver of one breach is not a waiver of another.

9.16.5 Force Majeure

Encypher is not liable for delay caused by events beyond its reasonable control, but it MUST still publish revocations as soon as it is able.

9.17 Other Provisions

None.

Appendix A. References

• RFC 2119, Key words for use in RFCs to Indicate Requirement Levels
• RFC 3647, Internet X.509 PKI Certificate Policy and Certification Practices Framework
• RFC 5280, Internet X.509 PKI Certificate and CRL Profile
• RFC 6960, Online Certificate Status Protocol
• RFC 8659, DNS Certification Authority Authorization (CAA) Resource Record
• RFC 9336, X.509 Certificate General-Purpose Extended Key Usage (EKU) for Document Signing
• RFC 9495, Certification Authority Authorization (CAA) Processing for Email Addresses
• CAWG Identity Assertion 1.2, section 8.2.4
• CA/Browser Forum Baseline Requirements for S/MIME Certificates, sections 1.6.1, 3.2.3, 3.2.6, 4.2.1, 4.9.1.1, 5.5.2, 7.1.4.2.2
• CA/Browser Forum TLS Baseline Requirements, sections 3.2.2.3, 3.2.2.4.4, 7.1.4.2.2
• IPTC Verified News Publisher Certificate Policy
• PRDs/CURRENT/PRD_CAWG_Org_Onboarding_Automation.md
• enterprise_api/docs/CAWG_IDENTITY_KMS.md
• docs/ca/signing-identity-and-certificate-operations.md
• Encypher C2PA Certificate Policy (docs/ca/certificate-policy.md) and Certification Practice Statement (docs/ca/certification-practice-statement.md), which this document does not alter

Appendix B. Approval Record

The owner approved version 1.0 on 2026-10-03. Each point the design source left open was approved as stated in the body, where it is marked "Owner decision (approved 2026-10-03)". In summary:

Version 1.0.1 (2026-10-05) records the values the witnessed issuing-CA operation of 2026-10-05 produced:

• new issuing CA (Sections 1.3.1 and 7.1.3): serial 42d16bd3dd374b72b252fb41aeb3d351eb4e2876, SHA-256 fingerprint 98b887bd26ca36452f570dbf894e2d4bdf95ef148bb591be401a41800a2aca76, valid 2026-10-05 02:33:36 UTC to 2031-10-06 02:38:36 UTC;
• signing ceremony records (Section 5.2.3): cawg_issuing_ca_20261005_024130_19c5d3b7 (issuing CA) and cawg_root_ocsp_20261005_024231_a091d923 (root-authorized OCSP responder);
• root-authorized OCSP responder certificate (Section 7.3): serial 4688e133e785370a6b7d3041a1210c152eb32a49, SHA-256 fingerprint 610e0d66eb76a38d01ba18f31089e9944050bf8c523b1dd7171555ae1683011a, valid 2026-10-05 02:35:48 UTC to 2027-10-06 02:40:48 UTC.