70 likes | 235 Views
S/MIME CMS-X.400 Drafts: Status & Issues. IETF #57 – S/MIME Working Group 15 July 2003 – Vienna, Austria. Chris Bonatti (IECA, Inc.) <BonattiC@ieca.com> Tel: (+1) 301-548-9569. Background.
E N D
S/MIME CMS-X.400 Drafts: Status & Issues IETF #57 – S/MIME Working Group15 July 2003 – Vienna, Austria Chris Bonatti (IECA, Inc.) <BonattiC@ieca.com> Tel: (+1) 301-548-9569
Background • X.400 is an obvious additional market for CMS-based security, but some basic conventions are not standardized. • X400Wrap draft specifies how to protect X.400 content with CMS objects. • It is roughly analogous to RFC 2633 (Msg Spec) except it is focused on X.400 content. • X400Transport draft specifies how to package CMS objects for transport by X.400 MTAs. • The two drafts were separated to allow mixed use, and encourage use of RFC 822/MIME content in X.400 communities.
Status of Drafts • These Internet drafts are in the following issues of publication: • draft-ietf-smime-x400wrap-07.txt 2003-JUN-29 • draft-ietf-smime-x400transport-08.txt 2003-JUN-29 • This latest issue of the drafts address comments from the Area Directors and IESG, and some errata noted by WG members during testing. • Provided drafts to solicit informal ITU-T/ ISO feedback(in parallel to our process).
Changes to x400wrap-07 • In 2.2, changed the OID for the MUST signature algorithm from id-dsa to id-dsa-with-sha1. • Noted in testing between Nexor and FFI. • Aligns with common usage. • Corresponding change has been made to 2633bis. • In 2.6, added a SHOULD requirement for content encryption with AES. • As per mail list discussion • Also reflected in 2633bis.
Changes to x400transport-08 • Revised Security Considerations section as per IESG guidance to more explicitly state: This specification introduces no new security concerns to the CMS or S/MIME models.
Comments & Issues • 2.6 of 2633bis shows key size requirements for AES. Is this required? Is it worth slowing down the x400wrap draft?
Way Forward • Continue to advance these drafts as Standards Track RFCs. • No need for a new LAST CALL perceived. • Watch for any ITU-T/ ISO feedback and raise any significant issues to the WG.