RFC 8410

Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure

📅 published August 2018, from ietf

RFC 8410 🌈

Okay bestie, this one is from the IETF, and it's all about giving Ed25519, Ed448, X25519, and X448 their own ID cards so they can show up in X.509 certificates ✨. Here's the title block tea 🫶

  • Title: Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure
  • Authors: S. Josefsson (SJD AB) and J. Schaad (August Cellars) 💖
  • Category: Standards Track 👑
  • Date: August 2018 🌸
  • ISSN: 2070-1721
  • Obsoletes / Updates: nothing is listed in the header, so this one isn't replacing or updating any other RFC 🙈

Abstract ✨

Okay so this doc sets up the algorithm identifiers and the ASN.1 encoding formats for the elliptic curve stuff that uses curve25519 and curve448 🦋. The signature algorithms it covers are Ed25519 and Ed448. The key agreement algorithms it covers are X25519 and X448. It also gives the encoding for the public key, private key, and Edwards-curve Digital Signature Algorithm (EdDSA) structures 💅.

Status of This Memo

This is an Internet Standards Track document 👑.

It's a product of the Internet Engineering Task Force (IETF), and it reflects the consensus of the IETF community 🫶. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check Section 2 of RFC 7841 🌈.

For the current status of this document, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8410 💜.

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 were in effect on the publication date. Please read these carefully, because they explain your rights and restrictions for this document 🙈. Code Components pulled out of this document must include the 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.  Requirements Terminology  . . . . . . . . . . . . . . . . . .   3
3.  Curve25519 and Curve448 Algorithm Identifiers . . . . . . . .   3
4.  Subject Public Key Fields . . . . . . . . . . . . . . . . . .   4
5.  Key Usage Bits  . . . . . . . . . . . . . . . . . . . . . . .   5
6.  EdDSA Signatures  . . . . . . . . . . . . . . . . . . . . . .   6
7.  Private Key Format  . . . . . . . . . . . . . . . . . . . . .   7
8.  Human-Readable Algorithm Names  . . . . . . . . . . . . . . .   8
9.  ASN.1 Module  . . . . . . . . . . . . . . . . . . . . . . . .   9
10. Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  11
  10.1.  Example Ed25519 Public Key . . . . . . . . . . . . . . .  11
  10.2.  Example X25519 Certificate . . . . . . . . . . . . . . .  12
  10.3.  Examples of Ed25519 Private Key  . . . . . . . . . . . .  14
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
12. Security Considerations . . . . . . . . . . . . . . . . . . .  15
13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
  13.1.  Normative References . . . . . . . . . . . . . . . . . .  16
  13.2.  Informative References . . . . . . . . . . . . . . . . .  16
Appendix A.  Invalid Encodings  . . . . . . . . . . . . . . . . .  18
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  19
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

1. Introduction ✨

Okay so [RFC7748] is where the elliptic curves curve25519 and curve448 get described 🦋. They were designed with performance and security in mind 💅. These curves can be used for Diffie-Hellman and for digital signature operations 🔥.

[RFC7748] covers the Diffie-Hellman operations on these curves. There's a convention where, when these two curves are used for Diffie-Hellman, people call them X25519 and X448 💖. This RFC defines the ASN.1 Object Identifiers (OIDs) for the X25519 and X448 operations, along with their parameters. It also explains how to use these OIDs for public and private keys 🌸.

[RFC8032] describes the elliptic curve signature system called Edwards-curve Digital Signature Algorithm (EdDSA), and it recommends using curve25519 and curve448 with it 🌈. EdDSA has two modes: PureEdDSA, which doesn't prehash, and HashEdDSA, which does prehash 🧚. The naming convention for algorithm and curve combos is "Ed25519" and "Ed448" for the PureEdDSA mode. This document does not give the conventions for the prehash versions of the signature algorithm 🙈. It does explain how to use the OIDs for public keys, private keys, and signatures 🫶.

[RFC8032] also defines the concept of a context. Contexts can separate signatures made for different purposes with the same key 🔑. This document does not define how to use contexts, and here's why 👀:

  • The current implementations of Ed25519 don't support contexts, so if they got specified now, it could push back the use of these algorithms even further 😭.
  • EdDSA is the only IETF algorithm that supports contexts right now. But people could get confused about which algorithms need separate keys and which don't, and that might lower security for those other algorithms 💀.
  • The cryptographic community is still talking about how well contexts actually help prevent attacks 🤔.
  • More discussion is needed on the right way to identify when context strings should be used. It isn't clear whether different OIDs should be used for different contexts, or whether the OID should just show that a context string has to be provided 🎀.

2. Requirements Terminology 💅

Okay, this is the important bit 👑. 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 read as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in all capitals, just like they do here 🌸.

3. Curve25519 and Curve448 Algorithm Identifiers 🦋

Certificates that follow [RFC5280] can carry a public key for any public key algorithm 🌈. The certificate tells you which algorithm it is with an algorithm identifier. An algorithm identifier is made of an OID and optional parameters 💖.

The AlgorithmIdentifier type is included here for convenience, and it's defined like this 🧚:

AlgorithmIdentifier  ::=  SEQUENCE  {
    algorithm   OBJECT IDENTIFIER,
    parameters  ANY DEFINED BY algorithm OPTIONAL
}

The fields in AlgorithmIdentifier mean the following 🫶:

  • algorithm identifies the cryptographic algorithm with an object identifier. Four such OIDs are defined below.
  • parameters, which are optional, are the associated parameters for the algorithm identifier in the algorithm field.

In this document, we define four new OIDs to identify the different curve and algorithm pairs ✨. The curves are curve25519 and curve448, and the algorithms are ECDH and EdDSA in pure mode 🔥. For all of the OIDs, the parameters MUST be absent 💅.

Some systems actually need the parameters to be present 😭. That can happen because of a defect in the original 1997 syntax, or because of a programming error where developers never got the memo that this wasn't true 🙈. The best fix is to repair those systems. If that's not possible, the problem should be contained to that subsystem and kept from spreading across the Internet 🛑.

The same algorithm identifiers are used to identify a public key, a private key, and a signature (for the two EdDSA related OIDs) 💜. There's extra encoding info below for each of these spots 🍓.

id-X25519    OBJECT IDENTIFIER ::= { 1 3 101 110 }
id-X448      OBJECT IDENTIFIER ::= { 1 3 101 111 }
id-Ed25519   OBJECT IDENTIFIER ::= { 1 3 101 112 }
id-Ed448     OBJECT IDENTIFIER ::= { 1 3 101 113 }

4. Subject Public Key Fields 🌸

In the X.509 certificate, the subjectPublicKeyInfo field uses the SubjectPublicKeyInfo type, which has this ASN.1 syntax 💖:

SubjectPublicKeyInfo  ::=  SEQUENCE  {
    algorithm         AlgorithmIdentifier,
    subjectPublicKey  BIT STRING
}

The fields in SubjectPublicKeyInfo mean the following 🦋:

  • algorithm is the algorithm identifier and parameters for the public key (see above).
  • subjectPublicKey holds the byte stream of the public key. The algorithms defined in this document always encode the public key as an exact multiple of 8 bits ✨.

Both [RFC7748] and [RFC8032] define the public key value as a byte string 🧚. Worth noting: the public key gets computed differently in each of those documents, so the same private key will not produce the same public key 😭.

Here's an example of a public key in the textual encoding defined in [RFC7468] 🎀:

-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEAGb9ECWmEzf6FQbrBZ9w7lshQhqowtrbLDFw4rXAxZuE=
-----END PUBLIC KEY-----

5. Key Usage Bits 🔑

The intended application for the key is shown in the keyUsage certificate extension 💅.

If the keyUsage extension is present in a certificate that indicates id-X25519 or id-X448 in SubjectPublicKeyInfo, then the following MUST be present 🌈:

keyAgreement;

One of the following MAY also be present 🦋:

encipherOnly; or
decipherOnly.

If the keyUsage extension is present in an end-entity certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage extension MUST contain one or both of the following values 💖:

nonRepudiation; and
digitalSignature.

If the keyUsage extension is present in a certification authority certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage extension MUST contain one or more of the following values 👑:

nonRepudiation;
digitalSignature;
keyCertSign; and
cRLSign.

6. EdDSA Signatures 🫶

Signatures can live in a bunch of different ASN.1 structures 🧚. The top level structure for a certificate is shown below. It's here to show how signatures are usually encoded, with an algorithm identifier and a spot for the signature ✨:

Certificate  ::=  SEQUENCE {
     tbsCertificate       TBSCertificate,
     signatureAlgorithm   AlgorithmIdentifier,
     signatureValue       BIT STRING  }

The same algorithm identifiers get used for signatures as for public keys 🔥. When they're identifying signature algorithms, the parameters MUST be absent 💅.

The data to be signed gets prepared for EdDSA first 🌸. Then a private key operation runs to generate the signature value 🦋. That value is the opaque value ENC(R) || ENC(S) described in Section 3.3 of [RFC8032] 🌈. The octet string for the signature goes straight into the BIT STRING, with no extra ASN.1 wrapping 💖. In the Certificate structure, the signature value sits in the "signatureValue" BIT STRING field 🍓.

7. Private Key Format 🔑

Okay bestie, so "Asymmetric Key Packages" [RFC5958] is the spec that explains how to wrap a private key in a structure that says which algorithm it's for. It even lets you tuck in the public key and extra attributes too 💅 For illustration, here's the ASN.1 structure OneAsymmetricKey, copied over so you can see the whole vibe:

   OneAsymmetricKey ::= SEQUENCE {
      version Version,
      privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
      privateKey PrivateKey,
      attributes [0] IMPLICIT Attributes OPTIONAL,
      ...,
      [[2: publicKey [1] IMPLICIT PublicKey OPTIONAL ]],
      ...
   }

   PrivateKey ::= OCTET STRING

   PublicKey ::= BIT STRING

The nitty gritty of how each algorithm encodes its own private key is left to the doc for that algorithm 🦋

For the keys in this doc, the private key is always an opaque byte sequence (basically a blob of bytes, no peeking inside 🙈). The ASN.1 type CurvePrivateKey exists to hold that byte sequence. So when you encode a OneAsymmetricKey object, the private key gets wrapped in a CurvePrivateKey object, and that whole thing is wrapped in the OCTET STRING of the "privateKey" field.

   CurvePrivateKey ::= OCTET STRING

To encode an EdDSA, X25519, or X448 private key, the "privateKey" field holds the encoded private key. The "privateKeyAlgorithm" field uses the AlgorithmIdentifier structure, encoded as defined above. If it's present, the "publicKey" field holds the encoded key as defined in [RFC7748] and [RFC8032] 💜

Here's an example of a private key in the textual encoding from [RFC7468]:

   -----BEGIN PRIVATE KEY-----
   MC4CAQAwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC
   -----END PRIVATE KEY-----

This next one is a glow-up: it encodes the private key too, but it also has an attribute and the public key included. Same textual encoding from [RFC7468] as before ✨

   -----BEGIN PRIVATE KEY-----
   MHICAQEwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC
   oB8wHQYKKoZIhvcNAQkJFDEPDA1DdXJkbGUgQ2hhaXJzgSEAGb9ECWmEzf6FQbrB
   Z9w7lshQhqowtrbLDFw4rXAxZuE=
   -----END PRIVATE KEY------
NOTE: Ngl, this is a bit of a drama. Some private key import functions haven't caught up with the new OneAsymmetricKey ASN.1 structure defined in [RFC7748] 😭 So they won't accept a private key structure that has the public key field. That means you have to do a balancing act between being able to do a consistency check on the key pair and having the widest possible ability to import the key.

8. Human-Readable Algorithm Names 🏷️

For consistent naming across implementations, this section sets up human-readable names for the algorithms in this document. Implementations SHOULD use these names when they refer to the algorithms 💖 If there's a strong reason to deviate, like an implementation with its own naming convention that wants to stay internally consistent, it's encouraged to deviate as little as possible from the names given here 🫶

Use the string ECDH when you're referring to a public key of type X25519 or X448 and the curve is unknown or doesn't matter.

When the curve is known, use the more specific string X25519 or X448 instead.

Use the string EdDSA when you're referring to a signing public key or signature and the curve is unknown or doesn't matter.

When the curve is known, use a more specific string. For the id-Ed25519 value, use Ed25519. For id-Ed448, use Ed448 🔥

9. ASN.1 Module 📜

For reference purposes, the ASN.1 syntax is presented as an ASN.1 module right here 🍓

   -- ASN.1 Module

   Safecurves-pkix-18
   { iso(1) identified-organization(3) dod(6) internet(1)
     security(5) mechanisms(5) pkix(7) id-mod(0)
     id-mod-safecurves-pkix(93) }

   DEFINITIONS EXPLICIT TAGS ::=
   BEGIN

   IMPORTS
     SIGNATURE-ALGORITHM, KEY-AGREE, PUBLIC-KEY, KEY-WRAP,
     KeyUsage, AlgorithmIdentifier
     FROM AlgorithmInformation-2009
       {iso(1) identified-organization(3) dod(6) internet(1) security(5)
       mechanisms(5) pkix(7) id-mod(0)
       id-mod-algorithmInformation-02(58)}

     mda-sha512
     FROM PKIX1-PSS-OAEP-Algorithms-2009
       { iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) id-mod(0)
         id-mod-pkix1-rsa-pkalgs-02(54) }

     kwa-aes128-wrap, kwa-aes256-wrap
     FROM CMSAesRsaesOaep-2009
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
         smime(16) modules(0) id-mod-cms-aes-02(38) }
     ;


   id-edwards-curve-algs OBJECT IDENTIFIER ::= { 1 3 101 }

   id-X25519        OBJECT IDENTIFIER ::= { id-edwards-curve-algs 110 }
   id-X448          OBJECT IDENTIFIER ::= { id-edwards-curve-algs 111 }
   id-Ed25519       OBJECT IDENTIFIER ::= { id-edwards-curve-algs 112 }
   id-Ed448         OBJECT IDENTIFIER ::= { id-edwards-curve-algs 113 }

    sa-Ed25519 SIGNATURE-ALGORITHM ::= {
       IDENTIFIER id-Ed25519
        PARAMS ARE absent
        PUBLIC-KEYS {pk-Ed25519}
        SMIME-CAPS { IDENTIFIED BY id-Ed25519 }
    }

    pk-Ed25519 PUBLIC-KEY ::= {
        IDENTIFIER id-Ed25519
        -- KEY no ASN.1 wrapping --
        PARAMS ARE absent
        CERT-KEY-USAGE {digitalSignature, nonRepudiation,
                        keyCertSign, cRLSign}
        PRIVATE-KEY CurvePrivateKey
    }

    kaa-X25519 KEY-AGREE ::= {
        IDENTIFIER id-X25519
        PARAMS ARE absent
        PUBLIC-KEYS {pk-X25519}
        UKM -- TYPE no ASN.1 wrapping -- ARE preferredPresent
        SMIME-CAPS {
           TYPE AlgorithmIdentifier{KEY-WRAP, {KeyWrapAlgorithms}}
           IDENTIFIED BY id-X25519 }
    }

    pk-X25519 PUBLIC-KEY ::= {
        IDENTIFIER id-X25519
        -- KEY no ASN.1 wrapping --
        PARAMS ARE absent
        CERT-KEY-USAGE { keyAgreement }
        PRIVATE-KEY CurvePrivateKey
    }

    KeyWrapAlgorithms KEY-WRAP ::= {
        kwa-aes128-wrap | kwa-aes256-wrap,
        ...
    }

    kaa-X448 KEY-AGREE ::= {
        IDENTIFIER id-X448
        PARAMS ARE absent
        PUBLIC-KEYS {pk-X448}
        UKM -- TYPE no ASN.1 wrapping  -- ARE preferredPresent
        SMIME-CAPS {
           TYPE AlgorithmIdentifier{KEY-WRAP, {KeyWrapAlgorithms}}
           IDENTIFIED BY id-X448 }
    }
    pk-X448 PUBLIC-KEY ::= {
        IDENTIFIER id-X448
        -- KEY no ASN.1 wrapping --
        PARAMS ARE absent
        CERT-KEY-USAGE { keyAgreement }
        PRIVATE-KEY CurvePrivateKey
    }

   CurvePrivateKey ::= OCTET STRING


   END

10. Examples 🌈

This section has illustrations of EdDSA public keys and certificates, showing off the parameter choices 💅

10.1. Example Ed25519 Public Key

Here's an example of an Ed25519 public key, serving full main character energy 👑

         Public Key Information:
             Public Key Algorithm: Ed25519
             Algorithm Security Level: High

         Public Key Usage:

         Public Key ID: 9b1f5eeded043385e4f7bc623c5975b90bc8bb3b

         -----BEGIN PUBLIC KEY-----
         MCowBQYDK2VwAyEAGb9ECWmEzf6FQbrBZ9w7lshQhqowtrbLDFw4rXAxZuE=
         -----END PUBLIC KEY-----

10.2. Example X25519 Certificate

Okay this one is so iconic 🦋 It's a self-issued PKIX certificate that uses Ed25519 to sign an X25519 public key. Here's the dump:

     0 300: SEQUENCE {
     4 223:   SEQUENCE {
     7   3:     [0] {
     9   1:       INTEGER 2
          :       }
    12   8:     INTEGER 56 01 47 4A 2A 8D C3 30
    22   5:     SEQUENCE {
    24   3:       OBJECT IDENTIFIER
          :         Ed 25519 signature algorithm { 1 3 101 112 }
          :       }
    29  25:     SEQUENCE {
    31  23:       SET {
    33  21:         SEQUENCE {
    35   3:           OBJECT IDENTIFIER commonName (2 5 4 3)
    40  14:           UTF8String 'IETF Test Demo'
          :           }
          :         }
          :       }
    56  30:     SEQUENCE {
    58  13:       UTCTime 01/08/2016 12:19:24 GMT
    73  13:       UTCTime 31/12/2040 23:59:59 GMT
          :       }
    88  25:     SEQUENCE {
    90  23:       SET {
    92  21:         SEQUENCE {
    94   3:           OBJECT IDENTIFIER commonName (2 5 4 3)
    99  14:           UTF8String 'IETF Test Demo'
          :           }
          :         }
          :       }
   115  42:     SEQUENCE {
   117   5:       SEQUENCE {
   119   3:         OBJECT IDENTIFIER
          :           ECDH 25519 key agreement { 1 3 101 110 }
          :         }
   124  33:       BIT STRING
          :         85 20 F0 09 89 30 A7 54 74 8B 7D DC B4 3E F7 5A
          :         0D BF 3A 0D 26 38 1A F4 EB A4 A9 8E AA 9B 4E 6A
          :       }
   159  69:     [3] {
   161  67:       SEQUENCE {
   163  15:         SEQUENCE {
   165   3:           OBJECT IDENTIFIER basicConstraints (2 5 29 19)
   170   1:           BOOLEAN TRUE
   173   5:           OCTET STRING, encapsulates {
   175   3:             SEQUENCE {
   177   1:               BOOLEAN FALSE
          :               }
          :             }
          :           }
   180  14:         SEQUENCE {
   182   3:           OBJECT IDENTIFIER keyUsage (2 5 29 15)
   187   1:           BOOLEAN FALSE
   190   4:           OCTET STRING, encapsulates {
   192   2:             BIT STRING 3 unused bits
          :               '10000'B (bit 4)
          :             }
          :           }
   196  32:         SEQUENCE {
   198   3:           OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14)
   203   1:           BOOLEAN FALSE
   206  22:           OCTET STRING, encapsulates {
   208  20:             OCTET STRING
          :               9B 1F 5E ED ED 04 33 85 E4 F7 BC 62 3C 59 75
          :               B9 0B C8 BB 3B
          :             }
          :           }
          :         }
          :       }
          :     }
   230   5:   SEQUENCE {
   232   3:     OBJECT IDENTIFIER
          :       Ed 25519 signature algorithm { 1 3 101 112 }
          :     }
   237  65:   BIT STRING
          :     AF 23 01 FE DD C9 E6 FF C1 CC A7 3D 74 D6 48 A4
          :     39 80 82 CD DB 69 B1 4E 4D 06 EC F8 1A 25 CE 50
          :     D4 C2 C3 EB 74 6C 4E DD 83 46 85 6E C8 6F 3D CE
          :     1A 18 65 C5 7A C2 7B 50 A0 C3 50 07 F5 E7 D9 07
          :   }

And here's that same certificate in PEM form, so you can copy and paste it 🎀

   -----BEGIN CERTIFICATE-----
   MIIBLDCB36ADAgECAghWAUdKKo3DMDAFBgMrZXAwGTEXMBUGA1UEAwwOSUVURiBUZX
   N0IERlbW8wHhcNMTYwODAxMTIxOTI0WhcNNDAxMjMxMjM1OTU5WjAZMRcwFQYDVQQD
   DA5JRVRGIFRlc3QgRGVtbzAqMAUGAytlbgMhAIUg8AmJMKdUdIt93LQ+91oNvzoNJj
   ga9OukqY6qm05qo0UwQzAPBgNVHRMBAf8EBTADAQEAMA4GA1UdDwEBAAQEAwIDCDAg
   BgNVHQ4BAQAEFgQUmx9e7e0EM4Xk97xiPFl1uQvIuzswBQYDK2VwA0EAryMB/t3J5v
   /BzKc9dNZIpDmAgs3babFOTQbs+BolzlDUwsPrdGxO3YNGhW7Ibz3OGhhlxXrCe1Cg
   w1AH9efZBw==
   -----END CERTIFICATE-----

10.3. Examples of Ed25519 Private Key 🔑

okay so here's an Ed25519 private key with no public key attached 🥺

-----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC
-----END PRIVATE KEY-----

and if you dump the same thing as ASN.1, this is what you get 🤓✨

    0 30   46: SEQUENCE {
    2 02    1:   INTEGER 0
    5 30    5:   SEQUENCE {
    7 06    3:     OBJECT IDENTIFIER
             :       Ed 25519 signature algorithm { 1 3 101 112 }
             :     }
   12 04   34:   OCTET STRING
             :     04 20 D4 EE 72 DB F9 13 58 4A D5 B6 D8 F1 F7 69
             :     F8 AD 3A FE 7C 28 CB F1 D4 FB E0 97 A8 8F 44 75
             :     58 42
             :   }

the actual value of the private key is 👀💖

D4 EE 72 DB F9 13 58 4A D5 B6 D8 F1 F7 69 F8 AD
3A FE 7C 28 CB F1 D4 FB E0 97 A8 8F 44 75 58 42

now the same Ed25519 private key, but this time it comes with an attribute AND the public key 🎀 it's giving a whole glow-up

-----BEGIN PRIVATE KEY-----
MHICAQEwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC
oB8wHQYKKoZIhvcNAQkJFDEPDA1DdXJkbGUgQ2hhaXJzgSEAGb9ECWmEzf6FQbrB
Z9w7lshQhqowtrbLDFw4rXAxZuE=
-----END PRIVATE KEY-----

and the ASN.1 dump of that one looks like this 💅

     0 114: SEQUENCE {
     2   1:   INTEGER 1
     5   5:   SEQUENCE {
     7   3:     OBJECT IDENTIFIER '1 3 101 112'
          :     }
    12  34:   OCTET STRING, encapsulates {
          :     04 20 D4 EE 72 DB F9 13 58 4A D5 B6 D8 F1 F7 69
          :     F8 AD 3A FE 7C 28 CB F1 D4 FB E0 97 A8 8F 44 75
          :     58 42
          :     }
    48  31:   [0] {
    50  29:     SEQUENCE {
    52  10:       OBJECT IDENTIFIER '1 2 840 113549 1 9 9 20'
    64  15:       SET {
    66  13:         UTF8String 'Curdle Chairs'
          :         }
          :       }
          :     }
   81  33:   [1] 00 19 BF 44 09 69 84 CD FE 85 41 BA C1 67 DC 3B
                 96 C8 50 86 AA 30 B6 B6 CB 0C 5C 38 AD 70 31 66
                 E1
          :   }

11. IANA Considerations 🌸

bestie, for the ASN.1 module in Section 9, IANA has registered value 93 for "id-mod-safecurves-pkix" in the "SMI Security for PKIX Module Identifier" (1.3.6.1.5.5.7.0) registry.

the OIDs are also being registered on their own in the IANA registry "SMI Security for Cryptographic Algorithms" in [RFC8411].

12. Security Considerations 🔐

this part is serious, so read it carefully 🥹

The security considerations of [RFC5280], [RFC7748], and [RFC8032] apply accordingly.

The procedures for going from a private key to a public key are different when used with Diffie-Hellman versus when used with Edwards Signatures. This means that the same public key cannot be used for both ECDH and EdDSA.

13. References 📚

13.1. Normative References

13.2. Informative References

Appendix A. Invalid Encodings 🙈

there are a bunch of things that need dealing with when a new key part gets decoded and imported into the system. a partial list includes:

  • ASN.1 encoding errors: Two items are highlighted here. First, the use of an OCTET STRING rather than a BIT STRING for the public key. The use of OCTET STRING was a copy error that existed in a previous draft version of this document; the structure is correct in [RFC5958]. However, any early implementation may have this wrong. Second, the value of the version field is required to be 0 if the publicKey is absent and 1 if present. This is called out in [RFC5958], but was not duplicated above.
  • Key encoding errors: Both [RFC7748] and [RFC8032] have formatting requirements for keys that need to be enforced. In some cases, the enforcement is done at the time of importing, for example, doing masking or a mod p operation. In other cases, the enforcement is done by rejecting the keys and having an import failure.
  • Key mismatch errors: If a public key is provided, it may not agree with the private key because either it is wrong or the wrong algorithm was used.

some systems are also going to be stricter about what they accept. As stated in [RFC5958], BER decoding of OneAsymmetricKey objects is a requirement for compliance. Despite this requirement, some acceptors will only decode DER formats. The following is a BER encoding of a private key. It is valid, but it may not be accepted by many systems 😬

-----BEGIN PRIVATE KEY-----
MIACAQAwgAYDK2VwAAAEIgQg1O5y2/kTWErVttjx92n4rTr+fCjL8dT74Jeoj0R1W
EIAAA==
-----END PRIVATE KEY-----

here's a quick sampling of some incorrect keys 🫣

in the following example, the private key does not match the masking requirements for X25519. For this example, the top bits are set to zero and the bottom three bits are set to 001.

-----BEGIN PRIVATE KEY-----
MFMCAQEwBQYDK2VuBCIEIPj///////////////////////////////////////8/oS
MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg==
-----END PRIVATE KEY-----

in the following examples, the key is the wrong length because an all-zero byte has been removed. In one case, the first byte has been removed; in the other case, the last byte has been removed.

-----BEGIN PRIVATE KEY-----
MFICAQEwBQYDK2VwBCIEIC3GfeUYbZGTAhwLEE2cbvJL7ivTlcy17VottfN6L8HwoS
IDIADBfk2Lv/J8H7YYwj/OmIcDx++jzVkKrKwS0/HjyQyM
-----END PRIVATE KEY-----
-----BEGIN PRIVATE KEY-----
MFICAQEwBQYDK2VwBCIEILJXn1VaLqvausjUaZexwI/ozmOFjfEk78KcYN+7hsNJoS
IDIACdQhJwzi/MCGcsQeQnIUh2JFybDxSrZxuLudJmpJLk
-----END PRIVATE KEY-----

Acknowledgments 💜

text and/or inspiration were drawn from [RFC5280], [RFC3279], [RFC4055], [RFC5480], and [RFC5639] 🫶

the following people discussed the document and gave feedback: Klaus Hartke, Ilari Liusvaara, Erwann Abalea, Rick Andrews, Rob Stradling, James Manger, Nikos Mavrogiannopoulos, Russ Housley, David Benjamin, Brian Smith, and Alex Wilson.

a big thank you to Symantec for kindly donating the OIDs used in this document 🌈✨

Authors' Addresses 🦋

Simon Josefsson SJD AB

Email: simon@josefsson.org

Jim Schaad August Cellars

Email: ietf@augustcellars.com

📦 where this page comes from