]>
<!-- Remove PH
Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure
-->
Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure
SJD ABsimon@josefsson.orgAugust Cellarsietf@augustcellars.comElliptic Curve Cryptography, Curve25519, Curve448,
Goldilocks, X.509, PKIX, PKI, OID, ASN.1, EdDSA,
Ed25519, Ed448, X25519, X448This 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 and Ed448.
The key agreement algorithm covered are X25519 and X448.
The encoding for Public Key, Private Key and EdDSA digital signature structures is provided.
In , the elliptic curves Curve25519
and Curve448 are described. They are designed with performance
and security in mind. The curves may be used for Diffie-Hellman
and Digital Signature operations.
describes the operations on these curves for the Diffie-Hellman operation.
A convention has developed that when these two curves are used with the Diffie-Hellman operation, they are referred to as X25519 and X448.
This RFC defines the ASN.1 Object Identifiers (OIDs) for the operations X25519 and X448 along with the parameters.
The use of these OIDs is described for public and private keys.
In the elliptic curve signature system Edwards-curve Digital Signature Algorithm (EdDSA) is described along with a recommendation for the use of the Curve25519 and Curve448.
EdDSA has defined two modes, the PureEdDSA mode without pre-hashing, and the HashEdDSA mode with pre-hashing.
The convention used for identifying the algorithm/curve combinations are to use the Ed25519 and Ed448 for the PureEdDSA mode.
The document does not provide the conventions needed for the pre-hash versions of the signature algorithm.
The use of the OIDs is described for public keys, private keys and signatures.
additionally defined the concept of a context.
Contexts can be used to differentiate signatures generated for different purposes with the same key.
The use of contexts is not defined in this document for the following reasons:
The current implementations of Ed25519 do not support the use of contexts, thus if specified it will potentially delay the use of these algorithms further.
The EdDSA algorithms are the only IETF algorithms that currently support the use of contexts, however there is a possibility that there will be confusion between which algorithms need have separate keys and which do not.
This may result in a decrease of security for those other algorithms.
There are still on going discussions among the cryptographic community about how effective the use of contexts is for preventing attacks.
There needs to be discussions about the correct way to identify when context strings are to be used.
It is not clear if different OIDs should be used for different contexts, or the OID should merely not that a context string needs to be provided.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in .Certificates conforming to can
convey a public key for any public key algorithm. The
certificate indicates the algorithm through an algorithm
identifier. This algorithm identifier is an OID and optionally
associated parameters.
The AlgorithmIdentifier type, which is included for
convenience, is defined as follows:The fields in AlgorithmIdentifier have the following
meanings:algorithm identifies the cryptographic algorithm with an
object identifier. This is one of the OIDs defined below.parameters, which are optional, are the associated
parameters for the algorithm identifier in the algorithm
field.
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.
In this document we defined four new OIDs for identifying the different curve/algorithm pairs.
The curves being Curve25519 and Curve448.
The algorithms being ECDH and EdDSA in pure mode.
For all of the OIDs, the parameters MUST be absent.
Regardless of the defect in the original 1997 syntax, implementations MUST NOT accept a parameters value of NULL.
The same algorithm identifiers are used for identifying a public key, identifying a private key and identifying a signature (for the four EdDSA related OIDs).
Additional encoding information is provided below for each of these locations.
In the X.509 certificate, the subjectPublicKeyInfo field has
the SubjectPublicKeyInfo type, which has the following ASN.1
syntax:The fields in SubjectPublicKeyInfo have the following meanings:algorithm is the algorithm identifier and parameters for
the public key (see above).subjectPublicKey contains the byte stream of the public key.
While the encoded public keys for the current algorithms are all an even number of octets, future curves could change that.
Both and define the public key value as being a byte string.
It should be noted that the public key is computed differently for each of these documents, thus the same private key will not produce the same public key.
The following is an example of a public key encoded using the textual encoding defined in .The intended application for the key is indicated in the
keyUsage certificate extension.
If the keyUsage extension is present in a certificate that indicates
id-X25119 or id-X448 in SubjectPublicKeyInfo, then the following MUST
be present:
one of the following MAY also be present:
If the keyUsage extension is present in an end-entity
certificate that indicates id-EdDSA25519 or id-EdDSA448, then the keyUsage extension
MUST contain one or both of the following values:If the keyUsage extension is present in a certification
authority certificate that indicates id-EdDSA25519 or id-EdDSA448, then the keyUsage extension
MUST contain one or more of the following values:
Signatures can be placed in a number of different ASN.1 structures.
The top level structure for a certificate is given below as being illustrative of how signatures are frequently encoded with an algorithm identifier and a location for the signature.
The same algorithm identifiers are used for signatures as are used for public keys.
When used to identify signature algorithms, the parameters MUST be absent.
The data to be signed is prepared for EdDSA. Then, a private
key operation is performed to generate the signature value.
This value is the opaque value ENC(R) || ENC(S) described in
section 3.3 of .
The octet string representing the signature is encoded directly in the BIT STRING without adding any additional ASN.1 wrapping.
For the Certificate structure, the signature value is wrapped in the 'signatureValue' BIT STRING field.
Asymmetric Key Packages describes how encode a private key in a structure that both identifies what algorithm the private key is for, but allows for the public key and additional attributes about the key to be included as well.
For illustration, the ASN.1 structure OneAsymmetricKey is replicated below.
The algorithm specific details of how a private key is encoded is left for the document describing the algorithm itself.
For the keys defined in this document, the private key is always an opaque byte sequence.
The ASN.1 type CurvePrivateKey is defined in this document to hold the byte sequence.
Thus when encoding a OneAsymmetricKey object, the private key is wrapped in an CurvePrivateKey object and wrapped by the OCTET STRING of the 'privateKey' field.
To encode a EdDSA, X25519 or X448 private key, the
"privateKey" field will hold the encoded private key.
The "privateKeyAlgorithm" field uses the AlgorithmIdentifier structure.
The structure is encoded as defined above.
If present, the "publicKey" field will hold the encoded key as defined in and .
public key.
The following is an example of a private key encoded using the textual encoding defined in .For the purpose of consistent cross-implementation naming
this section establishes human readable names for the algorithms
specified in this document. Implementations SHOULD use these
names when referring to the algorithms. If there is a strong
reason to deviate from these names -- for example, if the
implementation has a different naming convention and wants to
maintain internal consistency -- it is encouraged to deviate as
little as possible from the names given here.Use the string "ECDH" when referring to a public key of type X25519 or X448 when the curve is not known or relevant.When the curve is known, use the more specific string of X25519 or X448.Use the string "EdDSA" when referring to a signing public key or
signature when the curve is not known or relevant.When the curve is known, use a more specific
string.
For the id-EdDSA25519 value use the string "Ed25519".
For id-EdDSA448
use "Ed448". For reference purposes, the ASN.1 syntax is presented as an
ASN.1 module here.This section contains illustrations of EdDSA public keys and
certificates, illustrating parameter choices.An example of a Ed25519 public key:An example of a self issued PKIX certificate using Ed25519 to sign a X25519 public key would be:
An example of an Ed25519 private key:
The same item dumped as asn1 yields:
Note that the value of the private key is:
Text and/or inspiration were drawn from , , , , and .The following people discussed the document and provided
feedback: Klaus Hartke, Ilari Liusvaara, Erwann Abalea, Rick
Andrews, Rob Stradling, James Manger, Nikos Mavrogiannopoulos,
Russ Housley, David Benjamin, and Alex Wilson.A big thank you to Symantec for kindly donating the OIDs used
in this draft.None.
The security considerations of , , and apply accordingly.
The procedures for going from a private key to a public key is different for when used with Diffie-Helman and when used with Edwards Signatures.
This means that the same public key cannot be used for both ECDH and EdDSA.
&rfc2119;
&rfc5280;
&rfc5480;
&rfc7748;
&eddsa;
&rfc5958;
&rfc3279;
&rfc4055;
&rfc5639;
&rfc7468;