Received: by mx.ietf.org (Postfix) id CED8C46;
	Thu, 22 Oct 2026 21:05:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ietf.org; s=mail;
	t=1792703155;
	h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date:
	 message-id:message-id:to:to:cc:cc:mime-version:mime-version:
	 content-type:content-type:
  content-transfer-encoding:content-transfer-encoding;
	bh=ZSKbXz3qGVnQSnp06bqM/8IWamL0kZlQrBPdPl7WgFI=;
	b=Q33NyKTlaUqfqjZhDAS3lHJJnXPjtyLn5/wpfDV8VcyZl3MjvVj/rPwYmCZppoubScA8yz
	X9/kCr9dSZCf45UxddtmfcR6XuUND3hGyN7UPujlPgwhqM4MVSwHjkUsw1JFRm8nUMwzyj
	qehzwOuZ9ladxxcDefwjQpN2oICSvcY=
Authentication-Results: ORIGINATING;
	auth=pass smtp.auth=mail2@ietf.org smtp.mailfrom=iesg-secretary@ietf.org
Received: from [10.244.9.159] (gaia.k8s.ietf.org [4.156.85.76])
	by mail2.ietf.org (Postfix) with ESMTP id 9870B13AF2369;
	Thu, 22 Oct 2026 14:05:54 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 12.81.0
Auto-Submitted: auto-generated
Precedence: bulk
Sender: <iesg-secretary@ietf.org>
Message-ID: 
 <179270315454.753827.14404035447508379796@dt-datatracker-7457c9c988-pqlqx>
Date: Thu, 22 Oct 2026 14:05:54 -0700
Message-ID-Hash: 5X5NYGLRF4QVLUS57T636QQOI77JJ375
X-Message-ID-Hash: 5X5NYGLRF4QVLUS57T636QQOI77JJ375
X-MailFrom: iesg-secretary@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop;
 banned-address; header-match-stir.ietf.org-0; emergency; member-moderation;
 nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size;
 news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-stir-certificate-transparency@ietf.org, eckelcu@cisco.com,
 housley@vigilsec.com, stir-chairs@ietf.org, stir@ietf.org
X-Mailman-Version: 3.3.10
Reply-To: last-call@ietf.org, stir@ietf.org
Subject: [stir] Last Call: <draft-ietf-stir-certificate-transparency-05.txt> (STI
 Certificate Transparency) to Proposed Standard
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/stir/FpLmL89DxA6SgJjpRCjxGR1Qg00>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Owner: <mailto:stir-owner@ietf.org>
List-Post: <mailto:stir@ietf.org>
List-Subscribe: <mailto:stir-join@ietf.org>
List-Unsubscribe: <mailto:stir-leave@ietf.org>


The IESG has received a request from the Secure Telephone Identity Revisited
WG (stir) to consider the following document:
  'STI Certificate Transparency'
  <draft-ietf-stir-certificate-transparency-05.txt> as Proposed Standard

The IESG plans to make a decision on this document in the coming weeks, and
solicits last-call comments. Please send substantive comments to the
last-call@ietf.org mailing list, with stir@ietf.org copied, no later than
2026-11-05.  Please retain the beginning of the Subject line to facilitate
automated sorting.

Abstract

   This document describes a framework for the use of the Certificate
   Transparency (CT) protocol for publicly logging the existence of
   Secure Telephone Identity (STI) certificates as they are issued or
   observed.  This allows any interested party that is part of the STI
   ecosystem to audit STI certification authority (CA) activity and
   audit both the issuance of suspect certificates and the certificate
   logs themselves.  The intent is to establish a level of trust within
   the STI ecosystem that relies on the verification of telephone
   numbers.  This involves requiring STI certificates to be listed in an
   established log and refusing to honor those that are not.  This
   effectively establishes the precedent that STI CAs must add all
   issued certificates to the logs and thus establishes unique
   association of STI certificates to an authorized provider or assignee
   of a telephone number resource.  In the STI ecosystem, the primary
   role of CT is to provide verifiable trust by detecting the
   unauthorized issuance of duplicate telephone number level delegate
   certificates or provider level certificates.  This provides a robust
   auditable mechanism for the detection of unauthorized creation of
   certificate credentials for illegitimate spoofing of telephone
   numbers or service provider codes (SPC).

   The framework borrows the log structure and API model from RFC6962 to
   enable public auditing and verifiability of certificate issuance.
   While the foundational mechanisms for log operation, Merkle Tree
   construction, and Signed Certificate Timestamps (SCTs) are aligned
   with RFC6962, this document contextualizes their application in the
   STIR ecosystem, focusing on verifiable control over telephone number
   or service provider code resources.



The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-stir-certificate-transparency/


No IPR declarations have been submitted directly on this I-D.





