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
signature.asc
Description: PGP signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
