unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
* difficulty in rendering S/MIME signature status from some certificates
@ 2021-05-26 23:32 Daniel Kahn Gillmor
  2021-05-27  1:44 ` [PATCH 1/2] cli/show: produce "email" element in sigstatus Daniel Kahn Gillmor
  0 siblings, 1 reply; 9+ messages in thread
From: Daniel Kahn Gillmor @ 2021-05-26 23:32 UTC (permalink / raw)
  To: Notmuch Mail


[-- Attachment #1.1: Type: text/plain, Size: 2499 bytes --]

Hi folks--

id:e4a7efe92433f7c3e5dedeac0ea4efc003020296.camel@ericsson.com from the
IETF LAMPS WG mailing list <spasm@ietf.org> can be found at 
https://mailarchive.ietf.org/arch/msg/quic/FpbJTLXsoFLSNr--LgxCOC6IssY.
when rendering it, notmuch-emacs shows:

     [ Good signature by: 1.2.840.113549.1.9.1=#6D61676E75732E7765737465726C756E64406572696373736F6E2E636F6D,CN=Magnus Westerlund,O=Ericsson ]

1.2.840.113549.1.9.1 is the OID for emailAddress in distinguished names.
This field which is deprecated according to
https://www.oid-info.com/get/1.2.840.113549.1.9.1 and §5.2.1 of
https://datatracker.ietf.org/doc/html/rfc2985#page-7, but it is still
very much in use as evidenced by the message's X.509 certificate, which
was issued less than a year ago (in 2020-12-11) with a 3-year validity
window.

I wanted this to make this visible in notmuch as the more legible form
"EMAIL=magnus.westerlund@ericsson.com,CN=Magnus Westerlund,O=Ericsson".
i tracked it down to a constraint in libksba's parsing code, and
reported it to GnuPG (libksba's upstream) here:
https://dev.gnupg.org/T5450 and the fix was rejected.

I don't think that notmuch should try to contain any string-to-DN
parsing code, and notmuch's use of gmime here is basically a passthrough
from gpgme, so i'm a bit stuck.

It occurs to me that maybe notmuch should be identifying the e-mail
address (and only the e-mail address?) instead of the other elements of
the user ID, which are more dubious than the e-mail address anyway.

It seems possible to do this by using the g_mime_certificate's email
field in preference to the g_mime_certificate's user_id field, at least
for this particular certificate, because it contains a subjectAltName of
type rfc822name that is just the e-mail address.

I see a couple different options available to do this:

 a) add an "email?" field to the "signature" object in devel/schemata,
    and then teach notmuch-emacs to render that instead of the userid
    field in cases where it's present.

 b) replace the content of the userid field in the "signature" object
    with the e-mail address entirely.

I'm leaning toward (a), though it requires fiddling in more places.  At
the very least, the first step of (a) doesn't seem objectionable.

(note: GMimeCertificate's email field itself is of somewhat dubious
provenance, and i'm trying to clean that up at
https://github.com/jstedfast/gmime/pull/102)

What do folks think?

        --dkg

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2021-06-27 17:22 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-05-26 23:32 difficulty in rendering S/MIME signature status from some certificates Daniel Kahn Gillmor
2021-05-27  1:44 ` [PATCH 1/2] cli/show: produce "email" element in sigstatus Daniel Kahn Gillmor
2021-05-27  1:44   ` [PATCH 2/2] emacs: Prefer email address over User ID when showing valid signature Daniel Kahn Gillmor
2021-06-07 12:07     ` David Edmondson
2021-06-07 12:24       ` Daniel Kahn Gillmor
2021-06-26 16:41     ` [PATCH] " David Bremner
2021-06-27 15:13       ` Daniel Kahn Gillmor
2021-06-27 17:21       ` David Bremner
2021-06-27 17:21   ` [PATCH 1/2] cli/show: produce "email" element in sigstatus David Bremner

Code repositories for project(s) associated with this public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).