Mailing List Archive

Scute returning a full chain is confusing signing applications
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
Re: Scute returning a full chain is confusing signing applications [ In reply to ]
Hi!

I am currently using the t6002 branch which has a couple of small fixes.
For example commit ca9b9a4d9eed avoids hangs due to broken certificate
chains (it happens that I have some on my keyring). I am in general
satisfied wit the current state of things and that branch will soon be
merged. In particular osslsigncode works now every well with that
version. I could not fully test PDF signing because NSS does not
support Brainpool (which are used in Germany for qualified signatures).
Gniibe is working on getting a fix to NSS into Debian's version of NSS,
though.

On Thu, 15 Sep 2022 00:25, Damien Goutte-Gattat said:

> In fact, of the applications I tested, pdfsig is the only one who works
> correctly (it generates a valid signature).

Interesting because it seems to use NSS as well.

> 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?

I can't tell anymore; its too long ago:

2008-09-29 Marcus Brinkmann <marcus@g10code.com>

* src/gpgsm.c (struct search): New member WITH_CHAIN.
(search_cb): Only load chain if WITH_CHAIN is true.
(scute_gpgsm_get_cert): Call search_cb in the agent code path.


I would suggest that for now we use a new option (/etc/gnupg/scute.conf)
to either enable or disable chain lookups.


Salam-Shalom,

Werner


--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein
Re: Scute returning a full chain is confusing signing applications [ In reply to ]
On Thursday, 15 September 2022 08:46:45 BST Werner Koch wrote:
> I am currently using the t6002 branch which has a couple of small fixes.
> For example commit ca9b9a4d9eed avoids hangs due to broken certificate
> chains (it happens that I have some on my keyring). I am in general
> satisfied wit the current state of things and that branch will soon be
> merged.

Good to know, I shall redo my tests with that branch.


> I would suggest that for now we use a new option (/etc/gnupg/scute.conf)
> to either enable or disable chain lookups.

Happy with that solution. I'll try to come up with a patch soon.

Best,

- Damien