Re: [Keytrans] [MLS] Charter for KEYTRANS

[Orie Steele <[e-mail]>]

I had a great conversation with Kevin, and I also read this draft:

https://bren2010.github.io/draft-key-transparency/draft-mcmillion-key-transparency.html

Most of the questions I asked are answered in the draft, but I will
summarize some of the most important ones.

Why not use COSE?

Because the use cases do not benefit significantly from interop at the
encoding / format layer.

If you are interested in details consider the client-server model, where
the client and the server are in the same trust domain... Messages need to
only be understood by clients, they don't need to be exchanged with other
servers.

The portability of the proof types seems less important to KT than it is to
SCITT. This means less value in agreeing to a single format.

Assuming KT builds on prefix trees, there would be an easy way to support
the same proof structures SCITT wants to use with COSE... I'm pretty
confident that similar approach could be defined if KT chose to define
proofs using accumulators or verkel trees instead.

Based on what I read, and assuming the charter needed further narrowing,
I'd offer these suggestions, but it's possible they are not needed:

1. Explain more how the identity is bound to the service provider, and
specifically why portability / interoperability does not matter at this
layer for messaging app / comsec use case.

2. Specifically call out the intention to define proof formats for useful
properties related to detecting duplicity, key freshness, etc... Basically
the features you get from prefix trees, or the merkle ^2 paper, without
mentioning either.

3. Do you really need a new working group?

Imo yes, but that doesn't mean all your work needs to be self contained, it
would be awesome to collaborate on proof types and tree algorithms for COSE
if there is interest, but I don't think format wars should delay specifying
prefix tree or other cryptographic bits, and I think it is ok to do that
work as it was done for CT, even though I prefer to consume those
algorithms in COSE.

The current charter covers these topics already, I leave it to more
seasoned charter smiths to point out its weak points.

I'm happy to help address any I can.

Very excited for this work to happen at IETF.

Regards,

OS

On Fri, Jun 16, 2023, 6:06 PM Orie Steele <[e-mail]> wrote:

> Thanks for your comments Kevin!
>
> Inline:
>
> On Fri, Jun 16, 2023 at 4:20 PM Kevin Lewi <[e-mail]> wrote:
>
>> Hi all,
>>
>> Responses below. I tried to make a distinction between questions that are
>> directly relevant to the charter text, versus questions that are clarifying
>> what we could eventually consider.
>>
>> > Will the verifiability mechanism be encoded in a specific
>> serialization, for example COSE merkle proofs, or other CBOR structures
>> that make use of existing IETF work?
>>
>> We haven't established an agreement yet on how exactly the append-only
>> log will be constructed. We are not even committing (yet) to using any
>> specific Merkle-tree-based construction in the charter. There are lots of
>> ways to construct append-only logs with various properties: Merkle trees
>> with chronologically-ordered leaves, Merkle prefix (Patricia) trees,
>> indexed Merkle trees (https://eprint.iacr.org/2018/721.pdf), Verkle
>> trees (Merkle tree structure but using vector commitments), and even more
>> generally, cryptographic accumulators implemented using algebraic
>> techniques (e.g. https://eprint.iacr.org/2018/721.pdf). I think this
>> question would be a good one to ask further down the line, at least once we
>> have settled on a construction that is Merkle-tree-based (if we do).
>>
>
> Indeed, it is exactly these different schemes that I am interested in
> seeing standardized in such a way that existing IETF work might make use of
> them.
>
> For example, should MLS / JOSE / COSE both approach encoding consistency
> and inclusion proofs differently?
>
> I can easily see a world where we end up with the same algorithms
> registered and encoded several different times over, maybe there is no way
> around this, but why is CBOR not a "good enough choice"?
>
> We are working on this with SCITT and COSE today, at the time that RFC9162
> was published, maybe COSE was not the prefered way to handle things, but
> now we want to support "inclusion proofs" and "consistency proofs" in a
> standard way that COSE and JOSE can understand.
>
> I can imagine COSE and JOSE might end up redoing / profiling a lot of
> KeyTrans work to integrate the algorithms specified for use with JOSE and
> COSE, and if it's possible to avoid doing double work, I am happy to help.
>
>
>>
>> > Any plans to use anything from OAuth / OIDC?
>>
>> If this is a question about whether or not the charter should commit to
>> integrating with OAuth / OIDC: I think we shouldn't include it as a core
>> deliverable, and would prefer to stick to treating the identities as opaque
>> blobs as well. Maybe in the future, we could consider extending the scope
>> and integrating with OAuth / OIDC, but it's too early to commit to that
>> right now.
>>
>>
> I guess this probably means identity assurance, authentication assurance
> levels are out of scope as well?
>
> And perhaps that the protocol won't extend to users who own a device that
> want a transparent claim from a particular identity (service) provider?
>
>
>> > Why would that exclude symmetric keys?
>>
>> Hmm, let me maybe try to clarify what I originally meant by not
>> considering symmetric keys. I didn't mean to imply that we should take the
>> stance of saying: "do not put symmetric keys in the values that are being
>> bound to by identities, only put public keys there". Instead, what I meant
>> to imply was: "if you use public keys as these values that are being bound
>> to, then the keytrans mechanism will provide certain useful properties that
>> allow users to verify these keys are being represented consistently...
>> etc.". If you use symmetric keys, then the keytrans mechanism may not
>> necessarily provide all of the security properties that you would ideally
>> want for a symmetric key. I'm trying to refrain from adding even more
>> properties to the list, for the sake of focusing on a simpler version of
>> the problem that still captures practical use-cases (e.g. key transparency
>> for encrypted messaging). As always, we can consider extending the goals in
>> the future if it turns out to be easy to add these protections for
>> symmetric keys as well. Hope that makes sense!
>>
>>
> Yes, it makes sense, but if the content is opaque I think it is better to
> say the binding is between identity and opaque bytes, but is secured with
> at least some identity to public key binding verifiable process.
>
> Unlike merkle proofs it seems digital signatures are a "required building
> block", and they are needed to secure arbitrary content, but there is no
> specific encoding specified.
>
> > Does the current charter imply that keytrans will use 'IETF-made'
>> verifiability mechanisms based on JOSE or COSE?
>>
>> No, I don't believe this is implied in the current charter text, and I
>> think it should not be mentioned in the charter. But hopefully this should
>> not be ambiguous given the current text, so let me know if it is unclear
>> (and if you have a suggestion for how to make this more clear).
>>
>
> I don't think it's very clear in the current text, and I don't agree it is
> a good design goal.
>
> I think the charter should narrow the scope to support existing IETF work,
> particularly existing serialization such as JSON or CBOR.
>
> The charter should help avoid inventing new envelopes or key formats, if
> that is a goal for MLS, they should do the work in MLS and it should be
> used here.
>
> There are many ways to represent public keys and digital signatures,
> supporting COSE will create better interoperability.
>
> If COSE is a "bad choice", why is "opaque bytes" a better choice?...
>
> I am thinking especially of all the different ways digital signatures
> might fit into the "verification process" and all the different ways to
> represent them:
> DER, ASN.1, ES256, PEM, OpenPGP, EdDSA, BBS, RSA, JWK, COSE Key.... etc...
>
> If you don't narrow here, you either get poor interop, or you make a new
> format.... which probably does not help interop either.
>
>
>>
>>  > It seems to me that every individual party is intended maintain their
>> own personal private append-only log? I am not sure how else you are trying
>> to address PII requirements?
>>
>> Yes, assuming that by "individual party" you mean "service provider" (as
>> referenced in the charter), and not "end user who owns devices".
>>
>
> I'm not a lawyer, but does this make the service provider a Data
> Controller under GDPR, is that the intention?.. Are service providers also
> "identity providers" ?
>
> Is there any intention to support "end users who own devices", being the
> controller of their own data?
>
>
>> Each service provider will likely control a database of identity <->
>> public key mappings which they are not OK with just publishing in plaintext
>> for the world to see, since often the identities are considered PII.
>>
>>
> So the confidentiality model is the same as SCITT architecture, the
> assumption is that "inclusion and consistency proofs" are permissioned with
> some form of access control and so is the log entry contents (opaque bytes).
>
> This differs from RFC9162 which focused on a fully public transparency log
> IIRC.
>
>
>> > In consequence, my assumption is that you intend to proof to other
>> parties that you are maintaining such a personal append-only log? Is that
>> assumption correct? In general, using MLS as the sole source of
>> requirements without taking into account other IETF activities would appear
>> artificially constrained to me.
>>
>> Well, I believe there is a distinction to be made between two of the
>> deliverables for this reason.
>>
>> One deliverable, "Standardizing the core scheme for providing
>> verifiability for identity-to-public-key bindings in an end-to-end
>> encrypted system" would be protocol and integration agnostic, and the aim
>> would be to just focus on the cryptographic components (Merkle tree
>> construction) while treating things like "identities" and "public keys" as
>> opaque blobs.
>>
>
> Similar to how RFC9162 specified the minimal consistency proof, but did
> not define a compact encoding, serialization or envelope parameters for
> JOSE or COSE.
>
> RFC9162 defined new ways to represent digital signatures, and a lot
> of other registries, but it did not define new key formats...
>
> https://datatracker.ietf.org/doc/html/rfc9162#signature_algorithms
>
> https://datatracker.ietf.org/doc/html/rfc9162#section-10.2.3
> https://datatracker.ietf.org/doc/html/rfc9162#section-10.2.4
> https://datatracker.ietf.org/doc/html/rfc9162#section-10.2.5
> https://datatracker.ietf.org/doc/html/rfc9162#section-10.2.6
>
> I am hoping this won't be repeated for KT... but I am happy to be educated
> on why it is the right design choice here if someone feels strongly
> otherwise.
>
>
>> And then the last deliverable, "Standardizing integrations of this
>> verifiability mechanism with other protocols (where the exact security
>> guarantees provided will depend on the underlying encryption)" would be
>> where the opportunity to address other IETF activities would lie. Under the
>> milestones, we are starting with MLS with the hopes that it would be the
>> easiest and most concrete use-case to integrate with. If in the
>> former-mentioned deliverable we are being too constrained to MLS, then that
>> would be good feedback.
>>
>
> I think you are being too constrained, and I think you could get better
> adoption from building on JOSE or COSE. (sorry for repeating this point).
>
> I don't know if the charter should allow doing all 3 or just MLS, and
> leave the envelope encodings to other working groups,
> I think that depends on your use cases, and the preferences of
> implementers who are committing to implementation of charter deliverables.
>
> Maybe you don't need a new working group if this is just going to be
> MLS/JOSE/COSE signatures using * new inclusion proofs *, but securing
> opaque bytes that could be JWK or OpenPGP Keys?
>
>
>> I think ultimately it comes down to the set of properties that we are
>> promising (transparent, user-friendly, private, efficient, sustainable) and
>> whether or not those would suffice for integration with other IETF
>> proposals.
>>
>
> Yep, I agree.
>
> Here are a few other IETF work items to consider:
>
> COSE-HPKE
> COSE Encrypt / COSE KEY
> JWK / JWS / JWE
>
> JSON could be argued is not sustainable or efficient.
>
> MLS / COSE could be argued are not user friendly, but are more sustainable
> and efficient.
>
> Everyone loves to read YAML, but is it really a good idea for this kind of
> thing? Probably not.
>
> RFC9162 would support transparency, but maybe not the fancier merkle trees
> or alternatives you are interested in exploring.
>
>
>> If not, then it would be good to have a discussion on what additional
>> properties we would need to add, or maybe existing ones that should be
>> removed.
>>
>>
> My biggest concern remains inventing new key formats, and new encryption
> or signing envelope formats.
>
> If you need keys and encryption and signature envelopes, I think it would
> be better to build on JOSE / COSE.
> I don't have any experience with MLS, but it seems like it's potentially
> solving a subset of the same problems.
> I am interested to understand when MLS is better than COSE, and when COSE
> is better than MLS.
>
> If you need new encodings of crypto primitives for verifiable data
> aggregation or accumulators or prefix trees,
> you could be helping a much larger community by building them into COSE,
> and this might also shorten the time for implementers to support key
> trans, since they can use off the shelf libraries to get started.
> I don't think this is the case for MLS yet, but it might be in the future,
> perhaps this is the first step in that direction... If that's not the
> intention, it is worrying.
>
> I presented this work at IETF 116 on encoding RFC9162 consistency and
> inclusion proofs for COSE:
>
>
> https://ietf-scitt.github.io/draft-steele-cose-merkle-tree-proofs/draft-steele-cose-merkle-tree-proofs.html#section-4
>
> I'd be interested to understand what kinds of proofs you need to support
> beyond inclusion and consistency, and how to represent them in COSE secured
> with digital signatures.
>
> See also the COSE algorithm registry:
> https://www.iana.org/assignments/cose/cose.xhtml#algorithms
>
> To me, it seems you are intending to define verification algorithms and
> protocols for obtaining proofs (digital signatures with extra data), it
> feels like COSE or OAuth could be good building blocks.
>
> Hopefully we can chat at IETF 117.
>
> OS
>
>
>> Kevin
>>
>>
>> On Fri, Jun 16, 2023 at 8:31 AM Henk Birkholz <
>> [e-mail]> wrote:
>>
>>> Hi Kevin,
>>>
>>> what I think I am reading here is that keytrans intends to treat key
>>> material as opaque blobs, which sounds absolutely fine to me. But :-)
>>>
>>> * why would that exclude symmetric keys?
>>> * does the current charter imply that keytrans will use 'IETF-made'
>>> verifiability mechanisms based on JOSE or COSE?
>>>
>>> It seems to me that every individual party is intended maintain their
>>> own personal private append-only log? I am not sure how else you are
>>> trying to address PII requirements?
>>>
>>> Coming back to JOSE/COSE, opaque blobs are capable of expressing
>>> symmetric key serializations, or other key serializations, for example:
>>>
>>> application/jwk+json     [RFC7517]
>>> application/jwk-set+json [RFC7517]
>>>
>>> application/cose         [RFC9052]
>>> application/cose-key     [RFC9052]
>>> application/cose-key-set [RFC9052]
>>> application/cose-x509    [RFC9360]
>>>
>>> Securing content of known types is well solved for in JOSE and COSE.
>>>
>>> Opaque blobs can also be used to be used to store any attribute of an
>>> identity document, for example, date of birth, or government
>>> identifiers, such as social security numbers.
>>>
>>> In consequence, my assumption is that you intend to proof to other
>>> parties that you are maintaining such a personal append-only log? Is
>>> that assumption correct? In general, using MLS as the sole source of
>>> requirements without taking into account other IETF activities would
>>> appear artificially constrained to me.
>>>
>>> Viele Grüße,
>>>
>>> Henk
>>>
>>> On 16.06.23 03:09, Kevin Lewi wrote:
>>> > Hi Orie,
>>> >
>>> > Personally, I don't think that we should focus on key formats for the
>>> > core verifiability mechanism -- instead, we should treat the keys as
>>> > opaque blobs which can take on any form, and it is left to the
>>> consumer
>>> > of this verifiability mechanism (application layer) to determine what
>>> > format the keys should be stored in, what these keys actually "mean",
>>> > and what claims can be made about the overall system that uses this
>>> > verifiability mechanism.
>>> >
>>> > The exception here would be to address the "standardizing integrations
>>> > of this verifiability mechanism with other protocols" goal, where we
>>> > might indeed have to commit to a specific key format as dictated by
>>> the
>>> > other protocols, for example with MLS.
>>> >
>>> > I also don't think we should consider symmetric keys in scope here,
>>> > since the security properties that we would get out of secrecy for the
>>> > values that the identities are bound to is likely going to be quite
>>> > limited. I'd prefer it if we just focused on the public-key scenario,
>>> at
>>> > least to start.
>>> >
>>> > Good questions!
>>> >
>>> > Kevin
>>> >
>>> >
>>> > On Thu, Jun 15, 2023 at 5:54 PM Orie Steele <[e-mail]>
>>>
>>> > wrote:
>>> >
>>> >     These seem like good improvements.
>>> >
>>> >     Will there be a focus on any particular key formats or
>>> serializations?
>>> >
>>> >     For example COSE, JOSE or PGP keys?
>>> >
>>> >     Will new key formats be invented?
>>> >
>>> >     Will applications of the identity to key binding be in scope, for
>>> >     example using specific keys to prove specific claims related to the
>>> >     bound identity?
>>> >
>>> >     Are symmetric keys in scope?
>>> >
>>> >     OS
>>> >
>>> >
>>> >     On Thu, Jun 15, 2023, 7:30 PM Kevin Lewi <[e-mail]
>>> >     <mailto:[e-mail]>> wrote:
>>> >
>>> >         Hi folks,
>>> >
>>> >         Thanks to everyone for providing the comments. I worked with
>>> >         Brendan McMillion offline to update the text to address the
>>> >         concerns that were brought up in this thread (along with other
>>> >         comments made on the doc). Here are the main changes that were
>>> >         made since the last version:
>>> >
>>> >         1. Reducing the scope of the charter to focus on "providing
>>> >         verifiability for identity-to-public-key bindings" instead of
>>> >         "authenticating information about artifacts".
>>> >         2. In general, removing the claim that we will provide an
>>> >         "authentication mechanism" and shifting to saying that we will
>>> >         provide a "verifiability scheme", to avoid confusion about what
>>> >         exactly "authentication" means in the first place.
>>> >         3. Omitting the original list of threats that included
>>> "silently
>>> >         partitioning a group" and "falsifying information about the
>>> >         state of a group", and instead replacing the text with the
>>> >         single threat of executing "a man-in-the-middle (MITM) attack
>>> by
>>> >         distributing malicious public keys".
>>> >         4. Reworded the "privacy" property, to hopefully be more clear.
>>> >         5. Omitting the paragraph about how it is not a goal of this
>>> >         charter to "specify ways to verify that an account controls a
>>> >         phone number or email address or belongs to a specific legal
>>> >         person". I think with the downscoping to focus on
>>> >         identity-to-public-key bindings, this non-goal does not need to
>>> >         be explicitly stated anymore.
>>> >
>>> >         These changes have been incorporated directly into the charter
>>> >         described in the original link that Brendan shared:
>>> >
>>> https://docs.google.com/document/d/12NMFA0P1OYtE6_QoqP3J80tDr0z2-FEm2ZdiWeauAHE/edit?usp=sharing
>>> <
>>> https://docs.google.com/document/d/12NMFA0P1OYtE6_QoqP3J80tDr0z2-FEm2ZdiWeauAHE/edit?usp=sharing>
>>> . For convenience, I'll also copy the full text at the end of this email.
>>> >
>>> >         Anyway, here's to hoping that these changes are moving the
>>> >         charter in a positive direction. As always, please feel free to
>>> >         reply here or comment on the doc directly with any more
>>> >         questions / feedback!
>>> >
>>> >         Thanks,
>>> >         Kevin
>>> >
>>> >         -------------
>>> >
>>> >         Public keys used to provide end-to-end encrypted communication
>>> >         services are often authenticated solely by the assertion of the
>>> >         communications service provider. As a result, the underlying
>>> >         encryption protocols are left vulnerable to eavesdropping and
>>> >         impersonation by the service provider, which can execute a
>>> >         man-in-the-middle (MITM) attack by distributing malicious
>>> public
>>> >         keys. To mitigate MITM attacks, end-to-end encrypted
>>> >         communication service providers are increasingly looking for a
>>> >         way to provide verifiability for identity-to-public-key
>>> bindings
>>> >         in their system. A scheme for providing this verifiability of
>>> >         key bindings must be:
>>> >
>>> >
>>> >           *
>>> >
>>> >             Transparent: All end users (applications or devices)
>>> receive
>>> >             a globally consistent view of the data associated with each
>>> >             identity.
>>> >
>>> >           *
>>> >
>>> >             User-friendly: Little (ideally zero) user action, or even
>>> >             awareness of the system, is required to verify a user’s key
>>> >             bindings.
>>> >
>>> >           *
>>> >
>>> >             Private: The service provider is not required to publicly
>>> >             reveal potentially sensitive data about its users, such as:
>>> >             what keys are associated with an identity, or even whether
>>> >             or not a specific identity is registered by the service
>>> >             provider.
>>> >
>>> >           *
>>> >
>>> >             Efficient: The computational requirements for both end user
>>> >             and the service provider scales sub-linearly with the
>>> number
>>> >             of users in the system.
>>> >
>>> >           *
>>> >
>>> >             Sustainable: Data that is no longer required by end users
>>> >             may eventually stop being stored.
>>> >
>>> >
>>> >         The KEYTRANS working group will develop a standard for
>>> providing
>>> >         public verifiability for identity-to-public-key bindings in an
>>> >         end-to-end encrypted system with the above properties. This
>>> >         standardized approach will allow shared validation of the
>>> >         end-to-end encrypted communication service’s security
>>> properties
>>> >         and allows applications to share code.
>>> >
>>> >
>>> >         It is not a goal of this working group to enable
>>> >         interoperability between end-to-end encrypted services. Full
>>> >         interoperability of an application would require alignment at
>>> >         many different layers beyond security.
>>> >
>>> >
>>> >         Furthermore, it is not a goal of this working group to develop
>>> >         an end-to-end encryption protocol for user messages. Rather,
>>> the
>>> >         scheme developed by this group will be able to be integrated
>>> >         into other end-to-end encryption protocols.
>>> >
>>> >
>>> >         The main deliverables of the WG will be:
>>> >
>>> >
>>> >         * Specifying an architecture for this public verifiability
>>> mechanism
>>> >
>>> >
>>> >         * Standardizing the core scheme for providing verifiability for
>>> >         identity-to-public-key bindings in an end-to-end encrypted
>>> system
>>> >
>>> >
>>> >         * Standardizing integrations of this verifiability mechanism
>>> >         with other protocols (where the exact security guarantees
>>> >         provided will depend on the underlying encryption)
>>> >
>>> >
>>> >         The WG will work collaboratively with the MLS WG.
>>> >
>>> >
>>> >         Milestones
>>> >
>>> >
>>> >         Mar 2024 - Initial WG adoption of core transparent
>>> verifiability
>>> >         mechanism
>>> >
>>> >
>>> >         Jul 2024 - Initial WG adoption of MLS integration document
>>> >
>>> >
>>> >         Mar 2025 - Submit core transparent verifiability mechanism
>>> >         document to
>>> >
>>> >         IESG as Proposed Standard.
>>> >
>>> >
>>> >         Mar 2025 - Submit MLS integration document to IESG as Proposed
>>> >         Standard.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >         On Mon, Jun 12, 2023 at 5:31 AM Hannes Tschofenig
>>> >         <[e-mail] <mailto:[e-mail]>>
>>> >         wrote:
>>> >
>>> >             FWIW I only understood the charter text after watching the
>>> >             recording of the BOF from the last IETF meeting.
>>> >
>>> >
>>> >
>>> >             Am 08.06.2023 um 00:42 schrieb Eric Rescorla:
>>> >>             Replying with keytrans in the CC list
>>> >>
>>> >>             On Wed, Jun 7, 2023 at 3:39 PM Eric Rescorla <
>>> [e-mail]
>>> >>             <mailto:[e-mail]>> 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
>>> >>                 <[e-mail] <mailto:[e-mail]>> wrote:
>>> >>
>>> >>                     Hi!
>>> >>
>>> >>                     Since the KEYTRANS BoF at IETF 116
>>> >>                     (
>>> https://datatracker.ietf.org/meeting/116/session/keytrans <
>>> 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
>>> <
>>> 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/
>>> <
>>> https://mailarchive.ietf.org/arch/msg/keytrans/6VIEM87-TNe1OYXZRUyAwJX_1vo/
>>> >
>>> >>
>>> >>                     -- AD review of charter
>>> >>
>>> https://mailarchive.ietf.org/arch/msg/keytrans/GfDMvADn5ZgdR7ZfTZt2y296Nuo/
>>> <
>>> 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
>>> >>                     [e-mail] <mailto:[e-mail]>
>>> >>                     https://www.ietf.org/mailman/listinfo/mls
>>> >>                     <https://www.ietf.org/mailman/listinfo/mls>
>>> >>
>>> >>
>>> >             --
>>> >             Keytrans mailing list
>>> >             [e-mail] <mailto:[e-mail]>
>>> >             https://www.ietf.org/mailman/listinfo/keytrans
>>> >             <https://www.ietf.org/mailman/listinfo/keytrans>
>>> >
>>> >         --
>>> >         Keytrans mailing list
>>> >         [e-mail] <mailto:[e-mail]>
>>> >         https://www.ietf.org/mailman/listinfo/keytrans
>>> >         <https://www.ietf.org/mailman/listinfo/keytrans>
>>> >
>>> >
>>>
>>
>
> --
>
>
> ORIE STEELE
> Chief Technology Officer
> www.transmute.industries
>
> <https://transmute.industries>
>