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?
Tobiashas joined
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
Alexhas joined
mathieui
afaik the profanity dev is boothj5, and he’s not here
Kevhas left
Kevhas left
bjchas left
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?
Steffen Larsenhas joined
Flow
because we encode the OpenPGP message
Ge0rG
"This string MUST represent ..." maybe "correspond to" would be a better wording.
Steffen Larsenhas left
intosi has joined
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
boothj5has joined
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
boothj5has left
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>
Alexhas left
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
mathieuihas joined
Tobiashas joined
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.
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 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).
Alexhas joined
tim@boese-ban.dehas left
ralphmhas left
waqashas left
SamWhitedhas left
xnyhpshas left
intosi has joined
winfriedhas left
waqashas joined
Martinhas left
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)
dwdhas left
bjchas joined
foss81405971has joined
intosi has joined
Jake1984has joined
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
intosi has joined
intosi has left
intosi has joined
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
Flowhas joined
Holgerhas left
Holgerhas joined
foss81405971has joined
Holgerhas joined
Tobiashas joined
intosi has joined
Ge0rG
I hope I didn't kill the OX thread with my long response.
danielhas left
danielhas joined
Tobiashas joined
danielhas left
danielhas joined
Link Mauve
Given the date, I’d even say the opposite. :)
danielhas left
danielhas joined
fippohas joined
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
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
Flow
Ge0rG: it's just an example of packets where v4 must be used. The most important one, but just an example