[Keytrans] Re: draft-ietf-keytrans-architecture-10 ietf last call Artart review

Brendan McMillion <brendanmcmillion@gmail.com> Tue, 13 October 2026 17:50 UTC

MIME-Version: 1.0
References: <179181769875.225882.13458797272935020455@dt-datatracker-66f49ddcbd-pbt9f>
In-Reply-To: <179181769875.225882.13458797272935020455@dt-datatracker-66f49ddcbd-pbt9f>
From: Brendan McMillion <brendanmcmillion@gmail.com>
Date: Tue, 13 Oct 2026 10:50:24 -0700
Message-ID: <CAJTd26LQC8gBqG7osJeTq3O_EcXJJ5XXnvOPTrB-9zZPJjTiwA@mail.gmail.com>
To: Jiankang Yao <yaojk@cnnic.cn>
Content-Type: multipart/alternative; boundary="000000000000a7aa54065dbc7364"
Message-ID-Hash: 5G6BDN4O5DMA4NTJG2OOYL7EWNC5E7CN
CC: art@ietf.org, draft-ietf-keytrans-architecture.all@ietf.org, keytrans@ietf.org, last-call@ietf.org
Precedence: list
Subject: [Keytrans] Re: draft-ietf-keytrans-architecture-10 ietf last call Artart review
Archived-At: <https://mailarchive.ietf.org/arch/msg/keytrans/S0EBhGj601DvoSWeJKQgVjKS18g>

Hi Jiankang, thank you very much for the review!

It defines three fork detection mechanisms. However, it does not specify
> implementation behavior when none of these three methods can be used.
>
> When fork detection capability is unavailable, how does the implementation
> deal with this condition?
>

Without any mechanism for fork detection, an application can't securely
provide KT. I've added a sentence saying this explicitly.

2) This document is explicitly marked as Informational,
>  which is intended to provide architectural guidance rather than normative,
> interoperable protocol rules. However, the draft extensively uses
> uppercase RFC2119 "MUST" requirements throughout the text.
>

Thanks for catching this, RFC2119 terms have been replaced with plain
English.

 3)Title of the figure is too long.


Figure titles have been shortened, and the discussion moved into the
surrounding text.

I've updated the document on GitHub but haven't cut a new version. Let me
know if I should, otherwise I'll wait until last call is over to do so.

Best

On Mon, Oct 12, 2026 at 8:08 AM Jiankang Yao via Datatracker <
noreply@ietf.org> wrote:

> Document: draft-ietf-keytrans-architecture
> Title: Key Transparency Architecture
> Reviewer: Jiankang Yao
> Review result: Almost Ready
>
> I am the assigned ART-ART reviewer for this draft. The Art Area
> Review Team (ART-ART) reviews all IETF documents being processed
> by the IESG.  Please treat these comments just
> like any other last call comments.
>
> Document: draft-ietf-keytrans-architecture-10
> Reviewer: Jiankang Yao
> Review Date: 2026-10-12
>
> Summary: Almost Ready.
>
> This document defines the terminology and interaction patterns
> involved in the deployment of Key Transparency in a general secure
> group messaging infrastructure, and specifies the security properties
> that the protocol provides. It aims for informational document.
>
> Some issues below:
>
> 1) Section 3.3  said that “This provides ample opportunity for users to
> detect when a fork has
>    been presented but isn't in itself sufficient for detection.  To
>    detect forks, users require either a *trusted third party*,
>    *anonymous communication* with the transparency log, or *peer-to-peer
>    communication*.”
>
> It defines three fork detection mechanisms. However, it does not specify
> implementation behavior when none of these three methods can be used.
>
> When fork detection capability is unavailable, how does the implementation
> deal with this condition?
>
>
> 2) This document is explicitly marked as Informational,
>  which is intended to provide architectural guidance rather than
> normative,
> interoperable protocol rules. However, the draft extensively uses
> uppercase RFC2119 "MUST" requirements throughout the text.
>
>
> 3)Title of the figure is too long.
> for example,
>
> "Figure 1: Example request and response flow.  Valid requests
>         receive a response while invalid requests are blocked by the
>                               transport layer.
> "
>
> "
>  Figure 2: Example message flow in an anonymous deployment.  Users
>      request their own label from the transparency log and provide the
>        serialized response, functioning as a credential, in encrypted
>          messages to other users.  Required monitoring is provided
>                                 proactively.
> "
>
>
>
>

[Keytrans] draft-ietf-keytrans-architecture-10 ie… Jiankang Yao via Datatracker
[Keytrans] Re: draft-ietf-keytrans-architecture-1… Brendan McMillion