JDK-6971317 : Add new DSA/ECDSA algorithms that use IEEE P1363 format
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 7
  • Priority: P3
  • Status: Resolved
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2010-07-22
  • Updated: 2024-04-12
  • Resolved: 2014-07-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdResolved
Related Reports
Duplicate :  
JDK-8042967 - Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes
Description
This CR proposes a solution to a long-standing XMLDSig issue with the current DSA and ECDSA signature bytes format.

The format of the Signature bytes for these algorithms is an ASN.1 encoded sequence of the integers r and s:

  SEQUENCE ::= { r INTEGER, s INTEGER }

Unfortunately, this is not compatible with XMLDSig (and other signature formats/implementations including PKCS#11 and .NET), which doesn't ASN.1 encode them and simply base64 encodes the raw bytes of r and s concatenated (the IEEE P1363 format).

So, our XMLDSig implementation always has to strip off, or decode the ASN.1 stuff after calling Signature.sign() when generating signatures, and ASN.1 encode the signature bytes before calling Signature.verify() when verifying signatures.
Comments
Probably won't get to this for JDK 8 but I would like to try to resolve this in JDK 9. Not urgent since the current workaround (as described above), although not ideal, works fine.
23-05-2013
SUGGESTED FIX Add new standard signature format strings that identify the format: ex: SHA1withDSAandP1363Format SHA1withECDSAandP1363Format SHA256withECDSAandP1363Format SHA384withECDSAandP1363Format SHA512withECDSAandP1363Format One issue with this is that the "and" extended format is reserved for MGF functions, ex: MD5withRSAandMGF1 and this is not a mask generation function. However, the MGF functions are only used with RSA (which P1363 is not applicable) and to help avoid name clashes I suggest we specify a keyword (ex: "Format") that clearly distinguishes it from an MGF: <digest>with<encryption>and<format>Format
22-07-2010