Bootstrapping dual SMIME certificates for signing and encryption?

Question

To maintain the non-repudiation property of signing while still having escrow for the encryption key, it's recommended to have a separate certificates (and pub-priv keys) for signing (say CertSign) and encryption (say CertEnc).

Assuming a certain Alice with Alice-CertSign and Alice-CertEnc, from a practical perspective (modern mail clients), how are those two certificates distributed to Bob, Charlie, David etc so they can verify messages from Alice and send her encrypted messages?

If Alice sends a blank message to folks, would/does her email client send a concat of Alice-CertSign and Alice-CertEnc as an attachment? Any de-facto or de-jure standards on this bootstrap problem?

Driving this curiosity is a single-certificate experiment I just did via Comodo's free SMIME certificates. It does signing and encryption in a single certificate with non-repudiation bit NOT set (unsure if they keep a copy ... "behind"). On iOS6 that sends that single certificate as well as a signature inside as the smime.p7s attachment (which I couldn't run through openssl cms... - openssl pkcs7 ... only dumps certs).

Answer 1

The de jure standard is RFC 5751. In particular, see section 2.5.3: among the attributes which can be attached to a signature (a SignerInfo) is one called "SMIMEEncryptionKeyPreference" which identifies the certificate that the sender would like people to use when they send encrypted replies to him. The certificate itself is supposed to be included in the CertificateSet attached to the SignedData object.

Beyond the ASN.1 jargon, this means that the bootstrapping works thus: user A sends to user B a signed email; the signature not only authenticates the email itself, but includes a set of attributes which give to B enough information to send an encrypted reply to A, in particular A's encryption certificate, and an unambiguous designation of the specific certificate to use for encryption, in case the certificate contents are not enough (for instance, if user A has a certificate with a Key Usage extension which marks it as "signature only", and another certificate which is marked as "encryption only", then there is hardly any ambiguity).

Whether this will work well with existing MUA software is another question, which can only be answered through tests.