how to integrate ca-certificates with gpgsm (for email s/mime signature verification)

[Daniel Kahn Gillmor]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190609/e5b93f5e/attachment.sig>