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 5.3.0.3 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 5.3.0.3 (x64) Windows 8.1 Pro (x64) .NET Framework 4.6.2 (x64)
Created attachment 131181 [details] canonicalized SignedInfo
Created attachment 131182 [details] binary SignatureValue
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 (2.5.4.97) 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,2.5.4.97=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": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b5acaa42bb44ad358b0c126af18ea3bdf88d4bd3 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: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Follow-up for the Windows part is bug 98545.