[Standards] OX (OpenPGP for XMPP): A new OpenPGP XEP

Florian Schmaus flo at geekplace.eu
Fri Jan 8 09:39:10 UTC 2016


On 08.01.2016 02:37, Emmanuel Gil Peyrot wrote:
> On Wed, Jan 06, 2016 at 07:34:49PM +0200, Sergei Golovan wrote:
>> 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.

Please have a look on what I already wrote about this topic. I believe
that every OpenPGP API should provide you with a mechanism to determine
if a OpenPGP message contains signed and/or encrypted data.
Implementations then would typically use this information, verify if the
correct OpenPGP content element is used and if the other requirements
are met, and expose this information to the upper layers.

> 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.

We decided deliberately against <forwarded/>. I believe it's confusing
to include a message within a message in this case. Furthermore it is
required to specify exact requirements for OpenPGP content elements as
they are very security sensitive. While we could do this also for
<forwarded/> it is a cleaner, and I believe more secure, approach to
don't use it.

That said, nothing prevents you from putting <forwarded/> into
<signcrypt/>, <sign/> or <crypt/>. But for exchanging signed and
encrypted <body/> elements, you simply but it into the OpenPGP content
element.

>> 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?).

The secret key is always stored *encrypted* in a private PEP node. OX
allows multiple recipients.

> 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.

Fixed.

> 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
> lately.

Thanks for your feedback. :)

- Florian


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160108/485aa1b0/attachment.sig>


More information about the Standards mailing list