Currently i'm updating my x.509 certificate library to support ECC. Most of the builders that are implemented take a publicKey and derive the algorithm and such from the key. In RSA this is simple, you check the algorithm of the key and you can verify the bit length. However with ECC the key is based on a curve, and the curve name (of course) needs to be specified in the certificate (as OID).
The issue i'm working on right now is finding a way to come from either a java.security.interfaces.ECPublicKey or a org.bouncycastle.jce.interfaces.ECPublicKey to a curve name. (Both implementations are completely different from each other...)
One way i can think of is getting the key's ECPoint and validate that it is on a given curve. This way i can test all supported curves, this however feels cumbersome at runtime and possibly error prone if there are points overlapping 2 or more curves.
Another way is to get the ECCurve (bc implementation) or the EllipticCurve (jre implentation) and compare the curve details with the supported implementations. This also involves stepping through every known curve.
Does anybody know a better way of finding the curve name based on curve or publicKey details using jre(8/9) and bc only. And what is your feeling about the first solution, how likely would it be to get false hits.
I think i've found a valid solution using the EC5Util class for the jre type specifications. All of the double class instances with the same name make it a bit messy, however the functions are now accessible and useable.
From your description it appears what you really need is the OID, not the name. If so, that's easier, since the curve OID is present in the "X.509" encoding of an EC public key, which is actually the
SubjectPublicKeyInfo
structure from X.509 (replicated in PKIX, see rfc5280 #4.1 and rfc3279 #2.3.5 but skip the parts about explicit parameters, everybody uses the namedCurve=OID option) which is the encoding for JCA public keys, for both Sun/Oracle/OpenJDK and BC implementations (and all algorithms not just ECC). BC additionally provides good support to parse this structure:and for completeness even without Bouncy it's not hard if you don't use the largest curves and you're willing to cheat (which Java increasingly discourages):
I'd also note if you're building a certificate,
PublicKey.getEncoded()
is already the entire subjectPublicKeyInfo field, which is the only place you need to put the curve OID and except for self-signed the only place you put this key's algorithm OID.