RFC 8411

IANA Registration for the Cryptographic Algorithm Object Identifier Range

πŸ“… published August 2018, from ietf

IANA Registration for the Cryptographic Algorithm Object Identifier Range πŸŽ€

Okay so this one is an Informational RFC πŸ¦‹ published in August 2018, written by J. Schaad (August Cellars) and R. Andrews (DigiCert, Inc.). It's RFC 8411, ISSN 2070-1721. The header doesn't list anything it obsoletes or updates, so it's just vibing on its own πŸ’…

Abstract ✨

Okay, backstory time. When the Curdle Security Working Group got chartered, DigiCert, Inc. donated a range of object identifiers (OIDs) 🎁 to register the Edwards Elliptic Curve key agreement and signature algorithms. The donated OIDs were shorter than what you'd get from the existing S/MIME or PKIX arcs, which is honestly iconic. This document describes that donated range and the identifiers assigned from it, hands control of the range over to IANA, and sets up IANA allocation policies for any future assignments in there 🌸

Status of This Memo 🌈

Quick heads up: this is not an Internet Standards Track spec. It's published for informational purposes, so it's more of a "here's the info" situation than a "you must do this" one 🫢

It's a product of the Internet Engineering Task Force (IETF), so it reflects consensus from the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is up for any level of Internet Standard, though. See Section 2 of RFC 7841 for that. πŸ”

For the current status, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc8411.

Copyright (c) 2018 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) as they stood when this was published. Read those carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License. πŸ“œ

Table of Contents 🧚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   3
3.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
4.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
  4.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
  4.2.  Informative References  . . . . . . . . . . . . . . . . .   4
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   4
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1. Introduction πŸ¦‹

So, when the Curdle Security Working Group was chartered, DigiCert, Inc. donated a range of object identifiers to the group. Using those OIDs meant the Edwards Elliptic Curve key agreement [RFC7748] and signature [RFC8032] algorithms could be defined with smaller encodings than they'd get from the existing S/MIME or PKIX arcs. The first registrations from this arc were made while working on [RFC8410]. After those went in, there were still some unused values left over that other security groups could use πŸ’–

OIDs are mostly used with Abstract Syntax Notation One (ASN.1) [ASN.1]. ASN.1 keeps evolving, but OIDs work with any and all versions of ASN.1 ✨

This document covers the OIDs assigned from that donated range, transfers control of the range to IANA, and sets up IANA allocation policies for future assignments 🌸

The donated range from DigiCert, Inc. looks like this:

first: { iso (1) identified-organization (3) thawte (101) 100 }
last: { iso (1) identified-organization (3) thawte (101) 127 }

2. IANA Considerations πŸ’…

IANA created the "SMI Security for Cryptographic Algorithms" registry inside the SMI-numbers registry. It's a brand new registry with three columns, and here's what it looks like πŸ‘‘

+------------+-------------------------------+-----------------+
| Decimal    | Description                   | References      |
+------------+-------------------------------+-----------------+
| 0-99       | Retained by DigiCert          | RFC 8411        |
| 100        | Reserved for child reg        | RFC 8411        |
| 110        | id-X25519                     | [RFC8410]       |
| 111        | id-X448                       | [RFC8410]       |
| 112        | id-EdDSA25519                 | [RFC8410]       |
| 113        | id-EdDSA448                   | [RFC8410]       |
| 114        | Reserved for id-EdDSA25519-ph | [SAFE-X.509-03] |
| 115        | Reserved for id-EdDSA448-ph   | [SAFE-X.509-03] |
| 128 and up | Retained by DigiCert          | RFC 8411        |
+------------+-------------------------------+-----------------+
Table 1: SMI Security for Cryptographic Algorithms

The registration policy is "Specification Required" as defined in [RFC8126] πŸ“‹

The 'Decimal' column is required to be a number between 100 and 127 inclusive πŸ”’

The value 100 is reserved so a new arc can be set up below that point later on (starting at 1.3.101.100.1). If that child registry does get established, a name for this value gets assigned at that time. Until then, the experts can, at their discretion, assign an algorithm OID instead 🧠

3. Security Considerations πŸ”

Okay, this part is short but it's a whole vibe. This document just fills in an IANA registry and does not raise any new security considerations at all. The protocols that actually specify these values carry their own security considerations for how they're used, so go read those too 🫢

4. References πŸ“š

Here are all the references, exactly as written:

4.1. Normative References

[ASN.1]    ITU-T, "Information Technology - Abstract Syntax Notation
           One (ASN.1): Specification of basic notation", ITU-T
           Recommendation X.680, ISO/IEC 8824-1, August 2015.

4.2. Informative References

[RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
           for Security", RFC 7748, DOI 10.17487/RFC7748, January
           2016, <https://www.rfc-editor.org/info/rfc7748>.

[RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
           Signature Algorithm (EdDSA)", RFC 8032,
           DOI 10.17487/RFC8032, January 2017,
           <https://www.rfc-editor.org/info/rfc8032>.

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

[RFC8410]  Josefsson, S. and J. Schaad, "Algorithm Identifiers for
           Ed25519, Ed448, X25519, and X448 for Use in the Internet
           X.509 Public Key Infrastructure", RFC 8410,
           DOI 10.17487/RFC8410, August 2018.

[SAFE-X.509-03]
           Josefsson, S. and J. Schaad, "Algorithm Identifiers for
           Ed25519, Ed448, X25519 and X448 for use in the Internet
           X.509 Public Key Infrastructure", Work in Progress,
           draft-ietf-curdle-pkix-03, November 2016.

Acknowledgments πŸ™

Huge thanks to DigiCert for donating the OID range this document covers πŸ’œ When the donation happened, the root of the range was assigned to Symantec. It has since been transferred to DigiCert.

This document also uses a lot of text from a similar document by Russ Housley. As the authors put it, copying always makes things easier and less error prone 😭

Authors' Addresses πŸ’Œ

Jim Schaad August Cellars

Email: ietf@augustcellars.com

Rick Andrews DigiCert, Inc.

Email: rick.andrews@digicert.com

πŸ“¦ where this page comes from