Skip to main content

Liaison statement
Response to liaison on Cryptographic Message Syntax

Additional information about IETF liaison relationships is available on the IETF webpage and the Internet Architecture Board liaison webpage.
State Posted
Submitted Date 2013-11-25
From Group SEC
From Contact Scott Mansfield
To Group ITU-T-SG-17
To Contacts
Cc Martin Euchner <>
A Kremer <>
Koji Nakao <>
Anthony Rutkowski <>
Eliot Lear <>
Scott Mansfield <>
Stephen Farrell <>
Sean Turner <>
The IETF Chair <>
Response Contact
Technical Contact
Purpose In response
Attachments (None)
Liaisons referred by this one LS/o on Cryptographic Message Syntax [to ISO/IEC JTC 1/SC27/WG2, ISO/TC 68/SC2, IESG]
Liaisons referring to this one Security Area Response to Liaison on Cryptographic Message Syntax
Follow-up on Cryptographic Message Syntax communications
The IESG thanks you for the liaison statement, numbered LS073, regarding the
new work item to update and possibly extend the CMS (Cryptographic Message

The IESG believes that there is no need to update CMS to eliminate obsolete
ASN.1 features.  The ASN.1 modules for CMS were updated to the 2008 version of
ITU Rec. X.680 | ISO/IEC IS 8824-1 in RFC 6928 as soon as royalty-free tools
were available.  Updating the base specification, which is an Internet
Standard, to include excerpts from an '02/'08 ASN.1 module is unnecessary
because the ASN.1 type names used in the text still correlate to the ASN.1 type
names in the ASN.1 modules regardless of the year the ASN.1 module was
published.  Note that RFC 6025 provides guidance for implementers to convert
between different ASN.1 versions without introducing bits-on the-wire changes,
which is import to ensure backward compatibility is not sacrificed.

The IESG also does not believe that the new features added to the 2008 version
of ASN.1, namely the additional pre-defined types: DATE, DATE-TIME, DURATION,
CMS-based protocols because none of these new types are needed by CMS-based
IETF protocols.  Revising an existing protocol to adopt one of these new types
just because it is a new type would destroy backward compatibility; the IESG
does not believe that the abstract syntax should drive protocol changes
especially if it sacrifices backward compatibility.  Note that many of the
other ASN.1-based IETF protocols updated their ASN.1 modules to the 2002 ASN.1
version, but stopped short of referring to the 2008 ASN.1 version because of
the lack of need for the new 2008 ASN.1 types.

Updates to the base CMS specification are not needed to define new content
types that support additional key management techniques. Examples include:
Authenticated Enveloped Data defined in RFC 6083 and IBE (Identity Based
Encryption) defined in RFC 5409.  Both the sigcryption and constructed key
management content types could easily follow suit without updating the base
specification.  We invite the proponents of these content types to submit an
internet-draft that we will shepherd through the IETF process.

Stephen Farrell
Sean Turner
IETF Security Area Directors