Transporting Secure/Multipurpose Internet Mail Extensions (S/MIME) Objects in X.400
Extracted elements (28)
A RecipientInfo for the originator is recommended as good practice in case the MTS returns the whole EnvelopedData message, ensuring the originator can still decrypt it.
CMS objects are carried as X.400 message content rather than body parts because the content-bearing approach is compatible with all mail content types, while body-part embedding is reserved only for the forwarding use case where it is structurally necessary.
EITs replace MIME smime-type parameters in X.400 environments because MIME typing is not available in X.400; new EIT assignments should correspond to smime-type values on a one-to-one basis following section 3.2.2 of MSG.
The outer MIME wrapper that S/MIME uses for 7-bit transport is not required in a homogeneous X.400 environment (which supports 8-bit data natively) and SHOULD NOT be applied, though heterogeneous environments MAY require it.
Gateways or functions expecting IPMS content (such as those specified in MIXER and BODYMAP) cannot process messages using this native X.400 CMS transport mechanism; gateway services for X.400-to-SMTP relay are out of scope.
MTS conversion is incompatible with CMS protection mechanisms; X.400 systems implementing conversion services should generally be unable to convert CMS content types because they do not conform to X.420 structure rules.
X.400 DLs are not generally security-aware and do not regenerate RecipientInfo elements for DL members; using a security-aware Mail List conforming to ESS is recommended in preference to X.400 DLs when EnvelopedData is used.
For the certs-only message, the encapContentInfo eContent field MUST be absent and the signerInfos field MUST be empty.
If the CMS object is covered by an outer MIME wrapper, the content-type field of the P1 envelope MUST be set to id-data (OID { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }).
If the CMS object is not covered by an outer MIME wrapper, the content-type field of the P1 envelope MUST be set to id-ct-contentInfo (OID { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) content-types(1) 6 }).
Implementations generally SHOULD NOT embed CMS objects within X.400 body parts; they should instead convey them as X.400 message content per section 2.2.
Implementations MUST include the CMS object in the content field of the X.400 message when transporting CMS-protected messages natively in X.400.
In the event that ORAR (Originator Requested Alternate Recipient) is used, the originator is aware of the alternate recipient's identity and SHOULD include a corresponding RecipientInfo element in the EnvelopedData.
Sending agents SHOULD include the appropriate S/MIME EIT OID value; receiving agents SHOULD recognize S/MIME OID values in the EITs field and process accordingly.
The direct-reference field of the forwarded body part MUST include the OID formed by the concatenation of id-et-content and id-ct-contentInfo values.
When forwarding a CMS object in an IPMS or IPMS-compatible body part, implementations MUST use the content-body-part as formally defined by X.400, and MUST copy the CMS object into the Content field.
When forwarding CMS objects as IPMS body parts, the content-type field of the P1 envelope MUST be set to the value associated with the forwarding content type (e.g., integer 22 for IPMS).
When transporting CMS objects within an X.400 environment, the DL Expansion Prohibited service SHOULD be selected to prevent DL expansion from breaking EnvelopedData access control.
Encoded Information Types (EITs) carried in the original-encoded-information-types field of the X.400 envelope convey the S/MIME content type (enveloped-data, signed-data, certs-only, signed-receipt, enveloped-x400, signed-x400, compressed-data) in lieu of MIME content-type parameters.
S/MIME CMS objects are carried as the content of X.400 messages, using the P1 envelope content-type OID to indicate whether a MIME wrapper is present (id-data) or absent (id-ct-contentInfo).
When forwarding CMS objects inside IPMS, the content-body-part structure is used, with ForwardedContentParameters (delivery-time, delivery-envelope, mts-identifier) as an optional SET and the CMS object in the Content field.
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 of CMS (RFC 3852).
The id-eit-certsOnly OID ({ ... smime(16) id-eit(10) id-eit-certsOnly(3) }) identifies a certs-only CMS SignedData message; encapContentInfo eContent must be absent and signerInfos must be empty.
The id-eit-compressedData OID ({ ... smime(16) id-eit(10) id-eit-compressedData(7) }) identifies content compressed using the CMS CompressedData content type per RFC 3274.
The id-eit-envelopedData OID ({ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-eit(10) id-eit-envelopedData(1) }) identifies X.400 content protected by CMS EnvelopedData wrapping a MIME type.
The id-eit-envelopedX400 OID ({ ... smime(16) id-eit(10) id-eit-envelopedX400(5) }) and id-eit-signedX400 OID ({ ... id-eit-signedX400(6) }) identify X.400 content protected by CMS EnvelopedData or SignedData respectively per X400WRAP.
The id-eit-signedData OID ({ ... smime(16) id-eit(10) id-eit-signedData(2) }) identifies X.400 content protected by CMS SignedData wrapping a MIME type.
The id-eit-signedReceipt OID ({ ... smime(16) id-eit(10) id-eit-signedReceipt(4) }) identifies a Receipt content type protected by CMS SignedData per ESS.