Re: [MLS] Charter for KEYTRANS

Eric Rescorla <> Wed, 07 June 2023 22:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2FF7CC151520 for <>; Wed, 7 Jun 2023 15:40:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.893
X-Spam-Status: No, score=-6.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EmA8XTPk0-rW for <>; Wed, 7 Jun 2023 15:40:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::112c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 61921C15108D for <>; Wed, 7 Jun 2023 15:40:21 -0700 (PDT)
Received: by with SMTP id 00721157ae682-565de553de1so771567b3.0 for <>; Wed, 07 Jun 2023 15:40:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1686177620; x=1688769620; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9yBEsFmpOmtQNdxdgq+IPPeno18jCcygDNSw8yAAEtk=; b=Qc6zgvm8lTjcO3g0U7ptu1pzni1XvTDMd4kcEKBC2uJs/XQ5GHLohpvUAuBi4gA1Ti +OeJfT8ZiUP6ZrPbZqrMlMMpiGXzI0rWokmKhf+ec5QkLWn8164B4gG6mzC25Kc7IYTQ TmN7awQ69PTU0lqIP6oEjxdGWLyl5bKN07fq1kB4K5ocaGy+F1rmx8/NKvWlwxnzl8cf pE8/nCmaOWBN5x9KekzWw7F1XFK1d1JDVkPwcY3zCGqz9DIKkdFj3MU8R5vnekcVpxFu 7V43Ez7bmwO5Il4NeG5/z1LGhMTB93H5H7eo4VRCwVIE9AFPBcFnb83eCBdl7vDuB3EC mnrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1686177620; x=1688769620; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9yBEsFmpOmtQNdxdgq+IPPeno18jCcygDNSw8yAAEtk=; b=CZ7xPOcCVfm7Xl7RHNsIay24SR3lKJVSlvdDE4ex+ObGdfFWbCWvclKuuIghDCzeUf /Uuj9BYmjp/YVDV3pP7TVK8dcsbBHISczN9/6SvjdM8NhJDLK7rbBugQpkwwTo78FUiF xG2wlal9pkJvjBO9h28UJc+le4U/xYVTFMlACgXwMxatoKIAGreIP8ZDLO/yQpx2zjOT y4gbG8fY/UNQfC1QjQJSF6XWrIEbZ4tPCrkW3w4ScF9B2vYv7a+hZB3slr+4QFB7IJLn 17PdOGUn0rMGbmTzqaqSPvxS/0+JFdtnDpzuDuiDZBoAK3aMfOri7tJHfjQlfABgfvrD RpFA==
X-Gm-Message-State: AC+VfDyjFUX3WgvNYlpy3qT5qD+bjJZzDM4bH9l9voRjaUKKAbegPzgb EX+krM8C0QZMAugjxR2y/OgXmy17mxTncZ48KnOpVz9bzk3XKvLgIZ8=
X-Google-Smtp-Source: ACHHUZ7XzasMuDsaTkNByJ3GX8ceuzn0mWfiOl1Ah8Uzb0gGg98F7O+uduDqrHB4mcYpsnBEgMEqX1S27/snZSEAowY=
X-Received: by 2002:a0d:cc17:0:b0:565:232a:36a3 with SMTP id o23-20020a0dcc17000000b00565232a36a3mr545668ywd.17.1686177620358; Wed, 07 Jun 2023 15:40:20 -0700 (PDT)
MIME-Version: 1.0
References: <960d9858aa334c51a1392644a2059699@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
In-Reply-To: <960d9858aa334c51a1392644a2059699@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
From: Eric Rescorla <>
Date: Wed, 07 Jun 2023 15:39:43 -0700
Message-ID: <>
To: Roman Danyliw <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="000000000000170f8905fd91d26a"
Archived-At: <>
Subject: Re: [MLS] Charter for KEYTRANS
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Messaging Layer Security <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Jun 2023 22:40:25 -0000

Document: charter-ietf-keytrans-00-01.txt

I share a number of Richard's concerns about the level of
generality of this proposed charter.

I'm not sure that "authentication mechanism" is the term that I would
use here. Specifically, it seems likely that people will want to
deploy CT-like models in which there is a separate directory which
actually provides authentication and then a transparency mechanism
that is provided separately. I recognize that some ways of deploying
KT also are usable as authentication, but that's not the only way to
do things. The word I would use here is "public verifiability"
of the consensus data.

I concur with Richard that going from transparency about key
bindings to transparency about bindings and group state
is a huge scope expansion, and I think an unwise one. MLS already
provides a measure of consistency for group state and I think
This group should confine itself to providing transparency
for the identity->key bindings. You can always recharter later
once that's done.

  The KEYTRANS working group will develop a standard for
  authenticating information about artifacts in an end-to-end
  encrypted messaging system with the above properties.

As above, I don't think the right word here is "authenticating
information" but rather "public verifiability".

I would also strike the language here about end-to-end
encrypted messaging systems. While it's true that that's
the motivating case, if the system is cognizant of that
then something has gone wrong.

These comments would also entail some changes later in the charter,
but it's probably more helpful to discuss them in only one place,
so I'll stop here.


On Tue, May 23, 2023 at 12:18 PM Roman Danyliw <> wrote:

> Hi!
> Since the KEYTRANS BoF at IETF 116 (
>, there has
> been follow-up discussion on crafting a charter.  Since KEYTRANS is
> targeting a similar audience as MLS and is proposing an artifact to
> integrate with MLS, I'm sharing it here for visibility and review here.
> Current version of the KEYTRANS charter text
> Multiple threads of discussion
> -- initial charter
> -- AD review of charter
> While posting here, please bring any feedback to the keytrans@ietf
> mailing list.
> Regards,
> Roman
> _______________________________________________
> MLS mailing list