A Template for IANA Cryptographic Registries
draft-rsalz-crypto-registries-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Rich Salz | ||
| Last updated | 2024-11-13 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-rsalz-crypto-registries-00
TBD R. Salz
Internet-Draft Akamai Technologies
Intended status: Best Current Practice 13 November 2024
Expires: 17 May 2025
A Template for IANA Cryptographic Registries
draft-rsalz-crypto-registries-00
Abstract
This document provides recommendations for how IETF Working Groups
should create IANA registries that are related to cryptographic
algorithms. It is based on the lessons learned from the TLS
registries over the years.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-rsalz-crypto-registries/.
Discussion of this document takes place on the SAAG Security Area
mailing list (mailto:saag@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/saag/. Subscribe at
https://www.ietf.org/mailman/listinfo/saag/.
Source for this draft and an issue tracker can be found at
https://github.com/rsalz/draft-rsalz-crypto-registries.
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 17 May 2025.
Salz Expires 17 May 2025 [Page 1]
Internet-Draft IANA Crypto Registries November 2024
Copyright Notice
Copyright (c) 2024 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Specification Required . . . . . . . . . . . . . . . . . . . 3
4. Suggested Columns . . . . . . . . . . . . . . . . . . . . . . 4
4.1. The "Value" column . . . . . . . . . . . . . . . . . . . 4
4.2. The "Description" colummn . . . . . . . . . . . . . . . . 5
4.3. The "Reference" column . . . . . . . . . . . . . . . . . 5
4.4. The "Recommended" column . . . . . . . . . . . . . . . . 5
4.5. The "Comments" Column . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
This document provides recommendations for how IETF Working Groups
should create IANA registries that are related to cryptographic
algorithms. It is based on the lessons learned from the TLS
registries over the years as described in [RFC8447] and
[I-D.draft-ietf-tls-rfc8447bis].
The guidance here can be summarized as follows:
1. Each registry SHOULD be "Specification Required," as defined in
[RFC8126], Section 4.6.
2. If required by the "Value" format (see Section 4.1), consider
reserving a section for Private or Experimental Use.
Salz Expires 17 May 2025 [Page 2]
Internet-Draft IANA Crypto Registries November 2024
3. Each registry SHOULD have a "Recommended" column (see
Section 4.4).
4. Each registry SHOULD have a "Comments" column (see Section 4.5).
5. Most registries will need additional columns.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCPÂ 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Specification Required
The intent of the Specification Required standard for cryptographic
code points is to allow for relatively easy registration of code
points associated with protocols and algorithms that are being
developed outside of IETF or IRTF. A key requirement is that the
specification of the semantics must be "permanent and readily
available" as described in [RFC8126], Section 4.6. The defining
document should make explicit if Internet-Draft documents qualify, as
Section 4.6 does not say. Authors of the defining document should
read the entire [RFC8126] and make sure their descriptions and
requirements are clear.
Note that the IESG picks the Designated Experts, so they should not
be named in the defining document. Instead, specify the number of
experts and how many are required to approve. Phrases like "one of
two" or "two of three" are common requirements for approval. The
defining document SHOULD NOT suggest one person, to avoid a single
point of failure.
Designated experts ensure the specification is publicly available.
They may provide more in-depth reviews. Their review should not be
taken as an endorsement of the new registry entry.
When the work is done by an IETF WG or IRTF RG, that group should
collaborate with the defining WG in order to provide appropriate
review. A WG that defines a cryptographic registry MAY wish to
include text like the following in its instructions to the experts to
enforce this behavior. Such instructions should appear in the
defining document.
DE Instructions Unless the WG chairs indicate otherwise via email,
Salz Expires 17 May 2025 [Page 3]
Internet-Draft IANA Crypto Registries November 2024
the Designated Experts should decline code point registrations for
documents which have already been adopted or are being proposed
for adoption by IETF working groups or IRTF research groups.
4. Suggested Columns
Here is a summary of the recommendation; each column is described in
its own sub-section below. The following paragraph can be used as a
template when defining a registry.
The columns are defined as follows:
* Value (required): The value that appears in the data structure or
protocol. Additional sentences that describe the format, such as
fixed-number of bytes, text string, etc., should be added.
* Description (required): A brief desription, often pointing to a
section in the defining Reference.
* Reference (required): The publication defining the entry.
* Recommended (required): Whether or not this value is recommended
for general use.
* Comments (optional): Text that may be added to explain
transitions, or similar useful information.
4.1. The "Value" column
The "Value" column is the identifier for the cryptographic items in
the registry. Every value SHOULD be unique within the registry.
Values SHOULD ONLYy be re-used because of earlier mistakes and if
they still guarantee there is little to no chance of confusion.
Sometimes values are inherently unique. Example of this include ISO
Object Identifiers, and string identifiers like those in OpenSSH that
allow an identifier to have an "@domain-name" appended. It is up to
the Working Group to decide if such values should be in a registry.
Values that would have a Recommended value of "Y" probably SHOULD
appear.
In some registries, such as TLS Cipher Suites [TLSREG], the values
are one or more bytes, while NTP uses a single multi-byte value,
while JOSE uses short text names ([JOSEREG]), such as "s5c" for an
X.509 certificate chain.
Salz Expires 17 May 2025 [Page 4]
Internet-Draft IANA Crypto Registries November 2024
If a name is not inherently unique, the defining WG MAY wish to set
aside a specific range or values for "Experimental or Private Use."
It does not seem necessary to separate "Experimental" from the
"Private Use" concept. An example of private string identifiers from
[RFC6838], Sections 3.2 and 3.4, are the previxes "vnd." and "x.",
respectively.
Another reason for reserved values is for "greasing" the protocol, to
help prevent ossification by nework devices that do not allow
protocols to grow and evolve. See [RFC8701] for more information.
Such entries are often makred as "Reserved" in their Description, and
a reference to "RFC8710" in their reference.
4.2. The "Description" colummn
The "Description" is a brief description of the item. In many cases,
it will be a short reminder text that should serve as a "guidepost"
to the reference documentation, as done with the NTP Extension Field
Types in the NTP Registries, [NTPREG].
4.3. The "Reference" column
For work done in the IETF or IRTF, the "Reference" entry will almost
always point to a RFC about to be published. For work done outside
these organizations, the reference should be a URL that the
Designated Experts have verified to meet the requirements of
Section 3.
4.4. The "Recommended" column
This document specifies that a "Recommended" column be defined, with
three values that correspond to yes, no, and no opinion. Specifying
an initial value of "Y" or "D" in this column MUST require Standards
Action [RFC8126] for the defining RFC, otherwise the the field MUST
be empty or have the value of "N". Not all items defined in
Standards Track RFCs need to be set to "Y" or "D".
The entry SHOULD also be left blank for values that are unassigned or
reserved.
Y Indicates that the IETF has consensus that the item is
RECOMMENDED. This only means that the associated mechanism is fit
for the purpose for which it was defined. Careful reading of the
documentation for the mechanism is necessary to understand the
applicability of that mechanism. When the IETF recommends
mechanisms that have limited applicability, the working SHOULD
provide applicability statements that describe any limitations of
the mechanism or necessary constraints on its use.
Salz Expires 17 May 2025 [Page 5]
Internet-Draft IANA Crypto Registries November 2024
D Indicates that the item is discouraged. This marking could be
used to identify mechanisms that might result in problems if they
are used, such as a weak cryptographic algorithm or a mechanism
that might cause interoperability problems in deployment.
Implementers SHOULD consult the linked references associated with
the item to determine the conditions under which it SHOULD NOT or
MUST NOT be used.
N Indicates that the item has not been evaluated by the IETF and
that the IETF has made no statement about the suitability of the
associated mechanism. This does not necessarily mean that the
mechanism is flawed, only that no consensus exists. The IETF
might have consensus to leave an items marked as "N" on the basis
of it having limited applicability or usage constraints.
Once an entry is created, there are specific requirements to change
the value. Cryptographic algorithms become weaker over time, as more
attacks on them are defined. Any state transition to or from a "Y"
or "D" value requires IESG Approval.
The following is text that can be used in the notes section of any
registry that has a "Recommended" column:
Note If the "Recommended" column is set to "N", it does not
necessarily mean that it is flawed; but rather that the item
either has not been through the IETF consensus process, has
limited applicability, or is intended only for specific use cases.
If the "Recommended" column is set to "D" the item is discouraged
and SHOULD NOT or MUST NOT be used. Defining a "Recommended"
column value to "Y" or "D" requires Standards Action [RFC8126].
Any state transition to or from a "Y" or "D" value requires IESG
Approval.
4.5. The "Comments" Column
This is a brief free-text column that can be used to describe
transitions or limits on usage. Examples include:
* Obsoleted by RFC xxx
* Only for TLS 1.3 or later
Salz Expires 17 May 2025 [Page 6]
Internet-Draft IANA Crypto Registries November 2024
5. Security Considerations
Using Specification Required rather than IETF Review does,
admittedly, lower the theoretical amount of review provided by a WG.
Experience has shown, however, that WG members generally provided no
cryptographic review, especially in the case of referring to national
cipher suites.
Recommended algorithms are regarded as secure for general use at the
time of registration, Over time, however, cryptographic algorithms
and parameters will be broken or weakened. It is possible that the
"Recommended" status in the registry lags behind the most recent
advances in cryptanalysis. Implementers and users need to check that
the cryptographic algorithms listed continue to provide the expected
level of security.
6. IANA Considerations
This document is entirely about best practices for IANA-maintained
cryptographic registries. It does not define any new registries but
provides guidance to those who need to do so.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/rfc/rfc6838>.
[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/rfc/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
7.2. Informative References
Salz Expires 17 May 2025 [Page 7]
Internet-Draft IANA Crypto Registries November 2024
[I-D.draft-ietf-tls-rfc8447bis]
Salowey, J. A. and S. Turner, "IANA Registry Updates for
TLS and DTLS", Work in Progress, Internet-Draft, draft-
ietf-tls-rfc8447bis-10, 3 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
rfc8447bis-10>.
[JOSEREG] "JSON Web Signature and Encryption Header Parameters",
n.d., <https://www.iana.org/assignments/jose/
jose.xhtml#web-signature-encryption-header-parameters>.
[NTPREG] "Network Time Protocol (NTP) Parameters", n.d.,
<https://www.iana.org/assignments/ntp-parameters/ntp-
parameters.xhtml#ntp-parameters-3>.
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
<https://www.rfc-editor.org/rfc/rfc8447>.
[RFC8701] Benjamin, D., "Applying Generate Random Extensions And
Sustain Extensibility (GREASE) to TLS Extensibility",
RFC 8701, DOI 10.17487/RFC8701, January 2020,
<https://www.rfc-editor.org/rfc/rfc8701>.
[TLSREG] "TLS Cipher Suites", n.d.,
<https://www.iana.org/assignments/tls-parameters/tls-
parameters.xhtml#tls-parameters-4>.
Author's Address
Rich Salz
Akamai Technologies
Email: rsalz@akamai.com
Salz Expires 17 May 2025 [Page 8]