From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id WCocLwH7tF+AYgAA0tVLHw (envelope-from ) for ; Wed, 18 Nov 2020 10:44:17 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id kAUIKwH7tF8aGwAA1q6Kng (envelope-from ) for ; Wed, 18 Nov 2020 10:44:17 +0000 Received: from mail.notmuchmail.org (nmbug.tethera.net [144.217.243.247]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (2048 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 85C46940430 for ; Wed, 18 Nov 2020 10:44:13 +0000 (UTC) Received: from nmbug.tethera.net (localhost [127.0.0.1]) by mail.notmuchmail.org (Postfix) with ESMTP id 9155A28C5A; Wed, 18 Nov 2020 05:44:04 -0500 (EST) X-Greylist: delayed 40701 seconds by postgrey-1.36 at nmbug; Wed, 18 Nov 2020 05:44:01 EST Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [134.119.228.108]) by mail.notmuchmail.org (Postfix) with ESMTPS id A619D270EF for ; Wed, 18 Nov 2020 05:44:01 -0500 (EST) Received: from [46.244.197.164] (helo=condition-alpha.com) by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1kfALv-0000yP-6M; Wed, 18 Nov 2020 00:25:35 +0100 Message-Id: <788a8c0090f2cb866b357bedc87d3b41@condition-alpha.com> From: Alexander Adolf To: David Bremner , notmuch@notmuchmail.org Subject: Re: emacs: error decrypting s/mime In-Reply-To: <878sb55vcp.fsf@tethera.net> References: <87a6vm1wid.fsf@tethera.net> <87eeky5d1q.fsf@tethera.net> <878sb55vcp.fsf@tethera.net> Date: Wed, 18 Nov 2020 00:25:34 +0100 MIME-Version: 1.0 X-Df-Sender: YWxleGFuZGVyLmFkb2xmQGNvbmRpdGlvbi1hbHBoYS5jb20= Message-ID-Hash: A2CG6Q3YHYQBLVJAC2TK7PNTXNVAJWK5 X-Message-ID-Hash: A2CG6Q3YHYQBLVJAC2TK7PNTXNVAJWK5 X-MailFrom: alexander.adolf@condition-alpha.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-notmuch.notmuchmail.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header CC: Daniel Kahn Gillmor X-Mailman-Version: 3.2.1 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 144.217.243.247 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Spam-Score: -1.01 X-TUID: HPsP7pjfF0e8 Hello David, first of all, many thanks for not giving up on this one! David Bremner writes: > [...] > I think this might be a deeper issue. Looking at the structure of > > test/corpora/protected-headers/smime-sign+enc.eml > > it looks like there is an application/pkcs-7 part for the outer > container with an encstatus, and one inside that (with the same mime > type) with a sigstatus. So maybe the right thing is to just ignore > missing encstatus? > [...] Conceptually, a typical s/mime message looks like this: ---------------------------------------------------------------------- Received: From: To: Subject: Date: MIME-Version: 1.0 Content-Disposition: attachment; filename="smime.p7m" Content-Type: application/x-pkcs7-mime; smime-type=enveloped-data; name="smime.p7m" [more headers (opt.)] gibberish (the CMS) ---------------------------------------------------------------------- After decrypting the gibberish (CMS), you get a new mime tree structure, in which the top-level entity can be a multipart/signed (most often), or a message/rfc822 (sometimes), or something else (rarely seen) [1]. [1] https://tools.ietf.org/html/rfc8551 I.e. you decrypt, and further mime parts appear. No assumptions should be made about the tree's structure. Quoting from [1]: ---------------------------- Begin Quote ----------------------------- 3.1. Preparing the MIME Entity for Signing, Enveloping, or Compressing S/MIME is used to secure MIME entities. A MIME message is composed of a MIME header and a MIME body. A body can consist of a single MIME entity or a tree of MIME entities (rooted with a multipart). S/MIME can be used to secure either a single MIME entity or a tree of MIME entities. These entities can be in locations other than the root. S/MIME can be applied multiple times to different entities in a single message. [...] ----------------------------- End Quote ------------------------------ After decrypting your "outer" container (the CMS), the result is a mime tree, i.e. should start with "Content-Type:". Standard mime tree processing should be applied (recursively). The bodypart handler error message shows this "embedded (inner) mime tree", and in my case the top-level entity is a multipart/signed. You wrote "the outer container with an encstatus, and one inside that (with the same mime type) with a sigstatus". So it seems that at that point you have access to the root of the "inner tree" (multipart/signed, you can access the sigstatus), but the content-type information is from the "outer" container (the CMS) still. Perhaps the recursive mime re-parsing after the decryption is not happening? More new questions than answers... --alexander