Created attachment 131179 [details]
LibreOffice document with ECDSA signature
I have created a digitally signed LibreOffice document, where ECDSA signature was calculated over the SHA-256 hash of canonicalized SignedInfo XML node. I opened it with LibreOffice 184.108.40.206 but signature verification failed. On low-level I could test the signature with OpenSSL v1.0.1c: result was "Verified OK". (I also performed a negative test to be sure that OpenSSL works well.)
openssl dgst -sha256 -out SignatureValue_verified.txt -keyform PEM -verify Aron_Szabo_end_signer-public_key.pem -signature SignatureValue_binary.txt SignedInfo_to-be-hashed.txt
Could you check ECDSA support on low-level, under XMLSec Library? (I attached test files...)
Relevant modules of my environment:
LibreOffice 220.127.116.11 (x64)
Windows 8.1 Pro (x64)
.NET Framework 4.6.2 (x64)
Created attachment 131181 [details]
Created attachment 131182 [details]
Created attachment 131183 [details]
base64-encoded public key from X.509 certificate
dbgutil build prints this error:
warn:xmlsecurity.xmlsec:31557:1:xmlsecurity/source/xmlsec/errorcallback.cxx:48: transforms.c:1571: xmlSecTransformNodeRead() '' 'xmlSecTransformIdListFindByHref' 1 'href=http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256'
warn:xmlsecurity.xmlsec:31557:1:xmlsecurity/source/xmlsec/errorcallback.cxx:48: transforms.c:704: xmlSecTransformCtxNodeRead() '' 'xmlSecTransformNodeRead' 1 'name=SignatureMethod'
warn:xmlsecurity.xmlsec:31557:1:xmlsecurity/source/xmlsec/errorcallback.cxx:48: xmldsig.c:775: xmlSecDSigCtxProcessSignedInfoNode() '' 'xmlSecTransformCtxNodeRead' 1 'node=SignatureMethod'
warn:xmlsecurity.xmlsec:31557:1:xmlsecurity/source/xmlsec/errorcallback.cxx:48: xmldsig.c:568: xmlSecDSigCtxProcessSignatureNode() '' 'xmlSecDSigCtxProcessSignedInfoNode' 1 ' '
warn:xmlsecurity.xmlsec:31557:1:xmlsecurity/source/xmlsec/errorcallback.cxx:48: xmldsig.c:386: xmlSecDSigCtxVerify() '' 'xmlSecDSigCtxSignatureProcessNode' 1 ' '
Look like the first problem is that xmlsec doesn't recognize the http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256 string as a valid value for <SignatureMethod Algorithm="..."> when it uses a non-openssl backend (which is a problem for us, as we use the mscrypto/nss backends).
Marking as confirmed.
Created attachment 131436 [details]
LibreOffice document with ECDSA signature (fixed, 2017-02-24)
I have uploaded a fixed version of the LibreOffice document with ECDSA signature.
The reason: the unknown name elements of Subject/Issuer fields of the certificates are escaped to 'UNDEF' string instead of their OID value as string by OpenSSL library of PHP. This OID-to-string conversion was fixed in the case of unknown organizationIdentifier (18.104.22.168) name element.
C=HU,L=Budapest,O=NISZ Nemzeti Infokommunikációs Szolgáltató Zrt.,CN=Állampolgári Tanúsítványkiadó - Qualified Citizen CA,22.214.171.124=VATHU-10585560
It seems this signature still has a small problem, https://tools.ietf.org/html/rfc4050#section-3.3 says ECDSA signature value should be just the (r,s) pair as-is (with base64 encoding), while the sample applies the ASN1 encoding suggested by https://tools.ietf.org/html/rfc3279#section-2.2.3 -- which is an earlier RFC + applies in general, not in particular to xmldsig.
The result is that xmlsec refuses to verify the signature currently.
Created attachment 131679 [details]
LibreOffice document with ECDSA signature (fixed, 2017-03-06)
Thanks for the update, xmlsec now accepts this on Linux/macOS. Let me use this bug for the xmlsec/nss scenario and once it works, we could have a follow-up bug for the Windows part. Though that won't be too easy, since CryptoAPI doesn't seem to support ECDSA.
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":
tdf#105983 libxmlsec: backport NSS / ECDSA patches
It will be available in 5.4.0.
The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
Follow-up for the Windows part is bug 98545.