Skip to main content
replaced http://tools.ietf.org/html/rfc with https://www.rfc-editor.org/rfc/rfc
Source Link

There should be no reason to include the trust anchor (aka "root CA") into a signed email, because if the chain is to have any value for the recipient, then that recipient must already have it. Including the root CA in the email would only induce recipients into grabbing the root CA from the received email and inserting it in their trust store, which is a big security breach, similar to sending your banking coordinates to every phishing attempt you receive.

Distribution of root CA is assumed to be performed "out-of-band" and with a secure medium (for instance, hardcoded in the "Thunderbird" software package which you already assume to be trustworthy, since you let it read and write your emails). Distributing root CA by email strikes me as... less than optimally secure.

The underlying format for S/MIME, i.e. CMSCMS, lets you store whatever certificates you want in a SignedData element (this is not a chain but a big unsorted bag of certificates and other objects). However, Thunderbird has a default behaviour of just putting the certificates for the signer's chain, excluding the root CA; to my knowledge, this is not configurable, and I cannot blame it because including the root CA would make little sense -- see above.

There should be no reason to include the trust anchor (aka "root CA") into a signed email, because if the chain is to have any value for the recipient, then that recipient must already have it. Including the root CA in the email would only induce recipients into grabbing the root CA from the received email and inserting it in their trust store, which is a big security breach, similar to sending your banking coordinates to every phishing attempt you receive.

Distribution of root CA is assumed to be performed "out-of-band" and with a secure medium (for instance, hardcoded in the "Thunderbird" software package which you already assume to be trustworthy, since you let it read and write your emails). Distributing root CA by email strikes me as... less than optimally secure.

The underlying format for S/MIME, i.e. CMS, lets you store whatever certificates you want in a SignedData element (this is not a chain but a big unsorted bag of certificates and other objects). However, Thunderbird has a default behaviour of just putting the certificates for the signer's chain, excluding the root CA; to my knowledge, this is not configurable, and I cannot blame it because including the root CA would make little sense -- see above.

There should be no reason to include the trust anchor (aka "root CA") into a signed email, because if the chain is to have any value for the recipient, then that recipient must already have it. Including the root CA in the email would only induce recipients into grabbing the root CA from the received email and inserting it in their trust store, which is a big security breach, similar to sending your banking coordinates to every phishing attempt you receive.

Distribution of root CA is assumed to be performed "out-of-band" and with a secure medium (for instance, hardcoded in the "Thunderbird" software package which you already assume to be trustworthy, since you let it read and write your emails). Distributing root CA by email strikes me as... less than optimally secure.

The underlying format for S/MIME, i.e. CMS, lets you store whatever certificates you want in a SignedData element (this is not a chain but a big unsorted bag of certificates and other objects). However, Thunderbird has a default behaviour of just putting the certificates for the signer's chain, excluding the root CA; to my knowledge, this is not configurable, and I cannot blame it because including the root CA would make little sense -- see above.

Source Link
Tom Leek
  • 173.8k
  • 29
  • 352
  • 483

There should be no reason to include the trust anchor (aka "root CA") into a signed email, because if the chain is to have any value for the recipient, then that recipient must already have it. Including the root CA in the email would only induce recipients into grabbing the root CA from the received email and inserting it in their trust store, which is a big security breach, similar to sending your banking coordinates to every phishing attempt you receive.

Distribution of root CA is assumed to be performed "out-of-band" and with a secure medium (for instance, hardcoded in the "Thunderbird" software package which you already assume to be trustworthy, since you let it read and write your emails). Distributing root CA by email strikes me as... less than optimally secure.

The underlying format for S/MIME, i.e. CMS, lets you store whatever certificates you want in a SignedData element (this is not a chain but a big unsorted bag of certificates and other objects). However, Thunderbird has a default behaviour of just putting the certificates for the signer's chain, excluding the root CA; to my knowledge, this is not configurable, and I cannot blame it because including the root CA would make little sense -- see above.