Right, based on the current impl, a simple "==" seems to work as it's
the same NamedCurve instance inside CurveDB. Well, I could also do a bit
of code refactoring and add an equals utility method to ECUtil so this
may work better with 3rd party provider's impl.
Thanks,
Valerie
On 7/2/2019 8:27 PM, Weijun Wang wrote:
368 private static boolean isCompatible(ECParameterSpec sigParams,
369 ECParameterSpec keyParams) {
370 if (sigParams == null) {
371 // no restriction on key param
372 return true;
373 }
374 return sigParams.equals(keyParams);
375 }
What does "sigParams.equals(keyParams)" mean here? What is the getClass() of
those 2 ECParameterSpec objects?
Or maybe you mean "==" because it is always a NamedCurve stored in CurveDB?
Thanks,
Max
On Jul 3, 2019, at 10:48 AM, Valerie Peng <valerie.p...@oracle.com> wrote:
Hi
Any one can help reviewing this fix? Some ECDSA certificates contains signature
algorithm identifiers with non-null parameter bytes. Before RSASSA-PSS support,
these parameter bytes are ignored, however, after RSASSA-PSS support, the
parameter bytes are passed to the underlying signature impl and this breaks the
ECDSA certificate verification. In order for the verification to succeeds, the
SignatureUtil class needs to be able to parse the parameter bytes for ECDSA
certificate and that SunEC provider needs to accept non-null signature
parameters.
Bug: https://bugs.openjdk.java.net/browse/JDK-8225745
Webrev: http://cr.openjdk.java.net/~valeriep/8225745/webrev.00/
Mach5 run is clean.
Thanks,
Valerie
