On Sat Mar 05 19:58:57 2016, [email protected] wrote: > > These functions, although internal, appear to me to be the natural way > to serialize > and deserialize private ECDH groups. They are well tested and reusable > and the only > reason why they are not public is probably because OpenSSL is focused > on supplying > standardized named curves for TLS. Using private ECDH curves might not > make much sense > for TLS, but in my case it did: I used it for a VPN client/server > where the customer > requested the ability to use private ECDH groups in the IKEv2 > protocol, in addition > to the official IANA groups. > > With the proposed change it was easy for me to serialize the entire > set of all public > and private [EC]DH-Groups in single file by creating a few ASN1 rules > based on the > existing ASN1 structures (DHparameters resp. EC[PK]PARAMETERS). So > instead of > reinventing the wheel, I let OpenSSL do the main part of the > serialization. > > There is a thread that predates the creation of my ticket, where I > discussed my motivation > with Daniel Kahn Gillmor, see below. I hope my arguments convince you > that it is a good > idea to add these ASN1 structures and the related functions to the > public api. >
Well I agree that that ASN.1 structure is a natural way to encode/decode EC parameters I'm just wondering what alternatives there are. We'd be exposing internal structures with no accessors whose sole purpose would be to convert between EC_GROUP and back. The ideal situation would be an ASN.1 item which handle an EC_GROUP structure directly instead of the internal form. We don't currently have one though, Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3676 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
