Re: [Standards] XEP-0308: LMC of a previous correction

[JC Brand]

On Tue, Apr 02, 2019 at 12:06:20PM +0200, Georg Lukas wrote:



> While message reordering doesn't exist in XMPP (at least in theory), the
> "blockchain" of corrections provides a cleanly ordered relation over all
> corresponding corrections, whereas with the 'right' way, all corrections
> are equal and the latest one wins.
> 
> However, if you are receiving partial history from MAM or a MUC, it is
> well possible that the original message was either lost (because it's
> older than the retention interval), or is going to be loaded later as
> part of a history scroll back.
> 
> In this case, the 'right' way to interpret the first correction you
> receive is "inject a new message placeholder into the history, with
> unknown timestamp and no payload, then perform a correction on that".
> With the 'wrong' way, the first correction just naturally becomes the
> original message if it corrects an unknown @id.

I think with MAM catchup, the current reading of the spec (i.e. non-chained)
actually makes things easier.

With the chained approach, if you get only part of the chain, you'll need to
memorize somewhere that you're still waiting for an older message with a
particular id (and then when doing another MAM query you need to check
whether you got a message with that id).

With the non-chained approach, you can simply make a placeholder message (like
you suggested) and annotate corrections onto it (ordered by time received).
No need to store not-yet-received ids anywhere.
 
> I'm not sure which way is superior for handling an after-the-fact
> appearance of the original message. I'd also like to hear opinions from
> server archive developers.

> > I did that. It would be great if you didn’t -1 the clarification :p
> 
> It is well possible that my interpretation of the XEP ambiguity was
> not quite correct. However, it is shared by other widely deployed(?)
> implementations, and removing the ambiguity would be a breaking change
> to all those (and yes, I'm obviously biased here because of my own one).

As Kev already mentioned, there are other clients that implemented it
according to the way the XEP was intended, including mine.

What you're proposing would in any case require a namespace version bump right?

Given that, I think it's fair to merge Kev's clarification of the intent
of the current version regardless of whether the chained approach gets
accepted or not.

- JC
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0308: LMC of a previous correction

[JC Brand]

On Tue, Apr 02, 2019 at 02:15:24PM +0200, Georg Lukas wrote:



> > > While message reordering doesn't exist in XMPP (at least in theory),
> > > [...] all corrections are equal and the latest one wins.
> > …which is fine, AFAICS.
> 
> While a little bit tongue-in-cheek, my comment was intended to provoke
> further thought. One such situation(*) is when you perform two
> corrections of the same message from two different clients, with the
> corrections arriving at the recipient in arbitrary order. The 'wrong'
> approach spans a tree of message corrections leading to the original
> message as its root. A recipient will end up showing all leaf messages
> (because it won't be able to merge different sub-trees) as long as order
> is maintained over each sub-tree. With the 'right' approach, all
> corrections are leafs of the original, leaving the most
> delayed correction as the winner(**).

Are you arguing against your own suggested "chained" approach here?

Seems to me this is a problem that would only arise when using the chained
approach because then two correcting messages referring to the same
ancestor "id" require you to turn your linked list into a tree.

When implementing the current version of the spec (made more explicit with
Kev's clarification) this problem won't arise because the list of correcting
messages is ordered based on reception date, not linked via their "id"
attributes.



- JC
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)

[Evgeny]

On Wed, Apr 3, 2019 at 6:02 PM, Melvin Keskin  wrote:
I appreciate that you think of UX aspects but ATT should not degrade 
UX
when another way of authentication is implemented alongside it. For 
ATT

no user interaction is needed and it can always be used. It is not
necessary to deactivate it. It can just be extended by other
mechanisms covering other cases.


The problem is that ATT resolves the same problem as EAX does (by 
putting the burden on CAs). So we have two conflicting approaches.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)

[Evgeny]

On Wed, Apr 3, 2019 at 5:52 PM, Melvin Keskin  wrote:

Every way has its advantages and its disadvantages.


Everything is relative, I see.


That was the reason for creating ATT. I
wanted the users to benefit from automating the whole process of key
authentication now and not some day in the future. If we only
concentrate on the future, we will forget the problems current XMPP
users are facing nowadays.


And I kinda want to adopt EAX in the next century? I'm not going into 
ranting about "I need it ASAP" mentality in standards development, but 
with such approach, can you please address a potential problem of 
compatibility when some clients support EAX and some manual-only 
verification with ATT?


> My main focus are new XMPP users. It was> hard for me to get them to 
XMPP and we will lose them again if we do

> not provide solutions for current problems.

I don't see an urgent problem here, but okay.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Voting Summary 2019-03-31

[Dave Cridland]

On Wed, 3 Apr 2019 at 17:17, Paul Schaub  wrote:

> That's what I was going to say. There is no new crypto, and no cross
> signing, just exchanging fingerprints over an already secured channel. If
> that would be considered inventing you own crypto, we wouldn't be
> exchanging any encrypted messages at all.
>
>
There's no new algorithms, but this is a new automated trust system with
non-transitive properties. That's applied cryptography at least to the
level of, say, POSH, or similar. OMEMO just lifts libsignal and ports it to
XMPP with no changes in the "How". EAX, similarly, just applies X.509 in
fairly normal ways to XMPP. But we ran POSH through the IETF because it
built a different trust chain mechanism onto X.509. Why wouldn't we with
this?

The *people* involved might well have enough capability to review this
document, but I wouldn't claim to, and with the best will in the world, I
don't think either the XSF as a whole or the XMPP Council has the
institutional capability to review such a thing either - even if it were
complete enough to be able to fully understand its security, which it is
not.

Finally, there *is* cross-signing in all but name - the ATT message is
inherently signed when sent over the OMEMO channel. Yes, it's signing an
ATT message containing a fingerprint, rather than signing the public key
info of the key directly, but unless I'm missing something, this is
fundamentally equivalent. Yes, the signature is ephemeral, but it is a
signature nonetheless.


> Am 3. April 2019 18:12:47 MESZ schrieb "W. Martin Borgert" <
> deba...@debian.org>:
>>
>> Quoting Dave Cridland :
>>
>>> * But this is creating our own cryptography, and the XSF should not be
>>> doing that.
>>>
>>
>> If I understand ATT correctly, it's not cryptography in itself, but
>> automation of key "trust state" copying. More a kind of convenience
>> function. Please CMIIW.
>> --
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: standards-unsubscr...@xmpp.org
>> --
>>
>> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Voting Summary 2019-03-31

[Paul Schaub]

That's what I was going to say. There is no new crypto, and no cross signing, 
just exchanging fingerprints over an already secured channel. If that would be 
considered inventing you own crypto, we wouldn't be exchanging any encrypted 
messages at all.

Am 3. April 2019 18:12:47 MESZ schrieb "W. Martin Borgert" :
>Quoting Dave Cridland :
>> * But this is creating our own cryptography, and the XSF should not
>be
>> doing that.
>
>If I understand ATT correctly, it's not cryptography in itself, but
>automation of key "trust state" copying. More a kind of convenience
>function. Please CMIIW.
>
>___
>Standards mailing list
>Info: https://mail.jabber.org/mailman/listinfo/standards
>Unsubscribe: standards-unsubscr...@xmpp.org
>___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Voting Summary 2019-03-31

[W. Martin Borgert]

Quoting Dave Cridland :

* But this is creating our own cryptography, and the XSF should not be
doing that.


If I understand ATT correctly, it's not cryptography in itself, but
automation of key "trust state" copying. More a kind of convenience
function. Please CMIIW.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Voting Summary 2019-03-31

[Dave Cridland]

On Wed, 3 Apr 2019 at 15:34, Melvin Keskin  wrote:

> You wrote in your first message on ATT:
> > This alone is absolutely not a blocker to adoption in my view.
>
> Then I read:
> > -1 - I don't think there's evidence of this being anything beyond a
> > very
> > high-level sketch. Designing a cryptographic trust system is complex,
> > and
> > I'm not convinced we have the expertise to adequately do such a
> > thing.
>
> I am confused now because I thought you would accept ATT but it needs
> more improvement. What did you mean by "This alone is absolutely not a
> blocker to adoption in my view."?
>

I said, roughly:

* This specification is just a high-level sketch.
* But this is creating our own cryptography, and the XSF should not be
doing that.

The first is not a blocker. The second, I think, is.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)

[Ненахов Андрей]

 On Wed, 3 Apr 2019, 20:42 Paul Schaub,  wrote:

> Thats more a general OMEMO critic that has nothing to do with ATT, right?
>

No, I can totally see the benefits of  OMEMO for a (very unwelcome) subset
of our users. However, ATT seems to actually diminish said benefits.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)

[Paul Schaub]

Thats more a general OMEMO critic that has nothing to do with ATT, right?

Am 3. April 2019 17:25:23 MESZ schrieb "Ненахов Андрей" 
:
>What I don't get about this Trust Transfer thing is that it is kinda
>defeating the purpose of OTR-like encryption. If you are really that
>paranoid that you want/need forward secrecy for whatever you do, it's
>kinda
>counter-productive to have message conveniently copied to all your
>different devices. And if you just want a convenient way to be sure
>that
>all your devices are neatly synced but server admins can't read your
>messages, better invent something like PGP and a way to exchange public
>keys with chat partners and private keys between devices.
>
>As an example, there are secret chats in Telegram, and they work on
>strictly between two devices. You can't resume secret chat on another
>device, you can't participate in this chat from several devices, and it
>is
>actually OK for everybody. Also, having more devices in a secret chat
>reduces privacy and security, and if you aren't after security, then
>what
>are you after?
>
>-- 
>Andrew Nenakhov
>CEO, Redsolution, Inc.
>https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)

[Ненахов Андрей]

What I don't get about this Trust Transfer thing is that it is kinda
defeating the purpose of OTR-like encryption. If you are really that
paranoid that you want/need forward secrecy for whatever you do, it's kinda
counter-productive to have message conveniently copied to all your
different devices. And if you just want a convenient way to be sure that
all your devices are neatly synced but server admins can't read your
messages, better invent something like PGP and a way to exchange public
keys with chat partners and private keys between devices.

As an example, there are secret chats in Telegram, and they work on
strictly between two devices. You can't resume secret chat on another
device, you can't participate in this chat from several devices, and it is
actually OK for everybody. Also, having more devices in a secret chat
reduces privacy and security, and if you aren't after security, then what
are you after?

-- 
Andrew Nenakhov
CEO, Redsolution, Inc.
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)

[Melvin Keskin]

> I already replied: if we produce both XEPs, we'll end up with some 
> devices with manual/ATT verification and others with EAX. This will 
> further degrade UX. So the XEPs interaction is required to be 
> documented.

I appreciate that you think of UX aspects but ATT should not degrade UX
when another way of authentication is implemented alongside it. For ATT
no user interaction is needed and it can always be used. It is not
necessary to deactivate it. It can just be extended by other
mechanisms covering other cases.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)

[Melvin Keskin]

> I kinda misread your proposal, so it's irrelevant in the context of
> the 
> proposal, sorry for confusion.

OK, you're welcome.

> Well, I understand all this. However, a complete picture I see is 
> CA-signed certificates by default, and ATT and/or manual
> verification 
> when you need more rigid authentication.
> So my suggestion is to stop 
> taking positions (whether CAs are bad or whether manual verification
> is 
> usable for regular users) and create a more general "framework". I
> also 
> would like to note that MLS supports both ways. And, yeah, I see how 
> ATT can improve UX as well (in theory).

Every way has its advantages and its disadvantages. Currently, OMEMO is
the best supported and most widely-used (if not said only) end-to-end
encryption in my community. That was the reason for creating ATT. I
wanted the users to benefit from automating the whole process of key
authentication now and not some day in the future. If we only
concentrate on the future, we will forget the problems current XMPP
users are facing nowadays. My main focus are new XMPP users. It was
hard for me to get them to XMPP and we will lose them again if we do
not provide solutions for current problems.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Voting Summary 2019-03-31

[Melvin Keskin]

You wrote in your first message on ATT:
> This alone is absolutely not a blocker to adoption in my view.

Then I read:
> -1 - I don't think there's evidence of this being anything beyond a
> very
> high-level sketch. Designing a cryptographic trust system is complex,
> and
> I'm not convinced we have the expertise to adequately do such a
> thing.

I am confused now because I thought you would accept ATT but it needs
more improvement. What did you mean by "This alone is absolutely not a
blocker to adoption in my view."?

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)

[Melvin Keskin]

> Maybe one could bundle all those verifications up in some data
> structure and then either send 1! message or even do it over IQ.

In the next version of ATT fingerprints of keys of multiple contacts
will be bundled.

Thanks for your proposal.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)

[Evgeny]

On Wed, Apr 3, 2019 at 5:06 PM, Melvin Keskin  wrote:

ATT does not depend on EAX. It just tackles the challenge of key
authentication when using end-to-end encryption with multiple devices
having different keys.


I already replied: if we produce both XEPs, we'll end up with some 
devices with manual/ATT verification and others with EAX. This will 
further degrade UX. So the XEPs interaction is required to be 
documented.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)

[Evgeny]

On Wed, Apr 3, 2019 at 4:54 PM, Melvin Keskin  wrote:

Hello Evgeny,

thanks for your comments.


Hi, Melvin!


 This is especially doubtful,
 since it's speculated that the topology of a social graph has power-
 law
 distribution [1] and thus only a few people will benefit from the
 "trust transfer".


What exactly do mean by that?


I kinda misread your proposal, so it's irrelevant in the context of the 
proposal, sorry for confusion.



Using Certificate Authorities (CA) for key authentication would be
better than not authenticating keys at all. It could be used
additionally to the authentication of keys via ATT when you have no
other trusted channel to a contact.
ATT is completely independent of CAs. One advantage is that a user do
not have to decide which CA is trustworthy and which not. If one CA
trusts a contact's key and another not, the question "which CA should
the user trust?" comes up. Besides some other advantages that is a
problem ATT solves for the case when there is an already trusted
channel like a meeting in person.
In the case of own devices the user normally has such a trusted 
channel

to manually authenticate the keys of those devices (e.g., by scanning
their QR codes containing the fingerprint of the device's key). Thus, 
a

CA will never be necessary.

ATT does not exclude other ways of authentication. A combination of
more ways than that would be great to simplify the usage of end-to-
encrypted communication with authenticated keys.


Well, I understand all this. However, a complete picture I see is 
CA-signed certificates by default, and ATT and/or manual verification 
when you need more rigid authentication. So my suggestion is to stop 
taking positions (whether CAs are bad or whether manual verification is 
usable for regular users) and create a more general "framework". I also 
would like to note that MLS supports both ways. And, yeah, I see how 
ATT can improve UX as well (in theory).



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)

[Melvin Keskin]

> In the series of body semantics rants, I feel the need to mention
> that I
> don't like the wire format. I don't see any reason to overload body
> semantics with this new feature.
> 
> Clients that don't support this XEP won't be able to do anything with
> it
> and that would only appear raw to the user who would most likely be
> clueless about it.
> 
> Is there anything we can do here?

Yes, as stated in my email message to Dave Cridland, the next version
of ATT will not overload the body anymore.

Special thanks to Paul Schaub for finding a better solution and of
course thanks to you for your tenacity.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)

[Melvin Keskin]

> If the Council accepts both XEPs as is, then we raise 
inconsistency in our XEPs.
ATT does not depend on EAX. It just tackles the challenge of key
authentication when using end-to-end encryption with multiple devices
having different keys.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)

[Melvin Keskin]

Hello Evgeny,

thanks for your comments.

> I don't understand how this will work in practice indeed.
> 1) The "trusted" graph is not connected (i.e. you cannot reach any 
> vertex from any other vertex), thus, in the worst case the
> complexity 
> of verification will remain the same.

In all other cases than the worst case the users will benefit from ATT.

> This is especially doubtful, 
> since it's speculated that the topology of a social graph has power-
> law 
> distribution [1] and thus only a few people will benefit from the 
> "trust transfer".

What exactly do mean by that?

> 2) The problem of manual verification is still unresolved, because
> for 
> online persons (i.e. without meeting them offline) you have to use
> an 
> already trusted channel to perform verification, so chicken and egg 
> problem.

The goal of ATT is not to simplify the manual authentication instead it
reduces the number of manual authentications for multiple devices
(of two communication partners) each having a different key.

> 3) Isn't it better to work on the problem together, i.e. in the
> context 
> of my EAX proposals? If you don't trust the CA or want to have 
> additional guarantees you can resort to manual or ATT verification.
> I 
> don't see any contradictions here. Both approaches are kinda 
> complementary and can be working together, unless you're reluctant
> and 
> hate CAs.

Using Certificate Authorities (CA) for key authentication would be
better than not authenticating keys at all. It could be used
additionally to the authentication of keys via ATT when you have no
other trusted channel to a contact. 
ATT is completely independent of CAs. One advantage is that a user do
not have to decide which CA is trustworthy and which not. If one CA
trusts a contact's key and another not, the question "which CA should
the user trust?" comes up. Besides some other advantages that is a
problem ATT solves for the case when there is an already trusted
channel like a meeting in person.
In the case of own devices the user normally has such a trusted channel
to manually authenticate the keys of those devices (e.g., by scanning
their QR codes containing the fingerprint of the device's key). Thus, a
CA will never be necessary.

ATT does not exclude other ways of authentication. A combination of
more ways than that would be great to simplify the usage of end-to-
encrypted communication with authenticated keys.

Thanks.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)

[Melvin Keskin]

Hello Dave,

thank you for your comments.

> * It always worries me when people suggest security protocols and use
> odd
> naming conventions. There is, surely, no such thing as "trust
> transfer",
> whether automatic or not. Trust can be transitive, of course, but not
> transferable.

I would suggest to rather focus on the topic instead on the name.

> * The messages are simply defined as being URIs. One assumes these
> are
> transferred over XMPP, but it's not described how. Presumably these
> would
> need to be authenticated messages somehow - are these intended to be
> encrypted themselves using OMEMO? What format is used?

In the current version the URIs are inserted into the body of the XMPP
message using OMEMO.
Since the content of the trust message is exclusively used for
automatic processing, it would be better to use OMEMO encrypted XML
elements.
Therefore, I will change the format of the trust message's content from
URI to XML and take it out of the body.

> * §4.1 is virtually impossible to follow because there's no
> indication of
> who owns what devices.

In that section it is irrelevant who owns those devices. It should only
explain the basic procedure and give a rough understanding of it.

>  * In §6, we see that Bob's trust of the keys A2 and A3 is predicated
> on a
> continuing trust of the key A1, but the trust is described as
> absolute
> rather than as a chain. If A1's key is later revoked, it is unclear
> whether
> one expects B1 to continue to trust A2 and A3.

Only for clarification: In the examples A1, A2 etc. are devices not
keys.
The primary goal of the XEP was to minimize the number of manual
authentications. But for revocation your proposed chain of trust could
be used additionally. I will try to work on that in the next version.
 
> * It is not explained how A1 trusts A2 and A3, or vice-versa.

I do not understand your comment.
Could you please rephrase that?

> * §8.1 describes mandated behaviour, but does not explain what the
> attack
> is nor how this behaviour mitigates the attack.

 End-to-end encryption is based on the assumption that the devices are
not compromised. Section 8.1 is used for having an additional
protection when a device is stolen. If the recipient of the trust
message would like to check the correctness of the received information
via another channel, it may be done.
In the first case the user is simply informed about the automatic
authentication.
In the second case the user is asked for confirmation before any
authentication happens. The authentication which would normally be
automatic is then semi-automatic. That means that the trust message is
sent automatically but the authentication is not done completely
automatically.
I will move the first two sentences of section 8.1 to another section
so that the intention of the rest of that section is clear.

> * §8.2 describes a general attack briefly, and then mandates
> behaviour.
> Neither of which to my eyes has little or nothing to do with ATT
> itself,
> but relates to OMEMO (or even XMPP) in general.

ATT automates authentications which formerly had to be done manually. 
If you do not revoke the trust in blindly trusted keys after an
authentication, there is no chance to protect the user against active
attacks made with those keys even if you authenticated all of the good
keys. When using ATT, many steps are automated. So, the goal of
trusting only authenticated keys is easier to achieve. That is the
reason for recommending the described security policy.

> Overall, my view is that this specification is very unclear and
> impossible
> to implement as written.

Please have a look at https://github.com/olomono/att. There is an
implementation and an algorithm (pseudocode). I followed the current
version of the XEP. Thus, it is possible to implement the XEP by
following it.

> This alone is absolutely not a blocker to adoption
> in my view. However it is not clear whether the community has the
> ability
> and expertise to adequately review and develop such a specification.

There were many discussions until now with many of the current OMEMO
developers and also non-OMEMO client and server developers.
I improved the XEP with their help. So, I would say that the community
is able to review it.

You reviewed it as well (as a member of the community) and I will use
your comments for improving the XEP.

Thanks.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___