rfc-xmldiff rfc8410.original.xml rfc8410.xml

<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3279 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3279.xml">
<!ENTITY rfc4055 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4055.xml">
<!ENTITY rfc5280 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY rfc5480 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5480.xml">
<!ENTITY rfc5639 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5639.xml">
<!ENTITY rfc5755 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5755.xml">
<!ENTITY rfc5758 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5758.xml">
<!ENTITY rfc5915 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5915.xml">
<!ENTITY rfc5958 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5958.xml">
<!ENTITY rfc7468 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7468.xml">
<!ENTITY rfc7748 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7748.xml">
<!ENTITY rfc8174 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY eddsa   SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8032.xml">
<!ENTITY iana SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.schaad-curdle-oid-registry.xml">
]>

<?rfc strict="yes" ?>
<?rfc compact="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>

<rfc category="std"
     ipr="trust200902"
     docName="draft-ietf-curdle-pkix-10">
     
  <front>
    
    <title abbrev="Safe curves for X.509">
      <!-- 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
    </title>
    
    <author fullname="Simon Josefsson" initials="S." surname="Josefsson">
      <organization>SJD AB</organization>
      <address>
        <email>simon@josefsson.org</email>
      </address>
    </author>

    <author fullname="Jim Schaad" initials="J" surname="Schaad">
      <organization>August Cellars</organization>
      <address>
        <email>ietf@augustcellars.com</email>
      </address>
    </author>

    <date/>

    <keyword>Elliptic Curve Cryptography, Curve25519, Curve448,
    Goldilocks, X.509, PKIX, PKI, OID, ASN.1, EdDSA,
    Ed25519, Ed448, X25519, X448</keyword>

    <abstract>

      <t>This document specifies algorithm identifiers and ASN.1
      encoding formats for Elliptic Curve constructs using the curve25519 and curve448 curves.
      <!-- Remove ph
           The signature algorithms covered are Ed25519, Ed25519ph, Ed448 and Ed448ph.
           -->
      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.
      </t>

    </abstract>

  </front>

  <middle>

    <section title="Introduction">

      <t>
        In <xref target="RFC7748"/>, 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.
      </t>

      <t>
        <xref target="RFC7748"/> 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 associated parameters.
        The use of these OIDs is described for public and private keys.
      </t>
        

      <t>
        In <xref target="RFC8032"/> 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.
        <!-- Remove pre-hash
             The Ed25519ph and Ed448ph algorithm definitions specify the one-way hash function that is used for pre-hashing.
             The convention used for identifying the algorithm/curve combinations are to use the Ed25519 and Ed448 for the PureEdDSA mode, with Ed25519ph and Ed448ph for the HashEdDSA mode.
             -->
        The convention used for identifying the algorithm/curve combinations is to use "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.
      </t>

      <t>
        <xref target="RFC8032"/> 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:
        <list style="symbols">
          <t>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.</t>
          <t>
            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 to have separate keys and which do not.
            This may result in a decrease of security for those other algorithms.
          </t>
          <t>
            There are still ongoing discussions among the cryptographic community about how effective the use of contexts is for preventing attacks.
          </t>
          <t>
            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 note that a context string needs to be provided.
          </t>
        </list>
      </t>
    </section>

    <section title="Requirements Terminology">

      <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", and "OPTIONAL" in this document are to be interpreted as
      described in BCP 14 <xref target="RFC2119" /> <xref target="RFC8174"/> when, and only when, they
      appear in all capitals, as shown here.
      </t>

    </section>

    <section title="Curve25519 and Curve448 Algorithm Identifiers">

      <t>Certificates conforming to <xref target="RFC5280"/> 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.
      </t>
      
      <t>The AlgorithmIdentifier type, which is included for
      convenience, is defined as follows:</t>

      <figure>
        <artwork><![CDATA[
AlgorithmIdentifier  ::=  SEQUENCE  {
    algorithm   OBJECT IDENTIFIER,
    parameters  ANY DEFINED BY algorithm OPTIONAL
}
]]></artwork>
      </figure>

      <t>The fields in AlgorithmIdentifier have the following
      meanings:</t>

      <t><list style="symbols">
        <t>algorithm identifies the cryptographic algorithm with an
        object identifier.  Four such OIDs are defined below.</t>

    <t>parameters, which are optional, are the associated
    parameters for the algorithm identifier in the algorithm
    field.
    </t>
      </list></t>

      <t>
        <!-- RFC Editor:  I have been told that the following three sentences should be joined together, I tend to think
             that they are correct as separate items but it is something that a copy editor should look at -->
    In this document we define 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. <!--  and EdDSA in pre-hash mode. -->
    For all of the OIDs, the parameters MUST be absent.
      </t>

  <t>
    It is possible to find systems that require the parameters to be present.
    This can be either due to a defect in the original 1997 syntax or a programming error where developers never got input where this was not true.
    The optimal solution is to fix these systems, where this is not possible the problem needs to be restricted to that subsystem and not propigated to the internet.
  </t>
      <t>
        The same algorithm identifiers are used for identifying a public key, identifying a private key and identifying a signature (for the two EdDSA related OIDs).
        Additional encoding information is provided below for each of these locations.
      </t>

      <!--  Remove pre-hash algorithms
        id-Ed25519ph OBJECT IDENTIFIER ::= { 1 3 101 114 }
        id-Ed448ph   OBJECT IDENTIFIER ::= { 1 3 101 115 }
      -->
      
      <figure>
        <artwork><![CDATA[
id-X25519    OBJECT IDENTIFIER ::= { 1 3 101 110 }
id-X448      OBJECT IDENTIFIER ::= { 1 3 101 111 }
id-Ed25519   OBJECT IDENTIFIER ::= { 1 3 101 112 }
id-Ed448     OBJECT IDENTIFIER ::= { 1 3 101 113 }
]]></artwork>
      </figure>

      <!--
      <t>The OID id-Curve25519 refers to Curve25519.  The OID
      id-Curve448 refers to Curve448.  Both curves are described in
      <xref target="RFC7748"/>.  The OIDs id-Curve25519ph and
      id-Curve448ph refers to Curve25519 and Curve448 when used with
      pre-hashing as Ed25519ph and Ed448ph described in <xref
      target="RFC8032"/>.</t>
      
      <t>The public key value encoded into the ECPoint value is the
      raw binary values described in <xref target="RFC7748"/>.</t>
      -->

    </section>

    <section title="Subject Public Key Fields">

      <t>In the X.509 certificate, the subjectPublicKeyInfo field has
      the SubjectPublicKeyInfo type, which has the following ASN.1
      syntax:</t>

      <figure>
        <artwork><![CDATA[
SubjectPublicKeyInfo  ::=  SEQUENCE  {
    algorithm         AlgorithmIdentifier,
    subjectPublicKey  BIT STRING
}
]]></artwork>
      </figure>

      <t>The fields in SubjectPublicKeyInfo have the following meanings:</t>

      <t><list style="symbols">
        <t>algorithm is the algorithm identifier and parameters for
        the public key (see above).</t>

        <t>subjectPublicKey contains the byte stream of the public key.
        The algorithms defined in this document always encode the public key as an exact multiple of 8-bits.
        </t>
      </list></t>

      <t>
        Both <xref target="RFC7748"/> and <xref target="RFC8032"/> 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.
      </t>

      <t>The following is an example of a public key encoded using the  textual encoding defined in  <xref target="RFC7468"/>.</t>

      <figure>
<artwork><![CDATA[
-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEAGb9ECWmEzf6FQbrBZ9w7lshQhqowtrbLDFw4rXAxZuE=
-----END PUBLIC KEY-----      
]]></artwork>
      </figure>
    </section>

    <!--
    <section title="EdDSA Public Keys">

      <t>Certificates conforming to <xref target="RFC5280"/> may
      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.</t>

      <t>This section identify the OID and parameters for the EdDSA
      algorithm.  Conforming CAs MUST use the identified OIDs when
      issuing certificates containing EdDSA public keys.  Conforming
      applications supporting EdDSA MUST, at a minimum, recognize the
      OID identified in this section.</t>

      <t>The id-EdDSAPublicKey OID is used for identifying EdDSA
      public keys.</t>

      <figure>
      <artwork><![CDATA[
       id-EdDSAPublicKey OBJECT IDENTIFIER ::= { 1 3 101 100 }
       ]]></artwork>
      </figure>

      <t>The id-EdDSAPublicKey OID is intended to be used in the
      algorithm field of a value of type AlgorithmIdentifier.</t>

      <t>EdDSA public keys use the parameter field to specify the
      particular instantiation of EdDSA parameters.  The parameters
      field have the ASN.1 type EdDSAParameters as follows.</t>

      <figure>
      <artwork><![CDATA[
      EdDSAParameters ::= ENUMERATED { ed25519   (1),
          ed25519ph (2) }
          ed448     (3) }
          ed448ph   (4) }
]]></artwork>
     </figure>

      <t>The EdDSAParameters enumeration may be extended in the
      future.</t>

      <t>The "ed25519" and "ed448" values correspond to the PureEdDSA
      variants, and the "ed25519ph" and "ed448ph" values correspond to
      the HashEdDSA variants, as discussed in <xref
      target="RFC8032"/>.</t>

      <t>The raw binary EdDSA public key is encoded directly in the
      subjectPublicKey BIT STRING object.  Note that unlike some other
      schemes, there is no additional OCTET STRING encoding step.</t>

</section>
-->
    
    <section title="Key Usage Bits">
      
      <t>The intended application for the key is indicated in the
      keyUsage certificate extension.</t>

      <t>
        If the keyUsage extension is present in a certificate that indicates
        id-X25519 or id-X448 in SubjectPublicKeyInfo, then the following MUST
        be present:
      </t>

      <figure><artwork>
        keyAgreement;
      </artwork></figure>

      <t>
        one of the following MAY also be present:
      </t>

      <t>
        <figure><artwork>
          encipherOnly; or
          decipherOnly.
          </artwork>
        </figure>
      </t>

      <t>
        If the keyUsage extension is present in an end-entity
        <!-- Remove pre-hash
      certificate that indicates id-EdDSA25519, id-EdDSA25519ph, id-EdDSA448 or id-EdDSA448ph
        -->
      certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage extension
      MUST contain one or both of the following values:</t>

      <figure>
        <artwork><![CDATA[
        nonRepudiation; and
        digitalSignature.
]]></artwork>
      </figure>

      <t>If the keyUsage extension is present in a certification
      authority certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage extension
      MUST contain one or more of the following values:</t>

      <figure>
<artwork><![CDATA[
       nonRepudiation;
       digitalSignature;
       keyCertSign; and
       cRLSign.
       ]]></artwork>
      </figure>

        <!-- Remove pre-hash
        <t>
        CAs MUST NOT use the pre-hash versions of the EdDSA algorithms for the creation of certificates or CRLs.
        This is implied by the fact that those algorithms are not listed in the previous paragraph.
        Additionally OCSP responders SHOULD NOT use the pre-hash versions of the EdDSA algorithms when generating OCSP responses.
        No restriction is placed on generation of OCSP requests.
        </t>


      <t>
        AAs MUST NOT use the pre-hash versions of the EdDSA algorithms for the creation of attribute certificates or attribute CRLs <xref target="RFC5755"/>.
      </t>

      <t>
        The decision to require the use of pure mode balances the higher security of having a single failure point against the possibility that constrained devices, such as Hardware Security Modules (HSMs), may be unable to check signatures on CRLs due to the amount of memory required to hold the entire CRL in memory at one time.
        This concern can be addressed by CAs using CRL distribution points, combined with segmenting the certificates issued so that the length of any segmented CRL is not "too long" even if a large percentage of the certificates are revoked.
        The definition of "too long" is going to be highly dependent on what constrained device is being used, it can be on the order of single or low double digit kilobytes.
      </t>
        -->
        

    </section>

    <section title="EdDSA Signatures">

      <t>
        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.
      </t>


      <figure>
<artwork><![CDATA[
   Certificate  ::=  SEQUENCE  {
        tbsCertificate       TBSCertificate,
        signatureAlgorithm   AlgorithmIdentifier,
        signatureValue       BIT STRING  }
]]></artwork>
      </figure>

      <t>
        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.
      </t>

      <t>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 <xref target="RFC8032"/>.
      
      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.
      </t>

      <!-- Remove Prehash
      <t>
        When the pre-hash versions of the EdDSA signature algorithms are used, the hash function used for the pre-hash is defined by the algorithm.
        This means that the pre-hash function is implicitly included in the algorithm identifier rather than being explicit as done in <xref target="RFC3279"/>.
        </t>
        -->

      
    </section>

    <section title="Private Key Format">

      <t>
        <xref target="RFC5958">Asymmetric Key Packages</xref> describes how to 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.
      </t>
      
      <figure>
        <artwork><![CDATA[
OneAsymmetricKey ::= SEQUENCE {
   version Version,
   privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
   privateKey PrivateKey,
   attributes [0] IMPLICIT Attributes OPTIONAL,
   ...,
   [[2: publicKey [1] IMPLICIT PublicKey OPTIONAL ]],
   ...
}

PrivateKey ::= OCTET STRING

PublicKey ::= BIT STRING
]]></artwork>
      </figure>

      <t>
        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.
      </t>

      <figure>
      <artwork><![CDATA[
CurvePrivateKey ::= OCTET STRING
]]></artwork>
      </figure>
      
      <t>
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 <xref target="RFC7748"/> and <xref target="RFC8032"/>.
      </t>

      <t>The following is an example of a private key encoded using the textual encoding defined in  <xref target="RFC7468"/>.</t>

      <figure>
<artwork><![CDATA[
-----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC
-----END PRIVATE KEY-----
]]></artwork>
      </figure>

      <t>
        The following example, in addition to encoding the private key, additionally has an attribute included as well as the public key.
        As with the prior example, the textual  encoding defined in <xref target="RFC7468"/> is used.
      </t>
      <figure>
        <artwork><![CDATA[
-----BEGIN PRIVATE KEY-----
MHICAQEwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC
oB8wHQYKKoZIhvcNAQkJFDEPDA1DdXJkbGUgQ2hhaXJzgSEAGb9ECWmEzf6FQbrB
Z9w7lshQhqowtrbLDFw4rXAxZuE=
-----END PRIVATE KEY------]]></artwork>
      </figure>

      <t>
        NOTE: There exist some private key import functions that have not picked up the new ASN.1 structure OneAsymmetricKey that is defined in <xref target="RFC7748"/>.
        This means that they will not accept a private key structure which contains the public key field.
        This means a balancing act needs to be done between being able to do a consistency check on the key pair and widest ability to import the key.
      </t>
    </section>

    <section title="Human Readable Algorithm Names">

      <t>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.</t>

      <t>Use the string "ECDH" when referring to a public key of type "X25519" or "X448" when the curve is not known or relevant.</t>

      <t>When the curve is known, use the more specific string of "X25519" or "X448".</t>
      
      
      <t>Use the string "EdDSA" when referring to a signing public key or
      signature when the curve is not known or relevant.</t>

      <t>When the curve is known, use a more specific
      string. 
      For the id-Ed25519 value use the string "Ed25519".
      <!-- Remove pre-hash
      For
      the id-EdDSA25519ph value use the string "Ed25519ph".  --> For id-Ed448
      use "Ed448".  <!-- Remvoe prehash For id-EdDSA448ph use "Ed448ph".--></t>
      
    </section>

    <section title="ASN.1 Module" anchor="module">

      <t>For reference purposes, the ASN.1 syntax is presented as an
      ASN.1 module here.</t>

      <figure>
<artwork><![CDATA[
-- ASN.1 Module

Safecurves-pkix-0 -- TBD - IANA assigned module OID

DEFINITIONS EXPLICIT TAGS ::=
BEGIN

IMPORTS
  SIGNATURE-ALGORITHM, KEY-AGREE, PUBLIC-KEY, KEY-WRAP,
  KeyUsage, AlgorithmIdentifier
  FROM AlgorithmInformation-2009 
    {iso(1) identified-organization(3) dod(6) internet(1) security(5)
    mechanisms(5) pkix(7) id-mod(0)
    id-mod-algorithmInformation-02(58)}

  mda-sha512
  FROM PKIX1-PSS-OAEP-Algorithms-2009
    { iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-pkix1-rsa-pkalgs-02(54) }

  kwa-aes128-wrap, kwa-aes256-wrap
  FROM CMSAesRsaesOaep-2009
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
      smime(16) modules(0) id-mod-cms-aes-02(38) }
  ;
    

id-edwards-curve-algs OBJECT IDENTIFIER ::= { 1 3 101 }

id-X25519        OBJECT IDENTIFIER ::= { id-edwards-curve-algs 110 }
id-X448          OBJECT IDENTIFIER ::= { id-edwards-curve-algs 111 }
id-Ed25519       OBJECT IDENTIFIER ::= { id-edwards-curve-algs 112 }
id-Ed448         OBJECT IDENTIFIER ::= { id-edwards-curve-algs 113 }


 sa-Ed25519 SIGNATURE-ALGORITHM ::= {
    IDENTIFIER id-Ed25519
     PARAMS ARE absent
     PUBLIC-KEYS {pk-Ed25519}
     SMIME-CAPS { IDENTIFIED BY id-Ed25519 }
 }

 pk-Ed25519 PUBLIC-KEY ::= {
     IDENTIFIER id-Ed25519
     -- KEY no ASN.1 wrapping --
     PARAMS ARE absent
     CERT-KEY-USAGE {digitalSignature, nonRepudiation,
                     keyCertSign, cRLSign}
     PRIVATE-KEY CurvePrivateKey
 }

 kaa-X25519 KEY-AGREE ::= {
     IDENTIFIER id-X25519
     PARAMS ARE absent
     PUBLIC-KEYS {pk-X25519}
     UKM -- TYPE no ASN.1 wrapping -- ARE preferredPresent
     SMIME-CAPS {
        TYPE AlgorithmIdentifier{KEY-WRAP, {KeyWrapAlgorithms}}
        IDENTIFIED BY id-X25519 }
 }

 pk-X25519 PUBLIC-KEY ::= {
     IDENTIFIER id-X25519
     -- KEY no ASN.1 wrapping --
     PARAMS ARE absent
     CERT-KEY-USAGE { keyAgreement }
     PRIVATE-KEY CurvePrivateKey
 }

 KeyWrapAlgorithms KEY-WRAP ::= {
     kwa-aes128-wrap | kwa-aes256-wrap,
     ...
 }
     
 kaa-X448 KEY-AGREE ::= {
     IDENTIFIER id-X448
     PARAMS ARE absent
     PUBLIC-KEYS {pk-X448}
     UKM -- TYPE no ASN.1 wrapping  -- ARE preferredPresent
     SMIME-CAPS {
        TYPE AlgorithmIdentifier{KEY-WRAP, {KeyWrapAlgorithms}}
        IDENTIFIED BY id-X448 }
 }

 pk-X448 PUBLIC-KEY ::= {
     IDENTIFIER id-X448
     -- KEY no ASN.1 wrapping --
     PARAMS ARE absent
     CERT-KEY-USAGE { keyAgreement }
     PRIVATE-KEY CurvePrivateKey
 }

CurvePrivateKey ::= OCTET STRING
    
                                 
END
]]></artwork>
      </figure>

    </section>

    <section title="Examples">

      <t>This section contains illustrations of EdDSA public keys and
      certificates, illustrating parameter choices.</t>


      <section title="Example Ed25519 Public Key">

<t>An example of a Ed25519 public key:</t>

<figure>
  <artwork><![CDATA[
      Public Key Information:
          Public Key Algorithm: Ed25519
          Algorithm Security Level: High

      Public Key Usage:
      
      Public Key ID: 9b1f5eeded043385e4f7bc623c5975b90bc8bb3b
      
      -----BEGIN PUBLIC KEY-----
      MCowBQYDK2VwAyEAGb9ECWmEzf6FQbrBZ9w7lshQhqowtrbLDFw4rXAxZuE=
      -----END PUBLIC KEY-----
]]></artwork>
</figure>
      
      </section>

      <section title="Example X25519 Certificate">

<t>An example of a self issued PKIX certificate using Ed25519 to sign a X25519 public key would be:</t>

<figure>
  <artwork><![CDATA[
  0 300: SEQUENCE {
  4 223:   SEQUENCE {
  7   3:     [0] {
  9   1:       INTEGER 2
       :       }
 12   8:     INTEGER 56 01 47 4A 2A 8D C3 30
 22   5:     SEQUENCE {
 24   3:       OBJECT IDENTIFIER
       :         Ed 25519 signature algorithm { 1 3 101 112 }
       :       }
 29  25:     SEQUENCE {
 31  23:       SET {
 33  21:         SEQUENCE {
 35   3:           OBJECT IDENTIFIER commonName (2 5 4 3)
 40  14:           UTF8String 'IETF Test Demo'
       :           }
       :         }
       :       }
 56  30:     SEQUENCE {
 58  13:       UTCTime 01/08/2016 12:19:24 GMT
 73  13:       UTCTime 31/12/2040 23:59:59 GMT
       :       }
 88  25:     SEQUENCE {
 90  23:       SET {
 92  21:         SEQUENCE {
 94   3:           OBJECT IDENTIFIER commonName (2 5 4 3)
 99  14:           UTF8String 'IETF Test Demo'
       :           }
       :         }
       :       }
115  42:     SEQUENCE {
117   5:       SEQUENCE {
119   3:         OBJECT IDENTIFIER
       :           ECDH 25519 key agreement { 1 3 101 110 }
       :         }
124  33:       BIT STRING
       :         85 20 F0 09 89 30 A7 54 74 8B 7D DC B4 3E F7 5A
       :         0D BF 3A 0D 26 38 1A F4 EB A4 A9 8E AA 9B 4E 6A
       :       }
159  69:     [3] {
161  67:       SEQUENCE {
163  15:         SEQUENCE {
165   3:           OBJECT IDENTIFIER basicConstraints (2 5 29 19)
170   1:           BOOLEAN TRUE
173   5:           OCTET STRING, encapsulates {
175   3:             SEQUENCE {
177   1:               BOOLEAN FALSE
       :               }
       :             }
       :           }
180  14:         SEQUENCE {
182   3:           OBJECT IDENTIFIER keyUsage (2 5 29 15)
187   1:           BOOLEAN FALSE
190   4:           OCTET STRING, encapsulates {
192   2:             BIT STRING 3 unused bits
       :               '10000'B (bit 4)
       :             }
       :           }
196  32:         SEQUENCE {
198   3:           OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14)
203   1:           BOOLEAN FALSE
206  22:           OCTET STRING, encapsulates {
208  20:             OCTET STRING
       :               9B 1F 5E ED ED 04 33 85 E4 F7 BC 62 3C 59 75
       :               B9 0B C8 BB 3B
       :             }
       :           }
       :         }
       :       }
       :     }
230   5:   SEQUENCE {
232   3:     OBJECT IDENTIFIER
       :       Ed 25519 signature algorithm { 1 3 101 112 }
       :     }
237  65:   BIT STRING
       :     AF 23 01 FE DD C9 E6 FF C1 CC A7 3D 74 D6 48 A4
       :     39 80 82 CD DB 69 B1 4E 4D 06 EC F8 1A 25 CE 50
       :     D4 C2 C3 EB 74 6C 4E DD 83 46 85 6E C8 6F 3D CE
       :     1A 18 65 C5 7A C2 7B 50 A0 C3 50 07 F5 E7 D9 07
       :   }
      
-----BEGIN CERTIFICATE-----
MIIBLDCB36ADAgECAghWAUdKKo3DMDAFBgMrZXAwGTEXMBUGA1UEAwwOSUVURiBUZX
N0IERlbW8wHhcNMTYwODAxMTIxOTI0WhcNNDAxMjMxMjM1OTU5WjAZMRcwFQYDVQQD
DA5JRVRGIFRlc3QgRGVtbzAqMAUGAytlbgMhAIUg8AmJMKdUdIt93LQ+91oNvzoNJj
ga9OukqY6qm05qo0UwQzAPBgNVHRMBAf8EBTADAQEAMA4GA1UdDwEBAAQEAwIDCDAg
BgNVHQ4BAQAEFgQUmx9e7e0EM4Xk97xiPFl1uQvIuzswBQYDK2VwA0EAryMB/t3J5v
/BzKc9dNZIpDmAgs3babFOTQbs+BolzlDUwsPrdGxO3YNGhW7Ibz3OGhhlxXrCe1Cg
w1AH9efZBw==
-----END CERTIFICATE-----
]]></artwork>
</figure>

      </section>

      <section title="Examples of Ed25519 Private Key">
        <t>
          An example of an Ed25519 private key without the public key:
        </t>
    
      <figure>
<artwork><![CDATA[
-----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC
-----END PRIVATE KEY-----
]]></artwork>
      </figure>

      <t>The same item dumped as ASN.1 yields:
      </t>

      <figure><artwork>
 0 30   46: SEQUENCE {
 2 02    1:   INTEGER 0
 5 30    5:   SEQUENCE {
 7 06    3:     OBJECT IDENTIFIER
          :       Ed 25519 signature algorithm { 1 3 101 112 }
          :     }
12 04   34:   OCTET STRING
          :     04 20 D4 EE 72 DB F9 13 58 4A D5 B6 D8 F1 F7 69
          :     F8 AD 3A FE 7C 28 CB F1 D4 FB E0 97 A8 8F 44 75
          :     58 42
          :   }
          </artwork>
      </figure>

      <t>
        Note that the value of the private key is:
      </t>

      <figure><artwork>
D4 EE 72 DB F9 13 58 4A D5 B6 D8 F1 F7 69 F8 AD
3A FE 7C 28 CB F1 D4 FB E0 97 A8 8F 44 75 58 42
</artwork></figure>


        <t>
          An example of the same Ed25519 private key encoded with an attribute and the public key:
        </t>
    
      <figure>
<artwork><![CDATA[
-----BEGIN PRIVATE KEY-----
MHICAQEwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC
oB8wHQYKKoZIhvcNAQkJFDEPDA1DdXJkbGUgQ2hhaXJzgSEAGb9ECWmEzf6FQbrB
Z9w7lshQhqowtrbLDFw4rXAxZuE=
-----END PRIVATE KEY-----
]]></artwork>
      </figure>

      <t>The same item dumped as ASN.1 yields:
      </t>

      <figure><artwork>
  0 114: SEQUENCE {
  2   1:   INTEGER 1
  5   5:   SEQUENCE {
  7   3:     OBJECT IDENTIFIER '1 3 101 112'
       :     }
 12  34:   OCTET STRING, encapsulates {
       :     04 20 D4 EE 72 DB F9 13 58 4A D5 B6 D8 F1 F7 69
       :     F8 AD 3A FE 7C 28 CB F1 D4 FB E0 97 A8 8F 44 75
       :     58 42
       :     }
 48  31:   [0] {
 50  29:     SEQUENCE {
 52  10:       OBJECT IDENTIFIER '1 2 840 113549 1 9 9 20'
 64  15:       SET {
 66  13:         UTF8String 'Curdle Chairs'
       :         }
       :       }
       :     }
81  33:   [1] 00 19 BF 44 09 69 84 CD FE 85 41 BA C1 67 DC 3B
              96 C8 50 86 AA 30 B6 B6 CB 0C 5C 38 AD 70 31 66
              E1
       :   }
          </artwork>
      </figure>

    </section>
  </section>
  
    <section anchor="ack"
             title="Acknowledgments">

      <t>Text and/or inspiration were drawn from <xref
      target="RFC5280"/>, <xref target="RFC3279"/>, <xref
      target="RFC4055"/>, <xref target="RFC5480"/>, and <xref
      target="RFC5639"/>.</t>

      <t>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, Brian Smith, and Alex Wilson.</t>

      <t>A big thank you to Symantec for kindly donating the OIDs used
      in this draft.</t>
      
    </section>

    <section title="IANA Considerations">

      <t>
        IANA is requested to assign a module OID from the "SMI for PKIX Module Identifier" registry for the ASN.1 module in <xref target="module"/>.
      </t>

      <t>
	The OIDs are being independently registered in the IANA registry "SMI Security for Cryptographic Algorithms" in  <xref target="I-D.schaad-curdle-oid-registry"/>.
      </t>

    </section>

    <section anchor="Security" title="Security Considerations">

      <t>
        The security considerations of <xref target='RFC5280' />, <xref target="RFC7748"/>, and <xref target="RFC8032"/> apply accordingly.
      </t>

      <t>
        The procedures for going from a private key to a public key are different for when used with Diffie-Hellman and when used with Edwards Signatures.
        This means that the same public key cannot be used for both ECDH and EdDSA.
      </t>

      <!--
      <t>
        In the original design of Ed25519 signatures, there was a known attack between the pure and the pre-hash version of the signatures.
        This has since been corrected in the final version of the design.
        The initial problem meant that there was a known attack, and therefore a known reason to forbid the use of Ed25519 keys with the Ed25519ph signature scheme and visa versa.
        With the change in the design this attack has been prevented.
        This does not mean that the same Ed25519 key should be used with both schemes, there still may be attacks where collisions can be found.
        For this reason, the same keys are not to be used for the pure and pre-hash versions of the scheme.
        This applies to both curve 25519 and curve 448.
        </t>
        -->

    </section>

  </middle>

  <back>

    <references title="Normative References">

      &rfc2119;
      &rfc5280;
      &rfc5480;
      &rfc7748;
      &eddsa;
      &rfc5958;
      &rfc8174;

    </references>

    <references title="Informative References">

      &rfc3279;
      &rfc4055;
      &rfc5639;
      <!-- Remove for pre-hash
           &rfc5755;
           -->
<!--      &rfc5758; -->
<!--      &rfc5915; -->
&rfc7468;
&iana;

    </references>

    <section title="Invalid Encodings">
      <t>
        There are a number of things that need to be dealt with when a new key part is decoded and imported into the system.
        A partial list of these includes:
        <list style="symbols">
          <t>
            ASN.1 encoding errors:
            Two items are highlighted here.
            First, the use of an OCTET STRING rather than a BIT STRING for the public key.
            This was an incorrect copy of the structure from <xref target="RFC5958"/> which was corrected before publication.
            However, any early implementation may have this wrong.
            Second, the value of the version field is required to be 0 if the publicKey is absent and 1 if present.
            This is called out in <xref target="RFC5958"/> but is not duplicated in the main text.
          </t>
          <t>
            Key encoding errors:
            Both <xref target="RFC7748"/> and <xref target="RFC8032"/> have formatting requirements for keys that need to be enforced.
            In some cases the enforcement is done at the time of importing, for example doing masking or a mod p operation.
            In other cases the enforcement is done by rejecting the keys and having an import failure.
          </t>
          <t>
            Key mismatch errors: If a public key is provided, it may not agree with the private key either because it is wrong or the wrong algorithm was used.
          </t>
        </list>
      </t>

      <t>
        Some systems are also going to be stricter on what they accept.
        As stated in <xref target="RFC5958"/>, BER decoding of OneAsymmetricKey objects is a requirement for compliance.
        Despite this requirement, some acceptors will only decode DER formats.
        The following is a BER encoding of a private key, as such is is valid, but it may not be accepted by many systems.
      </t>

      <figure><artwork>
-----BEGIN PRIVATE KEY-----
MIACAQAwgAYDK2VwAAAEIgQg1O5y2/kTWErVttjx92n4rTr+fCjL8dT74Jeoj0R1W
EIAAA==
-----END PRIVATE KEY-----      
      </artwork></figure>



      <t>
        What follows here is a brief sampling of some incorrect keys.
      </t>

      <t>
        In the following example, the private key does not match the masking requirements for X25519.
        For this example the top bits are set to zero and the bottom three bits are set to 001.
      </t>

      <figure><artwork>
-----BEGIN PRIVATE KEY-----
MFMCAQEwBQYDK2VuBCIEIPj///////////////////////////////////////8/oS
MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg==
-----END PRIVATE KEY-----
      </artwork></figure>

      <t>
        In the following examples, the key is the wrong length because an all zero byte has been removed.
        In one case the first byte has been removed, in the other case the last byte has been removed.
      </t>

      <figure><artwork>
-----BEGIN PRIVATE KEY-----
MFICAQEwBQYDK2VwBCIEIC3GfeUYbZGTAhwLEE2cbvJL7ivTlcy17VottfN6L8HwoS
IDIADBfk2Lv/J8H7YYwj/OmIcDx++jzVkKrKwS0/HjyQyM
-----END PRIVATE KEY-----
      </artwork></figure>

      <figure><artwork>
-----BEGIN PRIVATE KEY-----
MFICAQEwBQYDK2VwBCIEILJXn1VaLqvausjUaZexwI/ozmOFjfEk78KcYN+7hsNJoS
IDIACdQhJwzi/MCGcsQeQnIUh2JFybDxSrZxuLudJmpJLk
-----END PRIVATE KEY-----
      </artwork></figure>


    </section>
  </back>
</rfc>

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc strict="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc compact="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<rfc category="std" ipr="trust200902" docName="draft-ietf-curdle-pkix-10" obsoletes="" updates="" submissionType="IETF" {http://www.w3.org/XML/1998/namespace}lang="en" consensus="yes" number="8410">
- <front>
  - <title abbrev="Safe curves for X.509" abbrev="Safe Curves for X.509">
    - <-- 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
    - Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure
    - </title>
  - <author fullname="Simon Josefsson" initials="S." surname="Josefsson">
    - <organization>
      - SJD AB
      - </organization>
    - <address>
      - <email>
        
        simon@josefsson.org
        
        </email>
      - </address>
    - </author>
  - <author fullname="Jim Schaad" initials="J" surname="Schaad">
    - <organization>
      - August Cellars
      - </organization>
    - <address>
      - <email>
        
        ietf@augustcellars.com
        
        </email>
      - </address>
    - </author>
  - <date month="July" year="2018"/>
  - <keyword>
    - Elliptic Curve Cryptography, Curve25519, Curve448, Goldilocks, X.509, PKIX, PKI, OID, ASN.1, EdDSA, Ed25519, Ed448, X25519, X448
    - </keyword>
  - <abstract>
    - <t>
      - This document specifies algorithm identifiers and ASN.1 encoding formats for Elliptic Curve constructs using the curve25519 and curve448 curves.
      - <--  Remove ph
                   The signature algorithms covered are Ed25519, Ed25519ph, Ed448 and Ed448ph.
                    -->
      - 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.
      - 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 and Ed448. The key agreement algorithms covered are X25519 and X448. The encoding for public key, private key, and Edwards-curve Digital Signature Algorithm (EdDSA) structures is provided.
      - </t>
    - </abstract>
  - </front>
- <middle>
  - <section title="Introduction" numbered="true" toc="default">
    - <t>
      - In <xref target="RFC7748" format="default" pageno="false"/>, 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 Sdigital signature operations. , 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. digital signature operations.
      - </t>
    - <t>
      - <xref target="RFC7748" format="default" pageno="false"/> 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 associated parameters. The use of these OIDs is described for public and private keys. 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 associated parameters. The use of these OIDs is described for public and private keys.
      - </t>
    - <t>
      - In <xref target="RFC8032" format="default" pageno="false"/> 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 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.
      - <--  Remove pre-hash
                     The Ed25519ph and Ed448ph algorithm definitions specify the one-way hash function that is used for pre-hashing.
                     The convention used for identifying the algorithm/curve combinations are to use the Ed25519 and Ed448 for the PureEdDSA mode, with Ed25519ph and Ed448ph for the HashEdDSA mode.
                      -->
      - The convention used for identifying the algorithm/curve combinations is to use "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.
      - In <xref target="RFC8032" format="default" pageno="false"/> 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 prehashing and the HashEdDSA mode with prehashing. The convention used for identifying the algorithm/curve combinations is to use "Ed25519" and "Ed448" for the PureEdDSA mode. This document does not provide the conventions needed for the prehash versions of the signature algorithm. The use of the OIDs is described for public keys, private keys and signatures. 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 prehashing and the HashEdDSA mode with prehashing. The convention used for identifying the algorithm/curve combinations is to use "Ed25519" and "Ed448" for the PureEdDSA mode. This document does not provide the conventions needed for the prehash versions of the signature algorithm. The use of the OIDs is described for public keys, private keys and signatures.
      - </t>
    - <t>
      - <xref target="RFC8032" format="default" pageno="false"/> additionally defineds 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: additionally defineds 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:
      - <list style="symbols">
        
        <t>
        
        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.
        
        </t>
        
        <t>
        
        The EdDSA algorithms areis the only IETF algorithms that currently support that currently supports the use of contexts; however, howethere is a possibility that there will be confusion between which algorithms need to haver there is a possibility that there will be confusion between which separate keys and which do not. This may result in a decrease of security for those other algorithms need to have separate keys and which do not. This may result in a decrease of security for those other algorithms.
        
        </t>
        
        <t>
        
        There are still ongoing discussions among the cryptographic community about how effective the use of contexts is for preventing attacks.
        
        </t>
        
        <t>
        
        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 note that a context string needs to be provided.
        
        </t>
        
        </list>
      - </t>
    - </section>
  - <section title="Requirements Terminology" numbered="true" toc="default">
    - <t>
      - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119" format="default" pageno="false"/> <xref target="RFC8174" format="default" pageno="false"/> when, and only when, they appear in all capitals, as shown here. when, and only when, they appear in all capitals, as shown here.
      - </t>
    - </section>
  - <section title="Curve25519 and Curve448 Algorithm Identifiers" numbered="true" toc="default">
    - <t>
      - Certificates conforming to <xref target="RFC5280" format="default" pageno="false"/> can convey a public key for any public key algorithm. The certificate indicates the algorithm through an algorithm identifier. This algorithm identifier isAn algorithm identifier consists of an OID and optionally associated parameters. can convey a public key for any public key algorithm. The certificate indicates the algorithm through an algorithm identifier. This algorithm identifier isAn algorithm identifier consists of an OID and optionally associated parameters. parameters.
      - </t>
    - <t>
      - The AlgorithmIdentifier type, which is included for convenience, is defined as follows:
      - </t>
    - <figure title="" suppress-title="false" align="left" alt="" width="" height="">
      - <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">
        
        AlgorithmIdentifier  ::=  SEQUENCE  {
            algorithm   OBJECT IDENTIFIER,
            parameters  ANY DEFINED BY algorithm OPTIONAL
        }
        
        </artwork>
      - </figure>
    - <t>
      - The fields in AlgorithmIdentifier have the following meanings:
      - </t>
    - <t>
      - <list style="symbols">
        
        <t>
        
        algorithm identifies the cryptographic algorithm with an object identifier. Four such OIDs are defined below.
        
        </t>
        
        <t>
        
        parameters, which are optional, are the associated parameters for the algorithm identifier in the algorithm field.
        
        </t>
        
        </list>
      - </t>
    - <t>
      - <-- RFC Editor: I have been told that the following three sentences should be joined together, I tend to think
        that they are correct as separate items but it is something that a copy editor should look at -->
      - In this document we define 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.
      - <-- and EdDSA in pre-hash mode. -->
      - For all of the OIDs, the parameters MUST be absent.
      - In this document, we define four new OIDs for identifying the different curve/algorithm pairs: the curves being curve25519 and curve448 and the algorithms being ECDH and EdDSA in pure mode. For all of the OIDs, the parameters MUST be absent.
      - </t>
    - <t>
      - It is possible to find systems that require the parameters to be present. This can be either due todue to either a defect in the original 1997 syntax or a programming error where developers never got input where this was not true. The optimal solution is to fix these systems; where this is not possible, where this is not possible the problem needs to be restricted to that subsystem and not propigated to the iagated to the Internet.
      - </t>
    - <t>
      - The same algorithm identifiers are used for identifying a public key, identifa private keying a private key and identifying, and a signature (for the two EdDSA related OIDs). Additional encoding information is provided below for each of these locations.
      - </t>
    - <--   Remove pre-hash algorithms
              id-Ed25519ph OBJECT IDENTIFIER ::= { 1 3 101 114 }
              id-Ed448ph   OBJECT IDENTIFIER ::= { 1 3 101 115 }
             -->
    - <figure title="" suppress-title="false" align="left" alt="" width="" height="">
      - <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">
        
        id-X25519    OBJECT IDENTIFIER ::= { 1 3 101 110 }
        id-X448      OBJECT IDENTIFIER ::= { 1 3 101 111 }
        id-Ed25519   OBJECT IDENTIFIER ::= { 1 3 101 112 }
        id-Ed448     OBJECT IDENTIFIER ::= { 1 3 101 113 }
        
        </artwork>
      - </figure>
    - <--
            <t>The OID id-Curve25519 refers to Curve25519.  The OID
            id-Curve448 refers to Curve448.  Both curves are described in
            <xref target="RFC7748"/>.  The OIDs id-Curve25519ph and
            id-Curve448ph refers to Curve25519 and Curve448 when used with
            pre-hashing as Ed25519ph and Ed448ph described in <xref
            target="RFC8032"/>.</t>
      
            <t>The public key value encoded into the ECPoint value is the
            raw binary values described in <xref target="RFC7748"/>.</t>
             -->
    - </section>
  - <section title="Subject Public Key Fields" numbered="true" toc="default">
    - <t>
      - In the X.509 certificate, the subjectPublicKeyInfo field has the SubjectPublicKeyInfo type, which has the following ASN.1 syntax:
      - </t>
    - <figure title="" suppress-title="false" align="left" alt="" width="" height="">
      - <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">
        
        SubjectPublicKeyInfo  ::=  SEQUENCE  {
            algorithm         AlgorithmIdentifier,
            subjectPublicKey  BIT STRING
        }
        
        </artwork>
      - </figure>
    - <t>
      - The fields in SubjectPublicKeyInfo have the following meanings:
      - </t>
    - <t>
      - <list style="symbols">
        
        <t>
        
        algorithm is the algorithm identifier and parameters for the public key (see above).
        
        </t>
        
        <t>
        
        subjectPublicKey contains the byte stream of the public key. The algorithms defined in this document always encode the public key as an exact multiple of 8- bits.
        
        </t>
        
        </list>
      - </t>
    - <t>
      - Both <xref target="RFC7748" format="default" pageno="false"/> and and <xref target="RFC8032" format="default" pageno="false"/> 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, thus the same private key will not produce the same public key. 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, thus the same private key will not produce the same public key.
      - </t>
    - <t>
      - The following is an example of a public key encoded using the textual encoding defined in <xref target="RFC7468" format="default" pageno="false"/>..
      - </t>
    - <figure title="" suppress-title="false" align="left" alt="" width="" height="">
      - <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">
        
        -----BEGIN PUBLIC KEY-----
        MCowBQYDK2VwAyEAGb9ECWmEzf6FQbrBZ9w7lshQhqowtrbLDFw4rXAxZuE=
        -----END PUBLIC KEY-----
        
        </artwork>
      - </figure>
    - </section>
  - <--
        <section title="EdDSA Public Keys">
    
          <t>Certificates conforming to <xref target="RFC5280"/> may
          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.</t>
    
          <t>This section identify the OID and parameters for the EdDSA
          algorithm.  Conforming CAs MUST use the identified OIDs when
          issuing certificates containing EdDSA public keys.  Conforming
          applications supporting EdDSA MUST, at a minimum, recognize the
          OID identified in this section.</t>
    
          <t>The id-EdDSAPublicKey OID is used for identifying EdDSA
          public keys.</t>
    
          <figure>
          <artwork><![CDATA[
           id-EdDSAPublicKey OBJECT IDENTIFIER ::= { 1 3 101 100 }
           ]]></artwork>
          </figure>
    
          <t>The id-EdDSAPublicKey OID is intended to be used in the
          algorithm field of a value of type AlgorithmIdentifier.</t>
    
          <t>EdDSA public keys use the parameter field to specify the
          particular instantiation of EdDSA parameters.  The parameters
          field have the ASN.1 type EdDSAParameters as follows.</t>
    
          <figure>
          <artwork><![CDATA[
          EdDSAParameters ::= ENUMERATED { ed25519   (1),
              ed25519ph (2) }
              ed448     (3) }
              ed448ph   (4) }
    ]]></artwork>
         </figure>
    
          <t>The EdDSAParameters enumeration may be extended in the
          future.</t>
    
          <t>The "ed25519" and "ed448" values correspond to the PureEdDSA
          variants, and the "ed25519ph" and "ed448ph" values correspond to
          the HashEdDSA variants, as discussed in <xref
          target="RFC8032"/>.</t>
    
          <t>The raw binary EdDSA public key is encoded directly in the
          subjectPublicKey BIT STRING object.  Note that unlike some other
          schemes, there is no additional OCTET STRING encoding step.</t>
    
    </section>
    -->
  - <section title="Key Usage Bits" numbered="true" toc="default">
    - <t>
      - The intended application for the key is indicated in the keyUsage certificate extension.
      - </t>
    - <t>
      - If the keyUsage extension is present in a certificate that indicates id-X25519 or id-X448 in SubjectPublicKeyInfo, then the following MUST be present:
      - </t>
    - <figure title="" suppress-title="false" align="left" alt="" width="" height="">
      - <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">
        
        keyAgreement;
        
        </artwork>
      - </figure>
    - <t>
      - one of the following MAY also be present:
      - </t>
    - <t>
      - <figure title="" suppress-title="false" align="left" alt="" width="" height="">
        
        <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">
        
                  encipherOnly; or
                  decipherOnly.
        
        
        </artwork>
        
        </figure>
      - </t>
    - <t>
      - If the keyUsage extension is present in an end-entity
      - <--  Remove pre-hash
              certificate that indicates id-EdDSA25519, id-EdDSA25519ph, id-EdDSA448 or id-EdDSA448ph
                 -->
      - If the keyUsage extension is present in an end-entity certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage extension MUST contain one or both of the following values:
      - </t>
    - <figure title="" suppress-title="false" align="left" alt="" width="" height="">
      - <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">
        
        nonRepudiation; and
        digitalSignature.
        
        </artwork>
      - </figure>
    - <t>
      - If the keyUsage extension is present in a certification authority certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage extension MUST contain one or more of the following values:
      - </t>
    - <figure title="" suppress-title="false" align="left" alt="" width="" height="">
      - <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">
        
               nonRepudiation;
               digitalSignature;
               keyCertSign; and
               cRLSign.
        
        
        </artwork>
      - </figure>
    - <--  Remove pre-hash
              <t>
              CAs MUST NOT use the pre-hash versions of the EdDSA algorithms for the creation of certificates or CRLs.
              This is implied by the fact that those algorithms are not listed in the previous paragraph.
              Additionally OCSP responders SHOULD NOT use the pre-hash versions of the EdDSA algorithms when generating OCSP responses.
              No restriction is placed on generation of OCSP requests.
              </t>
      
            <t>
              AAs MUST NOT use the pre-hash versions of the EdDSA algorithms for the creation of attribute certificates or attribute CRLs <xref target="RFC5755"/>.
            </t>
      
            <t>
              The decision to require the use of pure mode balances the higher security of having a single failure point against the possibility that constrained devices, such as Hardware Security Modules (HSMs), may be unable to check signatures on CRLs due to the amount of memory required to hold the entire CRL in memory at one time.
              This concern can be addressed by CAs using CRL distribution points, combined with segmenting the certificates issued so that the length of any segmented CRL is not "too long" even if a large percentage of the certificates are revoked.
              The definition of "too long" is going to be highly dependent on what constrained device is being used, it can be on the order of single or low double digit kilobytes.
            </t>
               -->
    - </section>
  - <section title="EdDSA Signatures" numbered="true" toc="default">
    - <t>
      - 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.
      - </t>
    - <figure title="" suppress-title="false" align="left" alt="" width="" height="">
      - <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">
        
           Certificate  ::=  SEQUENCE  {
                tbsCertificate       TBSCertificate,
                signatureAlgorithm   AlgorithmIdentifier,
                signatureValue       BIT STRING  }
        
        </artwork>
      - </figure>
    - <t>
      - 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.
      - </t>
    - <t>
      - 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 sSection 3.3 of <xref target="RFC8032" format="default" pageno="false"/>. 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. . 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.
      - </t>
    - <--  Remove Prehash
            <t>
              When the pre-hash versions of the EdDSA signature algorithms are used, the hash function used for the pre-hash is defined by the algorithm.
              This means that the pre-hash function is implicitly included in the algorithm identifier rather than being explicit as done in <xref target="RFC3279"/>.
              </t>
               -->
    - </section>
  - <section title="Private Key Format" numbered="true" toc="default">
    - <t>
      - <xref target="RFC5958" format="default" pageno="false">"Asymmetric Key Packages"</xref> describes how to encode a private key in a structure that both identifies what algorithm the private key is for, but and 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 isare left for the document describing the algorithm itself. describes how to encode a private key in a structure that both identifies what algorithm the private key is for, but and 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 isare left for the document describing the algorithm itself.
      - </t>
    - <figure title="" suppress-title="false" align="left" alt="" width="" height="">
      - <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">
        
        OneAsymmetricKey ::= SEQUENCE {
           version Version,
           privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
           privateKey PrivateKey,
           attributes [0] IMPLICIT Attributes OPTIONAL,
           ...,
           [[2: publicKey [1] IMPLICIT PublicKey OPTIONAL ]],
           ...
        }
        
        PrivateKey ::= OCTET STRING
        
        PublicKey ::= BIT STRING
        
        </artwork>
      - </figure>
    - <t>
      - 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.
      - </t>
    - <figure title="" suppress-title="false" align="left" alt="" width="" height="">
      - <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">
        
        CurvePrivateKey ::= OCTET STRING
        
        </artwork>
      - </figure>
    - <t>
      - To encode an 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 <xref target="RFC7748" format="default" pageno="false"/> and and <xref target="RFC8032" format="default" pageno="false"/>. .
      - </t>
    - <t>
      - The following is an example of a private key encoded using the textual encoding defined in <xref target="RFC7468" format="default" pageno="false"/>..
      - </t>
    - <figure title="" suppress-title="false" align="left" alt="" width="" height="">
      - <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">
        
        -----BEGIN PRIVATE KEY-----
        MC4CAQAwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC
        -----END PRIVATE KEY-----
        
        </artwork>
      - </figure>
    - <t>
      - The following example, in addition to encoding the private key, additionally has an attribute included as well as the public key. As with the prior example, the textual encoding defined in <xref target="RFC7468" format="default" pageno="false"/> is used. is used.
      - </t>
    - <figure title="" suppress-title="false" align="left" alt="" width="" height="">
      - <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">
        
        -----BEGIN PRIVATE KEY-----
        MHICAQEwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC
        oB8wHQYKKoZIhvcNAQkJFDEPDA1DdXJkbGUgQ2hhaXJzgSEAGb9ECWmEzf6FQbrB
        Z9w7lshQhqowtrbLDFw4rXAxZuE=
        -----END PRIVATE KEY------
        
        </artwork>
      - </figure>
    - <t>
      - NOTE: There exist some private key import functions that have not picked up the new ASN.1 structure OneAsymmetricKey that is defined in <xref target="RFC7748" format="default" pageno="false"/>. This means that they will not accept a private key structure that contains the public key field. This means a balancing act needs to be done betwhich contains the public key fieldeen being able to do a consistency check on the key pair and widest ability to import the key. . This means that they will not accept a private key structure that contains the public key field. This means a balancing act needs to be done between being able to do a consistency check on the key pair and widest ability to import the key. . This means that they will not accept a private key structure which contains the public key field. This means a balancing act needs to be done between being able to do a consistency check on the key pair and widest ability to import the key.
      - </t>
    - </section>
  - <section title="Human Readable Algorithm Names" title="Human-Readable Algorithm Names" numbered="true" toc="default">
    - <t>
      - 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.
      - </t>
    - <t>
      - Use the string "ECDH" when referring to a public key of type "X25519" or "X448" when the curve is not known or relevant.
      - </t>
    - <t>
      - When the curve is known, use the more specific string of "X25519" or "X448".
      - </t>
    - <t>
      - Use the string "EdDSA" when referring to a signing public key or signature when the curve is not known or relevant.
      - </t>
    - <t>
      - When the curve is known, use a more specific string. For the id-Ed25519 value use the string "Ed25519".
      - <--  Remove pre-hash
              For
              the id-EdDSA25519ph value use the string "Ed25519ph".   -->
      - For id-Ed448 use "Ed448".
      - <-- Remvoe prehash For id-EdDSA448ph use "Ed448ph". -->
      - When the curve is known, use a more specific string. For the id-Ed25519 value use the string "Ed25519". For id-Ed448, use "Ed448".
      - </t>
    - </section>
  - <section title="ASN.1 Module" anchor="module" numbered="true" toc="default">
    - <t>
      - For reference purposes, the ASN.1 syntax is presented as an ASN.1 module here.
      - </t>
    - <figure title="" suppress-title="false" align="left" alt="" width="" height="">
      - <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">
        
        -- ASN.1 Module
        
        Safecurves-pkix-18
        { iso(1) identified-organization(3) dod(6) internet(1)
        security(5) mechanisms(5) pkix(7) id-mod(0 -- TBD - IANA assigned mod) id-mod-safecule OID
        rves-pkix (93)
        
        DEFINITIONS EXPLICIT TAGS ::=
        BEGIN
        
        IMPORTS
          SIGNATURE-ALGORITHM, KEY-AGREE, PUBLIC-KEY, KEY-WRAP,
          KeyUsage, AlgorithmIdentifier
          FROM AlgorithmInformation-2009
            {iso(1) identified-organization(3) dod(6) internet(1) security(5)
            mechanisms(5) pkix(7) id-mod(0)
            id-mod-algorithmInformation-02(58)}
        
          mda-sha512
          FROM PKIX1-PSS-OAEP-Algorithms-2009
            { iso(1) identified-organization(3) dod(6) internet(1)
              security(5) mechanisms(5) pkix(7) id-mod(0)
              id-mod-pkix1-rsa-pkalgs-02(54) }
        
          kwa-aes128-wrap, kwa-aes256-wrap
          FROM CMSAesRsaesOaep-2009
            { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
              smime(16) modules(0) id-mod-cms-aes-02(38) }
          ;
        
        
        id-edwards-curve-algs OBJECT IDENTIFIER ::= { 1 3 101 }
        
        id-X25519        OBJECT IDENTIFIER ::= { id-edwards-curve-algs 110 }
        id-X448          OBJECT IDENTIFIER ::= { id-edwards-curve-algs 111 }
        id-Ed25519       OBJECT IDENTIFIER ::= { id-edwards-curve-algs 112 }
        id-Ed448         OBJECT IDENTIFIER ::= { id-edwards-curve-algs 113 }
        
        sa-Ed25519 SIGNATURE-ALGORITHM ::= {
            IDENTIFIER id-Ed25519
             PARAMS ARE absent
             PUBLIC-KEYS {pk-Ed25519}
             SMIME-CAPS { IDENTIFIED BY id-Ed25519 }
        }
        
        pk-Ed25519 PUBLIC-KEY ::= {
             IDENTIFIER id-Ed25519
             -- KEY no ASN.1 wrapping --
             PARAMS ARE absent
             CERT-KEY-USAGE {digitalSignature, nonRepudiation,
                             keyCertSign, cRLSign}
             PRIVATE-KEY CurvePrivateKey
        }
        
        kaa-X25519 KEY-AGREE ::= {
             IDENTIFIER id-X25519
             PARAMS ARE absent
             PUBLIC-KEYS {pk-X25519}
             UKM -- TYPE no ASN.1 wrapping -- ARE preferredPresent
             SMIME-CAPS {
                TYPE AlgorithmIdentifier{KEY-WRAP, {KeyWrapAlgorithms}}
                IDENTIFIED BY id-X25519 }
        }
        
        pk-X25519 PUBLIC-KEY ::= {
             IDENTIFIER id-X25519
             -- KEY no ASN.1 wrapping --
             PARAMS ARE absent
             CERT-KEY-USAGE { keyAgreement }
             PRIVATE-KEY CurvePrivateKey
        }
        
        KeyWrapAlgorithms KEY-WRAP ::= {
             kwa-aes128-wrap | kwa-aes256-wrap,
             ...
        }
        
        kaa-X448 KEY-AGREE ::= {
             IDENTIFIER id-X448
             PARAMS ARE absent
             PUBLIC-KEYS {pk-X448}
             UKM -- TYPE no ASN.1 wrapping  -- ARE preferredPresent
             SMIME-CAPS {
                TYPE AlgorithmIdentifier{KEY-WRAP, {KeyWrapAlgorithms}}
                IDENTIFIED BY id-X448 }
        }
        
        pk-X448 PUBLIC-KEY ::= {
             IDENTIFIER id-X448
             -- KEY no ASN.1 wrapping --
             PARAMS ARE absent
             CERT-KEY-USAGE { keyAgreement }
             PRIVATE-KEY CurvePrivateKey
        }
        
        CurvePrivateKey ::= OCTET STRING
        
        
        END
        
        </artwork>
      - </figure>
    - </section>
  - <section title="Examples" numbered="true" toc="default">
    - <t>
      - This section contains illustrations of EdDSA public keys and certificates, illustrating parameter choices.
      - </t>
    - <section title="Example Ed25519 Public Key" numbered="true" toc="default">
      - <t>
        
        An example of an Ed25519 public key:
        
        </t>
      - <figure title="" suppress-title="false" align="left" alt="" width="" height="">
        
        <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">
        
              Public Key Information:
                  Public Key Algorithm: Ed25519
                  Algorithm Security Level: High
        
              Public Key Usage:
        
              Public Key ID: 9b1f5eeded043385e4f7bc623c5975b90bc8bb3b
        
              -----BEGIN PUBLIC KEY-----
              MCowBQYDK2VwAyEAGb9ECWmEzf6FQbrBZ9w7lshQhqowtrbLDFw4rXAxZuE=
              -----END PUBLIC KEY-----
        
        </artwork>
        
        </figure>
      - </section>
    - <section title="Example X25519 Certificate" numbered="true" toc="default">
      - <t>
        
        An example of a self -issued PKIX certificate using Ed25519 to sign an X25519 public key would be:
        
        </t>
      - <figure title="" suppress-title="false" align="left" alt="" width="" height="">
        
        <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">
        
          0 300: SEQUENCE {
          4 223:   SEQUENCE {
          7   3:     [0] {
          9   1:       INTEGER 2
               :       }
        12   8:     INTEGER 56 01 47 4A 2A 8D C3 30
        22   5:     SEQUENCE {
        24   3:       OBJECT IDENTIFIER
               :         Ed 25519 signature algorithm { 1 3 101 112 }
               :       }
        29  25:     SEQUENCE {
        31  23:       SET {
        33  21:         SEQUENCE {
        35   3:           OBJECT IDENTIFIER commonName (2 5 4 3)
        40  14:           UTF8String 'IETF Test Demo'
               :           }
               :         }
               :       }
        56  30:     SEQUENCE {
        58  13:       UTCTime 01/08/2016 12:19:24 GMT
        73  13:       UTCTime 31/12/2040 23:59:59 GMT
               :       }
        88  25:     SEQUENCE {
        90  23:       SET {
        92  21:         SEQUENCE {
        94   3:           OBJECT IDENTIFIER commonName (2 5 4 3)
        99  14:           UTF8String 'IETF Test Demo'
               :           }
               :         }
               :       }
        115  42:     SEQUENCE {
        117   5:       SEQUENCE {
        119   3:         OBJECT IDENTIFIER
               :           ECDH 25519 key agreement { 1 3 101 110 }
               :         }
        124  33:       BIT STRING
               :         85 20 F0 09 89 30 A7 54 74 8B 7D DC B4 3E F7 5A
               :         0D BF 3A 0D 26 38 1A F4 EB A4 A9 8E AA 9B 4E 6A
               :       }
        159  69:     [3] {
        161  67:       SEQUENCE {
        163  15:         SEQUENCE {
        165   3:           OBJECT IDENTIFIER basicConstraints (2 5 29 19)
        170   1:           BOOLEAN TRUE
        173   5:           OCTET STRING, encapsulates {
        175   3:             SEQUENCE {
        177   1:               BOOLEAN FALSE
               :               }
               :             }
               :           }
        180  14:         SEQUENCE {
        182   3:           OBJECT IDENTIFIER keyUsage (2 5 29 15)
        187   1:           BOOLEAN FALSE
        190   4:           OCTET STRING, encapsulates {
        192   2:             BIT STRING 3 unused bits
               :               '10000'B (bit 4)
               :             }
               :           }
        196  32:         SEQUENCE {
        198   3:           OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14)
        203   1:           BOOLEAN FALSE
        206  22:           OCTET STRING, encapsulates {
        208  20:             OCTET STRING
               :               9B 1F 5E ED ED 04 33 85 E4 F7 BC 62 3C 59 75
               :               B9 0B C8 BB 3B
               :             }
               :           }
               :         }
               :       }
               :     }
        230   5:   SEQUENCE {
        232   3:     OBJECT IDENTIFIER
               :       Ed 25519 signature algorithm { 1 3 101 112 }
               :     }
        237  65:   BIT STRING
               :     AF 23 01 FE DD C9 E6 FF C1 CC A7 3D 74 D6 48 A4
               :     39 80 82 CD DB 69 B1 4E 4D 06 EC F8 1A 25 CE 50
               :     D4 C2 C3 EB 74 6C 4E DD 83 46 85 6E C8 6F 3D CE
               :     1A 18 65 C5 7A C2 7B 50 A0 C3 50 07 F5 E7 D9 07
               :   }
        
        -----BEGIN CERTIFICATE-----
        MIIBLDCB36ADAgECAghWAUdKKo3DMDAFBgMrZXAwGTEXMBUGA1UEAwwOSUVURiBUZX
        N0IERlbW8wHhcNMTYwODAxMTIxOTI0WhcNNDAxMjMxMjM1OTU5WjAZMRcwFQYDVQQD
        DA5JRVRGIFRlc3QgRGVtbzAqMAUGAytlbgMhAIUg8AmJMKdUdIt93LQ+91oNvzoNJj
        ga9OukqY6qm05qo0UwQzAPBgNVHRMBAf8EBTADAQEAMA4GA1UdDwEBAAQEAwIDCDAg
        BgNVHQ4BAQAEFgQUmx9e7e0EM4Xk97xiPFl1uQvIuzswBQYDK2VwA0EAryMB/t3J5v
        /BzKc9dNZIpDmAgs3babFOTQbs+BolzlDUwsPrdGxO3YNGhW7Ibz3OGhhlxXrCe1Cg
        w1AH9efZBw==
        -----END CERTIFICATE-----
        
        </artwork>
        
        </figure>
      - </section>
    - <section title="Examples of Ed25519 Private Key" numbered="true" toc="default">
      - <t>
        
        An example of an Ed25519 private key without the public key:
        
        </t>
      - <figure title="" suppress-title="false" align="left" alt="" width="" height="">
        
        <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">
        
        -----BEGIN PRIVATE KEY-----
        MC4CAQAwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC
        -----END PRIVATE KEY-----
        
        </artwork>
        
        </figure>
      - <t>
        
        The same item dumped as ASN.1 yields:
        
        </t>
      - <figure title="" suppress-title="false" align="left" alt="" width="" height="">
        
        <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">
        
        0 30   46: SEQUENCE {
        2 02    1:   INTEGER 0
        5 30    5:   SEQUENCE {
        7 06    3:     OBJECT IDENTIFIER
                  :       Ed 25519 signature algorithm { 1 3 101 112 }
                  :     }
        12 04   34:   OCTET STRING
                  :     04 20 D4 EE 72 DB F9 13 58 4A D5 B6 D8 F1 F7 69
                  :     F8 AD 3A FE 7C 28 CB F1 D4 FB E0 97 A8 8F 44 75
                  :     58 42
                  :   }
        
        
        </artwork>
        
        </figure>
      - <t>
        
        Note that the value of the private key is:
        
        </t>
      - <figure title="" suppress-title="false" align="left" alt="" width="" height="">
        
        <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">
        
        D4 EE 72 DB F9 13 58 4A D5 B6 D8 F1 F7 69 F8 AD
        3A FE 7C 28 CB F1 D4 FB E0 97 A8 8F 44 75 58 42
        
        </artwork>
        
        </figure>
      - <t>
        
        An example of the same Ed25519 private key encoded with an attribute and the public key:
        
        </t>
      - <figure title="" suppress-title="false" align="left" alt="" width="" height="">
        
        <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">
        
        -----BEGIN PRIVATE KEY-----
        MHICAQEwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC
        oB8wHQYKKoZIhvcNAQkJFDEPDA1DdXJkbGUgQ2hhaXJzgSEAGb9ECWmEzf6FQbrB
        Z9w7lshQhqowtrbLDFw4rXAxZuE=
        -----END PRIVATE KEY-----
        
        </artwork>
        
        </figure>
      - <t>
        
        The same item dumped as ASN.1 yields:
        
        </t>
      - <figure title="" suppress-title="false" align="left" alt="" width="" height="">
        
        <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">
        
          0 114: SEQUENCE {
          2   1:   INTEGER 1
          5   5:   SEQUENCE {
          7   3:     OBJECT IDENTIFIER '1 3 101 112'
               :     }
        12  34:   OCTET STRING, encapsulates {
               :     04 20 D4 EE 72 DB F9 13 58 4A D5 B6 D8 F1 F7 69
               :     F8 AD 3A FE 7C 28 CB F1 D4 FB E0 97 A8 8F 44 75
               :     58 42
               :     }
        48  31:   [0] {
        50  29:     SEQUENCE {
        52  10:       OBJECT IDENTIFIER '1 2 840 113549 1 9 9 20'
        64  15:       SET {
        66  13:         UTF8String 'Curdle Chairs'
               :         }
               :       }
               :     }
        81  33:   [1] 00 19 BF 44 09 69 84 CD FE 85 41 BA C1 67 DC 3B
                      96 C8 50 86 AA 30 B6 B6 CB 0C 5C 38 AD 70 31 66
                      E1
               :   }
        
        
        </artwork>
        
        </figure>
      - </section>
    - </section>
  - <section anchor="ack" title="Acknowledgments" numbered="true" toc="default">
    - <t>
      - Text and/or inspiration were drawn from <xref target="RFC5280" format="default" pageno="false"/>, , <xref target="RFC3279" format="default" pageno="false"/>, , <xref target="RFC4055" format="default" pageno="false"/>, , <xref target="RFC5480" format="default" pageno="false"/>, and , and <xref target="RFC5639" format="default" pageno="false"/>..
      - </t>
    - <t>
      - 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, Brian Smith, and Alex Wilson.
      - </t>
    - <t>
      - A big thank you to Symantec for kindly donating the OIDs used in this draft.
      - </t>
    - </section>
  - <section title="IANA Considerations" numbered="true" toc="default">
    - <t>
      - IANA is requested to assign a module OID from the "SMI for PKIX Module Identifier" registry for the ASN.1 module in <xref target="module" format="default" pageno="false"/>. .
      - For the ASN.1 module in <xref target="module" format="default" pageno="false"/>, IANA has registered value 93 for "id-mod-safecurves-pkix" in the "SMI Security for PKIX Module Identifier" (1.3.6.1.5.5.7.0) registry. , IANA has registered value 93 for "id-mod-safecurves-pkix" in the "SMI Security for PKIX Module Identifier" (1.3.6.1.5.5.7.0) registry.
      - </t>
    - <t>
      - The OIDs are being independently registered in the IANA registry "SMI Security for Cryptographic Algorithms" in <xref target="I-D.schaad-curdle-oid-registryRFC8411" format="default" pageno="false"/>. .
      - </t>
    - </section>
  - <section anchor="Security" title="Security Considerations" numbered="true" toc="default">
    - <t>
      - The security considerations of <xref target="RFC5280" format="default" pageno="false"/>, , <xref target="RFC7748" format="default" pageno="false"/>, and , and <xref target="RFC8032" format="default" pageno="false"/> apply accordingly. apply accordingly.
      - </t>
    - <t>
      - The procedures for going from a private key to a public key are different for when used with Diffie-Hellman andversus when used with Edwards Signatures. This means that the same public key cannot be used for both ECDH and EdDSA.
      - </t>
    - <--
            <t>
              In the original design of Ed25519 signatures, there was a known attack between the pure and the pre-hash version of the signatures.
              This has since been corrected in the final version of the design.
              The initial problem meant that there was a known attack, and therefore a known reason to forbid the use of Ed25519 keys with the Ed25519ph signature scheme and visa versa.
              With the change in the design this attack has been prevented.
              This does not mean that the same Ed25519 key should be used with both schemes, there still may be attacks where collisions can be found.
              For this reason, the same keys are not to be used for the pure and pre-hash versions of the scheme.
              This applies to both curve 25519 and curve 448.
              </t>
               -->
    - </section>
  - </middle>
- <back>
  - <references title="Normative References">
    - <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quote-title="true">
      - <front>
        
        <title>
        
        Key words for use in RFCs to Indicate Requirement Levels
        
        </title>
        
        <author initials="S." surname="Bradner" fullname="S. Bradner">
        
        <organization/>
        
        </author>
        
        <date year="1997" month="March"/>
        
        <abstract>
        
        <t>
        
        In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="BCP" value="14"/>
      - <seriesInfo name="RFC" value="2119"/>
      - <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      - </reference>
    - <reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5280" quote-title="true">
      - <front>
        
        <title>
        
        Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
        
        </title>
        
        <author initials="D." surname="Cooper" fullname="D. Cooper">
        
        <organization/>
        
        </author>
        
        <author initials="S." surname="Santesson" fullname="S. Santesson">
        
        <organization/>
        
        </author>
        
        <author initials="S." surname="Farrell" fullname="S. Farrell">
        
        <organization/>
        
        </author>
        
        <author initials="S." surname="Boeyen" fullname="S. Boeyen">
        
        <organization/>
        
        </author>
        
        <author initials="R." surname="Housley" fullname="R. Housley">
        
        <organization/>
        
        </author>
        
        <author initials="W." surname="Polk" fullname="W. Polk">
        
        <organization/>
        
        </author>
        
        <date year="2008" month="May"/>
        
        <abstract>
        
        <t>
        
        This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="5280"/>
      - <seriesInfo name="DOI" value="10.17487/RFC5280"/>
      - </reference>
    - <reference anchor="RFC5480" target="https://www.rfc-editor.org/info/rfc5480" quote-title="true">
      - <front>
        
        <title>
        
        Elliptic Curve Cryptography Subject Public Key Information
        
        </title>
        
        <author initials="S." surname="Turner" fullname="S. Turner">
        
        <organization/>
        
        </author>
        
        <author initials="D." surname="Brown" fullname="D. Brown">
        
        <organization/>
        
        </author>
        
        <author initials="K." surname="Yiu" fullname="K. Yiu">
        
        <organization/>
        
        </author>
        
        <author initials="R." surname="Housley" fullname="R. Housley">
        
        <organization/>
        
        </author>
        
        <author initials="T." surname="Polk" fullname="T. Polk">
        
        <organization/>
        
        </author>
        
        <date year="2009" month="March"/>
        
        <abstract>
        
        <t>
        
        This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDS-TRACK]
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="5480"/>
      - <seriesInfo name="DOI" value="10.17487/RFC5480"/>
      - </reference>
    - <reference anchor="RFC7748" target="https://www.rfc-editor.org/info/rfc7748" quote-title="true">
      - <front>
        
        <title>
        
        Elliptic Curves for Security
        
        </title>
        
        <author initials="A." surname="Langley" fullname="A. Langley">
        
        <organization/>
        
        </author>
        
        <author initials="M." surname="Hamburg" fullname="M. Hamburg">
        
        <organization/>
        
        </author>
        
        <author initials="S." surname="Turner" fullname="S. Turner">
        
        <organization/>
        
        </author>
        
        <date year="2016" month="January"/>
        
        <abstract>
        
        <t>
        
        This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="7748"/>
      - <seriesInfo name="DOI" value="10.17487/RFC7748"/>
      - </reference>
    - <reference anchor="RFC8032" target="https://www.rfc-editor.org/info/rfc8032" quote-title="true">
      - <front>
        
        <title>
        
        Edwards-Curve Digital Signature Algorithm (EdDSA)
        
        </title>
        
        <author initials="S." surname="Josefsson" fullname="S. Josefsson">
        
        <organization/>
        
        </author>
        
        <author initials="I." surname="Liusvaara" fullname="I. Liusvaara">
        
        <organization/>
        
        </author>
        
        <date year="2017" month="January"/>
        
        <abstract>
        
        <t>
        
        This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="8032"/>
      - <seriesInfo name="DOI" value="10.17487/RFC8032"/>
      - </reference>
    - <reference anchor="RFC5958" target="https://www.rfc-editor.org/info/rfc5958" quote-title="true">
      - <front>
        
        <title>
        
        Asymmetric Key Packages
        
        </title>
        
        <author initials="S." surname="Turner" fullname="S. Turner">
        
        <organization/>
        
        </author>
        
        <date year="2010" month="August"/>
        
        <abstract>
        
        <t>
        
        This document defines the syntax for private-key information and a content type for it. Private-key information includes a private key for a specified public-key algorithm and a set of attributes. The Cryptographic Message Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type. This document obsoletes RFC 5208. [STANDARDS-TRACK]
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="5958"/>
      - <seriesInfo name="DOI" value="10.17487/RFC5958"/>
      - </reference>
    - <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quote-title="true">
      - <front>
        
        <title>
        
        Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
        
        </title>
        
        <author initials="B." surname="Leiba" fullname="B. Leiba">
        
        <organization/>
        
        </author>
        
        <date year="2017" month="May"/>
        
        <abstract>
        
        <t>
        
        RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="BCP" value="14"/>
      - <seriesInfo name="RFC" value="8174"/>
      - <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      - </reference>
    - </references>
  - <references title="Informative References">
    - <reference anchor="RFC3279" target="https://www.rfc-editor.org/info/rfc3279" quote-title="true">
      - <front>
        
        <title>
        
        Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
        
        </title>
        
        <author initials="L." surname="Bassham" fullname="L. Bassham">
        
        <organization/>
        
        </author>
        
        <author initials="W." surname="Polk" fullname="W. Polk">
        
        <organization/>
        
        </author>
        
        <author initials="R." surname="Housley" fullname="R. Housley">
        
        <organization/>
        
        </author>
        
        <date year="2002" month="April"/>
        
        <abstract>
        
        <t>
        
        This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). Digital signatures are used to sign certificates and certificate revocation list (CRLs). Certificates include the public key of the named subject. [STANDARDS-TRACK]
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="3279"/>
      - <seriesInfo name="DOI" value="10.17487/RFC3279"/>
      - </reference>
    - <reference anchor="RFC4055" target="https://www.rfc-editor.org/info/rfc4055" quote-title="true">
      - <front>
        
        <title>
        
        Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
        
        </title>
        
        <author initials="J." surname="Schaad" fullname="J. Schaad">
        
        <organization/>
        
        </author>
        
        <author initials="B." surname="Kaliski" fullname="B. Kaliski">
        
        <organization/>
        
        </author>
        
        <author initials="R." surname="Housley" fullname="R. Housley">
        
        <organization/>
        
        </author>
        
        <date year="2005" month="June"/>
        
        <abstract>
        
        <t>
        
        This document supplements RFC 3279. It describes the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) signature algorithm, the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm and additional one-way hash functions with the Public-Key Cryptography Standards (PKCS) #1 version 1.5 signature algorithm in the Internet X.509 Public Key Infrastructure (PKI). Encoding formats, algorithm identifiers, and parameter formats are specified. [STANDARDS-TRACK]
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="4055"/>
      - <seriesInfo name="DOI" value="10.17487/RFC4055"/>
      - </reference>
    - <reference anchor="RFC5639" target="https://www.rfc-editor.org/info/rfc5639" quote-title="true">
      - <front>
        
        <title>
        
        Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation
        
        </title>
        
        <author initials="M." surname="Lochter" fullname="M. Lochter">
        
        <organization/>
        
        </author>
        
        <author initials="J." surname="Merkle" fullname="J. Merkle">
        
        <organization/>
        
        </author>
        
        <date year="2010" month="March"/>
        
        <abstract>
        
        <t>
        
        This memo proposes several elliptic curve domain parameters over finite prime fields for use in cryptographic applications. The domain parameters are consistent with the relevant international standards, and can be used in X.509 certificates and certificate revocation lists (CRLs), for Internet Key Exchange (IKE), Transport Layer Security (TLS), XML signatures, and all applications or protocols based on the cryptographic message syntax (CMS). This document is not an Internet Standards Track specification; it is published for informational purposes.
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="5639"/>
      - <seriesInfo name="DOI" value="10.17487/RFC5639"/>
      - </reference>
    - <--  Remove for pre-hash
                 &rfc5755;
                  -->
    - <-- &rfc5758; -->
    - <-- &rfc5915; -->
    - <reference anchor="RFC7468" target="https://www.rfc-editor.org/info/rfc7468" quote-title="true">
      - <front>
        
        <title>
        
        Textual Encodings of PKIX, PKCS, and CMS Structures
        
        </title>
        
        <author initials="S." surname="Josefsson" fullname="S. Josefsson">
        
        <organization/>
        
        </author>
        
        <author initials="S." surname="Leonard" fullname="S. Leonard">
        
        <organization/>
        
        </author>
        
        <date year="2015" month="April"/>
        
        <abstract>
        
        <t>
        
        This document describes and discusses the textual encodings of the Public-Key Infrastructure X.509 (PKIX), Public-Key Cryptography Standards (PKCS), and Cryptographic Message Syntax (CMS). The textual encodings are well-known, are implemented by several applications and libraries, and are widely deployed. This document articulates the de facto rules by which existing implementations operate and defines them so that future implementations can interoperate.
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="RFC" value="7468"/>
      - <seriesInfo name="DOI" value="10.17487/RFC7468"/>
      - </reference>
    - <-- &iana;draft-schaad-curdle-oid-registry-03; in AUTH48 as RFC8411 -->
    - <reference anchor="I-D.schaad-curdle-oid-registry" anchor="RFC8411" quote-title="true" target="http://www.rfc-editor.org/info/rfc8411">
      - <front>
        
        <title>
        
        IANA Registration for new Cryptographic Algorithm Object Identifier Range
        
        IANA Registration for the Cryptographic Algorithm Object Identifier Range
        
        </title>
        
        <author initials="J" surname="Schaad" fullname="Jim Schaad">
        
        <organization/>
        
        </author>
        
        <author initials="R" surname="Andrews" fullname="Rick Andrews">
        
        <organization/>
        
        </author>
        
        <date month="January" month="July" day="25" year="2018"/>
        
        <abstract>
        
        <t>
        
        When the Curdle Security Working Group was chartered, a range of object identifiers was donated by DigiCert, Inc. for the purpose of registering the Edwards Elliptic Curve key agreement and signature algorithms. This donated set of OIDs allowed for shorter values than would be possible using the existing S/MIME or PKIX arcs. This document describes the range of identifiers that were assigned in that donated range, transfers control of that range to IANA, and establishes IANA allocation policies for any future assignments within that range.
        
        </t>
        
        </abstract>
        
        </front>
      - <seriesInfo name="Internet-Draft" name="RFC" value="draft-schaad-curdle-oid-registry-03" value="8411"/>
      - <seriesInfo name="DOI" value="10.17487/RFC8411"/>
      - <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-schaad-curdle-oid-registry-03.txt"/>
      - </reference>
    - </references>
  - <section title="Invalid Encodings" numbered="true" toc="default">
    - <t>
      - There are a number of things that need to be dealt with when a new key part is decoded and imported into the system. A partial list of these includes:
      - <list style="symbols">
        
        <-- [rfced] Please clarify this sentence. Does it mean the following or otherwise?
        
        Current:
           This was an incorrect copy of the structure from [RFC5958],
           which was corrected before publication.
        
        Perhaps:
          This was a copy of an incorrect structure that was in
          the Internet-Draft; the structure is correct in [RFC5958].
        
        Or:
          This was a copy of incorrect structure that was in a draft
          of the document that later became [RFC5958]; the structure is
          correct in the RFC.
        -->
        
        <t>
        
        ASN.1 encoding errors: Two items are highlighted here. First, the use of an OCTET STRING rather than a BIT STRING for the public key. Thise use of OCTET STRING was an incorrect copy of the structure from copy error that existed in a previous draft version of this document; the structure is correct in <xref target="RFC5958" format="default" pageno="false"/> . Howhichever, any early implementation may have this was corrected before publication. Howeverrong. Second, any early implementation may have this wrong. Second, the value of the version field is required to be 0 if the publicKey is absent and 1 if present. This is called out in which was corrected before publication. However, any early implementation may have this wrong. Second, the value of the version field is required to be 0 if the publicKey is absent and 1 if present. This is called out in <xref target="RFC5958" format="default" pageno="false"/> but is not duplicated in the main text. but is not duplicated in the main text. , but was not duplicated above. , but was not duplicated above.
        
        </t>
        
        <t>
        
        Key encoding errors: Both <xref target="RFC7748" format="default" pageno="false"/> and and <xref target="RFC8032" format="default" pageno="false"/> have formatting requirements for keys that need to be enforced. In some cases, the enforcement is done at the time of importing, for example, doing masking or a mod p operation. In other cases, the enforcement is done by rejecting the keys and having an import failure. have formatting requirements for keys that need to be enforced. In some cases, the enforcement is done at the time of importing, for example, doing masking or a mod p operation. In other cases, the enforcement is done by rejecting the keys and having an import failure.
        
        </t>
        
        <t>
        
        Key mismatch errors: If a public key is provided, it may not agree with the private key either because either it is wrong or the wrong algorithm was used.
        
        </t>
        
        </list>
      - </t>
    - <t>
      - Some systems are also going to be stricter on what they accept. As stated in <xref target="RFC5958" format="default" pageno="false"/>, BER decoding of OneAsymmetricKey objects is a requirement for compliance. Despite this requirement, some acceptors will only decode DER formats. The following is a BER encoding of a private key, as such is; it is valid, but it may not be accepted by many systems. , BER decoding of OneAsymmetricKey objects is a requirement for compliance. Despite this requirement, some acceptors will only decode DER formats. The following is a BER encoding of a private key; it is valid, as sbuch is is valid, but it may not be accepted by many systems.
      - </t>
    - <figure title="" suppress-title="false" align="left" alt="" width="" height="">
      - <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">
        
        -----BEGIN PRIVATE KEY-----
        MIACAQAwgAYDK2VwAAAEIgQg1O5y2/kTWErVttjx92n4rTr+fCjL8dT74Jeoj0R1W
        EIAAA==
        -----END PRIVATE KEY-----
        
        </artwork>
      - </figure>
    - <t>
      - What follows here is a brief sampling of some incorrect keys.
      - </t>
    - <t>
      - In the following example, the private key does not match the masking requirements for X25519. For this example, the top bits are set to zero and the bottom three bits are set to 001.
      - </t>
    - <figure title="" suppress-title="false" align="left" alt="" width="" height="">
      - <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">
        
        -----BEGIN PRIVATE KEY-----
        MFMCAQEwBQYDK2VuBCIEIPj///////////////////////////////////////8/oS
        MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg==
        -----END PRIVATE KEY-----
        
        </artwork>
      - </figure>
    - <t>
      - In the following examples, the key is the wrong length because an all -zero byte has been removed. In one case, the first byte has been removed,; in the other case, the last byte has been removed.
      - </t>
    - <figure title="" suppress-title="false" align="left" alt="" width="" height="">
      - <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">
        
        -----BEGIN PRIVATE KEY-----
        MFICAQEwBQYDK2VwBCIEIC3GfeUYbZGTAhwLEE2cbvJL7ivTlcy17VottfN6L8HwoS
        IDIADBfk2Lv/J8H7YYwj/OmIcDx++jzVkKrKwS0/HjyQyM
        -----END PRIVATE KEY-----
        
        </artwork>
      - </figure>
    - <figure title="" suppress-title="false" align="left" alt="" width="" height="">
      - <artwork {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" align="left" alt="" width="" height="">
        
        -----BEGIN PRIVATE KEY-----
        MFICAQEwBQYDK2VwBCIEILJXn1VaLqvausjUaZexwI/ozmOFjfEk78KcYN+7hsNJoS
        IDIACdQhJwzi/MCGcsQeQnIUh2JFybDxSrZxuLudJmpJLk
        -----END PRIVATE KEY-----
        
        </artwork>
      - </figure>
    - </section>
  - <section title="Acknowledgments" numbered="no" toc="default">
    - <t>
      - Text and/or inspiration were drawn from <xref target="RFC5280" format="default" pageno="false"/>, , <xref target="RFC3279" format="default" pageno="false"/>, , <xref target="RFC4055" format="default" pageno="false"/>, , <xref target="RFC5480" format="default" pageno="false"/>, and , and <xref target="RFC5639" format="default" pageno="false"/>..
      - </t>
    - <t>
      - 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, Brian Smith, and Alex Wilson.
      - </t>
    - <t>
      - A big thank you to Symantec for kindly donating the OIDs used in this document.
      - </t>
    - </section>
  - </back>
- </rfc>

<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3279 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3279.xml">
<!ENTITY rfc4055 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4055.xml">
<!ENTITY rfc5280 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY rfc5480 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5480.xml">
<!ENTITY rfc5639 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5639.xml">
<!ENTITY rfc5755 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5755.xml">
<!ENTITY rfc5758 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5758.xml">
<!ENTITY rfc5915 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5915.xml">
<!ENTITY rfc5958 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5958.xml">
<!ENTITY rfc7468 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7468.xml">
<!ENTITY rfc7748 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7748.xml">
<!ENTITY rfc8174 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY eddsa   SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8032.xml">
]>

<?rfc strict="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>

<rfc submissionType="IETF" category="std" consensus="yes"
     ipr="trust200902"
     number="8410">
     
  <front>
    
    <title abbrev="Safe Curves for X.509">
        
      Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure
    </title>
    
    <author fullname="Simon Josefsson" initials="S." surname="Josefsson">
      <organization>SJD AB</organization>
      <address>
        <email>simon@josefsson.org</email>
      </address>
    </author>

    <author fullname="Jim Schaad" initials="J" surname="Schaad">
      <organization>August Cellars</organization>
      <address>
        <email>ietf@augustcellars.com</email>
      </address>
    </author>

    <date month="July" year="2018"/>

    <keyword>Elliptic Curve Cryptography, Curve25519, Curve448,
    Goldilocks, X.509, PKIX, PKI, OID, ASN.1, EdDSA,
    Ed25519, Ed448, X25519, X448</keyword>

    <abstract>

      <t>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 and Ed448.  The key agreement algorithms
      covered are X25519 and X448.  The encoding for public key,
      private key, and Edwards-curve Digital Signature Algorithm
      (EdDSA) structures is provided.
      </t>

    </abstract>

  </front>

  <middle>

    <section title="Introduction">

      <t>
        In <xref target="RFC7748"/>, 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.
      </t>

      <t>
        <xref target="RFC7748"/> 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 associated
        parameters.  The use of these OIDs is described for public and
        private keys.
      </t>
        

      <t>
        In <xref target="RFC8032"/> 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 prehashing and the HashEdDSA mode
        with prehashing.  The convention used for identifying the
        algorithm/curve combinations is to use "Ed25519" and "Ed448"
        for the PureEdDSA mode.  This document does not provide the
        conventions needed for the prehash versions of the signature
        algorithm.  The use of the OIDs is described for public keys,
        private keys and signatures.
      </t>

      <t>
        <xref target="RFC8032"/> additionally defines 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:
        <list style="symbols">
          <t>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.</t>
          <t>
            EdDSA is the only IETF algorithm that
            currently supports the use of contexts; however, there is a
            possibility that there will be confusion between which
            algorithms need to have separate keys and which do not.
            This may result in a decrease of security for those other
            algorithms.
          </t>
          <t>
            There are still ongoing discussions among the
            cryptographic community about how effective the use of
            contexts is for preventing attacks.
          </t>
          <t>
            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 note that a context
            string needs to be provided.
          </t>
        </list>
      </t>
    </section>

    <section title="Requirements Terminology">

      <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 <xref target="RFC2119" /> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.
      </t>

    </section>

    <section title="Curve25519 and Curve448 Algorithm Identifiers">

      <t>Certificates conforming to <xref target="RFC5280"/> can
      convey a public key for any public key algorithm.  The
      certificate indicates the algorithm through an algorithm
      identifier.  An algorithm identifier consists of an OID and optional parameters.
      </t>
      
      <t>The AlgorithmIdentifier type, which is included for
      convenience, is defined as follows:</t>

      <figure>
        <artwork><![CDATA[
AlgorithmIdentifier  ::=  SEQUENCE  {
    algorithm   OBJECT IDENTIFIER,
    parameters  ANY DEFINED BY algorithm OPTIONAL
}
]]></artwork>
      </figure>

      <t>The fields in AlgorithmIdentifier have the following
      meanings:</t>

      <t><list style="symbols">
        <t>algorithm identifies the cryptographic algorithm with an
        object identifier.  Four such OIDs are defined below.</t>

    <t>parameters, which are optional, are the associated
    parameters for the algorithm identifier in the algorithm
    field.
    </t>
      </list></t>

      <t>

    In this document, we define four new OIDs for identifying the
    different curve/algorithm pairs: the curves being curve25519 and
    curve448 and the algorithms being ECDH and EdDSA in pure mode.  For all of the OIDs, the
    parameters MUST be absent.
      </t>

  <t>
    It is possible to find systems that require the parameters to be
    present.  This can be due to either a defect in the original 1997
    syntax or a programming error where developers never got input
    where this was not true.  The optimal solution is to fix these
    systems; where this is not possible, the problem needs to be
    restricted to that subsystem and not propagated to the Internet.
  </t>
      <t>
        The same algorithm identifiers are used for identifying a
        public key, a private key, and a
        signature (for the two EdDSA related OIDs).  Additional
        encoding information is provided below for each of these
        locations.
      </t>

      
      <figure>
        <artwork><![CDATA[
id-X25519    OBJECT IDENTIFIER ::= { 1 3 101 110 }
id-X448      OBJECT IDENTIFIER ::= { 1 3 101 111 }
id-Ed25519   OBJECT IDENTIFIER ::= { 1 3 101 112 }
id-Ed448     OBJECT IDENTIFIER ::= { 1 3 101 113 }
]]></artwork>
      </figure>

    </section>

    <section title="Subject Public Key Fields">

      <t>In the X.509 certificate, the subjectPublicKeyInfo field has
      the SubjectPublicKeyInfo type, which has the following ASN.1
      syntax:</t>

      <figure>
        <artwork><![CDATA[
SubjectPublicKeyInfo  ::=  SEQUENCE  {
    algorithm         AlgorithmIdentifier,
    subjectPublicKey  BIT STRING
}
]]></artwork>
      </figure>

      <t>The fields in SubjectPublicKeyInfo have the following
      meanings:</t>

      <t><list style="symbols">
        <t>algorithm is the algorithm identifier and parameters for
        the public key (see above).</t>

        <t>subjectPublicKey contains the byte stream of the public key.
        The algorithms defined in this document always encode the public key as an exact multiple of 8 bits.
        </t>
      </list></t>

      <t>
        Both <xref target="RFC7748"/> and <xref target="RFC8032"/>
        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.
      </t>

      <t>The following is an example of a public key encoded using the
      textual encoding defined in <xref target="RFC7468"/>.</t>

      <figure>
<artwork><![CDATA[
-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEAGb9ECWmEzf6FQbrBZ9w7lshQhqowtrbLDFw4rXAxZuE=
-----END PUBLIC KEY-----      
]]></artwork>
      </figure>
    </section>
    
    <section title="Key Usage Bits">
      
      <t>The intended application for the key is indicated in the
      keyUsage certificate extension.</t>

      <t>
        If the keyUsage extension is present in a certificate that indicates
        id-X25519 or id-X448 in SubjectPublicKeyInfo, then the following MUST
        be present:
      </t>

      <figure><artwork>
        keyAgreement;
      </artwork></figure>

      <t>
        one of the following MAY also be present:
      </t>

      <t>
        <figure><artwork>
          encipherOnly; or
          decipherOnly.
          </artwork>
        </figure>
      </t>

      <t>
        If the keyUsage extension is present in an end-entity
        certificate that indicates id-Ed25519 or id-Ed448, then the
        keyUsage extension MUST contain one or both of the following
        values:</t>

      <figure>
        <artwork><![CDATA[
        nonRepudiation; and
        digitalSignature.
]]></artwork>
      </figure>

      <t>If the keyUsage extension is present in a certification
      authority certificate that indicates id-Ed25519 or id-Ed448,
      then the keyUsage extension MUST contain one or more of the
      following values:</t>

      <figure>
<artwork><![CDATA[
       nonRepudiation;
       digitalSignature;
       keyCertSign; and
       cRLSign.
       ]]></artwork>
      </figure>

        

    </section>

    <section title="EdDSA Signatures">

      <t>
        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.
      </t>


      <figure>
<artwork><![CDATA[
   Certificate  ::=  SEQUENCE  {
        tbsCertificate       TBSCertificate,
        signatureAlgorithm   AlgorithmIdentifier,
        signatureValue       BIT STRING  }
]]></artwork>
      </figure>

      <t>
        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.
      </t>

      <t>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 <xref target="RFC8032"/>.
      
      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.
      </t>
      
    </section>

    <section title="Private Key Format">

      <t>
        <xref target="RFC5958">"Asymmetric Key Packages"</xref>
        describes how to encode a private key in a structure that both
        identifies what algorithm the private key is for and 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 are left for the
        document describing the algorithm itself.
      </t>
      
      <figure>
        <artwork><![CDATA[
OneAsymmetricKey ::= SEQUENCE {
   version Version,
   privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
   privateKey PrivateKey,
   attributes [0] IMPLICIT Attributes OPTIONAL,
   ...,
   [[2: publicKey [1] IMPLICIT PublicKey OPTIONAL ]],
   ...
}

PrivateKey ::= OCTET STRING

PublicKey ::= BIT STRING
]]></artwork>
      </figure>

      <t>
        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 a CurvePrivateKey object and
        wrapped by the OCTET STRING of the "privateKey" field.
      </t>

      <figure>
      <artwork><![CDATA[
CurvePrivateKey ::= OCTET STRING
]]></artwork>
      </figure>
      
      <t>
To encode an 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 <xref target="RFC7748"/> and <xref
target="RFC8032"/>.
      </t>

      <t>The following is an example of a private key encoded using
      the textual encoding defined in <xref target="RFC7468"/>.</t>

      <figure>
<artwork><![CDATA[
-----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC
-----END PRIVATE KEY-----
]]></artwork>
      </figure>

      <t>
        The following example, in addition to encoding the private
        key, has an attribute included as well as the
        public key.  As with the prior example, the textual encoding
        defined in <xref target="RFC7468"/> is used.
      </t>
      <figure>
        <artwork><![CDATA[
-----BEGIN PRIVATE KEY-----
MHICAQEwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC
oB8wHQYKKoZIhvcNAQkJFDEPDA1DdXJkbGUgQ2hhaXJzgSEAGb9ECWmEzf6FQbrB
Z9w7lshQhqowtrbLDFw4rXAxZuE=
-----END PRIVATE KEY------]]></artwork>
      </figure>

      <t>
        NOTE: There exist some private key import functions that have
        not picked up the new ASN.1 structure OneAsymmetricKey that is
        defined in <xref target="RFC7748"/>.  This means that they
        will not accept a private key structure that contains the
        public key field.  This means a balancing act needs to be done
        between being able to do a consistency check on the key pair
        and widest ability to import the key.
      </t>
    </section>

    <section title="Human-Readable Algorithm Names">

      <t>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.</t>

      <t>Use the string "ECDH" when referring to a public key of type
      "X25519" or "X448" when the curve is not known or relevant.</t>

      <t>When the curve is known, use the more specific string of
      "X25519" or "X448".</t>
      
      
      <t>Use the string "EdDSA" when referring to a signing public key or
      signature when the curve is not known or relevant.</t>

      <t>When the curve is known, use a more specific
      string. 
      For the id-Ed25519 value use the string "Ed25519". For id-Ed448,
      use "Ed448".</t>
      
    </section>

    <section title="ASN.1 Module" anchor="module">

      <t>For reference purposes, the ASN.1 syntax is presented as an
      ASN.1 module here.</t>

      <figure>
<artwork><![CDATA[
-- ASN.1 Module

Safecurves-pkix-18
 { iso(1) identified-organization(3) dod(6) internet(1)
 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-safecurves-pkix (93)
  
DEFINITIONS EXPLICIT TAGS ::=
BEGIN

IMPORTS
  SIGNATURE-ALGORITHM, KEY-AGREE, PUBLIC-KEY, KEY-WRAP,
  KeyUsage, AlgorithmIdentifier
  FROM AlgorithmInformation-2009 
    {iso(1) identified-organization(3) dod(6) internet(1) security(5)
    mechanisms(5) pkix(7) id-mod(0)
    id-mod-algorithmInformation-02(58)}

  mda-sha512
  FROM PKIX1-PSS-OAEP-Algorithms-2009
    { iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-pkix1-rsa-pkalgs-02(54) }

  kwa-aes128-wrap, kwa-aes256-wrap
  FROM CMSAesRsaesOaep-2009
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
      smime(16) modules(0) id-mod-cms-aes-02(38) }
  ;
    

id-edwards-curve-algs OBJECT IDENTIFIER ::= { 1 3 101 }

id-X25519        OBJECT IDENTIFIER ::= { id-edwards-curve-algs 110 }
id-X448          OBJECT IDENTIFIER ::= { id-edwards-curve-algs 111 }
id-Ed25519       OBJECT IDENTIFIER ::= { id-edwards-curve-algs 112 }
id-Ed448         OBJECT IDENTIFIER ::= { id-edwards-curve-algs 113 }


 sa-Ed25519 SIGNATURE-ALGORITHM ::= {
    IDENTIFIER id-Ed25519
     PARAMS ARE absent
     PUBLIC-KEYS {pk-Ed25519}
     SMIME-CAPS { IDENTIFIED BY id-Ed25519 }
 }

 pk-Ed25519 PUBLIC-KEY ::= {
     IDENTIFIER id-Ed25519
     -- KEY no ASN.1 wrapping --
     PARAMS ARE absent
     CERT-KEY-USAGE {digitalSignature, nonRepudiation,
                     keyCertSign, cRLSign}
     PRIVATE-KEY CurvePrivateKey
 }

 kaa-X25519 KEY-AGREE ::= {
     IDENTIFIER id-X25519
     PARAMS ARE absent
     PUBLIC-KEYS {pk-X25519}
     UKM -- TYPE no ASN.1 wrapping -- ARE preferredPresent
     SMIME-CAPS {
        TYPE AlgorithmIdentifier{KEY-WRAP, {KeyWrapAlgorithms}}
        IDENTIFIED BY id-X25519 }
 }

 pk-X25519 PUBLIC-KEY ::= {
     IDENTIFIER id-X25519
     -- KEY no ASN.1 wrapping --
     PARAMS ARE absent
     CERT-KEY-USAGE { keyAgreement }
     PRIVATE-KEY CurvePrivateKey
 }

 KeyWrapAlgorithms KEY-WRAP ::= {
     kwa-aes128-wrap | kwa-aes256-wrap,
     ...
 }
     
 kaa-X448 KEY-AGREE ::= {
     IDENTIFIER id-X448
     PARAMS ARE absent
     PUBLIC-KEYS {pk-X448}
     UKM -- TYPE no ASN.1 wrapping  -- ARE preferredPresent
     SMIME-CAPS {
        TYPE AlgorithmIdentifier{KEY-WRAP, {KeyWrapAlgorithms}}
        IDENTIFIED BY id-X448 }
 }

 pk-X448 PUBLIC-KEY ::= {
     IDENTIFIER id-X448
     -- KEY no ASN.1 wrapping --
     PARAMS ARE absent
     CERT-KEY-USAGE { keyAgreement }
     PRIVATE-KEY CurvePrivateKey
 }

CurvePrivateKey ::= OCTET STRING
    
                                 
END
]]></artwork>
      </figure>

    </section>

    <section title="Examples">

      <t>This section contains illustrations of EdDSA public keys and
      certificates, illustrating parameter choices.</t>


      <section title="Example Ed25519 Public Key">

<t>An example of an Ed25519 public key:</t>

<figure>
  <artwork><![CDATA[
      Public Key Information:
          Public Key Algorithm: Ed25519
          Algorithm Security Level: High

      Public Key Usage:
      
      Public Key ID: 9b1f5eeded043385e4f7bc623c5975b90bc8bb3b
      
      -----BEGIN PUBLIC KEY-----
      MCowBQYDK2VwAyEAGb9ECWmEzf6FQbrBZ9w7lshQhqowtrbLDFw4rXAxZuE=
      -----END PUBLIC KEY-----
]]></artwork>
</figure>
      
      </section>

      <section title="Example X25519 Certificate">

<t>An example of a self-issued PKIX certificate using Ed25519 to sign
an X25519 public key would be:</t>

<figure>
  <artwork><![CDATA[
  0 300: SEQUENCE {
  4 223:   SEQUENCE {
  7   3:     [0] {
  9   1:       INTEGER 2
       :       }
 12   8:     INTEGER 56 01 47 4A 2A 8D C3 30
 22   5:     SEQUENCE {
 24   3:       OBJECT IDENTIFIER
       :         Ed 25519 signature algorithm { 1 3 101 112 }
       :       }
 29  25:     SEQUENCE {
 31  23:       SET {
 33  21:         SEQUENCE {
 35   3:           OBJECT IDENTIFIER commonName (2 5 4 3)
 40  14:           UTF8String 'IETF Test Demo'
       :           }
       :         }
       :       }
 56  30:     SEQUENCE {
 58  13:       UTCTime 01/08/2016 12:19:24 GMT
 73  13:       UTCTime 31/12/2040 23:59:59 GMT
       :       }
 88  25:     SEQUENCE {
 90  23:       SET {
 92  21:         SEQUENCE {
 94   3:           OBJECT IDENTIFIER commonName (2 5 4 3)
 99  14:           UTF8String 'IETF Test Demo'
       :           }
       :         }
       :       }
115  42:     SEQUENCE {
117   5:       SEQUENCE {
119   3:         OBJECT IDENTIFIER
       :           ECDH 25519 key agreement { 1 3 101 110 }
       :         }
124  33:       BIT STRING
       :         85 20 F0 09 89 30 A7 54 74 8B 7D DC B4 3E F7 5A
       :         0D BF 3A 0D 26 38 1A F4 EB A4 A9 8E AA 9B 4E 6A
       :       }
159  69:     [3] {
161  67:       SEQUENCE {
163  15:         SEQUENCE {
165   3:           OBJECT IDENTIFIER basicConstraints (2 5 29 19)
170   1:           BOOLEAN TRUE
173   5:           OCTET STRING, encapsulates {
175   3:             SEQUENCE {
177   1:               BOOLEAN FALSE
       :               }
       :             }
       :           }
180  14:         SEQUENCE {
182   3:           OBJECT IDENTIFIER keyUsage (2 5 29 15)
187   1:           BOOLEAN FALSE
190   4:           OCTET STRING, encapsulates {
192   2:             BIT STRING 3 unused bits
       :               '10000'B (bit 4)
       :             }
       :           }
196  32:         SEQUENCE {
198   3:           OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14)
203   1:           BOOLEAN FALSE
206  22:           OCTET STRING, encapsulates {
208  20:             OCTET STRING
       :               9B 1F 5E ED ED 04 33 85 E4 F7 BC 62 3C 59 75
       :               B9 0B C8 BB 3B
       :             }
       :           }
       :         }
       :       }
       :     }
230   5:   SEQUENCE {
232   3:     OBJECT IDENTIFIER
       :       Ed 25519 signature algorithm { 1 3 101 112 }
       :     }
237  65:   BIT STRING
       :     AF 23 01 FE DD C9 E6 FF C1 CC A7 3D 74 D6 48 A4
       :     39 80 82 CD DB 69 B1 4E 4D 06 EC F8 1A 25 CE 50
       :     D4 C2 C3 EB 74 6C 4E DD 83 46 85 6E C8 6F 3D CE
       :     1A 18 65 C5 7A C2 7B 50 A0 C3 50 07 F5 E7 D9 07
       :   }
      
-----BEGIN CERTIFICATE-----
MIIBLDCB36ADAgECAghWAUdKKo3DMDAFBgMrZXAwGTEXMBUGA1UEAwwOSUVURiBUZX
N0IERlbW8wHhcNMTYwODAxMTIxOTI0WhcNNDAxMjMxMjM1OTU5WjAZMRcwFQYDVQQD
DA5JRVRGIFRlc3QgRGVtbzAqMAUGAytlbgMhAIUg8AmJMKdUdIt93LQ+91oNvzoNJj
ga9OukqY6qm05qo0UwQzAPBgNVHRMBAf8EBTADAQEAMA4GA1UdDwEBAAQEAwIDCDAg
BgNVHQ4BAQAEFgQUmx9e7e0EM4Xk97xiPFl1uQvIuzswBQYDK2VwA0EAryMB/t3J5v
/BzKc9dNZIpDmAgs3babFOTQbs+BolzlDUwsPrdGxO3YNGhW7Ibz3OGhhlxXrCe1Cg
w1AH9efZBw==
-----END CERTIFICATE-----
]]></artwork>
</figure>

      </section>

      <section title="Examples of Ed25519 Private Key">
        <t>
          An example of an Ed25519 private key without the public key:
        </t>
    
      <figure>
<artwork><![CDATA[
-----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC
-----END PRIVATE KEY-----
]]></artwork>
      </figure>

      <t>The same item dumped as ASN.1 yields:
      </t>

      <figure><artwork>
 0 30   46: SEQUENCE {
 2 02    1:   INTEGER 0
 5 30    5:   SEQUENCE {
 7 06    3:     OBJECT IDENTIFIER
          :       Ed 25519 signature algorithm { 1 3 101 112 }
          :     }
12 04   34:   OCTET STRING
          :     04 20 D4 EE 72 DB F9 13 58 4A D5 B6 D8 F1 F7 69
          :     F8 AD 3A FE 7C 28 CB F1 D4 FB E0 97 A8 8F 44 75
          :     58 42
          :   }
          </artwork>
      </figure>

      <t>
        Note that the value of the private key is:
      </t>

      <figure><artwork>
D4 EE 72 DB F9 13 58 4A D5 B6 D8 F1 F7 69 F8 AD
3A FE 7C 28 CB F1 D4 FB E0 97 A8 8F 44 75 58 42
</artwork></figure>


        <t>
          An example of the same Ed25519 private key encoded with an attribute and the public key:
        </t>
    
      <figure>
<artwork><![CDATA[
-----BEGIN PRIVATE KEY-----
MHICAQEwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC
oB8wHQYKKoZIhvcNAQkJFDEPDA1DdXJkbGUgQ2hhaXJzgSEAGb9ECWmEzf6FQbrB
Z9w7lshQhqowtrbLDFw4rXAxZuE=
-----END PRIVATE KEY-----
]]></artwork>
      </figure>

      <t>The same item dumped as ASN.1 yields:
      </t>

      <figure><artwork>
  0 114: SEQUENCE {
  2   1:   INTEGER 1
  5   5:   SEQUENCE {
  7   3:     OBJECT IDENTIFIER '1 3 101 112'
       :     }
 12  34:   OCTET STRING, encapsulates {
       :     04 20 D4 EE 72 DB F9 13 58 4A D5 B6 D8 F1 F7 69
       :     F8 AD 3A FE 7C 28 CB F1 D4 FB E0 97 A8 8F 44 75
       :     58 42
       :     }
 48  31:   [0] {
 50  29:     SEQUENCE {
 52  10:       OBJECT IDENTIFIER '1 2 840 113549 1 9 9 20'
 64  15:       SET {
 66  13:         UTF8String 'Curdle Chairs'
       :         }
       :       }
       :     }
81  33:   [1] 00 19 BF 44 09 69 84 CD FE 85 41 BA C1 67 DC 3B
              96 C8 50 86 AA 30 B6 B6 CB 0C 5C 38 AD 70 31 66
              E1
       :   }
          </artwork>
      </figure>

    </section>
  </section>

    <section title="IANA Considerations">

      <t>
      For the ASN.1 module in <xref target="module"/>, IANA has registered
      value 93 for "id-mod-safecurves-pkix" in the "SMI
      Security for PKIX Module Identifier" (1.3.6.1.5.5.7.0) registry.
      </t>

      <t>
	The OIDs are being independently registered in the IANA
	registry "SMI Security for Cryptographic Algorithms" in <xref
	target="RFC8411"/>.
      </t>


    </section>

    <section anchor="Security" title="Security Considerations">

      <t>
        The security considerations of <xref target='RFC5280'/>,
        <xref target="RFC7748"/>, and <xref target="RFC8032"/> apply
        accordingly.
      </t>

      <t>
        The procedures for going from a private key to a public key
        are different when used with Diffie-Hellman versus when used
        with Edwards Signatures.  This means that the same public key
        cannot be used for both ECDH and EdDSA.
      </t>


    </section>

  </middle>

  <back>

    <references title="Normative References">

      &rfc2119;
      &rfc5280;
      &rfc5480;
      &rfc7748;
      &eddsa;
      &rfc5958;
      &rfc8174;

    </references>

    <references title="Informative References">

      &rfc3279;
      &rfc4055;
      &rfc5639;

&rfc7468;
<!--&iana;draft-schaad-curdle-oid-registry-03; in AUTH48 as RFC8411 -->



<reference anchor='RFC8411' target='http://www.rfc-editor.org/info/rfc8411'>
<front>
<title>IANA Registration for the Cryptographic Algorithm Object Identifier Range</title>

<author initials='J' surname='Schaad' fullname='Jim Schaad'>
    <organization />
</author>

<author initials='R' surname='Andrews' fullname='Rick Andrews'>
    <organization />
</author>

<date month='July' year='2018' />

<abstract><t>When the Curdle Security Working Group was chartered, a range of object identifiers was donated by DigiCert, Inc. for the purpose of registering the Edwards Elliptic Curve key agreement and signature algorithms.  This donated set of OIDs allowed for shorter values than would be possible using the existing S/MIME or PKIX arcs.  This document describes the range of identifiers that were assigned in that donated range, transfers control of that range to IANA, and establishes IANA allocation policies for any future assignments within that range.</t></abstract>

</front>

<seriesInfo name='RFC' value='8411' />
<seriesInfo name="DOI" value="10.17487/RFC8411"/>

</reference>


    </references>

    <section title="Invalid Encodings">
      <t>
        There are a number of things that need to be dealt with when a
        new key part is decoded and imported into the system.  A
        partial list of these includes:
        <list style="symbols">

<!--[rfced] Please clarify this sentence. Does it mean the following or otherwise?

Current:
   This was an incorrect copy of the structure from [RFC5958],
   which was corrected before publication.

Perhaps:
  This was a copy of an incorrect structure that was in 
  the Internet-Draft; the structure is correct in [RFC5958]. 

Or:
  This was a copy of incorrect structure that was in a draft 
  of the document that later became [RFC5958]; the structure is 
  correct in the RFC.
-->



          <t>
            ASN.1 encoding errors: Two items are highlighted here.
            First, the use of an OCTET STRING rather than a BIT STRING
            for the public key.  The use of OCTET STRING was a copy error that existed in a previous draft version of this document; the structure is correct in <xref target="RFC5958"/>.  However, any early
            implementation may have this wrong.  Second, the value of
            the version field is required to be 0 if the publicKey is
            absent and 1 if present.  This is called out in <xref
            target="RFC5958"/>, but was not duplicated above.
          </t>
          <t>
            Key encoding errors: Both <xref target="RFC7748"/> and
            <xref target="RFC8032"/> have formatting requirements for
            keys that need to be enforced.  In some cases, the
            enforcement is done at the time of importing, for example,
            doing masking or a mod p operation.  In other cases, the
            enforcement is done by rejecting the keys and having an
            import failure.
          </t>
          <t>
            Key mismatch errors: If a public key is provided, it may
            not agree with the private key because either it is wrong
            or the wrong algorithm was used.
          </t>
        </list>
      </t>

      <t>
        Some systems are also going to be stricter on what they
        accept.  As stated in <xref target="RFC5958"/>, BER decoding
        of OneAsymmetricKey objects is a requirement for compliance.
        Despite this requirement, some acceptors will only decode DER
        formats.  The following is a BER encoding of a private key; 
        it is valid, but it may not be accepted by many systems.
      </t>

      <figure><artwork>
-----BEGIN PRIVATE KEY-----
MIACAQAwgAYDK2VwAAAEIgQg1O5y2/kTWErVttjx92n4rTr+fCjL8dT74Jeoj0R1W
EIAAA==
-----END PRIVATE KEY-----      
      </artwork></figure>



      <t>
        What follows here is a brief sampling of some incorrect keys.
      </t>

      <t>
        In the following example, the private key does not match the
        masking requirements for X25519.  For this example, the top
        bits are set to zero and the bottom three bits are set to 001.
      </t>

      <figure><artwork>
-----BEGIN PRIVATE KEY-----
MFMCAQEwBQYDK2VuBCIEIPj///////////////////////////////////////8/oS
MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg==
-----END PRIVATE KEY-----
      </artwork></figure>

      <t>
        In the following examples, the key is the wrong length because
        an all-zero byte has been removed.  In one case, the first byte
        has been removed; in the other case, the last byte has been
        removed.
      </t>

      <figure><artwork>
-----BEGIN PRIVATE KEY-----
MFICAQEwBQYDK2VwBCIEIC3GfeUYbZGTAhwLEE2cbvJL7ivTlcy17VottfN6L8HwoS
IDIADBfk2Lv/J8H7YYwj/OmIcDx++jzVkKrKwS0/HjyQyM
-----END PRIVATE KEY-----
      </artwork></figure>

      <figure><artwork>
-----BEGIN PRIVATE KEY-----
MFICAQEwBQYDK2VwBCIEILJXn1VaLqvausjUaZexwI/ozmOFjfEk78KcYN+7hsNJoS
IDIACdQhJwzi/MCGcsQeQnIUh2JFybDxSrZxuLudJmpJLk
-----END PRIVATE KEY-----
      </artwork></figure>


    </section>

        <section title="Acknowledgments" numbered="no">

      <t>Text and/or inspiration were drawn from <xref
      target="RFC5280"/>, <xref target="RFC3279"/>, <xref
      target="RFC4055"/>, <xref target="RFC5480"/>, and <xref
      target="RFC5639"/>.</t>

      <t>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, Brian Smith, and Alex Wilson.</t>

      <t>A big thank you to Symantec for kindly donating the OIDs used
      in this document.</t>
      
    </section>
  </back>
</rfc>