Envelope a message for another user when the current user (current session) does not have a registered keypair
3 years ago
Originally Published: 2001-04-25
Article Number
000054482
Applies To
S/MIME-C 2.0
The following steps were performed:
1.  Start a new session without generating a keypair, importing a PKCS #12, or generating a cert request.
2.  Import the recipient's cert
2a.  List the contents of the cert database to ensure that the CC_MINE store contains no certs and that the recipient's cert is in the CC_NON_ROOT store.
3.  Create an address book entry for the recipient cert.
4.  Create an enveloped only message, for the entry we just created.
Issue
Envelope a message for another user when the current user (current session) does not have a registered keypair
SmtMsg_EncryptAndSign returns E_NO_KEYS
Cause
The S/MIME-C 2.0 Library Reference Manual says on p.214 that an SMT_E_NO_KEYS error can be returned if the "User sending the message either has no private key for a requested signing operation or has no certificate for encrypting the message for himself or herself" That is an indirect way of saying that the toolkit, when creating an enveloped message, always includes the sender of the message in the list of recipients.  The reason is that presumably, the sender wants to be able to decrypt that message in the future.  It's the same reason why we want to be able to save our sent items in email. Granted, not everyone wants to do this.  Ideally, we'd have a flag to specify whether or not the current user should be included in the list of recipients.
Resolution
Enhancement Request #17642 has been filed against S/MIME-C for this issue.  It is not likely that this will happen, since this change requires a change in the defined behavor of the toolkit, it will not be picked up in a bug-fix release.  It will have to appear in a release that includes new functionality.  Currently, only bug-fix releases are planned for S/MIME-C.  Remember that in S/MIME-C, the high-level APIs come at the cost of flexibility.  Consider Cert-C as an alternative, which is a lower-level toolkit and provides more flexibility.  You have complete control over the recipient list of an enveloped message in Cert-C

You must have a keypair for the user in S/MIME-C as the sender is always included in the list of recipients.

You may be tempted to just use some arbitrary keypair for the sender to workaround this problem.  Be aware of the security implications.  That 'temporary' sender's private key must be kept secure, since it can be used to open the envelope.
Don't see what you're looking for?