Hi Dirk, that all sounds good! I'll poke Thijs and Kim about updating the spec.
On 5/31/12 12:38 PM, Dirk Meyer wrote: > 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 >
