Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS)
Extracted elements (19)
HashEdDSA mode is not used with CMS because CMS SignedData typically includes signed attributes with the message digest of the content, making HashEdDSA offer no benefit. Only PureEdDSA is used with CMS.
No context string is used with CMS when applying EdDSA, as specified by design choice to keep the CMS integration straightforward.
The SignedData digestAlgorithms field SHOULD include the relevant hash OID when signing with signed attributes, but MAY include or omit it when signing without signed attributes, because in the latter case the digest is used internally to the signing operation rather than as a separately computed input.
PureEdDSA requires two passes over the input, which may cause API or bandwidth issues in environments that assume digital signature algorithms only need one pass. This is especially relevant when signed-data is used without signed attributes over large content.
When signing without signed attributes using Ed448, the digestAlgorithm is id-shake256 (not id-shake256-len), and parameters MUST be absent — contrasting with the signed-attributes case where id-shake256-len with a length parameter is required.
The SignerInfo signatureAlgorithm field MUST contain either id-Ed25519 or id-Ed448 depending on the curve used, and the algorithm parameters field MUST be absent.
The SignerInfo signedAttributes MUST include the message-digest attribute (RFC 5652 Section 11.2). For Ed25519, this digest MUST use SHA-512; for Ed448, SHAKE256 with 512-bit output.
When id-Ed25519 or id-Ed448 is used to identify a signature algorithm, the AlgorithmIdentifier parameters field MUST be absent.
When signing with Ed25519 and signed attributes are present, the SignerInfo digestAlgorithm MUST be id-sha512 and the algorithm parameters field MUST be absent.
When signing with Ed448 and signed attributes are present, the SignerInfo digestAlgorithm MUST be id-shake256-len, the algorithm parameters field MUST be present, and the parameter MUST contain 512 encoded as a positive integer.
When signing without signed attributes using Ed25519, the SignerInfo digestAlgorithm MUST be id-sha512 with absent parameters; for Ed448 it MUST be id-shake256 with absent parameters.
When using the id-sha512 or id-shake256 algorithm identifier, the parameters MUST be absent. When using id-shake256-len, the parameters MUST be present and MUST contain 512 encoded as a positive integer.
Ed25519 (EdDSA with curve25519) is identified by OID id-Ed25519 { 1 3 101 112 } and Ed448 (EdDSA with curve448) by id-Ed448 { 1 3 101 113 }, both defined in RFC 8410 and reused here for CMS algorithm identifiers.
The SignedData digestAlgorithms collection MAY contain any number of elements including zero. When signing with Ed25519 using signed attributes, it SHOULD include id-sha512; with Ed448 it SHOULD include id-shake256-len with a 512-bit length parameter.
Implementations must protect the EdDSA private key; compromise may allow signature forgery. Private key generation relies on quality random numbers, and inadequate PRNGs can result in little or no security — RFC 4086 provides guidance.
The same private key SHOULD NOT be used with more than one set of EdDSA parameters, as doing so may leak information about the key to an attacker, even though no concrete attack is known for PureEdDSA/HashEdDSA reuse.
Unlike DSA and ECDSA, EdDSA does not require generating a fresh random value per signature operation, which removes one class of implementation failure.
When computing signatures, the same hash function SHOULD be used for all operations to reduce the number of failure points in the signature process.
The EdDSA signature value is ENC(R) || ENC(S) as defined in RFC 8032 Section 3.3; it is ASN.1 encoded as an OCTET STRING and stored in the SignerInfo signature field.