Documenting and Referencing Cryptographic Components in IETF Documents
draft-paulwh-crypto-components-00

Network Working Group                                         P. Wouters
Internet-Draft                                                     Aiven
Intended status: Informational                                P. Hoffman
Expires: 25 July 2025                                              ICANN
                                                         21 January 2025

 Documenting and Referencing Cryptographic Components in IETF Documents
                   draft-paulwh-crypto-components-00

Abstract

   This document describes the history of how cryptographic components
   have been documented and referenced in the IETF, particularly in
   RFCs.  It also gives guidance for how such specification should
   happen in the future.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on 25 July 2025.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Wouters & Hoffman         Expires 25 July 2025                  [Page 1]
Internet-Draft              Crypto components               January 2025

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Referencing Cryptography in RFCs  . . . . . . . . . . . . . .   3
     2.1.  External References for Specifying Cryptography . . . . .   3
     2.2.  RFCs for Specifying Cryptography  . . . . . . . . . . . .   3
   3.  Using Identifiers for Cryptography in Protocols . . . . . . .   4
     3.1.  Per-Registry Requirements for Adding Code Points  . . . .   4
     3.2.  Private-Use Code Points . . . . . . . . . . . . . . . . .   5
     3.3.  Vendor Space Code Points  . . . . . . . . . . . . . . . .   5
     3.4.  Recommendations in IANA Registries  . . . . . . . . . . .   5
     3.5.  OIDs  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.6.  Identifiers and Intellectual Property . . . . . . . . . .   7
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The IETF has many diverse ways to document and reference
   cryptographic components that are used in protocols.  These practices
   have changed over time, based on the IETF community, the IETF
   leadership, and the types of components needed by protocols.

   The purpose of this document is to increase consistency and
   transparency in how the IETF handles cryptographic components.  This
   document does not define any new policies, but instead describes the
   many practices that have been used, particularly the practices that
   are considered best current practices today.

   In this document, items such as cryptographic algorithms, base
   primitives, functions, methods, and constructions are all lumped
   under the term "cryptographic components".  Doing so avoids the
   conflicting definitions of what differentiates, for example, a method
   from a construction.

   This document explicitly does not prohibit exceptions from the
   current practices.  Given the wide variety of historical practices,
   the difficulty of differentiating what is a base primitive and what
   is a cryptographic component, and the variety of needs in IETF
   working groups, the guidance in this document gives leeway for future
   specifications.

Wouters & Hoffman         Expires 25 July 2025                  [Page 2]
Internet-Draft              Crypto components               January 2025

2.  Referencing Cryptography in RFCs

   RFCs that define secure protocols need to reference cryptographic
   components, or those RFCs define the components themselves.  It is
   uncommon for IETF protocols to define cryptographic components;
   instead, those components are defined elsewhere and referenced in the
   protocol RFC.

   There are many sources for cryptographic references for RFCs.

2.1.  External References for Specifying Cryptography

   There are many sources of references for cryptography other than
   RFCs.  Such sources include:

   *  National standards development organizations (SDOs) such as the
      U.S.  National Institute of Standards and Technology (NIST) and
      the German Federal Office for Information Security (BSI)

   *  International SDOs such as the International Standards
      Organization (ISO) and the International Telecommunications Union
      (ITU)

   *  Academic papers and articles

   *  Internet Drafts not meant to proceed to RFC status

   *  Web sites of individual cryptographers

2.2.  RFCs for Specifying Cryptography

   In order to be published as an RFC, an Internet Draft must be
   sponsored by one of the following:

   *  An IETF working group (and then the working group's Area Director)

   *  A research group in the Internet Research Task Force (IRTF)

   *  An Area Director who is individually sponsoring the draft

   *  The Independent Submissions Editor (ISE)

   *  The Internet Architecture Board

Wouters & Hoffman         Expires 25 July 2025                  [Page 3]
Internet-Draft              Crypto components               January 2025

   RFCs describing cryptographic components have been published by the
   first four of those.  Note, however, that Area Directors may not be
   willing to individually sponsor drafts for cryptographic components
   because other venues for RFC publication can garner better reviews,
   and because RFCs are often not required for specifying cryptographic
   components (see Section 2.1).

   Many RFCs are specifications of cryptographic components, some are
   specific use cases of cryptography where additional operational
   constraints apply, and still others simply list cryptographic
   identifiers such as OIDs or IANA registration values.

   Whenever possible, cryptographic components related to a specific
   protocol should be specified separately from the protocol itself.
   This allows better review of the cryptography by cryptographers, and
   better review of the protocol by protocol experts.

3.  Using Identifiers for Cryptography in Protocols

   Although a proliferation of cryptographic components is a barrier to
   interoperability, the IETF encourages experimenting with new
   cryptographic components.  Identifiers used in IETF protocols are
   meant to be easy to obtain, as the IETF encourages experimentation
   and operational testing.  These identifiers are often called "code
   points" when they are listed in IANA registries, but might also be
   object identifiers (OIDs).  OIDs are covered in Section 3.5.

   IANA registries are described in depth in [RFC8126].  The following
   sections cover aspects of using IANA registries for cryptographic
   protocols; most of these aspects are the same for non-cryptographic
   protocols as well.

3.1.  Per-Registry Requirements for Adding Code Points

   In the past, some working groups had set the ability to add
   cryptographic component code points to IANA registries for their
   protocols be very strict, by requiring an RFC.  Recently, the rules
   for many registries have been updated to make it easier to get code
   points in order to allow for experimentation.  Where possible, the
   rules for cryptographic component registries should have an open
   registration policy (such as "Expert Review" or "Specification
   Required") so Internet Drafts can be used as specifications, not just
   RFCs.

   There are some IANA registries where the limited allocation space
   does not allow for handing out many experimental code points, such as
   those where the number of code points is limited to 256 or fewer.
   This necessitates a more conservative approach to code point

Wouters & Hoffman         Expires 25 July 2025                  [Page 4]
Internet-Draft              Crypto components               January 2025

   allocation, and might instead force experiments to use private use
   code points instead of having allocations for code points that might
   only be used occasionally.

   As stated above, Internet Drafts are a method for defining
   cryptographic components.  This method is controversial with some
   members of the IETF community because drafts were originally designed
   to be impossible to access six months after publication, and wording
   based on the assumption of that inaccessibility still appears
   automatically in current Internet Drafts.  However, using Internet
   Drafts as stable references for code points in IANA registries has
   been allowed for at least 20 years.  When a draft is used as a
   reference for a code point, a specific version of a draft is
   specified; that is, the filename of the draft must end in a two-digit
   number.

3.2.  Private-Use Code Points

   Every IANA registry for cryptographic components should reserve some
   code points for "private use".  These private-use code points can be
   used by protocol implementers to indicate components that do not have
   their own code points.  Generally, the RFC describing the protocol
   will define how the private-use code points can be used in practice.

3.3.  Vendor Space Code Points

   Some IANA registries use a an allocation scheme that allows for
   unlimited code points based on "vendor strings".  This allows for
   wide experimentation in a "vendor space" that acts as a private-use
   registration.  Such registrations might later be converted to an
   allocation not based on vendor names if the cryptographic component
   achieves IETF-wide consensus.

3.4.  Recommendations in IANA Registries

   Some IANA registries for specific cryptographic protocols have a
   column with a name such as "status" or "recommended" that indicates
   whether the the IETF recommends that a cryptographic component be
   used in that protocol.  The definition of the column should
   differentiate between recommending for implementation and
   recommending for deployment.

   *  Recommendations for implementation tell developers of the protocol
      whether they should or must include the cryptographic component in
      their software or hardware implementations.  Such recommendations
      make the component available to users, letting them choose whether
      or not to use the component in their deployments.

Wouters & Hoffman         Expires 25 July 2025                  [Page 5]
Internet-Draft              Crypto components               January 2025

   *  Recommendations for deployment tell the users of the protocol
      whether they should or must use the component in their
      deployments.

   In the former case, the IETF is only speaking to developers; in the
   latter, the IETF is speaking directly to users who configure their
   use of the protocol.  This difference between "implementation" and
   "deployment" has sometimes tripped up working groups, but it is quite
   important to people trying to understand the IANA registry contents.

   Decisions on setting the values in these columns to anything other
   than "MAY" require a standards track RFC.  That is, Independent
   Stream and IRTF RFCs cannot set or change the values in such a table
   in an IANA registry.

   A working group's decision about whether a particular cryptographic
   component is mandatory, suggested, suggested against, or must not be
   used, might not be an easy one to make, particularly in light of also
   having to decide for both implementation and deployment.  Deployed
   cryptographic components that are known to be weak, such as those
   with keys that are now considered to be too small, present a
   significant challenge for working groups.  For such a weak component,
   clearly the recommendation should be against deployment, but a
   similar recommend against allowing implementation can make deployed
   systems unusable.  Such decisions are left to working groups, an are
   not covered here in any significant depth.  Working groups might
   batch their decision-making into periodic chosen intervals.  Working
   groups that choose to go against IETF-wide trends for cryptographic
   component should clearly state why their choices differ.

   Having too many algorithms with a "recommended" status is harmful
   because it complicates implementations, deployments, and migrations
   to newer algorithms.

   Registries that do not have columns for "implementation" and/or
   "deployment" can be updated by working groups or the IETF to add
   those columns.

3.5.  OIDs

   Some IETF cryptographic protocols (notably CMS, CMP, S/MIME, and
   PKIX) use OIDs instead of IANA registries for code points.  OIDs are
   a hierarchical numbering system, normally stored in ASN.1 DER or BER
   encoding, and displayed as a series of positive integers separated by
   period (".") characters.  When designing new protocols, IANA
   registries with code points should be used instead of OIDs.

Wouters & Hoffman         Expires 25 July 2025                  [Page 6]
Internet-Draft              Crypto components               January 2025

   In IETF standards, many OIDs for cryptographic components normally
   are based on a part of the OID tree that was established in the early
   1990s.  However, many OIDs come from other parts of the OID tree, and
   no particular part of the OID tree is better or worse than any other
   for unique identification of cryptographic components.  In fact,
   individuals who want to control part of the OID tree (called "private
   enterprise numbers") can get their own OID prefix directly from IANA
   as described in [RFC9371].

3.6.  Identifiers and Intellectual Property

   Assigning code points for proprietary cryptographic components or
   cryptographic components that have known intellectual property rights
   (IPR) is acceptable as long as any IETF protocol using those code
   points also allow the protocol to be run without using those
   components.  The IETF policy on IPR can be found in [RFC8179].

4.  IANA Considerations

   This document contains no actions for IANA.  However, it discusses
   the use of IANA registries in many places.

5.  Security Considerations

   This document is about the use of cryptography in IETF protocols, and
   how that cryptography is referenced in those protocols.

   Reusing cryptographic components that have already been reviewed and
   approved in the IETF is usually better than creating new cryptography
   that must be reviewed before it is used in protocols.

6.  References

6.1.  Normative References

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

6.2.  Informative References

   [RFC8179]  Bradner, S. and J. Contreras, "Intellectual Property
              Rights in IETF Technology", BCP 79, RFC 8179,
              DOI 10.17487/RFC8179, May 2017,
              <https://www.rfc-editor.org/info/rfc8179>.

Wouters & Hoffman         Expires 25 July 2025                  [Page 7]
Internet-Draft              Crypto components               January 2025

   [RFC9371]  Baber, A. and P. Hoffman, "Registration Procedures for
              Private Enterprise Numbers (PENs)", RFC 9371,
              DOI 10.17487/RFC9371, March 2023,
              <https://www.rfc-editor.org/info/rfc9371>.

Authors' Addresses

   Paul Wouters
   Aiven
   Email: paul.wouters@aiven.io

   Paul Hoffman
   ICANN
   Email: paul.hoffman@icann.org

Wouters & Hoffman         Expires 25 July 2025                  [Page 8]