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 tsbsg17@itu.int
CcMartin Euchner
A Kremer
Koji Nakao
Anthony Rutkowski
Eliot Lear
Scott Mansfield
Stephen Farrell
Sean Turner
The IETF Chair
Response Contact scott.mansfield@ericsson.com
Technical Contact scott.mansfield@ericsson.com
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
Body
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