-
Link Mauve
Flow, what’s the rationale for having moved everything out of signcrypt, in OX?
-
Flow
Link Mauve: please define "everything" :)
-
Link Mauve
Err, not out, more like moved the attributes to elements.
-
Flow
ahh I assumed that is what you meant
-
Flow
short answer: because you can't have multiple attributes with the same name
-
Link Mauve
And you want to, in this case?
-
Flow
and we want to be able to specify multiple recipients
-
Flow
so the initial idea was to <signcrypt to='foo@bar.com' to='baz@bar.com'>
-
Flow
but that's not valid xml
-
Flow
so now we have <signcrypt ...><to .../><to .../>...
-
Link Mauve
Oh, the <to/> are there to list every recipient that can decrypt?
-
Flow
Link Mauve: Yes "OpenPGP content elements MUST possess at least one 'to' ..." and "The 'to' element(s) MUST have a 'jid' attribute which contains the intended recipient's XMPP address..."
-
Link Mauve
s/recipient's/recipients'/ then.
-
Flow
RFC 4880 already allows multiple recipients and there is no reasion to restrict an OX OpenPGP content element to one
-
Link Mauve
So should there always be a <to/> for yourself?
-
Link Mauve
Always?
-
Flow
Link Mauve: I don't think so
-
Flow
The encrypt to self is to allow users to read their own send messages
-
Flow
The <to/> in OpenPGP content elements is there to prevent attacks where the message is send by an attacker to a third party
-
Flow
which was not the intended recipient in the first place
-
Link Mauve
It might be useful to define what to do if you (the recipient) don’t match any of the <to/>.
-
Flow
Link Mauve: I think what we have in OX § 3.2 is sufficient right now
-
Flow
You can't specify what an implementation should to if the verification fails
-
Flow
If I wouild ask you what you plan to do in profanity, and then I would ask daniel what he plans to do in conversations, I would likely get two different answers.
-
Link Mauve
poezio* :)
-
Link Mauve
Actually, just slixmpp for now.
-
Flow
Link Mauve: Uhh, sorry.
-
Flow
Isn't the profanity dev also here?
-
Link Mauve
I know the mcabber dev is here, coucou McKael.
-
Link Mauve
Also the primitivus dev is here, coucou goffi.
-
Flow
Link Mauve: Are you going to the Summit/FOSDEM?
-
Link Mauve
Sure. :)
-
Link Mauve
Will miss the first morning of Summit though. :(
-
goffi
I need to check this OX stuff, it can be interesting for our private blog feature
-
mathieui
afaik the profanity dev is boothj5, and he’s not here
-
Ge0rG
am I reading OX right, that the <openpgp> element contains base64-encoded xml elements?
-
Flow
Ge0rG: no base64 encoded RFC 4880 messages which contain an encrypted and/or signed UTF-8 string which contains XML.
-
Flow
bbl
-
Ge0rG
maybe section 3 should more clearly state that, and provide a rationale
-
Flow
a rationale for?
-
Ge0rG
a rationale for putting base64-encoded xml into xml.
-
Flow
But that's not the case
-
Ge0rG
besides, there is no format specification in section 3, and only a brief examle of one of the three use cases
-
Flow
I admit that § 3.1 format specification is not very well written, but it is there: "The text content <openpgp/> (BASE64_OPENPGP_MESSAGE) is a Base64 encoded, as specified in RFC 4648 [3] § 4, OpenPGP message which contains an encrypted and/or signed UTF-8 encoded string. Note that OpenPGP's ASCII armor is not used, instead the XMPP client MUST encode the raw OpenPGP message, as specified in RFC 4880 [4], using Base64. This string MUST represent exactly one OpenPGP content element, that is either a <signcrypt/>, a <sign/> or a <crypt/> extension element qualified by the 'urn:xmpp:openpgp:0' namespace."
-
Ge0rG
also why use base64 over ascii armor?
-
Flow
because we encode the OpenPGP message
-
Ge0rG
"This string MUST represent ..." maybe "correspond to" would be a better wording.
-
Ge0rG
the OpenPGP message format also encodes whether it's a signed/encrypted message and which key-ids it is encrypted for. Why is this data duplicated inside?
-
Flow
key-ids != jids
-
Zash
wat
-
Zash
Ge0rG: I thougt "ascii armor" was base64?
-
moparisthebest
Ge0rG, it looks like base64 is used INSTEAD of ascii armor, not over it?
-
Ge0rG
moparisthebest: that's what I intended to say
-
Flow
and as for <signcrypt/>, <sign/> and <crypt>, for one, it is a fail safe, if an implementation constructs a <signcrypt/> message, because it wants to send a signed and encrtyped message, but only encrypts it using OpenPGP
-
Ge0rG
Zash: yes, but with dashes and headers added.
-
moparisthebest
oh so is it the same as the old spec? ascii armor stripped of whitespace and headers?
-
Ge0rG
Flow: how should a client receiving such a failed message behave?
-
Flow
Ge0rG: What woud you suggest?
-
moparisthebest
explosions
-
Flow
atomic ones?
-
moparisthebest
I was thinking more firecracker-like
-
Flow
uhh :(
-
Flow
Ge0rG: Link Mauve asked a similar question just before you today. I don't have an answer other then "it should consider the message as unverified", and I don't think a spec should specify what a client should/must do if a message is unverified.
-
Zash
Light the thermite failsafe device
-
moparisthebest
clients don't do nearly the same with with current pgp if decryption fails, I was messing around with this yesterday with a command-line pgp-capable sendxmpp command
-
Flow
moparisthebest: "don't do nearly the same"?
-
moparisthebest
conversations displays "can't decrypt, maybe you don't have the right private key?" even when 'encrypted content' is 'bla'
-
moparisthebest
and gajim sometimes displays the content of <body>, and sometimes shows no indication of having received a message at all
-
Flow
ahh
-
moparisthebest
Flow, I'm saying they aren't consistent in what they do when receiving bad pgp encrypted messages
-
moparisthebest
it would be nice if they were somewhat consistent though, I don't like gajim just dropping messages silently
-
moparisthebest
you probably don't want to specify what exactly they should say, maybe you could just specify they should inform the user in some way?
-
Ge0rG
what about sending an error back?
-
Ge0rG
though what do you do if a client (of multiple) just doesn't have the right key?
-
Ge0rG
Flow: by not having the redundancy, one could prevent the existence of these border cases.
-
Flow
Ge0rG: error as response of a presence has the potential for a presence leak, but if you check before sending that the entity has access to your presence anyway, then yes why not
-
moparisthebest
and they could *get* the key later, due to the nature of pgp
-
moparisthebest
like I set up conversations on a new phone and haven't set up openkeychain yet
-
Ge0rG
sending an error as a response to a malformed message doesn't seem too far-reached
-
moparisthebest
and do you still send the error back when you are retrieving with MAM ?
-
Flow
Ge0rG: I think a bad programmer is more likely to be able to construct an XML string prefixed with <signcrypt/>, <crypt/> and <sign/> then to use a OpenPGP library correctly
-
moparisthebest
or do all your devices receiving the carbon send messages?
-
Flow
So it's not about removinga border case, but about having a fail safe for this case
-
moparisthebest
there might be a difference to what you do if you don't have a key vs not-pgp, I'm not sure it'd be a problem outside of development
-
Ge0rG
Flow: I think that adding this redundancy creates the border cases in the first place
-
Ge0rG
"in the range of tenth of kilobytes" --> "in the range of tens of kilobytes" I suppose
-
Ge0rG
the timestamp is redundant as well.
-
Flow
Yep
-
Ge0rG
so a client may receive a message with three (different) timestamps. XEP-203, openpgp and <time>
-
Ge0rG
which one do you display?
-
Flow
I would display <time>
-
xnyhps
Ge0rG: And possibly timestamps added by multiple different servers. ;)
-
Flow
xnyhps: Which remindes me, I wanted to reply to your latest mail on standards@
-
xnyhps
Timestamps are quite messy because it's not easy to say who to trust in general.
-
Flow
I'd be interested in persuing the added:by approach
-
Flow
And from what I can read, daniel too
-
Flow
I'd like to hear from some more server guys what they think about it
-
Flow
I believe most of the business rules from xep359 could go into the added:by xep
-
xnyhps
Flow: Some of them, yeah
-
xnyhps
Still not sure the complexity is really worth it.
-
Flow
xnyhps: That's basically why I didn't replly initially
-
xnyhps
My main reason was that the things the server strips might have changed between when the message was originally sent and when the client received it (from MAM), but as long as servers also strip messages outgoing on MAM that's not a problem.
-
Link Mauve
Flow, might be useful to add a section about what to do if there are e.g. both an openpgp and a body element in a message or presence (iq obviously can’t have that).
-
Flow
Link Mauve: Hmmm, undecided, I personally don't think it is necessary
-
Flow
but patches welcome :)
-
Flow
XMPP-IM neither specifies what to do when a message with two <body/> arrives
-
Flow
(or maybe it does and I don't remember)
-
Ge0rG
Flow: "For example, direct child elements found in either <signcrypt/>, <sign/> and <crypt/> could be: " <- shouldn't that read "For example, <payload/> child elements..."?
-
Flow
Ge0rG: Thanks, that is a leftover from the attribute to elements migration
-
Flow
fixing right now
-
Ge0rG
Flow: also s/my/by/ in the §8.3 text
-
Flow
fixed
-
Ge0rG
Flow: the link from §6.1 to http://tools.ietf.org/html/rfc4880#section-5.5.2 talks about key packets, not about message formats
-
Ge0rG
I hope I didn't kill the OX thread with my long response.
-
Link Mauve
Given the date, I’d even say the opposite. :)
-
Ge0rG
Link Mauve: oh, right. I've been on holiday and missed it. Just found the time to read up, and the messages all were "new" to me
-
Flow
Ge0rG: it's just an example of packets where v4 must be used. The most important one, but just an example