Skip to main content

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

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: The IESG <>,, Daniel Migault <>,,,,,
Subject: Protocol Action: 'Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure' to Proposed Standard (draft-ietf-curdle-pkix-10.txt)

The IESG has approved the following document:
- 'Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for use in
   the Internet X.509 Public Key Infrastructure'
  (draft-ietf-curdle-pkix-10.txt) as Proposed Standard

This document is the product of the CURves, Deprecating and a Little more
Encryption Working Group.

The IESG contact persons are Benjamin Kaduk and Eric Rescorla.

A URL of this Internet Draft is:

Ballot Text

Technical Summary

   This document specifies algorithm identifiers and ASN.1 encoding
   formats for Elliptic Curve constructs using the Curve25519 and
   Curve448 curves.  The signature algorithms covered are Ed25519,
   Ed448.  The key agreement algorithm covered
   are X25519 and X448.  The Encoding for Public Key, Private Key and
   EdDSA digital signature structures is provided.

Working Group Summary

Main discussions that happened regarding the draft were:
      - the use of a context or not. The current agreement was not to use any specific context as this would lead to encourage people to use the same key for different usages. The same discussion appears in IPsec, with the DNSKEY. 
    - Names and designation for IOD format. We met in the IETF in Berlin (Benjamin, Jim, Russ as well as Rich and Daniel) and the next version reflected the discussion, and were adopted by the WG.   
    - Use of prehash or pure variant was raised in version 03 that mentioned "CAs MUST NOT use the pre-hash versions".  The main argument for enabling the prehash variant was to be able to sign large amount of data such as CRLs. However this can be addressed by combining CRL distribution points, combined with segmenting the certificates. For the care of simplicity, the consensus was that a single variant should be considered only and the choice was to follow the FCRG recommendations and chose the pure variant. As a result the draft has removed any mention of the purehash variant and stated clearly that only the pure variant is addressed by the draft.
    - OID identifier parameter MUST be absent and a parameter set to NULL MUST NOT be accepted.  Java implementation cannot be currently compatible with this. However, the working group consensus was to have a straight enforcement of the update specification of AlgorithmIdentifier. This is clearly mentioned in the draft so implementation can understand the motivation as well as becoming compliant with the updated spec.
      When the 1997
      syntax for AlgorithmIdentifier was initially defined, it omitted
      the OPTIONAL key word.  The optionality of the parameters field
      was later recovered via a defect report, but by then many people
      thought that the field was mandatory.  For this reason, a small
      number of implementations may still require the field to be

Document Quality

   There are several partial implementations and extensive review was received.


Daniel Migault is the document shepherd.   Eric Rescorla is the AD. 

RFC Editor Note