Network Working Group P. Hoffman
Internet-Draft VPN Consortium
Updates: 3370, 3565, 3851, 3852, J. Schaad
4108, 4998, 5035, 5083, 5084 Soaring Hawk Consulting
(if approved) December 21, 2007
Expires: June 23, 2008
New ASN.1 Modules for CMS and S/MIMEdraft-ietf-smime-new-asn1-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 23, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The Cryptographic Message Syntax (CMS) format, and many associated
formats, are expressed using ASN.1. The current ASN.1 modules
conform to the 1988 version of ASN.1. This document updates those
ASN.1 modules to conform to the 2002 version of ASN.1. There are no
bits-on-the-wire changes to any of the formats; this is simply a
change to the syntax.
Hoffman & Schaad Expires June 23, 2008 [Page 1]

Internet-Draft New ASN.1 for CMS and S/MIME December 20071. Introduction
Some developers would like the IETF to use the latest version of
ASN.1 in its standards. Most of the RFCs that relate to security
protocols still use ASN.1 from the 1988 standard, which has been
deprecated. This is particularly true for the standards that relate
to PKIX, CMS, and S/MIME.
This document updates the following RFCs to use ASN.1 modules that
conform to the 2002 version of ASN.1 [ASN1-2002]. Note that not all
the modules are updated; some are included to simply make the set
compete.
o RFC 3370, CMS Algorithms [RFC3370]
o RFC 3565, Use of AES in CMS [RFC3565]
o RFC 3851, S/MIME Version 3.1 Message Specification [RFC3851]
o RFC 3852, CMS main [RFC3852]
o RFC 4108, Using CMS to Protect Firmware Packages [RFC4108]
o RFC 4998, Evidence Record Syntax (ERS) [RFC4998]
o RFC 5035, Enhanced Security Services (ESS) [RFC5035]
o RFC 5083, CMS Authenticated-Enveloped-Data Content Type [RFC5083]
o RFC 5084, Using AES-CCM and AES-GCM Authenticated Encryption in
CMS [RFC5084]
Note that some of the modules in this document get some of their
definitions from places different than the modules in the original
RFCs. The idea is that these modules, when combined with the modules
in [NEW-PKIX] can stand on their own and do not need to import
definitions from anywhere else. Note that some of the modules here
import definitions from the common definitions module, "PKIX-
CommonTypes", in [NEW-PKIX].
1.1. Issues
This section will be removed before final publication.
1.1.1. More Modules To Be Added
There are many modules from standards-track RFCs that are not listed
in this document or the companion document on PKIX. We will discuss
Hoffman & Schaad Expires June 23, 2008 [Page 3]

Internet-Draft New ASN.1 for CMS and S/MIME December 2007
with the two communities which modules are appropriate for the two
documents. We will also consider making "super-modules", individual
modules which might update multiple RFCs at one time. We may also
add objects to some of the modules.
1.1.2. Algorithm Structure
Algorithms are currently not defined here. We need to discuss what
structure we want for algorithm objects. Currently, we just do
"parameter, OID", but we could add more. Because we don't know what
the final structure is, the object sets in the various modules are
commented out. We will fix this before finishing this project.
1.1.3. Module OIDs Changing
The OIDs given in the modules in this version of the document are the
same as the OIDs from the original modules, even though some of the
modules have changed syntax. That is clearly incorrect. In a later
version of this document, we will change the OIDs for every changed
module.
2. ASN.1 Module for RFC 3370
CryptographicMessageSyntaxAlgorithms
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cmsalg-2001(16) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
ALGORITHM
FROM PKIX-CommonTypes
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon(43) };
-- Algorithm Identifiers
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 }
md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) digestAlgorithm(2) 5 }
id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
x9-57(10040) x9cm(4) 1 }
Hoffman & Schaad Expires June 23, 2008 [Page 4]

Internet-Draft New ASN.1 for CMS and S/MIME December 2007A.1. Changes between draft-hoffman-cms-new-asn1-00 anddraft-ietf-smime-new-asn1-00
Changed the draft name.
Added RFC 3565,
Added RFC 4998.
Made RFCs-to-be 5083 and 5084 into RFCs.
In RFC 3370, a line in the comment staring with "Another way to
do..." was not commented out when it should have been.
In RFC 3851, the name of the module from which we are importing was
wrong, although the OID was right.
In RFC 3852, added the "...," and "[[v:" ASN.1 idioms to indicate
which version of CMS added the various extensions.
Authors' Addresses
Paul Hoffman
VPN Consortium
127 Segre Place
Santa Cruz, CA 95060
US
Phone: 1-831-426-9827
Email: paul.hoffman@vpnc.org
Jim Schaad
Soaring Hawk Consulting
Email: jimsch@exmsft.com
Hoffman & Schaad Expires June 23, 2008 [Page 38]

Internet-Draft New ASN.1 for CMS and S/MIME December 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Hoffman & Schaad Expires June 23, 2008 [Page 39]