Guidelines for Cryptographic Algorithm Agility
draft-iab-crypto-alg-agility-00

The information below is for an old version of the document
Document Type Active Internet-Draft
Last updated 2014-01-08
Replaces draft-housley-crypto-alg-agility
Stream IAB
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream IAB state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
Internet-Draft                                                R. Housley
Intended Status: Best Current Practice                    Vigil Security
Expires: 8 July 2014                                      8 January 2014

              Guidelines for Cryptographic Algorithm Agility
                   <draft-iab-crypto-alg-agility-00.txt>

Abstract

   Many IETF protocols may use of cryptographic algorithms to provide
   confidentiality, integrity, or non-repudiation.  Communicating peers
   must support the same cryptographic algorithm or algorithms for these
   mechanisms to work properly.  This memo provides guidelines for
   ensuring that such a protocol has the ability to migrate from one
   algorithm to another over time.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright and License Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors. All rights reserved.

Housley                                                         [Page 1]
Guidelines for Cryptographic Algorithm Agility              January 2014

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1.  Introduction

   Many IETF protocols may use of cryptographic algorithms to provide
   confidentiality, integrity, or non-repudiation.  For the mechanisms
   to work properly,communicating peers must support the same
   cryptographic algorithm or algorithms.  Yet, cryptographic algorithms
   become weaker with time.  As new cryptanalysis techniques are
   developed and computing performance improves, the work factor to
   break a particular cryptographic algorithm will reduce.  For the
   protocol implementer, this means that implementations should be
   modular to easily accommodate the insertion of new algorithms.  For
   the protocol designer, this means that one or more algorithm
   identifier must be carried, the set of mandatory to implement
   algorithms will change over time, and an IANA registry of algorithm
   identifiers will be needed.

1.1.  Terminology

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [RFC2119].

2.  Guidelines

   These guidelines are for use by IETF working groups and protocol
   authors for IETF protocols that make use of cryptographic algorithms.

2.1.  Algorithm Identifiers

   IETF protocols that make use of cryptographic algorithms MUST carry
   one or more algorithm identifier.

   Some approaches carry one identifier for each algorithm that is used.
   Other approaches carry one identifier for a suite of algorithms.
   Either approach is acceptable; however, designers are encouraged to
   pick one of these approaches and use it consistently throughout the
   protocol.

Housley                                                         [Page 2]
Guidelines for Cryptographic Algorithm Agility              January 2014

   An IANA registry SHOULD be used for these algorithm identifiers.

2.2.  Mandatory-to-Implement Algorithms

   For interoperability, communicating peers must support the same
   cryptographic algorithm or algorithms.  For this reason, the protocol
   SHOULD specify one or more mandatory-to-implement algorithm.  This is
   not done for protocols that are embedded in other protocols.  For
   example, S/MIME [RFC5751] makes use of CMS [RFC5652].  Other
   protocols also make use of CMS.  S/MIME specifies the mandatory-to-
   implement algorithms, not CMS.

   The IETF must be able to change the mandatory-to-implement algorithms
   over time.  It is highly desirable to make this change without
   updating the base protocol specification.  Therefore the base
Show full document text