Re: [Standards] EAX

[Daniele Ricci]

I found it in the spam folder. Thank you and sorry for the off-topic :-)

On Tue, Mar 12, 2019 at 7:41 PM Wiktor Kwapisiewicz  wrote:
>
> On 12.03.2019 19:17, Thilo Molitor wrote:
> > (...) Wiktors mails delivered through mailinglists will be dropped into
> > the spam folder by the receiving side or ignored at all.
>
> This varies from mailing list to mailing list.
>
> For example some IETF Mailing Lists (e.g. OpenPGP) when mangling the
> e-mail they also change "From" header so that there is no issue with the
> DKIM signature.
>
> https://lists.sr.ht/ uses a different approach - they leave the mail
> unmodified, just append List-* headers and relay it to all subscribers.
> This way the mail still passes DKIM checks. (Example: click "details" on
> this thread [0]).
>
> Kind regards,
> Wiktor
>
> [0]:
> https://lists.sr.ht/~sircmpwn/sr.ht-dev/%3C20190108111256.9088-1-wiktor%40metacode.biz%3E
>
> --
> https://metacode.biz/@wiktor
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___



-- 
Daniele
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] EAX

[Daniele Ricci]

Did I lose the email by Wiktor? Or did he replied to you only?

On Tue, 12 Mar 2019, 18:19 Evgeny,  wrote:

> On Tue, Mar 12, 2019 at 8:17 PM, Evgeny  wrote:
> > Yeah, my protoXEP allows for instant certificate issuance without
> > challenges [1]
>
> Oops, forgot the link:
> http://upload.zinid.ru/xep-eax-cir.html#cert-issuance
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Extending XEP-0085 Chat State Notifications, again

[Daniele Ricci]

FWIW, I second that. I'm using a custom extension for now, but I'd really
like to see this standardized. The type attribute is a nice idea.

On Fri, 1 Mar 2019, 09:50 Sergey Ilinykh,  wrote:

> I like the addition.
>
> Best Regards,
> Sergey
>
>
> пт, 1 мар. 2019 г. в 11:36, Ненахов Андрей  >:
>
>> This was discussed in July 2018 and, I guess, moved nowhere, but I'll
>> raise the issue once again. Any decent messenger bar XMPP based ones have
>> capabilities to signal type of user activity beyond just "composing a
>> message", but also "recording voice message", "recording video message",
>> "uploading file", 
>>
>> We NEED that in our clients, and, subsequently, we'd prefer it to be an
>> XMPP standard.
>>
>> So far we've extended XEP-0085 by adding a "type" attribute to
>>  element:
>> >from='berna...@shakespeare.lit/pda'
>>to='franci...@shakespeare.lit/elsinore'
>>type='chat'>
>> 
>> 
>>
>> Works OK by us and it does not break any clients with XEP-0085 that we
>> know of.
>>
>> However, last time when this matter was raised, there were objections
>> that 0085 is 'final' and therefore we can't change anything because of
>> reasons and was essentially discarded. Hope this time it'll be different.
>>
>> --
>> Andrew Nenakhov
>> CEO, Redsolution, Inc.
>> https://redsolution.com 
>> ___
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: standards-unsubscr...@xmpp.org
>> ___
>>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0384: encrypt stanzas

[Daniele Ricci]

Hi,
I noticed that the OMEMO XEP, at section 4.7, states:

"If the OMEMO element contains a , it is an OMEMO message
element. [...] If it succeeds, the decrypted contents are treated as
the  of the received message."

Unless I missed something, the XEP allows only for encrypted text from
the .
What if I want to encrypt a whole stanza, e.g. for including other
information such as delivery receipt requests, out-of-band data, or
anything else that might be worthy of encryption.

I could just feed the XML string to the OMEMO library and then parse
the XML on the other side, but - besides probably being not compatible
with the implementations currently out there - I'd like to know how
this could be addressed in XEP compliance terms.

Thank you
-- 
Daniele
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Daniele Ricci]

On Mon, Jan 16, 2017 at 11:18 AM, Kevin Smith  wrote:
> Just jumping in on the point of ‘standards…simply do not exist’ is very much 
> untrue for the client certificate auth point above.

Indeed, just lack of clients implementing it (IIRC there are just 1 or
2 clients capable of doing that, besides Kontalk).
Our implementation is a bit "custom" anyway:
https://github.com/kontalk/tigase-kontalk/blob/master/docs/server-internals.md#pgp-key-based-authentication

*Some* of those other extensions are described here:
https://github.com/kontalk/specs
(sorry, some stuff is still WIP)

-- 
Daniele
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Multi-stage registrations

[Daniele Ricci]

I've been using data forms for this [1] (sorry the spec doesn't
describe instruction forms, but you get the idea), IMHO I think it's
better than using hard-coded fields. I'd deprecate the hard-coded
field altogether.

[1] https://github.com/kontalk/specs/blob/master/register.md

On Wed, Feb 3, 2016 at 4:32 PM, Stephen Paul Weber
 wrote:
> This is in the context of transports, but could apply to account
> registration as well.  Sometimes one needs multiple steps in a registration
> process, usually because of an out-of-band verification that needs to happen
> (think: you give me phone number, I sms you a code, you give me the code.  I
> need your phone number in order to send you the code, but now you've
> submitted the form already)
>
> This is not a theoretical use case, I am using the below with a transport
> that I am implementing right now.
>
> Strawman proposal: new XEP that allows XEP-0077 iq results to return a new
> set of fields and/or data form.  Supporting clients see this form in the
> result and display to the user as per usual.  Non-supporting clients report
> "success" because they ignore the form, and the user can re-initiate
> registration with the entity to resume mid-flow.
>
> Example flow for transport registration use case with SMS verification:
>
> == Entity Requests Registration Fields from Host ==
>
> 
>   
> 
>
> == Host Returns Registration Fields to Entity ==
>
> 
>   
> 
>   We will send you a code to verify your phone number.
> 
> 
>   
> 
>
> == Entity Provides Required Information ==
>
> 
>   
> 1555
>   
> 
>
> == Host Informs Entity of More Fields Needed ==
>
> 
>   
> 
>   Enter the code you received via SMS
> 
> 
>   
> 
>
> == Entity Provies Further Information ==
>
> 
>   
> 123456
>   
> 
>
> == Host Informs Entity of Successful Registration ==
>
> 
>
> --
> Stephen Paul Weber, @singpolyma
> See  for how I prefer to be contacted
> edition right joseph
>
> ___
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>



-- 
Daniele
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Multi-stage registrations

[Daniele Ricci]

It depends on what we want to standardize:

1. data form fields (as in field names and/or multi-stage registration
workflow?)
2. new top level elements (much like username and password <-- there
should be kept for backwards compatibility of course, but adding new
ones... I don't know)

I have to say multi-stage registration is very unpredictable (e.g.
registration through SMS, OTP device, public key, and who knows what
else), so it would be hard to write a standard flexible enough IMO.
What do you suggest?



On Wed, Feb 3, 2016 at 4:53 PM, Stephen Paul Weber
 wrote:
>> https://github.com/kontalk/specs/blob/master/register.md
>
>
> This appears to be identical to my proposal, which gives me hope.  (Data
> forms are certainly supported by XEP-0077 already, and would of course be
> used more likely than the old fields on moders clients.  I think both should
> be supported by servers for compatability, but this is not really relevant
> to the particular issue of multi-stage support.)
>
> So it seems there is more need in the world than just mine, and two
> independently-developed but identical solutions.  Should we write up a
> "real" XEP?
>
>
> --
> Stephen Paul Weber, @singpolyma
> See  for how I prefer to be contacted
> edition right joseph



-- 
Daniele
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Multi-stage registrations

[Daniele Ricci]

On Wed, Feb 3, 2016 at 5:07 PM, Stephen Paul Weber
 wrote:
> I'm only proposing that multi-stage be supported.  What fields are sent and
> how the server interprets them will of course depend on what sort of
> registration is being done, but that seems out of scope (and likely not
> needed in most cases).
>

Oh ok, sorry I got it now.

Do you think producing a new version of XEP-0077 would be fine? Is
that possible by the way since it's a final standard (sorry I'm not
much of an expert on XEP drafting)?

-- 
Daniele
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0363 and Message MIME content type

[Daniele Ricci]

There wasn't much interest I think. But I have to say that I didn't
take the initiative either :-)
http://mail.jabber.org/pipermail/standards/2013-September/027992.html

On Fri, Jan 29, 2016 at 5:38 PM, Anurodh Pokharel  wrote:
> Hi all,
>  In the process of implementing XEP-0363  (HTTP file uploads
> http://xmpp.org/extensions/xep-0363.html) in Monal, I've come to the
> realization that it would make a lot of sense to include MIME content type
> and size in the message stanza.  I've done a bit of searching and I haven't
> found any XEP that defines this behavior.  If any of this sounds like it's
> already been done, please point me in the right direction.
>
> Essentially as I understand it, the issue is HTTP file uploads are designed
> to solve the problem of people using dropbox or some other third party cloud
> service and replace that with an XMPP server that performs all of this
> internally.  This is great but simply posting a link to an image or video
> alone isn't very useful to the recipient. One way of resolving this is to
> have the receiving client present the link or preform an HTTP HEAD call  to
> try to determine the media type and based on the response try to display the
> content inline. The problem here are there is nothing in the spec that
> requires the server serving the "attachment" to  support HEAD.  There is no
> guarantee that every HTTP configuration would allow this call.
>
> At the moment, on the client, we would have to scrape the URL to try to
> determine the media type (audio, video, image etc). While HEAD solves the
> problem,  I believe rather than require HEAD support, it may make sense to
> include the content type and size in the message stanza that has the URL of
> the uploaded file. This would be the same data passed to the server in the
> upload request.  HEAD would require 2 HTTP calls, first the HEAD to
> determine MIME  content type and and size and the second GET to fetch the
> actual media  The sender is aware of both the type and size and this allows
> the receiver to determine several things from the message stanza it self:
>
> 1. Is it a format that can be displayed inline?
> 2. Is the file small enough to download automatically? In particular, this
> is a concern for mobile users.
> 3. Is the file in a format that can can be streamed rather than kept in a
> local cache? This would make sense for audio and video.
>
> There are certain security considerations. Auto downloading content to
> display inline must require the receiver to trust/know the sender to prevent
> abuse (spam, web bugs to expose IP). Additionally, any decisions to download
> content based on the content size assumes the sender is honest about size.
>
>
> Thanks,
> -Anu
>
>
> ___
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>



-- 
Daniele
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Chat Markers vs. Delivery receipts

[Daniele Ricci]

On Mon, Jan 18, 2016 at 4:26 PM, Sam Whited  wrote:
> Chat markers and delivery receipts are orthogonal concepts. Chat
> markers are meant for determining if a client has viewed the current
> chat (or performed some action, eg. composing a message), while
> delivery receipts only show that a message has been delivered to your
> contacts client (and don't make any guarantees that they've actually
> seen the message).

Do you mean that a delivery receipt is the same as a "received" chat
marker sent for every message? Have I got this right?

> To illustrate, imagine you send a message that gets lost (but no error
> is returned) and is never delivered to your contact. Then they bring
> their conversation with you to the foreground and start composing a
> message. If you're only using chat markers, it will appear as if your
> contact has read your last message, but in reality it was never
> delivered to them.

Ok, so to best optimize the use of chat markers (and to save
bandwidth), I would have to wait a little bit for a batch of messages
to arrive and then send out a displayed notification for all of them
(assuming the user has displayed all of those at a time).
However, delivery receipts are still sent sequentially as soon as
messages arrive.

If I got this "batching" optimization right, can't I just use a chat
marker "received" notification for *every* message instead of a
delivery receipt? I could even use "displayed" notification as a bonus
(that is, it is implied that if you display a message you must have
received it, this way I send just one marker instead of two).

Best
-- 
Daniele
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Chat Markers vs. Delivery receipts

[Daniele Ricci]

Hello,
I'm implementing read notification (as in "displayed"), and I'm
wondering whether to use chat markers. Up to now I've been using
delivery receipts for, well, delivery notification. Now I'd like to
move one step further and support displayed notification too.

My question is: considering that my server stores delivery receipts
too, what is the real advantage of chat markers over delivery
receipts, besides supporting two more states (displayed, acked)? Am I
missing something from the XEP?
Also, I was surprised when I read "Chat Markers MAY be used alongside
Delivery Receipts", since they actually overlap, right?

Thanks
-- 
Daniele
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] OpenPGP and XEP-0027

[Daniele Ricci]

Hello Goffi,
XEP-0027 has serious security concerns, especially regarding reply
attacks and key verification (you can read those in the Security
considerations paragraph of the XEP). It's true that a real
replacement hasn't been drafted yet (there are some drafts, but
nothing really definitive or practical to use).
In my project I use a modified version of XEP-0027, using XEP-0189 for
key management (supervised by the server). I took an example from an
e2e RFC draft (I really can't remember the number now, sorry), which
used Message/CPIM to enforce message metadata inside the encrypted
content. That's a bit more secure than plain XEP-0027, still there are
many other attack vectors that can be used. I'll probably draft a XEP
one day.

As for making XEP-0027 obsolete, that XEP is just informative: it's
the description of a protocol that was never standardized and as I
said it had security issues from the beginning. But at the time,
security was a different thing ;-)


On Fri, Jul 31, 2015 at 10:16 AM, Goffi go...@goffi.org wrote:
 G'day,

 I have a few questions about OpenPGP. XEP-0027 has been obsoleted by council
 on 26/03/2014, but I can't see no explanation.

 OpenPGP is not the best for instant messaging (and OTR is the de facto
 standard), but still it's interesting for normal messages (e.g. with an SMTP
 gateway), and signatures, and offline messages, and probably other use
 cases.
 In addition, it would be nice to have a way to link the public key.

 So why OpenPGP has been obsoleted ? Is is still possible to see it coming
 back throught eventually a new more proper XEP ? I don't mean use it as the
 main e2e encryption model, but being able to use it with gateways or to
 diffuse the public key seems important to me.

 Thanks
 Goffi



-- 
Daniele

[Standards] Source control links

[Daniele Ricci]

Just wanted to notify that the link for the Git mirror is outdated:
http://xmpp.org/about-xmpp/xsf/xsf-source-control/

I think you've migrated to GitHub, right?

-- 
Daniele

Re: [Standards] Proposed XMPP Extension: HTTP File Upload

[Daniele Ricci]

On Thu, Jul 30, 2015 at 12:19 PM, Sergey Dobrov bin...@jrudevels.org wrote:
 While I'm very interested in an infrastructure that's fully XMPP-driven, I'm
 But again, I don't want to look like an advocate of utilizing HTTP, I really
 think it would be much greater to have XMPP infrastructure, but how can we
 motivate someone to implement that?


I can understand how administrators (and companies in general) will
not choose XMPP if it's an almighty protocol handling all of their
requirements. An optimal infrastructure is made up of many protocols
working together. In many cases, HTTP may and can be useful IMHO. But
I don't want to repeat other people's arguments about that.

-- 
Daniele

Re: [Standards] Move CSI to Last Call (Proposed)

[Daniele Ricci]

I for one using it in my project Kontalk. It saved me so much energy and
bandwidth, in its simplicity it's very useful.

Daniele
On 28 Jul 2015 08:59, Matthew Wild mwi...@gmail.com wrote:


 On 27 Jul 2015 22:31, Sam Whited s...@samwhited.com wrote:
 
  Hi all,
 
  I'd like to propose that the Council vote to move XEP-0452: Client
  State Indication into last call (the Proposed State), and then
  hopefully into draft afterwards.
 
  The XEP has been sitting dormant since it was last updated almost a
  year ago (2014-08-28), but this is not due to its being abandoned. It
  is being actively used in clients. The XEP is simple and does the job
  it was made to do (and no more). In my opinion the XEP is ready for
  advancement to last call, and I'd like to request that the council
  take up this issue as soon as possible.

 Out of curiosity,  what clients do you know of that are using it?

 Regards,
 Matthew

Re: [Standards] Proposed XMPP Extension: Push

[Daniele Ricci]

I was just waiting for this :-)
Thanks to Lance and everyone that contributed to the push XEP. I'll
start experimenting with it in a few days and eventually comment the
XEP itself if I bump into practical problems.


On Mon, Mar 2, 2015 at 10:46 PM, XMPP Extensions Editor edi...@xmpp.org wrote:
 The XMPP Extensions Editor has received a proposal for a new XEP.

 Title: Push

 Abstract: This specification defines a way for an XMPP servers to broadcast 
 information for use in push notifications to mobile and other devices.

 URL: http://xmpp.org/extensions/inbox/push.html

 The XMPP Council will decide in the next two weeks whether to accept this 
 proposal as an official XEP.




-- 
Daniele

Re: [Standards] XEP-0184 type attribute on message

[Daniele Ricci]

Thanks Christian,
I think I'll go with matching the type from the original message.


On Sat, Feb 28, 2015 at 6:44 PM, Christian Schudt
christian.sch...@gmx.de wrote:
 I have interpreted and implemented it as „normal, too.

 I have also suggested it to be more clear a year ago here, but unfortunately 
 nobody cared:
 http://mail.jabber.org/pipermail/standards/2014-January/028479.html

 - Christian

 Am 28.02.2015 um 14:43 schrieb Daniele Ricci daniele.ath...@gmail.com:

 Thanks Kurt,
 I can see that smack implementation puts normal. I can't look at other 
 libraries right now, I'll check tomorrow. Anyway I also would like to hear 
 the opinion of the people here.

 Daniele

 On 28 Feb 2015 14:02, Kurt Zeilenga kurt.zeile...@isode.com wrote:

  On Feb 28, 2015, at 3:27 AM, Daniele Ricci daniele.ath...@gmail.com 
  wrote:
 
  Hello people,
  I'm reading XEP-0184 and I can't find any indication of what I should
  put into the type attribute of delivery receipt stanzas (that is, with
  received/ inside). Should I leave it empty (defaulting to normal)
  or should I use the type of the original message?

 At least in the groupchat case, you must match the message type.  It’s not 
 clear to me whether generally matching the type is generally best.

 — Kurt




-- 
Daniele

[Standards] XEP-0184 type attribute on message

[Daniele Ricci]

Hello people,
I'm reading XEP-0184 and I can't find any indication of what I should
put into the type attribute of delivery receipt stanzas (that is, with
received/ inside). Should I leave it empty (defaulting to normal)
or should I use the type of the original message?

Thanks
-- 
Daniele

Re: [Standards] XEP-0184 type attribute on message

[Daniele Ricci]

Thanks Kurt,
I can see that smack implementation puts normal. I can't look at other
libraries right now, I'll check tomorrow. Anyway I also would like to hear
the opinion of the people here.

Daniele
On 28 Feb 2015 14:02, Kurt Zeilenga kurt.zeile...@isode.com wrote:


  On Feb 28, 2015, at 3:27 AM, Daniele Ricci daniele.ath...@gmail.com
 wrote:
 
  Hello people,
  I'm reading XEP-0184 and I can't find any indication of what I should
  put into the type attribute of delivery receipt stanzas (that is, with
  received/ inside). Should I leave it empty (defaulting to normal)
  or should I use the type of the original message?

 At least in the groupchat case, you must match the message type.  It’s not
 clear to me whether generally matching the type is generally best.

 — Kurt

Re: [Standards] OTR

[Daniele Ricci]

Hello everybody,
referring to commit:
https://github.com/winfried/XMPP-OTR/commit/76a5cf06a3728e042740c0e30ba535e55b2613a8

I know it's still work in progress, but I want to start from there to
say my two cents.
I think encrypting the whole stanza can be avoided in some cases.
Also, the only stanza type that has sense to be encrypted with OTR is
message/. Therefore, I'd distinguish between two specific cases:

* encryption of message body: just include the encrypted message body
in the otr/ element as a child of message/
* encryption of whole stanza (for other purposes or for complex
messages): encrypt the whole stanza and encapsulate the OTR content in
an otr/ element as a child of message/

The only problem here is how to recognise the encrypted data? Is it a
text body or a stanza? Maybe we can use a type attribute to otr/,
revealing more metadata? Or maybe we could add a header to the
encrypted data:

-8---
Content-type: text/plain

message body
-8---

-8---
Content-type: application/xmpp+xml

message ...
 
/message

What do you think?


On Tue, Feb 3, 2015 at 11:07 AM, Winfried Tilanus winfr...@tilanus.com wrote:
 On 03-02-15 11:03, Ralph Meijer wrote:
 Sure it will be short. However, some notes on limitations and security
 considerations would also need to be added. If only to make it easier to
 compare against other e2e proposals. If you want to make a start with a
 XEP, that's appreciated.

 https://github.com/winfried/XMPP-OTR

 If you give me your github name, I will give you write access ;-)

 Winfried



-- 
Daniele

Re: [Standards] OTR

[Daniele Ricci]

Of course, I was just talking about a deterministic way of describing the
encrypted data - and to save bandwidth.

Anyway the point of metadata leakage is valid. We (as in XMPP) do what we
can and we encrypt what we can. Anonymity was never the scope of XMPP.

Daniele
On 3 Feb 2015 12:59, Bartosz Małkowski bmalkow...@tigase.pl wrote:


  Wiadomość napisana przez Daniele Ricci daniele.ath...@gmail.com w
 dniu 3 lut 2015, o godz. 12:20:
 
  The only problem here is how to recognise the encrypted data? Is it a
  text body or a stanza? Maybe we can use a type attribute to otr/,
  revealing more metadata? Or maybe we could add a header to the
  encrypted data:

 I don’t understand.

 If client receives messageotr…
 then it will decrypt data and expect that result of decryption is stanza
 (or maybe other element allowed in XMPP Stream), then client will process
 received and decrypted element like any other received elements.

 Look at https://tools.ietf.org/html/draft-miller-xmpp-e2e-02 (4.3.
 Example - Securing a Message). The same idea.

 --
 Bartosz Małkowski
 Tigase Polska
 xmpp:bmal...@malkowscy.net

[Standards] Server-assisted message receipts

[Daniele Ricci]

Hello everyone,
I'd like to propose a new XEP or possibly a change to an existing one.
My purpose is to draft something between AMP [1] and delivery receipts
[2], for message stanzas only, designed to give developers and server
administrators a simple tool for making sure messages are delivered
between client and server and between servers.

I'm currently using my own XEP described here [3] for my own project,
but I'd like to extend XEP-0184 to support two more tags:

sent/
This is used by the server to indicate clients (or another server)
that the message has been accepted and queued for delivery. An id
attribute in this tag will identify the message with a
server-generated unique ID.

ack/
This is sent by the server to acknowledge that the received/ stanza
has been accepted and the delivery receipt is being delivered.
This may also be sent by the client to acknowledge that the
received/ stanza was received correctly. The id attribute will be
filled with the stanza id from the received/ stanza.

Matching of request-reply (e.g. request-sent pair) in every step shall
be done using the stanza ID attribute.

I don't want to complicate things, I just want to give people and
myself a simpler choice that does not involve the complexity of AMP or
the ubiquitous approach of stream management [4].

Thanks to anyone willing to comment this.
Regards
-- 
Daniele

[1] http://xmpp.org/extensions/xep-0079.html
[2] http://www.xmpp.org/extensions/xep-0184.html
[3] https://github.com/kontalk/specs/wiki/XMPP-extensions#server-receipts
[4] http://xmpp.org/extensions/xep-0198.html

[Standards] One more CSS responsive hack

[Daniele Ricci]

Hello,
I've just created a merge request for a new modification:
https://gitorious.org/xmpp/xmpp/merge_requests/4

Very useful for reading XEPs from mobile phones.
Details are in the merge request description.

Cheers
-- 
Daniele

Re: [Standards] Cleaning the Wiki

[Daniele Ricci]

I'd like to also point out that the SSL certificate is not valid for
the host name wiki.xmpp.org, thus leading to browser certificate
errors.

Regards

On Mon, Sep 1, 2014 at 4:06 PM, edhelas edhe...@movim.eu wrote:
 Hi,

 I'm currently looking at our official Wiki (https://wiki.xmpp.org/) and
 there's a couple of things that need to be cleaned.

 On the main page, the XMPP technologies panel :
 - The Client/Server list in https://wiki.xmpp.org/web/Tech_pages/BOSH need
 to be updated (last change 2010)
 - Same for the Jingle page https://wiki.xmpp.org/web/Tech_pages/Jingle (last
 change 2010)
 - Same for the Pubsub page https://wiki.xmpp.org/web/Tech_pages/PubSub (last
 change 2010)

 - We can delete the https://wiki.xmpp.org/web/Tech_pages/Reliability page
 (empty, never changed)
 - Same for https://wiki.xmpp.org/web/Tech_pages/Privacy
 - Same for https://wiki.xmpp.org/web/Tech_pages/Admin
 - Same for https://wiki.xmpp.org/web/Tech_pages/Disco

 - The page https://wiki.xmpp.org/web/XMPP_URIs need to be seriously updated
 or deleted (last change 2010)

 Furthermore I really think that we need to create several pages like
 https://wiki.xmpp.org/web/PubSubIssues to list all the issues and we find in
 the related XEP. On the mailing list we easily loose the emails that talked
 about theses issues in our history.

 By listing all all of them with a clear explanation and where exactly it
 appear in the XEP we will be able to really track them and fix them during
 the meetings :)

 Or maybe we can use a bugtracker for that ?

 Also, it would be nice to have a system that give us a clear overview of
 which client and server implement each XEP. I know that the work is huge but
 maybe with tools that use the Disco/Caps system we will be able to fill
 theses informations easily.
 And because an implementation status is not a boolean we have to list all
 the stuffs that are not well implemented in the clients/server with (if
 possible) a link to their bugtracker.

 All theses stuffs will help us to have a clearer idea of where we are and
 what we have to do for the the future.

 Regards,

 Jaussoin Timothée aka edhelas



-- 
Daniele

Re: [Standards] SMS/Email Forwarding of Messages

[Daniele Ricci]

Hello Spencer,
what about extending [1] XEP-0297 [2] to include something to
enable/disable automatic forwarding?

[1] by extending I mean either improving that one or writing another
one which uses XEP-0297
[2] http://xmpp.org/extensions/xep-0297.html

On Mon, Feb 17, 2014 at 2:47 PM, Spencer MacDonald
spencer.macdonald.ot...@gmail.com wrote:
 Is there any XEP that covers a message getting forwarded using another 
 transport e.g. SMS, Email?

 If not would there be any interest in making a standard one?

 My personal use case is if the recipient is offline, the message can be 
 forward to their phone as an SMS.

 Regards

 Spencer



-- 
Daniele

[Standards] xmpp.net test SSL trust

[Daniele Ricci]

Hello,
am I wrong or do I get that CACert [1] certificates are not trusted by
the test tool at xmpp.net?

[1] http://www.cacert.org/

-- 
Daniele

Re: [Standards] xmpp.net test SSL trust

[Daniele Ricci]

(I'm sorry what is the right list?)

I understand what you mean... maybe the test tool can be tuned so that
a CACert get less points than e.g. Verisign, but a score of zero is
very unkind :-) I mean there are desktop configurations that have
CACert installed (e.g. 99% of Linux distributions).

On Thu, Feb 6, 2014 at 10:45 AM, Dave Cridland d...@cridland.net wrote:
 On Thu, Feb 6, 2014 at 9:40 AM, Daniele Ricci daniele.ath...@gmail.com
 wrote:

 Hello,
 am I wrong or do I get that CACert [1] certificates are not trusted by
 the test tool at xmpp.net?

 [1] http://www.cacert.org/


 Not that this is really the right list, but you're right.

 I believe Thijs wanted to mimic the normal desktop trust anchors (ie, CA
 selection), so that a fresh, ordinary user would have the same set of CAs on
 their machine.

 Whatever *we* might think of CACert, that seems a reasonable definition.

 Dave.



-- 
Daniele

Re: [Standards] xmpp.net test SSL trust

[Daniele Ricci]

I think I understand why... my server has no direct TLS port, just
STARTTLS. Is the certificate tested via STARTTLS as well?

On Thu, Feb 6, 2014 at 10:50 AM, Tobias Markmann
tmarkm...@googlemail.com wrote:
 Hi,

 On Thu, Feb 6, 2014 at 10:40 AM, Daniele Ricci daniele.ath...@gmail.com
 wrote:

 Hello,
 am I wrong or do I get that CACert [1] certificates are not trusted by
 the test tool at xmpp.net?

 [1] http://www.cacert.org


 CACert certificates seem to be trusted, at least jabber.ccc.de uses them and
 the tool shows no issues in that regard.

 https://xmpp.net/result.php?domain=jabber.ccc.detype=server#certificates

 Cheers,
 Tobias



-- 
Daniele

Re: [Standards] Push notification XEP

[Daniele Ricci]

Sorry for the late reply Lance.
That was what I was missing The client app sends an IQ
to its backend service, registering a device ID. And this can happen
because the CBS is connected to the user's server in some way (the
CBS can verify the user's server).

For the rest, the diagrams are very clear, and I can begin
implementing it in Kontalk [1], possibly as a standalone component, as
soon as it reaches a more-or-less stable status.

Did you have any chance to discuss it in person at FOSDEM? How's going
there by the way?


[1] http://www.kontalk.org/

On Mon, Jan 27, 2014 at 9:16 PM, Lance Stout lancest...@gmail.com wrote:
 I tried writing up an explanation, but it ended up rather long-winded and 
 confusing to follow. So I made some diagrams instead :)

 https://cloudup.com/c223kt48cGZ

 The flows presented there modify what I have in that write-up to make some 
 things simpler. Let me know if there are areas that need
 more fleshing out for explanation, or if your questions weren't fully 
 addressed.


 — Lance



-- 
Daniele

Re: [Standards] Push notification XEP

[Daniele Ricci]

That's great :-) I'll look forward to read it.

Daniele
On 2 Feb 2014 15:00, Lance Stout lancest...@gmail.com wrote:

  Did you have any chance to discuss it in person at FOSDEM? How's going
  there by the way?

 Yes, we had quite a bit of good discussion on this topic at the summit,
 and now that I have all of the notes I will have an updated Push XEP
 proposal out in a few days.

Re: [Standards] Push notifications

[Daniele Ricci]

I wish I was there... :-(
I'll reply to Lance mail as soon as I find 10 minutes straight (thank
you for your very clear picture of the XEP by the way).

On Fri, Jan 31, 2014 at 11:32 AM, Simon Tennant si...@buddycloud.com wrote:
 Interesting conversations about push today.

 This is how we do it (curently) at buddycloud to send someone followed you
 new posts in your channel etc.

 https://github.com/buddycloud/buddycloud-pusher/blob/master/README.md

 Keen to standardise.

 S.
 --
 Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours:
 goo.gl/tQgxP



-- 
Daniele

Re: [Standards] Push notification XEP

[Daniele Ricci]

On Tue, Jan 21, 2014 at 10:44 PM, Lance Stout lancest...@gmail.com wrote:
 So I install Otalk on my phone, and establish a connection to my own server, 
 lance.im.
 The Otalk client detects that lance.im supports the push extension via 
 disco/caps.
 The Otalk client then registers the 'push.otalk.im' endpoint (which the Otalk 
 client
 knows about because it's hardcoded) as a recipient for push notifications for
 la...@lance.im on lance.im. Included in that registration MAY be some ID value
 that the Otalk client provides, which is completely opaque and only intended 
 for
 use by 'push.otalk.im' as the registered endpoint. (Eg, the Otalk client app 
 could
 request an ID value from its backend server that associates 'la...@lance.im' 
 with a
 device id/token before starting the registration process at lance.im.)


Hi Lance,
that's what I was talking about: that opaque ID is the device token
which must reach the push notification component, otherwise it
wouldn't know how to send the push notification request to the
proprietary server (e.g. GCM).
If I got it right, it's in the id attribute of the register/
element so, I didn't notice it at first. And, if I got this right too,
this sentence should be expanded: MAY specify an opaque id attribute
that the receiving service MAY use to target that specific device when
using stream management adding something like or when sending a push
notification to the proprietary service or something like that.

Can you please explain this: When set to client, the recipient will
receive a notification only when there are no online connections that
have specified the same recipient.

Also you say in your e-mail it's up to the app's backend service to
forward that notification over its preferred proprietary push service
to the installed app on some device. Are you saying that the client
has to connect to the push notification proprietary service instead of
the server doing it?

-- 
Daniele

[Standards] Push notification XEP

[Daniele Ricci]

Hello list,
I was thinking of writing a XEP for sending a sender ID (Google Cloud
Messaging) or a device token (Apple Push Notification Service) or any
other push notification service token (that is, a generic one) to the
server.
Almost all push notification services works the same way: the server
provides a provider ID to the client and the client provides a device
token to the server.

I was thinking of using service discovery to advertise the service
from a server:

iq from='example.com' type='result' id='H-2' to='al...@example.com'
  query xmlns='http://jabber.org/protocol/disco#items'
node='http://jabber.org/extensions/presence#push'
item node='SENDER-ID' jid='gcm.push.example.com' name='Google
Cloud Messaging'/
item node='PROVIDER-ID' jid='apns.push.example.com' name='Apple
Push Notification Service'/
item ... /
 /query
/iq

In the node attribute I'd put the provider ID I was talking about earlier.

Device token could be sent using a presence update from the client:

presence
  status.../status
  ...
  c xmlns='http://jabber.org/extensions/presence#push
provider='gcm.push.example.com'REGISTRATION-ID/c
/presence

(that would need to be filtered by the server before broadcasting the
presence update though, for security reasons).

Or an iq to the push notification address could be used:

iq to='gcm.push.example.com'
  token xmlns='http://jabber.org/extensions/presence#push'DEVICE-TOKEN/token
/iq

I'd really appreciate some feedback. I think it would be a useful XEP.
Regards,
-- 
Daniele

Re: [Standards] Push notification XEP

[Daniele Ricci]

I was thinking of a more specific (and simpler) approach to just using
push notification services. Buddycloud is much more than that.

On Tue, Jan 21, 2014 at 11:30 AM, Abmar Barros abma...@gmail.com wrote:
 It sounds like what we've been doing with the buddycloud pusher:
 https://github.com/buddycloud/buddycloud-pusher.

 We currently use it to send GCM and emails regarding buddycloud-related
 events, as per its documentation, but it can be easily extended to push any
 XMPP event to any pusher service, eg.: Apple's, SMS.

 Regards,
 Abmar


 On Tue, Jan 21, 2014 at 7:58 AM, Daniele Ricci daniele.ath...@gmail.com
 wrote:

 Hello list,
 I was thinking of writing a XEP for sending a sender ID (Google Cloud
 Messaging) or a device token (Apple Push Notification Service) or any
 other push notification service token (that is, a generic one) to the
 server.
 Almost all push notification services works the same way: the server
 provides a provider ID to the client and the client provides a device
 token to the server.

 I was thinking of using service discovery to advertise the service
 from a server:

 iq from='example.com' type='result' id='H-2' to='al...@example.com'
   query xmlns='http://jabber.org/protocol/disco#items'
 node='http://jabber.org/extensions/presence#push'
 item node='SENDER-ID' jid='gcm.push.example.com' name='Google
 Cloud Messaging'/
 item node='PROVIDER-ID' jid='apns.push.example.com' name='Apple
 Push Notification Service'/
 item ... /
  /query
 /iq

 In the node attribute I'd put the provider ID I was talking about
 earlier.

 Device token could be sent using a presence update from the client:

 presence
   status.../status
   ...
   c xmlns='http://jabber.org/extensions/presence#push
 provider='gcm.push.example.com'REGISTRATION-ID/c
 /presence

 (that would need to be filtered by the server before broadcasting the
 presence update though, for security reasons).

 Or an iq to the push notification address could be used:

 iq to='gcm.push.example.com'
   token
 xmlns='http://jabber.org/extensions/presence#push'DEVICE-TOKEN/token
 /iq

 I'd really appreciate some feedback. I think it would be a useful XEP.
 Regards,
 --
 Daniele




 --
 Abmar Barros
 MSc in Computer Science from the Federal University of Campina Grande -
 www.ufcg.edu.br
 OurGrid Team Leader - www.ourgrid.org
 Buddycloud Dev - www.buddycloud.org
 Paraíba - Brazil



-- 
Daniele

Re: [Standards] Push notification XEP

[Daniele Ricci]

Hi everyone,
sorry I won't be at the summit. Any chance FOSDEM stops in Italy? :-)
I can't make any promise, but I'll try to make it for next year.

Your idea [1] seems good to me. A couple of questions:

1. I assume the endpoint is the equivalent of a device token for
APNS and registration ID for GCM
2. I didn't see a way to make the server advertise its provider ID
which is necessary at least for APNS and GCM. Maybe in the discovery
reply stanza?

I still have to study the others (Windows, Blackberry, Symbian?)
because there might be more stuff for the XEP to cover. Let me get
back at you, I'll see what I can find in the developer's reference,
but I doubt they will be that different from Apple or Google.


[1] http://legastero.github.io/customxeps/extensions/push.html

On Tue, Jan 21, 2014 at 7:01 PM, Lance Stout lancest...@gmail.com wrote:
 We discussed precisely this at the last summit. Nobody has actually written a
 XEP yet, it would be great if you're able to write one :)

 I wrote this up to summarize our discussions at the summit and after:
 http://legastero.github.io/customxeps/extensions/push.html

 I've only given a quick look, but it seems similar to the approach that kicked
 off this thread, and to the ideas behind the BuddyCloud push component.


 This is the model we arrived at in October:

 Definitions:
 1) Client app: The thing the user is actually using and interacting with on a 
 device.
 2) Client Backend Service (CBS): A server run by the maintainers of the client
app. The CBS is able to integrate any open/Proprietary Push Notifications 
 to
deliver updates to its associated client apps.
 3) Proprietary Push Notifications: Apple's Push Notifications, Google Cloud 
 Messaging, etc
 4) XMPP Push Service: An XMPP server component/plugin which delivers messages 
 to
a CBS on behalf of a user.

 Goal: Allow a user to have push notification experience using an arbitrary
 third-party Client App with their personal server. Making this possible 
 implies
 that use cases where the Client App and XMPP server are part of the same 
 overall
 system are also possible (eg, a special purpose app that just happens to be
 using XMPP as an implementation detail, not a generic chat application).

 Note: It is the CBS that talks with any Proprietary Push service, not the XMPP
 server itself. This is done because the CBS has private key material that it
 won't share with an arbitrary XMPP server. In many Proprietary Push Services, 
 the
 notification will appear to come from the Client App and Client App 
 developers aren't
 going to give you their private keys so you can enable push for their client 
 on
 your personal server and risk allowing anyone to spoof their notifications.

 So what we end up with is this flow:

 1) User establishes stream using Client App.
 2) Client App discovers that the server has an XMPP Push Service
 3) Client App registers the stream with the push service, indicating an 
 endpoint
for its CBS that will receive the pushed data.
 4) When certain conditions are met (user has no connections, no connection 
 for a
given Client App, a stream in XEP-0198 zombie mode, etc) the XMPP Push 
 Service
sends a to-be-decided update to the CBS.
 5) The CBS can then convert the received update into an open/Proprietary Push
Notification.
 6) The user's device receives a push notification from their Client App.
 *) At any time, the user can view the set of endpoints that are registered to
receive notifications, and remove them.


 There are still things that need to be worked out, namely what does an update
 contain and when exactly do we trigger them.

 The goal is that we provide sufficient use case coverage to heavily discourage
 Client App from deciding to proxy the entire session through its CBS. We have
 seen Client Apps that do this and store user credentials in the CBS to create
 connections at any time, and that behaviour makes me nervous. However, that
 approach is 'simplest' and gives Client App developers the greatest degree of
 control, so this will need a lot of input from existing Client App developers 
 to
 be successful.


 — Lance



-- 
Daniele

[Standards] Suspend incoming presence updates

[Daniele Ricci]

Hello list,
is it possible to suspend presence updates from one or more contacts?
I took a quick look to Privacy Lists [1], could it be used for such a scenario?

Thanks

[1] http://xmpp.org/extensions/xep-0016.html

-- 
Daniele

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Daniele Ricci]

Hi Peter,
I'm working on a mobile IM based on XMPP, I'd like to be there when you
start. Please include me in your list.

Thanks

Daniele
On 30 Oct 2013 14:44, Peter Waher peter.wa...@clayster.com wrote:

  Hello Mark  Dave.

 ** **

 Thanks for the info. I’ve added it to the list of ideas to study before we
 produce the proposal for battery sensors.

 ** **

 As you say, there are various things you might need to think about when it
 comes to battery powered devices. Bandwidth, packet size, memory, cpu (CPU
 drains battery), etc. The most important is battery life time. Many sensors
 might have work for up to 10 years without replacing battery. For this to
 work you also need to take sleeping into account, and how systems interact
 with devices that are only intermittently (albeit regularly) connected to
 the network, etc. Then of course, there’s the problem of bandwidth
 throttling. If a device is in a low power mode (which is a higher state
 than sleep mode), how can you make sure you can still send important
 messages to it?

 ** **

 Anybody interested in these questions, please let me know, and I’ll
 include you when the time comes to start working on the extensions. (People
 who have already expressed their interest are already added to the list.)*
 ***

 ** **

 Best regards,

 Peter Waher

 ** **

 ** **

 *From:* Dave Cridland [mailto:d...@cridland.net]
 *Sent:* den 29 oktober 2013 17:23
 *To:* XMPP Standards
 *Subject:* Re: [Standards] Standard for Throttling/Queueing Stanzas

 ** **

 On Tue, Oct 29, 2013 at 6:41 PM, Mark Rejhon marky...@gmail.com wrote:**
 **

   You might want to peek at:

 http://xmpp.org/extensions/xep-0286.html

 It's deferred, but it also pertains to efficiency for battery powered
 devices.  

 Most of what it says also applies to battery powered sensor, with a few
 modifications.

  ** **

 Mostly it concerns itself with power drain due to 3G radio levels.

 ** **

 I'd imagine that for sensor devices, the memory/bandwidth tradeoffs may be
 different for compression, for example.

Re: [Standards] Out of band: MIME type

[Daniele Ricci]

Hi again,
I see this thread is quite dead now. I simply wanted to ask if it's
worth the effort to dive into the XEP and add such a feature. I will
make the necessary changes myself and submit them to you.

On Wed, Jul 24, 2013 at 10:18 PM, Daniele Ricci
daniele.ath...@gmail.com wrote:
 Hi Peter,
 you mean it would be worth to change XEP-0066 in such a way?

 On Thu, Jul 18, 2013 at 5:34 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 7/18/13 2:42 AM, Daniele Ricci wrote:

 FWIW, even a length attribute could be useful to save an HEAD
 request (always to be considered no more than a hint).

 Yes, we have that in XEP-0096 but not in XEP-0066.

 file xmlns='http://jabber.org/protocol/si/profile/file-transfer'
   name='test.txt'
   size='1022'
   descThis is info about the file./desc
 /file

 Peter

 - --
 Peter Saint-Andre
 https://stpeter.im/


 -BEGIN PGP SIGNATURE-
 Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQIcBAEBAgAGBQJR6Ar2AAoJEOoGpJErxa2p3D8QAJ1egp8HuumsfUWjeAw4I8bM
 Y/qj9RV7GnSo1NnfQoc8L/JaxOX9WqEaMVOH338daQbPExCNwq0vtvEozMIakBBK
 Th3hhV0GU5+yIgQIxFu40EdZ5oqwo2TGATXzeCtu0MbSRRL2jA0ZVa/RCAPQ/4QA
 TTWNjiHObjKHfh9zpCDuweZusD0wsffxHGIL4m3e9QSZ8Tcq7lda1gHUb+rcPq0T
 KWASKiezl6fhRkUh6XQjCpXA7D53bVkZrbSavbSNEQTtZZM/E1ONSlCwsjMtV98b
 KdOyjw/9SHrqy6/nvGYLlNO43QyTN4fEGoCxKpwV4pLnMUozzFiXC7NJgpcxj2Kd
 ldiQVaBwmA4ECJytchm2+tuEqH4zA0kmLai9JDRTteKhXPtuVBSSdA1VBMhQ34qf
 4BF3fL0hNH5DKcM0K8cNQMlIs/jsReydbAUTFFdiVQrB6A2olQFfyEbgsAb8+a4H
 iErKCVLqKG1dGEKSq2Rpq2mzDsCg4zpTWUY2q9xT/cxahKSsgyqnxWkQCYJaoWzL
 L46DQ9iLItbSQN7d8VaRPpi9emZRjuasoWKKTlzr+sBn8lbx3aIjIiJYCUzuY6+6
 bybZ2bOxU4kr3YC6hEtiWsl9em4CWBZFUtLlGs9pw+kOyXfnIGGS0XTo0z0+CBw3
 3RyV2XilogbdULomEDaC
 =Bti0
 -END PGP SIGNATURE-



 --
 Daniele



-- 
Daniele

Re: [Standards] Application-level delivery notification between server and client

[Daniele Ricci]

Hi Dave,
thanks for your delightful answer. Actually I was going to reply with
pretty much the same arguments, I was looking for the time to write
that... you saved me from a long writing :-)

Anyway Dave has perfectly catched my needs. Although I ended up
defining my own extension, I really would like to standardize it or
(if possible) use an existing XEP.

p.s. the last paragraph came 3 times.


On Thu, Aug 8, 2013 at 11:37 AM, Dave Cridland d...@cridland.net wrote:
 I know this thread is going to sleep, but I'd like to stick my oar in. :-)

 On Tue, Aug 6, 2013 at 9:15 PM, Daniele Ricci daniele.ath...@gmail.com
 wrote:

 Please correct me if I'm wrong at any point, just to be sure I
 understand XEP 198 and how I can use it in the right way.


 XEP-0198 is designed to make a stream:
  - Reliable: You know what has definitely been received by the peer.
  - Recoverable: You can have a stream span TCP connections, in effect,
 without duplication or loss.

 But note this *only* has an effect for streams; chat sessions span
 multiple streams - unless you're talking to a server, or using XEP-0174
 (Serverless messaging, in case I've got the number wrong) - and so all this
 is doing is making each leg of the journey reliable. That's important, but
 not sufficient.


 In my case, I can only use the 'h' attribute to store the server-side
 message ID. Which I can't do according to the spec.


 Right - h is purely a count. Because it's only one stream, rather than
 end-to-end, we can do this, and it's sufficient. We could have had a/ and
 r/ contain random guids or something, but then people would have expected
 to be able to insert semantic meaning into them, and they don't need that.
 a/ is the conversational equivalent of saying Right? at the end of a
 sentence, and r/ is the equivalent of saying Uh-huh and nodding
 politely. You don't need to figure out which sentences have been received,
 because it's just everything up until this point.

 But just like a conversation where one side is just grunting and nodding,
 while you know they've heard, you don't know if there was anything more.


 But the biggest and main issue is: a receipt is actually part of a
 message. It's not stream management; it means Alice will receive a
 delivery receipt when message has been delivered (and acknowledged) by
 Bob. I can't just throw off r/ at any time for this purpose - it
 would not be stream management any more. That's why I think I need
 something half XEP 198 and half XEP 194.


 And you're right - except you don't want half '198 and half '184, you
 actually want all of both.

 Whilst XEP-0198 makes streams reliable, to make chat sessions reliable to
 need XEP-0184, which will then mean you can reliably send a message - and
 reliably get a receipt back when it's delivered.

 The reason you need both, despite them looking superficially similar, is
 that without any XEP-0198 in place you can't actually tell if it was the
 message that was lost or the XEP-0184 receipt, and so while the safe thing
 to do is warn the user and possibly resend, that may be very irritating for
 the recipient.

 The reason you need both, despite them looking superficially similar, is
 that without any XEP-0198 in place you can't actually tell if it was the
 message that was lost or the XEP-0184 receipt, and so while the safe thing
 to do is warn the user and possibly resend, that may be very irritating for
 the recipient.

 The reason you need both, despite them looking superficially similar, is
 that without any XEP-0198 in place you can't actually tell if it was the
 message that was lost or the XEP-0184 receipt, and so while the safe thing
 to do is warn the user and possibly resend, that may be very irritating for
 the recipient.

 I hope that makes things clearer,

 Dave.



-- 
Daniele

Re: [Standards] Application-level delivery notification between server and client

[Daniele Ricci]

Hi Kevin,
XEP 198 lets you acknowlege every stanza in the stream. I want
something more specific. Something to confirm messages and return
(together with the ack) a message identifier - which is actually a
server-side message ID). And all of that in a paranoid way: when a
message is sent, server sends ack back (with message ID); when a
message is delivered, client sends an ack back to the server.

I had to make my own extension for that (basically an extension to the
message/ stanza), similar to XEP 184, but server-managed; do you
think I could use some existing XEP for this job? Would it worth it to
write a new one?



On Tue, Aug 6, 2013 at 8:13 PM, Kevin Smith ke...@kismith.co.uk wrote:
 On Tue, Aug 6, 2013 at 7:10 PM, Maxim Ignatenko gelraen...@gmail.com wrote:
 Is there any draft that addresses the problem of silently losing
 messages when client's TCP connection times out?

 XEP 198.

 /K



-- 
Daniele

Re: [Standards] Application-level delivery notification between server and client

[Daniele Ricci]

Please correct me if I'm wrong at any point, just to be sure I
understand XEP 198 and how I can use it in the right way.

First of all, in this:
the client or server can send ack elements at any time over the stream

this means that I can send a/ or r/ just for message stanzas.

Then it states:
The value of 'h' starts at zero at the point stream management is
enabled or requested to be enabled (see note below). The value of 'h'
is then incremented to one for the first stanza handled and
incremented by one again with each subsequent stanza handled.

In my case, I can only use the 'h' attribute to store the server-side
message ID. Which I can't do according to the spec.

But the biggest and main issue is: a receipt is actually part of a
message. It's not stream management; it means Alice will receive a
delivery receipt when message has been delivered (and acknowledged) by
Bob. I can't just throw off r/ at any time for this purpose - it
would not be stream management any more. That's why I think I need
something half XEP 198 and half XEP 194.

If you have any more advices on a way to handle this situation,
please. I don't like to re-invent the wheel :-)



On Tue, Aug 6, 2013 at 9:58 PM, Matthew Wild mwi...@gmail.com wrote:
 On 6 August 2013 20:51, Daniele Ricci daniele.ath...@gmail.com wrote:
 Hi Kevin,
 XEP 198 lets you acknowlege every stanza in the stream. I want
 something more specific. Something to confirm messages and return
 (together with the ack) a message identifier - which is actually a
 server-side message ID). And all of that in a paranoid way: when a
 message is sent, server sends ack back (with message ID); when a
 message is delivered, client sends an ack back to the server.

 I don't understand what the difference to or advantage over XEP-0198 is?

 Regards,
 Matthew



-- 
Daniele

Re: [Standards] Out of band: MIME type

[Daniele Ricci]

Hi Peter,
you mean it would be worth to change XEP-0066 in such a way?

On Thu, Jul 18, 2013 at 5:34 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 7/18/13 2:42 AM, Daniele Ricci wrote:

 FWIW, even a length attribute could be useful to save an HEAD
 request (always to be considered no more than a hint).

 Yes, we have that in XEP-0096 but not in XEP-0066.

 file xmlns='http://jabber.org/protocol/si/profile/file-transfer'
   name='test.txt'
   size='1022'
   descThis is info about the file./desc
 /file

 Peter

 - --
 Peter Saint-Andre
 https://stpeter.im/


 -BEGIN PGP SIGNATURE-
 Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQIcBAEBAgAGBQJR6Ar2AAoJEOoGpJErxa2p3D8QAJ1egp8HuumsfUWjeAw4I8bM
 Y/qj9RV7GnSo1NnfQoc8L/JaxOX9WqEaMVOH338daQbPExCNwq0vtvEozMIakBBK
 Th3hhV0GU5+yIgQIxFu40EdZ5oqwo2TGATXzeCtu0MbSRRL2jA0ZVa/RCAPQ/4QA
 TTWNjiHObjKHfh9zpCDuweZusD0wsffxHGIL4m3e9QSZ8Tcq7lda1gHUb+rcPq0T
 KWASKiezl6fhRkUh6XQjCpXA7D53bVkZrbSavbSNEQTtZZM/E1ONSlCwsjMtV98b
 KdOyjw/9SHrqy6/nvGYLlNO43QyTN4fEGoCxKpwV4pLnMUozzFiXC7NJgpcxj2Kd
 ldiQVaBwmA4ECJytchm2+tuEqH4zA0kmLai9JDRTteKhXPtuVBSSdA1VBMhQ34qf
 4BF3fL0hNH5DKcM0K8cNQMlIs/jsReydbAUTFFdiVQrB6A2olQFfyEbgsAb8+a4H
 iErKCVLqKG1dGEKSq2Rpq2mzDsCg4zpTWUY2q9xT/cxahKSsgyqnxWkQCYJaoWzL
 L46DQ9iLItbSQN7d8VaRPpi9emZRjuasoWKKTlzr+sBn8lbx3aIjIiJYCUzuY6+6
 bybZ2bOxU4kr3YC6hEtiWsl9em4CWBZFUtLlGs9pw+kOyXfnIGGS0XTo0z0+CBw3
 3RyV2XilogbdULomEDaC
 =Bti0
 -END PGP SIGNATURE-



-- 
Daniele

[Standards] Out of band: MIME type

[Daniele Ricci]

Greetings,
I found out to be needing a type attribute in the url/ element in
XEP-0066 [1]. I guess it could be useful as a hint to know in advance
the mime type of what we are going to download (e.g. for http URIs).
What do you think?

Regards

[1] http://xmpp.org/extensions/xep-0066.html

--
Daniele

Re: [Standards] Out of band: MIME type

[Daniele Ricci]

I know, I mean without contacting the URI itself in anyway. It's just
a hint to save a HTTP request, even if it's a short one (mobile
environment needs).
FWIW, even a length attribute could be useful to save an HEAD request
(always to be considered no more than a hint).


On Thu, Jul 18, 2013 at 10:30 AM, Ashley Ward ashley.w...@surevine.com wrote:
 On 18 Jul 2013, at 08:30, Daniele Ricci daniele.ath...@gmail.com wrote:

 Greetings,
 I found out to be needing a type attribute in the url/ element in
 XEP-0066 [1]. I guess it could be useful as a hint to know in advance
 the mime type of what we are going to download (e.g. for http URIs).
 What do you think?

 Could you not just do an HTTP HEAD request to discover the MIME type if you 
 need to know the type before downloading it?

 --
 Ash



--
Daniele

Re: [Standards] Heml.is and federation..

[Daniele Ricci]

Hi Steffen,
please refer to this thread [1] to go on with further discussions. I
am too looking for a standard and interoperable way of doing e2e
encryption, but the current situation is still a bit confusing.

[1] http://mail.jabber.org/pipermail/standards/2013-July/027731.html

On Fri, Jul 12, 2013 at 10:42 PM, Ralph Meijer ral...@ik.nu wrote:
 On 2013-07-12 20:56, Steffen Larsen wrote:

 Hi,

 I just stumbled upon https://heml.is, which is a new XMPP client for IOS
 and Android. Anyone knows these guys?

 It uses XMPP and PGP for encryption, but do any of you guys know if they
 federate?.. What I can see from skimming their page, its yet another silo,
 due to the fact of PGP and their own infrastructure.
 So federation and using your own domain does not seem feasible, right?
 Anyone want to discuss this and the alternatives besides OTR? Security
 labels?

 When I see something like this I get exited to start with because I
 actually want something like this on the client/server part, but then later
 on gets down to earth when it seems out of the standards. Or is it just me?


 I think the most interesting aspect of projects like this is the addition of
 some form of end-to-end encryption. If you want to be involved in an effort
 like this, I strongly recommend you get on the IETF XMPP WG mailing list and
 discuss Matt Miller's draft [1].

 This is basically the result of several attempts to standardize e2s
 encryption for XMPP. It needs more eyes, implementations and feedback.

 [1] http://tools.ietf.org/html/draft-miller-xmpp-e2e-06

 --
 ralphm



-- 
Daniele

[Standards] Public-key-driven presence subscription

[Daniele Ricci]

Greetings,
I'm working to extend XMPP to be suited for my project. My project has
the need to not store rosters on behalf of users. I'm already using
asymmetric encryption and I though that I might be able to verify a
presence subscription request by looking at public key signatures. For
example:

* Alice requests presence subscription to Bob
* Bob receives the subscription request along with Alice's public key
* if Bob accepts, he signs Alice's public key using his private key
* Bob will reply to the subscription request including signed Alice's public key
* Alice is now authorized to see Bob's presence - server just need to
check for the right signature on the public key

This has some advantages:
* Server doesn't need to store roster lists for each users. Storing
public keys will be enough
* Using a WoT system (such as OpenPGP), we can encourage people to use it
* This system can be used for handling permissions to send messages
and generally obtain information about a user - server will check the
signatures to see if a user is allowed to see someone else info or
send a message

Please note that my project has no roster list management, but I think
that this method can be applied also to output a roster list generated
on-the-fly by looking at public key signatures.

Is this an insane approach? What do you think?

Regards,
--
Daniele

Re: [Standards] RFC 3923 (e2e with S/MIME) and OpenPGP

[Daniele Ricci]

On Mon, Jul 1, 2013 at 7:06 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
 What about applying PGP/MIME instead

 As in http://xmpp.org/extensions/xep-0027.html perhaps?


I mean using PGP/MIME the same way RFC 3923 uses S/MIME.

 I think you mean: draft-miller-xmpp-e2e replaces RFC 3923.


Yes, I put the * symbol because there were several draft versions of
that spec :-)

 Is there some draft to follow/improve where e2e+PGP/MIME is
 defined?

 XEP-0027.


You mean in the meantime that a more safe spec is drafted?

 (1) Matt's work on draft-miller-xmpp-e2e
 (2) OTR (potentially with future enhancements to make it more
 XMPP-friendly)

 Some energy is going into both of those (Paul Wouters and I plan to
 sync up at the IETF meeting at the end of July to work on an
 Internet-Draft providing informational documentation about OTR). Since
 you seem to care about this issue, your feedback would be welcome.


Sure! Because my needs are mobile-oriented, I have to implement some
e2e solution that works when both users are online or not (something
like offline-storage OTR?). Of course an offline solution is less
safe than an online one, but of course there might be a compromise
(warning the user that e.g. forward secrecy might be compromised
because recipient is offline might be an option). Anyway, please keep
this in mind when you will discuss your new Internet-Draft.

--
Daniele

[Standards] RFC 3923 (e2e with S/MIME) and OpenPGP

[Daniele Ricci]

Greetings,
I was reading RFC 3923 [1], and it always talks about S/MIME encrypted
message format. What about applying PGP/MIME instead - or better, let
the RFC handle both cases?
If I understand correctly, draft-miller-xmpp-e2e-* are replaced by RFC
3923. Is there some draft to follow/improve where e2e+PGP/MIME is
defined?


By the way: encryption/signing in XMPP is very confusing: there are at
least a dozen documents (RFCs and XEPs) defining it - of course I
should follow approved XEPs and RFCs, but I'm also looking around:
maybe some XEPs are already widely implemented or they will be
approved soon.


Thank you,
Cheers

[1] http://tools.ietf.org/html/rfc3923

--
Daniele

Re: [Standards] Mobile viewport

[Daniele Ricci]

That's great.
I've been using gen.py for that (a little bit modified because it was
looking for mercurial revisions!??). However a simple 1-liner with
xsltproc should be enough.

On Wed, Jun 19, 2013 at 11:45 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
 Fixed:

 http://xmpp.org/extensions/xep-0008.html

 We don't have a script that generates all the XEP files, but I figured
 you might like to see one example (I've updated xep.xsl and we just need
 to regenerate the XEPs).

 Peter

 On 6/18/13 6:30 AM, Daniele Ricci wrote:
 I've created an example XEP to test it with my Android mobile:
 http://www.kontalk.org/files/xmpp/xep-0008.html

 On Tue, Jun 18, 2013 at 2:30 PM, Daniele Ricci daniele.ath...@gmail.com 
 wrote:
 Hi all,
 I often read XEPs and RFCs from my mobile phone. It would be nice to
 add a viewport meta to the XSL to let mobile phones display them
 correctly. I've just tried, works great. Something like this (of
 course you can change it to whatever you consider useful):

 meta name=viewport content=width=device-width; initial-scale=1.0;
 maximum-scale=2.0;/

 A quick article that talks about that:
 https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag
 Just an example anyway.

 Of course XML prettified data will go out of the screen if it's larger
 than the viewport (that is, device width).

 Cheers
 --
 Daniele



-- 
Daniele

[Standards] Mobile viewport

[Daniele Ricci]

Hi all,
I often read XEPs and RFCs from my mobile phone. It would be nice to
add a viewport meta to the XSL to let mobile phones display them
correctly. I've just tried, works great. Something like this (of
course you can change it to whatever you consider useful):

meta name=viewport content=width=device-width; initial-scale=1.0;
maximum-scale=2.0;/

A quick article that talks about that:
https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag
Just an example anyway.

Of course XML prettified data will go out of the screen if it's larger
than the viewport (that is, device width).

Cheers
--
Daniele

Re: [Standards] Mobile viewport

[Daniele Ricci]

I've created an example XEP to test it with my Android mobile:
http://www.kontalk.org/files/xmpp/xep-0008.html

On Tue, Jun 18, 2013 at 2:30 PM, Daniele Ricci daniele.ath...@gmail.com wrote:
 Hi all,
 I often read XEPs and RFCs from my mobile phone. It would be nice to
 add a viewport meta to the XSL to let mobile phones display them
 correctly. I've just tried, works great. Something like this (of
 course you can change it to whatever you consider useful):

 meta name=viewport content=width=device-width; initial-scale=1.0;
 maximum-scale=2.0;/

 A quick article that talks about that:
 https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag
 Just an example anyway.

 Of course XML prettified data will go out of the screen if it's larger
 than the viewport (that is, device width).

 Cheers
 --
 Daniele



-- 
Daniele

Re: [Standards] TLS over OpenPGP

[Daniele Ricci]

Continuing on this topic - just a short (maybe) off-topic: I recently
implemented OpenPGP over TLS on my project [1], using my patches on
python-gnutls which eventually became a fork [2].

[1] http://blog.casaricci.it/2013/04/24/openpgp-authentication-over-tls
[2] https://gitorious.org/pygnutls

On Thu, Apr 18, 2013 at 6:06 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
 On Thu, Apr 18, 2013 at 04:21:02PM +0200, Daniele Ricci wrote:
 In the meantime: I just wrote Python bindings for GnuTLS OpenPGP
 support [1], patch is here: [2]
 Next step would be a Twisted endpoint.

 [1] http://twistedmatrix.com/trac/ticket/6175#comment:6
 [2] 
 http://twistedmatrix.com/trac/attachment/ticket/6175/python-gnutls-1.2.4-gpg.diff

 Cool. You might want to ping Ralph Meijer (who is on this list) about
 Twisted, since he's the author of Wokkel: http://wokkel.ik.nu/

 Peter




-- 
Daniele

Re: [Standards] TLS over OpenPGP

[Daniele Ricci]

On Tue, Apr 23, 2013 at 12:33 PM, Hannes Tschofenig
hannes.tschofe...@gmx.net wrote:
 TLS over OpenPGP sounds a bit strange. I looked at your blog post and it
 seems that you have implemented RFC 6091, which allows OpenPGP certificates
 to be used instead of X.509 certificates within the TLS handshake.


Yes, actually a more correct definition would be OpenPGP over TLS,
but over not as in tunneled or wrapped, but as in authenticated
using OpenPGP certificates :-)

 I am curious how you use the OpenPGP certificates: do you use them for
 server-side authentication and, if so, how do you validate the certs?


Yes I use them for authentication. In my case, I just need to verify
if one or more signatures are present on the client's public key
(signature that a server can recognize as valid). After that,
server iterates through all certificate uids, searching for a special
token on the comment field (e.g. kontalk or something like that,
maybe xmpp or jabber or jabber|domain.com, maybe we could define
a XEP for that? [2]); the e-mail field will be the client's Jabber ID (of
course verifications to the e-mail field are made too just in case [1]). I
still have to find a use for the name field... I guess it can be used
as a public name, since jabber IDs in my case are a bit hard to
remember (sha1 hash@kontalk.net).

 Ciao
 Hannes

 PS: You might also be interested to take a look at:
 http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-07

 It adds the use of raw public keys.


Out of band? Meaning it uses another channel for certificate
verification? I don't fully understand...


[1] actually the current implementation (as of today) just takes the
e-mail field from the first uid, I'm implementing the other checks
right now.
[2] actually XEP-0178 already has that: auth/ element can be filled
with the jabber id a client wants to authenticate with - of course
server will decide if it's allowed or not. So I guess the comment
field is useless afterall :-)

-- 
Daniele

Re: [Standards] TLS over OpenPGP

[Daniele Ricci]

On Tue, Apr 23, 2013 at 2:06 PM, Dave Cridland d...@cridland.net wrote:
 So in X.509 terms, the peer provides a certificate, and you assemble a chain
 back to a known trust anchor (typically a public CA, by walking back through
 the issuers). If that chain looks good (and if the other parameters on the
 certificate, such as expiry, are OK, and if the certificate has not been
 explicitly revoked, and so on) then you trust the certificate, and can use
 the identifier information within it (Subject Alternative Names, or the
 Subject DN itself, typically extracting CommonNames in ways that leave me
 queasy) to decide on an identifier.


Maybe I wasn't clear enough, sorry. Server does check for its own
signatures on client's public key just as a server inspects the CA
chain for X.509 certificates. That is possible because during prior
registration to the XMPP server, client public key is signed by the
server private key (no XEP for this yet AFAIK :-)

 works reliably I don't know. This is all particularly useful in the case
 whether the certificate contains multiple identifiers, ambiguous identifiers
 (like wildcards) or no identifiers at all.


Yes, that's what XEP-0178 is for; but you're right, maybe it's a
redundancy in this case, since the from attribute can be used for
identification.

 You've given how to extract identifiers from PGP keys, which seems useful,
 but not how each party might decide to trust the key at all.


I described client authentication before; client instead, in my case,
has already a list of valid fingerprints it can accept as valid
(trusted servers I might say).

-- 
Daniele

Re: [Standards] TLS over OpenPGP

[Daniele Ricci]

On Tue, Apr 23, 2013 at 2:29 PM, Dave Cridland d...@cridland.net wrote:
 Ah, OK, so the server's key is also its own trust anchor.

 The problem I worry about here is that it means that a server compromise
 event will lead to a situation where the server's keypair can be used to
 subvert existing accounts. This is a bit of a nightmare scenario in many
 deployments.


Isn't it what could happen with CA authorities too? At least until the
compromised keys are replaces with new ones, the compromised key can
be used for malicious purposes.

 You could work around this by separating the functions - so the server
 trusts a third party, which itself signs the keys of registering clients.


Well, my aim is: client always has one single credential, with which
it can login to any of the servers within the network. Using passwords
or some hard-stored credential would require data replication;
checking key signatures will save space and resources. I know there
are consequences to this (continues below).

 However, once you worked in ways to handle client key compromise, and all
 the rest, I don't see what this is buying you that running a private X.509
 CA for the service would not. And doing the latter would mean using
 off-the-shelf components (including an unmodified server and often
 unmodified clients, too). Personally, I'm lazy enough to see the idea of
 avoiding having to write new code to be a great idea.


Clients will be using their OpenPGP keys to sign messages for one
another, I thought it could be useful to use the same keys to
authenticate too - thus avoiding having two different keypairs (one
for authentication, one for encryption/signing).

 I don't see how you'd handle key rollover either.


I wonder how do they do in X.509: I mean if a key is compromised,
*all* certificates signed with that key must be discarded almost
immediately - and replaced with a new one. Couldn't I do the same?

 I'm not saying you're doing everything entirely wrong, just that X.509 has
 these problems well-understood and (usually) solved. The primary advantage
 of using something like OpenPGP keys would be to buy into an existing
 infrastructure without use of public CAs, but you can do the latter whilst
 still using PKIX, and you don't seem to be trying to do the former.


My implementations and ideas I'm exposing here are just a start; I'm
still starting to dive into all these (for me) new concepts as I try
to build this instant messaging system. I know I still have a lot to
learn, I'm here also for that :-)

 FWIW, the unsolved problem using PKIX is that you need the client to supply
 a CSR during registration, and obtain a signed certificate back, possibly
 later. I'd be very keen to see this defined, and would be interested in
 helping.


In which way this is a problem? Because of the delay between key+CSR
generation and its signing by the CA?

-- 
Daniele

Re: [Standards] TLS over OpenPGP

[Daniele Ricci]

On Tue, Apr 23, 2013 at 4:37 PM, Dave Cridland d...@cridland.net wrote:
 There are signing/encryption proposals based around X.509, too. In the XMPP
 world, I'm tempted to suggest hammering


Hammering? What do you mean?

 In the PKIX model, the key used for signing belongs to a CA, which can be
 protected better against compromise than a key used for signing and
 encryption (and authentication), such as a client or server key, so
 revocation of entire CA certificates is rare, and typically makes headline
 news.


That's the issue: it always come to relying to a (possibly) commercial
third party to do the job. It contrasts with the concept of
community-driven server network. In my mind, every server in the
network has its own CA, otherwise it won't be community-driven.
Anyway, I don't think a third party CA would sign certificate requests
blindly (that is, given by a server when it's registering a new
account for a new user).

 Well, if you want to have the certificate provision based around an in-band,
 or client-driven, registration protocol, then I think you need a method for
 having the certificate (or PGP key) signed. It seems reasonable to want to
 standardize this.


Sure, that would be great.

-- 
Daniele

Re: [Standards] TLS over OpenPGP

[Daniele Ricci]

On Tue, Apr 23, 2013 at 4:42 PM, Simon McVittie
simon.mcvit...@collabora.co.uk wrote:
 On 23/04/13 14:21, Daniele Ricci wrote:
 I hope you don't mean context-free signatures on individual IMs similar
 to those in XEP-0027 http://xmpp.org/extensions/xep-0027.html?


That is actually one of the things I still need to address. Being
Kontalk primarly targeted to mobile devices, it might not always be
possible to estabilish an OTR session because one of the two peers
could often be offline.
Have you got any suggestion about this?

 I suggest thinking about your threat model - who is the attacker and
 what can they do? - before designing cryptographic protocols: otherwise,
 it's easy to end up with a system that has gained more complexity than
 actual security.


I know... but I need to gather much information in order to plan ahead
all of this - that's why I'm here. I implemented RFC 6091 because I
wanted to see it working and also to generate some interests.

 If you want identity based on OpenPGP, but authentication using X.509
 (to take advantage of existing code), one way to do it is to have a
 machine-readable OpenPGP-signed assertion of the form please assume
 that only I have access to the corresponding private key for the
 following self-signed X.509 cert: [...]. Something like that, or a
 subkey-based approach, would also have the advantage that an exploitable
 bug in your XMPP software would only result in disclosure of XMPP
 messages, and not a compromise of the OpenPGP key (and hence everything
 else it had been used for).


If I sign you something you provide I can prove I own my private key,
right? Isn't it what TLS and RFC 6091 somewhat define? Maybe I didn't
fully understand your statement.


-- 
Daniele

Re: [Standards] TLS over OpenPGP

[Daniele Ricci]

On Tue, Apr 23, 2013 at 6:02 PM, Daniele Ricci daniele.ath...@gmail.com wrote:
 I hope you don't mean context-free signatures on individual IMs similar
 to those in XEP-0027 http://xmpp.org/extensions/xep-0027.html?


I can always give users a warning that when user is offline security
is decreased. Using some sort of push mechanism, sender could wait for
the recipient to go online and then begin a OTR session (some sort of
an async begin-session request)

-- 
Daniele

[Standards] TLS over OpenPGP

[Daniele Ricci]

Hi list!
I'm developing a messaging application based on XMPP [1], focusing on
community, privacy and security.
What I want to discuss here is I've decided to use OpenPGP keys to
encrypt data between users. Also it would be optimal to use those keys
to authenticate against servers too.

I started by implementing a very simple (and unsafe) SASL mechanism, a
simple challenge/response method (like SSHv1). But things are getting
a little more complicated, and since this application is targeted
mostly to mobile devices, authenticating in-band of an XML stream
would be a huge waste of network traffic. A server-side working
implementation based on Twisted can be found on xmppserver repository
[2].

Before even considering a SASL mechanism, I bumped into RFC 6091 [3],
namely Using OpenPGP Keys for Transport Layer Security (TLS)
Authentication. This protocol would save bandwidth but lacks of
implementations (only GnuTLS implements this - and only the mainstream
C version, so no bindings).

Because Kontalk aims to target multiple platforms, this RFC will
require many implementations to be written (e.g. Android would require
- for example - a separate Bouncycastle implementation).
On the other hand, a SASL mechanism requires an application level
implementation (that is, it's already part of the XML stream, easier
to implement - but no standard present yet).

Another option would be put into a X.509 certificate the PGP key as a
blob (quite a workaround eh?), but I prefer not to consider that :-)

The question is: SASL or TLS?

Bye

[1] https://code.google.com/p/kontalk/
[2] https://code.google.com/p/kontalk/source/browse/?repo=xmppserver
[3] http://datatracker.ietf.org/doc/rfc6091/

-- 
Daniele