Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: The IESG <firstname.lastname@example.org>, email@example.com, Daniel Migault <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com 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: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/
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 present. """ Document Quality There are several partial implementations and extensive review was received. Personnel Daniel Migault is the document shepherd. Eric Rescorla is the AD.