Author Topic: S/MIME Signature without Certificate?  (Read 553 times)

Chilkat

  • Administrator
  • Full Member
  • *****
  • Posts: 103
  • Karma: +6/-0
    • View Profile
S/MIME Signature without Certificate?
« on: January 10, 2018, 07:57:42 AM »
I have an S/MIME question.

One of our communication partners incorrectly builds the email.
It does not integrate its certificate into the e-mail, but only that of the certificate manufacturer.

If I check the signature with mime.verify in MFC, of course, I get the message that it was signed incorrectly.

The communication partner says he does not have to pass his certificate in S/MIME, we should record it ourselves.
But I cannot pass a certificate to the Verify function either.

All other partners integrate your certificate correctly in the S/MIME.

So I'm pretty sure that the communication partner makes a mistake. Do you agree with me?
Or do I understand something wrong?

Thank you in advance and many greetings

Chilkat

  • Administrator
  • Full Member
  • *****
  • Posts: 103
  • Karma: +6/-0
    • View Profile
Re: S/MIME Signature without Certificate?
« Reply #1 on: January 10, 2018, 08:16:24 AM »
This is a great question.

First, there should be no fear of providing one's digital certificate to one's partner.  The digital certificate contains the public key, and never contains the private key.  Other formats, such as .pfx (.p12), Java KeyStores, etc. are containers that contain both unencrypted certificates and the encrypted/protected private keys.  One would never give a .pfx w/ password to another party, unless of course it's a test cert + private key.

For signature verification, the certificate's public key is required.  (The private key was used in signing the message, and the public key is used to verify.)   If the partner does not provide the certificate in the S/MIME signature (and the certificate in turn contains the public key), then he must provide an unambiguous means for you to locate his certificate from your own certificate stores.  In other words, your partner would've needed to previously provide you with his certificate so that you can "install" it on your system (or just keep it as a file where you can locate it).  Embedding the certificate makes it convenient.  Internal to the S/MIME PKCS7 signature, there is always something called a "SignerInfo" construct, and this contains the signing certificate's IssuerName + serial number, and from that information the signer's certificate can be located on your local system to retrieve the public key for verification.

On a Windows system, the Chilkat API will automatically try to find the matching certificate (by issuer name + serial number) in the Windows registry-based certificate stores.  There are also methods where you can explicitly provide the cert to be used for signature verification.

In summary, your partner does not need to include his certificate in the signature, but he SHOULD.  If he does not, then it is required that beforehand, he should've provided you with his certificate so that you can install it on your system.  (But what a pain-in-the-arse that is..  Now there's something to remember every time you run your software on another system -- can't forget to install each of your customer's certs -- for those customers, who for no apparent/good reason, decide it's prudent to not simply create S/MIME in the typical fashion.)