[Standards] OpenPGP IM: all stanza types supported?
flo at geekplace.eu
Thu Sep 29 10:53:09 UTC 2016
On 29.09.2016 00:00, Fabian Beutel wrote:
> First, did I interpret the OpenPGP-XEP-0373/374 correctly that any
> stanza can be encrypted and not only messages?
Yes and No. XEP-0373 defines an extension element called <openpgp/>
which carries OpenPGP encrypted and/or signed data. It does not talk
about (full or not full) stanza encryption per se, although full stanza
OpenPGP encryption using the <openpgp/> element would be possible..
> If so, I think it might be good to explicitly state that in XEP-0374.
XEP-0374 is an application profile for XEP-0373. It explains and shows
examples of extension elements to be wrapped into an <openpgp/> element
like message bodies or XHTML-IM.
> Also, I would suggest to strictly require implementations to
> transparently handle the content of the <payload> element.
> "[...] SHOULD be processed similar as if they had been direct extension
> elements of the stanza" may be a to vague - here I would suggest to use
> MUST instead. 
> That way, when I'm talking to a client that supports XEP-0374 I can be
> sure that it understands any encrypted stanza I send and for example
> jingle negotiations could happen encrypted.
That 'SHOULD' was put there deliberately. We don't think that it would
be a good idea to require implementations to support every possible
extension element wrapped into a <openpgp/>. However I could imagine
that we create a small minimal required set of extension elements which
have to be supported once a feature like 'urn:xmpp:openpgp:im:0' is
announced. Possible this set would just consist of '<body/>.
> I created a pull request for these suggestions and would be happy if the
> authors would take a look at it! 
I'll comment on your changes here. As I said above, the 'SHOULD' was
chosen for a reason. And I see what you try with your 'Stanza support'
section, but XEP-0374 is just not the right place to specify it, because
it's really just about exchanging IM messages. If you want OpenPGP
secured Presence and IQ stanzas, then those should be defined in an
extra XEP which reuses the building blocks for XEP-0373. That's the idea
behind the XEP-373/374 split. 373 provided the fundamental primitives
which can be used in other XEPs to specify OpenPGP application profiles.
We already had some discussion about OpenPGP secured Presence/IQ in the
past. But OpenPGP secured Presence is at least controversial, because it
will possible (depending on how you design it) leave your key unlocked
and the benefits are minimal.
>  The situation in example 3 in XEP-0374, where the containing stanza
> already has a <body> element ("<body>This message is encrypted using
> OpenPGP.</body>") could be handled by requiring that in case of a name
> conflict (an element already exists) the encrypted element always takes
> precedence over the unencrypted one.
I would have bet we already added such a rule. But if not, it should be
Thanks for you feedback.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 603 bytes
Desc: OpenPGP digital signature
More information about the Standards