Re: [Standards] Feedback on XEP-0257: Client Certificate Management for SASL EXTERNAL
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 elements: > > It has been a long time, I hope I can remember :) > >>> The element should contain a and the >>> contains a different , 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 >>> 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 element could directly be inside the element. >>> The in the (which is actually a fingerprint) should >>> either be removed completely (it adds no info) and therefore basing >>> removing and revoking on the "real" , or it should be renamed >>> to something like // 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 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 >
Re: [Standards] Feedback on XEP-0257: Client Certificate Management for SASL EXTERNAL
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 elements: It has been a long time, I hope I can remember :) >> The element should contain a and the >> contains a different , 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 >> 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 element could directly be inside the element. >> The in the (which is actually a fingerprint) should >> either be removed completely (it adds no info) and therefore basing >> removing and revoking on the "real" , or it should be renamed >> to something like // 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 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
Re: [Standards] Feedback on XEP-0257: Client Certificate Management for SASL EXTERNAL
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 elements: > The element should contain a and the > contains a different , 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 > 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 element could directly be inside the element. > The in the (which is actually a fingerprint) should > either be removed completely (it adds no info) and therefore basing > removing and revoking on the "real" , or it should be renamed > to something like // 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 query > result. Though maybe this is a bit too far outside the scope of > this XEP. > > Best regards, > Thijs Alkemade
Re: [Standards] Feedback on XEP-0257: Client Certificate Management for SASL EXTERNAL
On 2012-05-31T18:32:31 CEST, 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. I agree that some clarification would definitely be great. I would also like to point out that the XEP lacks a 'Discovering Support' section. Nothing fancy needed, just the standard 'Use disco#info, look for ' etc. Regards, Kim Alvefur
[Standards] Feedback on XEP-0257: Client Certificate Management for SASL EXTERNAL
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 elements: The element should contain a and the contains a different , 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 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 element could directly be inside the element. The in the (which is actually a fingerprint) should either be removed completely (it adds no info) and therefore basing removing and revoking on the "real" , or it should be renamed to something like // 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 query result. Though maybe this is a bit too far outside the scope of this XEP. Best regards, Thijs Alkemade