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
