[Standards] OX (OpenPGP for XMPP): A new OpenPGP XEP
Emmanuel Gil Peyrot
linkmauve at linkmauve.fr
Fri Jan 8 01:37:17 UTC 2016
I just started an implementation in slixmpp, it currently supports
decryption/verification and encryption/sign of signcrypt in
On Wed, Jan 06, 2016 at 07:34:49PM +0200, Sergei Golovan wrote:
> Hi Florian.
> On Wed, Jan 6, 2016 at 3:32 PM, Florian Schmaus <flo at geekplace.eu> wrote:
> > Hello everyone,
> > After a few more weeks of hard work on a ProtoXEP, we are now pleased to
> > announce a first preview of our work. Some parts are still not finished,
> > but everything important is there and thus the ideal time has come to
> > ask for feedback and start the discussion on the XMPP Standards mailing
> > list.
> > The current state of the XEP, which we gave the short name 'OX' (OpenPGP
> > for XMPP), can be found rendered at
> > http://geekplace.eu/xeps/xep-openpgp/xep-openpgp.html
> After a quick reading I'd like to propose to use the <sign/>, <crypt/>
> and <signcrypt/> elements as outer elements, and put some XML
> element like <openpgp/> inside (signed or encrypted as intended).
> It'd be more convenient for the recipient to know in advance what
> to do with the OpenPGP message, so different elements is better
> than the same <openpgp/> when the recipient would have to
> decide which message he got by the message itself.
+1 on that, this is one of the biggest issues here, as there is no way
to know which operation(s) to do before actually attempting them.
A possible candidate to replace the signcrypt, sign and crypt elements
would be XEP-0297, to allow implementations to reuse the forwarded
element as a root one. The only missing thing would be the rpad one,
and it could be added as a namespaced attribute on forwarded.
> Also, I'm a bit concerned about using XMPP server to synchronize
> user's private key. Isn't it too dangerous to keep private key somwhere
> on the internet? I've always thought that one always keeps his
> private key on a controlled computers.
I’m also quite puzzled at this choice, a potentially better solution
would be to allow multiple recipient keys (multiple items on a node?).
> Sergei Golovan
I should also note a spec issue, “OpenPGP content elements MUST posses
at least one 'to' and exactly one 'timestamp' attribute”, since there
can only be zero or one attribute of a kind on an element, the “at
least” and “exactly” specifiers are superfluous.
I’m overall quite happy with this XEP, it solves the multi-resources
issue of XEP-0247 and OTR, and the full stanza encryption of OTR
and OMEMO in a straightforward way, and also provides a way to *not*
use forward-secrecy, which has been requested by quite a few users
Emmanuel Gil Peyrot
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: not available
More information about the Standards