Movatterモバイル変換

<?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<?rfc toc="yes"?><?rfc symrefs="yes"?><rfc category="std"     ipr="trust200902"  <front>    <title abbrev="Safe for X.509">      Algorithm Identifiers for Ed25519, Ed448, and X448 for 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>    <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 constructs using the      curve25519 and curve448 curves.  The signature algorithms      covered are Ed25519 and Ed448.  The key agreement      covered are X25519 and X448.  The encoding for and structures is provided.      </t>    </abstract>  </front>  <middle>    <section title="Introduction">      <t>        In <xref/>, 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 operations.      </t>      <t>        <xref/> 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/> 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 the        PureEdDSA mode without and the HashEdDSA mode        with  The convention used for identifying the        algorithm/curve combinations is to use "Ed25519" and "Ed448"        for the PureEdDSA mode. document does not provide the        conventions needed for the versions of the signature        algorithm.  The use of the OIDs is described for public keys,        private keys and signatures.      </t>      <t>        <xref/> additionally 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>          <t>The current implementations of Ed25519 do not support the          use of if it will potentially delay          the use of these algorithms further.</t>          <t>            EdDSA the only IETF that            currently the use of 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 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 BCP14 <xref /> <xref/> when, and onlywhen, they appear in all capitals, as shown here.      </t>    </section>    <section title="Curve25519 and Curve448 Algorithm Identifiers">      <t>Certificates conforming to <xref/> can      convey a public key for any public key algorithm.  The      certificate indicates the algorithm through an algorithm      identifier. algorithm identifier an OID and 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>        <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 we define four new OIDs for identifying the    different curve/algorithm curves being curve25519 and 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 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 where this is not the problem needs to be    restricted to that subsystem and not to the  </t>      <t>        The same algorithm identifiers are used for identifying a        public key, a private 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>        <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        </t>      </list></t>      <t>        Both <xref/> and <xref/>        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 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/>.</t>      <figure><artwork><![CDATA[-----BEGIN PUBLIC KEY-----MCowBQYDK2VwAyEAGb9ECWmEzf6FQbrBZ9w7lshQhqowtrbLDFw4rXAxZuE=-----END PUBLIC KEY-----]]></artwork>      </figure>    </section>    <section for key certificate 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 3.3 of <xref/>.      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      </t>    </section>    <section title="Private Key Format">      <t>        <xref Key        describes how to encode a private key in a structure that both        identifies what algorithm the private key is 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        details of how a private key is encoded 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 STRINGPublicKey ::= 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. when encoding a OneAsymmetricKey object, the        private key is wrapped in CurvePrivateKey object and        wrapped by the OCTET STRING of the "privateKey" field.      </t>      <figure>      <artwork><![CDATA[CurvePrivateKey ::= OCTET STRING]]></artwork>      </figure>      <t>To encode EdDSA, or X448 private key, the "privateKey"field will hold the encoded private key.  The "privateKeyAlgorithm"field uses the AlgorithmIdentifier structure.  The structure isencoded as defined above.  If present, the "publicKey" field will holdthe encoded key as defined in <xref/> and <xreftarget="RFC8032"/>.      </t>      <t>The following is an example of a private key encoded using      the textual encoding defined in <xref/>.</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/> is used.      </t>      <figure>        <artwork><![CDATA[-----BEGIN PRIVATE KEY-----MHICAQEwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhCoB8wHQYKKoZIhvcNAQkJFDEPDA1DdXJkbGUgQ2hhaXJzgSEAGb9ECWmEzf6FQbrBZ9w7lshQhqowtrbLDFw4rXAxZuE=-----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/>.  This means that they        will not accept a private key structure 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 Algorithm Names">      <t>For the purpose of consistent cross-implementation naming,      this section establishes 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      use    </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 ModuleDEFINITIONS EXPLICIT TAGS ::=BEGINIMPORTS  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 STRINGEND]]></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 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 PKIX certificate using Ed25519 to sign 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 TRUE173   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 FALSE190   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 FALSE206  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-----MIIBLDCB36ADAgECAghWAUdKKo3DMDAFBgMrZXAwGTEXMBUGA1UEAwwOSUVURiBUZXN0IERlbW8wHhcNMTYwODAxMTIxOTI0WhcNNDAxMjMxMjM1OTU5WjAZMRcwFQYDVQQDDA5JRVRGIFRlc3QgRGVtbzAqMAUGAytlbgMhAIUg8AmJMKdUdIt93LQ+91oNvzoNJjga9OukqY6qm05qo0UwQzAPBgNVHRMBAf8EBTADAQEAMA4GA1UdDwEBAAQEAwIDCDAgBgNVHQ4BAQAEFgQUmx9e7e0EM4Xk97xiPFl1uQvIuzswBQYDK2VwA0EAryMB/t3J5v/BzKc9dNZIpDmAgs3babFOTQbs+BolzlDUwsPrdGxO3YNGhW7Ibz3OGhhlxXrCe1Cgw1AH9efZBw==-----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 AD3A 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++CXqI9EdVhCoB8wHQYKKoZIhvcNAQkJFDEPDA1DdXJkbGUgQ2hhaXJzgSEAGb9ECWmEzf6FQbrBZ9w7lshQhqowtrbLDFw4rXAxZuE=-----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> module the "SMI for PKIX Module Identifier"      </t>      <t>The OIDs are being independently registered in the IANAregistry "SMI Security for Cryptographic Algorithms" in <xref      </t>    </section>    <section anchor="Security" title="Security Considerations">      <t>        The security considerations of <xref        <xref/>, and <xref/> apply        accordingly.      </t>      <t>        The procedures for going from a private key to a public key        are different when used with Diffie-Hellman when used        with Edwards Signatures.  This means that the same public key both and      </t>    </section>  </middle>  <back>    <references title="Normative References">      &rfc2119;      &rfc5280;      &rfc5480;      &rfc7748;      &eddsa;      &rfc5958;      &rfc8174;    </references>    <references title="Informative References">      &rfc3279;      &rfc4055;      &rfc5639;&rfc7468;    </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>          <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. was copy of the structure <xref  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 but not duplicated          </t>          <t>            Key encoding errors: Both <xref/> and            <xref/> have formatting requirements for            keys that need to be enforced.  In some the            enforcement is done at the time of importing, for            doing masking or a mod p operation.  In other 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 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/>, 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 is valid, but it may not be accepted by many systems.      </t>      <figure><artwork>-----BEGIN PRIVATE KEY-----MIACAQAwgAYDK2VwAAAEIgQg1O5y2/kTWErVttjx92n4rTr+fCjL8dT74Jeoj0R1WEIAAA==-----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 the top        bits are set to zero and the bottom three bits are set to 001.      </t>      <figure><artwork>-----BEGIN PRIVATE KEY-----MFMCAQEwBQYDK2VuBCIEIPj///////////////////////////////////////8/oSMDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg==-----END PRIVATE KEY-----      </artwork></figure>      <t>        In the following examples, the key is the wrong length because        an byte has been removed.  In one the first byte        has been in the other the last byte has been        removed.      </t>      <figure><artwork>-----BEGIN PRIVATE KEY-----MFICAQEwBQYDK2VwBCIEIC3GfeUYbZGTAhwLEE2cbvJL7ivTlcy17VottfN6L8HwoSIDIADBfk2Lv/J8H7YYwj/OmIcDx++jzVkKrKwS0/HjyQyM-----END PRIVATE KEY-----      </artwork></figure>      <figure><artwork>-----BEGIN PRIVATE KEY-----MFICAQEwBQYDK2VwBCIEILJXn1VaLqvausjUaZexwI/ozmOFjfEk78KcYN+7hsNJoSIDIACdQhJwzi/MCGcsQeQnIUh2JFybDxSrZxuLudJmpJLk-----END PRIVATE KEY-----      </artwork></figure>    </section>  </back></rfc>