Mailing List Archive

how to integrate ca-certificates with gpgsm (for email s/mime signature verification)
Hi gnupg users and developers, ,

I use notmuch-emacs to read my email and sometimes do use GnuPG,
therefore notmuch-emacs is configured to verify signatures but
does so also for S/MIME signatures. When displaying such emails
I'm asked if I trust the respective Root CAs Cert. That's tedious.

Therefore I would like to integrate certificates provided by
debians ca-certificates package with gpgsm, but the only way I
found to do so, would be to manually import all those
certificates.

Isn't there an option to read in those certs from /etc/ssl... at
start-up?

Ciao; Gregor


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: how to integrate ca-certificates with gpgsm (for email s/mime signature verification) [ In reply to ]
Hi Gregor, everyone--

On Wed 2019-06-05 19:10:57 +0200, Gregor Zattler wrote:
> I use notmuch-emacs to read my email and sometimes do use GnuPG,
> therefore notmuch-emacs is configured to verify signatures but
> does so also for S/MIME signatures. When displaying such emails
> I'm asked if I trust the respective Root CAs Cert. That's tedious.

I agree that this is not only tedious -- it's an impossible question for
users to answer, especially if the signature verification is done at
indexing time, when the user doesn't even have a smidgen of context.

See also https://bugs.debian.org/888025 for a mutt+gpgsm example of this
kind of frustration. (i'm cc'ing that bug report since it has seen no
decisive action; perhaps this discussion will help move things along
there)

The current behavior is:

The user sees "do you ultimately trust XXX to correctly certify user
certificates?", with "cancel" and "yes".

If they answer "yes", they're asked "please verify that the
certificate identified as XXX has the fingerprint YYYY", with
"cancel", and "correct"

i can't imagine any situation where a user is equipped to answer the
first question -- even if they believe that it's being asked in good
faith. and the second question is somehow even more impossible. What
certificate? How is the user supposed to know what to verify here?

> Therefore I would like to integrate certificates provided by
> debians ca-certificates package with gpgsm, but the only way I
> found to do so, would be to manually import all those
> certificates.

I'm one of the debian maintainers for gnupg, and i admit that i haven't
put a lot of work into the gpgsm system integration. I did a bit of
digging just now, and i've got some ideas, but be warned that i haven't
dug deeply into the tradeoffs here yet. i welcome feedback!

looking at the documentation for trustlist.txt in gpg-agent(1) (it seems
odd to have it documented there, since i thought gpg-agent was for
secret key material only, weird!), it looks like trustlist.txt has an
`include-default` option, which maybe defaults to
`/etc/gnupg/trustlist.txt` on debian (i haven't done much testing!)

Of course, gpgsm has to learn about these root certificates somehow as
well, and i think doesn't have an easy way to make use of a separate
keybox (perhaps Werner or another GnuPG dev can correct me on this).

Read gpgsm(1), i see that /usr/share/gnupg/com-certs.pem could be set up
as a symlink to /etc/ssl/certs/ca-certificates.crt. But this only works
to import those root certificates at the initial creation of
pubring.kbx, so it won't work in an ongoing way (e.g. when
ca-certificates gets updated, they won't be updated.

So, what can Debian do to improve this integration? here is a series of
suggestions of changes to the gnupg2 source package in debian (i have no
code to back them up yet, commentary and patches welcome):

* make sure gpgsm Recommends: ca-certificates

* add /etc/ca-certificates/update.d/gnupg to the gpgsm package (see
update-ca-certificates(8) for a description of this hook), which
should maintain /var/lib/gnupg/trustlist.txt and
/var/lib/gnupg/ca-certificates.kbx . (Maybe add a postinst script to
invoke this as well?)

* consider adding a symlink (a conffile, yuck):

- /etc/gnupg/trustlist.txt ? /var/lib/gnupg/trustlist.txt

* add a symlink to the gpgsm package:

- /usr/share/gnupg/com-certs.pem ? /etc/ssl/certs/ca-certificates.crt

* (maybe) change the default of gpg-agent's allow-mark-trusted to be
false, rather than true. This is both a safety precaution, and a
usability improvement, since i can't think of a context in which the
user is well-prepared to actually answer these questions in the way
that they're presented.

This is still imperfect (the client has no way to learn of certiifcates
added via ca-certificates after they've first populated their
pubring.kbx), but it strikes me that it would be a strict improvement
over the status quo.

What do you think?

After doing a brief review, i have a bunch more questions for GnuPG
upstream too:

* Could i convince you to search for trustlist.txt in
/var/lib/gnupg/trustlist.txt as the system default, if
/etc/gnupg/trustlist.txt is not found?

That is, if no trustlist.txt is present in $GNUPGHOME, or if
$GNUPGHOME/trustlist.txt has the include-default directive, it looks
first for /etc/gnupg/trustlist.txt. if it is found, it uses it. if
it is not found, it looks in /var/lib/gnupg/trustlist.txt.

That would relieve me of needing to maintain a conffile in the debian
package, which i would strongly prefer.

* if i have an auto-generated /var/lib/gnupg/ca-certificates.kbx that
is kept in sync with the system trustlist, is there a way that i can
coax gpgsm to use it as a secondary (read-only) keyring by default?
(i'm not asking for presence in this keyring to be used to infer
trust; just that these certificates are always known, and can
therefore be referenced (or deliberately ignored or marked
untrustworthy) in the user's trustlist.txt. Is such an option
available already? the gpgsm(1) manpage doesn't even mention
--keyring, but it seems to support --keyring anyway. so maybe there
are other options i'm not aware of that could do this already, like
some sort of --system-keyring ?

* can i convince you to disable "allow-mark-trusted" in gpg-agent by
default? What is the use case where this seems like a sensible thing
to offer?

* can we improve the documentation of trustlist.txt? From the comments
auto-written to this file, it looks like it's intended to be part of
the GnuPG family's "API" -- users are told how to deal with this file
when editing it directly. If that's the case, we really need to know
what it is supposed to do, in a concise and easily findable way.

gpgsm(1) refers to it, but doesn't direct the user toward any other
documentation. The comments written into the file when it is
auto-generated are unclear. what does the 'S' and 'P' and '*' flag
mean? (in the codebase, i see that they mean "S/MIME" and "PGP" and
either, but that's still unclear. what is the fingerprint *of* -- is
it the X.509 certificate? if so, what could 'P' possibly mean? Is it
the OpenPGP v4 fingerprint? if so, what could 'S' possibly mean?
What would this fingerprint mean for '*'? if it's 'P', does that
mean it has an effect on gpg and not just gpgsm?)

doc/debugging.texi claims:

You may use the @code{relax} flag in @file{trustlist.txt} to
accept the certificate anyway. Note that the fingerprint and this
flag may only be added manually to @file{trustlist.txt}.

And yet, when i use:

gpg-connect-agent "$DIGEST S whatever" /bye

it seems to add the "relax" keyword.

The header auto-written into trustlist.txt is not only bulky -- it's
prone to falling out of date. If this were better documented, and
that documentation were placed someplace stable by the installed
package, then when writing out a trustlist.txt, you could just have a
one-line header pointing to the documentation.



To be clear, my goals here are similar to my goals for gpg:

* default user configuration should be as close as possible to no
configuration at all

* the default system configuration should also be as close to no
configuration as possible.

* the package should ship with good documentation in a stable,
easily-findable place.

* the defaults should be well integrated into the host operationg
system.

* it should be possible for the user to have their user account diverge
from the system defaults as narrowly as possible, while still
receiving updates to the system defaults during package upgrades that
retain their divergences.

* it should be possible for the system administrator to have the system
defaults diverge as narrowly as possible from the package defaults,
without doing a lot of work at package upgrade to retain that
divergence.

Happy to hear any feedback about these suggestions and questions!

--dkg