CMS-X.400 Drafts

1
CMS-X.400 Drafts

• Chris Bonatti
• IECA, Inc.

2
Introduction

• Two new Internet drafts
• draft-ietf-smime-x400wrap-01.txt 22-NOV-2000
• draft-ietf-smime-x400transport-01.txt 22-NOV-2000

3
Overview - X.400 Wrapping

• Specifies how to protect X.400 content with CMS
  objects.
• Roughly analogous to RFC 2633 (Msg Spec)
• Decided to cite RFC 2633 when practical (rather
  than duplicate)
• Assumes that backward compatibility with S/MIME
  v2 is not necessary, since there is
• No installed base of X.400 using CMS
• No known S/MIME v2 products that decode X.400
  content.
• Attempt to try to minimize any unnecessary
  overhead from MIME.
• Noted that products generally do not support
  encapsulating content types other than data (such
  as signed-data or enveloped-data).

4
Proposed Wrapping
5
X.400 Wrapping Provisions

• OIDs The innermost CMS wrapper MUST identify
  the encapsulated content using the X.400 content
  type associated with that content (i.e., in the
  eContentType field of the SignedData, or (if a
  signature is not applied) to the contentType
  field of the EnvelopedData. The id-data value is
  not used because MIME encoding is not applied to
  the X.400 content prior to wrapping.
• smime-type Parameters The draft defines new
  values of the smime-type parameter to identify
  secure messages containing X.400 content when
  conveyed as the MIME content type
  application/pkcs7-mime
• signed-x400 Identifies SignedData encapsulating
  X.400 content.
• enveloped-x400 Identifies EnvelopedData
  encapsulating X.400 content.
• Detached Signature Form The S/MIME Message
  Specification specifies a form of detached
  signature. This form uses the
  multipart/signed MIME content-type to create a
  signed structure that can be read by non-S/MIME
  aware UAs. Such an option was not believed to be
  easily possible within the X.400 environment and
  has been omitted.

6
Wrapping Comments Issues

• Bill Ottaway contributed a detailed review and
  highlighted lots of non-controversial errata that
  has since been corrected.
• Sections 3.2 and 3.3 were clarified based on the
  mailing list discussion with Graeme Lunt.
• Text previously cited ASN.1 for content encoding,
  but the real requirement was that the native
  encoding be preserved regardless of what is was.
• X.400 content types are not guaranteed to be
  defined in ASN.1.
• The new sentence reads "Note that this X.400
  content SHOULD maintain the encoding defined by
  the content type, but SHOULD NOT be MIME
  wrapped.
• Graeme also suggested some minor corrections to
  these sections to make the ASN.1 objects and
  fields clearer.

7
Overview - X.400 Transport

• Specifies how to package CMS objects for
  transport by X.400 MTAs.
• Separated from X.400 wrapping draft to encourage
  use of RFC 822/MIME content in X.400 communities.
• Assumes that the encapsulated content is an RFC
  822/MIME message.
• Assumes that the outer MIME wrapper is not
  generally necessary in X.400.
• Recognizes that circumstances may exist when the
  outer MIME wrapper is desirable.
• When a gateway into SMTP transport is part of the
  architecture.

8
X.400 Transport Provisions

• OIDs CMS objects shall be identified as
  follows
• If the CMS object is covered by an outer MIME
  wrapper, it should be identified by the value
  id-data.
• If the CMS object is not covered by an outer MIME
  wrapper, it should be identified by the value
  id-ct-contentInfo.
• Packaging Specifies that implementations MUST
  include the CMS object in the content field of
  the X.400 message, except when forwarding a CMS
  signed message. Implementations SHOULD NOT
  otherwise embed CMS objects within X.400 body
  parts because of the dependency on the support
  provided by the content type.
• When conveying the CMS object as content, the
  content-type field of the P1 envelope MUST be set
  to identify the CMS object.
• When forwarding a CMS object in an IPMS or
  IPMS-compatible body part, implementations MUST
  use the content-body-part as defined in X.420.
• Certs-only Format The S/MIME Message
  Specification specifies a convention for
  identifying a message that contains a degenerate
  SignedData structure. Such a structure contains
  no encapsulated content, but is sent merely for
  the purpose of conveying certificates. This
  certs-only convention does not function in
  X.400 and has been omitted.

9
Transport Comments Issues

• Bill Ottaway contributed a detailed review and
  highlighted a few non-controversial errata that
  has since been corrected.

10
Questions

• ????

11
Which Tracks?