Securing X.400 Content with Secure/Multipurpose Internet Mail Extensions (S/MIME)
Extracted elements (28)
Backward compatibility with S/MIME version 2 is not a requirement because no existing X.400 implementations are believed to support S/MIME v2, and signed interoperability between X.400 and MIME S/MIME v2 systems is not easily achievable.
Canonicalization is not required for X.400 content because it is a binary rather than text encoding, and only the 'embedded' content version is used, which dramatically simplifies the S/MIME production description.
For nested CMS structures, the innermost smime-type SHOULD be propagated upward to outer MIME wrappers, so that the type reflects the innermost protection layer (e.g., a certs-only message that is then encrypted still carries smime-type=certs-only).
Implementations SHOULD directly encode the encapsulated object as eContent rather than using id-data OID with MIME wrappers at each nesting layer, avoiding enormous overhead that S/MIME v2 compatibility would have required.
The outer MIME wrapper is omitted for X.400 transport but used for SMTP transport because gateway systems bridging X.400 and SMTP are expected to apply or remove the outer wrapper as appropriate, and the wrapper is outside the security wrappers.
If CMS objects are sent as parts of an RFC 822 message, a standard MIXER gateway will likely encapsulate the message in a format not usable by X.400 recipients. Gateway services for relay between X.400 and SMTP environments are out of scope.
The outer MIME wrapper MAY be dynamically added or removed throughout the delivery path since it is outside the signature and encryption wrappers, enabling flexible 7-bit transport support without affecting security.
X.400 addresses in end-entity certificates SHOULD be in the subjectAltName extension and SHOULD NOT be in the subject distinguished name. Sending agents SHOULD match the originator address in X.400 content with an X.400 address in the signer's certificate.
An S/MIME implementation MUST be able to receive and process arbitrarily nested CMS structures within reasonable resource limits of the recipient computer.
Any X.400 addresses in end-entity certificates MUST be encoded using the x400Address CHOICE of the GeneralName type in the subjectAltName extension. Receiving agents MUST recognize X.400 addresses in the subjectAltName field.
For triple-wrapped messages, the EnvelopedData encryptedContentInfo contentType MUST be set to id-signedData, and the outer SignedData encapContentInfo eContentType MUST be set to id-envelopedData.
MIME wrapping for 7-bit transport MUST only be used around the outermost CMS structure, and in that case the application/pkcs7-mime content type MUST be used.
Only SignedData and EnvelopedData CMS content types are used for CMS-X.400; other CMS content types are excluded from this profile.
Receiving agents MUST handle zero or one instance of each signed attribute (signingTime, sMIMECapabilities, sMIMEEncryptionKeyPreference). Sending agents SHOULD generate one instance of each in every CMS-X.400 message.
Receiving agents MUST support id-dsa-with-sha1 with absent (not NULL) algorithm parameters, and MUST support rsaEncryption. Sending agents MUST support either id-dsa-with-sha1 or rsaEncryption.
Senders MUST use the envelopedData content type to apply privacy protection to a message; this content type does not provide authentication.
Sending agents MUST use the signedData content type to apply a digital signature to a message or, in a degenerate case without signature information, to convey certificates.
Sending and receiving agents MUST support encryption and decryption with tripleDES (DES EDE3 CBC), and SHOULD support AES at key sizes of 128, 192, and 256 bits.
Sending and receiving agents MUST support rsaEncryption for key encryption, and SHOULD support Diffie-Hellman as defined in [CMSALG].
Sending and receiving agents MUST support SHA-1 as the digest algorithm identifier.
The X.400 content to be protected MUST be placed in the EnvelopedData encryptedContentInfo encryptedContent field, with its OID in the contentType field. The content SHOULD maintain its defined encoding and SHOULD NOT be MIME wrapped.
CMS-X.400 messages use SignedData and EnvelopedData content types encapsulated in a ContentInfo SEQUENCE. The X.400 content is placed in the eContent field with its ASN.1 OID in the eContentType field, without MIME wrapping.
For MIME-wrapped signed X.400 content, the content type is 'application/pkcs7-mime; smime-type=signed-x400' with Content-Transfer-Encoding base64. For enveloped content, smime-type is 'enveloped-x400'.
The SignerInfo type supports signed attributes including signingTime, sMIMECapabilities, sMIMEEncryptionKeyPreference, and signingCertificate. Processing of these attributes MUST conform to the S/MIME Message Specification [MSG].
Triple-wrapped X.400 messages follow a six-step process: ASN.1 encode content, inner sign, encrypt (id-signedData as contentType), outer sign (id-envelopedData as eContentType), with optional MIME wrapping only on the outermost layer.
X.400 content carried in SMTP without CMS wrapping uses the MIME type: 'application/x400-content; content-type = 1*DIGIT *("." 1*DIGIT)', where the parameter value is either an integer or OID in dotted notation.
Sending enveloped but not signed messages does not provide data integrity. It is possible to replace ciphertext such that the processed message is still valid but with altered meaning.
This specification introduces no new security concerns to the CMS or S/MIME models. Security issues are identified in section 5 of [MSG], section 6 of [ESS], and the Security Considerations section of [CMS].