Scute returning a full chain is confusing signing applications

[Damien Goutte-Gattat]

Hi,

I have been testing various PDF signing applications with Scute, and
found that several of them seem to be "confused" by the fact that Scute
may provide them with a full certificate chain instead of a single
certificate.

Specifically, I have tested:

* pdfsig, part of poppler <https://poppler.freedesktop.org/>
* Okular, part of the KDE environment <https://okular.kde.org/>
* LibreOffice <https://www.libreoffice.org/>
* JSignPDF <http://jsignpdf.sourceforge.net/>

The key intended for signing is on a Yubikey token. The corresponding
certificate, signed by my own pseudo-certification authority, is *not*
available on the token (the Yubikey's CertDO slot is too small for a
RSA-2048 certificate), but is loaded in my GpgSM keyring.

In that situation, since Scute cannot find the certificate on the token,
it gets it from GpgSM instead. But then, instead of only getting the
certificate itself, it gets the certificate *and* the chain of
certificates that signed it.

And this behaviour seems to be unexpected by some signing applications.
In fact, of the applications I tested, pdfsig is the only one who works
correctly (it generates a valid signature).

Okular *almost* works correctly: it generates a valid signature, but the
"signed by" label that it adds to the PDF shows the CommonName of the
root certificate, instead of the CommonName of the leaf certificate.

LibreOffice generates an invalid signature.

JSignPDF fails to sign, complaining that the certificate it got from the
PKCS11 token is not usable for signing.

The problem disappears completely if I patch Scute to get it to return
solely the leaf certificate:

---8<-----
--- scute-1.7.0.orig/src/gpgsm.c        2020-02-08 15:07:48.000000000 +0000
+++ scute-1.7.0/src/gpgsm.c     2022-09-12 20:36:24.142735383 +0100
@@ -136,7 +136,6 @@
     }
 
   DEBUG (DBG_INFO, "scute_gpgsm_get_cert: falling back to gpgsm");
-  search.with_chain = true;
   err = scute_gpgsm_search_certs (KEYLIST_BY_GRIP, kinfo->grip,
                                   search_cb, &search);
   return err;
--->8-----

Then all 4 signing applications successfully generate valid signatures
(and, in the case of Okular, with a correct user-visible label).

The fact that pdfsig has no trouble to deal with the chain returned by
Scute suggests that the other applications may be at fault, rather than
Scute itself. (I actually hope to find the time to investigate the other
applications further, and with any luck getting them fixed.)

But still I don't understand why Scute behaves differently depending on
whether the certificate is found on the token or not. If the certificate
is on the token, then Scute returns only that certificate; if not, Scute
returns the full chain obtained from GpgSM. What is the rationale for
this difference of behaviour?

Sorry for the long message, I hope the above is clear enough. I am happy
to try to provide more details if needed.

Best,

- Damien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220915/4a9dd56c/attachment.sig>