Certificate Policy

Write abstract.

Version 1.0 Draft 14 October 2026 · Version history

This is a working draft of the first version of this specification and may be changed without warning.

License

This specification is subject to the W3C Patent Policy (2004).

For sample or reference code included in the specification itself, that code is subject to the Apache 2.0 license, unless otherwise designated. In the case of any conflict or confusion within this specification repository between the W3C Patent Policy (2004) or other designated license, the terms of the W3C Patent Policy (2004) shall apply.

These terms are inherited from the Decentralized Identity Foundation Project Charter.

Contributing

This section is non-normative.

This specification is an active working draft. If you wish to contribute to its development, please view the CAWG membership page.

Foreword

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. No party shall be held responsible for identifying any or all such patent rights.

Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement.

This document was prepared by the Creator Assertions Working Group, a working group of the Decentralized Identity Foundation.

THESE MATERIALS ARE PROVIDED “AS IS.” The Contributors and Licensees expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to the materials. The entire risk as to implementing or otherwise using the materials is assumed by the implementer and user. IN NO EVENT WILL THE CONTRIBUTORS OR LICENSEES BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THIS DELIVERABLE OR ITS GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER MEMBER HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Table of contents

1. Overview

This certificate policy (CP) establishes the requirements governing the issuance of CAWG claim signing certificates for use by individuals or organizations abiding by the technical specifications developed by the Creator Assertions Working Group.

The policy sets the requirements that MUST be met by a certification authority (CA) in the process of issuing CAWG claim signing certificates to subscribers that intends to make CAWG claims on digital assets.

CAWG claim signing certificates under this policy MUST only be issued by certification authorities that have successfully passed the CAWG conformance program, as documented through their inclusion in the CAWG trust list. Digital certificates issued under this CP indicate an assurance level that can be used by a relying party as part of its trust evaluation of an subscriber that makes claims on CAWG assertions.

Certification authorities that comply with this certificate policy and want to issue certificates under the CAWG conformance program MUST apply to the CAWG governing authority for inclusion on the CAWG trust list.

This certificate policy considers the Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates, as adopted by the CA/Browser Forum.

Is the above paragraph still true and relevant?

These requirements describe three certificate profiles differentiated by the type of subject that apply to CAWG claim-signing certificates:

Certificate type Description

organization-validated

Includes only organizational (legal entity) attributes in the subject.

sponsor-validated

Combines individual (natural person) attributes in conjunction with a subject:organizationName (an associated legal entity) attribute. Registration for sponsor-validated certificates MAY be performed by an enterprise RA.

individual-validated

Includes only individual (natural person) attributes in the subject.

The following certificate policy identifiers are reserved for use by CAs as a means of asserting compliance with this document as follows:

These are the CA/B Forum S/MIME Legacy OIDs (2.23.140.1.5.{2,3,4}.1). CAWG doesn’t own that arc, so it can’t use them to signal compliance with this policy, and the CAWG interim trust model already rejects Legacy certificates. Suggest getting a CAWG IANA PEN (free, about a week) and defining {cawg} 1 1 as this CP’s OID, plus one OID per validation type. Issuers MAY also add the S/MIME BR Multipurpose/Strict OIDs when a certificate also meets the BR.

organization-validated
{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) smime-baseline(5) organization-validated (2) legacy (1)} (2.23.140.1.5.2.1); and

{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) smime-baseline(5) organization-validated (2) multipurpose (2)} (2.23.140.1.5.2.2); and

{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) smime-baseline(5) organization-validated (2) strict (3)} (2.23.140.1.5.2.3); and

sponsor-validated
{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) smime-baseline(5) sponsor-validated (3) legacy (1)} (2.23.140.1.5.3.1); and

{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) smime-baseline(5) sponsor-validated (3) multipurpose (2)} (2.23.140.1.5.3.2); and

{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) smime-baseline(5) sponsor-validated (3) strict (3)} (2.23.140.1.5.3.3); and

individual-validated
{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) smime-baseline(5) individual-validated (4) legacy (1)} (2.23.140.1.5.4.1); and

{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) smime-baseline(5) individual-validated (4) multipurpose (2)} (2.23.140.1.5.4.2); and

{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) smime-baseline(5) individual-validated (4) strict (3)} (2.23.140.1.5.4.3).

  • Title: CAWG certificate policy

  • Identifier: TBD

    This document’s own identifier is still TBD; see the policy OID note above.

  • Current Version: 1.0 draft

  • Date of Approval: TBD

  • Organization: The Creator Assertions Working Group (CAWG)

1.1. Certificate usage

1.1.1. Intended use

Certificates issued under this CP are to be used exclusively by individuals and organizations named as the subjects of the certificates, which have been implemented by the subscribers, to digitally sign CAWG claims at the assurance level indicated by the certificate.

1.1.2. Prohibited use

Any use of certificates issued under this policy outside of the CAWG Specification or the CAWG conformance program is strictly prohibited.

1.2. Policy administration

This CP is administered by the administering authority on behalf of the governing authority.

This makes the Trust Task Force the Administering Authority that operates the program. That conflicts with the 2 Oct Friends of CAWG decision that CAWG designates and sets requirements but does not operate registries or conformance programs. Suggest a Program Administrator independent of applicants, appointed by the Steering Committee as Governing Authority, with two-person approval for list changes.

1.2.1. Contact information

This e-mail address doesn’t exist yet and will likely change as CAWG reconsiders its name.

1.2.2. CP approval procedures

The governing authority approves the CP and any amendments. Amendments are made either by updating the entire CP or by publishing an addendum. The governing authority determines whether an amendment to this CP requires notice or an OID change.

2. Normative references

  • RFC 9598 is listed twice.

  • TS 119 495 (PSD2), the DNSSEC RFCs, RFC 8823 and the TLS BRs don’t apply and can be dropped.

  • Add FIPS 140-3 alongside 140-2.

  • Add links for documents not already linked.

  • Unify style of linking.

  • Add Asciidoc anchors for each doc so it can be referenced elsewhere.

  • BCP 14

  • RFC 2119

  • RFC 8174

  • RFC 5280

  • RFC 3161

  • eIDAS: Regulation (EU) No 910/2014 as amended by Regulation (EU) 2024/1183 and Directive (EU) 2022/2555

  • ETSI EN 319 403-1, Electronic Signatures and Trust Infrastructures (ESI); Trust Service Provider Conformity Assessment; Part 1 - Requirements for conformity assessment bodies assessing Trust Service Providers.

  • ETSI EN 319 411-1, Electronic Signatures and Trust Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 1: General requirements.

  • ETSI EN 319 411-2, Electronic Signatures and Trust Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 2: Requirements for trust service providers issuing EU qualified certificates.

  • ETSI EN 119 411-6, Electronic Signatures and Trust Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 6: Requirements for Trust Service Providers issuing publicly trusted S/MIME certificates.

    This should be ETSI TS 119 411-6, not EN.

  • ETSI EN 319 412-1, Electronic Signatures and Trust Infrastructures (ESI); certificate profiles; Part 1: Overview and common data structures.

  • ETSI EN 319 412-5, Electronic Signatures and Trust Infrastructures (ESI); certificate profiles; Part 5: QCStatements.

  • ETSI TS 119 172-4, Electronic Signatures and Trust Infrastructures (ESI); Signature Policies;. Part 4: Signature applicability rules.

  • ETSI TS 119 495, Electronic Signatures and Trust Infrastructures (ESI); Sector Specific Requirements; certificate profiles and TSP Policy Requirements for Open Banking.

  • FIPS 140-2, Federal Information Processing Standards Publication - Security Requirements For Cryptographic Modules, Information Technology Laboratory, National Institute of Standards and Technology, May 25, 2001.

  • ICAO DOC 9303, Machine Readable Travel Documents, Part 10, Logical Data Structure (LDS) for Storage of Biometrics and Other Data in the Contactless Integrated Circuit (IC), International Civil Aviation Organization, Eighth Edition, 2021.

  • ICAO DOC 9303, Machine Readable Travel Documents, Part 11, Security Mechanisms for MRTDs, International Civil Aviation Organization, Eighth Edition, 2021.

  • ISO 17065:2012, Conformity assessment — Requirements for bodies certifying products, processes and services.

  • ISO 17442-1:2020, Financial services — legal entity identifier (LEI) - Part 1: Assignment.

  • ISO 17442-2:2020, Financial services — legal entity identifier (LEI) - Part 2: Application in digital certificates.

  • ISO/IEC TS 18013-5, Information technology — Personal identification — ISO-compliant driving licence — Part 5: Mobile Driving Licence (mDL) application.

  • ISO/IEC TS 18013-7, Information technology — Personal identification — ISO-compliant driving licence — Part 7: Mobile Driving Licence (mDL) digital trust service.

  • Network and certificate System Security Requirements, Version 2.0 or later. See https://cabforum.org/network-security-requirements/.

  • NIST SP 800-89, Recommendation for Obtaining Assurances for Digital Signature Applications.

  • RFC 2119, Request for Comments: 2119, Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. March 1997.

  • RFC 3647, Request for Comments: 3647, Internet X.509 public key infrastructure: certificate policy and Certification Practices Framework, S. Chokhani, et al. November 2003.

  • RFC 3739, Request for Comments: 3739, Internet X.509 public key infrastructure: Qualified certificates Profile, S. Santesson, et al. March 2004.

  • RFC 4035, Request for Comments: 4035, Protocol Modifications for the DNS Security Extensions. R. Arends, et al. March 2005.

  • RFC 4509, Request for Comments: 4509, Use of SHA-256 in DNSSEC Delegation signer (DS) Resource Records (RRs). W. Hardaker. May 2006.

  • RFC 5019, Request for Comments: 5019, The Lightweight online certificate status protocol (OCSP) Profile for High-Volume Environments, A. Deacon, et al. September 2007.

  • RFC 5155, Request for Comments: 5155, DNS Security (DNSSEC) Hashed Authenticated Denial of Existence. B. Laurie, et al. March 2008.

  • RFC 5280, Request for Comments: 5280, Internet X.509 public key infrastructure: certificate and certificate revocation list (CRL) Profile, D. Cooper et al. May 2008.

  • RFC 5702, Request for Comments: 5702, Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC. J. Jansen. October 2009.

  • RFC 6818, Updates to the Internet X.509 public key infrastructure certificate and certificate revocation list (CRL) Profile, P. Yee. January 2013.

  • RFC 6840, Request for Comments: 6840, Clarifications and Implementation Notes for DNS Security (DNSSEC). S. Weiler, et al. February 2013.

  • RFC 6960, Request for Comments: 6960, X.509 Internet public key infrastructure online certificate status protocol - OCSP, S. Santesson, et al. June 2013.

  • RFC 8823, Request for Comments: 8823, Extensions to Automatic certificate Management Environment for End-User S/MIME certificates, A. Melnikov. April 2021.

  • RFC 8555, Request for Comments: 8555, Automatic certificate Management Environment (ACME), R. Barnes et al. March 2019.

  • RFC 9598, Request for Comments: 9598, Internationalized Email Addresses in X.509 certificates, A. Melnikov, et al. May 2024.

  • RFC 8499, Request for Comments: 8499, DNS Terminology, P. Hoffman, et al. January 2019.

  • RFC 9495, Request for Comments: 9495, certification authority authorization (CAA) Processing for Email Addresses, C. Bonnell. October 2023.

  • RFC 9598, Request for Comments: 9598, Internationalized Email Addresses in X.509 certificates, A. Melnikov, et al. May 2024.

  • “TLS Baseline Requirements” means the current version of the CA/Browser Forum’s “Baseline Requirements for the Issuance and Management of Publicly‐Trusted TLS Server certificates.” See https://cabforum.org/baseline-requirements-documents/

  • WebTrust for certification authorities, CPA Canada.

  • X.509, Recommendation ITU-T X.509 (10/2012) | ISO/IEC 9594-8:2014 (E), Information technology – Open Systems Interconnection – The Directory: Public-key and attribute certificate frameworks.

3. Terms and definitions

Administering authority

The party that the CAWG governing authority empowers to operate its conformance program on its behalf. It recognizes and accredits key conformance roles which agree to participate in the program. The CAWG Trust Task Force of the Creator Assertions Working Group operates in this capacity.

Affiliate

A corporation, partnership, joint venture or other entity controlling, controlled by, or under common control with another entity, or an agency, department, political subdivision, or any entity operating under the direct control of a government entity.

Applicant

The natural person or legal entity that applies for (or seeks renewal of) a certificate. Once the certificate is issued, the applicant is referred to as the subscriber. For certificates issued to devices, the applicant is the entity that controls or operates the device named in the certificate, even if the device is sending the actual certificate request.

Applicant’s representative

A natural person or human sponsor who is either the applicant, employed by the applicant, or an authorized agent who has express authority to represent the applicant:

  1. who signs and submits, or approves a certificate request on behalf of the applicant;

  2. who signs and submits a subscriber agreement on behalf of the applicant; and/or

  3. who acknowledges the terms of use on behalf of the applicant when the applicant is an affiliate of the CA or is the CA.

Application software supplier

A supplier of email client software or other relying-party application software such as mail user agents (web-based or application based) and email service providers that process S/MIME certificates.

Reconsider definition — likely holdover from S/MIME policy.

Assertion
Asset
Assumed name (or doing business as, DBA)

Also known as “doing business as”, “DBA”, or “d/b/a” name in the US and “trading as” name in the UK.

Assurance level

An indication to a relying party of the level of confidence that it may have that identity assertions and claims signed with a given CAWG claim signing certificate reflect the actual claimant. A higher assurance level allows the relying party to have a greater level of confidence.

The assurance level is conveyed through the CAWG-al (TBD) X.509 v3 certificate extension in a CAWG claim signing certificate. The value of this extension is an encoded OID value that corresponds to a numeric value no higher than the maximum assurance level for a given claim signing issuer. The OID values corresponding to each assurance level are defined in the CAWG oid.txt MIB definition file.

The assurance level in the CAWG claim signing certificate that is issued to an organization or individual may be lower than the maximum assurance level that the issuer is potentially eligible for.

Attestation

A letter attesting that subject information is correct written by an accountant, lawyer, government official, or other reliable third party customarily relied upon for such information.

Audit period

In a period-of-time audit, the period between the first day (start) and the last day of operations (end) covered by the auditors in their engagement. (This is not the same as the period of time when the auditors are on-site at the CA.) The coverage rules and maximum length of audit periods are defined in Section 11.1, “Compliance audits”.

Audit report

A report from a qualified auditor stating the qualified auditor’s opinion on whether an entity’s processes and controls comply with the mandatory provisions of these requirements.

CA key pair

A key pair where the public key appears as the subject public key info in one or more root CA certificate(s) and/or subordinate CA certificate(s).

CAWG certificate policy

A document that sets the requirements that MUST be met by certification authorities (CAs) in the process of issuing digital certificates to subscribers that intend to sign CAWG digital assertions, and the requirements that MUST be met by the subscribers in their use of the certificates.

C2PA claim
CAWG claim signing certificate

An X.509 certificate issued by one of the certification authorities on the CAWG trust list to an instance of the Conforming Implementer’s conforming generator product, and names the generator product as the subject of the certificate.

C2PA leftover: this issues the certificate to a generator product, which is C2PA’s claim-signing model.

A CAWG identity certificate binds a person or organization, not a software product. The same applies to the CA, Subscriber and Signer definitions. Suggest renaming to CAWG Identity Certificate and defining the subject as the verified person or organization.

CAWG conformance program

A risk-based governance program intended to hold applicants who want to demonstrate their conformance to its requirements and then differentiate themselves through CAWG recognition by satisfying program requirements being acknowledged as achieving that level of conformance. It consists of a set of processes, policies, and requirements governing the designation of applicant certification authorities as adhering to the CAWG certificate policy, as defined by the CAWG Trust Task Force.

Processes include:

CAWG governance framework

A collection of governance documents which defines the CAWG trust ecosystem including roles, requirements and processes used by the CAWG governing authority to achieve greater assurance over the provenance and authenticity of digital asset content.

C2PA Content Credential
C2PA Content Credentials specification

A globally recognized standard for providing digital asset content provenance and authenticity. It is designed to enable global, opt-in, adoption of digital provenance techniques through the creation of a rich ecosystem of digital provenance enabled applications for a wide range of individuals and organizations while meeting appropriate security requirements.

C2PA manifest
CAWG trust list

In the context of the CAWG conformance program, a CAWG-managed list of X.509 certificate trust anchors (either root or subordinate certification authorities) that issue certificates to individualas and organizationss under the CAWG certificate policy.

CAWG TSA trust list

A CAWG-managed list of X.509 certificate trust anchors (either root or subordinate certification authorities) that issue time-stamp signing certificates to time-stamping authorities (TSA).

Separate TSA list: CAWG Identity Assertion 1.3 already uses the C2PA TSA Trust List, which this draft also cites later.

A second CAWG TSA list, the TSA requirements (including the On-Device TSA) and the TSA profiles all duplicate C2PA. Suggest deleting them and pointing to the C2PA TSA Trust List.

Certificate

An electronic document that uses a digital signature to bind a public key and an identity.

Certificate signing request (or CSR)

Definition pending.

Certification authority (or CA)

A trusted entity that issues, signs, and revokes digital certificates that bind public keys to subscriber identities. CAs are also known as PKI certificate Authorities because they issue certificates based on public key infrastructure (PKI). These certificates contain credentials that confirm the possession of a private key by an entity, among other verified attributes. Individualas and organizations sign C2PA manifests using digital signing credentials issued by CAs.

An entity on the CAWG trust list that is trusted by the CAWG conformance program to issue X.509 CAWG claim signing certificates to instances of conforming generator products.

An organization that operates a certification authority may also operate a time-stamping authority.

Certification authority authorization (or CAA)

From RFC 9495: “The certification authority authorization (CAA) DNS resource record (RR) provides a mechanism for domains to express the allowed set of certification authorities that are authorized to issue certificates for the domain.

Certificate data

Certificate requests and data related thereto (whether obtained from the applicant or otherwise) in the CA’s possession or control or to which the CA has access.

Certificate management process

Processes, practices, and procedures associated with the use of keys, software, and hardware, by which the CA verifies certificate data, issues certificates, maintains a repository, and revokes certificates.

Certificate policy (or CP)

A set of rules that indicates the applicability of a named certificate to a particular community and/or PKI implementation with common security requirements.

Certification practice statement (or CPS)

One of several documents forming the governance framework in which certificates are created, issued, managed, and used.

Certificate problem report

Complaint of suspected key compromise, certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to certificates.

Certificate profile

A set of documents or files that defines requirements for certificate content and certificate extensions in accordance with Section 10, “Certificate, CRL, and OCSP profiles” e.g., a section in a CA’s CPS or a certificate template file used by CA software.

Certificate request

Definition pending.

Certificate revocation list (or CRL)

A regularly updated time-stamped list of revoked certificates that is created and digitally signed by the CA that issued the certificates.

Certificate type

This CP defines certificate profiles differentiated by the type of subject, (for example organization, sponsored, individual).

Common name (or CN)

Definition pending.

Conformance criteria

A set of normative requirements that the CAWG expects a governed party to demonstrate its conformance as part of the CAWG conformance program. This criteria consists of requirements in the CAWG certificate policy.

Control

Possession, directly or indirectly, of the power to: (1) direct the management, personnel, finances, or plans of such entity; (2) control the election of a majority of the directors; or (3) vote that portion of voting shares required for “control” under the law of the entity’s jurisdiction of incorporation or registration but in no case less than 10%.

Conversion

The process of converting text from one writing system to ASCII characters.

Country

Either a member of the United Nations OR a geographic region recognized as a sovereign state by at least two UN member nations.

Cross certificate

A certificate that is used to establish a trust relationship between two root CAs.

Cryptographically secure pseudo-random number generator (or CSPRNG)

A pseudo-random number generator intended for use in a cryptographic system.

Delegated third party

A natural person or legal entity that is not the CA but is authorized by the CA, and whose activities are not within the scope of the appropriate CA audits, to assist in the certificate management process by performing or fulfilling one or more of the CA requirements found herein.

Digital identity document

A government-issued identity document that is issued in a machine-processable form, that is digitally signed by the issuer, and that is in purely digital form.

Digital signature

Definition pending.

Distinguished name (or DN)

Definition pending.

Domain label

From RFC 8499: “An ordered list of zero or more octets that makes up a portion of a domain name. Using graph theory, a label identifies one node in a portion of the graph of all possible domain names.”

Domain name

An ordered list of one or more domain labels assigned to a node in the domain name system.

Domain name system (or DNS)

Definition pending.

Electronic identification (or eID)

A credential containing individual identification data and/or attributes and which is used for authentication for an online service.

Enterprise RA

An employee or agent of an organization unaffiliated with the CA who authorizes issuance of certificates to that organization.

European Telecommunications Standards Institute (or ETSI)

Definition pending.

European unique identifier (or EUID)

The EUID uniquely identifies officially-registered organizations, legal entities, and branch offices within the European Union or the European Economic Area. The EUID is specified in chapter 9 of the Annex contained in the Implementing Regulation (EU) 2021/1042 which describes rules for the application of Directive (EU) 2017/1132 “relating to certain aspects of company law (codification).”

Extended key usage (or EKU)

Definition pending.

Expiry date

The “Not After” date in a certificate that defines the end of a certificate’s validity period.

Federal Information Processing Standard (or FIPS)

Definition pending. (US Government)

Fully-qualified domain name

A domain name that includes the domain labels of all superior nodes in the Internet domain name system.

Governed party

An organization which desires to play a recognized role in the CAWG conformance program. It applies to the CAWG conformance program which requires them to sign a legal agreement and have their application reviewed prior to entering them on the CAWG trust list. Governed parties of the C2PA ecosystem are certification authorities that elect to apply and and abide by the CAWG conformance program requirements.

Governing authority

The organization responsible for the trust of the ecosystem. It empowers an administering authority to manage the ecosystem and certifying entities to convey trust. The CAWG is the governing party of its conformance program driven by its Steering Committee.

Government entity

A government-operated legal entity, agency, department, ministry, branch, or similar element of the government of a country, or political subdivision within such country (such as a state, province, city, county, etc.).

Hardware security module (or HSM)

Definition pending.

Individual
Individual-validated

Refers to a certificate subject that includes only individual (natural person) attributes, rather than attributes linked to an organization.

International Civil Aviation Organization (or ICAO)

Definition pending.

International Organization for Standardization (or ISO)

Definition pending.

Issuer

Definition pending.

Issuing authority

Definition pending.

Issuing CA

In relation to a particular certificate, the CA that issued the certificate. This could be either a root CA or a subordinate CA.

Jurisdiction of incorporation

The country and (where applicable) the state or province or locality where the organization’s legal existence was established by a filing with (or an act of) an appropriate government agency or entity (e.g., where it was incorporated). In the context of a government entity, the country and (where applicable) the state or province where the entity’s legal existence was created by law.

Key compromise

A private key is said to be compromised if its value has been disclosed to an unauthorized person, or an unauthorized person has had access to it.

Key generation script

A documented plan of procedures for the generation of a CA key pair.

Key pair

A private key and its associated public key.

Legal entity

An association, corporation, partnership, proprietorship, trust, government entity or other entity with legal standing in a country’s legal system.

Legal entity identifier (or LEI)

Definition pending.

Linting

A process in which the content of digitally signed data such as a precertificate (RFC 9162 §3.2), certificate, CRL, or OCSP response, or data-to-be-signed object such as a tbsCertificate (RFC 5280 §4.1.1.1) is checked for conformance with the profiles and requirements defined in these requirements.

Maximum assurance level

A numeric designation, using generally accepted market schemes based on degree of validation performed on an individual or organization.

Mobile driver license (or mDL)

A driver license that is issued in digital format by an issuing authority that is authorized by the relevant government or jurisdiction to issue driving licenses in accordance with applicable law, and conforms to ISO/IEC 18013-5 and ISO/IEC 18013-7.

National Institute of Standards and Technology (or NIST)

Definition pending. (US Government)

Natural person

An individual; a human being as distinguished from a legal entity.

Name constraint

Definition pending.

Object identifier (or OID)

A unique alphanumeric or numeric identifier registered under the International Organization for Standardization’s applicable standard for a specific object or object class.

OCSP responder

An online server operated under the authority of the CA and connected to its repository for processing certificate status requests. See also, online certificate status protocol.

Online certificate status protocol (or OCSP)

An online certificate-checking protocol that enables relying-party application software to determine the status of an identified certificate. See also OCSP responder.

Organization (or O)

In the distinguished name field of a certificate.

Organization-validated

Refers to a certificate subject that includes only Organizational (legal entity) attributes, rather than attributes linked to an individual.

Organizational unit (or OU)

In the distinguished name field of a certificate.

Parent company

A company that controls a subsidiary company.

Personal name

Personal name is a name of an individual subject typically presented as subject:givenName and/or subject:surname. However, the personal name may be in a format preferred by the subject, the CA, or enterprise RA as long as it remains a meaningful representation of the subject’s verified name.

Physical identity document

A government-issued identity document issued in physical and human-readable form (such as a passport or national identity card).

Private key

The key of a key pair that is kept secret by the holder of the key pair, and that is used to create digital signatures and/or to decrypt electronic records or files that were encrypted with the corresponding public key.

Pseudonym

A fictitious identity that a person assumes for a particular purpose. Unlike an anonymous identity, a pseudonym can be linked to the person’s real identity.

Public key

The key of a key pair that can be publicly disclosed by the holder of the corresponding private key and that is used by a relying party to verify digital signatures created with the holder’s corresponding private key and/or to encrypt messages so that they can be decrypted only with the holder’s corresponding private key.

Public key infrastructure (or PKI)

A set of hardware, software, people, procedures, rules, policies, and obligations used to facilitate the trustworthy creation, issuance, management, and use of certificates and keys based on public key cryptography.

Publicly-trusted certificate

A certificate that is trusted by virtue of the fact that its corresponding root CA certificate is distributed as a trust anchor in widely-available application software.

Qualified auditor

A natural person or legal entity that meets the requirements of [review-of-delegated-parties].

Random value

A value specified by a CA to the applicant that exhibits at least 112 bits of entropy.

Registered domain name

A domain name that has been registered with a domain name registrar.

Registration authority (or RA)

An entity authorized by the certification authority to collect, verify, and submit information provided by applicants and/or subscribers which is to be entered into public key certificates. The term RA refers to hardware, software, and individuals that collectively perform this function, including tasks such as validating platform attestations and presence of potential subscriber implementations on the C2PA Conforming Products List. The RA operates under the CA’s authority and adheres to the guidelines set forth in the C2PA certificate policy.

Above is a potential holdover from C2PA CP and should be revisited.

The CA MAY delegate the performance of all, or any part, of Section 6.2, “Initial identity validation” requirements to a delegated third party, provided that the process as a whole fulfills all of the requirements of Section 6.2, “Initial identity validation”.

Before the CA authorizes a delegated third party to perform a delegated function, the CA MUST contractually require the delegated third party to:

  1. Meet the qualification requirements of Section 8.3, “Personnel controls”, when applicable to the delegated function;

  2. Retain documentation in accordance with Section 8.5.2, “Retention period for archive”;

  3. Abide by the other provisions of these requirements that are applicable to the delegated function; and

  4. Comply with (a) the CA’s CP and/or CPS or (b) the delegated third party’s practice statement that the CA has verified complies with these requirements.

Enterprise registration authorities

The CA MAY delegate to an enterprise registration authority (RA) to verify certificate requests for subjects within the enterprise RA’s own organization. The CA MUST NOT accept certificate requests authorized by an enterprise RA unless the following requirements are satisfied:

  1. If the certificate request is for a Organization-validated, or Sponsor-validated profile, the CA MUST confirm that the enterprise RA has authorization or control of the requested email domain(s) in accordance with Section 6.2, “Initial identity validation” or Section 6.2, “Initial identity validation”.

  2. The CA MUST confirm that the subject:organizationName name is either that of the delegated enterprise, or an affiliate of the delegated enterprise, or that the delegated enterprise is an agent of the named subject. For example, the CA MUST NOT issue a certificate containing the subject name “XYZ Co.” on the authority of enterprise RA “ABC Co.”, unless the two companies are Affiliated as defined in Section 6.2, “Initial identity validation” or “ABC Co.” is the agent of “XYZ Co.” This requirement applies regardless of whether the accompanying requested email domain falls within the subdomains of ABC Co.‘s registered domain name.

Review applicability of e-mail controls for CAWG.

The CA MUST impose these limitations as a contractual requirement on the enterprise RA and monitor compliance by the enterprise RA in accordance with [review-of-delegated-parties].

Registration reference

Definition pending.

Reliable data source

Definition pending.

Reliable method of communication

A method of communication, such as a postal/courier delivery address, telephone number, or email address, that was verified using a source other than the applicant’s representative.

Relying party

An entity that evaluates the trustworthiness of assertions made by a signer in a C2PA asset, based on the signer’s identity and the assurance level encoded into the C2PA claim Signing certificate.

Revisit for CAWG.

Repository

An online database containing publicly-disclosed PKI governance documents (such as certificate policies and certification practice statements) and certificate status information, either in the form of a CRL or an OCSP response.

Rich execution environment (or REE)
Root certification authority (or Root CA)
Root certification authority certificate (or Root CA certificate)

The self-signed certificate issued by the root CA to identify itself and to facilitate verification of certificates issued to its subordinate CAs.

Root of trust (or RoT)
Security incident
Signer

In the CAWG Trust Model, the assertions enumerated in the created_assertions object of the CAWG Claim are attributed to the signer.

The term CAWG Trust Model is introduced here but not used or defined anywhere else.

The above definition looks like a holdover from C2PA. Consider rewording to referenced_assertions and named actor for consistency with terms used in the identity assertion spec

In the context of the CAWG conformance program, an indiviual or organization identified as the subject of a CAWG Signing certificate is always the signer.

Sponsor-validated

Refers to a certificate subject which combines individual (natural person) attributes in conjunction with an subject:organizationName (an associated legal entity) attribute. Registration for sponsor-validated certificates MAY be performed by an enterprise RA where the subject:organizationName is either that of the delegated enterprise, or an affiliate of the delegated enterprise, or that the delegated enterprise is an agent of the named subject organization.

Subscriber

An applicant that has become a customer of one of the certification authorities on the CAWG trust list, and is eligible to receive CAWG claim signing certificates for use by instances of their conforming generator product.

Check use of “generator product.”

Subject

The natural person, device, system, unit, or legal entity identified in a certificate as the subject. The subject is either the subscriber or a mailbox under the control and operation of the subscriber.

Check reference to mailbox. May not apply here.

Subject identity information

Information that identifies the certificate subject. Subject identity information does not include a mailbox address listed in the subject:commonName or subject:emailAddress fields, or in the subjectAltName extension.

Check reference to mailbox. May not apply here.

Subject information

Definition pending.

Subject public key info

Definition pending.

Subordinate CA

A certification authority whose certificate is signed by the root CA, or another subordinate CA.

Subscriber

A natural person or legal entity to whom a certificate is issued and who is legally bound by a subscriber agreement or terms of use.

Subscriber agreement

An agreement between the CA and the applicant/subscriber that specifies the rights and responsibilities of the parties.

Subsidiary company

A company that is controlled by a parent company.

Supplementary evidence

Used in addition to authoritative evidence to strengthen the reliability of the identity verification and/or as evidence for attributes that are not evidenced by the authoritative evidence.

Technically-constrained subordinate CA certificate

A subordinate CA certificate which uses a combination of extended key usage settings and name constraint settings to limit the scope within which the subordinate CA certificate MAY issue certificates to subscriber or additional subordinate CAs.

Terms of use

Provisions regarding the safekeeping and acceptable uses of a certificate issued in accordance with these requirements when the applicant/subscriber is an affiliate of the CA or is the CA.

Time-stamping authority (or TSA)

A server that provides electronic certification and trust services by creating a hash of a document or digital information. The hash verifies the date and time of the document’s creation or last modification, and acts as an independent witness to prove that the document has not changed since it was signed. This is similar to how a notary acts for online documents. TSAs that are part of applicant certification authorities that want to be recognized as issuing digital signing credentials approved by the CAWG, must satisfy the requirements of the program to be considered approved and designated as such within its governance records.

Transport Layer Security (or TLS)

Definition pending.

Trusted execution environment (or TEE)

Definition pending.

Trusted role

Definition pending.

4. Standard terms

The key words “MUST,” “MUST NOT,” “REQUIRED,” “SHALL,” “SHALL NOT,” “SHOULD,” “SHOULD NOT,” “RECOMMENDED,” “NOT RECOMMENDED,” “MAY,” and “OPTIONAL” in this document are to be interpreted as described in BCP 14, RFC 2119, and RFC 8174 when they appear in any casing (upper, lower, or mixed).

5. Publication and repository responsibilities

This section outlines the mechanisms for disseminating the certificate policy and the practices for maintaining a repository of issued certificates.

5.1. Repositories

The CA MUST make revocation information for subordinate CA certificates and subscriber certificates available in accordance with this policy.

5.2. Publication

This CP and the CAWG trust list containing CAs that issue certificates under this CP MUST be made publicly available on the CAWG website (https://cawg.io), ensuring transparency and accessibility for all interested parties.

Update link once CAWG chooses its new name.

A CA issuing certificates under this CP is required to disclose certain business practices as defined in this CP. This requirement may be met with a publicly disclosed CPS or another method defined by the CA in consultation with CAWG.

5.3. Repositories

There are two subsections titled "Repositories" here. Can we merge them?

A CA issuing certificates under this CP MUST establish and maintain an internal, secure repository containing records of all certificates issued under this CP. A record for an issued certificate MUST be stored for at least 1 year after its expiry date. Records in this repository MUST include essential details such as certificate serial numbers, subject names, validity periods, X.509v3 extensions and their values, and revocation status. The repository MUST be subject to stringent access controls and regular audits to ensure its integrity and confidentiality.

5.4. Time or frequency of publication

The CA MUST develop, implement, enforce, and annually update a certificate policy and/or certification practice statement (CP and/or CPS) that describes in detail how the CA implements the latest version of these requirements. The CA MUST review and update its CP and/or CPS at least every 365 days, incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document.

6. Identification and authentication

6.1. Naming

No stipulation.

6.1.1. Types of names

When the subject:commonName of a certificate issued to an individual does not contain a mailbox address, it is specified as a personal name or pseudonym as described in Section 10.1.4.2.2, “Subject distinguished name fields”(a).

Review reference to mailbox address. May not apply to CAWG.

Names consisting of multiple words are permitted. Given names joined with a hyphen are considered as one single given name. Subjects with more than one given name MAY choose one or several of their given names in any sequence. Subjects MAY choose the order of their given name(s) and surname in accordance with national preference.

The CA MAY allow common variations or abbreviations of personal names consistent with local practice.

6.1.2. The use of meaningful names

Personal names MUST be a meaningful representation of the subject’s name as verified in the identifying documentation or enterprise RA records.

6.1.3. Anonymity or pseudonymity of subscribers

The purpose of a pseudonym is to provide a unique identifier linked to an individual in a pseudonymized manner when certain privacy conditions are required. For example, a pseudonym may be used if a government agency requires officials to sign certain decisions via S/MIME so those decisions trace back to individuals, but emphasize the importance of the role over individual identity in the certificate. The CA MUST disclose in its CP and/or CPS if it allows the use of pseudonyms.

For Sponsor-validated certificates, the CA MAY use a subject:pseudonym attribute in the certificate if the associated subject has been verified according to Section 6.2.2, “Authentication of individual identity”. If present, the subject:pseudonym attribute MUST be:

  1. either a unique identifier selected by the CA for the subject of the certificate; or

  2. an identifier selected by the enterprise RA which uniquely identifies the subject of the certificate within the organization included in the subject:organizationName attribute.

For Individual-validated certificates, the CA MAY use the subject:pseudonym attribute if the associated subject has been verified according to Section 6.2.2, “Authentication of individual identity”. If present, the subject:pseudonym attribute MUST be:

  1. either a unique identifier selected by the CA for the subject of the certificate; or

  2. an identifier verified based on government-issued identity documents.

Pseudonym certificates are not anonymous. CAs and enterprise RAs MUST treat individual identity information relating to a pseudonym as private in accordance with [information-treated-as-private].

6.1.4. Uniqueness of names

The subjects of claim signing subscribers shall be unique. Name uniqueness is not violated when multiple certificates are issued to the same entity. For example, A CA MAY issue certificates with the same subject DN under this CP to multiple units of the same organization.

Revisit use of “claim signing subscriber” above. May be hold over from C2PA.

6.2. Initial identity validation

The CA MUST authenticate the identity attributes of the subject to be included in the S/MIME certificate according to the requirements of the following sections:

Certificate type Organization identity Individual identity

Organization-validated

Section 6.2.1

N/A

Sponsor-validated

Section 6.2.1

Section 6.2.2

Individual-validated

N/A

Section 6.2.2

6.2.1. Authentication of organization identity

The following requirements MUST be fulfilled to authenticate organization identity included in the Organization-validated and Sponsor-validated profiles.

6.2.1.1. Attribute collection of organization identity

The CA or RA MUST collect and retain evidence supporting the following identity attributes for the organization:

  1. Formal name of the legal entity;

  2. A registered assumed name for the legal entity (if included in the subject);

  3. An affiliate of the legal entity as described in Section 10.1.4.2.2, “Subject distinguished name fields” (if included in the subject as an subject:organizationalUnitName);

  4. An address of the legal entity (if included in the subject);

  5. Jurisdiction of incorporation or registration of the legal entity; and

  6. Identifier and type of identifier for the legal entity.

The identifier MUST be included in the certificate subject:organizationIdentifier as specified in Section 10.1.4.2.2, “Subject distinguished name fields” and Appendix A.

Fix up link to Appendix A. Not quite sure where this was meant to go.

6.2.1.2. Validation of organization identity

If an attestation is used as evidence for the validation of the attributes described in this section, then the attestation MUST be verified for authenticity as described in Section 6.2.6, “Reliability of verification sources”.

6.2.1.2.1. Verification of name, address, and identifier

The CA or RA MUST verify the full legal name and an address (if included in the certificate subject) of the legal entity applicant using documentation provided by, or through communication with, at least one of the following:

  1. A government agency in the jurisdiction of the legal entity’s creation, existence, or recognition;

  2. A legal entity identifier (LEI) data reference;

  3. A site visit by the CA or a third party who is acting as an agent for the CA; or

  4. An attestation which includes a copy of supporting documentation used to establish the applicant’s legal existence (such as a certificate of registration, articles of incorporation, operating agreement, statute, or regulatory act) and its current status.

The CA or RA MAY use the same documentation or communication described in 1 through 4 above to verify both the applicant’s identity and address.

In cases 1 and 4 above, the CA or RA MUST verify that the status of the applicant is not designated by labels such as “ceased,” “inactive,” “invalid,” “not current,” or the equivalent.

In case 2 above when LEI data reference is used, the CA or RA MUST verify that the RegistrationStatus is ISSUED and the EntityStatus is ACTIVE. The CA MUST only allow use of an LEI if the ValidationSources entry is FULLY_CORROBORATED. An LEI MUST NOT be used if the ValidationSources entry is PARTIALLY_CORROBORATED, PENDING, or ENTITY_SUPPLIED_ONLY.

6.2.1.2.2. Verification of assumed name

Applicants MAY request an assumed name to be included in the certificate. The CA or RA MUST verify that:

  1. The applicant has registered its use of the assumed name with the appropriate government agency for such filings in the jurisdiction of its incorporation or registration; and

  2. The assumed name filing continues to be valid.

The CA MAY rely on an attestation that indicates the assumed name under which the applicant conducts business, the government agency with which the assumed name is registered, and that such filing continues to be valid.

6.2.1.3. Disclosure of verification sources

The CA or RA MUST verify the registration reference to be included in the certificate from a register that is maintained or authorized by the relevant government agency. The CA MUST disclose the authorized sources it uses to verify the applicant’s creation, existence, or recognition. This disclosure MUST be through an appropriate and readily accessible online means. The CA MUST document where to obtain this information within Section 3.2 of the CA’s CP and/or CPS.

Nothing in these requirements prohibits the use of third-party vendors to obtain regularly-updated and current information from the government register provided that the third party obtains the information directly from the government.

In the case of a LEI data reference, the CA or RA MUST verify the associated data record with the Global Legal Entity Identifier Foundation.

6.2.2. Authentication of individual identity

The following requirements MUST be fulfilled to authenticate individual identity attributes included in Sponsor-validated and Individual-validated certificate profiles.

The CA, RA, or enterprise RA MUST collect and retain evidence supporting the following identity attributes for the individual applicant:

  1. Given name(s) and surname(s), which MUST be current names;

  2. Pseudonym (if used);

  3. Title (if used);

  4. Address (if displayed in subject); and

  5. Further information as needed to uniquely identify the applicant.

The CA or RA MUST comply with applicable data protection legislation in the gathering and retention of evidence relating to individual identity supporting this requirement in accordance with [information-treated-as-private].

6.2.2.1. Attribute collection of individual identity

The CA MUST document and publish the methods it uses to collect individual identity attributes.

6.2.2.1.1. From a physical identity document

If physical identity documents are used to provide evidence, the CA or RA MUST accept only government-issued passports or identity cards, and other official identity documents of comparable reliability (such as drivers license or military ID).

The physical identity document used as evidence MUST contain a face photo and/or other information that can be compared with the applicant’s physical appearance.

The CA MUST document and publish information describing the physical or digital identity documents or document types it accepts.

6.2.2.1.2. From a digital identity document

If digital identity documents (such as government-issued passports or national ID cards including a chip bearing digitally signed information about the holder) are used to provide evidence, the CA or RA MUST only accept eMRTD digital identity documents in compliance with ICAO 9303 part 10.

This method does not include “eID” as described in Regulation (EU) 910/2014.

6.2.2.1.3. Using electronic identification schemes (eID)

If an eID is used to provide evidence, the CA or RA MUST only accept “notified” eID schemes according to Article 9 of the eIDAS Regulation and the eID shall conform to eIDAS LoA “Substantial” or “High.”

The CA MUST document and publish information describing the eID and associated eID attributes it accepts.

6.2.2.1.4. From a certificate supporting a digital signature applied by the applicant

If a digital signature is used to provide evidence, the CA or RA MUST have the applicant digitally sign the certificate request using a valid personal certificate that was issued under an approved framework described in Section 6.2.2.1.5, “Approved frameworks”.

Identity attributes are evidenced by the signing certificate, not by the content of the signed document. The CA or RA MUST only rely upon the signing certificate as evidence for identity attributes if the digital signature is valid in accordance with the requirements of the relevant approved framework.

The CA SHOULD consider requirements to avoid issuance of consecutive certificates that are issued based on a preceding certificate, where the original verification of the subject’s identity may have been conducted in the distant past.

6.2.2.1.5. Approved frameworks

Identify the approved frameworks.

6.2.2.1.6. Criteria to propose additional frameworks

The CA/Browser Forum S/MIME certificate Working Group may consider additional trust service frameworks that provide an equivalent level of security and validation compared to these requirements. Proposals that evaluate the additional framework against the following criteria MAY be submitted to the questions@cabforum.org mailing list:

S/MIME leftover: this routes new identity frameworks to the CA/B Forum S/MIME Working Group, and the approved frameworks are to be added by ballot. CAWG can’t change its policy through CA/B Forum ballots. Suggest the CAWG Governing Authority approves additional frameworks and lists them in this CP.

  • Legal context: the framework MUST be subject to regulatory provisions, which describe the requirements imposed on the certificate issuer/trust service provider, the legal effects of the trust services, and the corresponding certificate levels;

  • Identity validation: the approved certificate levels must provide a level of assurance equivalent to that of the identity validation methods described in these requirements;

  • Supervision and auditing systems: the framework MUST include appropriate rules providing for:

    • supervision to ensure that trust service providers meet regulatory-imposed provisions;

    • requirements imposed on auditing bodies when conducting audits; and

    • supervision of the auditing bodies.

  • Best practices and transparency: the requirements of the trust service framework and evidence of supervision of the approved trust service providers MUST be publicly available. The trust service framework shall require trust service providers to disclose their practices in a publicly available CP and/or CPS.

6.2.2.1.7. From enterprise RA records

In the case of Sponsor-validated certificates approved by an enterprise RA, records maintained by the enterprise RA MUST be accepted as evidence of individual identity.

The enterprise RA MUST maintain records to satisfy the requirements of Registration authority (or RA) and [review-of-delegated-parties].

6.2.2.1.8. Affiliation from company attestation

In the case of Sponsor-validated certificates not approved by an enterprise RA, the CA or RA MAY verify the authority or affiliation of an individual to represent an organization to be included in the subject:organizationName of the certificate using an attestation provided by the organization and verified in accordance with Section 6.2.6, “Reliability of verification sources”.

The CA or RA MUST still verify the identity of the individual in accordance with Section 6.2.2, “Authentication of individual identity” and the organization in accordance with Section 6.2.1, “Authentication of organization identity”.

6.2.2.1.9. From a general attestation

Evidence for individual identity attributes MAY be gathered using an attestation from a qualified legal practitioner or notary in the applicant’s jurisdiction.

6.2.2.1.10. From authorized reference sources as supplementary evidence

Evidence for individual identity attributes MUST use at least one of the following sources for authoritative evidence: a physical or digital identity document, an eligible eID, an eligible mDL, digital signature supported by certificate, enterprise RA records, or suitable attestation.

The CA or RA MAY additionally gather and verify supplementary evidence using authorized sources such as additional official documents, government or regulatory registers, or national population registers.

Examples of this method include:

  • If the subject presents an ID featuring an applicant name that has subsequently been changed, the evidence MAY be complemented by inspection of an official document such as a marriage certificate or court order documenting the change.

  • If a professional title of a regulated profession in the subject:country, or a corporate title linked to the subject:organizationName, is to be used it MUST be verified against supporting documentation, a reliable data source, or attestation.

  • In cases where the “role” LEI is included in an extension of a Sponsor-validated certificate, the CA MUST verify that the LEI is assigned to the individual and the subject:organizationName in the certificate subject.

  • The CA MAY verify the address (but not the identity) of the applicant using a utility bill, bank statement, credit card statement, government-issued tax document, or other form of identification that the CA determines to be reliable.

The CA MUST internally document the accepted reference sources, including a description of the documents or attestations accepted as supplementary evidence.

6.2.2.1.11. From a mobile driver license (mDL)

If an mDL is used to provide evidence, the CA or RA MUST only accept an mDL that:

  • is issued by an issuing authority that is legally authorized by the relevant government or jurisdiction to issue driving licenses;

  • conforms to ISO/IEC 18013-5;

  • supports validation through the verification protocols defined in ISO/IEC 18013-7; and

  • can demonstrate a valid certificate chain from the Document signer certificate to an issuing authority certificate that is verifiable through a publicly available trust anchor or trust list approved by the issuing jurisdiction.

The CA MUST document and publish information describing the issung jurisdictions and mDL versions it accepts.

6.2.2.2. Validation of individual identity

The CA or RA MUST validate all identity attributes of the individual to be included in the certificate.

If the evidence has an explicit validity period, the CA MUST verify that the time of the identity validation is within this validity period. In context this can include the notBefore and notAfter fields of a digital signature certificate or the date of expiry of an identity document.

The CA or RA MAY reuse existing evidence to validate individual identity subject to the age restrictions in Section 7.3.1, “Performing identification and authentication functions”.

6.2.2.2.1. Validation of a physical identity document

The physical identity document MUST be presented in its original form. The CA MUST employ procedures to ensure the evidence presented by the applicant is a genuine identity document that is not counterfeited or falsified/modified.

The CA or RA MAY use manual (in person) or remote procedures. A remote process MUST ensure that the applicant has the document in hand and presents the document in real-time in front of a camera.

The CA or RA registration agent MUST make a visual comparison of the physical appearance of the applicant and the face photo and/or other information on the physical identity document.

The CA or RA registration agent MUST have access to authoritative sources of information on document appearance and validation for forms of identity document accepted by the CA.

The CA or RA MUST retain information sufficient to evidence the fulfillment of the identity validation process and the verified attributes. In addition to identity attributes, the CA or RA MUST record the following information: issuer, validity period, and the document’s unique identification number.

Automated and manual processes MAY be used in combination, (for example the CA or RA may deploy automated tools to support the work of a registration agent, or an automated process that falls back to a registration agent if the process yields an uncertain result).

6.2.2.2.2. Validation of a digital identity document

The CA or RA MUST only accept digital identity documents if the issuer’s digital signature on the document is successfully validated against the relevant country signing certificates (e.g., from the ICAO public key database).

The CA or RA MUST record information obtained from the digital identity document to evidence the identity proofing process. In addition to identity attributes and face photo, the following information MUST be recorded: issuer, validity period, and the document’s unique identification number.

The CA or RA registration agent MUST make a visual comparison of the physical appearance of the applicant and the face photo and/or other information on the digital identity document.

Automated and manual processes MAY be used in combination. (For example, using automated tools to support the work of a registration agent, or an automated process that falls back to a registration agent if the process yields an uncertain result.)

6.2.2.2.3. Validation of eID

If authentication using an eID is used to provide evidence, the CA or RA MUST confirm that the eID scheme is suitable (i.e., that the eID is accessible via a “notified” eIDAS-Node), and that the individual eID is valid (i.e., not expired, suspended, or revoked).

The authentication using the eID MUST be created as part of the identity validation process, and evidence of the validation with the eID’s Identity Provider (IdP) MUST be retained by the CA or RA.

6.2.2.2.4. Validation of digital signature with certificate

If a digital signature with certificate is used to provide evidence, the signature MUST be created as part of the identity validation process.

The CA or RA MUST validate the digital signature and MUST only use the signing certificate as evidence for identity attributes if the signature is valid.

If required identity attributes to be collected are not present in the certificate, the CA or RA MUST collect these attributes from other sources and validate them accordingly.

6.2.2.2.5. Validation using an enterprise RA record

An enterprise RA issuing a sponsor-validated certificate MUST validate all identity attributes of an individual to be included in the certificate. The enterprise RA MAY rely upon existing internal records to validate individual identity.

6.2.2.2.6. Validation of affiliation from a company attestation

The reliability of the attestation MUST be verified according to Section 6.2.6, “Reliability of verification sources”.

6.2.2.2.7. Validation of a general attestation

The reliability of the attestation MUST be verified according to Section 6.2.6, “Reliability of verification sources”.

6.2.2.2.8. Validation of a supplementary evidence

No stipulation.

6.2.2.2.9. Validation of an mDL

If an mDL is used to provide evidence, the CA or RA MUST:

  • Authenticate to the mDL holder’s device and request data in conformance with ISO/IEC 18013-5 and ISO/IEC 18013-7;

  • Verify the authenticity and integrity of the mDL data through validation of the Mobile Security Object (MSO) and its signature chain;

  • Validate the document signer certificate chain against the issuing jurisdiction’s published trust infrastructure; and

  • Verify that the mDL is current and has not been revoked or expired.

The mDL authentication MUST be performed in real-time as part of the identity validation process, and MUST NOT rely on previously captured mDL data.

6.2.3. Non-verified subscriber information

Subscriber information that has not been verified in accordance with these requirements MUST NOT be included in publicly-trusted S/MIME certificates.

Reword since this isn’t an S/MIME policy document.

6.2.4. Validation of authority

Before commencing to issue Organization-validated and Sponsor-validated certificates for an applicant, the CA or RA MUST use a reliable method of communication to verify the authority and approval of an applicant representative to perform one or more of the following:

  • to act as an enterprise RA;

  • to request issuance or revocation of certificates; or

  • to assign responsibilities to others to act in these roles.

The CA or RA MAY establish a process that allows an applicant to specify the individuals who may act as applicant representatives on an ongoing basis. The CA MUST provide an applicant with a list of its authorized applicant representatives upon the applicant’s verified written request.

The CA or RA MAY use the sources listed in Section 6.2.1.1, “Attribute collection of organization identity” to verify the reliable method of communication. Provided that the CA or RA uses a reliable method of communication, the CA or RA MAY establish the authenticity of the certificate request directly with the applicant representative or with an authoritative source within the applicant’s organization, such as the applicant’s main business offices, corporate offices, human resource offices, information technology offices, or other department that the CA or RA deems appropriate.

6.2.5. Criteria for interoperation

The CA MUST disclose all cross certificates that identify the CA as the subject, provided that the CA arranged for or accepted the establishment of the trust relationship (i.e., the cross certificate at issue).

6.2.6. Reliability of verification sources

Before relying on a source of verification data to validate certificate requests, the CA MUST verify its suitability as a reliable data source. Enterprise RA records are a reliable data source for individual subject attributes included in sponsor-validated certificates issued to the enterprise RA’s organization.

The CA or RA MAY rely upon a letter attesting that subject information or other fact is correct. The CA or RA MUST verify that the letter was written by an accountant, lawyer, government official, or other reliable third party in the applicant’s jurisdiction customarily relied upon for such information.

An attestation MUST include a copy of documentation supporting the fact to be attested. The CA or RA MUST use a reliable method of communication to contact the sender and to confirm the attestation is authentic.

6.3. Identification and authentication for certificate issuance and certificate renewal

The CA MUST require the use of secure access credentials (for example, usernames and passwords, client certificates, or bearer tokens) for certificate enrollment.

The CA MUST verify the subscriber’s ownership of the key pair for which certificate issuance is requested, for example by verifying a signed certificate signing request (CSR) provided by the subscriber, or by inspecting relevant configuration in a key management system.

6.4. Ongoing subscriber identification and authentication

The CA MUST re-authenticate the identity of the subscriber after no more than TBD days since the last authentication, using the procedure described under Section 6.2, “Initial identity validation”.

Inconsistent: TBD days here, while the validation-data reuse rules allow 825 days. Pick one value; suggest re-validating organizations at least every 825 days and individuals no longer than the certificate validity.

6.5. Identification and authentication for re-key requests

All requests for subscriber certificate re-key MUST be treated in the same manner as applications for new certificates, and the CA MUST perform the same identity validation processes as defined in Section 6.3, “Identification and authentication for certificate issuance and certificate renewal”.

6.6. Identification and authentication for revocation requests

Revocation requests MAY be initiated by the subscriber, the CA, or the CAWG. If the request is subscriber or CAWG initiated, the CA MUST authenticate the requestor and verify the authenticity and validity of the revocation request. Once authentication is completed and the authenticity and validity of the request are verified, the CA MUST revoke the certificate within 72 hours.

Inconsistent: 72 hours here, but the revocation reasons section uses 24 hours and 5 days. Suggest keeping the 24h/5d timings and removing this sentence.

7. Certificate life-cycle operational requirements

7.1. Certificate application

The applicant initiates the certificate request process by submitting a formal application to become a subscriber using the method designated by the CA. The applicant MUST provide all requisite information and documentation as specified in this CP. This includes:

  1. information about the individual or organization for which the certificate is requested, and

  2. the assurance level of the certificates which the applicant will be requesting for their claim signing certificate.

Revisit use of “claim signing certificate.”

7.2. Enrollment process and responsibilities

Prior to the issuance of a certificate, the CA MUST obtain the following documentation from the applicant:

The certificate request and subscriber agreement or terms of use MUST be in a form prescribed by the CA and MUST comply with these requirements including Section 12.6, “Representations and warranties”. The CA SHOULD obtain any additional documentation the CA determines necessary to fulfill these requirements.

The certificate request MUST contain a request from, or on behalf of, the applicant for the issuance of a certificate, and a certification by, or on behalf of, the applicant that all of the information contained therein is correct.

One certificate request MAY suffice for multiple certificates to be issued to the same applicant, subject to the validation reuse periods described in Section 7.3.1, “Performing identification and authentication functions”, provided that each certificate is supported by a valid, current certificate request signed by the appropriate applicant representative on behalf of the applicant.

A CA may rely on a previously verified certificate request to issue a replacement certificate if:

  1. the previous certificate being referenced was not revoked,

  2. the expiration date of the replacement certificate is the same as the previous certificate being referenced, and

  3. the subject information of the certificate is the same as the previous certificate being referenced.

7.3. Certificate application processing

7.3.1. Performing identification and authentication functions

Applicant information MUST include, but not be limited to, at least one mailbox field to be included in the certificate’s subjectAltName extension.

S/MIME leftover with a privacy cost: this requires an email address in the SAN, and commonName may also be an email address. A CAWG certificate is embedded in every asset the subscriber signs, permanently, so this publishes their email with all their content. Suggest making email optional and off by default; the mailbox-control revocation reasons and Enterprise RA domain-control rules would go with it.

The CA MAY reuse completed validations and/or supporting evidence performed in accordance with Section 6.2, “Initial identity validation”, within the following limits:

  1. Authentication of organization identity: Completed validation of organization identity in accordance with Section 6.2.1, “Authentication of organization identity”, MUST be obtained no more than 825 days prior to issuing the certificate.

    Validation of authority in accordance with Section 6.2.4, “Validation of authority”, MUST be obtained no more than 825 days prior to issuing the certificate, unless a contract between the CA and the applicant specifies a different term. For example, the contract MAY include the perpetual assignment of roles until revoked by the applicant or CA, or until the contract expires or is terminated.

  2. Authentication of individual identity: Completed validation of individual identity in accordance with Section 6.2.2, “Authentication of individual identity” MUST be obtained no more than 825 days prior to issuing the certificate.

A prior validation MUST NOT be reused if any data or document used in the prior validation was obtained more than the maximum time permitted for reuse of the data or document prior to issuing the certificate.

7.3.2. Certificate issuance

  1. All certificate signing operations performed by a root CA MUST be performed by at least two individuals in trusted roles (i.e. the CA system operator, system officer, or PKI administrator). One of these individuals must deliberately command the root CA to perform a certificate signing operation.

  2. All CA certificates issued by the CA MUST follow a documented process. All CA certificate issuance MUST be performed by personnel in trusted roles under the principles of multiple person control and split knowledge.

  3. Time stamping certificate issuance MUST follow identification, authentication, and verification processes as documented in the CA’s business practices.

  4. Claim signing certificate issuance MUST be subject to the process outlined in Section 6.3, “Identification and authentication for certificate issuance and certificate renewal”.

7.4. Certificate acceptance

  1. Certificate acceptance by the subscriber MUST indicate the subscriber’s acceptance of the terms of a subscriber agreement that includes required stipulations of this CP.

  2. The acceptance MUST be implicit through successful installation and use of the certificate by an instance of the generator product.

    C2PA leftover: implicit acceptance by a generator product is the device model. A person or organization should accept the certificate explicitly through the Subscriber Agreement.

  3. Certificates issued under this CP are to be used exclusively by individual or organizations named as subjects of the certificates, to digitally sign CAWG claims at the assurance level indicated by the certificate. Any usage for any other purpose is strictly prohibited.

7.5. Key pair and certificate usage

  1. Private keys corresponding to root certificates MUST NOT be used to create signatures except for the following purposes:

    1. Self-signed certificates to represent the root CA itself;

    2. Certificates for subordinate CAs and cross-certified CA certificates;

    3. Certificates for OCSP responders; and

    4. Certificate revocation lists.

  2. Private keys corresponding to intermediate CA certificates where the Basic Constraints contains pathLenContraint=1 MUST NOT be used to sign certificates except in the following cases:

    1. Certificates for subordinate CAs

    2. Certificates for infrastructure purposes (administrative role certificates, internal CA operational device certificates); and

    3. Certificates for OCSP response verification.

  3. Subscriber claim signing and time stamping certificates MUST only be issued by subordinate CAs where the Basic Constraints contains a pathLenConstraint=0.

  4. The use of a specific key is determined by the key usage extension in the X.509 certificate.

  5. The private key associated with the public key to which a claim signing certificate has been issued under this CP MUST remain under the exclusive control of the subscriber and MUST NOT be exported.

  6. Claim signing certificates issued under this CP are to be used exclusively by individuals or organizations named as subjects of the certificates, to digitally sign CAWG claims at the assurance level indicated by the certificate. Any usage for any other purpose is strictly prohibited.

  7. Time stamping certificates issued under this CP are to be used exclusively by the time stamping authority or unit named as subjects of the certificates to provide time stamping services.

  8. OCSP responder certificates issued under this CP are to be used exclusively to sign OCSP responses for certificates issued by the OCSP responder certificate’s issuing CA.

  9. Any other use of a private key or certificate shall be deemed as misuse and its corresponding certificate subject to revocation per certificate revocation.

7.6. Certificate renewal

Certificate renewal with the same key is not permitted, and the CA MUST NOT issue a new certificate for a key pair for which it had previously issued a certificate.

7.7. Certificate re-key

All requests for subscriber certificate re-key shall be treated identical to applications for new certificates, and the CA MUST perform the same identity validation processes as defined in Section 6.3, “Identification and authentication for certificate issuance and certificate renewal”.

7.8. Certificate modification

Certificate modifications MUST NOT be permitted by CAs operating in conformance with this CP. If changes to the subject information are necessary, the CA and the subscriber MUST follow the process outlined in Section 6.2, “Initial identity validation”.

7.9. Certificate revocation and suspension

7.9.1. Circumstances for revocation

7.9.1.1. Reasons for revoking a subscriber certificate

The CA MUST revoke a certificate within 24 hours if one or more of the following occurs:

  1. the subscriber requests in writing that the CA revoke the certificate,

  2. the subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization,

  3. the CA obtains evidence that the subscriber’s private key corresponding to the public key in the certificate suffered a key compromise,

  4. the CA is made aware of a demonstrated or proven method that can easily compute the subscriber’s private key based on the public key in the certificate (such as a Debian weak key, see https://wiki.debian.org/SSLkeys), or

  5. the CA obtains evidence that the validation of domain authorization or mailbox control for any mailbox address in the certificate should not be relied upon.

Revisit reference to mailboxes. Probably not relevant for CAWG.

The CA SHOULD revoke a certificate within 24 hours and MUST revoke a certificate within 5 days if one or more of the following occurs:

  1. the certificate no longer complies with the requirements of Section 9.1.5, “Key sizes” and Section 9.1.6, “Public key parameters generation and quality checking”,

  2. the CA obtains evidence that the certificate was misused,

  3. the CA is made aware that a subscriber has violated one or more of its material obligations under the subscriber agreement or terms of use,

  4. the CA is made aware of any circumstance indicating that use of an email address or fully-qualified domain name in the certificate is no longer legally permitted (e.g., a court or arbitrator has revoked the right to use an email address or domain name, a relevant licensing or services agreement between the subscriber has terminated, or the account holder has failed to maintain the active status of the email address or domain name),

    Revisit reference to mailboxes. Probably not relevant for CAWG.

  5. the CA is made aware of a material change in the information contained in the certificate,

  6. the CA is made aware that the certificate was not issued in accordance with these requirements or the CA’s CP and/or CPS,

  7. the CA determines or is made aware that any of the information appearing in the certificate is inaccurate,

  8. the CA’s right to issue certificates under these requirements expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP repository,

  9. revocation is required by the CA’s CP and/or CPS, or

  10. the CA is made aware of a demonstrated or proven method that exposes the subscriber’s private key to compromise or if there is clear evidence that the specific method used to generate the private key was flawed.

7.9.1.2. Reasons for revoking a subordinate CA certificate

The issuing CA MUST revoke a subordinate CA certificate within seven (7) days if one or more of the following occurs:

  1. the subordinate CA requests revocation in writing;

  2. the subordinate CA notifies the issuing CA that the original certificate request was not authorized and does not retroactively grant authorization;

  3. the issuing CA obtains evidence that the subordinate CA’s private key corresponding to the public key in the certificate suffered a key compromise or no longer complies with the requirements of Section 9.1.5, “Key sizes” and Section 9.1.6, “Public key parameters generation and quality checking”;

  4. the issuing CA obtains evidence that the certificate was misused;

  5. the issuing CA is made aware that the certificate was not issued in accordance with or that subordinate CA has not complied with this document or the applicable CP and/or CPS;

  6. the issuing CA determines that any of the information appearing in the certificate is inaccurate or misleading;

  7. the issuing CA or subordinate CA ceases operations for any reason and has not made arrangements for another CA to provide revocation support for the certificate;

  8. the issuing CA’s or subordinate CA’s right to issue certificates under these requirements expires or is revoked or terminated, unless the issuing CA has made arrangements to continue maintaining the CRL/OCSP repository; or

  9. revocation is required by the issuing CA’s CP and/or CPS.

7.9.2. Who can request revocation

The subscriber, RA, or issuing CA can initiate revocation. Additionally, subscribers, relying parties, application software suppliers, and other third parties MAY submit certificate problem reports informing the issuing CA of reasonable cause to revoke a certificate.

7.9.3. Procedure for revocation request

The CA MUST provide a process for subscribers to request revocation of their own certificates. The process MUST be described in the CA’s CP and/or CPS. The CA MUST maintain a continuous 24x7 ability to accept and respond to revocation requests and certificate problem reports.

The CA MUST provide clear instructions for reporting suspected private key compromise, certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to certificates. The CA MUST publicly disclose the instructions through a readily accessible online means and in Section 1.5.2 of their CPS.

Do we know that the CPS will still have the same section 1.5.2 reference?

7.9.4. Revocation request grace period

No stipulation.

7.9.5. Time within which CA must process the revocation request

Within 24 hours after receiving a certificate problem report, the CA MUST investigate the facts and circumstances related to a certificate problem report and provide a preliminary report on its findings to both the subscriber and the entity who filed the certificate problem report.

After reviewing the facts and circumstances, the CA MUST work with the subscriber and any entity reporting the certificate problem report or other revocation-related notice to establish whether or not the certificate will be revoked, and if so, a date on which the CA will revoke the certificate. The period from receipt of the certificate problem report or revocation-related notice to published revocation MUST NOT exceed the time frame set forth in Section 7.9.1.1, “Reasons for revoking a subscriber certificate”. The date selected by the CA SHOULD consider the following criteria:

  1. the nature of the alleged problem (scope, context, severity, magnitude, risk of harm),

  2. the consequences of revocation (direct and collateral impacts to subscribers and relying parties),

  3. the number of certificate problem reports received about a particular certificate or subscriber,

  4. the entity making the complaint (for example, a complaint from a law enforcement official should be addressed with higher priority), and

  5. relevant legislation.

7.9.6. Revocation checking requirement for relying parties

No stipulation.

Following certificate issuance, a certificate may be revoked for reasons stated in Section 7.9, “Certificate revocation and suspension”. Therefore, relying parties SHOULD check the revocation status of all certificates that contain a CDP or OCSP pointer.

7.9.7. CRL issuance frequency

For the status of subscriber certificates: the CA MUST update and reissue CRLs at least once every seven days, and the value of the nextUpdate field MUST NOT be more than ten days beyond the value of the thisUpdate field.

For the status of subordinate CA certificates: the CA MUST update and reissue CRLs at least:

  1. once every twelve months; and

  2. within 24 hours after revoking a subordinate CA certificate.

The value of the nextUpdate field MUST NOT be more than twelve months beyond the value of the thisUpdate field.

7.9.8. Maximum latency for CRLs

No stipulation.

7.9.9. On-line revocation/status checking availability

When provided, OCSP responses MUST conform to RFC 6960 and/or RFC 5019. OCSP responses MUST either:

  1. be signed by the CA that issued the certificates whose revocation status is being checked, or

  2. be signed by an OCSP responder whose certificate is signed by the CA that issued the certificate whose revocation status is being checked.

In the latter case, the OCSP signing certificate MUST contain the ocspSigning EKU (1.3.6.1.5.5.7.3.9) and an extension of type id-pkix-ocsp-nocheck, as defined by RFC 6960.

7.9.10. On-line revocation checking requirements

OCSP responders operated by the CA MUST support the HTTP GET method, as described in RFC 6960 and/or RFC 5019.

The validity interval of an OCSP response is the difference in time between the thisUpdate and nextUpdate field, inclusive. For purposes of computing differences, a difference of 3,600 seconds MUST be equal to one hour, and a difference of 86,400 seconds MUST be equal to one day, ignoring leap seconds.

For the status of subscriber certificates:

  1. OCSP responses MUST have a validity interval greater than or equal to eight hours;

  2. OCSP responses MUST have a validity interval less than or equal to ten days;

  3. for OCSP responses with validity intervals less than sixteen hours, then the CA MUST update the information provided via an online certificate status protocol prior to one-half of the validity period before the nextUpdate; and

  4. for OCSP responses with validity intervals greater than or equal to sixteen hours, then the CA MUST update the information provided via an online certificate status protocol at least eight hours prior to the nextUpdate, and no later than four days after the thisUpdate.

For the status of subordinate CA certificates, the CA MUST update information provided via OCSP:

  1. at least every twelve months, and

  2. within 24 hours after revoking a subordinate CA certificate.

If the OCSP responder receives a request for the status of a certificate serial number that is “unused,” then the responder SHOULD NOT respond with a “good” status. If the OCSP responder is for a CA that is not technically-constrained in line with Section 10.1.5, “Name constraints”, the responder MUST NOT respond with a “good” status for such requests.

A certificate serial number within an OCSP request is “assigned” if a certificate with that serial number has been issued by the issuing CA, using any current or previous key associated with that CA subject, or “unused” if otherwise.

7.10. End of subscription

Upon termination of the subscription or cessation of relevant activities, the subscriber MUST follow industry best practices for destroying the private key(s).

7.11. Key escrow and recovery

The CA MAY escrow the subscriber’s private key as specified in the CA’s CP and/or CPS.

Critical, key escrow: escrow suits S/MIME encryption keys but defeats attribution for a signing key, because if the CA holds a copy the signature no longer proves the subscriber made it. It also contradicts the MUST NOT be exported rule.

Suggest: Subscriber signing keys MUST NOT be escrowed, archived or backed up by the CA or any RA. The same applies to the private key Escrow section and the validity section that lets the CA keep escrowed keys after expiry.

The CA MUST notify subscribers when their private keys are escrowed. Escrowed private keys MUST be stored in encrypted form. The CA MUST protect escrowed private keys from unauthorized disclosure.

The CA MUST recover subscriber private keys only under the circumstances permitted within the CA’s CP and/or CPS.

8. Facility, management, and operational controls

This section details the physical, procedural, and personnel controls necessary to safeguard the CA’s operations and maintain the integrity of the PKI system, particularly as it relates to the issuance and management of certificates. While physical security remains important, the emphasis here is on logical and procedural controls, reflecting the nature of the environment where these certificates will be used.

The CA MUST develop, implement, and maintain a comprehensive security program designed to:

  1. protect the confidentiality, integrity, and availability of certificate data and certificate management processes;

  2. protect against anticipated threats or hazards to the confidentiality, integrity, and availability of the certificate data and certificate management processes;

  3. protect against unauthorized or unlawful access, use, disclosure, alteration, or destruction of any certificate data or certificate management processes;

  4. protect against accidental loss or destruction of, or damage to, any certificate data or certificate management processes; and

  5. comply with all other security requirements applicable to the CA by law.

The certificate management process MUST include:

  1. physical security and environmental controls;

  2. system integrity controls, including configuration management, integrity maintenance of trusted code, and malware detection/prevention;

  3. network security and firewall management, including port restrictions and IP address filtering;

  4. user management, separate trusted-role assignments, education, awareness, and training; and

  5. logical access controls, activity logging, and inactivity time-outs to provide individual accountability.

The CA’s security program MUST include an annual risk assessment that:

  1. identifies foreseeable internal and external threats that could result in unauthorized access, disclosure, misuse, alteration, or destruction of any certificate data or certificate management processes;

  2. assesses the likelihood and potential damage of these threats, taking into consideration the sensitivity of the certificate data and certificate management processes; and

  3. assesses the sufficiency of the policies, procedures, information systems, technology, and other arrangements that the CA has in place to counter such threats.

Based on the risk assessment, the CA MUST develop, implement, and maintain a security plan consisting of security procedures, measures, and products designed to achieve the objectives set forth above and to manage and control the risks identified during the risk assessment, commensurate with the sensitivity of the certificate data and certificate management processes. The security plan MUST include administrative, organizational, technical, and physical safeguards appropriate to the sensitivity of the certificate data and certificate management processes. The security plan MUST also take into account then-available technology and the cost of implementing the specific measures, and MUST implement a reasonable level of security appropriate to the harm that might result from a breach of security and the nature of the data to be protected.

8.1. Physical security controls

8.1.1. Site security

  1. The CA’s facilities housing critical PKI infrastructure and sensitive data MUST be located in a secure environment with controlled access. This MAY be a dedicated facility or a secure area within a larger building.

  2. Physical security measures, such as locks, access control systems, and visitor management procedures, should be implemented to prevent unauthorized physical access.

8.1.2. Restricted areas

  1. Areas containing sensitive systems or data, such as server rooms or data centers, MUST have restricted access, limited to authorized personnel only.

  2. Multi-factor authentication mechanisms MUST be deployed for accessing these restricted areas.

8.1.3. Equipment security

Critical equipment, including servers, network devices, and any hardware security modules (HSMs), MUST be physically secured to prevent unauthorized access, tampering, or theft.

8.2. Procedural controls

8.2.1. Documented procedures

Comprehensive and up-to-date documentation MUST be maintained for all CA operational procedures, including:

  1. Certificate issuance, renewal, and revocation processes.

  2. Key generation and management practices within devices or applications.

  3. Attestation validation procedures when required by a particular assurance level.

  4. Incident response and disaster recovery plans.

  5. Security policies, guidelines, and access control measures.

8.2.2. Separation of duties

  1. Critical functions, such as attestation validation, certificate issuance, and revocation, MUST be segregated among different individuals or teams to prevent conflicts of interest and minimize the risk of fraud or error.

  2. Dual control mechanisms MUST be deployed for physical access to CA equipment and any access required to perform specific CA operations (i.e., m of n rule where m represents the number of key shareholders required to perform an operation and n represents the total number of key shares).

  3. All certificate signing operations performed by a root CA MUST be performed by at least two individuals in trusted roles (i.e. the CA system operator, system officer, or PKI administrator).

8.2.3. Change management

  1. A formal change management process MUST be established to control and document all changes to the CA’s infrastructure, software, or procedures.

  2. All changes MUST undergo thorough testing and approval before implementation.

  3. Rollback and/or roll-forward plans MUST be in place to revert changes in the event of unforeseen issues.

8.3. Personnel controls

8.3.1. Clearances

The CA’s policies and procedures MUST specify the background checks and clearance procedures required for trusted roles and non-trusted roles. As a minimum, verification checks on permanent staff MUST be performed at the time of job application and every five years for those individuals undertaking trusted roles.

8.3.2. Training and awareness

  1. All personnel involved in CA operations MUST undergo regular security awareness training, including PKI concepts, data protection, incident response, attestation validation (if applicable), and their specific roles and responsibilities.

  2. Periodic retraining MUST occur to verify the continued trustworthiness of personnel involved in the activities related to key management and certificate management. This training MUST be performed if there is a material change in PKI operation.

8.3.3. Access control

  1. Access to CA systems and data MUST be granted on a need-to-know basis, adhering to the principle of least privilege.

  2. Strong password policies, multi-factor authentication, and regular access reviews MUST be implemented.

8.4. Audit logging procedures

8.4.1. Types of events recorded

The CA and each delegated third party MUST record events related to the security of their certificate systems, certificate management systems, root CA systems, and delegated third party systems. The CA and each delegated third party MUST record events related to their actions taken to process a certificate request and to issue a certificate, including all information generated and documentation received in connection with the certificate request; the time and date; and the personnel involved. The CA MUST make these records available to its qualified auditor as proof of the CA’s compliance with these requirements.

The CA MUST record at least the following events:

  1. CA certificate and key lifecycle events, including:

    1. key generation, backup, storage, recovery, archival, and destruction;

    2. certificate requests, renewal, and re-key requests, and revocation;

    3. approval and rejection of certificate requests;

    4. cryptographic device lifecycle management events;

    5. generation of certificate revocation lists;

    6. signing of OCSP responses (as described in Section 7.9, “Certificate revocation and suspension” and certificate status services; and

      No corresponding certificate status services section appears in the Google Doc. Determine whether to create one, and link to it here and from the audit logging requirements if appropriate.

    7. introduction of new certificate profiles and retirement of existing certificate profiles.

  2. Subscriber certificate lifecycle management events, including:

    1. certificate requests, renewal, and re-key requests, and revocation;

    2. all verification activities stipulated in these requirements and the CA’s certification practice statement;

    3. approval and rejection of certificate requests;

    4. issuance of certificates;

    5. generation of certificate revocation lists; and

    6. signing of OCSP responses (as described in Section 7.9, “Certificate revocation and suspension” and certificate status services).

      No corresponding certificate status services section appears in the Google Doc. Determine whether to create one, and link to it here and from the audit logging requirements if appropriate.

  3. Security events, including:

    1. successful and unsuccessful PKI system access attempts;

    2. PKI and security system actions performed;

    3. security profile changes;

    4. installation, update, and removal of software on a certificate System;

    5. system crashes, hardware failures, and other anomalies;

    6. relevant router and firewall activities (as described in Section 8.4.1.1, “Router and firewall activities logs”); and

    7. entries to and exits from the CA facility.

Log records MUST include at least the following elements:

  1. date and time of event,

  2. identity of the person making the journal record (when applicable), and

  3. description of the event.

8.4.1.1. Router and firewall activities logs

Logging of router and firewall activities necessary to meet the requirements of Section 8.4.1, “Types of events recorded” MUST at a minimum include:

  1. successful and unsuccessful login attempts to routers and firewalls; and

  2. logging of all administrative actions performed on routers and firewalls, including configuration changes, firmware updates, and access control modifications; and

  3. logging of all changes made to firewall rules, including additions, modifications, and deletions; and

  4. logging of all system events and errors, including hardware failures, software crashes, and system restarts.

8.4.2. Frequency of processing audit log

No stipulation.

8.4.3. Retention period for audit log

The CA and each delegated third party MUST retain, for at least two (2) years:

Retention too short: two years (and one year for the repository) is the BR minimum. Provenance content is validated for decades, so evidence of who was vetted should outlive that. Suggest the life of the issuing CA plus 7 years.

  1. CA certificate and key lifecycle management event records (as set forth in Section 8.4.1, “Types of events recorded” (1)) after the later occurrence of:

    1. the destruction of the CA private key, or

    2. the revocation or expiration of the final CA certificate in that set of certificates that have an X.509v3 basicConstraints extension with the cA field set to true and which share a common public key corresponding to the CA private key;

  2. subscriber certificate lifecycle management event records (as set forth in Section 8.4.1, “Types of events recorded” (2)) after the expiration of the subscriber certificate;

  3. any security event records (as set forth in Section 8.4.1, “Types of events recorded” (3)) after the event occurred.

While these requirements set the minimum retention period, the CA MAY choose a greater value as more appropriate in order to be able to investigate possible security or other types of incidents that will require retrospection and examination of past audit log events.

8.4.4. Protection of audit log

No stipulation.

8.4.5. Audit log backup procedures

No stipulation.

8.4.6. Audit collection system (internal vs. external)

No stipulation.

8.4.7. Notification to event-causing subject

No stipulation.

8.4.8. Vulnerability assessments

The CA’s security program MUST include an annual risk assessment that:

  1. identifies foreseeable internal and external threats that could result in unauthorized access, disclosure, misuse, alteration, or destruction of any certificate data or certificate management processes;

  2. assesses the likelihood and potential damage of these threats, taking into consideration the sensitivity of the certificate data and certificate management processes; and

  3. assesses the sufficiency of the policies, procedures, information systems, technology, and other arrangements that the CA has in place to counter such threats.

8.5. Records archival

8.5.1. Types of records archived

The CA and each delegated third party MUST archive all audit logs (as set forth in Section 8.4.1, “Types of events recorded”).

Additionally, the CA and each delegated third party MUST archive:

  1. documentation related to the security of their certificate systems, certificate management systems, root CA systems, and delegated third party systems; and

  2. documentation related to their verification, issuance, and revocation of certificate requests and certificates.

8.5.2. Retention period for archive

Archived audit logs (as set forth in Section 8.5.1, “Types of records archived”, MUST be retained for a period of at least two (2) years from their record creation timestamp, or as long as they are required to be retained per Section 8.4.3, “Retention period for audit log”, whichever is longer.

Additionally, the CA and each delegated third party MUST retain, for at least two (2) years:

  1. all archived documentation related to the security of certificate systems, certificate management systems, root CA systems and delegated third party systems (as set forth in Section 8.5.1, “Types of records archived”); and

  2. all archived documentation relating to the verification, issuance, and revocation of certificate requests and certificates (as set forth in Section 8.5.1, “Types of records archived”) after the later occurrence of:

    1. such records and documentation were last relied upon in the verification, issuance, or revocation of certificate requests and certificates; or

    2. the expiration of the subscriber certificates relying upon such records and documentation.

While these requirements set the minimum retention period, the CA MAY choose a greater value as more appropriate in order to be able to investigate possible security or other types of incidents that will require retrospection and examination of past records archived.

8.5.3. Protection of archive

No stipulation.

8.5.4. Archive backup procedures

No stipulation.

8.5.5. Requirements for time-stamping of records

No stipulation.

8.5.6. Archive collection system (internal or external)

No stipulation.

8.5.7. Procedures to obtain and verify archive information

No stipulation.

8.6. Key changeover

8.6.1. Key changeover process

  1. A secure and documented process MUST be in place for the periodic rotation of CA keys.

  2. The changeover process should minimize disruption to subscribers and maintain the chain of trust.

  3. CAs SHOULD encourage subscribers to retain key rotation agility.

8.6.2. Subscriber notification

Subscribers SHOULD be notified in advance of any planned key changeover events, allowing them sufficient time to update their systems and configurations.

8.7. Compromise and disaster recovery

8.7.1. Incident response plan

CA operators MUST have an incident response plan and a disaster recovery plan.

The CA MUST document a business continuity and disaster recovery procedures designed to notify and reasonably protect application software suppliers, subscribers, and relying parties in the event of a disaster, security compromise, or business failure. The CA is not required to publicly disclose its business continuity plans but MUST make its business continuity plan and security plans available to the CA’s auditors upon request. The CA MUST annually test, review, and update these procedures.

The business continuity plan MUST include:

  1. the conditions for activating the plan,

  2. emergency procedures,

  3. fallback procedures,

  4. resumption procedures,

  5. a maintenance schedule for the plan,

  6. awareness and education requirements,

  7. the responsibilities of the individuals,

  8. recovery time objective (RTO),

  9. regular testing of contingency plans,

  10. the CA’s plan to maintain or restore the CA’s business operations in a timely manner following interruption to or failure of critical business processes,

  11. a requirement to store critical cryptographic materials (i.e., secure cryptographic device and activation materials) at an alternate location,

  12. what constitutes an acceptable system outage and recovery time,

  13. how frequently backup copies of essential business information and software are taken,

  14. the distance of recovery facilities to the CA’s main site, and

  15. procedures for securing its facility to the extent possible during the period of time following a disaster and prior to restoring a secure environment either at the original or a remote site.

8.7.2. Backup and recovery

  1. Secure backups of all critical data, including certificate databases, CA key material, configuration files, and audit logs, MUST be maintained.

  2. Backups should be stored off-site and regularly tested to ensure recoverability.

  3. A documented recovery plan outlining the steps to restore operations after a disaster or system failure MUST be in place.

8.8. CA or RA termination

8.8.1. Termination procedures

  1. Procedures MUST be established for the orderly termination of the CA’s operations or the revocation of an RA’s delegation.

  2. These procedures should address the secure handling and disposal of sensitive data, keys, and equipment.

  3. Except where expedited action is necessitated in response to a CA or RA security incident, subscribers MUST receive advance notification, allowing them ample time to transition to alternative CAs or RAs.

9. Technical security controls

This section details the technical measures and safeguards implemented to protect the cryptographic keys and ensure the security of the subscriber generator product and the CA’s infrastructure.

Review use of “generator product” term. Likely holdover from C2PA.

9.1. Key pair generation and installation

9.1.1. Key pair generation and installation by CAs

  1. The certification authority MUST maintain effective controls to provide reasonable assurance that the integrity of keys and certificates it manages is established and protected throughout their life cycles.

  2. The CA MUST maintain controls to provide reasonable assurance that CA key pairs are generated in accordance with the CA’s disclosed business practices and defined procedures specified within detailed key generation ceremony scripts.

  3. The CA’s disclosed business practices MUST include but are not limited to:

    1. generation of CA keys are undertaken in a physically- or cloud-secured environment;

    2. generation of CA keys are performed by personnel in trusted roles under the principles of multiple-person control and split knowledge;

    3. generation of CA keys occur within FIPS 140-2 Level 2 or higher, FIPS 140-3 Level 2 or higher, or an appropriate Common Criteria Protection Profile or Security Target, EAL 4 or higher cryptographic modules meeting the applicable technical and business requirements as disclosed in the CA’s business practices;

      Inconsistent: CA keys may be generated at FIPS 140 Level 2 but must be stored at Level 3. Suggest Level 3 for both.

    4. generation of CA keys are witnessed by an independent party and/or recorded; and

    5. CA key generation activities are logged.

  4. The CA key generation script includes the following:

    1. definition of roles and participant responsibilities;

    2. approval for conduct of the key generation ceremony;

    3. cryptographic hardware (or cloud-based HSM) and activation materials required for the ceremony;

    4. specific steps performed during the key generation ceremony;

    5. physical security requirements for the ceremony location (if not using cloud-based HSM);

    6. procedures for secure storage of cryptographic hardware and activation materials following the key generation ceremony (if not using cloud-based HSM)

    7. sign-off from participants and witnesses indicating whether key generation ceremony was performed in accordance with the detailed key generation ceremony script; and

    8. notation of any deviations from the key generation ceremony script.

The CA MUST reject a certificate request if one or more of the following conditions are met:

  1. the key pair does not meet the requirements set forth in Section 9.1.5, “Key sizes” and/or Section 9.1.6, “Public key parameters generation and quality checking”;

  2. there is clear evidence that the specific method used to generate the private key was flawed;

  3. the CA is aware of a demonstrated or proven method that exposes the applicant’s private key to compromise;

  4. the CA has previously been made aware that the applicant’s private key has suffered a key compromise, such as through the provisions of Section 7.9.1.1, “Reasons for revoking a subscriber certificate”; or

  5. the CA is aware of a demonstrated or proven method to easily compute the applicant’s private key based on the public key (such as a Debian weak key, see https://wiki.debian.org/SSLkeys).

The CA or a delegated third party MAY generate the private key on behalf of the subscriber.

9.1.2. Private key delivery to subscriber

Parties other than the subscriber MUST NOT archive the subscriber private key without authorization by the subscriber.

If the CA or any of its designated RAs become aware that a subscriber’s private key has been communicated to a person or organization not authorized by the subscriber, then the CA MUST revoke all certificates that include the public key corresponding to the communicated private key.

If the CA or a delegated third party generates the private key on behalf of the subscriber where the private keys will be transported to the subscriber, then the entity generating the private key MUST either:

  1. transport the private key in hardware with an activation method that is equivalent to 128 bits of encryption, where the material used to activate/protect the private key (e.g., a password used to secure a PKCS-12 file) must be delivered to the subscriber securely and separately from the container holding the private key; or

  2. encrypt the private key with at least 112 bits of encryption strength.

Illustrative examples include:

  • Using a 128-bit AES key to wrap the private key.

  • Storing the key in a PKCS-12 file encrypted using a password and algorithm whose combination provides at least 112 bits of encryption strength.

  • Transporting the private key and/or PKCS-12 file and/or activation material via a TLS or other authenticated and encrypted network connection with at least 112 bits of encryption strength.

  • Other approaches that meet the requirements are allowed.

The CA or delegated third party MUST NOT store subscriber private keys in clear text.

9.1.3. Public key delivery to certificate issuer

No stipulation.

9.1.4. CA public key delivery to relying parties

No stipulation.

9.1.5. Key sizes

For RSA key pairs the CA MUST:

  • For keys corresponding to CA certificates (including Root, Subordinate and cross certificates) signed on or after 15 September 2026 ensure that the modulus size, when encoded, is at least 4096 bits; and

    Inconsistent: RSA 4096 here, but the YAML profiles say 3072 or larger, which matches C2PA. The 2027 rule below is also keyed to id-kp-emailProtection, which shouldn’t be in CAWG certificates.

  • For keys corresponding to subscriber certificates, ensure that the modulus size, when encoded, is at least 2048 bits; and

  • Ensure that the modulus size, in bits, is evenly divisible by 8.

Effective 15 September 2027 the CA MUST NOT issue certificates from any CA if all of the following conditions are true:

The paragraph above intends to prevent the issuance of S/MIME subscriber certificates by existing subordinate CAs which have an RSA key size of less than 3072 bits. The issuance of Delegated OCSP Signing certificates by these CAs remains permitted.

Review references to S/MIME. Also the date-specific references are likely carried over from S/MIME and may not be needed here.

For ECDSA key pairs, the CA MUST:

  • Ensure that the key represents a valid point on the NIST P-256, NIST P-384, or NIST P-521 elliptic curve.

For EdDSA key pairs, the CA MUST:

  • Ensure that the key represents a valid point on the Curve25519 or Curve448 elliptic curve.

For ML-DSA key pairs, the CA MUST:

  • Ensure the Key uses one of the following parameter sets:

    • ML-DSA-44 (OID: 2.16.840.1.101.3.4.3.17), or

    • ML-DSA-65 (OID: 2.16.840.1.101.3.4.3.18), or

    • ML-DSA-87 (OID: 2.16.840.1.101.3.4.3.19).

For ML-KEM key pairs, the CA MUST:

Algorithms: ML-KEM is a key-encapsulation mechanism and can’t sign, so it doesn’t belong in a signing-certificate policy (here, in the key usage table and in the algorithm IDs). ML-DSA and Ed448 aren’t in the C2PA 2.4 allowed list (ES256/384/512, PS256/384/512, Ed25519), which the CAWG X.509 credential inherits, so validators would reject them. Suggest marking them reserved for a future version.

  • Ensure the key uses one of the following parameter sets:

    • ML-KEM-512 (OID: 2.16.840.1.101.3.4.4.1), or

    • ML-KEM-768 (OID: 2.16.840.1.101.3.4.4.2), or

    • ML-KEM-1024 (OID: 2.16.840.1.101.3.4.4.3).

No other algorithms or key sizes are permitted.

9.1.6. Public key parameters generation and quality checking

For RSA key pairs: the CA MUST confirm that the value of the public exponent is an odd number equal to 3 or more. Additionally, the public exponent SHOULD be in the range between 2^16 + 1 and 2^256 - 1. The modulus SHOULD also have the following characteristics: an odd number, not the power of a prime, and have no factors smaller than 752. (See NIST SP 800-89, Section 5.3.3.)

For ECDSA key pairs: the CA SHOULD confirm the validity of all keys using either the ECC Full public key Validation Routine or the ECC Partial public key Validation Routine. (See NIST SP 800-56A: Revision 2, Sections 5.6.2.3.2 and 5.6.2.3.3.)

Add HTTP links to the NIST sections cited above.

For EdDSA key pairs: no stipulation.

For ML-DSA key pairs: no stipulation.

For ML-KEM key pairs: no stipulation.

9.1.7. Key usage purposes (as per X.509 v3 key usage field)

Private keys corresponding to root CA certificates MUST NOT be used to sign certificates except in the following cases:

  1. Self-signed certificates to represent the root CA itself;

  2. Certificates for subordinate CAs and cross certificates;

  3. Certificates for infrastructure purposes (administrative role certificates, internal CA operational device certificates); and

  4. Certificates for OCSP response verification.

9.2. Private key protection and cryptographic module engineering controls

The CA MUST implement physical and logical safeguards to prevent unauthorized certificate issuance. Protection of the CA private key outside the validated system or device specified above MUST consist of physical security, encryption, or a combination of both, implemented in a manner that prevents disclosure of the private key. The CA MUST encrypt its private key with an algorithm and key-length that, according to the state of the art, are capable of withstanding cryptanalytic attacks for the residual life of the encrypted key or key part.

9.2.1. Cryptographic module standards and controls

No stipulation.

9.2.2. Private key (n out of m) multi-person control

No stipulation.

9.2.3. Private key escrow

No stipulation.

9.2.4. Private key backup

9.2.5. Private key archival

Parties other than the subordinate CA MUST NOT archive the subordinate CA private keys without authorization by the subordinate CA.

9.2.6. Private key transfer into or from a cryptographic module

If the issuing CA generated the private key on behalf of the subordinate CA, then the issuing CA MUST encrypt the private key for transport to the subordinate CA. If the issuing CA becomes aware that a subordinate CA’s private key has been communicated to an unauthorized person or an organization not affiliated with the subordinate CA, then the issuing CA MUST revoke all certificates that include the public key corresponding to the communicated private key.

9.2.7. Private key storage on cryptographic module

The CA MUST protect its private key in a system or device that has been validated as meeting at least FIPS 140-2 level 3, FIPS 140-3 level 3, or an appropriate Common Criteria Protection Profile or Security Target, EAL 4 (or higher), which includes requirements to protect the private key and other assets against known threats.

Consider adding links to the FIPS or CCPP documents above.

9.2.8. Method of activating private key

No stipulation.

9.2.9. Method of deactivating private key

No stipulation.

9.2.10. Method of destroying private key

No stipulation.

9.2.11. Cryptographic module rating

No stipulation.

9.3. Other aspects of key pair management

9.3.1. Public key archival

No stipulation.

9.3.2. Certificate operational periods and key pair usage periods

Generation certificate Maximum Validity Period

Strict and multipurpose

825 days

Legacy

1185 days

Validity: 825 and 1,185 days with a Legacy generation is S/MIME carry-over. C2PA caps end-entity certificates at 366 days. Suggest a single profile with a 366-day maximum.

For the purpose of calculations, a day is measured as 86,400 seconds. Any amount of time greater than this, including fractional seconds and/or leap seconds, MUST represent an additional day. For this reason, subscriber certificates SHOULD NOT be issued for the maximum permissible time by default, in order to account for such adjustments.

Where escrow is supported in accordance with Section 7.11, “Key escrow and recovery”, the CA MAY retain subscriber private keys past the certificate Maximum Validity Period.

9.3.3. Controls for subscriber keys

Control requirements for subscriber keys MAY vary by the assurance level of the implementation.

9.4. Activation data

The CA MUST protect activation data from compromise or disclosure. Appropriate cryptographic and physical access controls MUST be implemented to prevent unauthorized use of any CA private key or HSM activation data.

9.5. Computer security controls

  1. Security measures such as secure coding practices, code signing, and regular security updates MUST be employed.

  2. CA systems MUST be secured from unauthorized access using multi-factor authentication security controls.

9.6. Lifecycle security controls

  1. Throughout the certificate lifecycle, from issuance to revocation, security controls MUST be in place to ensure the confidentiality, integrity, and availability of certificates and associated data.

  2. Certificate issuance and revocation processes MUST be protected against unauthorized actions and tampering.

  3. Certificate status information MUST be readily available and accessible to relying parties as defined in certificate status services and the relevant certificate profiles.

No corresponding certificate status services section appears in the Google Doc. Determine whether to create one, and link to it here and from the audit logging requirements if appropriate.

9.7. Network security controls

  1. The CA MUST enforce secure communication protocols and practices when interacting with the generator products or RAs during certificate operations.

    Revisit use of “generator product” term.

  2. Network traffic MUST be protected against eavesdropping, tampering, and unauthorized access.

  3. Remote access to CA systems, made by CA employees or external systems, if permitted, MUST require authentication.

  4. Connections made by CA employees or CA systems to remote computer systems MUST be authenticated.

  5. Access to diagnostic ports, as documented by the CA, MUST be securely controlled.

  6. Controls (e.g., firewalls) MUST be in place to protect the CA’s internal network from any unauthorized access from any other network.

  7. Controls MUST be in place to limit the network services (e.g., HTTP, FTP, etc.) available to authorized users in accordance with the CA’s access control policies.

  8. The security attributes of all network services used by the CA organization MUST be documented by the CA.

  9. Routing controls MUST be in place to ensure that computer connections and information flows do not breach the CA’s access control policy.

  10. The CA MUST maintain local network components (e.g., firewalls and routers) in a physically secure environment and audit their configurations periodically for compliance with the CA’s configuration requirements.

  11. Sensitive data MUST be encrypted when exchanged over public or untrusted networks.

9.8. Time-stamping authorities

Organizations that operate CAs that issue certificates in accordance with this CP MAY also provide an RFC 3161-compliant time-stamping authority (TSA), and the organization MAY apply to the conformance program for inclusion on the CAWG TSA trust list. The TSA MAY operate several identifiable time-stamp units (TSU).

Does CAWG need to operate a TSA registry at launch? I’d recommend we delete this section.

Two forms of time-stamping authorities are permitted under this CP:

  • Backend TSA, operated as a service by the CA.

  • On-Device TSA, intended for use on mobile/edge devices to support local time-stamping without requiring a network connection.

9.8.1. General TSA requirements

  1. The CA MUST disclose its TSA practices including the hashing algorithms, the expected life time of the time-stamp signature, subscriber and relying party obligations (if any), any limitations on the use of the time-stamp and information on how to verify the time-stamp, the intended time-accuracy, and logging of TSA events including how long logs are maintained (and hence are available to provide supporting evidence).

  2. The time values the TSU uses in the time-stamp shall be traceable to at least one of the real time values distributed by a UTC(k) laboratory.

  3. The intended accuracy MUST be defined in the time-stamp, and the time included in the time-stamp MUST be synchronized with this accuracy. The declared accuracy SHOULD be of 1 second or better. TSA clock synchronization MUST be maintained when a leap second occurs as notified by the appropriate body.

  4. The TSA MUST detect if the time that would be applied in a time-stamp drifts outside the declared accuracy. In this situation, the TSU MUST stop time-stamp issuance.

  5. The time-stamp MUST be signed using private keys that are reserved exclusively for this purpose. A TSU MUST have a single time-stamp signing key active at a time.

  6. The TSA MUST only accept time-stamp requests that use SHA2-256, SHA2-384, and SHA2-512 hashing algorithms.

9.8.2. Backend TSA

  1. TSU signing keys MUST be generated and stored within a secure cryptographic device which is a trustworthy system that has been assured to EAL 4 or higher in accordance with ISO/IEC 15408, or equivalent internationally recognized evaluation criteria for IT security, or as meeting at least FIPS 140-2 level 3, FIPS 140-3 level 3, or an appropriate Common Criteria Protection Profile or Security Target, EAL 4 (or higher), which includes requirements to protect the private key and other assets against known threats.

9.8.3. On-device TSA

  1. The On-Device TSA MUST attempt to synchronize its time at least once every 24 hours with an online time source whose time values are traceable to at least one of the real time values distributed by a UTC(k) laboratory. The trusted online time source MAY be a Backend TSA on the C2PA TSA Trust List. In such a case, the On-Device TSA MUST adhere to the following procedure:

  2. The On-Device TSA application MUST run in a Trusted Execution Environment. The On-Device TSA application can accept MessageImprint and nonce (optional) from outside of the Trusted Execution Environment.

  3. TSU signing keys MUST be generated and stored within a Trusted Execution Environment.

10. Certificate, CRL, and OCSP profiles

This section outlines the technical specifications and formats for the certificates, certificate revocation lists (CRLs), and online certificate status protocol (OCSP) responses associated with this CP. It also defines the X.509 v3 extension to indicate the assurance level of each certificate.

10.1. Certificate profile

CAs MUST generate non-sequential certificate serial numbers greater than zero (0) and less than 2^159 containing at least 64 bits of output from a CSPRNG.

10.1.1. Version number(s)

Certificates MUST be of type X.509 v3.

10.1.2. Certificate content and extensions; application of RFC 6818

This section specifies the additional requirements for certificate content and extensions for certificates.

10.1.2.1. Root CA certificates
  1. basicConstraints (MUST be present)

    This extension MUST be marked critical. The cA field MUST be set true. The pathLenConstraint field SHOULD NOT be present.

  2. keyUsage (MUST be present)

    This extension MUST be marked critical. Bit positions for keyCertSign and cRLSign MUST be set. If the root CA private key is used for signing OCSP responses, then the digitalSignature bit MUST be set.

  3. certificatePolicies (SHOULD NOT be present)

    This extension SHOULD NOT be present.

  4. extKeyUsage (MUST NOT be present)

    This extension MUST NOT be present.

  5. subjectKeyIdentifier (MUST be present)

    This extension MUST NOT be marked critical. It MUST contain a value that is included in the keyIdentifier field of the authorityKeyIdentifier extension in certificates issued by the root CA.

10.1.2.2. Subordinate CA certificates
  1. certificatePolicies (MUST be present)

    This extension SHOULD NOT be marked critical.

    All policyIdentifiers included in this extension MUST be included in accordance with Section 10.1.2.2, “Subordinate CA certificates”.

    If the value of this extension includes a PolicyInformation which contains a qualifier of type id-qt-cps (OID: 1.3.6.1.5.5.7.2.1), then the value of the qualifier MUST be a HTTP or HTTPS URL for the issuing CA’s CP and/or CPS, relying party Agreement, or other pointer to online policy information provided by the issuing CA. If a qualifier of type id-qt-unotice (OID: 1.3.6.1.5.5.7.2.2) is included, then it MUST contain explicitText and MUST NOT contain noticeRef.

  2. cRLDistributionPoints (MUST be present)

    This extension MUST NOT be marked critical. It MUST contain the HTTP URL of the CA’s CRL service.

  3. authorityInformationAccess (SHOULD be present)

    This extension MUST NOT be marked critical.

    It SHOULD contain the HTTP URL of the issuing CA certificate (accessMethod = 1.3.6.1.5.5.7.48.2). It MAY contain the HTTP URL of the issuing CA OCSP responder (accessMethod = 1.3.6.1.5.5.7.48.1).

  4. basicConstraints (MUST be present)

    This extension MUST be marked critical. The cA field MUST be set true. The pathLenConstraint field MAY be present.

  5. keyUsage (MUST be present)

    This extension MUST be marked critical. Bit positions for keyCertSign and cRLSign MUST be set. If the subordinate CA private key is used for signing OCSP responses, then the digitalSignature bit MUST be set.

  6. nameConstraints (MAY be present)

    This extension SHOULD be marked critical.

    Non-critical name constraints are an exception to RFC 5280 §4.2.1.10; however, they MAY be used until the nameConstraints extension is supported by application software suppliers whose software is used by a substantial portion of relying parties worldwide.
  7. extKeyUsage (MAY be present for cross certificates; MUST be present otherwise)

    For cross certificates that share a subject distinguished name and subject public key with a root CA certificate operated in accordance with these requirements, this extension MAY be present. If present, this extension SHOULD NOT be marked critical. This extension MUST only contain usages for which the issuing CA has verified the cross certificate is authorized to assert. This extension MUST NOT contain the anyExtendedKeyUsage usage.

    For all other subordinate CA certificates, including technically-constrained subordinate CA certificates, this extension MUST be present and SHOULD NOT be marked critical.

    While RFC 5280 §4.2.1.12 notes that this extension will generally only appear within end-entity certificates, these requirements make use of this extension to further protect relying parties by limiting the scope of subordinate certificates, as implemented by a number of application software suppliers.

    For subordinate CA certificates that will be used to issue S/MIME certificates, the value id-kp-emailProtection MUST be present. The values id-kp-serverAuth, id-kp-codeSigning, id-kp-timeStamping, and anyExtendedKeyUsage MUST NOT be present. Other values MAY be present.

  8. authorityKeyIdentifier (MUST be present)

    This extension MUST NOT be marked critical. It MUST contain a keyIdentifier field and it MUST NOT contain a authorityCertIssuer or authorityCertSerialNumber field.

  9. subjectKeyIdentifier (MUST be present)

    This extension MUST NOT be marked critical. It MUST contain a value that is included in the keyIdentifier field of the authorityKeyIdentifier extension in certificates issued by the subordinate CA.

10.1.2.3. Subscriber certificates
  1. certificatePolicies (MUST be present)

    This extension SHOULD NOT be marked critical. It MUST include exactly one of the reserved policyIdentifiers listed in Section 10.1.6.1, “Reserved certificate policy identifiers”, and MAY contain one or more identifiers documented by the CA in its CP and/or CPS.

    If the value of this extension includes a PolicyInformation which contains a qualifier of type id-qt-cps (OID: 1.3.6.1.5.5.7.2.1), then the value of the qualifier MUST be a HTTP or HTTPS URL for the issuing CA’s CP and/or CPS, relying party agreement, or other pointer to online policy information provided by the issuing CA. If a qualifier of type id-qt-unotice (OID: 1.3.6.1.5.5.7.2.2) is included, then it MUST contain explicitText and MUST NOT contain noticeRef.

    Why allow plain HTTP URLs?

  2. cRLDistributionPoints (MUST be present)

    This extension SHOULD NOT be marked critical. It MUST contain at least one distributionPoint whose fullName value includes a GeneralName of type uniformResourceIdentifier that includes a URI where the issuing CA’s CRL can be retrieved.

    Two contradictory profile sets: these S/MIME BR profiles require a CRL distribution point, but the later CRL Profile says CAs need not implement CRLs. There are two CRL Profile and two OCSP Profile sections, and the root pathLenConstraint differs between them. Suggest keeping one profile set; the YAML ones are the better base.

    Generation Allowed URI scheme

    Strict and Multipurpose

    Every uniformResourceIdentifier MUST have the URI scheme HTTP. Other schemes MUST NOT be present.

    Legacy

    At least one uniformResourceIdentifier MUST have the URI scheme HTTP. Other schemes (LDAP, FTP, …​) MAY be present.

    Not sure we need to carry forward S/MIME’s “legacy” generation certificates.

  3. authorityInformationAccess (SHOULD be present)

    This extension MUST NOT be marked critical.

    1. id-ad-ocsp

      The authorityInformationAccess extension MAY contain one or more accessMethod values of type id-ad-ocsp that specifies the URI of the issuing CA’s OCSP responder.

      Generation Allowed URI scheme

      Strict and Multipurpose

      When provided, every accessMethod MUST have the URI scheme HTTP. Other schemes MUST NOT be present.

      Legacy

      When provided, at least one accessMethod MUST have the URI scheme HTTP. Other schemes (LDAP, FTP, …​) MAY be present.

      Not sure we need to carry forward S/MIME’s “legacy” generation certificates.

    2. id-ad-caIssuers

      The authorityInformationAccess extension SHOULD contain at least one accessMethod value of type id-ad-caIssuers that specifies the URI of the issuing CA’s certificate.

      Generation Allowed URI scheme

      Strict and Multipurpose

      When provided, every accessMethod MUST have the URI scheme HTTP. Other schemes MUST NOT be present.

      Legacy

      When provided, at least one accessMethod MUST have the URI scheme HTTP. Other schemes (LDAP, FTP, …​) MAY be present.

      Not sure we need to carry forward S/MIME’s “legacy” generation certificates.

  4. basicConstraints (optional)

    This extension MAY be present. The cA field MUST NOT be true. pathLenConstraint field MUST NOT be present.

  5. keyUsage (MUST be present)

    This extension SHOULD be marked critical.

    Generation rsaEncryption id-ecPublicKey id-Ed25519* and *id-Ed448

    Strict

    For signing only, bit positions MUST be set for digitalSignature and MAY be set for nonRepudiation. For key management only, bit positions MUST be set for keyEncipherment.<br>For dual use, bit positions MUST be set for digitalSignature and keyEncipherment and MAY be set for nonRepudiation.

    For signing only, bit positions MUST be set for digitalSignature and MAY be set for nonRepudiation. For key management only, bit positions MUST be set for keyAgreement and MAY be set for encipherOnly or decipherOnly. For dual use, bit positions MUST be set for digitalSignature and keyAgreement, MAY be set for nonRepudiation, and MAY be set for encipherOnly or decipherOnly (only if keyAgreement is set).

    Bit positions MUST be set for digitalSignature and MAY be set for nonRepudiation.

    Multipurpose and Legacy

    For signing only, bit positions MUST be set for digitalSignature and MAY be set for nonRepudiation. For key management only, bit positions MUST be set for keyEncipherment and MAY be set for dataEncipherment. For dual use, bit positions MUST be set for digitalSignature and keyEncipherment, MAY be set for nonRepudiation, and MAY be set for dataEncipherment.

    For signing only, bit positions MUST be set for digitalSignature and MAY be set for nonRepudiation. For key management only, bit positions MUST be set for keyAgreement and MAY be set for encipherOnly or decipherOnly. For dual use, bit positions MUST be set for digitalSignature and keyAgreement, MAY be set for nonRepudiation, and MAY be set for encipherOnly or decipherOnly (only if keyAgreement is set).

    Bit positions MUST be set for digitalSignature and MAY be set for nonRepudiation.

    Not sure we need to carry forward S/MIME’s “legacy” generation certificates.

    Other bit positions MUST NOT be set.

    Generation id-ml-dsa id-ml-kem

    Legacy and Multipurpose and Strict

    Bit positions MUST be set for digitalSignature and MAY be set for nonRepudiation. Other bit positions MUST NOT be set.

    keyEncipherment MUST be the only key usage set.

    Not sure we need to carry forward S/MIME’s “legacy” generation certificates.

  6. extKeyUsage (MUST be present)

    Generation KeyPurposeId

    Strict

    id-kp-emailProtection MUST be present. Other values MUST NOT be present.

    Multipurpose and Legacy

    id-kp-emailProtection MUST be present. Other values MAY be present.

    Not sure we need to carry forward S/MIME’s “legacy” generation certificates.

    Critical, EKU: subscriber certificates must carry id-kp-emailProtection and Strict allows nothing else. That makes every CAWG certificate a working S/MIME email certificate, and a Strict certificate can never carry id-kp-documentSigning, which CAWG Identity assertion 1.3 requires validators to accept. Suggest requiring a CAWG EKU (for example cawg-kp-identitySigning under the CAWG PEN) and/or id-kp-documentSigning, and prohibiting emailProtection, serverAuth, codeSigning, timeStamping, C2PA claimSigning and anyExtendedKeyUsage.

    The values id-kp-serverAuth, id-kp-codeSigning, id-kp-timeStamping, and anyExtendedKeyUsage MUST NOT be present.

  7. authorityKeyIdentifier (MUST be present)

    This extension MUST NOT be marked critical. The keyIdentifier field MUST be present. authorityCertIssuer and authorityCertSerialNumber fields MUST NOT be present.

  8. subjectAlternativeName (MUST be present)

    This extension SHOULD NOT be marked critical unless the subject field is an empty sequence.

    The value of this extension MUST be encoded as specified in Section 10.1.4.2.1, “Subject alternative name extension”.

  9. Legal entity identifier (optional)

    Generation LEI

    Organization-validated

    LEI (1.3.6.1.4.1.52266.1) MAY be present and MUST NOT be marked critical. Role (1.3.6.1.4.1.52266.2) MUST NOT be present.

    Sponsor-validated

    LEI (1.3.6.1.4.1.52266.1) or for role (1.3.6.1.4.1.52266.2) MAY be present and MUST NOT be marked critical.

    Individual-validated

    Prohibited

    The legal entity identifier (LEI) is a 20-character, alphanumeric code used in accordance with ISO 17442-1:2020, Clause 6 and ISO 17442-2:2020, Clause 4.

    Add links to ISO docs if possible.

    The CA MUST verify that the RegistrationStatus for the LEI record is ISSUED and the EntityStatus is ACTIVE. The CA MUST only allow use of an LEI if the ValidationSources entry is FULLY_CORROBORATED. An LEI MUST NOT be used if ValidationSources entry is PARTIALLY_CORROBORATED, PENDING, or ENTITY_SUPPLIED_ONLY.

    In cases where the “role” LEI is used, the CA MUST verify that the LEI data reference is assigned to the individual subject whose identity has been verified in accordance with Section 6.2.2, “Authentication of individual identity”.

  10. subjectKeyIdentifier (SHOULD be present)

    This extension MUST NOT be marked critical. It SHOULD contain a value that is derived from the public key included in the subscriber certificate.

10.1.2.4. All certificates

All fields and extensions MUST be set in accordance with RFC 5280. The CA MUST NOT issue a certificate that contains a keyUsage flag, extKeyUsage value, certificate extension, or other data not specified in Section 10.1.2.1, “Root CA certificates”, Section 10.1.2.2, “Subordinate CA certificates”, or Section 10.1.2.3, “Subscriber certificates” unless the CA is aware of a reason for including the data in the certificate. If the CA includes fields or extensions in a certificate that are not specified but are otherwise permitted by these requirements, then the CA MUST document the processes and procedures that the CA employs for the validation of information contained in such fields and extensions in its CP and/or CPS.

CAs MUST NOT issue a certificate with:

  1. Extensions that do not apply in the context of the public Internet (such as an extKeyUsage value for a service that is only valid in the context of a privately managed network), unless:

    1. such value falls within an OID arc for which the applicant demonstrates ownership, or

    2. the applicant can otherwise demonstrate the right to assert the data in a public context; or

    3. the extension is defined within an open standards specification and intended for use by other organizations. A certificate that includes such an extension MUST conform to the specifications of the open standard and of these requirements.

  2. Field or extension values which have not been validated according to the processes and procedures described in these requirements or the CA’s CP and/or CPS.

10.1.3. Algorithm object identifiers

10.1.3.1. Subjectpublickeyinfo

The following requirements apply to the subjectPublicKeyInfo field within a certificate. No other encodings are permitted.

10.1.3.1.1. RSA

The CA MUST indicate an RSA key using the rsaEncryption (OID: 1.2.840.113549.1.1.1) algorithm identifier. The parameters MUST be present, and MUST be an explicit NULL.

The CA MUST NOT use a different algorithm, such as the `id-RSASSA-PSS (OID: 1.2.840.113549.1.1.10) algorithm identifier, to indicate an RSA key.

When encoded, the AlgorithmIdentifier for RSA keys MUST be byte-for-byte identical with the following hex-encoded bytes: 300d06092a864886f70d0101010500

Effective 15 September 2026 the CA MUST NOT sign a certificate using a signature algorithm that incorporates SHA-1.

Prior to 15 September 2026 the CA MUST revoke any unexpired subordinate CA certificate whose signature algorithm incorporates SHA-1.

Date-specific limitations are a likely holdover from S/MIME. Consider removing.

10.1.3.1.2. ECDSA

The CA MUST indicate an ECDSA key using the id-ecPublicKey (OID: 1.2.840.10045.2.1) algorithm identifier. The parameters MUST use the namedCurve encoding.

  • For P-256 keys, the namedCurve MUST be secp256r1 (OID: 1.2.840.10045.3.1.7).

  • For P-384 keys, the namedCurve MUST be secp384r1 (OID: 1.3.132.0.34).

  • For P-521 keys, the namedCurve MUST be secp521r1 (OID: 1.3.132.0.35).

When encoded, the AlgorithmIdentifier for ECDSA keys MUST be byte-for-byte identical with the following hex-encoded bytes:

  • For P-256 keys, 301306072a8648ce3d020106082a8648ce3d030107.

  • For P-384 keys, 301006072a8648ce3d020106052b81040022.

  • For P-521 keys, 301006072a8648ce3d020106052b81040023.

10.1.3.1.3. EdDSA

The CA MUST indicate an EdDSA key using one of the following algorithm identifiers below:

  • For Curve25519 keys, the algorithm MUST be id-Ed25519 (OID: 1.3.101.112).

  • For Curve448 keys, the algorithm MUST be id-Ed448 (OID: 1.3.101.113).

The parameters for EdDSA keys MUST be absent.

When encoded, the AlgorithmIdentifier for EdDSA keys MUST be byte-for-byte identical with the following hex-encoded bytes:

  • For Curve25519 keys, 300506032b6570.

  • For Curve448 keys, 300506032b6571.

10.1.3.1.4. ML-DSA

Neither CAWG nor C2PA has allowed ML-DSA encryption. Should we remove this section?

The CA MUST indicate an ML-DSA key using one of the following algorithm identifiers below:

  • ML-DSA-44 (OID: 2.16.840.1.101.3.4.3.17), or

  • ML-DSA-65 (OID: 2.16.840.1.101.3.4.3.18), or

  • ML-DSA-87 (OID: 2.16.840.1.101.3.4.3.19).

The parameters for ML-DSA keys MUST be absent. The CA MUST NOT use HashML-DSA; only “pure” ML-DSA is permitted.

When encoded, the AlgorithmIdentifier for ML-DSA keys MUST be byte-for-byte identical with the following hex-encoded bytes:

  • For ML-DSA-44, 300b0609608648016503040311.

  • For ML-DSA-65, 300b0609608648016503040312.

  • For ML-DSA-87, 300b0609608648016503040313.

10.1.3.1.5. ML-KEM

Neither CAWG nor C2PA has allowed ML-KEM encryption. Should we remove this section?

The CA MUST indicate an ML-KEM key using one of the following algorithm identifiers below:

  • ML-KEM-512 (OID: 2.16.840.1.101.3.4.4.1), or

  • ML-KEM-768 (OID: 2.16.840.1.101.3.4.4.2), or

  • ML-KEM-1024 (OID: 2.16.840.1.101.3.4.4.3).

The parameters for ML-KEM keys MUST be absent.

When encoded, the AlgorithmIdentifier for ML-KEM keys MUST be byte-for-byte identical with the following hex-encoded bytes:

  • For ML-KEM-512, 300b0609608648016503040401.

  • For ML-KEM-768, 300b0609608648016503040402.

  • For ML-KEM-1024, 300b0609608648016503040403.

10.1.3.2. Signature AlgorithmIdentifier

All objects signed by a CA private key MUST conform to these requirements on the use of the AlgorithmIdentifier or AlgorithmIdentifier-derived type in the context of signatures.

In particular, it applies to all of the following objects and fields:

  • the signatureAlgorithm field of a certificate,

  • the signature field of a TBSCertificate (for example, as used by a certificate),

  • the signatureAlgorithm field of a CertificateList,

  • the signature field of a TBSCertList, and

  • the signatureAlgorithm field of a BasicOCSPResponse.

No other encodings are permitted for these fields.

10.1.3.2.1. RSA

The CA MUST use one of the following signature algorithms and encodings. When encoded, the AlgorithmIdentifier MUST be byte-for-byte identical with the specified hex-encoded bytes.

  • RSASSA-PKCS1-v1_5 with SHA-256:

    Encoding: 300d06092a864886f70d01010b0500.

  • RSASSA-PKCS1-v1_5 with SHA-384:

    Encoding: 300d06092a864886f70d01010c0500.

  • RSASSA-PKCS1-v1_5 with SHA-512:

    Encoding: 300d06092a864886f70d01010d0500.

  • RSASSA-PSS with SHA-256, MGF-1 with SHA-256, and a salt length of 32 bytes:

    Encoding:

    304106092a864886f70d01010a3034a00f300d0609608648016503040201
    0500a11c301a06092a864886f70d010108300d0609608648016503040201
    0500a203020120
  • RSASSA-PSS with SHA-384, MGF-1 with SHA-384, and a salt length of 48 bytes:

    Encoding:

    304106092a864886f70d01010a3034a00f300d0609608648016503040202
    0500a11c301a06092a864886f70d010108300d0609608648016503040202
    0500a203020130
  • RSASSA-PSS with SHA-512, MGF-1 with SHA-512, and a salt length of 64 bytes:

    Encoding:

    304106092a864886f70d01010a3034a00f300d0609608648016503040203
    0500a11c301a06092a864886f70d010108300d0609608648016503040203
    0500a203020140
10.1.3.2.2. ECDSA

The CA MUST use the appropriate signature algorithm and encoding based upon the signing key used.

If the signing key is P-256, the signature MUST use ECDSA with SHA-256. When encoded, the AlgorithmIdentifier MUST be byte-for-byte identical with the following hex-encoded bytes: 300a06082a8648ce3d040302.

If the signing key is P-384, the signature MUST use ECDSA with SHA-384. When encoded, the AlgorithmIdentifier MUST be byte-for-byte identical with the following hex-encoded bytes: 300a06082a8648ce3d040303.

If the signing key is P-521, the signature MUST use ECDSA with SHA-512. When encoded, the AlgorithmIdentifier MUST be byte-for-byte identical with the following hex-encoded bytes: 300a06082a8648ce3d040304.

10.1.3.2.3. EdDSA

The CA MUST use the appropriate signature algorithm and encoding based upon the signing key used.

If the signing key is Curve25519, the signature algorithm MUST be id-Ed25519 (OID: 1.3.101.112). When encoded, the AlgorithmIdentifier MUST be byte-for-byte identical with the following hex-encoded bytes: 300506032b6570.

If the signing key is Curve448, the signature algorithm MUST be id-Ed448 (OID: 1.3.101.113). When encoded, the AlgorithmIdentifier MUST be byte-for-byte identical with the following hex-encoded bytes: 300506032b6571.

10.1.3.2.4. ML-DSA

Neither CAWG nor C2PA has allowed ML-DSA encryption. Should we remove this section?

The CA MUST use the appropriate signature algorithm and encoding based upon the signing key used.

If the signing key is ML-DSA-44, the signature algorithm MUST be id-ml-dsa-44 (OID: 2.16.840.1.101.3.4.3.17). When encoded, the AlgorithmIdentifier MUST be byte-for-byte identical with the following hex-encoded bytes: 300b0609608648016503040311.

If the signing key is ML-DSA-65, the signature algorithm MUST be id-ml-dsa-65 (OID: 2.16.840.1.101.3.4.3.18). When encoded, the AlgorithmIdentifier MUST be byte-for-byte identical with the following hex-encoded bytes: 300b0609608648016503040312.

If the signing key is ML-DSA-87, the signature algorithm MUST be id-ml-dsa-87 (OID: 2.16.840.1.101.3.4.3.19). When encoded, the AlgorithmIdentifier MUST be byte-for-byte identical with the following hex-encoded bytes: 300b0609608648016503040313.

10.1.4. Name forms

Attribute values MUST be encoded according to RFC 5280.

10.1.4.1. Name encoding

For every valid certification path (as defined by RFC 5280 §6):

10.1.4.2. Subject information: Subscriber certificates

By issuing the certificate, the CA represents that it followed the procedure set forth in its CP and/or CPS to verify that, as of the certificate’s issuance date, all of the subject information was accurate.

Subject attributes MUST NOT contain only metadata such as ., -, and ` ` (i.e., space) characters, and/or any other indication that the value is absent, incomplete, or not applicable.

10.1.4.2.1. Subject alternative name extension
10.1.4.2.2. Subject distinguished name fields
  1. Certificate field: subject:commonName (OID 2.5.4.3)
    Contents: If present, this attribute MUST contain one of the following values verified in accordance with Section 6.2, “Initial identity validation”.

    certificate type Contents

    Organization-validated

    subject:organizationName or mailbox address

    Sponsor-validated

    personal name, pseudonym, or mailbox address

    Individual-validated

    personal name, pseudonym, or mailbox address

    Review use of mailbox address.

    If present, the personal name MUST contain a name of the subject. The personal name SHOULD be presented as subject:givenName and/or subject:surname. The personal name MAY be in the subject’s preferred presentation format or a format preferred by the CA or enterprise RA, but MUST be a meaningful representation of the subject’s name as verified under Section 6.2.2, “Authentication of individual identity”.

    If the subject:commonName contains a pseudonym, then the subject:givenName and/or subject:surname attributes MUST NOT be present. If present, the pseudonym MUST contain the subject:pseudonym if that subject attribute is also present.

    If the subject:commonName contains a personal name, then the subject:pseudonym attribute MUST NOT be present.

    Like all other certificate attributes, subject:commonName and subject:emailAddress MUST comply with the attribute upper bounds defined in RFC 5280.

    Additional specifications for naming are provided in Section 6.1, “Naming”.

  2. Certificate field: subject:organizationName (OID 2.5.4.10)
    Contents: If present, the subject:organizationName field MUST contain the subject’s full legal organization name and/or an assumed name as verified under Section 6.2.1, “Authentication of organization identity”. If both are included, the assumed name MUST appear first, followed by the full legal organization name in parentheses. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g., if the official record shows “Company Name Incorporated”, the CA MAY use “Company Name Inc.” or “Company Name.”

  3. Certificate field: subject:organizationalUnitName (OID: 2.5.4.11)
    Contents: If present, the CA MUST confirm that the subject:organizationalUnitName is the full legal organization name of an affiliate of the subject:organizationName in the certificate and has been verified in accordance with the requirements of Section 6.2.1, “Authentication of organization identity”. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations.

  4. Certificate field: subject:organizationIdentifier (2.5.4.97)
    Contents: If present, the subject:organizationIdentifier field MUST contain a registration reference for a legal entity assigned in accordance to the identified registration scheme. The registration reference SHOULD be unique where the registration scheme and jurisdiction provide unique identifiers.

    The subject:organizationIdentifier MUST be encoded as a PrintableString or UTF8String.

    The registration scheme identified in the certificate MUST be the result of the verification performed in accordance with Section 6.2.1, “Authentication of organization identity”.

    If the registration reference is assigned at the country level, the registration scheme MUST be identified using the following structure in the presented order:

    • 3 character registration scheme identifier; and

    • 2 character ISO 3166-1 country code for the nation in which the registration scheme is operated, or as described in Note 1; and

    • a hyphen-minus - (0x2D (ASCII), U+002D (UTF-8)); and

    • registration reference allocated in accordance with the identified registration scheme (or as described in the note about the NTR registration scheme).

    If the registration reference is assigned at the subdivision (state or province) level and is not unique at the national level, the registration scheme MUST be identified using the following structure in the presented order:

    • 3 character registration scheme identifier; and

    • 2 character ISO 3166-1 country code for the nation in which the registration scheme is operated; and

    • plus + (0x2B (ASCII), U+002B (UTF-8)); and

    • up-to-3 character ISO 3166-2 identifier for the subdivision; and

    • a hyphen-minus - (0x2D (ASCII), U+002D (UTF-8)); and

    • registration reference allocated in accordance with the identified registration scheme.

    Registration references MAY contain hyphens but registration schemes, ISO 3166-1 country codes, and ISO 3166-2 identifiers MUST NOT contain hyphens. Therefore if more than one hyphen appears in the structure, the leftmost hyphen is a separator, and the remaining hyphens are part of the registration reference. For example:

    • NTRGB-12345678 (NTR scheme, Great Britain, registration reference at country level is 12345678).

    • NTRUS+CA-12345678 (NTR Scheme, United States - California, registration reference at state level is 12345678).

    • PSDBE-NBB-1234.567.890 (PSD Scheme, Belgium, national competent authority identifier is NBB, registration reference assigned by the NCA is 1234.567.890).

    • VATEL-123456789 (VAT Scheme, Greece using EU Council Directive 2006/112/EC as amended, registration reference is 12345678).

    Registration schemes listed in Appendix A are recognized as valid under these requirements.

    Could not find Appendix A in Google Doc.

    The CA MUST:

    1. confirm that the organization represented by the registration reference is the same as the organization named in the organizationName field as specified in Section 10.1.4.2.2, “Subject distinguished name fields”; and

    2. further verify the registration reference matches other information verified in accordance with Section 6.2.1, “Authentication of organization identity”.

    With the exception of the LEI and INT registration schemes, if a subject:countryName is present in the certificate the country code used in the registration scheme identifier MUST match that of the subject:countryName in the certificate.

    For the VAT registration scheme, the country prefix described in Article 215 of EU Council Directive 2006/112/EC, as amended, MAY be used instead of the ISO 3166-1 country code. If the country prefix described in Article 215 of EU Council Directive 2006/112/EC is used, the subject:countryName attribute, if present, MUST contain the corresponding ISO 3166-1 country code.

    For the LEI registration scheme, the ISO 3166-1 code XG MUST be used.

    For the following types of entities that do not have an identifier from the registration schemes listed in Appendix A:

    Could not find Appendix A in Google Doc.

    • For government entities, the CA MUST enter the registration scheme identifier GOV followed by the 2 character ISO 3166-1 country code for the nation in which the government entity is located. If the government entity is verified at a subdivision (state or province) level, then a plus + (0x2B (ASCII), U+002B (UTF-8)) followed by an ISO 3166-2 identifier for the subdivision (up to three alphanumeric characters) is added.

    • For international organization entities, the CA MUST enter the registration scheme identifier INT followed by the ISO 3166-1 code XG. An international organization entity is founded by a constituent document, e.g., a charter, treaty, convention or similar document, signed by, or on behalf of, a minimum of two sovereign state governments. For example:

      • GOVUS (government entity, United States)

      • GOVUS+CA (government entity, United States - California)

      • INTXG (international organization)

    For the NTR registration scheme, when the organization or legal entity is registered in the European Union or the European Economic Area, the registration reference MAY use the EUID identifier. When the organization or legal entity is registered in Germany, the registration reference SHOULD use the EUID identifier. The structure of the EUID MUST be as follows:

    • 2 character ISO 3166-1 country code, which must match the country code used in the leading string NTR; and

    • the business register identifier for the particular section or office of the domestic register that assigned the registration reference; and

    • dot-sign . (U+002E); and

    • the registration reference allocated by the domestic register.

    For example:

    • NTRDE-DER3306.HRB12345 (DE is the country code for Germany, R3306 is the business register identifier for the district court in Cologne, and HRB12345 is the locally-assigned registration reference).

  5. Certificate field: subject:givenName (2.5.4.42) and/or subject:surname (2.5.4.4)
    Contents: If present, the subject:givenName field and subject:surname field MUST contain a natural person subject’s name as verified under Section 6.2.2, “Authentication of individual identity”. Subjects with a single legal name MUST provide the name in the subject:surname attribute. The subject:givenName and/or subject:surname MUST NOT be present if the subject:pseudonym is present.

  6. Certificate field: subject:pseudonym (2.5.4.65)
    Contents: The subject:pseudonym MUST NOT be present if the subject:givenName and/or subject:surname are present. If present, the subject:pseudonym field MUST be verified according to Section 6.1.3, “Anonymity or pseudonymity of subscribers”.

  7. Certificate field: subject:serialNumber (2.5.4.5)
    Contents: If present, the subject:serialNumber MAY be used to contain an identifier assigned by the CA or RA to identify and/or to disambiguate the subscriber.

    In addition, the subject:serialNumber MAY be used in the Sponsor-validated and Individual-validated profiles to contain a natural person identifier as described in ETSI EN 319 412-1 §5.1.3. Registration schemes listed in A are recognized as valid under these requirements. The CA MUST confirm that the individual represented by the natural person Identifier is the same as the certificate subject in accordance with Section 6.2.2, “Authentication of individual identity”.

    Link to ETSI document section?

  8. Certificate field: subject:title (2.5.4.12)
    Contents: If present, the subject:title field MUST contain only a organizational role/title or a regulated professional designation verified according to Section 6.2.2, “Authentication of individual identity”.

  9. Certificate field: Number and street: subject:streetAddress (OID: 2.5.4.9)
    Contents: If present, the subject:streetAddress field MUST contain the subject’s street address information as verified under Section 6.2.1, “Authentication of organization identity” for organization-validated and sponsor-validated certificate types or Section 6.2.2, “Authentication of individual identity” for individual-validated certificate types. The subject:streetAddress field MUST only be used if the subject:localityName or subject:stateOrProvinceName field is present.

  10. Certificate field: subject:localityName (OID: 2.5.4.7)
    Contents: If present, the subject:localityName field MUST contain the subject’s locality information as verified under Section 6.2.1, “Authentication of organization identity” for organization-validated and sponsor-validated certificate types or Section 6.2.2, “Authentication of individual identity” for individual-validated certificate types. If the subject:countryName field specifies the ISO 3166-1 user-assigned code of XX in accordance with Section 10.1.4.2.2, “Subject distinguished name fields” (n), the subject:localityName field MAY contain the subject’s locality and/or state or province information. The subject:localityName field MUST only be used if the subject:countryName field is present.

    Check (n) reference. Likely incorrect given Asciidoc migration.

  11. Certificate field: subject:stateOrProvinceName (OID: 2.5.4.8)
    Contents: If present, the subject:stateOrProvinceName field MUST contain the subject’s state or province information as verified under Section 6.2.1, “Authentication of organization identity” for organization-validated and sponsor-validated certificate types or Section 6.2.2, “Authentication of individual identity” for individual-validated certificate types. If the subject:countryName field specifies the ISO 3166-1 user-assigned code of XX in accordance with Section 10.1.4.2.2, “Subject distinguished name fields” (n), the subject:stateOrProvinceName field MAY contain the full name of the subject’s country information. The subject:stateOrProvinceName field MUST only be used if the subject:countryName field is present.

  12. Certificate field: subject:postalCode (OID: 2.5.4.17)
    Contents: If present, the subject:postalCode field MUST contain the subject’s ZIP or postal information as verified under Section 6.2.1, “Authentication of organization identity” for organization-validated and sponsor-validated certificate types or Section 6.2.2, “Authentication of individual identity” for individual-validated certificate types. The subject:postalCode field MUST only be used if the subject:countryName field is present.

  13. Certificate field: subject:countryName (OID: 2.5.4.6)
    Contents: If present, the subject:countryName MUST contain the two-letter ISO 3166-1 country code associated with the location of the subject verified under Section 6.2.1, “Authentication of organization identity” for organization-validated and sponsor-validated certificate types or Section 6.2.2, “Authentication of individual identity” for individual-validated certificate types. If a country is not represented by an official ISO 3166-1 country code, the CA MUST specify the ISO 3166-1 user-assigned code of XX indicating that an official ISO 3166-1 alpha-2 code has not been assigned.

10.1.4.2.3. Subject DN attributes for organization-validated profile
Attribute Use

commonName

MAY

organizationName

MUST

organizationalUnitName

MAY

organizationIdentifier

MUST

givenName

MUST NOT

surname

MUST NOT

pseudonym

MUST NOT

serialNumber

MAY

emailAddress

MAY

title

MUST NOT

streetAddress

MAY

localityName

MAY

stateOrProvinceName

MAY

postalCode

MAY

countryName

MAY

Other

MAY

10.1.4.2.4. Subject DN attributes for sponsor-validated profile
Attribute Use

commonName

MAY

organizationName

MUST

organizationalUnitName

MAY

organizationIdentifier

MUST

givenName

MAY

surname

MAY

pseudonym

MAY

serialNumber

MAY

emailAddress

MAY

title

MAY

streetAddress

MAY

localityName

MAY

stateOrProvinceName

MAY

postalCode

MAY

countryName

MAY

Other

MAY

10.1.4.2.5. Subject DN attributes for individual-validated profile
Attribute Use

commonName

MAY

organizationName

MUST NOT

organizationalUnitName

MUST NOT

organizationIdentifier

MUST NOT

givenName

MAY

surname

MAY

pseudonym

MAY

serialNumber

MAY

emailAddress

MAY

title

MAY

streetAddress

MAY

localityName

MAY

stateOrProvinceName

MAY

postalCode

MAY

countryName

MAY

Other

MAY

10.1.4.3. Subject information: Root certificates and subordinate CA certificates

By issuing a subordinate CA certificate, the CA represents that it followed the procedure set forth in its CP and/or CPS to verify that, as of the certificate’s issuance date, all of the subject information was accurate.

10.1.4.3.1. Subject distinguished name fields
  1. Certificate field: subject:commonName (OID 2.5.4.3)
    Required/optional: MUST be present
    Contents: This field SHOULD contain an identifier for the certificate such that the certificate’s name is unique across all certificates issued by the issuing CA.

  2. Certificate field: subject:organizationName (OID 2.5.4.10)
    Required/optional: MUST be present
    Contents: This field MUST contain either the subject CA’s name or DBA as verified under Section 6.2.1.2.2, “Verification of assumed name”. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g., if the official record shows “Company Name Incorporated,” the CA MAY use “Company Name Inc.” or “Company Name.”

  3. Certificate field: subject:countryName (OID: 2.5.4.6)
    Required/optional: MUST be present
    Contents: This field MUST contain the two‐letter ISO 3166‐1 country code for the country in which the CA’s place of business is located.

  4. Other subject attributes: Other attributes MAY be present within the subject field. If present, other attributes MUST contain information that has been verified by the CA.

10.1.5. Name constraints

For a subordinate CA certificate to be considered technically-constrained, the certificate MUST include an extended key usage (EKU) extension specifying all extended key usages for which the subordinate CA certificate is authorized to issue certificates. The anyExtendedKeyUsage KeyPurposeId MUST NOT appear within this extension.

Open question: Shall CAWG use name constraints?

Review comment: Rather than name constraints, scope trust with a dedicated CAWG issuing CA (pathLen=0, CAWG EKU, CAWG policy OID) and list that certificate as the trust anchor, not the issuer’s root. Trusting a CA for CAWG then doesn’t trust its TLS, S/MIME, or C2PA business.

10.1.6. Certificate policy object identifier

This section describes the content requirements for the root CA, subordinate CA, and subscriber certificates as they relate to the identification of certificate policy.

10.1.6.1. Reserved certificate policy identifiers

The following CA/Browser Forum certificate policy identifiers are reserved for use by CAs to assert that a certificate complies with these requirements.

certificate type Policy identifier

Organization-validated

2.23.140.1.5.2.1

Sponsor-validated

2.23.140.1.5.3.1

Individual-validated

2.23.140.1.5.4.1

These OIDs likely need to be replaced with CAWG-specific OIDs.

10.1.6.2. Root CA certificates

A root CA certificate SHOULD NOT contain the certificatePolicies extension. If present, the extension MUST conform to the requirements set forth for certificates issued to subordinate CAs in Section 10.1.6.3, “Subordinate CA certificates”.

10.1.6.3. Subordinate CA certificates

A certificate issued to a subordinate CA that is not an affiliate of the issuing CA:

  1. MUST include one or more explicit policy identifiers defined in Section 10.1.6.1, “Reserved certificate policy identifiers”, that indicate the subordinate CA’s adherence to and compliance with these requirements and MAY contain one or more identifiers documented by the subordinate CA in its CP and/or CPS; and

  2. MUST NOT contain the anyPolicy identifier (2.5.29.32.0).

A certificate issued to a subordinate CA that is an affiliate of the issuing CA MUST include a set of policy identifiers from one of the two options below:

  1. One or more explicit policy identifiers defined in Section 10.1.6.1, “Reserved certificate policy identifiers”, that indicate the subordinate CA’s adherence to and compliance with these requirements and MAY contain one or more identifiers documented by the subordinate CA in its CP and/or CPS; or

  2. The anyPolicy identifier (2.5.29.32.0).

The subordinate CA and the issuing CA MUST represent, in their CP and/or CPS, that all certificates containing a policy identifier indicating compliance with these requirements are issued and managed in accordance with these requirements.

10.1.6.4. Subscriber certificates

A certificate issued to a subscriber MUST contain, within the certificate’s certificatePolicies extension, a policy identifier that is specified in Section 10.1.6.1, “Reserved certificate policy identifiers”.

The certificate MAY also contain additional policy identifier(s) documented by the issuing CA in its CP and/or CPS.

10.2. CRL profile

10.2.1. Version number(s)

No stipulation.

10.2.2. CRL and CRL entry extensions

If present, the reasonCode (OID 2.5.29.21) extension MUST NOT be marked critical.

If a CRL entry is for a root CA or subordinate CA certificate, including cross certificates, this CRL entry extension MUST be present. The CRLreason of certificateHold (6) MUST NOT be used for root CA or subordinate CA certificates.

If a CRL entry is for a certificate not technically capable of causing issuance, this CRL entry extension SHOULD be present, but MAY be omitted, subject to the following requirements:

  • The CRLReason indicated MUST NOT be unspecified (0). If the reason for revocation is unspecified, CAs MUST omit the reasonCode entry extension.

  • The repository MAY include CRL entries that have a CRLreason of certificateHold (6) for certificates that include the certificate policy identifiers for the Legacy or Multipurpose Generations. The repository MUST NOT include CRL entries that have a CRLreason of certificateHold (6) for certificates that include the certificate policy identifiers for the Strict Generation.

    Revisit reference to legacy/strict generations. Likely holdover from S/MIME.

  • If a reasonCode CRL entry extension is present, the CRLReason MUST indicate the most appropriate reason for revocation of the certificate, as defined by the CA within its CP/CPS.

10.3. OCSP profile

If an OCSP response is for a root CA or subordinate CA certificate, including cross certificates, and that certificate has been revoked, then the revocationReason field within the RevokedInfo of the CertStatus MUST be present.

The CRLReason indicated MUST contain a value permitted for CRLs, as specified in Section 10.2.2, “CRL and CRL entry extensions”.

10.3.1. Version number(s)

No stipulation.

10.3.2. OCSP extensions

The singleExtensions of an OCSP response MUST NOT contain the reasonCode (OID 2.5.29.21) CRL entry extension.

10.4. Certificate profiles

This name is very similar to Section 10.1, “Certificate profile”, in this same major section. Can we merge these or choose names that are less similar?

These listings appear to be written in YAML. If so, please add a link to the definition of the YAML grammar. If YAML is correct, consider adding YAML syntax coloring. (Replace [source] with [source,yaml] in each of the listings below.)

10.4.1. Certificate profiles for certification authorities

10.4.1.1. Root
# Summary of Certificate Profile Constraints for a self-signed CAWG Root CA certificate

Profile: C2PA Root CA

Core Fields:
  Version: v3
  Serial Number: Positive integer (high entropy recommended) up to 20 octets
  Signature Algorithm: RSA (PSS or SHA2 variants) or ECDSA (SHA2 variants)
  Issuer Name: Matches Subject Name (Self-Signed). Requires C, O, CN attributes.
  Validity Period: Long-term (e.g., 20 years typical). Specific dates set at generation.
  Subject Name: Unique name for the Root CA. Requires C, O, CN attributes. Matches Issuer Name.
  Subject Public Key Info:
    Algorithm: rsaEncryption or id-ecPublicKey
    RSA Key Size: 3072 bits or larger
    ECC Curve: P-384 or P-521

Extensions:
  Subject Key Identifier:
    Presence: MUST
    Critical: FALSE
    Value: Hash of public key (RFC 5280 Method 1 - SHA-1)
  Authority Key Identifier:
    Presence: OPTIONAL
    Critical: FALSE
    Value: MUST contain keyIdentifier matching Subject Key Identifier (using RFC 5280 Method 1 - SHA-1). Issuer/Serial optional.
  Key Usage:
    Presence: MUST
    Critical: TRUE
    Bits: keyCertSign, cRLSign
  Basic Constraints:
    Presence: MUST
    Critical: TRUE
    Value: cA=TRUE, pathLenConstraint=2 or less
  Certificate Policies:
    Presence: SHOULD NOT
    Critical: FALSE
  extkey Usage:
    Presence: MUST NOT
    Critical: FALSE
  Authority Information Access:
    Presence: MUST NOT
  CRL Distribution Points:
    Presence: MUST NOT

Remove C2PA reference.

10.4.1.2. Intermediate CA
# Summary of Certificate Profile Constraints for the first intermediate CA certificate

Profile: CAWG First Intermediate CA

Core Fields:
  Version: v3
  Serial Number: Positive integer (high entropy recommended) up to 20 octets
  Signature Algorithm: RSA (PSS or SHA2 variants) or ECDSA (SHA2 variants)
  Issuer Name: Matches Subject Name of Root CA.
  Validity Period: Medium-term (e.g., 5 years typical). Specific dates set at generation.
  Subject Name: Unique name for the First Intermediate CA. Requires C, O, CN attributes.
  Subject Public Key Info:
    Algorithm: rsaEncryption or id-ecPublicKey
    RSA Key Size: 3072 bits or larger
    ECC Curve: P-384 or P-521

Extensions:
  Subject Key Identifier:
    Presence: MUST
    Critical: FALSE
    Value: Hash of public key (RFC 5280 Method 1 - SHA-1)
  Authority Key Identifier:
    Presence: MUST
    Critical: FALSE
    Value: MUST contain keyIdentifier matching Subject Key Identifier (using RFC 5280 Method 1 - SHA-1). Issuer/Serial optional.
  Key Usage:
    Presence: MUST
    Critical: TRUE
    Bits: keyCertSign, cRLSign
  Basic Constraints:
    Presence: MUST
    Critical: TRUE
    Value: cA=TRUE, pathLenConstraint=1
  Certificate Policies:
    Presence: MUST
    Critical: FALSE
    Value: MUST contain CAWG-certificate-policy OID (TBD). MAY also contain an additional policy OID from the IANA private arc controlled by the CA to indicate the CPS under which the CA is operated. Qualifiers optional.
  Authority Information Access:
    Presence: MUST (if CRL Distribution Points is not present)
    Critical: FALSE
    Value: Sequence of AccessDescription. MUST include one with accessMethod=id-ad-ocsp. SHOULD include one with accessMethod=id-ad-caIssuers. accessLocation must be HTTP URI.
  CRL Distribution Points:
    Presence: MUST (if Authority Information Access with id-ad-ocsp is not present)
    Critical: FALSE
    Value: MUST contain HTTP URI pointing to CRL location.
10.4.1.3. Claim signing issuing CA
# Summary of Certificate Profile Constraints for the last intermediate CA which issues CAWG claim signing leaf certificates

Profile: CAWG claim signing issuing CA

Core Fields:
  Version: v3
  Serial Number: Positive integer (high entropy recommended) up to 20 octets
  Signature Algorithm: RSA (PSS or SHA2 variants) or ECDSA (SHA2 variants)
  Issuer Name: Matches Subject Name of signing issuing CA (either Root CA or another subordinate).
  Validity Period: Max 1827 days.
  Subject Name: Unique name for the Issuing CA. Requires C, O, CN attributes.
  Subject Public Key Info:
    Algorithm: rsaEncryption or id-ecPublicKey
    RSA Key Size: 3072 bits or larger
    ECC Curve: P-384 or P-521

Extensions:
  Subject Key Identifier:
    Presence: MUST
    Critical: FALSE
    Value: Hash of public key (RFC 5280 Method 1 - SHA-1)
  Authority Key Identifier:
    Presence: MUST
    Critical: FALSE
    Value: MUST contain keyIdentifier (matching the SKI of the CA that issued this cert (root or intermediate), using RFC 5280 Method 1). Issuer/Serial optional.
  Key Usage:
    Presence: MUST
    Critical: TRUE
    Bits: keyCertSign, cRLSign
  Basic Constraints:
    Presence: MUST
    Critical: TRUE
    Value: cA=TRUE, pathLenConstraint=0
  Extended Key Usage:
    Presence: MUST
    Critical: FALSE
    Value: MUST contain CAWG-kp-claimSigning in addition to at least one of id-kp-emailProtection, id-kp-documentSigning
  Certificate Policies:
    Presence: MUST
    Critical: FALSE
    Value: MUST contain CAWG-certificate-policy OID (TBD). ). MAY also contain an additional policy OID from the IANA private arc controlled by the CA to indicate the CPS under which the CA is operated. Qualifiers optional.
  Authority Information Access:
    Presence: MUST (if CRL Distribution Points is not present)
    Critical: FALSE
    Value: Sequence of AccessDescription. MUST include one with accessMethod=id-ad-ocsp. SHOULD include one with accessMethod=id-ad-caIssuers. accessLocation must be HTTP URI.
  CRL Distribution Points:
    Presence: MUST (if Authority Information Access with id-ad-ocsp is not present)
    Critical: FALSE
    Value: MUST contain HTTP URI pointing to CRL location.

Naming and conflict: CAWG-kp-claimSigning will be confused with c2pa-kp-claimSigning, and identity signing isn’t claim signing. It also contradicts the BR subordinate CA profile, which requires emailProtection. Suggest cawg-kp-identitySigning with a real OID, and dropping emailProtection here.

10.4.1.4. TSA issuing CA
# Summary of Certificate Profile for the last intermediate CA which issues TSA time-stamp signing leaf certificates

Profile: C2PA TSA Issuing CA

Core Fields:
  Version: v3
  Serial Number: Positive integer (high entropy recommended) up to 20 octets
  Signature Algorithm: RSA (PSS or SHA2 variants) or ECDSA (SHA2 variants)
  Issuer Name: Matches Subject Name of signing Root CA.
  Validity Period: Max 5479 days
  Subject Name: Unique name for the TSA Issuing CA. Requires C, O, CN attributes.
  Subject Public Key Info:
    Algorithm: rsaEncryption or id-ecPublicKey
    RSA Key Size: 3072 bits or larger
    ECC Curve: P-384 or P-521

Extensions:
  Subject Key Identifier:
    Presence: MUST
    Critical: FALSE
    Value: Hash of public key (RFC 5280 Method 1 - SHA-1)
  Authority Key Identifier:
    Presence: MUST
    Critical: FALSE
    Value: MUST contain keyIdentifier (matching the SKI of the CA that issued this cert (root or intermediate), using RFC 5280 Method 1). Issuer/Serial optional.
  Key Usage:
    Presence: MUST
    Critical: TRUE
    Bits: keyCertSign, cRLSign
  Basic Constraints:
    Presence: MUST
    Critical: TRUE
    Value: cA=TRUE, pathLenConstraint=0
  Extended Key Usage:
    Presence: MUST
    Critical: FALSE
    Value: MUST contain exactly id-kp-timeStamping.
  Certificate Policies:
    Presence: MUST
    Critical: FALSE
    Value: MUST contain CAWG-certificate-policy OID (1.3.6.1.4.1.62558.1.1). MAY also contain an additional policy OID from the IANA private arc controlled by the CA to indicate the CPS under which the CA is operated. Qualifiers optional.
  Authority Information Access:
    Presence: MUST (if CRL Distribution Points is not present)
    Critical: FALSE
    Value: Sequence of AccessDescription. MUST include one with accessMethod=id-ad-ocsp. SHOULD include one with accessMethod=id-ad-caIssuers. accessLocation must be HTTP URI.
  CRL Distribution Points:
    Presence: MUST (if Authority Information Access with id-ad-ocsp is not present)
    Critical: FALSE
    Value: Must contain HTTP URI pointing to CRL location.

Remove C2PA reference in title.

Wrong OID: 1.3.6.1.4.1.62558.1.1 is C2PA’s certificate policy OID (PEN 62558 belongs to C2PA). Replace it with the CAWG CP OID once assigned.

10.4.2. Certificate profiles for leaf certificates

10.4.2.1. OCSP responder leaf certificates
# Summary of CAWG OCSP Responder Certificate Profile Constraints (leaf certificate)

Profile: CAWG OCSP Responder

Core Fields:
  Version: v3
  Serial Number: Positive integer (high entropy recommended) up to 20 octets
  Signature Algorithm: RSA (PSS or SHA2 variants) or ECDSA (SHA2 variants) - EdDSA excluded.
  Issuer Name: Matches Subject Name of signing Issuing CA.
  Validity Period: Specific dates set at generation (Max duration not specified by CAWG profile).
  Subject Name: Unique name for the OCSP Responder. Requires C, O, CN attributes.
  Subject Public Key Info:
    Algorithm: rsaEncryption or id-ecPublicKey
    RSA Key Size: 2048 bits or larger
    ECC Curve: P-256, P-384, or P-521

Extensions:
  Subject Key Identifier:
    Presence: MUST
    Critical: FALSE
    Value: Hash of public key (RFC 5280 Method 1 - SHA-1)
  Authority Key Identifier:
    Presence: MUST
    Critical: FALSE
    Value: MUST contain keyIdentifier (matching Issuing CA SKI, using RFC 5280 Method 1). Issuer/Serial optional.
  Key Usage:
    Presence: MUST
    Critical: TRUE
    Bits: digitalSignature
  Basic Constraints:
    Presence: MUST
    Critical: TRUE
    Value: cA=FALSE
  Extended Key Usage:
    Presence: MUST
    Critical: FALSE
    Value: MUST contain exactly id-kp-OCSPSigning.
  OCSP NoCheck:
    Presence: MUST
    Critical: FALSE
    Value: NULL
  Authority Information Access:
    Presence: MUST NOT
  CRL Distribution Points:
    Presence: MUST NOT
10.4.2.2. CAWG claim signing leaf certificates - any assurance level

Missing subscriber profile: this section has no leaf profile, and the text after it is pasted prose. the identity leaf is the most important profile in the document. suggest: CA=false; digitalsignature (optionally nonrepudiation); CAWG EKU and/or documentsigning; CAWG policy OID plus a validation-type OID; validity of 366 days or less; aia with OCSP.

This section appears to contain a combination of Markdown and YAML. Once we decide on the appropriate structure, translate from Markdown syntax to Asciidoc.

# Summary of CAWG claim signing leaf certificate profile constraints for any assurance level

#### All Certificates

All fields and extensions MUST be set in accordance with https://datatracker.ietf.org/doc/html/rfc5280[RFC 5280]. The CA MUST NOT issue a Certificate that contains a `keyUsage` flag, `extKeyUsage` value, Certificate extension, or other data not specified in <<certificate-content-and-extensions-root-ca-certificates>>, <<certificate-content-and-extensions-subordinate-ca-certificates>>, or <<certificate-content-and-extensions-subscriber-certificates>> unless the CA is aware of a reason for including the data in the Certificate. If the CA includes fields or extensions in a Certificate that are not specified but are otherwise permitted by these requirements, then the CA MUST document the processes and procedures that the CA employs for the validation of information contained in such fields and extensions in its CP and/or CPS.

CAs MUST NOT issue a Certificate with:

1. Extensions that do not apply in the context of the public Internet (such as an `extKeyUsage` value for a service that is only valid in the context of a privately managed network), unless:<br>
   i. such value falls within an OID arc for which the Applicant demonstrates ownership, or<br>
   ii. the Applicant can otherwise demonstrate the right to assert the data in a public context; or<br>
   iii. the extension is defined within an open standards specification and intended for use by other organizations. A Certificate that includes such an extension MUST conform to the specifications of the open standard and of these requirements.
2. Field or extension values which have not been validated according to the processes and procedures described in these requirements or the CA's CP and/or CPS.

#### TSA Time-Stamp Signing Leaf Certificates

\\\ yaml
# Human-readable summary of C2PA TSA Time-Stamp Signing Leaf Certificate Profile Constraints
Profile: C2PA TSA Time-Stamp Signing Leaf
Core Fields:
  Version: v3
  Serial Number: Positive integer (high entropy recommended) up to 20 octets
  Signature Algorithm: RSA (PSS or SHA2 variants) or ECDSA (SHA2 variants) - EdDSA excluded.
  Issuer Name: Matches Subject Name of signing TSA Issuing CA.
  Validity Period: Max 4110 days
  Subject Name: Unique name for the TSA service. Requires C, O, CN attributes.
  Subject Public Key Info:
    Algorithm: rsaEncryption or id-ecPublicKey
    RSA Key Size: 2048 bits or larger
    ECC Curve: P-256, P-384, or P-521

Extensions:
  Subject Key Identifier:
    Presence: MUST
    Critical: FALSE
    Value: Hash of public key (RFC 5280 Method 1 - SHA-1)
  Authority Key Identifier:
    Presence: MUST
    Critical: FALSE
    Value: MUST contain keyIdentifier (matching TSA Issuing CA SKI, using RFC 5280 Method 1). Issuer/Serial optional.
  Key Usage:
    Presence: MUST
    Critical: TRUE
    Bits: digitalSignature, nonRepudiation (contentCommitment)
  Basic Constraints:
    Presence: MUST
    Critical: TRUE
    Value: cA=FALSE
  Extended Key Usage:
    Presence: MUST
    Critical: TRUE
    Value: MUST contain exactly id-kp-timeStamping.
  Certificate Policies:
    Presence: MUST
    Critical: FALSE
    Value: MUST contain CAWG-certificate-policy OID (TBD). MAY also contain an additional policy OID from the IANA private arc controlled by the CA to indicate the CPS under which the issuing CA is operated. Qualifiers optional.
  Authority Information Access:
    Presence: MUST (if CRL Distribution Points is not present)
    Critical: FALSE
    Value: Sequence of AccessDescription. MUST include one with accessMethod=id-ad-ocsp. SHOULD include one with accessMethod=id-ad-caIssuers. accessLocation must be HTTP URI.
  CRL Distribution Points:
    Presence: MUST (if Authority Information Access with id-ad-ocsp is not present)
    Critical: FALSE
    Value: MUST contain HTTP URI pointing to CRL location.

10.5. CRL profile

See identically-named Section 10.2, “CRL profile” in this same major section. Can we merge these?

This CP does not require CAs to implement CRLs to support certificate revocation status checking. Should the CA choose to implement CRLs for their CA or subscriber certificates, the CRLs MUST conform with the minimum CRL profile specified in RFC 5280 Section 5.

Add link to RFC.

10.6. OCSP profile

See identically-named Section 10.3, “OCSP profile” in this same major section. Can we merge these?

OCSP responses MUST, at a minimum, conform to profile specified in the RFC 6960.

Add link to RFC.

11. Compliance audit and other assessments

This section defines the requirements for compliance audits and assessments to verify adherence to this CP and maintain the integrity of the PKI system, specifically focusing on the processes and controls surrounding the issuance and management of certificates.

11.1. Compliance audits

11.1.1. Regular audits

  1. The CA MUST undergo regular compliance audits conducted by an independent, qualified third-party auditor.

  2. Audits MUST assess the CA’s adherence to this CP, relevant industry standards (e.g., WebTrust for CA), and any applicable legal or regulatory requirements.

  3. The audit frequency MUST depend on the risk profile and assurance level, but at a minimum, annual audits are recommended.

Audits: annual audits are only recommended and WebTrust is an example. Suggest annual audits MUST be done under WebTrust for CAs plus WebTrust S/MIME, or ETSI EN 319 411-1.

11.1.2. Audit scope

Audits SHOULD cover all aspects of the CA’s operations relevant to this CP, with particular emphasis on:

  1. certificate issuance, renewal, and revocation processes;

  2. attestation validation procedures;

  3. key management practices within devices or applications and the CA’s infrastructure;

  4. logical and procedural security controls;

  5. personnel security and training related to attestation validation and certificate management; and

  6. incident response and disaster recovery procedures.

11.1.3. Audit reports

  1. The CA SHOULD make audit reports available to the CAWG steering committee and other authorized parties upon request.

  2. Audit reports SHOULD clearly identify any non-conformities or areas for improvement.

  3. Audit reports SHOULD be in International English or be accompanied by a professional translation to English.

  4. The CA SHOULD take corrective action to address any identified deficiencies.

11.2. Other assessments

11.2.1. Vulnerability assessments and penetration tests

  1. The CA SHOULD conduct regular vulnerability assessments and penetration tests on its infrastructure, systems, and attestation validation processes (if applicable) to identify and address security weaknesses.

  2. These assessments SHOULD be performed by qualified security professionals and SHOULD also include reviews of the security of the generator product platforms and any attestation services used.

    Revisit reference to generator product. Likely holdover from C2PA.

  3. Remediation plans SHOULD be developed and implemented to address any identified vulnerabilities.

11.2.2. Security incident reviews

  1. In the event of a security incident, the CA MUST conduct a thorough review to determine the root cause, impact, and lessons learned.

  2. The review MUST result in actionable recommendations to prevent similar incidents in the future.

  3. Incident reports MUST be shared with the CAWG steering committee and the CAWG trust task force.

    Do we want to add any stipulation about privacy or confidentiality in meetings where incident reports are discussed?

The CA’s commitment to regular compliance audits and other assessments demonstrates its dedication to maintaining a secure and trustworthy PKI environment for CAWG content origination.

This section outlines various business and legal considerations pertinent to the issuance and utilization of certificates under this CP, delineating the financial obligations, confidentiality and privacy safeguards, intellectual property rights, and dispute resolution mechanisms.

12.1. Fees

12.1.1. Fees for services

The CA MAY levy reasonable fees for services rendered under this CP, encompassing certificate issuance, renewal, revocation, and technical support. The fee structure MUST be transparently published and readily accessible to subscribers.

12.1.2. Fee adjustments

The CA reserves the right to modify its fee structure with prior notification to subscribers, ensuring transparency and predictability in cost management.

12.1.3. Subscriber responsibility

The subscriber assumes full responsibility for any and all fees incurred under this CP.

12.2. Financial responsibility

12.2.1. Subscriber’s financial obligation

The subscriber bears the financial responsibility for all fees associated with the certificate lifecycle, including issuance, renewal, and any potential revocation fees.

12.2.2. CA’s limited liability

The CA MUST NOT be held liable for any financial losses or damages incurred by the subscriber as a consequence of certificate misuse, compromise, or revocation, unless such losses directly arise from the CA’s negligence or willful misconduct.

12.3. Confidentiality of business information

12.3.1. CA’s commitment to confidentiality

The CA pledges to uphold the confidentiality of all non-public subscriber business information obtained during the certificate application and validation processes.

12.3.2. Information sharing restrictions

Such information MUST NOT be shared with any third parties without the subscriber’s explicit written consent, except when mandated by law or regulation, or required for independent auditing purposes.

12.4. Privacy of personal information

12.4.1. Compliance with privacy laws

The CA commits to collecting and processing personal information in strict accordance with applicable privacy laws and regulations.

12.4.2. Purpose limitation

Personal information MUST be collected and utilized solely for the purposes explicitly outlined in this CP, including but not limited to identity verification and certificate issuance.

12.4.3. Data subject rights

Subscribers retain the right to access, rectify, or erase their personal information held by the CA, subject to legal and regulatory constraints.

12.5. Intellectual property rights

12.5.1. Subscriber’s ownership

The subscriber maintains full ownership and control over all intellectual property rights associated with the claim generation implementation that signs using certificates issued under this CP.

12.5.2. CA’s non-claim

The CA asserts no claim or ownership over any intellectual property rights pertaining to the subscriber’s implementation.

12.6. Representations and warranties

12.6.1. CA representations

By issuing a certificate, the CA makes the certificate warranties listed herein to the following certificate beneficiaries:

  1. The subscriber that is a party to the subscriber agreement or terms of use for the certificate;

  2. The CAWG with whom the issuing CA has entered into a contract for inclusion of a CA record in the CAWG trust list; and

    Legal: contracting requires a legal entity; under the LF JDF structure that would be the project’s series LLC, so check with LF counsel, including the Delaware clause (which also reads governed by MUST be construed). The Right to Use Domain Name warranty refers to a product name, a C2PA leftover. Disclaimers, liability and dispute resolution are all No stipulation; CAs should at least have to state these in their CPS.

  3. All relying parties who reasonably rely on a valid certificate.

The CA represents and warrants to the certificate beneficiaries that, during the period when the certificate is valid, the CA has complied with these requirements and its disclosed business practices in issuing and managing the certificate.

The certificate warranties specifically include, but are not limited to, the following:

  1. Right to use domain name or IP address: That, at the time of issuance, the CA

    1. implemented a procedure for verifying that the applicant either had the right to use, or had control of, product name listed in the certificate’s subject field and subjectAltName extension;

      Not sure domain name, IP address, or product name make sense in the CAWG context.

    2. followed the procedure when issuing the certificate; and

    3. accurately described the procedure in the CA’s certificate policy and/or certification practice statement;

  2. Authorization for certificate: That, at the time of issuance, the CA

    1. implemented a procedure for verifying that the subject authorized the issuance of the certificate and that the applicant representative is authorized to request the certificate on behalf of the subject;

    2. followed the procedure when issuing the certificate; and

    3. accurately described the procedure in the CA’s certificate policy and/or certification practice statement;

  3. Accuracy of information: That, at the time of issuance, the CA

    1. implemented a procedure for verifying the accuracy of all of the information contained in the certificate;

    2. followed the procedure when issuing the certificate; and

    3. accurately described the procedure in the CA’s certificate policy and/or certification practice statement;

  4. Subscriber agreement: That, if the CA and subscriber are not affiliated, the subscriber and CA are parties to a legally valid and enforceable subscriber agreement that satisfies these requirements, or, if the CA and subscriber are the same entity or are Affiliated, the applicant representative acknowledged the terms of use;

  5. Status: That the CA maintains a 24×7 publicly-accessible repository with current information regarding the status (valid or revoked) of all unexpired certificates; and

  6. Revocation: That the CA revokes the certificate for any of the reasons specified in this CP.

A root CA MUST be responsible for the performance and warranties of the issuing CA, for the issuing CA’s compliance with this CP, and for all liabilities and indemnification obligations of the issuing CA under this CP, as if the root CA were the issuing CA issuing the certificates.

12.6.2. Subscriber representations

By applying for and utilizing certificates under this CP, the subscriber represents and warrants the following:

  1. The information furnished in the certificate application is accurate, complete, and truthful.

  2. They possess the requisite legal authority to request and utilize certificates under this CP.

  3. They MUST adhere to all stipulations and restrictions delineated in this CP.

  4. They MUST employ the certificates solely for their intended purpose, refraining from any prohibited activities.

12.7. Disclaimers of warranties

12.7.1. CA’s disclaimer

No stipulation.

12.7.2. Content disclaimer

No stipulation.

12.8. Limitations of liability

12.8.1. CA’s limited liability

No stipulation.

12.8.2. Exclusion of consequential damages

No stipulation.

12.9. Indemnities

No stipulation.

12.10. Term and termination

12.10.1. Term

This CP becomes effective when approved by the CAWG governing authority. Amendments to this CP become effective upon publication. This CP has no specified term.

12.10.2. Termination

This CP, as amended from time to time, MUST remain in force until it is replaced by a new version. Termination of this CP is at the discretion of the CAWG governing authority.

12.10.3. Termination rights

No stipulation.

12.10.4. Post-termination obligations

No stipulation.

12.11. Individual notices and communications with participants

12.11.1. Written communication

All official notices and communications between the CA and the subscriber MUST be in writing and conveyed electronically or by mail.

12.11.2. Contact information

All parties MUST maintain accurate and up-to-date contact information to facilitate effective communication.

12.12. Amendments

12.12.1. Policy modification

The CAWG governing authority retains the right to amend this CP at any time, reflecting evolving security best practices, technological advancements, or regulatory changes.

12.12.2. Subscriber notification

Subscribers MUST be promptly notified of any material changes to the CP through appropriate channels, ensuring they remain informed of their obligations and responsibilities.

12.12.3. Acceptance of amendments

Continued utilization of certificates after CP amendments constitutes the subscriber’s acceptance of the revised terms and conditions.

12.13. Dispute resolution procedures

No stipulation.

12.14. Governing law

12.14.1. Jurisdiction

This CP and any agreements arising from it MUST be governed by MUST be construed pursuant to the laws of the State of Delaware (without regard to conflict of laws principles). The state and federal courts of Delaware, U.S.A. MUST have jurisdiction and the parties waive any other jurisdiction.

“MUST be governed by” vs “MUST be construed pursuant to”: choose one.

12.15. Compliance with applicable law

Both the CA and the subscriber are obligated to comply with all applicable laws and regulations pertaining to the issuance, use, and management of certificates under this CP.

12.16. Miscellaneous provisions

12.16.1. Governing agreements

12.16.1.1. Between the CAWG governing authority and CAs

The relationship between the CAWG governing authority and the CAs MUST be governed by the certification authority agreement and this certificate policy.

12.16.1.2. Between CAs and subscribers

The relationship between the CA and the subscriber MUST be governed by the CA’s subscriber agreement.

12.16.2. Waiver

No stipulation.

12.16.3. Severability

In the event that any provision of this CP is deemed invalid or unenforceable, the remaining provisions MUST remain in full force and effect, and the invalid or unenforceable provision MUST be replaced with a valid and enforceable provision that most closely approximates the intent of the original provision.

12.17. Other provisions

No stipulation.

13. Requirements for validating dynamic evidence

C2PA leftover: everything from here to the end of the document (AL1/AL2 tables, generator product objectives, Android/Apple/cloud attestation guidance) is C2PA device-attestation material with no meaning for a person’s or newsroom’s identity certificate. Suggest deleting it; if CAWG wants assurance levels, define identity assurance levels mapped to the organization, Sponsor and individual validation types. Assurance level is currently used without a definition.

13.1. Requirements for assurance level 1 certificates

13.1.1. O.1 Conforming GP instance provides proof of its eligibility during automated certificate enrollment.

Requirement: CA MUST verify that the entity attempting certificate enrollment is an instance of a subscriber’s generator product, through an authentication method commonly accepted for certificate enrollment (e.g. SCEP, EST, ACME, client certificates, etc.).

13.1.2. O.2 GP TOE protects the confidentiality of the signing key.

No stipulation.

13.1.3. O.3 - GP TOE protects the Claim Generator from exploits, misconfiguration and misuse.

No stipulation.

13.1.4. O.4 - GP TOE protects the asset and assertions from being tampered with at generation.

No stipulation.

13.1.5. O.5 - GP TOE protects the traffic between subsystems and components of those subsystems from being intercepted and/or modified.

No stipulation.

13.1.6. O.6 - Hosting environment is protected from exploit, misconfiguration and misuse.

No stipulation.

13.2. Requirements for assurance level 2 certificates

13.2.1. O.1 Conforming GP instance provides proof of its eligibility during automated certificate enrollment.

Requirement: CA MUST verify that the entity attempting certificate enrollment is an instance of a subscriber’s generator product, through requesting and validating verifiable, hardware-backed artifacts that attest to the package names, hashes, code signing certificates or other certificates of the entity requesting certificate enrollment. CA MUST NOT issue a certificate if the entity attempting certificate enrollment is unable to present this evidence, or if the values in the hardware-backed artifacts do not meet the aforementioned requirements.

13.2.2. O.2 GP TOE protects the confidentiality of the signing key.

Requirement: CA MUST verify that the key pair for which certificate enrollment is being attempted is generated and stored within a hardware-backed platform keystore service or Key Management Service, by requesting and validating verifiable, hardware-backed artifacts that attest to the security attributes of the key and its possession by an instance of the subscriber’s generator product. CA MUST NOT issue a certificate if the entity attempting certificate enrollment is unable to present this evidence, or if the values in the hardware-backed artifacts do not meet the aforementioned requirements.

13.2.3. O.3 - GP TOE protects the Claim Generator from exploits, misconfiguration and misuse.

Consider having numbered subsections or a numbered list where there are multiple requirements such as this.

Requirement: CA MUST verify that the platform on which the Claim Generator integrated with the instance of the generator product attempting certificate enrollment is running has booted securely into authenticated software images by requesting and validating verifiable artifacts backed by a hardware root of trust. CA MUST NOT issue a certificate if the entity attempting certificate enrollment is unable to present this evidence, or if the values in the hardware-backed artifacts do not meet the aforementioned requirements.

Requirement: CA MUST verify that the platform on which the Claim Generator integrated with the instance of the generator product attempting certificate enrollment is running has security patches no older than the latest patch or version required to fix or otherwise mitigate any vulnerabilities with a CRITICAL or HIGH severity ratings in the NIST Common Vulnerability Scoring System (CVSS, https://nvd.nist.gov/vuln-metrics/cvss) version 3 or greater, within 90 days of detection, by requesting and validating verifiable artifacts backed by a hardware root of trust. CA MUST NOT issue a certificate if the entity attempting certificate enrollment is unable to present this evidence, or if the values in the hardware-backed artifacts do not meet the aforementioned requirements.

Requirement: CA MUST verify, depending on the method which the applicant has selected:

  1. the recency of application of security patches of the Claim Generator integrated with the instance of the generator product requesting certificate enrollment is no older than 90 days

  2. that the revision (e.g. version, branch, or commit identifier) of the Claim Generator integrated with the instance of the generator product attempting certificate enrollment is one that is registered in good standing with the CA, by requesting and validating verifiable artifacts backed by a hardware root of trust.

CA MUST NOT issue a certificate if the entity attempting certificate enrollment is unable to present this evidence, or if the values in the hardware-backed artifacts do not meet the aforementioned requirements.

13.2.4. O.4 - GP TOE protects the asset and assertions from being tampered with at generation.

Requirement: CA MUST verify that the platform on which software in the GP TOE that processes/modifies the Digital Content and/or assertions is running has booted securely into authenticated software images, by requesting and validating verifiable artifacts backed by a hardware root of trust. CA MUST NOT issue a certificate if the entity attempting certificate enrollment is unable to present this evidence, or if the values in the hardware-backed artifacts do not meet the aforementioned requirements.

Requirement: CA MUST verify that the platform on which all such software in the GP TOE is running has security patches no older than the latest patch or version required to fix or otherwise mitigate any vulnerabilities with a CRITICAL or HIGH severity ratings in the NIST Common Vulnerability Scoring System (CVSS, https://nvd.nist.gov/vuln-metrics/cvss) version 3 or greater, within 90 days of detection, by requesting and validating verifiable artifacts backed by a hardware root of trust. CA MUST NOT issue a certificate if the entity attempting certificate enrollment is unable to present this evidence, or if the values in the hardware-backed artifacts do not meet the aforementioned requirements.

Requirement: CA MUST verify, depending on the method which the applicant has selected:

  1. the recency of application of security patches of all such software in the GP TOE is no older than 90 days

  2. that the revision (e.g. version, branch, or commit identifier) of the all such software in the GP TOE attempting certificate enrollment is one that is registered in good standing with the CA, by requesting and validating verifiable artifacts backed by a hardware root of trust.

CA MUST NOT issue a certificate if the entity attempting certificate enrollment is unable to present this evidence, or if the values in the hardware-backed artifacts do not meet the aforementioned requirements.

13.2.5. O.5 - GP TOE protects the traffic between subsystems and components of those subsystems from being intercepted and/or modified.

No stipulation.

13.2.6. O.6 - Hosting environment is protected from exploit, misconfiguration and misuse.

No stipulation.

14. Platform-specific guidance

Many references to “generator product” in this section. Will need to be reworded for CAWG context.

Should this section be non-normative?

While the CA is required to validate the above requirements, the specific methods for doing so varies by the specific service/platform. This section attempts to provide specific guidance for different types of platforms and attestation methods.

Generally, key and platform attestation flows require the CA to issue a unique, dynamic challenge (usually referred to as a nonce) to the entity from which it is requesting attestation. Platform attestation providers in turn include the challenge nonce in the attestation report, and the CA MUST verify that the challenge nonce in the attestation report matches the one that it issued to the instance of the generator product requesting certificates. CAs MUST follow the recommendations of attestation service/platform providers when generating nonces.

14.1. Android key attestation

Android key attestation can be used for validating the security attributes of a subscriber’s CAWG claim signing key, validating the identity and integrity of the instance of the generator product requesting certificates, and validating the integrity of the Android platform on which the application is running.

Not sure what the security objectives paragraph was intended to state. Possibly mangled in Asciidoc conversion.

Security objectives addressed by this service/platform: . security objective 1 . security objective 2 . security objective 3 . security objective 4

14.1.1. Resources

The following links are provided by Google. Non-normative references?

14.1.2. Guidance on values

14.1.2.1. Guidance on values for assurance level 1

No stipulation.

14.1.2.2. Guidance on values for assurance level 2

Based on the values of the attributes in the Android Key attestation certificate attestation extension

Consider linking the Security objectives and other requirement sources to the relevant parts of this document?

Formatting needs work here. Long identifierNames are distorting the column-width preferences I am requesting.

Requirement source Attestation certificate chain attribute Value

security objective O.3, security objective O.4

Leaf certificate → 1.3.6.1.4.1.11129.2.1.17 → attestationSecurityLevel

1 (TrustedEnvironment) or 2 (StrongBox)

security objective O.3, security objective O.4

Leaf certificate → 1.3.6.1.4.1.11129.2.1.17 → keyMintSecurityLevel

1 (TrustedEnvironment) or 2 (StrongBox)

security objective O.1, security objective O.2, security objective O.3, security objective O.4

Leaf certificate → 1.3.6.1.4.1.11129.2.1.17 → attestationChallenge

Matches the value of the challenge issued by the CA

security objective O.1

Leaf certificate → 1.3.6.1.4.1.11129.2.1.17 → softwareEnforced.attestationApplicationID [Tag 709] → package_infos → set element → package_name

Matches the package name of the subscriber’s generator product app that’s registered with the CA

security objective O.1

Leaf certificate → 1.3.6.1.4.1.11129.2.1.17 → softwareEnforced.attestationApplicationID [Tag 709] → package_infos → set element → version

Matches one of the versions of the subscriber’s generator product app that’s registered with the CA

security objective O.1

Leaf certificate → 1.3.6.1.4.1.11129.2.1.17 → softwareEnforced.attestationApplicationID [Tag 709] → signature_digests → set element

Matches the SHA-256 digests of the subscriber’s generator product app’s signing certificates registered with the CA

claim signing certificate profile constraint

Leaf certificate → 1.3.6.1.4.1.11129.2.1.17 → hardwareEnforced.purpose [Tag 1]

Set with an item whose value is equivalent to: SIGN/2 as described in KeyPurpose.aidl

claim signing certificate profile constraint

Leaf certificate → 1.3.6.1.4.1.11129.2.1.17 → hardwareEnforced.algorithm [Tag 2]

Equivalent to RSA/1 or EC/ 3 as described in Algorithm.aidl

claim signing certificate profile constraint

Leaf certificate → 1.3.6.1.4.1.11129.2.1.17 → hardwareEnforced.keySize [Tag 3]

For RSA keys, one of: 2048, 3072, 4096. For EC keys, one of: 256, 384, 521

claim signing certificate profile constraint

Leaf certificate → 1.3.6.1.4.1.11129.2.1.17 → hardwareEnforced.digest [Tag 5]

Set with items whose values are equivalent to: SHA_2_256/4 SHA_2_384/5, or SHA_2_512/6 as described in Digest.aidl

claim signing certificate profile constraint

Leaf certificate → 1.3.6.1.4.1.11129.2.1.17 → hardwareEnforced.padding [Tag 6]

[For RSA keys only] Equivalent to: RSA_PSS/3 as described in PaddingMode.aidl

claim signing certificate profile constraint

Leaf certificate → 1.3.6.1.4.1.11129.2.1.17 → hardwareEnforced.ecCurve [Tag 10]

Equivalent to: P_256/1, P_384/2, or P_521/3 as described in EcCurve.aidl Please note: Matches the corresponding value in Tag 3 for EC keys.

security objective O.2

Leaf certificate → 1.3.6.1.4.1.11129.2.1.17 → hardwareEnforced.origin [Tag 702]

Equivalent to: GENERATED/0 as described in KeyOrigin.aidl

security objective O.4

Leaf certificate → 1.3.6.1.4.1.11129.2.1.17 → hardwareEnforced.rootOfTrust [Tag 704] → deviceLocked [Element 2 of sequence]

Equivalent to true

security objective O.4

Leaf certificate → 1.3.6.1.4.1.11129.2.1.17 → hardwareEnforced.rootOfTrust [Tag 704] → verifiedBootState [Element 3 of sequence]

0 ( Verified)

security objective O.4

Leaf certificate → 1.3.6.1.4.1.11129.2.1.17 → hardwareEnforced.osPatchLevel [Tag 706]

4 months or less relative to the month of the CSR submission. Cannot be in the future relative to the month of the CSR submission. For example, for a CSR submitted in the month of August 2026, an acceptable value would be any of 202608, 202607, 202606, or 202605.

security objective O.1

Leaf certificate → 1.3.6.1.4.1.11129.2.1.17 → hardwareEnforced.attestationIdBrand [Tag 710]

If subscriber’s generator product app is intended to run on only a specific OEM device brand, matches the value registered with the CA

security objective O.1

Leaf certificate → 1.3.6.1.4.1.11129.2.1.17 → hardwareEnforced.attestationIdManufacturer [Tag 716]

If subscriber’s generator product app is intended to run on only a specific OEM device brand, matches the value registered with the CA

security objective O.1

Leaf certificate → 1.3.6.1.4.1.11129.2.1.17 → hardwareEnforced.attestationIdModel [Tag 717]

If subscriber’s generator product app is intended to run on only a specific OEM device model, matches the value registered with the CA

security objective O.4

Leaf certificate → 1.3.6.1.4.1.11129.2.1.17 → hardwareEnforced.vendorPatchLevel [Tag 718]

90 days or less from the date of the CSR submission. Cannot be in the future relative to the date of the CSR submission. For example, for a CSR submitted on June 20th, 2026, a value of 20260505 is acceptable (46 day difference), while a value of 20260105 is not (166 day difference).

security objective O.4

Leaf certificate → 1.3.6.1.4.1.11129.2.1.17 → hardwareEnforced.bootPatchLevel [Tag 718]

90 days or less from the date of the CSR submission. Cannot be in the future relative to the date of the CSR submission. For example, for a CSR submitted on June 20th, 2026, a value of 20260505 is acceptable (46 day difference), while a value of 20260105 is not (166 day difference).

14.2. Google Play Integrity

Add guidance based on Google Play Integrity documentation.

14.3. Apple App Attest

Add guidance based on Apple App Attest documentation.

14.4. Qualcomm Wireless Edge Services (QWES)

Add guidance based on Qualcomm WES documentation.

14.5. IETF remote attestation procedures (RATS)

Add guidance based on RFC 9334.

14.6. AWS Key Management Service

Add guidance based on AWS KMS documentation.

14.7. AWS Nitro Enclaves attestation

14.8. Microsoft Azure Key Vault and Azure managed HSM

14.9. Microsoft Azure attestation

Add guidance based on Azure attestation documentation.

14.10. Google Cloud Platform Cloud HSM Key attestation

14.11. Google Cloud Confidential VM attestation

Appendix A: Version history

This section is non-normative.

14 October 2026

  • Initial draft.