Re: [MLS] [Keytrans] Charter for KEYTRANS

I am in agreement with ekr's comments here, especially:

> This group should confine itself to providing transparency
for the identity->key bindings. You can always recharter later
once that's done.

I believe this will not only remove some confusion echoed in the above
replies, but also help us to focus on something we can concretely build,
with less risk of overpromising and underdelivering.

And I am also supportive of the change in wording from "authenticating" to
something like "providing public verifiability", since authenticating is
likely to involve other components of an e2ee system that keytrans should
(in my opinion) not try to address.

Otherwise, the charter looks good to me!

Kevin

On Wed, Jun 7, 2023 at 3:42 PM Eric Rescorla <ekr@rtfm.com> wrote:

> Replying with keytrans in the CC list
>
> On Wed, Jun 7, 2023 at 3:39 PM Eric Rescorla <ekr@rtfm.com> wrote:
>
>> 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.
>>
>> -Ekr
>>
>>
>>
>> On Tue, May 23, 2023 at 12:18 PM Roman Danyliw <rdd@cert.org> wrote:
>>
>>> Hi!
>>>
>>> Since the KEYTRANS BoF at IETF 116 (
>>> https://datatracker.ietf.org/meeting/116/session/keytrans), 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
>>>
>>> https://docs.google.com/document/d/12NMFA0P1OYtE6_QoqP3J80tDr0z2-FEm2ZdiWeauAHE/edit
>>>
>>> Multiple threads of discussion
>>> -- initial charter
>>>
>>> https://mailarchive.ietf.org/arch/msg/keytrans/6VIEM87-TNe1OYXZRUyAwJX_1vo/
>>>
>>> -- AD review of charter
>>>
>>> https://mailarchive.ietf.org/arch/msg/keytrans/GfDMvADn5ZgdR7ZfTZt2y296Nuo/
>>>
>>> While posting here, please bring any feedback to the keytrans@ietf
>>> mailing list.
>>>
>>> Regards,
>>> Roman
>>>
>>> _______________________________________________
>>> MLS mailing list
>>> MLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mls
>>>
>> --
> Keytrans mailing list
> Keytrans@ietf.org
> https://www.ietf.org/mailman/listinfo/keytrans
>