Network Working Group P. Wouters
Internet-Draft Aiven
Intended status: Informational P. Hoffman
Expires: 15 August 2025 ICANN
11 February 2025
Documenting and Referencing Cryptographic Components in IETF Documents
draft-paulwh-crypto-components-02
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 15 August 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 15 August 2025 [Page 1]
Internet-Draft Crypto components February 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . 8
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 15 August 2025 [Page 2]
Internet-Draft Crypto components February 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
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,
Wouters & Hoffman Expires 15 August 2025 [Page 3]
Internet-Draft Crypto components February 2025
and because RFCs are often not required for specifying cryptographic
components (see Section 2.1). Documents from working groups and
those sponsored by Area Directors must get IETF consensus (as
determined by the IESG) before publication as RFCs.
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"). These do not need to be RFCs, but should be stable
references.
Stable specifications are important references for developers who
rely on a registry with code points. Individual web sites are
probably the least-used references for cryptographic components for
good reasons: the URLs for them might change or disappear, the
content of the web sites might change in ways that would affect the
components' definition, and so on.
Wouters & Hoffman Expires 15 August 2025 [Page 4]
Internet-Draft Crypto components February 2025
Although there is no IETF-wide consensus at the time of this writing
as to whether specific versions of an Internet Drafts are appropriate
for all registries as stable references, they have been used in the
past for cryptographic purposes. Until further guidance is
developed, the decision about whether a draft is acceptable can
continue to be addressed on a case-by-case basis by the designated
expert for the specific registry.
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
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.
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
Each working group gets to specify the rules for the registries for
the cryptographic components they create. These rules require IETF
consensus during the process of creating the 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.
Wouters & Hoffman Expires 15 August 2025 [Page 5]
Internet-Draft Crypto components February 2025
* 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.
* 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.
Working groups setting up such registries should strongly consider
mandating that 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 would not be able to 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.
Wouters & Hoffman Expires 15 August 2025 [Page 6]
Internet-Draft Crypto components February 2025
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.
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]. The ASN.1 prefix for the IANA PEN tree is
1.3.6.1.4.1.
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>.
Wouters & Hoffman Expires 15 August 2025 [Page 7]
Internet-Draft Crypto components February 2025
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>.
[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 15 August 2025 [Page 8]