Hi,
Following up here with suggested language for the section associated with the
*inP1363Formatsignatures. I don’t have write access to the JBS bug as of yet.
The ECDSA signature algorithms, as defined by ANSI X9.62, with an output
defined in IEEE P1363 format. Both r and s are encoded as unsigned big-endian
integers that have been padded to be equal in length to the curve order. The
final encoded signature is the r ands concatenated as r || s, resulting in a
byte array that is exactly twice as long as the curve order.
The DSA signature algorithms, as defined by ANSI X9.62, with an output defined
in IEEE P1363 format. Both r and s are encoded as unsigned big-endian integers
that have been padded to be equal in length to the underlying group order q.
The final encoded signature is the r ands concatenated as r || s, resulting in
a byte array that is exactly twice as long as the group order.
From: "Jiva, Azeem" <javaj...@amazon.com>
Date: Tuesday, December 17, 2019 at 3:43 PM
To: "security-dev@openjdk.java.net" <security-dev@openjdk.java.net>
Subject: Incorrect documentation
Security experts,
The official Java Security Standard Algorithm Names incorrectly documents the
Signature.*withECDSAinP1363Format algorithms as
SEQUENCE ::= { r INTEGER, s INTEGER }
This is incorrect. The IEEE P1363 Format is defined as concatenating the r and
s values (with no ASN.1 encoding, but with appropriate padding). The
implementations appear correct. This just appears to be a documentation issue.
The documentation for Java 11, 12, and 13 would need to be updated.
I refer you to the Wikipedia page [2], item #7 that has the relevant information
Thank you.
[1]:
https://docs.oracle.com/en/java/javase/12/docs/specs/security/standard-names.html#signature-algorithms
[2]:
https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Signature_generation_algorithm
