Add X.509 trust model guidance

docs/modules/ROOT/partials/credential-types/x509.adoc

@@ -23,6 +23,7 @@ In each of the above sections, the following changes MUST be applied:
 The `signer_payload` data structure MUST be serialized as described in link:++https://www.rfc-editor.org/rfc/rfc8949.html#name-core-deterministic-encoding++[Section 4.2.1, “Core Deterministic Encoding,”] of RFC 8949: Concise Binary Object Representation.
 The resulting byte string is presented to the _<<_credential_holder,credential holder>>_ for signature.
 * Any reference to the _claim generator_ MUST be replaced with the _<<_actor,actor>>_ whose _X.509 certificate_ is being used for this assertion.
+* The *<<_identity_assertion,identity assertion>>* generator SHALL use an _X.509 certificate_ that complies with the trust model described in xref:_trust_model_for_x_509_certificates[xrefstyle=full].
 
 ==== Validating the COSE signature
 
@@ -37,5 +38,56 @@ In each of the above sections, the following changes MUST be applied:
 
 * Any reference to the _claim_ MUST be replaced with the CBOR serialization of the `signer_payload` field from the *<<_identity_assertion,identity assertion>>.*
 * Any reference to the _claim generator_ MUST be replaced with the _<<_actor,actor>>_ whose _X.509 certificate_ is being used for this assertion.
-* The validator SHALL maintain one or more _<<_trust_list,trust lists>>_ which do not need to be the same as the _<<_trust_list,trust lists>>_ used to validate claim generator signatures as described in link:++https://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html#_c2pa_signers++[Section 14.4.1, “C2PA Signers.”]
-* The validator SHALL consider any v1 time-stamp as defined in link:++https://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html#_choosing_the_payload++[Section 10.3.2.5.2, “Choosing the payload”] to be invalid.
+* A validator MUST NOT issue the status `cawg.identity.trusted` for an *<<_identity_assertion,identity assertion>>* unless the _X.509 certificate_ is found to comply with the trust model as described in xref:_trust_model_for_x_509_certificates[xrefstyle=full].
+* A validator SHALL consider any v1 time-stamp as defined in link:++https://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html#_choosing_the_payload++[Section 10.3.2.5.2, “Choosing the payload”] to be invalid.
+
+==== Trust model for X.509 certificates
+
+A validator shall maintain the following information for evaluating CAWG X.509 signers, known as the *CAWG trust list*:
+
+* A list of accepted Extended Key Usage (EKU) values. For each accepted EKU value,
+** A list of accepted Certificate Policy (CP) values.
+** A list of X.509 certificate trust anchors.
+
+The list of accepted EKUS MUST include `id-kp-documentSigning` (1.3.6.1.5.5.7.3.36).
+No certificate policy or trust anchors are required for `id-kp-documentSigning` at this time.
+
+The requirements for link:++https://spec.c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_time_stamping_authorities++[Time stamping authorities] and link:++https://spec.c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_private_credential_storage++[Private credential storage] are identical to those stated in the C2PA technical standard.
+An implementation MAY share the implementation for these two trust lists between C2PA and CAWG implementations.
+
+[#interim-trust-model]
+===== Interim trust model additions
+
+[IMPORTANT]
+.Time restrictions for this section
+====
+The configuration options described in this section are valid only for *identity assertions* generated on or before 31 March 2027.
+An *identity assertion* generator MUST include a valid time stamp in the C2PA manifest or CAWG identity assertion.
+An *identity assertion* validator MUST be configured to _verify_ *identity assertions* that were valid at the time of issuance regardless of time of validation.
+====
+
+As of this writing (October 2025), the CAWG has not identified a suitable publicly-governed trust infrastructure for content assertion signing.
+In order to facilitate the use of CAWG identity assertions before such a trust infrastructure exists, the *CAWG trust list* is extended to include support for S/MIME certificates.
+The requirements for such certificates, stated below, are adapted from requirements specified by the CA/Browser Forum in https://cabforum.org/uploads/CA-Browser-Forum-SMIMEBR-1.0.11.pdf[Baseline Requirements for the Issuance and Management of Publicly‐Trusted S/MIME Certificates, version 1.0.11].
+
+The *CAWG trust list* MUST be configured to accept any certificate that meets *all* of the following requirements when used to sign an *identity assertion* issued during the validity window described above.
+
+1. The EKU `id-kp-emailProtection` (1.3.6.1.5.5.7.3.4) is used.
+2. One of the following certificate policy IDs is used:
++
+** Organization-validated Multipurpose (2.23.140.1.5.2.2)
+** Organization-validated Strict (2.23.140.1.5.2.3)
+** Sponsor-validated Multipurpose (2.23.140.1.5.3.2)
+** Sponsor-validated Strict (2.23.140.1.5.3.3)
+** Individual-validated Multipurpose (2.23.140.1.5.4.2)
+** Individual-validated Strict (2.23.140.1.5.4.3)
++
+IMPORTANT: This list does not include Mailbox-validated or “legacy” certificate purpose OIDs.
+3. The certificate chains up to one of the following roots of trust:
++
+** The https://wiki.mozilla.org/CA[Mozilla Root Store with the Email (S/MIME) Trust Bit Enabled].
+A PEM-encoded version of this list is available at https://ccadb.my.salesforce-sites.com/mozilla/IncludedRootsPEMTxt?TrustBitsInclude=Email.
+** The https://iptc.org/verified-news-publishers-list/[IPTC Origin Verified News Publishers List].
+A PEM-encoded version of this list is available at https://iptc.org/verified-news-publishers-list/verified-news-publishers-list.pem.
+** _TO DO: Are there other publicly-available roots to consider?_
+4. The certificate was valid and not revoked at time of signature.