DSA and ECDSA signature format is incompatible with XMLDSig

[Sean Mullan]

Hi,

I would like to try to fix 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 
like .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. I could live with this until now because it was limited to DSA which 
wasn't in wide use. But now the same problem comes up with ECDSA.

I would really like to clean this up. There seems to be a couple of ways we 
could fix this:

1. Add new standard signature format strings that identify the format: ex:

   SHA1withDSAandP1363
   SHA1withECDSAandP1363
   SHA256withECDSAandP1363
   SHA384withECDSAandP1363
   SHA512withECDSAandP1363

I like this the best, but 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. My suggestion is that we use a keyword (ex: Format) that 
clearly distinguishes it from an MGF:

   <digest>with<encryption>and<format>Format

ex:

   SHA256withECDSAandP1363Format

2. Add a new AlgorithmParameterSpec subclass that specifies the format, and then 
call Signature.setParameter before generating/verifying the signature.

I'm not thrilled by this option, because this isn't really a standard input 
parameter, and will cause problems if/when you want to use it with an algorithm 
that does require input parameters (like an RSA PSSParameterSpec)

3. Add a higher level DSA/ECDSA Signer API that returns the r and s as 
BigIntegers and leaves the encoding of those bytes to the application.

This is a very clean solution, but is more of a significant API change as it 
would be introducing a new higher level API for generating/validating signatures.

4. Do nothing

Live with it :(

-------

Any other comments, suggestions?

Thanks,
Sean