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
Assuming a certain Alice with
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-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).