idnits 2.17.1 draft-ietf-curdle-pkix-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 28, 2017) is 2586 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 460 -- Looks like a reference, but probably isn't: '1' on line 279 -- Looks like a reference, but probably isn't: '3' on line 497 ** Downref: Normative reference to an Informational RFC: RFC 7748 ** Downref: Normative reference to an Informational RFC: RFC 8032 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Josefsson 3 Internet-Draft SJD AB 4 Intended status: Standards Track J. Schaad 5 Expires: September 29, 2017 August Cellars 6 March 28, 2017 8 Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for use in the 9 Internet X.509 Public Key Infrastructure 10 draft-ietf-curdle-pkix-04 12 Abstract 14 This document specifies algorithm identifiers and ASN.1 encoding 15 formats for Elliptic Curve constructs using the Curve25519 and 16 Curve448 curves. The signature algorithms covered are Ed25519 and 17 Ed448. The key agreement algorithm covered are X25519 and X448. The 18 encoding for Public Key, Private Key and EdDSA digital signature 19 structures is provided. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 29, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Terminology . . . . . . . . . . . . . . . . . . 3 57 3. Curve25519 and Curve448 Algorithm Identifiers . . . . . . . . 3 58 4. Subject Public Key Fields . . . . . . . . . . . . . . . . . . 4 59 5. Key Usage Bits . . . . . . . . . . . . . . . . . . . . . . . 5 60 6. EdDSA Signatures . . . . . . . . . . . . . . . . . . . . . . 6 61 7. Private Key Format . . . . . . . . . . . . . . . . . . . . . 6 62 8. Human Readable Algorithm Names . . . . . . . . . . . . . . . 7 63 9. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . 8 64 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 10.1. Example Ed25519 Public Key . . . . . . . . . . . . . . . 10 66 10.2. Example X25519 Certificate . . . . . . . . . . . . . . . 10 67 10.3. Example Ed25519 Private Key . . . . . . . . . . . . . . 12 68 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 69 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 73 14.2. Informative References . . . . . . . . . . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 76 1. Introduction 78 In [RFC7748], the elliptic curves Curve25519 and Curve448 are 79 described. They are designed with performance and security in mind. 80 The curves may be used for Diffie-Hellman and Digital Signature 81 operations. 83 [RFC7748] describes the operations on these curves for the Diffie- 84 Hellman operation. A convention has developed that when these two 85 curves are used with the Diffie-Hellman operation, they are referred 86 to as X25519 and X448. This RFC defines the ASN.1 Object Identifiers 87 (OIDs) for the operations X25519 and X448 along with the parameters. 88 The use of these OIDs is described for public and private keys. 90 In [RFC8032] the elliptic curve signature system Edwards-curve 91 Digital Signature Algorithm (EdDSA) is described along with a 92 recommendation for the use of the Curve25519 and Curve448. EdDSA has 93 defined two modes, the PureEdDSA mode without pre-hashing, and the 94 HashEdDSA mode with pre-hashing. The convention used for identifying 95 the algorithm/curve combinations are to use the Ed25519 and Ed448 for 96 the PureEdDSA mode. The document does not provide the conventions 97 needed for the pre-hash versions of the signature algorithm. The use 98 of the OIDs is described for public keys, private keys and 99 signatures. 101 [RFC8032] additionally defined the concept of a context. Contexts 102 can be used to differentiate signatures generated for different 103 purposes with the same key. The use of contexts is not defined in 104 this document for the following reasons: 106 o The current implementations of Ed25519 do not support the use of 107 contexts, thus if specified it will potentially delay the use of 108 these algorithms further. 110 o The EdDSA algorithms are the only IETF algorithms that currently 111 support the use of contexts, however there is a possibility that 112 there will be confusion between which algorithms need have 113 separate keys and which do not. This may result in a decrease of 114 security for those other algorithms. 116 o There are still on going discussions among the cryptographic 117 community about how effective the use of contexts is for 118 preventing attacks. 120 o There needs to be discussions about the correct way to identify 121 when context strings are to be used. It is not clear if different 122 OIDs should be used for different contexts, or the OID should 123 merely not that a context string needs to be provided. 125 2. Requirements Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 3. Curve25519 and Curve448 Algorithm Identifiers 133 Certificates conforming to [RFC5280] can convey a public key for any 134 public key algorithm. The certificate indicates the algorithm 135 through an algorithm identifier. This algorithm identifier is an OID 136 and optionally associated parameters. 138 The AlgorithmIdentifier type, which is included for convenience, is 139 defined as follows: 141 AlgorithmIdentifier ::= SEQUENCE { 142 algorithm OBJECT IDENTIFIER, 143 parameters ANY DEFINED BY algorithm OPTIONAL 144 } 145 The fields in AlgorithmIdentifier have the following meanings: 147 o algorithm identifies the cryptographic algorithm with an object 148 identifier. This is one of the OIDs defined below. 150 o parameters, which are optional, are the associated parameters for 151 the algorithm identifier in the algorithm field. When the 1997 152 syntax for AlgorithmIdentifier was initially defined, it omitted 153 the OPTIONAL key word. The optionality of the parameters field 154 was later recovered via a defect report, but by then many people 155 thought that the field was mandatory. For this reason, a small 156 number of implementations may still require the field to be 157 present. 159 In this document we defined four new OIDs for identifying the 160 different curve/algorithm pairs. The curves being Curve25519 and 161 Curve448. The algorithms being ECDH and EdDSA in pure mode. For all 162 of the OIDs, the parameters MUST be absent. Regardless of the defect 163 in the original 1997 syntax, implementations MUST NOT accept a 164 parameters value of NULL. 166 The same algorithm identifiers are used for identifying a public key, 167 identifying a private key and identifying a signature (for the four 168 EdDSA related OIDs). Additional encoding information is provided 169 below for each of these locations. 171 id-X25519 OBJECT IDENTIFIER ::= { 1 3 101 110 } 172 id-X448 OBJECT IDENTIFIER ::= { 1 3 101 111 } 173 id-Ed25519 OBJECT IDENTIFIER ::= { 1 3 101 112 } 174 id-Ed448 OBJECT IDENTIFIER ::= { 1 3 101 113 } 176 4. Subject Public Key Fields 178 In the X.509 certificate, the subjectPublicKeyInfo field has the 179 SubjectPublicKeyInfo type, which has the following ASN.1 syntax: 181 SubjectPublicKeyInfo ::= SEQUENCE { 182 algorithm AlgorithmIdentifier, 183 subjectPublicKey BIT STRING 184 } 186 The fields in SubjectPublicKeyInfo have the following meanings: 188 o algorithm is the algorithm identifier and parameters for the 189 public key (see above). 191 o subjectPublicKey contains the byte stream of the public key. 192 While the encoded public keys for the current algorithms are all 193 an even number of octets, future curves could change that. 195 Both [RFC7748] and [RFC8032] define the public key value as being a 196 byte string. It should be noted that the public key is computed 197 differently for each of these documents, thus the same private key 198 will not produce the same public key. 200 The following is an example of a public key encoded using the textual 201 encoding defined in [RFC7468]. 203 -----BEGIN PUBLIC KEY----- 204 MCowBQYDK2VwAyEAGb9ECWmEzf6FQbrBZ9w7lshQhqowtrbLDFw4rXAxZuE= 205 -----END PUBLIC KEY----- 207 5. Key Usage Bits 209 The intended application for the key is indicated in the keyUsage 210 certificate extension. 212 If the keyUsage extension is present in a certificate that indicates 213 id-X25119 or id-X448 in SubjectPublicKeyInfo, then the following MUST 214 be present: 216 keyAgreement; 218 one of the following MAY also be present: 220 encipherOnly; or 221 decipherOnly. 223 If the keyUsage extension is present in an end-entity certificate 224 that indicates id-EdDSA25519 or id-EdDSA448, then the keyUsage 225 extension MUST contain one or both of the following values: 227 nonRepudiation; and 228 digitalSignature. 230 If the keyUsage extension is present in a certification authority 231 certificate that indicates id-EdDSA25519 or id-EdDSA448, then the 232 keyUsage extension MUST contain one or more of the following values: 234 nonRepudiation; 235 digitalSignature; 236 keyCertSign; and 237 cRLSign. 239 6. EdDSA Signatures 241 Signatures can be placed in a number of different ASN.1 structures. 242 The top level structure for a certificate is given below as being 243 illustrative of how signatures are frequently encoded with an 244 algorithm identifier and a location for the signature. 246 Certificate ::= SEQUENCE { 247 tbsCertificate TBSCertificate, 248 signatureAlgorithm AlgorithmIdentifier, 249 signatureValue BIT STRING } 251 The same algorithm identifiers are used for signatures as are used 252 for public keys. When used to identify signature algorithms, the 253 parameters MUST be absent. 255 The data to be signed is prepared for EdDSA. Then, a private key 256 operation is performed to generate the signature value. This value 257 is the opaque value ENC(R) || ENC(S) described in section 3.3 of 258 [RFC8032]. The octet string representing the signature is encoded 259 directly in the BIT STRING without adding any additional ASN.1 260 wrapping. For the Certificate structure, the signature value is 261 wrapped in the 'signatureValue' BIT STRING field. 263 7. Private Key Format 265 Asymmetric Key Packages [RFC5958] describes how encode a private key 266 in a structure that both identifies what algorithm the private key is 267 for, but allows for the public key and additional attributes about 268 the key to be included as well. For illustration, the ASN.1 269 structure OneAsymmetricKey is replicated below. The algorithm 270 specific details of how a private key is encoded is left for the 271 document describing the algorithm itself. 273 OneAsymmetricKey ::= SEQUENCE { 274 version Version, 275 privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, 276 privateKey PrivateKey, 277 attributes [0] Attributes OPTIONAL, 278 ..., 279 [[2: publicKey [1] PublicKey OPTIONAL ]], 280 ... 281 } 283 PrivateKey ::= OCTET STRING 285 PublicKey ::= OCTET STRING 286 For the keys defined in this document, the private key is always an 287 opaque byte sequence. The ASN.1 type CurvePrivateKey is defined in 288 this document to hold the byte sequence. Thus when encoding a 289 OneAsymmetricKey object, the private key is wrapped in an 290 CurvePrivateKey object and wrapped by the OCTET STRING of the 291 'privateKey' field. 293 CurvePrivateKey ::= OCTET STRING 295 To encode a EdDSA, X25519 or X448 private key, the "privateKey" field 296 will hold the encoded private key. The "privateKeyAlgorithm" field 297 uses the AlgorithmIdentifier structure. The structure is encoded as 298 defined above. If present, the "publicKey" field will hold the 299 encoded key as defined in [RFC7748] and [RFC8032]. public key. 301 The following is an example of a private key encoded using the 302 textual encoding defined in [RFC7468]. 304 -----BEGIN PRIVATE KEY----- 305 MC4CAQAwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC 306 -----END PRIVATE KEY----- 308 8. Human Readable Algorithm Names 310 For the purpose of consistent cross-implementation naming this 311 section establishes human readable names for the algorithms specified 312 in this document. Implementations SHOULD use these names when 313 referring to the algorithms. If there is a strong reason to deviate 314 from these names -- for example, if the implementation has a 315 different naming convention and wants to maintain internal 316 consistency -- it is encouraged to deviate as little as possible from 317 the names given here. 319 Use the string "ECDH" when referring to a public key of type X25519 320 or X448 when the curve is not known or relevant. 322 When the curve is known, use the more specific string of X25519 or 323 X448. 325 Use the string "EdDSA" when referring to a signing public key or 326 signature when the curve is not known or relevant. 328 When the curve is known, use a more specific string. For the id- 329 EdDSA25519 value use the string "Ed25519". For id-EdDSA448 use 330 "Ed448". 332 9. ASN.1 Module 334 For reference purposes, the ASN.1 syntax is presented as an ASN.1 335 module here. 337 -- ASN.1 Module 339 Safecurves-pkix-0 {1 3 101 120} 341 DEFINITIONS EXPLICIT TAGS ::= 342 BEGIN 344 IMPORTS 345 SIGNATURE-ALGORITHM, KEY-AGREE, PUBLIC-KEY, KEY-WRAP, 346 KeyUsage, AlgorithmIdentifier 347 FROM AlgorithmInformation-2009 348 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 349 mechanisms(5) pkix(7) id-mod(0) 350 id-mod-algorithmInformation-02(58)} 352 mda-sha512 353 FROM PKIX1-PSS-OAEP-Algorithms-2009 354 { iso(1) identified-organization(3) dod(6) internet(1) 355 security(5) mechanisms(5) pkix(7) id-mod(0) 356 id-mod-pkix1-rsa-pkalgs-02(54) } 358 kwa-aes128-wrap, kwa-aes256-wrap 359 FROM CMSAesRsaesOaep-2009 360 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 361 smime(16) modules(0) id-mod-cms-aes-02(38) } 362 ; 364 id-edwards-curve-algs OBJECT IDENTIFIER ::= { 1 3 101 } 366 id-X25519 OBJECT IDENTIFIER ::= { id-edwards-curve-algs 110 } 367 id-X448 OBJECT IDENTIFIER ::= { id-edwards-curve-algs 111 } 368 id-EdDSA25519 OBJECT IDENTIFIER ::= { id-edwards-curve-algs 112 } 369 id-EdDSA448 OBJECT IDENTIFIER ::= { id-edwards-curve-algs 113 } 371 sa-EdDSA25519 SIGNATURE-ALGORITHM ::= { 372 IDENTIFIER id-EdDSA25519 373 PARAMS ARE absent 374 PUBLIC-KEYS {pk-EdDSA25519} 375 SMIME-CAPS { IDENTIFIED BY id-EdDSA25519 } 376 } 377 pk-EdDSA25519 PUBLIC-KEY ::= { 378 IDENTIFIER id-EdDSA25519 379 -- KEY no ASN.1 wrapping -- 380 PARAMS ARE absent 381 CERT-KEY-USAGE {digitalSignature, nonRepudiation, 382 keyCertSign, cRLSign} 383 PRIVATE-KEY CurvePrivateKey 384 } 386 kaa-X25519 KEY-AGREE ::= { 387 IDENTIFIER id-X25519 388 PARAMS ARE absent 389 PUBLIC-KEYS {pk-X25519} 390 UKM -- TYPE no ASN.1 wrapping -- ARE preferredPresent 391 SMIME-CAPS { 392 TYPE AlgorithmIdentifier{KEY-WRAP, {KeyWrapAlgorithms}} 393 IDENTIFIED BY id-X25519 } 394 } 396 pk-X25519 PUBLIC-KEY ::= { 397 IDENTIFIER id-X25519 398 -- KEY no ASN.1 wrapping -- 399 PARAMS ARE absent 400 CERT-KEY-USAGE { keyAgreement } 401 PRIVATE-KEY CurvePrivateKey 402 } 404 KeyWrapAlgorithms KEY-WRAP ::= { 405 kwa-aes128-wrap | kwa-aes256-wrap, 406 ... 407 } 409 kaa-X488 KEY-AGREE ::= { 410 IDENTIFIER id-X448 411 PARAMS ARE absent 412 PUBLIC-KEYS {pk-X448} 413 UKM -- TYPE no ASN.1 wrapping -- ARE preferredPresent 414 SMIME-CAPS { 415 TYPE AlgorithmIdentifier{KEY-WRAP, {KeyWrapAlgorithms}} 416 IDENTIFIED BY id-X448 } 417 } 419 pk-X448 PUBLIC-KEY ::= { 420 IDENTIFIER id-X448 421 -- KEY no ASN.1 wrapping -- 422 PARAMS ARE absent 423 CERT-KEY-USAGE { keyAgreement } 424 PRIVATE-KEY CurvePrivateKey 426 } 428 CurvePrivateKey ::= OCTET STRING 430 END 432 10. Examples 434 This section contains illustrations of EdDSA public keys and 435 certificates, illustrating parameter choices. 437 10.1. Example Ed25519 Public Key 439 An example of a Ed25519 public key: 441 Public Key Information: 442 Public Key Algorithm: EdDSA25519 443 Algorithm Security Level: High 445 Public Key Usage: 447 Public Key ID: 9b1f5eeded043385e4f7bc623c5975b90bc8bb3b 449 -----BEGIN PUBLIC KEY----- 450 MCowBQYDK2VwAyEAGb9ECWmEzf6FQbrBZ9w7lshQhqowtrbLDFw4rXAxZuE= 451 -----END PUBLIC KEY----- 453 10.2. Example X25519 Certificate 455 An example of a self issued PKIX certificate using Ed25519 to sign a 456 X25519 public key would be: 458 0 300: SEQUENCE { 459 4 223: SEQUENCE { 460 7 3: [0] { 461 9 1: INTEGER 2 462 : } 463 12 8: INTEGER 56 01 47 4A 2A 8D C3 30 464 22 5: SEQUENCE { 465 24 3: OBJECT IDENTIFIER 466 : EdDSA 25519 signature algorithm { 1 3 101 112 } 467 : } 468 29 25: SEQUENCE { 469 31 23: SET { 470 33 21: SEQUENCE { 471 35 3: OBJECT IDENTIFIER commonName (2 5 4 3) 472 40 14: UTF8String 'IETF Test Demo' 473 : } 474 : } 475 : } 476 56 30: SEQUENCE { 477 58 13: UTCTime 01/08/2016 12:19:24 GMT 478 73 13: UTCTime 31/12/2040 23:59:59 GMT 479 : } 480 88 25: SEQUENCE { 481 90 23: SET { 482 92 21: SEQUENCE { 483 94 3: OBJECT IDENTIFIER commonName (2 5 4 3) 484 99 14: UTF8String 'IETF Test Demo' 485 : } 486 : } 487 : } 488 115 42: SEQUENCE { 489 117 5: SEQUENCE { 490 119 3: OBJECT IDENTIFIER 491 : ECDH 25519 key agreement { 1 3 101 110 } 492 : } 493 124 33: BIT STRING 494 : 85 20 F0 09 89 30 A7 54 74 8B 7D DC B4 3E F7 5A 495 : 0D BF 3A 0D 26 38 1A F4 EB A4 A9 8E AA 9B 4E 6A 496 : } 497 159 69: [3] { 498 161 67: SEQUENCE { 499 163 15: SEQUENCE { 500 165 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) 501 170 1: BOOLEAN TRUE 502 173 5: OCTET STRING, encapsulates { 503 175 3: SEQUENCE { 504 177 1: BOOLEAN FALSE 505 : } 506 : } 507 : } 508 180 14: SEQUENCE { 509 182 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) 510 187 1: BOOLEAN FALSE 511 190 4: OCTET STRING, encapsulates { 512 192 2: BIT STRING 3 unused bits 513 : '10000'B (bit 4) 514 : } 515 : } 516 196 32: SEQUENCE { 517 198 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14) 518 203 1: BOOLEAN FALSE 519 206 22: OCTET STRING, encapsulates { 520 208 20: OCTET STRING 521 : 9B 1F 5E ED ED 04 33 85 E4 F7 BC 62 3C 59 75 522 : B9 0B C8 BB 3B 523 : } 524 : } 525 : } 526 : } 527 : } 528 230 5: SEQUENCE { 529 232 3: OBJECT IDENTIFIER 530 : EdDSA 25519 signature algorithm { 1 3 101 112 } 531 : } 532 237 65: BIT STRING 533 : AF 23 01 FE DD C9 E6 FF C1 CC A7 3D 74 D6 48 A4 534 : 39 80 82 CD DB 69 B1 4E 4D 06 EC F8 1A 25 CE 50 535 : D4 C2 C3 EB 74 6C 4E DD 83 46 85 6E C8 6F 3D CE 536 : 1A 18 65 C5 7A C2 7B 50 A0 C3 50 07 F5 E7 D9 07 537 : } 539 -----BEGIN CERTIFICATE----- 540 MIIBLDCB36ADAgECAghWAUdKKo3DMDAFBgMrZXAwGTEXMBUGA1UEAwwOSUVURiBUZX 541 N0IERlbW8wHhcNMTYwODAxMTIxOTI0WhcNNDAxMjMxMjM1OTU5WjAZMRcwFQYDVQQD 542 DA5JRVRGIFRlc3QgRGVtbzAqMAUGAytlbgMhAIUg8AmJMKdUdIt93LQ+91oNvzoNJj 543 ga9OukqY6qm05qo0UwQzAPBgNVHRMBAf8EBTADAQEAMA4GA1UdDwEBAAQEAwIDCDAg 544 BgNVHQ4BAQAEFgQUmx9e7e0EM4Xk97xiPFl1uQvIuzswBQYDK2VwA0EAryMB/t3J5v 545 /BzKc9dNZIpDmAgs3babFOTQbs+BolzlDUwsPrdGxO3YNGhW7Ibz3OGhhlxXrCe1Cg 546 w1AH9efZBw== 547 -----END CERTIFICATE----- 549 10.3. Example Ed25519 Private Key 551 An example of an Ed25519 private key: 553 -----BEGIN PRIVATE KEY----- 554 MC4CAQAwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC 555 -----END PRIVATE KEY----- 557 The same item dumped as asn1 yields: 559 0 30 46: SEQUENCE { 560 2 02 1: INTEGER 0 561 5 30 5: SEQUENCE { 562 7 06 3: OBJECT IDENTIFIER 563 : EdDSA 25519 signature algorithm { 1 3 101 112 } 564 : } 565 12 04 34: OCTET STRING 566 : 04 20 D4 EE 72 DB F9 13 58 4A D5 B6 D8 F1 F7 69 567 : F8 AD 3A FE 7C 28 CB F1 D4 FB E0 97 A8 8F 44 75 568 : 58 42 569 : } 571 Note that the value of the private key is: 573 D4 EE 72 DB F9 13 58 4A D5 B6 D8 F1 F7 69 F8 AD 574 3A FE 7C 28 CB F1 D4 FB E0 97 A8 8F 44 75 58 42 576 11. Acknowledgements 578 Text and/or inspiration were drawn from [RFC5280], [RFC3279], 579 [RFC4055], [RFC5480], and [RFC5639]. 581 The following people discussed the document and provided feedback: 582 Klaus Hartke, Ilari Liusvaara, Erwann Abalea, Rick Andrews, Rob 583 Stradling, James Manger, Nikos Mavrogiannopoulos, Russ Housley, David 584 Benjamin, and Alex Wilson. 586 A big thank you to Symantec for kindly donating the OIDs used in this 587 draft. 589 12. IANA Considerations 591 None. 593 13. Security Considerations 595 The security considerations of [RFC5280], [RFC7748], and [RFC8032] 596 apply accordingly. 598 The procedures for going from a private key to a public key is 599 different for when used with Diffie-Helman and when used with Edwards 600 Signatures. This means that the same public key cannot be used for 601 both ECDH and EdDSA. 603 14. References 605 14.1. Normative References 607 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 608 Requirement Levels", BCP 14, RFC 2119, 609 DOI 10.17487/RFC2119, March 1997, 610 . 612 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 613 Housley, R., and W. Polk, "Internet X.509 Public Key 614 Infrastructure Certificate and Certificate Revocation List 615 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 616 . 618 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 619 "Elliptic Curve Cryptography Subject Public Key 620 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 621 . 623 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 624 for Security", RFC 7748, DOI 10.17487/RFC7748, January 625 2016, . 627 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 628 Signature Algorithm (EdDSA)", RFC 8032, 629 DOI 10.17487/RFC8032, January 2017, 630 . 632 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 633 DOI 10.17487/RFC5958, August 2010, 634 . 636 14.2. Informative References 638 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 639 Identifiers for the Internet X.509 Public Key 640 Infrastructure Certificate and Certificate Revocation List 641 (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 642 2002, . 644 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 645 Algorithms and Identifiers for RSA Cryptography for use in 646 the Internet X.509 Public Key Infrastructure Certificate 647 and Certificate Revocation List (CRL) Profile", RFC 4055, 648 DOI 10.17487/RFC4055, June 2005, 649 . 651 [RFC5639] Lochter, M. and J. Merkle, "Elliptic Curve Cryptography 652 (ECC) Brainpool Standard Curves and Curve Generation", 653 RFC 5639, DOI 10.17487/RFC5639, March 2010, 654 . 656 [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, 657 PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, 658 April 2015, . 660 Authors' Addresses 662 Simon Josefsson 663 SJD AB 665 Email: simon@josefsson.org 667 Jim Schaad 668 August Cellars 670 Email: ietf@augustcellars.com