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 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
[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 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
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 feature' etc. Regards, Kim Alvefur
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 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
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 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
