bug#67931: [PATCH] Use S/MIME key from content for mail signing via OpenSSL

[Eric Abrahamsen]

Illia Ostapyshyn <illia@yshyn.com> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> The patch seems to work as intended -- I won't claim to know enough
>> about SMIME to know if it does the right thing or not. Can you briefly
>> explain what the additional certificates actually do, and why they're
>> useful in signing but not in encryption?
>
> End-user SMIME certificates are signed by the (intermediate) CAs that
> issued them.  The issuer's certificate can be in turn signed by another
> CA up the hierarchy, resulting in a chain that ends with the implicitly
> trusted root authority.  When signing a message, you can include the
> intermediate CA certificates, allowing the recipient to verify the whole
> chain.  With openssl, this is done via the -certfile argument [1]:
>
> -certfile file
>     Allows additional certificates to be specified. When signing these
>     will be included with the message. When verifying these will be
>     searched for the signers certificates. ...

Thanks! So basically like TLS cert chaining.

> Encryption is orthogonal to this: it only uses the public keys of your
> recipients from their certificates, the chain is irrelevant.

I'm mostly trying to understand how broken this was, prior to this
patch. Obviously there was the hard-coding of the key, the original
issue. Has encryption been broken this whole time, too?

Encryption is a separate MML tag, right? And also a separate cert (the
recipient's, not the user's). Why would additional certificates on your
own certfile interfere with the process of encrypting to the user?

I'm not trying to be difficult, I'd just like to have a better grasp of
what's going on here!

> The MML tag parameter names are a bit unfortunate here: the new
> `chainfile' parameter translates to "-cerfile" arguments and the
> existing `certfile' parameters translate to positional "recipcert"
> arguments of openssl [1].

I'm not too concerned about that, the vast majority of the time this
process should be automatic.

Eric