Return-Path: X-Original-To: keytrans@mail2.ietf.org Delivered-To: keytrans@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 68952121F4E60 for ; Fri, 31 Jul 2026 21:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1785557280; bh=K0dRU10PwIiHm6pRHmEePcBv5fO4Gl8yz05uXW1E2Sc=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=Tuhija0hHtEBjYwYa1CpaRr/32b1eqR8Vv93QA+uP82tdeMvybBnsCPPouvPPR0BF cYFuVXYfKcJRiy/Mhng0ld+RIxBwkKvbESc9C1E0dXaNtYOcVKlPbbXQY/jw9nVLlz +wd8X5/dYlPIlXTGqv2lDVTbxP/SREGKKP0/S5DM= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNkq1JL55NFP for ; Fri, 31 Jul 2026 21:07:59 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 41CA7121F4E56 for ; Fri, 31 Jul 2026 21:07:59 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-472326ca506so1270788f8f.2 for ; Fri, 31 Jul 2026 21:07:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1785557278; cv=none; d=google.com; s=arc-20260327; b=hTlfLXoZQsxFG/ekqoCi2shSM4ltsC9nFwqQmWp2XDwaHLb4HMLLuSL0pbjHFoLCxj lz5e2jPp/wwtjgjqIGJz+67y5GsJ3Kg+RWo/VS3k1Z5+s8nTivB4tV1MLLDPuv7Ti7fi Og6Z71OYBql1Opu1sVxytB0jXUy4YYDMufRjH3QUnKiWN8R0/pFehsIxLKYzJR+WqE+L 2ADA2s1bpj5p5GAowjAiBVoJqFjKTssP2rmhfpBFQJlTCmAV5tL6Q1UMhAA6iCRNmLiy uwEY8aDPvjm/ig4UoH4YrCASvJxV68W0K06xxYdkiikaNGvMpzdvAHMrjghxIlUEZcWG fUCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=oCforbc4jLiYoZyr4Fos6fJHIBVn8+zG4yCBUOJj/4w=; fh=2JBGcSVTvcbL/+TnnwMWYN3F3xq6l8JY6RvYo3IzGD4=; b=RAXGf3GR/8awQszusG29QXBQgcHF5Tl9gL4t3QazDL+/LO9ewTaPoMhjEA5WyFi3rH NJ4kEP/Fn7MFtJkIW0oON+xOjAT8p5X9HFQ/sRGxQKo4z8TCkroe5lpYG8LiCWf/F3OS sjnte83WK+SHzXWualOt4QbL8BQq3ETNiHUc6KOAop6HzeSMvkcivEH0yRZT4O40hytM KMzEwZdSJb+x5I6kOtkvKxHJNjwMVB4chrg0SUdVOsrOmhbsXARQrzOyzf6F6aN1LHhj JB24gZ5kVDTQvmt+hJKvyCrwJEwJysrt2v1ggDK1p0zLoCNK+Td+e7mc5rGVJDD3lTLT WfIA==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785557278; x=1786162078; darn=ietf.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=oCforbc4jLiYoZyr4Fos6fJHIBVn8+zG4yCBUOJj/4w=; b=ra73BXZMclp+AJOCuTYREiFkU09eUID4BmBmmy/8ycqB/J5CoEW/eU3JdHyg2usQVB 4t+z8oqmQfIl1x4Nk11tDWvnAO/AEfGVWot6rBUd3jl9ZMyHn57wW904DH4htfQBWzzC OXrsWePcX4O9SIM315hdmPfpsk657HU3k6RduL7OQQN/2IxK7Y2shmTPWjP7MXedfLgE vhxq3o7tVEwLzMVF4CRRUXGet/sMfxnY2l5IA749nbGjHPLv5iOfmH5NSLz8mbP/1em/ FKk+XQJQIPg2+EcFrAcZ9CnYJytYlPH/xIU4w1G8FLkJYTZwq1dVcQSA9bHL+v8jmFlu mwJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785557278; x=1786162078; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=oCforbc4jLiYoZyr4Fos6fJHIBVn8+zG4yCBUOJj/4w=; b=RI+uYjOzYWTxDJwc79Reoqh1sbxBirvBjb7PAoCch+v1Ul5IF3XkhtYy507eI/luaO SGpePBRByvKiXF6jZJssQkPVuHZqVUBkOZV6gkLUTgcReNRESfI3hmJTKnv8lIWOH+4r UCQj3naXKMXU0CqRCAfUyDWKnsNeBOh+efgRdrvokXbF8x7+z+3Io3OagW8EaYz2wD5Y 5BHj9YtVoQA5+HjmobzOQP3mSU2+Iu45fQYenxlZWws3qeadJ5qE1ymNcevpq1slbYPC oK1SwBpbHgz/6ghDnaSqeHGh/2CSSxplXkkMR7KHFC0MV7EAeHSc8hlEj5cPVFscQGdv pwzA== X-Gm-Message-State: AOJu0Yz4nzA8RfkU2nULa5rLgDyuWdvfsHduvdhqyc/qtMfmY6SM0MSC Tr7x3H35wWSXjtpkoNo31Y96ssC6Hs9dAO2N4q7VA3P6RFJo+qtNzzKhrB7y2Rf1Tly+IOi9Mg5 CNmod5rP1gGE7aNv276Lt3SlU6etTJLPiXveNUI0= X-Gm-Gg: AR+sD11WIn0+LD47jRRB5ZMxnPYF2dKWBFD/wNiLmeyDquNgk3LbyGhr/v/ktuV5cKu Uzb9e3mkhIC0whWR4ueCJlnTkkKzcK8cDEnLVPGy+lF+T4UQC13jpZB3PhAfMB8x4HVdl35qSRh 4qwdRnxnUrX6LjgdKQ2kicIaFzvEHftpWgkCAYbLGdd92ppc2bja2tPSW5X5uspDboE62gV6941 aGlLKu2tKdCG4GsLsBNfm5635qoA/vGDpU2BmA6TG2aWGbJOeX2rQljFnfDxG264pi8ZN4lKMHA sMQx60nm1pMagc3gKcK9fesW9s7yRPZahc6wiecmR2rWpDPOgzRShRoEADeD2bbmjJ7aCvKga4A r1jQj+O9OlLCeFUDX77DBVEUjju5243x75w== X-Received: by 2002:a05:6000:460b:b0:47f:96e6:70a with SMTP id ffacd0b85a97d-47fd72625a6mr3670927f8f.0.1785557278047; Fri, 31 Jul 2026 21:07:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brendan McMillion Date: Fri, 31 Jul 2026 21:07:45 -0700 X-Gm-Features: AUfX_mz-MK-SYcInLpS8QTI8aSKWO1ly8S2D_JKU-S7c3k5kgTBRAGirgTC4Jyc Message-ID: To: Felix Linker Content-Type: multipart/alternative; boundary="00000000000048c07a0657f473c9" Message-ID-Hash: O53GJIIJBLL3M25OCPZMGNY7DPI5XU7G X-Message-ID-Hash: O53GJIIJBLL3M25OCPZMGNY7DPI5XU7G X-MailFrom: brendanmcmillion@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: keytrans@ietf.org X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BKeytrans=5D_Re=3A_Keytrans=40IETF_126_=3A_Call_for_agenda_topic?= =?utf-8?q?s?= List-Id: Key Transparency Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000048c07a0657f473c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi again I opened this PR, which recommends that implementations output, or be able to output, their messages in TLS format: https://github.com/ietf-wg-keytrans/draft-protocol/pull/52 -- The "or be able to output" clause here is somewhat load-bearing. While I don't think that TLS is going to be the right wire format for most applications, I think it's a small ask that implementations include serializers for TLS format if it allows more thorough interop testing. Also, I rewatched the meeting recording and I think I misunderstood your comments on the CombinedTreeProof. You said at the time that the wire format of the CombinedTreeProof is fine, but that the text in the draft is lacking. There's a series of subsections of section 13.2 that explain what exactly goes into the CombinedTreeProof for each algorithm. Does this text address your concern / is it in the right direction but needs further development? On Fri, Jul 31, 2026 at 2:31=E2=80=AFPM Brendan McMillion < brendanmcmillion@gmail.com> wrote: > Hi Felix > > We should make one wire format mandatory. Currently, the draft allows >> implementers to freely choose the wire format. I would make TLS mandator= y. >> If people want to use a different wire format, they of course still can, >> but fixing TLS allows us to at least hope that different implementations >> interoperate. > > > To give my own thoughts and to recap the discussion on the list a bit, th= e > pros of not having a fixed wire format are: > > - Given the nature of this protocol, we can expect that most applications > are going to want to customize their use / implementation of it to some > degree. As an easy example, an application might be very prescriptive abo= ut > what labels can be searched for / updated / monitored, to the point where > allowing these fields to even be set in a request would be pointless. A > flexible wire format makes these customizations easier to accomplish. > - Inspecting the contents of requests is necessary for access control. > Allowing flexibility, at least in the encoding of requests, also makes th= is > easier to accomplish. > - TLS cedes a lot of ground as far as extensibility, compressibility, and > human intelligibility. > > The only con that I've seen discussed of not having a fixed wire format i= s > that it makes interop testing harder. But the counterpoint here is that, > since the wire format isn't fixed, we shouldn't be interop testing it. We > should be interop testing un-encoded structures. So I wouldn't give you a > byte string corresponding to an encoded SearchRequest, I'd give you > SearchRequest{last: 1234, label: "brendan", ...} and see how your > implementation processes it. > > I suggest simplifying the PrefixProof structure as follows: Represent >> prefix trees as a list of leafs with their depth. Either store the node'= s >> hash value (can be omitted for an empty leaf) or store the VRF output an= d >> the commitment. The reconstruction algorithm can then simply do a DFS >> search over the prefix tree and initialize it along the way. With the >> current wire format, one must merge prefix trees first with the binary >> ladder, then initiate leafs from the prefix search results, then fill in >> node values. > > > I don't understand how this is a simplification. You say that currently, > you have to write code to compute each leaf's hash from the VRF output an= d > commitment before you can evaluate the proof. And your claim is that you > can simplify your implementation if each leaf's hash is directly in the > proof. The issue with putting the leaf hashes directly into the proof, > though, is that now you have to verify they're correct. So your proposal > swaps code that does "compute each leaf's hash from the VRF output and > commitment and insert it into the PrefixProof calculations" for "compute > each leaf's hash from the VRF output and commitment and check that it > matches what's in the PrefixProof." This doesn't seem any simpler to > implement and requires more bytes on the wire. Am I missing something her= e? > > Such language makes the draft hard to implement because one now needs to >> consider the entire document to understand how to parse the data structu= re. >> I think this one will be quite hard to address. I cannot come up with th= e >> right language right now, because I'm not sure what actually holds about= , >> e.g., the combined tree proof in all cases. But maybe that's a sign that >> such text is needed. > > > It's extremely simple to parse this data structure though, it's 4 arrays > of simple data types. That's all that should be done at the parsing phase= . Evaluating > the proofs is also meant to be fairly easy: you implement the algorithms = as > they're specified, and when one of the algorithms needs a timestamp or a > prefix proof, you pop the next one off of the `timestamps` or > `prefix_proofs` field, respectively. So you essentially have two queues. > This implementation strategy is discussed somewhat briefly in Appendix C. > > But note what this means: explicitly associating each timestamp or prefix > proof with its log entry doesn't actually simplify implementation. Each > algorithm already wants a specific set of timestamps in a specific order > (which timestamps? evaluate the algorithm!). But now you need to parse th= is > more complex wire format and do extra verification, such as: ensuring tha= t > the same position isn't listed multiple times, enforcing an order on the > encoded map entries, and so on. Let me know if I'm missing something abou= t > this proposal, or if maybe adding more text to Appendix C would be helpfu= l > > On Tue, Jul 28, 2026 at 4:31=E2=80=AFAM Felix Linker > wrote: > >> Hi everyone, >> >> As there was little time for discussion at the end of the meeting, I >> wanted to raise my three suggestions for the protocol document on list a= nd >> here what other people say. Here they are: >> >> - We should make one wire format mandatory. Currently, the draft >> allows implementers to freely choose the wire format. I would make TL= S >> mandatory. If people want to use a different wire format, they of cou= rse >> still can, but fixing TLS allows us to at least hope that different >> implementations interoperate. >> - I suggest simplifying the PrefixProof structure as follows: >> Represent prefix trees as a list of leafs with their depth. Either st= ore >> the node's hash value (can be omitted for an empty leaf) or store the= VRF >> output and the commitment. The reconstruction algorithm can then simp= ly do >> a DFS search over the prefix tree and initialize it along the way. Wi= th the >> current wire format, one must merge prefix trees first with the binar= y >> ladder, then initiate leafs from the prefix search results, then fill= in >> node values. >> - I implemented this new wire format for testing purposes, and my >> code for constructing prefix trees indeed becomes much simpler: >> https://github.com/felixlinker/keytrans-verification/blob/ca4157ae= 8aaaae0b0e5b4b4e0e9d6d08524786a1/pkg/trees/prefix/prefix.go#L471 >> - Previously, this was the code to first merge binary ladder >> results into the prefix tree: >> https://github.com/felixlinker/keytrans-verification/blob/3c4bb83d= 7dbcf47a4091d54653a5b6a2dcc84a8f/pkg/proofs/proofs.go#L102 >> and this is the code to construct the prefix tree: >> https://github.com/felixlinker/keytrans-verification/blob/3c4bb83d= 7dbcf47a4091d54653a5b6a2dcc84a8f/pkg/trees/prefix/prefix.go#L536 >> - I suggest describing the wire format more explicitly. For example, >> Section 12.3, specifying the combined tree proof, only says: "The >> timestamps field contains the timestamps of specific log entries [...= ]. >> There is no explicit indication as to which log entry the elements >> correspond to, as they are provided in the order that the algorithm t= he >> user is executing would request them." Such language makes the draft = hard >> to implement because one now needs to consider the entire document to >> understand how to parse the data structure. I think this one will be = quite >> hard to address. I cannot come up with the right language right now, >> because I'm not sure what actually holds about, e.g., the combined tr= ee >> proof in all cases. But maybe that's a sign that such text is needed. >> >> >> Curious to hear what the rest thinks! >> >> Best, >> Felix >> >> Am Do., 16. Juli 2026 um 10:14 Uhr schrieb Felix Linker < >> linkerfelix@gmail.com>: >> >>> Hi Prachi and fellow keytrans enthusiasts, >>> >>> We made progress implementing a client. The client is still very much >>> WIP, but I believe (with an asterisk) that it should be able to verify >>> greatest version queries. >>> >>> The code for that can be found here: >>> https://github.com/felixlinker/keytrans-verification/blob/felixlinker/c= lient-state/pkg/client/client.go#L98 >>> Development currently happens on that branch. >>> >>> I could not test whether the client works yet because I'm not aware of = a >>> server implementation that generates search responses for search reques= ts. >>> Maybe my understanding here is wrong, I asked both Guy and Brendan for >>> this. Would be great to have test vectors. My implementation of a prefi= x >>> and log tree is tested, but only "against itself," i.e., I check that m= y >>> implementation satisfies certain invariants. >>> >>> We also prove that our go implementation is memory safe. We haven't gon= e >>> much further than that in our mechanized proofs because I would first l= ike >>> to test whether the client implementation actually works. It is much >>> cheaper to test than to prove, so I want to do that first. >>> >>> The asterisk that I mentioned above is that I took the liberty to chang= e >>> the server response format slightly so that proofs are easier to parse.= I >>> could, at the meeting, present my experience implementing the client. M= y >>> life would be much simpler if the change in wire format were part of th= e >>> draft, and I find there are certain parts of the draft which are hard t= o >>> implement and get right. >>> >>> Best, >>> Felix >>> >>> >>> Am Di., 14. Juli 2026 um 16:50 Uhr schrieb Prachi Jain < >>> prachi.jain1288@gmail.com>: >>> >>>> Hello KEYTRANS enthusiasts, >>>> >>>> Please share any topics, discussion items, or anything else you'd like >>>> to cover during our time at IETF 126. We have an hour allocated to us. >>>> >>>> >>>> -Chairs >>>> -- >>>> Keytrans mailing list -- keytrans@ietf.org >>>> To unsubscribe send an email to keytrans-leave@ietf.org >>>> >>> -- >> Keytrans mailing list -- keytrans@ietf.org >> To unsubscribe send an email to keytrans-leave@ietf.org >> > --00000000000048c07a0657f473c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi again

I opened this PR, which recomm= ends that implementations output, or be able to output, their messages in T= LS format:=C2=A0https://github.com/ietf-wg-keytrans/draft-protocol/pull/52 = -- The "or be able to output" clause here is somewhat load-bearin= g. While I don't think that TLS is going to be the right wire format fo= r most applications, I think it's a small ask that implementations incl= ude serializers for TLS format if it allows more thorough interop testing.<= /div>

Also, I rewatched the meeting recording and I thin= k I misunderstood your comments on the CombinedTreeProof. You said at the t= ime that the wire format of the CombinedTreeProof is fine, but that the tex= t in the draft is lacking. There's a series of subsections of section 1= 3.2 that explain what exactly goes into the CombinedTreeProof for each algo= rithm. Does this text address your concern / is it in the right direction b= ut needs further development?

On Fri, Jul 31, 20= 26 at 2:31=E2=80=AFPM Brendan McMillion <brendanmcmillion@gmail.com> wrote:
Hi Felix

We should make one wire format mandatory. Currently, the draft allows im= plementers=C2=A0to freely choose the wire format. I would make TLS mandator= y. If people want to use a different wire format, they of course still can,= but fixing=C2=A0TLS allows us to at least hope that different implementati= ons interoperate.

To give my own tho= ughts and to recap the discussion on the list a bit, the pros of not having= a fixed wire format are:

- Given the nature of th= is protocol, we can expect that most applications are going to want to cust= omize their use / implementation of it to some degree. As an easy example, = an application might be very prescriptive about what labels can be searched= for / updated / monitored, to the point where allowing these fields to eve= n be set in a request would be pointless. A flexible wire format makes thes= e customizations easier to accomplish.
- Inspecting the contents = of requests is necessary for access control. Allowing flexibility, at least= in the encoding of requests, also makes this easier to accomplish.
- TLS cedes a lot of ground as far as extensibility, compressibility, an= d human intelligibility.

The only con that I'v= e seen discussed of not having a fixed wire format is that it makes interop= testing harder. But the counterpoint here is that, since the wire format i= sn't fixed, we shouldn't be interop testing it.=C2=A0We should be i= nterop testing=C2=A0un-encoded structures. So I wouldn't give you a byt= e string corresponding to an encoded SearchRequest, I'd give you Search= Request{last: 1234, label: "brendan", ...} and see how your imple= mentation processes it.

I suggest simplifying the PrefixPr= oof structure as follows: Represent prefix trees as a list of leafs with th= eir depth. Either store the node's hash value (can be omitted=C2=A0for = an empty leaf) or store the VRF output and the commitment. The reconstructi= on algorithm can then simply do a DFS search over the prefix tree and initi= alize it along the way. With the current wire format, one must merge prefix= trees first with the binary ladder, then initiate leafs from the prefix se= arch results, then fill in node values.

<= div>I don't understand how this is a simplification. You say that curre= ntly, you have to write code to compute each leaf's hash from the VRF o= utput and commitment before you can evaluate the proof. And your claim is t= hat you can simplify your implementation if each leaf's hash is directl= y in the proof.=C2=A0The issue= with putting the leaf hashes directly into the proof, though, is that now = you have to verify they're correct. So your proposal swaps code that does "compute each leaf's hash from the= VRF output and commitment and insert it into the PrefixProof calculations&= quot; for "compute each leaf's hash from the VRF output and commit= ment and check that it = matches what's in the PrefixProof." This doesn't seem any simp= ler to implement and requires more bytes on the wire. Am I missing somethin= g here?

<= /span>
Such language makes the draft hard to imp= lement because one now needs to consider the entire document to understand = how to parse the data structure. I think this one will be quite hard to add= ress. I cannot come up with the right language right now, because I'm n= ot sure what actually holds about, e.g., the combined tree proof in all cas= es. But maybe that's a sign that such text is needed.

It's extremely simple to parse this data structur= e though, it's 4 arrays of simple data types. That's all that shoul= d be done at the parsing phase.=C2=A0Evaluating the proofs is also meant to be fairly easy: you implement= the algorithms as they're specified, and when one of the algorithms ne= eds a timestamp or a prefix proof, you pop the next one off of the `timesta= mps` or `prefix_proofs` field, respectively. So you essentially have two qu= eues. This implementation strategy is discussed somewhat briefly in Appendi= x C.

But note what th= is means: explicitly associating each timestamp or prefix proof with its lo= g entry doesn't actually simplify implementation. Each algorithm alread= y wants a specific set of timestamps in a specific order (which timestamps?= evaluate the algorithm!). But now you need to parse this more complex wire= format and do extra verification, such as: ensuring that the same position= isn't listed multiple times, enforcing an order on the encoded map ent= ries, and so on.=C2=A0Let me know if I'm missing something about this p= roposal, or if maybe adding more text to Appendix C would be helpful=

On Tue, Jul 28, 2026 at 4:31=E2=80=AFAM Felix Linker <linkerfelix@gmail.com>= ; wrote:
Hi everyone,

As there was little time for discussion at the end of the meeting, I wante= d=C2=A0to raise my three suggestions for the protocol document on list and = here what other people say. Here they are:
  • We should make= one wire format mandatory. Currently, the draft allows implementers=C2=A0t= o freely choose the wire format. I would make TLS mandatory. If people want= to use a different wire format, they of course still can, but fixing=C2=A0= TLS allows us to at least hope that different implementations interoperate.=
  • I suggest simplifying the PrefixProof structure as follows: Repres= ent prefix trees as a list of leafs with their depth. Either store the node= 's hash value (can be omitted=C2=A0for an empty leaf) or store the VRF = output and the commitment. The reconstruction algorithm can then simply do = a DFS search over the prefix tree and initialize it along the way. With the= current wire format, one must merge prefix trees first with the binary lad= der, then initiate leafs from the prefix search results, then fill in node = values.
  • I suggest = describing the wire format more explicitly. For example, Section 12.3, spec= ifying the combined tree proof, only says: "The timestamps field conta= ins the timestamps of specific log entries [...]. There is no explicit indi= cation as to which log entry the elements correspond to, as they are provid= ed in the order that the algorithm the user is executing would request them= ." Such language makes the draft hard to implement because one now nee= ds to consider the entire document to understand how to parse the data stru= cture. I think this one will be quite hard to address. I cannot come up wit= h the right language right now, because I'm not sure what actually hold= s about, e.g., the combined tree proof in all cases. But maybe that's a= sign that such text is needed.

Curious = to hear what the rest thinks!

Best,
Feli= x

Am Do., 16. Juli 2026 um 10:14=C2=A0Uhr schrieb Felix Li= nker <linkerf= elix@gmail.com>:
Hi Prachi and fellow keytrans enthusiasts,
We made progress implementing a client. The client is still ver= y much WIP, but I believe (with an asterisk) that it should be able to veri= fy greatest version queries.

The code for that can= be found here:=C2=A0https://github.com/felixlinker/keytrans-verification/blob/felixlin= ker/client-state/pkg/client/client.go#L98 Development currently happens= on that branch.

I could not test whether the clie= nt works yet because I'm not aware of a server implementation that gene= rates search responses for search requests. Maybe my understanding here is = wrong, I asked both Guy and Brendan for this. Would be great to have test v= ectors. My implementation of a prefix and log tree is tested, but only &quo= t;against itself," i.e., I check that my implementation satisfies cert= ain invariants.

We also prove that our go implemen= tation is memory safe. We haven't gone much further than that in our me= chanized proofs because I would first like to test whether the client imple= mentation actually works. It is much cheaper to test than to prove, so I wa= nt to do that first.

The asterisk that I mentioned= above is that I took the liberty to change the server response format slig= htly so that proofs are easier to parse. I could, at the meeting, present m= y experience implementing the client. My life would be much simpler if the = change in wire format were part of the draft, and I find there are certain = parts of the draft which are hard to implement and get right.
Best,
Felix


Am Di., 14. Juli 202= 6 um 16:50=C2=A0Uhr schrieb Prachi Jain <prachi.jain1288@gmail.com>:
Hello K= EYTRANS enthusiasts,=C2=A0

Please share any= topics, discussion items, or anything else you'd like to cover during = our time at IETF 126. We have an hour allocated to us.=C2=A0


-Chairs

--
Keytrans mailing list -- keytrans@ietf.org
To unsubscribe send an email to keytrans-leave@ietf.org
--
Keytrans mailing list -- keytrans@ietf.org
To unsubscribe send an email to keytrans-leave@ietf.org
--00000000000048c07a0657f473c9--