Link MauveFlow, what’s the rationale for having moved everything out of signcrypt, in OX?
FlowLink Mauve: please define "everything" :)
Link MauveErr, not out, more like moved the attributes to elements.
Flowahh I assumed that is what you meant
Flowshort answer: because you can't have multiple attributes with the same name
Link MauveAnd you want to, in this case?
Flowand we want to be able to specify multiple recipients
Flowso the initial idea was to <signcrypt to='foo@bar.com' to='baz@bar.com'>
Flowbut that's not valid xml
Flowso now we have <signcrypt ...><to .../><to .../>...
Link MauveOh, the <to/> are there to list every recipient that can decrypt?
Tobiashas joined
FlowLink 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 Mauves/recipient's/recipients'/ then.
FlowRFC 4880 already allows multiple recipients and there is no reasion to restrict an OX OpenPGP content element to one
Link MauveSo should there always be a <to/> for yourself?
Link MauveAlways?
FlowLink Mauve: I don't think so
FlowThe encrypt to self is to allow users to read their own send messages
FlowThe <to/> in OpenPGP content elements is there to prevent attacks where the message is send by an attacker to a third party
Flowwhich was not the intended recipient in the first place
Link MauveIt might be useful to define what to do if you (the recipient) don’t match any of the <to/>.
FlowLink Mauve: I think what we have in OX § 3.2 is sufficient right now
FlowYou can't specify what an implementation should to if the verification fails
FlowIf 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 Mauvepoezio* :)
Link MauveActually, just slixmpp for now.
FlowLink Mauve: Uhh, sorry.
FlowIsn't the profanity dev also here?
Link MauveI know the mcabber dev is here, coucou McKael.
Link MauveAlso the primitivus dev is here, coucou goffi.
FlowLink Mauve: Are you going to the Summit/FOSDEM?
Link MauveSure. :)
Link MauveWill miss the first morning of Summit though. :(
goffiI need to check this OX stuff, it can be interesting for our private blog feature
Alexhas joined
mathieuiafaik the profanity dev is boothj5, and he’s not here
Kevhas left
Kevhas left
bjchas left
Ge0rGam I reading OX right, that the <openpgp> element contains base64-encoded xml elements?
FlowGe0rG: no base64 encoded RFC 4880 messages which contain an encrypted and/or signed UTF-8 string which contains XML.
Flowbbl
Ge0rGmaybe section 3 should more clearly state that, and provide a rationale
Flowa rationale for?
Ge0rGa rationale for putting base64-encoded xml into xml.
FlowBut that's not the case
Ge0rGbesides, there is no format specification in section 3, and only a brief examle of one of the three use cases
FlowI 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."
Ge0rGalso why use base64 over ascii armor?
Steffen Larsenhas joined
Flowbecause we encode the OpenPGP message
Ge0rG"This string MUST represent ..." maybe "correspond to" would be a better wording.
Steffen Larsenhas left
intosi has joined
Ge0rGthe 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?
Flowkey-ids != jids
Zashwat
ZashGe0rG: I thougt "ascii armor" was base64?
moparisthebestGe0rG, it looks like base64 is used INSTEAD of ascii armor, not over it?
Ge0rGmoparisthebest: that's what I intended to say
Flowand 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
Ge0rGZash: yes, but with dashes and headers added.
moparisthebestoh so is it the same as the old spec? ascii armor stripped of whitespace and headers?
Ge0rGFlow: how should a client receiving such a failed message behave?
FlowGe0rG: What woud you suggest?
moparisthebestexplosions
Flowatomic ones?
moparisthebestI was thinking more firecracker-like
Flowuhh :(
FlowGe0rG: 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.
ZashLight the thermite failsafe device
moparisthebestclients 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
Flowmoparisthebest: "don't do nearly the same"?
moparisthebestconversations displays "can't decrypt, maybe you don't have the right private key?" even when 'encrypted content' is 'bla'
moparisthebestand gajim sometimes displays the content of <body>, and sometimes shows no indication of having received a message at all
Flowahh
moparisthebestFlow, I'm saying they aren't consistent in what they do when receiving bad pgp encrypted messages
boothj5has joined
moparisthebestit would be nice if they were somewhat consistent though, I don't like gajim just dropping messages silently
moparisthebestyou probably don't want to specify what exactly they should say, maybe you could just specify they should inform the user in some way?
Ge0rGwhat about sending an error back?
Ge0rGthough what do you do if a client (of multiple) just doesn't have the right key?
Ge0rGFlow: by not having the redundancy, one could prevent the existence of these border cases.
FlowGe0rG: 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
moparisthebestand they could *get* the key later, due to the nature of pgp
moparisthebestlike I set up conversations on a new phone and haven't set up openkeychain yet
Ge0rGsending an error as a response to a malformed message doesn't seem too far-reached
moparisthebestand do you still send the error back when you are retrieving with MAM ?
FlowGe0rG: 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
moparisthebestor do all your devices receiving the carbon send messages?
FlowSo it's not about removinga border case, but about having a fail safe for this case
moparisthebestthere 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
Ge0rGFlow: 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
boothj5has left
Ge0rGthe timestamp is redundant as well.
FlowYep
Ge0rGso a client may receive a message with three (different) timestamps. XEP-203, openpgp and <time>
Ge0rGwhich one do you display?
FlowI would display <time>
Alexhas left
xnyhpsGe0rG: And possibly timestamps added by multiple different servers. ;)
Flowxnyhps: Which remindes me, I wanted to reply to your latest mail on standards@
xnyhpsTimestamps are quite messy because it's not easy to say who to trust in general.
FlowI'd be interested in persuing the added:by approach
FlowAnd from what I can read, daniel too
FlowI'd like to hear from some more server guys what they think about it
FlowI believe most of the business rules from xep359 could go into the added:by xep
mathieuihas joined
Tobiashas joined
xnyhpsFlow: Some of them, yeah
xnyhpsStill not sure the complexity is really worth it.
Flowxnyhps: That's basically why I didn't replly initially
xnyhpsMy 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.
intosi has joined
intosi has left
intosi has joined
Tobiashas joined
dwdhas left
intosi has left
intosi has joined
Holgerhas left
dwdhas left
Holgerhas joined
dwdhas left
edhelashas left
intosi has left
intosi has joined
edhelashas joined
intosi has left
intosi has joined
ralphmhas left
dwdhas left
Link MauveFlow, 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).
Alexhas joined
tim@boese-ban.dehas left
ralphmhas left
waqashas left
SamWhitedhas left
xnyhpshas left
intosi has joined
winfriedhas left
waqashas joined
Martinhas left
FlowLink Mauve: Hmmm, undecided, I personally don't think it is necessary
Flowbut patches welcome :)
FlowXMPP-IM neither specifies what to do when a message with two <body/> arrives
Flow(or maybe it does and I don't remember)
dwdhas left
bjchas joined
foss81405971has joined
intosi has joined
Jake1984has joined
Ge0rGFlow: "For example, direct child elements found in either <signcrypt/>, <sign/> and <crypt/> could be:
" <- shouldn't that read "For example, <payload/> child elements..."?
FlowGe0rG: Thanks, that is a leftover from the attribute to elements migration
Flowfixing right now
Ge0rGFlow: also s/my/by/ in the §8.3 text
Flowfixed
intosi has joined
intosi has left
intosi has joined
Ge0rGFlow: the link from §6.1 to http://tools.ietf.org/html/rfc4880#section-5.5.2 talks about key packets, not about message formats
Flowhas joined
Holgerhas left
Holgerhas joined
foss81405971has joined
Holgerhas joined
Tobiashas joined
intosi has joined
Ge0rGI hope I didn't kill the OX thread with my long response.
danielhas left
danielhas joined
Tobiashas joined
danielhas left
danielhas joined
Link MauveGiven the date, I’d even say the opposite. :)
danielhas left
danielhas joined
fippohas joined
Ge0rGLink 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
dwdhas left
dwdhas left
foss81405971has joined
Lancehas joined
dwdhas left
lloydhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
moparisthebesthas left
soulhas left
SouLhas left
ThUnD3r|Gr33nhas joined
mathieuihas joined
mark.erdhas joined
mathieuihas left
mathieuihas joined
mark.erdhas left
ralphmhas left
mark.erdhas joined
SouLhas left
mark.erdhas left
intosi has joined
SouLhas left
SouLhas joined
Holgerhas left
dwdhas left
Lancehas joined
Lancehas joined
Lancehas joined
Lancehas joined
intosi has left
intosi has joined
soulhas joined
Holgerhas joined
waqashas left
waqashas joined
Tobiashas joined
Flowhas joined
dwdhas left
dwdhas left
Tobiashas left
dwdhas left
FlowGe0rG: it's just an example of packets where v4 must be used. The most important one, but just an example
XSF Discussion - 2016-01-21