Hi, Thanks for the review and ACK.
On Mon, Jan 29, 2018 at 5:18 AM, Arne Schwabe <a...@rfc2549.org> wrote: > Am 25.01.18 um 20:45 schrieb selva.n...@gmail.com: >> From: Selva Nair <selva.n...@gmail.com> >> >> - This automatically supports EC certificates through >> --management-external-cert >> - EC signature request from management is prompted by >> >PK_SIGN if the client supports it (or >RSA_SIGN) >> Response should be of the form 'pk-sig' (or rsa-sig >> by older clients) followed by DER encoded signature >> as base64 terminated by 'END' on a new line. >> >> > > Acked-by: Arne Schwabe <a...@rfc2549.org> > > Ack from my side. Note that this patch will ask for a ec signatre with > > RSA-SIGN when the user has put a EC certificate in the config and the ui > does not send "version 2". I am not sure that we need to address this > tough. That kind of configuration will break anyway. It just now does at > a different point. And putting an EC certificate is not something that > should happen on accident. I do not think we need to be concerned about this. An old UI would just say either it doesn't support signing using the key or that it got incorrect signature request from the daemon. So instead of erroring out in openvpn we will error out in the UI. But that's the theory, I do not know how extant UI's out there would respond to RSA_SIGN request with data != 36 bytes or when key is not RSA. The !=36 byte thing already happened when we merged the TLS1.2 patch. What will the android client do in this case? Jonathan, would tunnelblick cope if it gets an RSA_SIGN when the key is EC or with unexpected data size? Selva ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
