Sorry about top-posting, but I wanted to preserve the entire message for Dirk Meyer (cc'd).
Given that Dirk it not really actively involved in XMPP any longer (AFAIK), I think it would be good for Thijs and perhaps Kim to take over maintenance of this spec. 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. On 5/31/12 10:32 AM, Thijs Alkemade wrote: > Hello list, > > In order to make it easier to implement client-side certificates in > Adium, I started on writing a module to implement XEP 0257: Client > Certificate Management for SASL EXTERNAL in Prosody, which has since > then been improved by Kim Alvefur. I have some comments about the > XEP, which I would like to share. > > - Example 5 and 6 have a typo: an erroneous "/" on line 4. > > - 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. > > - I'd like some clarification of the meaning of the <name> elements: > 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. > > - 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. > > 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. > > 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. > > Best regards, > Thijs Alkemade
