What is Miklos hacking - Tags: xmlsec

I created a toy project to experiment with a few technologies I wanted to try
out (cmake,
googletest,
xmlsec outside LibreOffice,
libzip and AppVeyor). The
result is a tool with a similar interface as pdfsig from poppler (for PDF
files), just for ODF: a cmdline executable to verify the digital signature(s)
in an ODF document.

The source code now has CI on Linux and
Windows, so perhaps in a shape that is interesting for others to have a look
as well. And if not, then no problem, it was interesting to put together these
building blocks and see them working as expected. :-)

I wrote about ECDSA handling in LibreOffice
last year, back then the target
was to be able to verify signatures using the ECDSA algorithm on Linux.

Lots of things happened since then, this post is meant to summarize those
improvements. My personal motivation is that Hungarian eID cards come with a
gov-trusted ECDSA (x509) cert, so handling those in LibreOffice would be nice.
My goals were:

platforms: handling Windows as well, not only Linux/macOS

operations: handling signing as well, not only verification

formats: cover all of ODF, OOXML and PDF

Let’s see what has happened:

Linux, ODF, sign: we had hardcoded RSA algorithm when generating a signature, now
we infer the sign algorithm from the signing cert algorithm
(commit)

Windows, PDF, sign: the certificate chooser had to be ported to from
CryptoAPI to
CNG
(commit)

Windows, ODF, verify / sign: this was the largest problem, this required a
whole new libxmlsec backend
(interface,
implementation, all in
C90) and also required conditionally using that new backend in LibreOffice
(commit)

Windows, OOXML, sign: this was almost functional, except that the UI
recently regressed, now fixed
(commit)

Finally now that everything is ported on Windows to use CNG, I could enable
it by default yesterday.

I could test hardware-based signing after this, which was fine out of the box
on both platforms. Some screenshots:

Linux:

Windows:

(There is no reason why this would not work on macOS, but I did not test that.)

Thanks Gabor Kelemen who helped me to get a sane card reader that has
reasonable driver support on Linux.

All this is available in master (towards LibreOffice 6.2), or you can grab a
daily build and try it out
right now. :-)

Last month a
LibreOffice
bugreport was filed, as the ODF signature created with Hungarian citizen eID
cards is not something LibreOffice can verify. After a bit of research it
seemed that LibreOffice and NSS (what we use for crypto work on Linux/macOS)
is not a problem, but xmlsec’s NSS backend does not recognize ECDSA keys (RSA
or DSA keys work fine).

After this the xmlsec code looked good enough. I had to request an update of
the bugdoc in the TDF bug twice, as the signature itself looked also incorrect
initially:

an attribute type in the signature that had no official abbreviation was
described as "UNDEF" instead of the dotted decimal form

RFC3279 specifies that an
ECDSA signature value in general should be ASN1-encoded in general, but
RFC4050 is specific to XML
digital signatures and that one says it should not be ASN1-encoded. The
bugdoc was initially ASN1-encoded.

Finally a warning still remains: while trying to parse the text of the
<X509IssuerName> element, the dotted decimal form is still not parsed (see
this NSS bugreport). The
bug is confirmed on the mailing list, but no other progress have been made so
far.

Oh, and of course: Windows is still untouched, there a bigger problem remains:
we use CryptoAPI (not CNG) there, and that does not support ECDSA at all.
Hooray for open-source libs where you can add such support yourself. ;-)