Liaison statement
Response to liaison on Cryptographic Message Syntax

State Posted
Posted Date 2013-12-02
From Group SEC
From Contact Scott Mansfield
To Group ITU-T-SG-17
To Contacts
CcMartin 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 Syntax).

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, NOT-A-NUMBER, OID-IRI, RELATIVE-OID-IRI, TIME, TIME-OF-DAY, warrant changing 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