



Internet Engineering Task Force                        V. Joseph
Internet-Draft                                         E. Hamadeh
Intended status: Informational                         C. Zhang
Expires: August 20, 2026                               February 20, 2026


              Certificate Expectation Assertions (CEA)
                        draft-joseph-cea-00


Abstract

   This document specifies Certificate Expectation Assertions (CEA), a
   DNS-based mechanism enabling domain owners to publish expected
   certificate authority identities for their domains. Clients can
   compare observed TLS certificates against these published
   expectations to identify potential unauthorized interception.

   CEA uses DNSSEC-signed DNS TXT records, supports multiple certificate
   authorities, and employs fail-open transparency rather than blocking
   connections. This approach differs from HPKP's fail-secure model and
   provides an optional mechanism for interception detection.

   This document is published as Informational to document the CEA
   protocol for experimental deployment. It does not modify TLS or PKI
   infrastructure and is not an IETF standard. This is an experimental
   specification that has not been endorsed by any IETF Working Group
   and does not represent IETF consensus.

   Note: This document does not modify the TLS protocol (RFC 8446),
   certificate validation procedures (RFC 5280), or PKI infrastructure.
   CEA is an optional client-side transparency overlay that provides
   additional information to users. Implementations that do not support
   CEA continue to function normally with no changes to TLS behavior.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 20, 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.





[Vineeth Joseph , Ethan Hamadeh , Chen Zhang]              Expires August 20, 2026                [Page 1]

Internet-Draft                    CEA                      February 2026


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.3.  Key Design Features . . . . . . . . . . . . . . . . . . .   4
     1.4.  Scope and Non-Scope . . . . . . . . . . . . . . . . . . .   4
     1.5.  Relationship to Existing Work . . . . . . . . . . . . . .   5
   2.  Motivation and Problem Statement  . . . . . . . . . . . . . .   6
     2.1.  TLS Interception Landscape  . . . . . . . . . . . . .   4
     2.2.  Limitations of Existing Solutions . . . . . . . . . . . .   5
     2.3.  Design Requirements . . . . . . . . . . . . . . . . . . .   6
   3.  CEA Mechanism Overview  . . . . . . . . . . . . . . . . . . .   7
     3.1.  Publishing Certificate Expectations  . . . . . . . . . . .   7
     3.2.  Client Validation Process . . . . . . . . . . . . . . . .   7
     3.3.  User Experience . . . . . . . . . . . . . . . . . . . . .   8
   4.  CEA Record Specification  . . . . . . . . . . . . . . . . . .   9
     4.1.  DNS Resource Record Format  . . . . . . . . . . . . . . .   9
     4.2.  CEA Record Syntax . . . . . . . . . . . . . . . . . . . .   9
     4.3.  Field Definitions . . . . . . . . . . . . . . . . . . . .  10
     4.4.  DNSSEC Requirements . . . . . . . . . . . . . . . . . . .  11
     4.5.  Alternative Verification Methods  . . . . . . . . . . . .  12
   5.  Client Validation Algorithm . . . . . . . . . . . . . . . . .  14
     5.1.  CEA Record Discovery  . . . . . . . . . . . . . . . . . .  12
     5.2.  Certificate Validation  . . . . . . . . . . . . . . . . .  12
     5.3.  Error Handling  . . . . . . . . . . . . . . . . . . . . .  13
   6.  Semantic Trust Categories . . . . . . . . . . . . . . . . . .  14
     6.1.  Category Taxonomy . . . . . . . . . . . . . . . . . . . .  14
     6.2.  Policy Automation . . . . . . . . . . . . . . . . . . . .  15
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
     7.1.  Threat Model and Scope  . . . . . . . . . . . . . . . . .  18
     7.2.  DNSSEC Security Requirements  . . . . . . . . . . . . . .  20
     7.3.  DNS Poisoning Attacks . . . . . . . . . . . . . . . . . .  21
     7.4.  Downgrade Attacks and Fail-Open Behavior  . . . . . . . .  21
     7.5.  Privacy Considerations  . . . . . . . . . . . . . . . . .  22
     7.6.  Certificate Authority Compromise  . . . . . . . . . . . .  23
     7.7.  Interaction with Encrypted ClientHello  . . . . . . . . .  24
     7.8.  Additional Security Considerations  . . . . . . . . . . .  25
   8.  Operational Considerations  . . . . . . . . . . . . . . . . .  26
     8.1.  Certificate Authority Rotation  . . . . . . . . . . . . .  25
     8.2.  Key Rollover  . . . . . . . . . . . . . . . . . . . . . .  26
     8.3.  Monitoring and Incident Response  . . . . . . . . . . . .  26
   9. Deployment Guidance . . . . . . . . . . . . . . . . . . . . .  27
     9.1.  For Domain Owners  . . . . . . . . . . . . . . . . . . .  27
     9.2.  For Client Implementers  . . . . . . . . . . . . . . . .  28
     9.3.  For Enterprise Networks  . . . . . . . . . . . . . . . .  29
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  30
     10.1.  DNS TXT Record Prefix Registration . . . . . . . . . . .  30
     10.2.  CEA Version Registry . . . . . . . . . . . . . . . . . .  30
     10.3.  CEA Category Registry  . . . . . . . . . . . . . . . . .  31
   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  32
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  32
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  32
     12.2.  Informative References . . . . . . . . . . . . . . . . .  33
   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  25
   Appendix B.  Frequently Asked Questions . . . . . . . . . . . . .  26
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  28



[Vineeth Joseph , Ethan Hamadeh , Chen Zhang]              Expires August 20, 2026                [Page 2]

Internet-Draft                    CEA                      February 2026


1.  Introduction

   TLS [RFC8446] provides confidentiality and integrity for Internet
   communications. TLS interception by intermediaries creates
   transparency challenges. Existing mechanisms have limitations: HPKP
   [RFC7469] deprecated due to operational brittleness, Certificate
   Transparency [RFC6962] provides post-issuance auditing but not real-
   time detection.

   This document specifies Certificate Expectation Assertions (CEA), a
   DNS-based mechanism enabling domains to publish expected CA SPKI
   hashes and clients to identify mismatches, providing transparency
   signals that MAY indicate interception.

   CEA is complementary to CT [RFC6962] and DANE [RFC6698]. CEA does not
   replace PKIX validation (RFC 5280) or modify TLS (RFC 8446). CEA
   operates as an application-layer overlay AFTER standard TLS validation
   succeeds. All standard TLS validation (chain verification, hostname
   matching, expiration) continues unchanged.

   CEA does not define a new authentication mechanism, does not introduce
   new trust anchors, and does not alter TLS handshake processing; it
   provides an advisory transparency signal evaluated after successful
   PKIX validation.

   This specification is submitted as an experimental Independent Stream
   document. It does not claim to be the optimal solution for TLS
   transparency and welcomes feedback from the IETF community.
   Implementers should carefully evaluate whether CEA fits their specific
   deployment requirements.

1.1.  Requirements Language

   Key words per RFC 2119 [RFC2119]. Since this is Informational,
   normative language applies only to implementations that elect to
   support CEA.

1.2.  Terminology

   CA: Entity that issues certificates [RFC5280].
   CEA Record: DNS TXT record with certificate expectations.
   Interception: Intermediary terminates TLS, inspects plaintext.
   SPKI: DER-encoded public key from CA certificate [RFC5280].
   Expected Issuer: CA in CEA record authorized to issue certificates.
   Observed Issuer: CA in certificate presented during TLS handshake.

1.3.  Key Design Features

   1. SPKI-based expectations via DNS
   2. Multi-path consensus (resolver diversity, 75% threshold)
   3. Semantic categories (Financial, Healthcare) for compliance
   4. Tiered confidence levels (DNSSEC, DoT/DoH, multi-path, TOFU)
   5. Fail-open transparency (warnings, not blocking)

1.4.  Scope and Non-Scope

   CEA is NOT: a TLS protocol modification (RFC 8446), a change to
   certificate validation (RFC 5280), a PKI replacement, or mandatory.

   Clients that implement CEA are RECOMMENDED to: continue standard TLS
   validation per RFC 5280, avoid rejecting connections based solely on
   CEA failures, allow users to proceed despite mismatches.

1.4.1.  Explicit Non-Goals

   CEA does NOT protect against: state-level DNS infrastructure
   compromise (attacker controls authoritative DNS and DNSSEC), CA
   compromise listed in CEA record, client-side compromise, fail-open
   bypass (attacker blocks all verification paths).

   Mitigation for state-level DNS: Multi-path consensus with
   geographically diverse resolvers provides partial protection.

1.4.2.  Relationship to IETF Working Groups

   This document does not claim consensus from any IETF Working Group.
   CEA is an experimental mechanism submitted through the Independent
   Submission stream (RFC 8729). This specification does not represent
   IETF consensus and does not modify or supersede any IETF standards-
   track work. Implementers should be aware that CEA has not been
   reviewed or endorsed by the TLS Working Group, DNSOP Working Group,
   or any other IETF body.

1.5.  Relationship to Existing Work

   CEA builds upon lessons learned from prior certificate validation
   mechanisms. This section clarifies CEA's relationship to existing
   IETF specifications and explains design choices informed by
   deployment experience.

1.5.1.  Relationship to DANE (DNS-Based Authentication of Named Entities)

   DANE (RFC 6698, RFC 7671) is the most similar existing mechanism,
   using DNS to publish certificate expectations. Key differences:

   Design Philosophy:

   o  DANE: Fail-secure enforcement (MUST reject mismatches)
   o  CEA: Fail-open transparency (MAY warn users)

   DNSSEC Dependency:

   o  DANE: DNSSEC required for all deployments
   o  CEA: Tiered model works without DNSSEC (Levels 1-3)

   Deployment Status for HTTPS (2026):

   o  DANE HTTPS: Limited browser adoption despite RFC 6698 publication
      in 2012
   o  DANE has seen deployment primarily in the email/SMTP domain
   o  CEA: Experimental proposal informed by DANE deployment experience

   DANE Deployment Challenges for HTTPS:

   o  Fail-secure enforcement creates operational challenges for
      enterprise TLS inspection scenarios
   o  DNSSEC deployment remains limited in some regions
   o  Operational complexity similar to challenges faced by HPKP

   CEA Design Approach:

   o  Transparency-focused model accommodates enterprise inspection
      scenarios
   o  Tiered validation model functions without DNSSEC dependency
   o  Fail-open behavior reduces operational risk

   Relationship: CEA does not replace DANE. Both serve complementary
   roles for different use cases (DANE for mail servers with fail-secure
   needs, CEA for HTTPS with transparency focus).

   Technical Comparison Table:

   +------------------------+-----------------------+------------------+
   | Aspect                 | CEA                   | DANE             |
   +------------------------+-----------------------+------------------+
   | DNSSEC Required        | No (Levels 1-3)       | Yes (mandatory)  |
   |                        | Optional (Level 4)    |                  |
   +------------------------+-----------------------+------------------+
   | PKIX Replacement       | No (overlay only)     | Optional         |
   |                        |                       | (DANE-TA mode)   |
   +------------------------+-----------------------+------------------+
   | Deployment Scope       | Application policy    | DNS + TLS        |
   |                        | layer                 | infrastructure   |
   +------------------------+-----------------------+------------------+
   | Trust Anchor Change    | No (uses OS/browser   | Potentially yes  |
   |                        | CA store)             | (DANE-TA)        |
   +------------------------+-----------------------+------------------+
   | Failure Mode           | Fail-open (warnings)  | Fail-secure      |
   |                        |                       | (blocks)         |
   +------------------------+-----------------------+------------------+
   | Enterprise TLS         | Compatible (warns)    | Incompatible     |
   | Inspection             |                       | (blocks)         |
   +------------------------+-----------------------+------------------+
   | Browser Support        | Experimental          | Limited browser  |
   |                        |                       | adoption         |
   +------------------------+-----------------------+------------------+
   | Primary Use Case       | HTTPS transparency    | SMTP/Mail        |
   |                        |                       | authentication   |
   +------------------------+-----------------------+------------------+
   | TLS Validation         | None (advisory        | May augment or   |
   | Semantics              | overlay only)         | replace PKIX     |
   |                        |                       | validation       |
   +------------------------+-----------------------+------------------+

   DANE is appropriate for environments where fail-secure enforcement is
   acceptable (e.g., mail servers). CEA is designed for environments
   requiring transparency without blocking (e.g., enterprise web
   browsing).

   Architectural Distinction:

   CEA and DANE have complementary architectural approaches. DANE can
   modify TLS certificate validation (replacing or augmenting PKIX
   trust), while CEA operates as a transparency layer AFTER standard TLS
   validation succeeds. CEA provides transparency signals without
   blocking connections. This architectural difference allows both
   mechanisms to serve complementary roles in different deployment
   contexts.

1.5.2.  Relationship to HPKP (HTTP Public Key Pinning)

   HPKP (RFC 7469, deprecated 2018) provides the historical lesson that
   informed CEA's design.

   What HPKP Got Right:

   o  SPKI-based pinning (CEA uses same approach)
   o  Recognized need for CA-level expectations

   Why HPKP Failed:

   o  Operational Brittleness: Misconfigurations locked users out
      permanently
   o  Chicken-and-Egg: Delivered over HTTPS, couldn't validate first
      connection
   o  No Recovery: Once pinned incorrectly, domain became inaccessible
   o  Weaponization: Attackers could pin to malicious certificates

   CEA Design Improvements:

   o  DNS Delivery: Out-of-band, can validate first connection
   o  Fail-Open: Misconfigurations don't break sites
   o  TTL-Based Expiry: Errors automatically heal after TTL
   o  Multiple CAs: Supports smooth CA rotation
   o  Transparency Not Prevention: Users retain agency

   Specific HPKP Problem CEA Solves:

   HPKP Scenario: Domain owner sets pin for CA-A, later switches to
   CA-B, forgets to update pin. Result: All users locked out until max-
   age expires (months).

   CEA Equivalent: Domain owner publishes CEA for CA-A, switches to
   CA-B. Result: Users see warning but can proceed. CEA record updates
   via DNS TTL (hours), or domain owner can pre-publish both CAs.

   Historical Context: Chrome removed HPKP support in 2018 citing
   "limited legitimate usage and high risk of misconfiguration." CEA
   addresses these exact concerns through fail-open design and DNS-based
   updates.

1.5.3.  Relationship to Certificate Transparency (CT)

   Certificate Transparency (RFC 6962) and CEA are complementary, not
   competitive.

   CT's Role:

   o  Detects unauthorized issuance after the fact
   o  Monitors: "Did a CA issue a certificate it shouldn't have?"
   o  Timeline: Post-issuance detection (hours to days)

   CEA's Role:

   o  Detects unauthorized usage at connection time
   o  Monitors: "Is this certificate being used as expected?"
   o  Timeline: Real-time detection during TLS handshake

   Complementary Defense:

   o  CT: Detects unauthorized CA issuance (post-hoc monitoring)
   o  CEA: Detects when legitimate CAs are used for interception
         (real-time transparency)

   Example Scenario:

   1.  Enterprise installs corporate CA in employee devices
   2.  CT logs show no unauthorized issuance (CA is legitimate)
   3.  CEA identifies connection uses corporate CA instead of expected
       public CA (SPKI mismatch)
   4.  User informed of potential interception

   CT Cannot Detect:

   o  Enterprise proxy using locally-trusted CA
   o  State-level interception with compelled CA
   o  TLS interception using legitimate intermediate CAs

   CEA Cannot Detect:

   o  Compromised CA issuing fraudulent certificates (CT's job)
   o  Zero-day CA key compromise before CT logging

   Layered Security: Organizations should deploy both CT monitoring AND
   CEA validation for comprehensive protection.

1.5.4.  Relationship Summary

   CEA occupies a unique position in the certificate security ecosystem:

   +-------------------+-------------+--------+-------------------+
   | Mechanism         | Enforcement | Scope  | Browser Support   |
   +-------------------+-------------+--------+-------------------+
   | DANE (RFC 6698)   | Fail-secure | HTTPS  | Not deployed      |
   | HPKP (RFC 7469)   | Fail-secure | HTTPS  | Deprecated 2018   |
   | CT (RFC 6962)     | Observability| CA    | Universal         |
   | CAA (RFC 8659)    | Enforcement | CA     | N/A (CA-side)     |
   | CEA (This doc)    | Transparency| HTTPS  | Experimental      |
   +-------------------+-------------+--------+-------------------+

   Design Principle: CEA is transparency-focused and fail-open,
   differing from the fail-secure approaches of HPKP and DANE. CEA
   complements CT's post-issuance monitoring by detecting active
   interception in real-time.

   Key Feature: CEA provides user awareness through transparency signals
   rather than connection blocking, allowing deployment without the
   operational risks associated with fail-secure mechanisms.

2.  Motivation and Problem Statement

2.1.  TLS Interception Landscape

   TLS interception modifies the end-to-end security model of encrypted
   communications. Interception occurs in various contexts:

   Malicious Activity:  Attackers use interception techniques to
      eavesdrop on communications, steal credentials, inject malware,
      or perform man-in-the-middle attacks.

   Surveillance:  Government entities may intercept TLS traffic for
      intelligence gathering purposes, raising privacy concerns.

   Enterprise Monitoring:  Organizations deploy SSL/TLS inspection
      appliances for security analysis, though these systems create
      transparency and compliance considerations.

   Content Filtering:  Educational institutions and public networks
      use interception for policy enforcement, often without explicit
      user notification.

   The common characteristic of all interception scenarios is that the
   client application receives a certificate issued by an entity other
   than the domain owner's chosen certificate authority. When the
   intercepting CA's root certificate is trusted by the client (either
   through the system trust store or manual installation), the client
   has no mechanism to detect that interception has occurred.

   This creates fundamental security and privacy problems:

   Privacy Violation (PRIMARY CONCERN):  Users are unaware when their
      supposedly private communications are being read by third parties.
      This violates the reasonable expectation of privacy that TLS
      encryption is intended to provide. Users cannot give informed
      consent when interception is invisible.

   Loss of Expected End-to-End Security:  When TLS interception occurs,
      the security model changes from end-to-end encryption to two
      separate TLS sessions (client-to-proxy and proxy-to-server). While
      this remains valid TLS behavior when the proxy CA is trusted, users
      may have a reasonable expectation of direct end-to-end encryption
      that is not met. This occurs without user awareness or explicit
      consent in many deployments.

   Attack Surface Expansion:  Interception increases the attack surface
      by adding additional points where plaintext is exposed. Inspection
      appliances and their credential stores become high-value targets
      for attackers.




[Vineeth Joseph , Ethan Hamadeh , Chen Zhang]              Expires August 20, 2026                [Page 4]

Internet-Draft                    CEA                      February 2026


   Compliance Risk:  Organizations performing inspection may
      inadvertently violate regulations (e.g., GDPR, HIPAA, PCI-DSS)
      by intercepting sensitive data flows. Current systems lack
      mechanisms to prove non-interception of regulated traffic.

2.2.  Limitations of Existing Solutions

2.2.1.  HTTP Public Key Pinning (HPKP)

   HPKP [RFC7469] allowed websites to instruct browsers to only accept
   specific public keys for a given domain. While conceptually sound,
   HPKP suffered from critical operational issues:

   o  Rigidity: Websites could not easily change certificate providers
      without risking widespread connection failures.

   o  No Recovery Mechanism: Misconfigured pins could render websites
      inaccessible for extended periods.

   o  Cache Persistence: Pins were cached in browsers for extended
      periods with no ability for immediate updates.

   o  Deployment Complexity: Backup pins and careful operational
      procedures were required but often not implemented correctly.

   These limitations led to HPKP's deprecation in 2018.

2.2.2.  Certificate Transparency (CT)

   Certificate Transparency (CT) [RFC6962] provides append-only public logs
   of issued certificates. While valuable for detecting unauthorized
   certificate issuance, CT does not address interception detection:

   o  CT logs record certificate issuance events, not certificate usage

   o  CT does not provide real-time validation during TLS handshakes

   o  CT does not inform users when interception is occurring

2.2.3.  Certification Authority Authorization (CAA) Records

   Certification Authority Authorization (CAA) [RFC6844] enables domain
   owners to restrict which CAs may issue certificates. However:

   o  CAA restricts issuance authorization, not certificate usage

   o  CAA is checked during certificate issuance, not during client
      connections




[Vineeth Joseph , Ethan Hamadeh , Chen Zhang]              Expires August 20, 2026                [Page 5]

Internet-Draft                    CEA                      February 2026


   o  CAA does not detect when a validly issued certificate is being
      used by an intercepting proxy

2.2.4.  Application-Level Pinning

   Some applications implement certificate or public key pinning
   internally. This approach:

   o  Requires per-application implementation

   o  Does not benefit web browsers or other TLS clients

   o  Suffers from the same operational challenges as HPKP

2.3.  Design Requirements

   Based on the limitations of existing mechanisms, CEA addresses the
   following design requirements:

   R1:  MUST provide a mechanism for domain owners to publish expected
        certificate authorities

   R2:  MUST enable clients to validate observed certificates against
        published expectations

   R3:  MUST support multiple authorized certificate authorities to
        enable CA rotation without service disruption

   R4:  MUST provide a mechanism for rapid updates to published
        expectations

   R5:  MUST be cryptographically protected against tampering

   R6:  SHOULD provide user transparency when interception is detected
        rather than blocking connections

   R7:  SHOULD be deployable without requiring changes to certificate
        authorities

   R8:  SHOULD leverage existing infrastructure where possible

   R9:  MAY provide semantic categorization to enable policy automation






[Vineeth Joseph , Ethan Hamadeh , Chen Zhang]              Expires August 20, 2026                [Page 6]

Internet-Draft                    CEA                      February 2026


3.  CEA Mechanism Overview

3.1.  Publishing Certificate Expectations

   Domain owners publish certificate expectations by creating DNS TXT
   resource records under the "_cea" subdomain. For example, to publish
   expectations for "example.com", the domain owner creates a record at
   "_cea.example.com".

   The CEA record contains:

   o  A version identifier

   o  A list of authorized certificate authority names

   o  Optional semantic trust categories

   o  Optional cache duration parameters

   The CEA record SHOULD be DNSSEC-signed to provide cryptographic
   assurance of authenticity and integrity. DNSSEC provides the highest
   security guarantee (confidence Level 4), but CEA deployment does NOT
   require universal DNSSEC adoption. Clients MAY use alternative
   verification methods (DoT/DoH, multi-path consensus, registry) for
   domains without DNSSEC, as specified in Section 4.5.

3.2.  Client Validation Process

   When a client establishes a TLS connection, it performs validation
   in two phases:

   Phase 1 - Standard TLS Validation (REQUIRED):

   1.  Perform complete RFC 5280 certificate validation: chain
       verification, hostname matching, expiration, revocation checks

   2.  If RFC 5280 validation fails, reject connection per standard TLS
       procedures. CEA validation does NOT proceed.

   Phase 2 - CEA Transparency Check (OPTIONAL, only after Phase 1 succeeds):

   3.  Query DNS for CEA record for the target domain

   4.  If available, validate DNSSEC signature chain

   5.  Extract expected CA SPKI hashes from CEA record

   6.  Compute SPKI hash of the issuing CA certificate (the
       certificate that directly signed the end-entity certificate,
       typically an intermediate CA)

   7.  If SPKI matches any expected hash: CEA check passes, no action

   8.  If SPKI does not match: CEA check fails, MAY display
       transparency warning. Connection remains established (fail-open).

   Important: CEA is a post-validation transparency overlay. RFC 5280
   validation is unchanged and takes precedence.






[Vineeth Joseph , Ethan Hamadeh , Chen Zhang]              Expires August 20, 2026                [Page 7]

Internet-Draft                    CEA                      February 2026


3.3.  User Experience and Transparency

   CEA is designed to provide transparency and user empowerment. The
   primary goal is to restore informed consent by making interception
   visible to users.

   When a CEA validation failure occurs (indicating potential
   interception), the recommended behavior prioritizes user agency:

   For Interactive Clients (e.g., Web Browsers):

   o  Display a clear warning that interception may be occurring

   o  Provide information about the expected cryptographic identity
      (SPKI hash) and the observed identity

   o  Explain the implications: "Your organization or network may be
      reading this connection"

   o  Present options with clear privacy implications:

      -  Continue (user accepts interception for this session)

      -  Always trust this network (user consents to monitoring)

      -  Use alternative connection (VPN, cellular, etc.)

      -  Do not connect (preserve privacy)

   o  Log the event for user's own security awareness

   o  Recommended: Warnings SHOULD be user-facing. Implementations MAY
      allow enterprise policy control, but SHOULD ensure users have
      visibility into policy-suppressed warnings through logging or
      notification mechanisms where operationally feasible.

   For Automated Clients (e.g., API Clients, IoT Devices):

   o  Log the validation failure

   o  Optionally alert administrators

   o  Proceed or abort based on local policy configuration

   This approach balances security with operational flexibility,
   particularly in enterprise environments where legitimate SSL
   inspection may be employed.

4.  CEA Record Specification

4.1.  DNS Resource Record Format

   CEA records are published as DNS TXT resource records [RFC1035] under
   the "_cea" subdomain label.

   For domain "example.com", the CEA record is at "_cea.example.com".
   For subdomain "www.example.com", it is at "_cea.www.example.com".

4.2.  CEA Record Syntax

   The CEA record is a semicolon-separated string of tag-value pairs:

     cea-record = "v=CEA1" *(";" tag "=" value)

   Supported tags:
   -  v: Version (REQUIRED, must be "CEA1")
   -  pins: SPKI hashes (REQUIRED)
   -  cat: Categories (OPTIONAL)  
   -  max_age: Cache lifetime in seconds (OPTIONAL, default: 86400)

   Example:
     v=CEA1;pins=sha256/X3pGTSOuJeEVw989IJ/cEtXUEmy52zs1TZQrU06KUKg=;cat=Financial

4.3.  Field Definitions

4.3.1.  Version (v)

   REQUIRED. Must be "CEA1". Clients MUST ignore unknown versions.

4.3.2.  Pins (pins)

   REQUIRED. Comma-separated list of expected CA SPKI hashes.

   Format: hash-algorithm/base64-encoded-hash

   Supported algorithms:
   -  sha256 (REQUIRED)
   -  sha384 (RECOMMENDED)
   -  sha512 (OPTIONAL)

   SPKI Calculation: Extract SubjectPublicKeyInfo from the issuing CA
   certificate, compute SHA-256 hash, Base64 encode [RFC4648].

   Chain Level Clarification: In a typical PKI chain (Root CA ->
   Intermediate CA -> End-Entity), the "issuing CA" is the certificate
   that directly signed the end-entity certificate (typically the
   intermediate). Domain owners MAY pin the intermediate, the root, or
   both. Pinning the intermediate provides stronger binding; pinning the
   root provides operational flexibility during intermediate rotation.

   Example: pins=sha256/X3pGTSOuJeEVw989IJ/cEtXUEmy52zs1TZQrU06KUKg=

4.3.3.  Categories (cat)

   OPTIONAL. Comma-separated semantic trust categories (see Section 6).

   Example: cat=Financial,Healthcare

4.3.4.  Maximum Age (max_age)

   OPTIONAL. Cache lifetime in seconds. Default: 86400 (24 hours).

   Example: max_age=3600

4.4.  DNSSEC Requirements

   CEA records SHOULD be signed with DNSSEC [RFC4033] when available.
   DNSSEC provides cryptographic authenticity and prevents cache
   poisoning.

   Clients MAY require DNSSEC for high-security deployments. When DNSSEC
   validation fails or is unavailable, clients SHOULD use alternative
   verification methods (Section 4.5).

4.5.  Alternative Verification Methods

   When DNSSEC is unavailable, clients can verify CEA records using:

4.5.1.  Trust on First Use (TOFU) - Level 1

   On first connection, client caches the observed CA SPKI. On subsequent
   connections, client compares presented certificate against cached SPKI.
   Warns on mismatch.

   Limitation: Vulnerable to MITM on first connection.

4.5.2.  DNS-over-TLS / DNS-over-HTTPS - Level 3.5

   Query CEA records via encrypted DNS (DoT [RFC7858] or DoH [RFC8484])
   to prevent passive DNS eavesdropping and active modification.

   Recommended DoH resolvers: Cloudflare (1.1.1.1), Google (8.8.8.8),
   Quad9 (9.9.9.9).

4.5.3.  Multi-Path Consensus - Level 3

   Query CEA record from n >= 8 geographically diverse DNS resolvers.
   Accept result if t >= 75% of resolvers agree.

   Provides increased resistance to localized DNS manipulation through
   resolver diversity. Assumes independent, honest resolver selection.
   Does NOT provide formal Byzantine fault tolerance due to: lack of
   resolver coordination, potential upstream correlation, and no
   protection against coordinated attacks. See Section 7.8.3 for
   limitations.

   Example: Query 8 resolvers, require 6 to agree (75% threshold).
   Increases resistance to single-resolver compromise.

4.5.4.  Public Registry Lookup - Level 2

   Query CEA records from a public registry of verified CEA assertions
   (e.g., certificate transparency-style log).

   Registry provides independent verification but introduces centralization.

5.  Client Validation Algorithm

   This section describes the validation algorithm for clients that
   implement CEA. Implementation is OPTIONAL.

5.1.  CEA Record Discovery

   Clients discover CEA records by querying "_cea.<domain>" TXT records.

   Verification methods (in order of preference):
   1.  DNSSEC validation (Level 4) - highest confidence
   2.  DNS-over-HTTPS/TLS (Level 3.5) - encrypted DNS
   3.  Multi-path consensus (Level 3) - resolver diversity
   4.  Registry lookup (Level 2) - independent verification
   5.  TOFU (Level 1) - first-use caching

   If no method succeeds, proceed without CEA validation (fail-open).

   Parse the TXT record per Section 4.2. Cache the result using max_age
   or DNS TTL.

5.2.  Certificate Validation

   After obtaining the CEA record, validate the presented certificate:

   1.  Extract the issuing CA certificate (the certificate that directly
       signed the end-entity certificate, typically an intermediate)
   2.  Compute SHA-256 hash of the issuing CA's SubjectPublicKeyInfo
   3.  Compare against pins in CEA record
   4.  If any pin matches, validation succeeds
   5.  If no match, validation fails

   SPKI is the DER-encoded ASN.1 structure from [RFC5280] Section
   4.1.2.7. Hash includes SEQUENCE tag and length octets.

5.3.  Error Handling

   CEA validation results:

   -  PASS: Certificate SPKI matches a pin in CEA record. Proceed with
      connection.

   -  FAIL: CEA record exists but SPKI does not match. Warn user of
      potential interception.

   -  ERROR: CEA record unavailable (DNS timeout, parse error). Fail-
      open: proceed with connection, optionally inform user.

   -  NONE: Domain does not publish CEA record. Proceed with standard
      TLS validation.

5.3.1.  User Warnings

   On CEA validation failure (FAIL state), clients SHOULD present a
   warning that indicates:

   -  Unexpected certificate detected
   -  Possible TLS interception
   -  Option to proceed or abort connection
   -  Option to report the incident

   Warning UX should differentiate CEA failures from standard TLS errors
   (invalid certificate, expired, hostname mismatch).

5.3.2.  Fail-Open vs Fail-Closed

   CEA implements fail-open behavior: if CEA record is unavailable
   (ERROR state), connection proceeds.

   Rationale: Fail-closed (block connection on CEA unavailability) would
   enable DoS attacks by suppressing CEA records. Domains can enforce
   fail-closed via semantic categories (Section 6.2).

5.3.3.  Network Memory

   Clients SHOULD implement network memory: if a domain previously
   published a CEA record, subsequent absence (transition from PASS/FAIL
   to ERROR/NONE) triggers a warning.

   Memory retention: 90 days recommended.

   This mitigates downgrade attacks where attackers suppress CEA records
   after initial publication.

   Operational Considerations: Network memory introduces stateful
   behavior similar to mechanisms like HPKP that experienced operational
   challenges. However, CEA's fail-open design significantly reduces
   brittleness risk: memory failures trigger warnings rather than
   blocking connections. Implementations SHOULD provide mechanisms to
   clear memory state if operational issues arise (e.g., legitimate
   domain configuration changes, CA migration failures).

5.4.  Multi-Path Consensus Algorithm

   Multi-path consensus queries n >= 8 diverse resolvers and accepts
   results with t >= 75% agreement.

5.4.1.  Resolver Selection

   Recommended diversity:
   -  Geographic: Different jurisdictions
   -  Organizational: Different operators
   -  Infrastructure: Different anycast networks

5.4.2.  Consensus Threshold

   Threshold t = 75% increases resistance to resolver compromise.

   For n=8: requires 6/8 agreement, tolerates up to 2 compromised
   resolvers (assuming independence).
   For n=12: requires 9/12 agreement, tolerates up to 3 compromised
   resolvers (assuming independence).

   The 75% threshold is a deployment trade-off between availability and
   compromise resistance. Lower thresholds (e.g., 50%) provide
   insufficient resistance to partial resolver compromise, while higher
   thresholds (e.g., 90%) significantly reduce availability under benign
   resolver disagreement. The 75% value tolerates limited resolver
   compromise while maintaining practical connectivity. Implementations
   MAY choose stricter thresholds based on local policy.

5.4.3.  Tie Handling

   If no result achieves threshold (e.g., 50/50 split), treat as ERROR
   and fail-open.

6.  Semantic Trust Categories

   The optional "cat=" parameter allows domains to signal semantic trust
   categories for policy automation.

6.1.  Category Taxonomy

   Standard categories include: Financial, Healthcare, Government,
   Military, Education, E-commerce, Social-Media, Communication, Cloud-
   Provider, Enterprise, IoT, Critical-Infrastructure.

   Implementations MAY define additional categories. See IANA
   Considerations (Section 11.3) for registry.

6.2.  Policy Automation

   Categories enable policy signaling for enterprise compliance, but
   require independent verification due to self-attestation.

   Security Warning: Categories are self-attested by domain owners.
   Malicious domains can claim any category to bypass security controls.
   Enterprises MUST NOT trust categories without verification:

   -  Maintain verified allowlists of known Financial/Healthcare domains
   -  Cross-reference with business registrations or industry databases
   -  Monitor for category abuse and require manual approval for
      category-based exemptions
   -  Log all category claims for audit

   Example implementation with verification:

     IF categories CONTAINS "Financial" OR "Healthcare" THEN
       IF domain IN verified_financial_allowlist THEN
         DO NOT intercept (verified compliance requirement)
         LOG exemption for audit
       ELSE
         LOG "Unverified category claim: " + domain
         APPLY normal inspection policy
       END IF
     END IF

   Categories provide a compliance signal but MUST NOT be trusted
   without independent verification. Unverified category exemptions
   create security bypass opportunities.

7.  Security Considerations

   This section provides security analysis including attack classification,
   threat modeling, resolver diversity properties, and explicit
   limitations.

   Note: CEA provides detection signals, not cryptographic proof of
   interception. SPKI mismatches and consensus failures indicate potential
   interception but do not constitute unforgeable proof. CEA enables user
   transparency and informed decision-making.

7.1.  Attack Classification and Threat Model

   CEA addresses a specific threat class: network-level TLS interception
   by MITM attackers using locally-trusted CAs. This includes enterprise
   proxies, government MITM, compromised network equipment, and malicious
   software that installs root certificates.

7.1.1.  Attacks CEA Mitigates

   -  Enterprise MITM with Self-Signed CA: Detection when DNS is not
      suppressed and domain publishes CEA record excluding the
      enterprise CA

   -  Nation-State MITM (Network-Level): Detection when attacker cannot
      control all DNS resolution paths

   -  Rogue Certificate from Authorized CA: Partial detection based on
      pinning granularity

   -  Cache Poisoning DNS Injection: Detection via DNSSEC validation or
      multi-path consensus

7.1.2.  Explicit Limitations (Out-of-Scope)

   CEA does NOT protect against:

   -  State-level DNS control: Attacker controlling authoritative DNS and
      DNSSEC infrastructure can modify CEA records. Mitigation: Multi-path
      consensus with geographically diverse resolvers.

   -  Compromised CA listed in CEA: If attacker compromises a CA that
      domain authorizes in CEA record, CEA validation passes. This is
      working as designed.

   -  Client-side compromise: If attacker controls the client (malware,
      OS modification), CEA validation can be bypassed.

   -  Fail-open bypass: If attacker blocks all CEA verification paths
      (DNSSEC + DoT/DoH + multi-path + registry), client fails open to
      prevent DoS. This is intentional.

7.1.3.  Resolver Diversity and Consensus Limitations

   CEA multi-path consensus uses resolver diversity to increase
   resistance to localized DNS manipulation. This approach has specific
   properties and important limitations:

   Property 1 (Transparency Under Network-Level Attack): If an attacker
   has on-path DNS control and MITM capabilities but cannot compromise
   DNSSEC infrastructure, CEA's multi-path consensus MAY provide
   transparency signals under specific conditions.

   Property 2 (Fail-Open Limitation): If an attacker blocks all
   verification paths, CEA fails open. This is an acknowledged limitation
   required for internet-scale deployment.

   Property 3 (Resolver Diversity): Multi-path consensus (e.g., querying
   8 resolvers with 75% threshold) increases resistance to single-
   resolver compromise. However, this is NOT formal Byzantine fault
   tolerance because: (a) resolvers do not coordinate, (b) resolvers may
   share upstream providers, creating correlation, (c) resolver selection
   assumes honest choices, (d) no protection against coordinated resolver
   compromise.

   Property 4 (Jurisdictional Diversity): Querying resolvers across
   jurisdictional boundaries MAY provide partial protection against
   single-nation DNS manipulation, subject to the limitations in Property
   3.

   These properties assume independent, honest resolver selection.
   Correlated resolver infrastructure or coordinated attacks reduce
   effectiveness.

7.2.  DNSSEC Requirements

   CEA records SHOULD be signed with DNSSEC when available:

   -  DNSSEC provides cryptographic authenticity for CEA records
   -  DNSSEC-signed CEA records prevent cache poisoning attacks
   -  Clients MAY require DNSSEC for high-security deployments

   When DNSSEC is unavailable or validation fails, clients SHOULD fall
   back to multi-path consensus or registry lookup (Section 5.1).

7.3.  DNS Poisoning and Cache Attacks

   CEA is vulnerable to DNS cache poisoning attacks if:
   1) DNSSEC is not deployed, AND
   2) Multi-path consensus is disabled, AND
   3) Registry fallback is not used

   Mitigation: Enable at least two of {DNSSEC, multi-path, registry}.

7.4.  Downgrade Attacks and Fail-Open Behavior

   Attackers may attempt to suppress CEA records via:

   -  Active suppression: Return NXDOMAIN for _cea TXT queries
   -  DNS timeout: Block all DNS queries to force ERROR state
   -  DNSSEC stripping: Remove DNSSEC signatures to bypass validation

   CEA employs network memory to detect suppression: once a domain has
   published a CEA record, clients remember this for 90 days. Subsequent
   absence triggers warnings. This mitigates downgrade attacks against
   domains that previously published CEA.

   Fail-open behavior is INTENTIONAL: blocking all internet connectivity
   (fail-closed) enables DoS attacks and violates deployment constraints.

7.5.  Privacy Considerations

   CEA's privacy properties are compared to existing DNS-based trust
   mechanisms (CAA, TLSA, OCSP).

7.5.1.  Privacy Characteristics

   CEA introduces no new DNS query patterns beyond domain-scoped TXT
   lookups and therefore does not materially alter DNS visibility
   characteristics. DNS observers learn the domain being accessed (same
   as A/AAAA queries), with DoT/DoH encryption available.

   Note: Multi-path consensus (Section 4.5.3) queries 8+ resolvers,
   expanding the set of observers who learn about the connection. This
   creates additional privacy exposure compared to single-resolver DNS.
   Clients using multi-path SHOULD use DoH/DoT to all resolvers when
   possible.

   Standard single-resolver CEA queries do not introduce privacy leaks
   beyond existing DNS infrastructure.

7.5.2.  Privacy Requirements for DoT/DoH

   CEA clients SHOULD use DNS-over-TLS (DoT) or DNS-over-HTTPS (DoH) when
   available to prevent passive DNS eavesdropping. This is a
   recommendation, not a requirement, to maintain deployment flexibility.

   Enterprise networks may block DoT/DoH; CEA gracefully degrades to
   standard DNS in these environments.

7.5.3.  Network Tagging Concern

   CEA queries may reveal that a client is interception-aware. However:

   -  DNS queries are observable regardless (A/AAAA queries reveal domains)
   -  DoT/DoH usage already signals privacy-conscious behavior
   -  CEA adoption reduces tagging risk over time (normalization)

7.6.  Certificate Authority Compromise

   If an attacker compromises a CA that is authorized in a domain's CEA
   record, CEA validation will pass (certificate is "expected"). This is
   not a vulnerability--it is working as designed.

   Mitigation: Domains should minimize the number of authorized CAs in
   their CEA record (principle of least privilege).

7.7.  Interaction with Encrypted ClientHello (ECH)

   ECH encrypts the TLS SNI field to prevent passive observers from
   learning the target domain. CEA and ECH are complementary:

   -  ECH prevents passive eavesdropping of SNI
   -  CEA detects active MITM attacks

   CEA validation occurs AFTER TLS handshake completion, using the
   certificate presented by the server. CEA does not validate ECH public
   keys or configurations--this remains the responsibility of the TLS
   stack.

   ECH downgrade attacks (attacker stripping ECH extension) are outside
   CEA's scope; however, if the downgrade results in certificate
   mismatch, CEA will detect it.

7.8.  Additional Security Considerations

7.8.1.  CEA Does Not Replace TLS Validation

   CEA is an ADDITIONAL check performed after standard TLS validation.
   Clients MUST continue to validate:

   -  Certificate chain to trusted root CA
   -  Certificate validity period
   -  Hostname verification
   -  Revocation status (OCSP/CRLSets)

   CEA augments TLS validation; it does not replace it.

   CEA does not alter certificate validation success or failure as
   defined by RFC 5280. A certificate that passes RFC 5280 validation
   MUST be treated as valid regardless of CEA outcome. CEA results are
   advisory transparency signals and MUST NOT modify the TLS state
   machine.

7.8.2.  Enterprise Warning Fatigue

   Users in enterprise environments with legitimate TLS interception may
   experience warning fatigue if CEA warnings are too aggressive.

   Mitigation: Network memory implementation (Section 7.2.1) learns
   stable enterprise interception patterns and reduces warning frequency
   for known-stable environments.

7.8.3.  Multi-Path Resolver Trust and Limitations

   Multi-path consensus assumes that >= 75% of queried resolvers are
   honest. This assumption has known limitations:

   -  Works well against: Enterprise proxies, local MITM, single-
      resolver compromise
   -  Weak against: Jurisdictional capture (state controls multiple
      resolvers), coordinated resolver collusion
   -  Fails when: Attacker controls >= 25% of selected resolvers AND
      blocks remaining queries

   Recommended resolver diversity (helps but doesn't eliminate risk):
   Geographic diversity (different jurisdictions), organizational
   diversity (different operators), infrastructure diversity (different
   anycast networks).

   Important Limitation: Multi-path consensus is a best-effort resolver
   diversity mechanism, not a cryptographic guarantee or formal Byzantine
   fault tolerance system. Effectiveness depends on resolver independence
   and honest selection. Users should understand these limitations when
   relying on Level 3 validation.

7.8.4.  Downgrade: CEA Record Stripping

   Attackers may return NXDOMAIN for _cea queries to suppress CEA
   validation. Mitigation: Network memory (Section 7.2.1) detects
   suppression for domains that previously published CEA.

   Initial deployment (domain first publishes CEA): No protection against
   suppression. However, this is no worse than current state (no CEA).

7.8.5.  Active DNS Suppression

   State-level attackers may actively suppress CEA TXT queries. Multi-
   path consensus provides partial mitigation by querying diverse
   resolvers across jurisdictional boundaries.

   Limitation: If all resolvers are suppressed, CEA fails open (Section
   8.4).

7.8.6.  Semantic Categories Privacy

   The "cat=" parameter may reveal domain's security posture. This is
   intentional: domains explicitly signal their policy to enable
   automated client responses (Section 6).

8.  Operational Considerations

8.1.  Certificate Authority Rotation

   CEA supports smooth CA rotation by listing multiple CA SPKIs
   simultaneously.

   Recommended procedure:
   1.  Expand CEA record to include both old and new CA SPKIs
   2.  Wait for DNS propagation (TTL + safety margin)
   3.  Obtain and deploy certificate from new CA
   4.  After verification, remove old CA SPKI from CEA record

   Emergency migration: If immediate CA change is required, update CEA
   record first, then deploy new certificate. Some clients may
   experience warnings during propagation delay.

8.2.  Key Rollover

   DNSSEC key rollover follows RFC 6781 procedures. CEA records should
   use sufficiently long TTL (>= 3600 seconds) to avoid excessive re-
   querying during normal operation.

8.3.  Monitoring and Incident Response

   Domain operators should monitor for:
   -  CEA record availability (DNS query success rate)
   -  DNSSEC validation success rate
   -  Client-reported validation failures

   Incident response: If unexpected validation failures occur, verify
   CEA record accuracy, check for certificate chain issues, and
   investigate potential DNS poisoning or unauthorized certificate
   issuance.

8.4.  CDN and Multi-Certificate Scenarios

   Domains using multiple CAs (e.g., CDN with different CAs per region)
   should list all CA SPKIs in the CEA record. Example:

     pins=sha256/CA1_SPKI,sha256/CA2_SPKI,sha256/CA3_SPKI

   Important Limitation (Shared CA Risk): CEA validates the CA SPKI, not
   the end-entity certificate. In shared hosting/CDN scenarios, an
   attacker with a valid certificate from the same CA (even for a
   different domain) will pass CEA validation. Example: If
   bank.example.com lists "CloudFlare CA" and attacker.example.net has a
   CloudFlare certificate, MITM using attacker's certificate passes CEA.
   Mitigation: RFC 5280 hostname validation prevents this attack. CEA
   provides CA transparency; RFC 5280 provides hostname verification.

9.  Deployment Guidance

9.1.  For Domain Owners

   Deploying CEA requires publishing a DNS TXT record and maintaining it
   during CA rotation.

   Steps:
   1.  Identify authorized CAs: List all CAs that issue certificates for
       your domain
   2.  Compute SPKI hashes: Extract CA certificates, compute SHA-256
       hash of SPKI
   3.  Publish CEA record: Add "_cea.<domain>" TXT record with pins
   4.  Enable DNSSEC: Sign CEA records with DNSSEC when possible
   5.  Monitor: Track CEA query success rates and validation failures

   Example:
     _cea.example.com. TXT "v=CEA1;pins=sha256/X3pGTSOu...;cat=Financial"

   Update during CA rotation: Add new CA SPKI before deploying new
   certificate, remove old CA SPKI after migration completes.

9.2.  For Client Implementers

   Client implementation options:
   -  Browser extension
   -  System-level proxy
   -  TLS library integration
   -  Enterprise gateway

   Recommended features:
   -  Multi-path consensus for resolver diversity
   -  Network memory for downgrade detection
   -  Clear user warnings on validation failure
   -  Category-based policy automation

9.3.  For Enterprise Networks

   Enterprises performing TLS inspection should:
   1.  Publish CEA records for internal services listing inspection CA
   2.  Respect category exemptions (Financial, Healthcare)
   3.  Provide transparency to users about interception
   4.  Maintain clear documentation of interception policy

   CEA enables transparent and auditable enterprise inspection while
   protecting privacy-sensitive categories.

10.  IANA Considerations

10.1.  DNS TXT Record Prefix Registration

   IANA is requested to register the "_cea" DNS subdomain label prefix.

   Prefix: _cea
   Purpose: Certificate Expectation Assertions for TLS validation
   Reference: This document

10.2.  CEA Version Registry

   IANA is requested to create a CEA Versions registry.

   Initial registration:
   -  Version: CEA1
   -  Status: Current
   -  Reference: This document

   Registration Procedure: Specification Required [RFC8126]

10.3.  CEA Category Registry

   IANA is requested to create a CEA Categories registry.

   Initial registrations: Financial, Healthcare, Government, Military,
   Education, E-commerce, Social-Media, Communication, Cloud-Provider,
   Cloud-Storage, Entertainment, News-Media, Enterprise, IoT, Critical-
   Infrastructure (as defined in Section 6.1).

   Registration Procedure: Expert Review [RFC8126]

10.3.1.  Expert Review Criteria

   Designated Experts MUST evaluate registration requests against:

   1.  Legitimate regulatory or compliance purpose: Category must
       correspond to recognized legal/regulatory framework (e.g.,
       Healthcare for HIPAA, Financial for PCI-DSS).

   2.  Objective verifiability: Must be possible to verify domain
       belongs to category (business registration, industry
       certification, government designation).

   3.  Non-circumvention purpose: Category must not be designed to
       circumvent legitimate security monitoring.

   Categories designed primarily for convenience without regulatory
   basis SHOULD be rejected.

10.3.2.  Registration Template

   Requesters must provide:
   -  Category name
   -  Regulatory/compliance basis
   -  Verification method
   -  Use case justification
   -  Reference documentation

10.3.3.  Designated Expert Appointment

   The Independent Stream Editor will appoint Designated Experts for the
   CEA Category Registry.

11.  Acknowledgments

   The author thanks the IETF TLS Working Group for their input and
   feedback.

   This work builds upon the lessons learned from HTTP Public Key
   Pinning (HPKP) and Certificate Transparency (CT). The author
   acknowledges the contributions of those who developed and deployed
   these earlier mechanisms.

12.  References

12.1.  Normative References



[Vineeth Joseph , Ethan Hamadeh , Chen Zhang]              Expires August 20, 2026               [Page 21]

Internet-Draft                    CEA                      February 2026


   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, DOI 10.17487/RFC4033, March 2005,
              <https://www.rfc-editor.org/info/rfc4033>.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, DOI 10.17487/RFC4034, March 2005,
              <https://www.rfc-editor.org/info/rfc4034>.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
              <https://www.rfc-editor.org/info/rfc4035>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

12.2.  Informative References

   [RFC6781]  Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
              Operational Practices, Version 2", RFC 6781,
              DOI 10.17487/RFC6781, December 2012,
              <https://www.rfc-editor.org/info/rfc6781>.

   [RFC6844]  Hallam-Baker, P. and R. Stradling, "DNS Certification
              Authority Authorization (CAA) Resource Record", RFC 6844,
              DOI 10.17487/RFC6844, January 2013,
              <https://www.rfc-editor.org/info/rfc6844>.





[Vineeth Joseph , Ethan Hamadeh , Chen Zhang]              Expires August 20, 2026               [Page 22]

Internet-Draft                    CEA                      February 2026


   [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
              Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
              <https://www.rfc-editor.org/info/rfc6962>.

   [RFC7469]  Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
              Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469,
              April 2015, <https://www.rfc-editor.org/info/rfc7469>.

   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
              and P. Hoffman, "Specification for DNS over Transport
              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858,
              May 2016, <https://www.rfc-editor.org/info/rfc7858>.

   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
              <https://www.rfc-editor.org/info/rfc8484>.

Appendix A.  Examples

A.1.  Example 1: Financial Institution

   A bank publishes the following CEA record:

   _cea.bank.example.com. 3600 IN TXT "v=CEA1;pins=sha256/X3pGTSOuJeEVw989IJ/cEtXUEmy52zs1TZQrU06KUKg=,sha256/YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=;cat=Financial"

   When a user connects from home:
   - Browser queries _cea.bank.example.com via DoH (encrypted)
   - Receives CEA record (DNSSEC validated, Level 4)
   - TLS handshake provides certificate from DigiCert
   - Browser extracts SPKI from DigiCert CA certificate
   - Computes SHA-256 hash: X3pGTSOuJeEVw989IJ/cEtXUEmy52zs1TZQrU06KUKg=
   - Matches first pin in CEA record
   - Validation succeeds: [PASS] Direct connection

   When a user connects from corporate network with TLS inspection:
   - Browser queries _cea.bank.example.com (DNSSEC validated)
   - Receives CEA record with bank's expected SPKI pins
   - TLS handshake provides certificate from "CorporateProxyCA"
   - Browser extracts SPKI from Corporate CA certificate
   - Computes SHA-256 hash: ZZh2eUS0a7Lka31SsAo8KLobRH/vFuMNlChGG3Gvjij=
   - Does NOT match any pin in CEA record
   - Validation fails: [WARNING] Warning displayed to user

A.2.  Example 2: Cloud Service with Multiple CAs

   A cloud service provider publishes:

   _cea.cloud.example.com. 3600 IN TXT "v=CEA1;pins=sha256/AAAA...=,sha256/BBBB...=,sha256/CCCC...=;cat=Cloud-Provider"





[Vineeth Joseph , Ethan Hamadeh , Chen Zhang]              Expires August 20, 2026               [Page 23]

Internet-Draft                    CEA                      February 2026


   Week 1: Service uses DigiCert certificate
   - SPKI hash matches first pin (sha256/AAAA...=)
   - Validation succeeds [PASS]

   Week 2: Service switches to CloudFlare certificate
   - SPKI hash matches second pin (sha256/BBBB...=)
   - Validation succeeds [PASS]
   - No service disruption, no user warnings

   Week 3: Service uses Let's Encrypt for new regions
   - SPKI hash matches third pin (sha256/CCCC...=)
   - Validation succeeds [PASS]
   - Smooth multi-CA operation with cryptographic validation

A.3.  Example 3: Enterprise with Policy Automation

   Hospital publishes:

   _cea.hospital.example.org. 3600 IN TXT "v=CEA1;pins=sha256/YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=;cat=Healthcare,HIPAA"

   Corporate firewall implements policy with verification:

   IF cea_record.categories CONTAINS "Healthcare" OR "HIPAA" THEN
     IF hostname IN verified_healthcare_allowlist THEN
       BYPASS ssl_inspection
       LOG "Exempted " + hostname + " (verified HIPAA compliance)"
     ELSE
       LOG "WARNING: Unverified Healthcare claim: " + hostname
       PERFORM ssl_inspection
     END IF
   ELSE
     PERFORM ssl_inspection
   END IF

   Result:
   - Verified hospital traffic is exempted from inspection
   - HIPAA compliance with security controls (verified allowlist)
   - Audit log provides evidence
   - Unverified category claims are logged and inspected normally

Appendix B.  Frequently Asked Questions

B.1.  Why DNS TXT Records Instead of HTTPS Resource Record?

   CEA uses DNS TXT records for immediate deployability (100% DNS server
   compatibility) and scope separation. The HTTPS RR (RFC 9460) describes
   "how to connect" (ALPN, ECH), while CEA describes "what to expect
   when connected" (certificate validation). Future versions may explore
   HTTPS RR integration.

B.2.  Why Not Extend CAA?

   CAA (RFC 8659) specifies which CAs MAY issue certificates (issuance
   authorization). CEA specifies which CAs a domain CURRENTLY uses
   (expectation assertion). These are orthogonal: CAA is a policy for CAs,
   CEA is a signal for clients. Extending CAA would conflate these
   semantics.

B.3.  Why Not Solve Via Certificate Transparency?

   Certificate Transparency (CT) detects mis-issuance AFTER certificates
   are logged. CEA provides real-time detection DURING TLS handshake
   before any data is transmitted. CT and CEA are complementary: CT
   audits the CA ecosystem, CEA detects network-level interception.

B.4.  How Does This Work with Enterprise TLS Inspection?

   CEA respects enterprise environments: enterprises can publish CEA
   records listing their inspection CA, or clients can learn stable
   enterprise patterns via network memory (Section 7.2.1). CEA does not
   break legitimate enterprise inspection--it makes interception
   transparent and auditable.

B.5.  What Is Novel Compared to Prior Work?

   CEA combines ideas from HPKP (pinning), DANE (DNS-based trust), and
   resolver diversity. The novelty is the integration: multi-path DNS
   consensus for increased attack resistance, semantic categories for
   policy automation, and network memory for warning fatigue mitigation.
   See Section 1.5 for detailed comparison to prior mechanisms.






[Vineeth Joseph , Ethan Hamadeh , Chen Zhang]              Expires August 20, 2026               [Page 26]

Authors' Addresses

   Vineeth Joseph
   Palo Alto Networks
   United States

   Email: vinjoseph@paloaltonetworks.com, vintjoseph871@gmail.com


   Ethan Hamadeh
   Palo Alto Networks
   United States

   Email: ehamadeh@paloaltonetworks.com


   Chen Zhang
   Palo Alto Networks
   United States

   Email: tozhang@paloaltonetworks.com, tozh300@gmail.com.
