Debugging Starting Point for S/MIME Signature Verification?

Debugging Starting Point for S/MIME Signature Verification?

[Alexander Adolf]

Hello,

I am looking at S/MIME messages that are signed only, i.e. are not
encrypted. For some, a signature status button is inserted, for others
not.

I have used edebug to look into some of the notmuch-show-* functions,
and it seems that for those signed messages that are displayed without
the signature status button, the :sigstatus property is nil when the
first notmuch-show-* function is called for the message already.

Where in the elisp code should I look for the :sigstatus property being
determined and set?


Any hints appreciated, and many thanks in advance,

  --alexander

Re: Debugging Starting Point for S/MIME Signature Verification?

[David Bremner]

Alexander Adolf <alexander.adolf@condition-alpha.com> writes:

> Hello,
>
> I am looking at S/MIME messages that are signed only, i.e. are not
> encrypted. For some, a signature status button is inserted, for others
> not.
>
> I have used edebug to look into some of the notmuch-show-* functions,
> and it seems that for those signed messages that are displayed without
> the signature status button, the :sigstatus property is nil when the
> first notmuch-show-* function is called for the message already.
>
> Where in the elisp code should I look for the :sigstatus property being
> determined and set?
>
>
> Any hints appreciated, and many thanks in advance,
>

I guess you should start with "notmuch show --verify --format=json
$msg | jq"  on the command line. If the information is not there,
nothing in the elisp will create it. You can use sexp output if you
prefer, but it is easier to pretty-print the json.

d

Re: Debugging Starting Point for S/MIME Signature Verification?

[Alexander Adolf]

David Bremner <david@tethera.net> writes:

> [...]
> I guess you should start with "notmuch show --verify --format=json
> $msg | jq"  on the command line. If the information is not there,
> nothing in the elisp will create it. You can use sexp output if you
> prefer, but it is easier to pretty-print the json.

Thanks for the pointer, David! Your hint seems bang on.

First of all, it spits an error on stderr:
---------------------------- Begin Quote -----------------------------
Failed to verify signed part: Cannot verify multipart/signed part:
signature content-type does not match protocol.
----------------------------- End Quote ------------------------------

The top-level multipart/signed has:
---------------------------- Begin Quote -----------------------------
Content-Type: multipart/signed;
	protocol="application/x-pkcs7-signature";
	micalg=SHA1;
	boundary="----=_NextPart_000_0978_01D7F747.BB1F7A60"
----------------------------- End Quote ------------------------------

And the signature part starts:
---------------------------- Begin Quote -----------------------------
------=_NextPart_000_0978_01D7F747.BB1F7A60
Content-Type: application/pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"
----------------------------- End Quote ------------------------------

So it seems it's "x-pkcs7-signature" not matching "pkcs7-signature" that
prevents the signature check from happening.

"x-pkcs7-signature" is a legacy media type, ans was deprecated with
RFC 2311 [1] back in March 1998 already.

A similar issue seems to have been discussed in Mozilla Bug 148232 [2]
back in 2002. Comment 7 on that bug [3] mentions RFC 2311, and it seems
the conclusion of the Mozilla devs at the time was to treat
"x-pkcs7-signature" as an alias for "pkcs7-signature" [4].

[1] https://datatracker.ietf.org/doc/html/rfc2311
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=148232
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=148232#c7
[4] https://bugzilla.mozilla.org/attachment.cgi?id=93002&action=diff

Of course it is a pain in parts I am too polite to mention right now,
that 20 years on email tools still generate the deprecated, proprietary
"x-" media type.

Nonetheless, I would still dare to make a case for adding a
corresponding alias treatment in notmuch. Not only for the sake of
catering for messages sent by dumb, current, proprietary email
implementations (read: interoperability), but also to enable signature
verification on those really old messages in people's archives.

Ready to be shot down in flames... ;-))


Cheers,

  --alexander

Re: Debugging Starting Point for S/MIME Signature Verification?

[David Bremner]

Alexander Adolf <alexander.adolf@condition-alpha.com> writes:

>
> Nonetheless, I would still dare to make a case for adding a
> corresponding alias treatment in notmuch. Not only for the sake of
> catering for messages sent by dumb, current, proprietary email
> implementations (read: interoperability), but also to enable signature
> verification on those really old messages in people's archives.
>

As far as I can tell from a quick look at the gmime (the library which
handles this for us) source, that alias should already be there. I'm
guessing there is something else peculiar about the mime structure, or
maybe a bug in gmime. Can you get a signed message from this MUA that
you can share?

d

Re: Debugging Starting Point for S/MIME Signature Verification?

[David Bremner]

Alexander Adolf <alexander.adolf@condition-alpha.com> writes:

>
> Nonetheless, I would still dare to make a case for adding a
> corresponding alias treatment in notmuch. Not only for the sake of
> catering for messages sent by dumb, current, proprietary email
> implementations (read: interoperability), but also to enable signature
> verification on those really old messages in people's archives.
>

This should be fixed in Gmime commit
0dfc44ad5b8f4eb1dbcfb010dddc02675a699ab8, although I haven't tested it
personally. If you want to test you will either need to build gmime from
source or wait for a gmime release.

d

Re: Debugging Starting Point for S/MIME Signature Verification?

[Alexander Adolf]

David Bremner <david@tethera.net> writes:

> [...]
> This should be fixed in Gmime commit
> 0dfc44ad5b8f4eb1dbcfb010dddc02675a699ab8, although I haven't tested it
> personally. If you want to test you will either need to build gmime from
> source

Head scratcher...

> or wait for a gmime release. [...]

I'll rather do that. ;-)

Many thanks again for your support!!! I'll hold my breath for the next
gmime release, and will be in touch again if that shouldn't solve it.


Cheers,

  --alexander