Hi, On 05/31/2012 07:49 PM, Peter Saint-Andre wrote: > Given that Dirk it not really actively involved in XMPP any longer > (AFAIK)
Sadly, no, my current job does not involve XMPP at all and my free hacking time is used for Freevo. I still plan to make it possible to control Freevo using XMPP but that is not something that will happen soon. But if someone includes me in a Cc, I will answer. :) > I think it would be good for Thijs and perhaps Kim to take over > maintenance of this spec. Sounds like a good idea. > I also agree about decoupling this spec from XEP-0189, which as you say > went in a different direction because of some work that Matt Miller and > I were doing on end-to-end encryption at the IETF. Is it correct that 0.14 is the latest version of 0189? >> - It uses XEP 0189 to format the public keys. However, afaict it was >> written for version 0.8 of that specification, which differs a lot >> from the current version. I don't think the latest version suffices >> (it appears to me it can only send the public key and some other >> meta-data such as begin and end time, not the full certificate). >> Theoretically, this is not a problem as everyone can look up the old >> version of the XEP, but in practice it might be very confusing and >> cause problems for developers who need to implement different >> versions of 0189. Yes, I just added the full certificate. The current version of 0189 is different and in its current version it is useless for SASL EXTERNAL. >> - I'd like some clarification of the meaning of the <name> elements: It has been a long time, I hope I can remember :) >> The <append> element should contain a <name> and the <keyinfo> >> contains a different <name>, which according to 0189v0.8, should be >> th SHA1 hash of the certificate. Is the former name required to be >> unique? The examples suggest revocation and removal is done based on >> the latter name, but this is not explicitly noted. The first name was a human readable name. Otherwise, the user does not know which certificate to remove. It is never stated that it should be unique, but it would be helpfull for the user to know which certificate belongs to which client (the idea was to have a different certificate for each client to revoke a stolen device without touching everything else). Since it is never stated to be unique and the SHA1 hash is, the hash is used for the revoke. >> - Related to the previous point, 0189v0.8 says that the <x509cert> >> element is optional, and only the fingerprint is required. While >> technically this is not a problem for 0257 (hash the client's >> certificate when it connects, and only compare that), I think this >> would have a lot of usability and security problems. Yes, for 0189 alone the hash was enough, for 0257 it should be required. >> Taking the last 3 points together, I propose removing the link with >> 0189, as that XEP seems to serve a different purpose now. All that >> is really necessary is to transmit the PEM encoded certificate, so >> the <x509cert> element could directly be inside the <append> element. >> The <name> in the <keyinfo> (which is actually a fingerprint) should >> either be removed completely (it adds no info) and therefore basing >> removing and revoking on the "real" <name>, or it should be renamed >> to something like <fingerprint>/<hash>/<id> and the XEP should be >> changed to explicitly note that removal/revocation is based on this >> value. Agreed. Remove the reference to 0189, keep the human readable name and make it unique. By that the user can identify the client if every client has a different certificate. Remove/revoke can be done using that unique name. >> Additionally, I think it would be a nice enhancement to be able to >> check which online resources are using which client side certificate >> at a given moment, for example as part of the <items /> query >> result. Though maybe this is a bit too far outside the scope of >> this XEP. Sounds like a good idea. It would be very nice to have SASL EXTERNAL support for clients in Prosody. This would be an important step forward for me if I will ever implement XMPP support in Freevo. Regards, Dirk
