Secure Multipurpose Internal Mail Extension (S/MIME) is implemented correctly as an approved cryptographic protocol.]]>This section covers information on the conditions under which S/MIME can be used as an approved cryptographic protocol.]]>When using a product that implements S/MIME, requirements for using approved cryptographic protocols will also need to be referenced from Section 17.3 - Approved Cryptographic Protocols.]]>Information relating to the development of password selection policies and password requirements can be found in Section 16.1 - Identification and Authentication.]]>Further information on S/MIME can be found at:
Reference
Title
Publisher
Source
Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification
]]>Decommissioning MUST ensure any remanent cryptographic data is destroyed or unrecoverable.]]>Decommissioning of faulty or redundant equipment MUST comply with media sanitisation requirements described in Chapter 12 – Product Security.]]>S/MIME 2.0 used weaker cryptography (40-bit keys) than is approved for use by the government. Version 3.0 was the first version to become an Internet Engineering Taskforce (IETF) standard.]]>Agencies choosing to implement S/MIME should be aware of the inability of many content filters to inspect encrypted messages and any attachments for inappropriate content, and for server-based antivirus software to scan for viruses and other malicious code.]]>Improper decommissioning and sanitisation presents opportunities for harvesting Private Keys. Products that hosted multiple Private Keys for the management of multiple identities should be considered points of aggregation with an increased “target value”. Where cloud based computing services have been employed, media sanitisation may be problematic and require the revocation and re-issue of new keys.]]>Agencies MUST NOT allow versions of S/MIME earlier than 3.0 to be used.]]>