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 <f...@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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
