idnits 2.17.1 draft-ietf-curdle-pkix-03.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 (November 23, 2016) is 2710 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 511 -- Looks like a reference, but probably isn't: '1' on line 310 -- Looks like a reference, but probably isn't: '3' on line 548 ** Downref: Normative reference to an Informational RFC: RFC 7748 ** Downref: Normative reference to an Informational draft: draft-irtf-cfrg-eddsa (ref. 'I-D.irtf-cfrg-eddsa') 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: May 27, 2017 August Cellars 6 November 23, 2016 8 Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and 9 X448 for use in the Internet X.509 Public Key Infrastructure 10 draft-ietf-curdle-pkix-03 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, 17 Ed25519ph, Ed448 and Ed448ph. The key agreement algorithm covered 18 are X25519 and X448. The encoding for Public Key, Private Key and 19 EdDSA digital signature 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 May 27, 2017. 38 Copyright Notice 40 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . 7 62 8. Human Readable Algorithm Names . . . . . . . . . . . . . . . 8 63 9. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . 8 64 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 10.1. Example Ed25519 Public Key . . . . . . . . . . . . . . . 11 66 10.2. Example X25519 Certificate . . . . . . . . . . . . . . . 11 67 10.3. Example Ed25519 Private Key . . . . . . . . . . . . . . 13 68 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 69 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 70 13. Security Considerations . . . . . . . . . . . . . . . . . . . 14 71 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 73 14.2. Informative References . . . . . . . . . . . . . . . . . 15 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 [I-D.irtf-cfrg-eddsa] the elliptic curve signature system Edwards- 91 curve 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 Ed25519ph and Ed448ph algorithm 95 definitions specify the one-way hash function that is used for pre- 96 hashing. The convention used for identifying the algorithm/curve 97 combinations are to use the Ed25519 and Ed448 for the PureEdDSA mode, 98 with Ed25519ph and Ed448ph for the HashEdDSA mode. The use of the 99 OIDs is described for public keys, private keys and signatures. 101 [I-D.irtf-cfrg-eddsa] additionally defined the concept of a context. 102 Contexts can be used to differentiate signatures generated for 103 different purposes with the same key. The use of contexts is not 104 defined in 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 six new OIDs for identifying the 160 different curve/algorithm pairs. The curves being Curve25519 and 161 Curve448. The algorithms being ECDH, EdDSA in pure mode and EdDSA in 162 pre-hash mode. For all of the OIDs, the parameters MUST be absent. 163 Regardless of the defect in the original 1997 syntax, implementations 164 MUST NOT accept a 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 } 175 id-Ed25519ph OBJECT IDENTIFIER ::= { 1 3 101 114 } 176 id-Ed448ph OBJECT IDENTIFIER ::= { 1 3 101 115 } 178 4. Subject Public Key Fields 180 In the X.509 certificate, the subjectPublicKeyInfo field has the 181 SubjectPublicKeyInfo type, which has the following ASN.1 syntax: 183 SubjectPublicKeyInfo ::= SEQUENCE { 184 algorithm AlgorithmIdentifier, 185 subjectPublicKey BIT STRING 186 } 188 The fields in SubjectPublicKeyInfo have the following meanings: 190 o algorithm is the algorithm identifier and parameters for the 191 public key (see above). 193 o subjectPublicKey contains the byte stream of the public key. 194 While the encoded public keys for the current algorithms are all 195 an even number of octets, future curves could change that. 197 Both [RFC7748] and [I-D.irtf-cfrg-eddsa] define the public key value 198 as being a byte string. It should be noted that the public key is 199 computed differently for each of these documents, thus the same 200 private key will not produce the same public key. 202 The following is an example of a public key encoded using the textual 203 encoding defined in [RFC7468]. 205 -----BEGIN PUBLIC KEY----- 206 MCowBQYDK2VwAyEAGb9ECWmEzf6FQbrBZ9w7lshQhqowtrbLDFw4rXAxZmE= 207 -----END PUBLIC KEY----- 209 5. Key Usage Bits 211 The intended application for the key is indicated in the keyUsage 212 certificate extension. 214 If the keyUsage extension is present in a certificate that indicates 215 id-X25119 or id-X448 in SubjectPublicKeyInfo, then the following MUST 216 be present: 218 keyAgreement; 220 one of the following MAY also be present: 222 encipherOnly; or 223 decipherOnly. 225 If the keyUsage extension is present in an end-entity certificate 226 that indicates id-EdDSA25519, id-EdDSA25519ph, id-EdDSA448 or id- 227 EdDSA448ph , then the keyUsage extension MUST contain one or both of 228 the following values: 230 nonRepudiation; and 231 digitalSignature. 233 If the keyUsage extension is present in a certification authority 234 certificate that indicates id-EdDSA25519 or id-EdDSA448, then the 235 keyUsage extension MUST contain one or more of the following values: 237 nonRepudiation; 238 digitalSignature; 239 keyCertSign; and 240 cRLSign. 242 CAs MUST NOT use the pre-hash versions of the EdDSA algorithms for 243 the creation of certificates or CRLs. This is implied by the fact 244 that those algorithms are not listed in the previous paragraph. 245 Additionally OCSP responders SHOULD NOT use the pre-hash versions of 246 the EdDSA algorithms when generating OCSP responses. No restriction 247 is placed on generation of OCSP requests. 249 AAs MUST NOT use the pre-hash versions of the EdDSA algorithms for 250 the creation of attribute certificates or attribute CRLs [RFC5755]. 252 The decision to require the use of pure mode balances the higher 253 security of having a single failure point againist the possibility 254 that constrained devices, such as Hardware Security Modules (HSMs), 255 may be unable to check signatures on CRLs due to the amount of memory 256 required to hold the entire CRL in memory at one time. This concern 257 can be addressed by CAs using CRL distribution points, combined with 258 segmenting the certificates issued so that the length of any 259 segmented CRL is not "too long" evenif a large percentage of the 260 certificates are revoked. The defintion of "too long" is going to be 261 highly dependent on what constrained device is being used, it can be 262 on the order of single or low double digit kilobytes. 264 6. EdDSA Signatures 266 Signatures can be placed in a number of different ASN.1 structures. 267 The top level structure for a certificate is given below as being 268 illustrative of how signatures are frequently encoded with an 269 algorithm identifier and a location for the signature. 271 Certificate ::= SEQUENCE { 272 tbsCertificate TBSCertificate, 273 signatureAlgorithm AlgorithmIdentifier, 274 signatureValue BIT STRING } 276 The same algorithm identifiers are used for signatures as are used 277 for public keys. When used to identify signature algorithms, the 278 parameters MUST be absent. 280 The data to be signed is prepared for EdDSA. Then, a private key 281 operation is performed to generate the signature value. This value 282 is the opaque value ENC(R) || ENC(S) described in section 3.3 of 283 [I-D.irtf-cfrg-eddsa]. The octet string representing the signature 284 is encoded directly in the BIT STRING without adding any additional 285 ASN.1 wrapping. For the Certificate structure, the signature value 286 is wrapped in the 'signatureValue' BIT STRING field. 288 When the pre-hash versions of the EdDSA signature algorithms are 289 used, the hash function used for the pre-hash is defined by the 290 algorithm. This means that the pre-hash function is implicitly 291 included in the algorithm identifier rather than being explicit as 292 done in [RFC3279]. 294 7. Private Key Format 296 Asymmetric Key Packages [RFC5958] describes how encode a private key 297 in a structure that both identifies what algorithm the private key is 298 for, but allows for the public key and additional attributes about 299 the key to be included as well. For illustration, the ASN.1 300 structure OneAsymmetricKey is replicated below. The algorithm 301 specific details of how a private key is encoded is left for the 302 document describing the algorithm itself. 304 OneAsymmetricKey ::= SEQUENCE { 305 version Version, 306 privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, 307 privateKey PrivateKey, 308 attributes [0] Attributes OPTIONAL, 309 ..., 310 [[2: publicKey [1] PublicKey OPTIONAL ]], 311 ... 312 } 314 PrivateKey ::= OCTET STRING 316 PublicKey ::= OCTET STRING 318 For the keys defined in this document, the private key is always an 319 opaque byte sequence. The ASN.1 type EdPrivateKey is defined in this 320 document to hold the byte sequence. Thus when encoding a 321 OneAsymmetricKey object, the private key is wrapped in an 322 EdPrivateKey object and then placed in the 'privateKey' field. 324 EdPrivateKey ::= OCTET STRING 326 To encode a EdDSA, X25519 or X448 private key, the "privateKey" field 327 will hold the encoded private key. The "privateKeyAlgorithm" field 328 uses the AlgorithmIdentifier structure. The structure is encoded as 329 defined above. If present, the "publicKey" field will hold the 330 encoded key as defined in [RFC7748] and [I-D.irtf-cfrg-eddsa]. 331 public key. 333 The following is an example of a private key encoded using the 334 textual encoding defined in [RFC7468]. 336 -----BEGIN PRIVATE KEY----- 337 MC4CAQAwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC 338 -----END PRIVATE KEY----- 340 8. Human Readable Algorithm Names 342 For the purpose of consistent cross-implementation naming this 343 section establishes human readable names for the algorithms specified 344 in this document. Implementations SHOULD use these names when 345 referring to the algorithms. If there is a strong reason to deviate 346 from these names -- for example, if the implementation has a 347 different naming convention and wants to maintain internal 348 consistency -- it is encouraged to deviate as little as possible from 349 the names given here. 351 Use the string "ECDH" when referring to a public key of type X25519 352 or X448 when the curve is not known or relevant. 354 When the curve is known, use the more specific string of X25519 or 355 X448. 357 Use the string "EdDSA" when referring to a signing public key or 358 signature when the curve is not known or relevant. 360 When the curve is known, use a more specific string. For the id- 361 EdDSA25519 value use the string "Ed25519". For the id-EdDSA25519ph 362 value use the string "Ed25519ph". For id-EdDSA448 use "Ed448". For 363 id-EdDSA448ph use "Ed448ph". 365 9. ASN.1 Module 367 For reference purposes, the ASN.1 syntax is presented as an ASN.1 368 module here. 370 -- ASN.1 Module 372 Safecurves-pkix-0 {1 3 101 120} 374 DEFINITIONS EXPLICIT TAGS ::= 375 BEGIN 377 IMPORTS 378 SIGNATURE-ALGORITHM, KEY-AGREE, PUBLIC-KEY, KEY-WRAP, 379 KeyUsage, AlgorithmIdentifier 380 FROM AlgorithmInformation-2009 381 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 382 mechanisms(5) pkix(7) id-mod(0) 383 id-mod-algorithmInformation-02(58)} 385 mda-sha512 386 FROM PKIX1-PSS-OAEP-Algorithms-2009 387 { iso(1) identified-organization(3) dod(6) internet(1) 388 security(5) mechanisms(5) pkix(7) id-mod(0) 389 id-mod-pkix1-rsa-pkalgs-02(54) } 391 kwa-aes128-wrap, kwa-aes256-wrap 392 FROM CMSAesRsaesOaep-2009 393 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 394 smime(16) modules(0) id-mod-cms-aes-02(38) } 395 ; 397 id-edwards-curve-algs OBJECT IDENTIFIER ::= { 1 3 101 } 399 id-X25519 OBJECT IDENTIFIER ::= { id-edwards-curve-algs 110 } 400 id-X448 OBJECT IDENTIFIER ::= { id-edwards-curve-algs 111 } 401 id-EdDSA25519 OBJECT IDENTIFIER ::= { id-edwards-curve-algs 112 } 402 id-EdDSA25519-ph OBJECT IDENTIFIER ::= { id-edwards-curve-algs 114 } 403 id-EdDSA448 OBJECT IDENTIFIER ::= { id-edwards-curve-algs 113 } 404 id-EdDSA448-ph OBJECT IDENTIFIER ::= { id-edwards-curve-algs 115 } 406 sa-EdDSA25519 SIGNATURE-ALGORITHM ::= { 407 IDENTIFIER id-EdDSA25519 408 PARAMS ARE absent 409 PUBLIC-KEYS {pk-EdDSA25519} 410 SMIME-CAPS { IDENTIFIED BY id-EdDSA25519 } 411 } 413 pk-EdDSA25519 PUBLIC-KEY ::= { 414 IDENTIFIER id-EdDSA25519 415 -- KEY no ASN.1 wrapping -- 416 PARAMS ARE absent 417 CERT-KEY-USAGE {digitalSignature, nonRepudiation, 418 keyCertSign, cRLSign} 419 PRIVATE-KEY EdPrivateKey 420 } 422 sa-EdDSA25519-ph SIGNATURE-ALGORITHM ::= { 423 IDENTIFIER id-EdDSA25519-ph 424 PARAMS ARE absent 425 HASHES { mda-sha512 } 426 PUBLIC-KEYS {pk-EdDSA25519-ph} 427 SMIME-CAPS { IDENTIFIED BY id-EdDSA25519-ph } 428 } 430 pk-EdDSA25519-ph PUBLIC-KEY ::= { 431 IDENTIFIER id-EdDSA25519-ph 432 -- KEY no ASN.1 wrapping -- 433 PARAMS ARE absent 434 CERT-KEY-USAGE {digitalSignature, nonRepudiation} 435 PRIVATE-KEY EdPrivateKey 436 } 438 kaa-X25519 KEY-AGREE ::= { 439 IDENTIFIER id-X25519 440 PARAMS ARE absent 441 PUBLIC-KEYS {pk-X25519} 442 UKM -- TYPE no ASN.1 wrapping -- ARE preferredPresent 443 SMIME-CAPS { 444 TYPE AlgorithmIdentifier{KEY-WRAP, {KeyWrapAlgorithms}} 445 IDENTIFIED BY id-X25519 } 446 } 448 pk-X25519 PUBLIC-KEY ::= { 449 IDENTIFIER id-X25519 450 -- KEY no ASN.1 wrapping -- 451 PARAMS ARE absent 452 CERT-KEY-USAGE { keyAgreement } 453 PRIVATE-KEY EdPrivateKey 454 } 456 KeyWrapAlgorithms KEY-WRAP ::= { 457 kwa-aes128-wrap | kwa-aes256-wrap, 458 ... 459 } 461 kaa-X488 KEY-AGREE ::= { 462 IDENTIFIER id-X448 463 PARAMS ARE absent 464 PUBLIC-KEYS {pk-X448} 465 UKM -- TYPE no ASN.1 wrapping -- ARE preferredPresent 466 SMIME-CAPS { 467 TYPE AlgorithmIdentifier{KEY-WRAP, {KeyWrapAlgorithms}} 468 IDENTIFIED BY id-X448 } 469 } 471 pk-X448 PUBLIC-KEY ::= { 472 IDENTIFIER id-X448 473 -- KEY no ASN.1 wrapping -- 474 PARAMS ARE absent 475 CERT-KEY-USAGE { keyAgreement } 476 PRIVATE-KEY EdPrivateKey 477 } 479 EdPrivateKey ::= OCTET STRING 481 END 483 10. Examples 485 This section contains illustrations of EdDSA public keys and 486 certificates, illustrating parameter choices. 488 10.1. Example Ed25519 Public Key 490 An example of a Ed25519 public key: 492 Public Key Information: 493 Public Key Algorithm: EdDSA25519 494 Algorithm Security Level: High 496 Public Key Usage: 498 Public Key ID: 9b1f5eeded043385e4f7bc623c5975b90bc8bb3b 500 -----BEGIN PUBLIC KEY----- 501 MCowBQYDK2VwAyEAGb9ECWmEzf6FQbrBZ9w7lshQhqowtrbLDFw4rXAxZmE= 502 -----END PUBLIC KEY----- 504 10.2. Example X25519 Certificate 506 An example of a self issued PKIX certificate using Ed25519 to sign a 507 X25519 public key would be: 509 0 300: SEQUENCE { 510 4 223: SEQUENCE { 511 7 3: [0] { 512 9 1: INTEGER 2 513 : } 514 12 8: INTEGER 56 01 47 4A 2A 8D C3 30 515 22 5: SEQUENCE { 516 24 3: OBJECT IDENTIFIER 517 : EdDSA 25519 signature algorithm { 1 3 101 112 } 518 : } 519 29 25: SEQUENCE { 520 31 23: SET { 521 33 21: SEQUENCE { 522 35 3: OBJECT IDENTIFIER commonName (2 5 4 3) 523 40 14: UTF8String 'IETF Test Demo' 524 : } 525 : } 526 : } 527 56 30: SEQUENCE { 528 58 13: UTCTime 01/08/2016 12:19:24 GMT 529 73 13: UTCTime 31/12/2040 23:59:59 GMT 530 : } 531 88 25: SEQUENCE { 532 90 23: SET { 533 92 21: SEQUENCE { 534 94 3: OBJECT IDENTIFIER commonName (2 5 4 3) 535 99 14: UTF8String 'IETF Test Demo' 536 : } 537 : } 538 : } 539 115 42: SEQUENCE { 540 117 5: SEQUENCE { 541 119 3: OBJECT IDENTIFIER 542 : ECDH 25519 key agreement { 1 3 101 110 } 543 : } 544 124 33: BIT STRING 545 : 85 20 F0 09 89 30 A7 54 74 8B 7D DC B4 3E F7 5A 546 : 0D BF 3A 0D 26 38 1A F4 EB A4 A9 8E AA 9B 4E 6A 547 : } 548 159 69: [3] { 549 161 67: SEQUENCE { 550 163 15: SEQUENCE { 551 165 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) 552 170 1: BOOLEAN TRUE 553 173 5: OCTET STRING, encapsulates { 554 175 3: SEQUENCE { 555 177 1: BOOLEAN FALSE 556 : } 557 : } 558 : } 559 180 14: SEQUENCE { 560 182 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) 561 187 1: BOOLEAN FALSE 562 190 4: OCTET STRING, encapsulates { 563 192 2: BIT STRING 3 unused bits 564 : '10000'B (bit 4) 565 : } 566 : } 567 196 32: SEQUENCE { 568 198 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14) 569 203 1: BOOLEAN FALSE 570 206 22: OCTET STRING, encapsulates { 571 208 20: OCTET STRING 572 : 9B 1F 5E ED ED 04 33 85 E4 F7 BC 62 3C 59 75 B9 573 : 0B C8 BB 3B 574 : } 575 : } 576 : } 577 : } 578 : } 579 230 5: SEQUENCE { 580 232 3: OBJECT IDENTIFIER 581 : EdDSA 25519 signature algorithm { 1 3 101 112 } 582 : } 583 237 65: BIT STRING 584 : AF 23 01 FE DD C9 E6 FF C1 CC A7 3D 74 D6 48 A4 585 : 39 80 82 CD DB 69 B1 4E 4D 06 EC F8 1A 25 CE 50 586 : D4 C2 C3 EB 74 6C 4E DD 83 46 85 6E C8 6F 3D CE 587 : 1A 18 65 C5 7A C2 7B 50 A0 C3 50 07 F5 E7 D9 07 588 : } 590 -----BEGIN CERTIFICATE----- 591 MIIBLDCB36ADAgECAghWAUdKKo3DMDAFBgMrZXAwGTEXMBUGA1UEAwwOSUVURiBUZX 592 N0IERlbW8wHhcNMTYwODAxMTIxOTI0WhcNNDAxMjMxMjM1OTU5WjAZMRcwFQYDVQQD 593 DA5JRVRGIFRlc3QgRGVtbzAqMAUGAytlbgMhAIUg8AmJMKdUdIt93LQ+91oNvzoNJj 594 ga9OukqY6qm05qo0UwQzAPBgNVHRMBAf8EBTADAQEAMA4GA1UdDwEBAAQEAwIDCDAg 595 BgNVHQ4BAQAEFgQUmx9e7e0EM4Xk97xiPFl1uQvIuzswBQYDK2VwA0EAryMB/t3J5v 596 /BzKc9dNZIpDmAgs3babFOTQbs+BolzlDUwsPrdGxO3YNGhW7Ibz3OGhhlxXrCe1Cg 597 w1AH9efZBw== 598 -----END CERTIFICATE----- 600 10.3. Example Ed25519 Private Key 602 An example of an Ed25519 private key: 604 -----BEGIN PRIVATE KEY----- 605 MC4CAQAwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC 606 -----END PRIVATE KEY----- 608 11. Acknowledgements 610 Text and/or inspiration were drawn from [RFC5280], [RFC3279], 611 [RFC4055], [RFC5480], and [RFC5639]. 613 The following people discussed the document and provided feedback: 614 Klaus Hartke, Ilari Liusvaara, Erwann Abalea, Rick Andrews, Rob 615 Stradling, James Manger, Nikos Mavrogiannopoulos, Russ Housley, David 616 Benjamin, and Alex Wilson. 618 A big thank you to Symantec for kindly donating the OIDs used in this 619 draft. 621 12. IANA Considerations 623 None. 625 13. Security Considerations 627 The security considerations of [RFC5280], [RFC7748], and 628 [I-D.irtf-cfrg-eddsa] apply accordingly. 630 The procedures for going from a private key to a public key is 631 different for when used with Diffie-Helman and when used with Edwards 632 Signatures. This means that the same public key cannot be used for 633 both ECDH and EdDSA. 635 In the original design of Ed25519 signatures, there was a known 636 attack between the pure and the pre-hash version of the signatures. 637 This has since been corrected in the final version of the design. 638 The initial problem meant that there was a known attack, and 639 therefore a known reason to forbid the use of Ed25519 keys with the 640 Ed25519ph signature scheme and visa versa. With the change in the 641 design this attack has been prevented. This does not mean that the 642 same Ed25519 key should be used with both schemes, there still may be 643 attacks where collisions can be found. For this reason, the same 644 keys are not to be used for the pure and pre-hash versions of the 645 scheme. This applies to both curve 25519 and curve 448. 647 14. References 649 14.1. Normative References 651 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 652 Requirement Levels", BCP 14, RFC 2119, 653 DOI 10.17487/RFC2119, March 1997, 654 . 656 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 657 Housley, R., and W. Polk, "Internet X.509 Public Key 658 Infrastructure Certificate and Certificate Revocation List 659 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 660 . 662 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 663 "Elliptic Curve Cryptography Subject Public Key 664 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 665 . 667 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 668 for Security", RFC 7748, DOI 10.17487/RFC7748, January 669 2016, . 671 [I-D.irtf-cfrg-eddsa] 672 Josefsson, S. and I. Liusvaara, "Edwards-curve Digital 673 Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-08 674 (work in progress), August 2016. 676 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 677 DOI 10.17487/RFC5958, August 2010, 678 . 680 14.2. Informative References 682 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 683 Identifiers for the Internet X.509 Public Key 684 Infrastructure Certificate and Certificate Revocation List 685 (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 686 2002, . 688 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 689 Algorithms and Identifiers for RSA Cryptography for use in 690 the Internet X.509 Public Key Infrastructure Certificate 691 and Certificate Revocation List (CRL) Profile", RFC 4055, 692 DOI 10.17487/RFC4055, June 2005, 693 . 695 [RFC5639] Lochter, M. and J. Merkle, "Elliptic Curve Cryptography 696 (ECC) Brainpool Standard Curves and Curve Generation", 697 RFC 5639, DOI 10.17487/RFC5639, March 2010, 698 . 700 [RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet 701 Attribute Certificate Profile for Authorization", 702 RFC 5755, DOI 10.17487/RFC5755, January 2010, 703 . 705 [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, 706 PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, 707 April 2015, . 709 Authors' Addresses 711 Simon Josefsson 712 SJD AB 714 Email: simon@josefsson.org 715 Jim Schaad 716 August Cellars 718 Email: ietf@augustcellars.com