1 / 11

CMS-X.400 Drafts

CMS-X.400 Drafts. Chris Bonatti IECA, Inc. Introduction. Two new Internet drafts: draft-ietf-smime-x400wrap-01.txt 22-NOV-2000 draft-ietf-smime-x400transport-01.txt 22-NOV-2000. Overview - X.400 Wrapping. Specifies how to protect X.400 content with CMS objects.

sun
Download Presentation

CMS-X.400 Drafts

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. MIME Wrapper SignedData (optional) MIME Wrapper MIME Wrapper (optional) EnvelopedData (optional) SignedData (optional) MIME Wrapper EnvelopedData (optional) SignedData SignedData MIME Wrapper X.400 MessageContent RFC822 MessageContent 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. Standards Informational Which Tracks?

More Related