Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure
updated by
- rfc-9295 — Clarifications for Ed25519, Ed448, X25519, and X448 Algorithm Identifiers
Extracted elements (19)
Contexts (as defined in RFC 8032) are not included in this specification for several reasons: current Ed25519 implementations do not support them, there is potential for confusion about which algorithms require separate keys, there is ongoing cryptographic debate about their effectiveness, and there is no clear consensus on how to identify context string usage via OIDs.
Some systems require AlgorithmIdentifier parameters to be present due to defects in the original 1997 syntax or programming errors. The document notes the optimal solution is to fix such systems rather than propagating the requirement to the Internet.
This document covers only PureEdDSA mode (Ed25519, Ed448) and does not provide conventions for HashEdDSA (prehash) variants, as the convention for the pure mode is the established one and prehash variants have different identifier considerations.
Early implementations may have incorrectly used OCTET STRING instead of BIT STRING for the public key field (a copy error from a prior draft). Additionally, the OneAsymmetricKey version field must be 0 when publicKey is absent and 1 when publicKey is present.
Some acceptors will only decode DER-encoded OneAsymmetricKey objects despite RFC 5958 requiring BER decoding for compliance. The appendix provides a valid BER-encoded private key example that may be rejected by strict implementations.
Some private key import functions have not adopted the OneAsymmetricKey structure from RFC 7748 and will reject private key structures that include the optional publicKey field. Implementers must balance consistency checking against maximum import compatibility.
For all four algorithm OIDs (id-X25519, id-X448, id-Ed25519, id-Ed448), the parameters field in AlgorithmIdentifier MUST be absent.
If the keyUsage extension is present in a CA certificate indicating id-Ed25519 or id-Ed448, the keyUsage extension MUST contain one or more of: nonRepudiation, digitalSignature, keyCertSign, cRLSign.
If the keyUsage extension is present in an end-entity certificate indicating id-Ed25519 or id-Ed448, the keyUsage extension MUST contain nonRepudiation and/or digitalSignature.
Implementations SHOULD use the human-readable algorithm names defined in Section 8: 'ECDH' for X25519/X448 when curve is unknown, 'X25519'/'X448' when curve is known, 'EdDSA' for signing when curve is unknown, and 'Ed25519'/'Ed448' when curve is known.
Key encoding requirements from RFC 7748 and RFC 8032 must be enforced when importing keys. Enforcement may be done by applying masking or mod p operations, or by rejecting non-conforming keys with an import failure.
When algorithm identifiers are used to identify signature algorithms (as opposed to public keys), the parameters MUST be absent.
CurvePrivateKey is defined as an OCTET STRING to hold the opaque byte sequence of the private key for EdDSA, X25519, or X448. This type provides a uniform container for all four algorithm private keys.
Four OIDs are defined for curve25519/curve448 algorithm identifiers: id-X25519 (1.3.101.110), id-X448 (1.3.101.111), id-Ed25519 (1.3.101.112), and id-Ed448 (1.3.101.113). The same OIDs identify public keys, private keys, and signatures for the EdDSA variants.
IANA registered value 93 for 'id-mod-safecurves-pkix' in the 'SMI Security for PKIX Module Identifier' registry (1.3.6.1.5.5.7.0). The four algorithm OIDs are independently registered in 'SMI Security for Cryptographic Algorithms' via RFC 8411.
The procedures for deriving a public key from a private key differ between Diffie-Hellman (X25519/X448) and Edwards Signatures (Ed25519/Ed448). Consequently, the same private key will not produce the same public key for both operations, and the same public key cannot be used for both ECDH and EdDSA.
EdDSA signature value is the opaque ENC(R) || ENC(S) octet string from RFC 8032 Section 3.3, encoded directly in the BIT STRING without additional ASN.1 wrapping. For X.509 certificates, this is placed in the signatureValue BIT STRING field.
Private keys for EdDSA, X25519, and X448 are encoded using the OneAsymmetricKey structure (RFC 5958). The private key byte sequence is wrapped in a CurvePrivateKey OCTET STRING, which is then wrapped in the privateKey OCTET STRING field. The optional publicKey field holds the encoded public key as a BIT STRING.
The SubjectPublicKeyInfo structure encodes the public key in the subjectPublicKey BIT STRING field. For all algorithms defined in this document, the public key is always encoded as an exact multiple of 8 bits with no additional ASN.1 wrapping.