Hey Florian,
thanks for your feedback.
> 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..
>
> 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.
That's how I understood it. I guess my suggestion would be to move
the focus of XEP-0374 from describing what elements an <openpgp/> element
can contain to describing what can contain an <openpgp/> element, which
(at least to me) seems to make more sense.
> 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 guess currently every client implementing XEP-0373 automatically
satisfies all requirements from XEP-0374, as there are basically none.
It's formally not required to be able to handle *any* encrypted element.
Even the three examples in the XEP (<body>, <active> and <html>) are
never strictly required to be supported by a client. All it says is that
"for example, direct child elements found in <payload/> in the context
of IM could be" those three.
So if I talk to a client advertising 'urn:xmpp:openpgp:im:0', that
doesn't give me any knowledge about what elements I can encrypt!
So you suggest to define a set of elements which have to be encryptable.
However, I can't think of any reason why requireing every possible
extension element to be encryptable is a bad idea. Can you give some
examples where this may be bad?
I mean from an implementation point of view it is probably the easiest
to just implement encryption transparently. Just go through the stanza
and replace every <openpgp/>, done.
And say, for example, we only require <body> elements to be supported.
Any implementation receiving a message would have to decrypt the payload
anyways before it knows that it contains a <body> element, so it just
seems just intuitive to just use the content anyway, no matter what it is.
I think this is another reason on why we should make the distinction
between *what can contain* encrypted elements (e.g. only <message>), not
what elements are required to be handled if encrypted.
> [...] 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.
I understand that there may be different requirements in a non-IM scenario,
but IQs are also explicitly part of the Xmpp-IM-Specification (RFC 6121)
and I think it makes sense to include them in such an application profile.
> 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.
Okay, for Presence I also fail to come up with a strong argument for
supporting it. However, in the case of IQs it could have great benefits,
e.g. hiding metadata and IPs and such in the case of Jingle negotiations.
So let me make a new suggestion, then. Maybe we could define several
namespaces (e.g. 'urn:xmpp:openpgp:im:message:0',
'urn:xmpp:openpgp:im:iq:0', 'urn:xmpp:openpgp:im:presence:0') so that
clients could selectively opt-in to what stanzas they are able to receive
encrypted? I think this could all be handled in one XEP and defining three
separate XEPs would probably be very redundant...
>
> > [1] 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
> considered.
Okay, I haven't found it but of course I might have missed it. :)
Thanks again for your feedback and best regards,
Fabian
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
