To work with some Apple APIs, we need to use ECDSA keys with the NIST P-192 curve (secp192r1). It would be convenient if this curve were implemented by crypto/x509 and crypto/elliptic such that functions like x509.ParseECPrivateKey and x509.ParsePKIXPublicKey worked with such keys. The crypto/x509 interface can't be used directly with our own curve definitions; in order to support P-192 we have to copy-paste various bits of crypto/x509 code.
It's not clear to me from my googling whether this curve is considered deficient or should be avoided for some reason, nor could I find any prior discussion about its inclusion in the stdlib crypto packages. If there is a reason that this curve should not be used then I understand not including it in crypto/*; in that case, this issue can serve as a record of that decision.
/cc @FiloSottile
To work with some Apple APIs, we need to use ECDSA keys with the NIST P-192 curve (secp192r1). It would be convenient if this curve were implemented by crypto/x509 and crypto/elliptic such that functions like
x509.ParseECPrivateKeyandx509.ParsePKIXPublicKeyworked with such keys. The crypto/x509 interface can't be used directly with our own curve definitions; in order to support P-192 we have to copy-paste various bits of crypto/x509 code.It's not clear to me from my googling whether this curve is considered deficient or should be avoided for some reason, nor could I find any prior discussion about its inclusion in the stdlib crypto packages. If there is a reason that this curve should not be used then I understand not including it in crypto/*; in that case, this issue can serve as a record of that decision.
/cc @FiloSottile