RFC 8419

Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS)

📅 published August 2018, from ietf

📜 RFC 8419 💖 Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS)

okay bestie, so this one is by R. Housley from Vigil Security 🦋, and it's a Standards Track doc ✨ published in August 2018. It's an official ISSN 2070-1721 thing, and it doesn't obsolete or update any other RFCs, so it's a clean slate 🧼✨

Anyway, the whole vibe here is: how do you use EdDSA signatures inside CMS (the Cryptographic Message Syntax) without things going sideways? It's giving "here's the rulebook, no cap" 💅

Abstract

okay so the TL;DR 🌸 this doc sets the conventions for using EdDSA with curve25519 and curve448 in CMS. EdDSA has two modes, PureEdDSA and HashEdDSA 🧐, but HashEdDSA is not used with CMS, and no context string is used with CMS either. so yeah, only the pure version is in the chat 💜

Status of This Memo

this is an Internet Standards Track document 🎀 which means it went through public review and got the okay from the IESG (the Internet Engineering Steering Group) 👑 if you want more info on how Internet Standards work, check out Section 2 of RFC 7841 🍓

the current status, errata, and feedback stuff lives at:

https://www.rfc-editor.org/info/rfc8419

Copyright (c) 2018 IETF Trust and the document authors 💕 All rights reserved, so be respectful 🫶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which are in effect as of the publication date. Read these carefully, bestie, because they explain your rights and restrictions 📚

Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as described in the Simplified BSD License 🧚

Table of Contents

okay so here's the map 🗺️ (page numbers from the original, for your collection 🌈):

1. Introduction ....................................................2
   1.1. Terminology ................................................2
   1.2. ASN.1 ......................................................2
2. EdDSA Signature Algorithm .......................................3
   2.1. Algorithm Identifiers ......................................3
   2.2. EdDSA Algorithm Identifiers ................................3
   2.3. Message Digest Algorithm Identifiers .......................4
   2.4. EdDSA Signatures ...........................................4
3. Signed-data Conventions .........................................5
   3.1. Signed-data Conventions with Signed Attributes .............5
   3.2. Signed-data Conventions without Signed Attributes ..........6
4. Implementation Considerations ...................................6
5. Security Considerations .........................................6
6. IANA Considerations .............................................7
7. References ......................................................7
   7.1. Normative References .......................................7
   7.2. Informative References .....................................8
Acknowledgments ....................................................9
Author's Address ...................................................9

1. Introduction ✨

okay so this doc is all about using EdDSA [RFC8032] with curve25519 [CURVE25519] and curve448 [CURVE448] in the CMS [RFC5652] signed-data content type 💖 EdDSA has PureEdDSA and HashEdDSA modes [RFC8032], but HashEdDSA is a no-go for CMS 🙅‍♀️ and no context string is used with CMS either. the curves get nicknames: EdDSA with curve25519 is "Ed25519", and EdDSA with curve448 is "Ed448" 🦋 and the CMS rules for PureEdDSA with Ed25519 and Ed448 are what's in here ✨

1.1. Terminology

the BCP 14 key words are in play here 🧠 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in ALL CAPS like this 💅 lowercase versions are just regular words, no cap.

1.2. ASN.1

CMS values are generated using ASN.1 [X680], which uses the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) [X690] 🌸

2. EdDSA Signature Algorithm 🦋

the Edwards-curve Digital Signature Algorithm (EdDSA) [RFC8032] is a variant of Schnorr's signature system with (possibly twisted) Edwards curves 🧚 Ed25519 is meant to run at around the 128-bit security level, and Ed448 is meant to run at around the 224-bit security level 💪

one of EdDSA's parameters is the "prehash" function 🔥 it can be the identity function, which gives you an algorithm called "PureEdDSA", or a collision-resistant hash function, which gives you "HashEdDSA" 👑 most of the time, the CMS SignedData includes signed attributes, including the message digest of the content. since HashEdDSA gives no benefit when signed attributes are there, only PureEdDSA is used with CMS 💜

2.1. Algorithm Identifiers

each algorithm is identified by an object identifier, and the algorithm identifier can carry parameters if it needs them 🎀

here's the ALGORITHM definition, repeated for convenience:

ALGORITHM ::= CLASS {
    &id    OBJECT IDENTIFIER UNIQUE,
    &Type  OPTIONAL }
  WITH SYNTAX {
    OID &id [PARMS &Type] }

2.2. EdDSA Algorithm Identifiers

the EdDSA signature algorithm is defined in [RFC8032], and the rules for encoding the public key are in [RFC8410] 🌈

the id-Ed25519 and id-Ed448 object identifiers identify EdDSA public keys in certificates. they're specified in [RFC8410], and repeated here for convenience 🍓

sigAlg-Ed25519  ALGORITHM  ::=  { OID id-Ed25519 }

sigAlg-Ed448    ALGORITHM  ::=  { OID id-Ed448 }

id-Ed25519  OBJECT IDENTIFIER  ::=  { 1 3 101 112 }

id-Ed448    OBJECT IDENTIFIER  ::=  { 1 3 101 113 }

2.3. Message Digest Algorithm Identifiers

when the signer includes signed attributes, a message digest algorithm computes the message digest on the eContent value 🔍 when signing with Ed25519, the message digest algorithm MUST be SHA-512 [FIPS180] 🔐 more info on SHA-512 is in [RFC6234] 🧁 when signing with Ed448, the message digest algorithm MUST be SHAKE256 [FIPS202] with a 512-bit output value 🦄

signing with Ed25519 uses SHA-512 as part of the signing operation, and signing with Ed448 uses SHAKE256 as part of the signing operation ✨

for convenience, the object identifiers and parameter syntax for these algorithms are repeated here 💖

hashAlg-SHA-512  ALGORITHM  ::=  { OID id-sha512 }

hashAlg-SHAKE256  ALGORITHM  ::=  { OID id-shake256 }
hashAlg-SHAKE256-LEN  ALGORITHM  ::=  { OID id-shake256-len
                        PARMS ShakeOutputLen }

hashalgs  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
                        country(16) us(840) organization(1)
                        gov(101) csor(3) nistalgorithm(4) 2 }

id-sha512  OBJECT IDENTIFIER  ::=  { hashAlgs 3 }

id-shake256  OBJECT IDENTIFIER  ::=  { hashAlgs 12 }

id-shake256-len  OBJECT IDENTIFIER  ::=  { hashAlgs 18 }

ShakeOutputLen  ::=  INTEGER  -- Output length in bits

when using the id-sha512 or id-shake256 algorithm identifier, the parameters MUST be absent 🙅‍♀️

when using the id-shake256-len algorithm identifier, the parameters MUST be present, and the parameter MUST contain 512, encoded as a positive integer value 💅

2.4. EdDSA Signatures

the id-Ed25519 and id-Ed448 object identifiers are also used for signature values 🫶 when they identify signature algorithms, the AlgorithmIdentifier parameters field MUST be absent 🙈

the data to be signed goes through PureEdDSA, and then a private key operation spits out the signature value 🔑 as described in Section 3.3 of [RFC8032], the signature value is the opaque value ENC(R) || ENC(S), where || means concatenation 🧵 and as described in Section 5.3 of [RFC5652], the signature value is ASN.1 encoded as an OCTET STRING and goes in the signature field of SignerInfo 💜

3. Signed-data Conventions 🌸

the processing depends on whether the signer includes signed attributes 🧐

including signed attributes is preferred 💖 but the conventions for signed-data without signed attributes are provided for completeness, so don't skip them 🙃

3.1. Signed-data Conventions with Signed Attributes

the SignedData digestAlgorithms field includes the identifiers of the message digest algorithms used by one or more signers 🍓 there MAY be any number of elements in the collection, including zero 🦋 when signing with Ed25519, the digestAlgorithm SHOULD include id-sha512, and if it's present, the algorithm parameters field MUST be absent ✨ when signing with Ed448, the digestAlgorithm SHOULD include id-shake256-len, and if it's present, the algorithm parameters field MUST also be present, and the parameter MUST contain 512, encoded as a positive integer value 💅

the SignerInfo digestAlgorithm field includes the identifier of the message digest algorithm used by the signer 🔐 when signing with Ed25519, the digestAlgorithm MUST be id-sha512, and the algorithm parameters field MUST be absent 🫶 when signing with Ed448, the digestAlgorithm MUST be id-shake256-len, the algorithm parameters field MUST be present, and the parameter MUST contain 512, encoded as a positive integer value 🌈

the SignerInfo signedAttributes MUST include the message-digest attribute as specified in Section 11.2 of [RFC5652] 💜 when signing with Ed25519, the message-digest attribute MUST contain the message digest computed over the eContent value using SHA-512 🎀 when signing with Ed448, the message-digest attribute MUST contain the message digest computed over the eContent value using SHAKE256 with an output length of 512 bits 🧁

the SignerInfo signatureAlgorithm field MUST contain either id-Ed25519 or id-Ed448, depending on which elliptic curve the signer used 🦄 the algorithm parameters field MUST be absent 🙈

the SignerInfo signature field contains the octet string that comes out of the EdDSA private key signing operation 🔑✨

🚧 okay bestie, that's part 1! the rest of the doc (Section 3.2 onward, plus Implementation Considerations, Security Considerations, IANA, References, Acknowledgments, and the Author's Address) is coming in part 2 💕 stay tuned, we're not done yet 🌟

3.2. Signed-data Conventions without Signed Attributes ✨

okay so the SignedData digestAlgorithms field is where you list the message digest algorithms used by one or more signers 💅 There MAY be any number of elements in that collection, even zero 🌸 When you sign with Ed25519, the list MAY include id-sha512, and if it's there, the algorithm parameters field MUST be absent 🫶 When you sign with Ed448, the list MAY include id-shake256, and if it's there, the algorithm parameters field MUST be absent 🦋

The SignerInfo digestAlgorithm field holds the identifier of the message digest algorithm the signer used ✨ With Ed25519, the digestAlgorithm MUST be id-sha512, and the algorithm parameters field MUST be absent 💜 With Ed448, the digestAlgorithm MUST be id-shake256, and the algorithm parameters field MUST be absent 🎀

NOTE: Either id-sha512 or id-shake256 is used as part of the private key signing operation 🙈 But that operation doesn't take a message digest computed with either of these algorithms as an input, so it's not a double-hash situation.

The SignerInfo signatureAlgorithm field MUST contain either id-Ed25519 or id-Ed448, depending on which elliptic curve the signer used 👑 The algorithm parameters field MUST be absent here too.

The SignerInfo signature field contains the octet string that comes out of the EdDSA private key signing operation 🔥

4. Implementation Considerations ✨

The EdDSA specification [RFC8032] includes the following warning, and it's honestly worth highlighting 👀 It matters most when signed-data is used without signed attributes and the content to be signed might be quite large 📦

PureEdDSA requires two passes over the input. Many existing APIs, protocols, and environments assume digital signature algorithms only need one pass over the input and may have API or bandwidth concerns supporting anything else.

5. Security Considerations 💀

Okay, this section is serious, bestie 😭 Implementations must protect the EdDSA private key. If the EdDSA private key is compromised, somebody may be able to forge signatures 🚨

The generation of the EdDSA private key relies on random numbers 🎲 Using inadequate pseudo-random number generators (PRNGs) to create these values can result in little or no security 😩 An attacker may find it much easier to reproduce the PRNG environment that produced the keys and then search the resulting small set of possibilities, instead of brute-force searching the whole key space 🙀 Generating quality random numbers is genuinely difficult, and RFC 4086 [RANDOM] offers important guidance in this area 📚

Unlike DSA and Elliptic Curve Digital Signature Algorithm (ECDSA), EdDSA does not require the generation of a random value for each signature operation 🦋

Using the same private key with different algorithms has the potential to leak extra information about the private key to an attacker 👀 For this reason, the same private key SHOULD NOT be used with more than one set of EdDSA parameters 🚫 Although, it appears there are no security concerns when using the same private key with PureEdDSA and HashEdDSA [RFC8032] 🤷‍♀️

When computing signatures, the same hash function SHOULD be used for all operations 💅 This reduces the number of failure points in the signature process 🫶

6. IANA Considerations 🧚

This document has no IANA actions. Nothing to register, bestie 🌈

7. References 📚

7.1. Normative References

7.2. Informative References

Acknowledgements 🫶

Many thanks to Jim Schaad, Daniel Migault, and Adam Roach for the careful review and comments 💖 Thanks also to Quynh Dang for coordinating the object identifiers assignment by NIST 🌸

Author's Address 🦋

Russ Housley
918 Spring Knoll Drive
Herndon, VA  20170
United States of America

Email: housley@vigilsec.com
📦 where this page comes from