idnits 2.17.1 draft-ietf-curdle-pkix-01.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 : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 8 characters in excess of 72. == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 15, 2016) is 2782 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 484 -- Looks like a reference, but probably isn't: '1' on line 283 -- Looks like a reference, but probably isn't: '3' on line 523 == Unused Reference: 'RFC5915' is defined on line 669, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 7748 == Outdated reference: A later version (-08) exists of draft-irtf-cfrg-eddsa-06 ** Downref: Normative reference to an Informational draft: draft-irtf-cfrg-eddsa (ref. 'I-D.irtf-cfrg-eddsa') Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 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: February 16, 2017 August Cellars 6 August 15, 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-01 12 Abstract 14 This document specify algorithm identifiers and ASN.1 encoding 15 formats for Elliptical 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 February 16, 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 . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . 11 67 10.3. Example Ed25519 Private Key . . . . . . . . . . . . . . 13 68 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 69 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 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. A convention has developed that when these two curves 82 are used with the Diffie-Hellman operation, they are referred to as 83 X25519 and X448. 85 In [I-D.irtf-cfrg-eddsa] the elliptic curve signature system EdDSA is 86 described and the recommended choice of curves Ed25519/Ed448 are 87 chosen. EdDSA has defined two modes, the PureEdDSA mode without pre- 88 hashing, and the HashEdDSA mode with pre-hashing. Unlike other 89 digital signature algorithms, the Ed25519ph and Ed448ph algorithm 90 definitions specify the one-way hash function that is used. Attacks 91 have been described when the same key is used with and without pre- 92 hashing for Ed25519, so a single key MUST NOT be used for both modes. 93 The convention used for identifying the algorithm/curve combinations 94 are to use the Ed25519 and Ed448 for the PureEdDSA mode and Ed25519ph 95 and Ed448ph for the HashEdDSA mode. 97 This RFC defines ASN.1 object identifiers for EdDSA for use in the 98 Internet X.509 PKI [RFC5280], and parameters for Ed25519, Ed25519ph, 99 Ed448 and Ed448ph. This document serves a similar role as [RFC3279] 100 does for RSA (and more), [RFC4055] for RSA-OAEP/PSS, and [RFC5758] 101 for SHA2-based (EC)DSA. This document also specify ASN.1 "named 102 curve" object identifiers for Curve25519 and Curve448, similar to 103 what is done in [RFC5639]. This allows the curves to be used and 104 referenced in PKIX standards and software, in particular enabling re- 105 use of existing constructs already defined for ECDSA/ECDH but for the 106 new curves. Similar to [RFC5639], this document does not describe 107 the cryptographic algorithms to be used with the specified parameters 108 nor their application in other standards. 110 2. Requirements Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 3. Curve25519 and Curve448 Algorithm Identifiers 118 Certificates conforming to [RFC5280] can convey a public key for any 119 public key algorithm. The certificate indicates the algorithm 120 through an algorithm identifier. This algorithm identifier is an OID 121 and optionally associated parameters. 123 The AlgorithmIdentifier type, which is included for convenience, is 124 defined as follows: 126 AlgorithmIdentifier ::= SEQUENCE { 127 algorithm OBJECT IDENTIFIER, 128 parameters ANY DEFINED BY algorithm OPTIONAL 129 } 131 The fields in AlgorithmIdentifier have the following meanings: 133 o algorithm identifies the cryptographic algorithm with an object 134 identifier. This is one of the OIDs defined below. 136 o parameters, which are optional, are the associated parameters for 137 the algorithm identifier in the algorithm field. When the 1997 138 syntax for AlgorithmIdentifier was initially defined, it omitted 139 the OPTIONAL key word. The optionality of the parameters field 140 was later recovered via a defect report, but by then many people 141 thought that the field was mandatory. For this reason, a small 142 number of implementations may still require the field to be 143 present. 145 In this document we defined six new OIDs for identifying the 146 different curve/algorithm pairs. The curves being Curve25519 and 147 Curve448. The algorithms being ECDH, EdDSA in pure mode and EdDSA in 148 pre-hash mode. For all of the OIDs, the parameters MUST be absent. 149 Implementations SHOULD NOT accept a parameters value of NULL. 151 The same algorithm identifiers are used for identifying a public key, 152 identifying a private key and identifying a signature (for the four 153 EdDSA related OIDs). Additional encoding information is provided 154 below for each of these locations. 156 id-X25519 OBJECT IDENTIFIER ::= { 1.3.101.110 } 157 id-X448 OBJECT IDENTIFIER ::= { 1.3.101.111 } 158 id-Ed25519 OBJECT IDENTIFIER ::= { 1.3.101.112 } 159 id-Ed448 OBJECT IDENTIFIER ::= { 1.3.101.113 } 160 id-Ed25519ph OBJECT IDENTIFIER ::= { 1.3.101.114 } 161 id-Ed448ph OBJECT IDENTIFIER ::= { 1.3.101.115 } 163 4. Subject Public Key Fields 165 In the X.509 certificate, the subjectPublicKeyInfo field has the 166 SubjectPublicKeyInfo type, which has the following ASN.1 syntax: 168 SubjectPublicKeyInfo ::= SEQUENCE { 169 algorithm AlgorithmIdentifier, 170 subjectPublicKey BIT STRING 171 } 173 The fields in SubjectPublicKeyInfo have the following meanings: 175 o algorithm is the algorithm identifier and parameters for the 176 public key (see above). 178 o subjectPublicKey contains the byte stream of the public key. 179 While the encoded public keys for the current algorithms are all 180 an even number of octets, future curves could change that. 182 Both [RFC7748] and [I-D.irtf-cfrg-eddsa] define the public key value 183 as being a byte string. It should be noted that the public key is 184 computed differently for each of these documents, thus the same 185 private key will not produce the same public key. 187 The following is an example of a public key encoded using the textual 188 encoding defined in [RFC7468]. 190 -----BEGIN PUBLIC KEY----- 191 MCowBQYDK2VwAyEAGb9ECWmEzf6FQbrBZ9w7lshQhqowtrbLDFw4rXAxZmE= 192 -----END PUBLIC KEY----- 194 5. Key Usage Bits 196 The intended application for the key is indicated in the keyUsage 197 certificate extension. 199 If the keyUsage extension is present in a certificate that indicates 200 id-X25119 or id-X448 in SubjectPublicKeyInfo, then the following MUST 201 be present: 203 keyAgreement; 205 one of the following MAY also be present: 207 encipherOnly; or 208 decipherOnly. 210 If the keyUsage extension is present in an end-entity certificate 211 that indicates id-EdDSA25519, id-EdDSA25519ph, id-EdDSA448 or id- 212 EdDSA448ph , then the keyUsage extension MUST contain one or both of 213 the following values: 215 nonRepudiation; and 216 digitalSignature. 218 If the keyUsage extension is present in a certification authority 219 certificate that indicates id-EdDSA25519 or id-EdDSA448, then the 220 keyUsage extension MUST contain one or more of the following values: 222 nonRepudiation; 223 digitalSignature; 224 keyCertSign; and 225 cRLSign. 227 CAs MUST NOT use the pre-hash versions of the EdDSA algorithms for 228 the creation of certificates or CRLs. This is implied by the fact 229 that those algorithms are not listed in the previous paragraph. 230 Additionally OCSP responders SHOULD NOT use the pre-hash versions of 231 the EdDSA algorithms when generating OCSP responses. No restriction 232 is placed on generation of OCSP requests. 234 AAs MUST NOT use the pre-hash versions of the EdDSA algorithms for 235 the creation of attribute certificates or attribute CRLs [RFC5755]. 237 6. EdDSA Signatures 239 Signatures can be placed in a number of different ASN.1 structures. 240 The top level structure for a certificate is given below as being 241 illustrative of how signatures are frequently encoded with an 242 algorithm identifier and a location for the signature. 244 Certificate ::= SEQUENCE { 245 tbsCertificate TBSCertificate, 246 signatureAlgorithm AlgorithmIdentifier, 247 signatureValue BIT STRING } 249 The same algorithm identifiers are used for signatures as are used 250 for public keys. When used to identify signature algorithms, the 251 parameters MUST be absent. 253 The data to be signed is prepared for EdDSA. Then, a private key 254 operation is performed to generate the signature value. This value 255 is the opaque value ENC(R) || ENC(S) described in section 3.3 of 256 [I-D.irtf-cfrg-eddsa]. The octet string representing the signature 257 is encoded directly in the BIT STRING without adding any additional 258 ASN.1 wrapping. For the Certificate structure, the signature value 259 is wrapped in the 'signatureValue' BIT STRING field. 261 When the pre-hash versions of the EdDSA signature algorithms are 262 used, the hash function used for the pre-hash is defined by the 263 algorithm. This means that the pre-hash function is implicitly 264 included in the algorithm identifier rather than being explicit as 265 done in [RFC3279]. 267 7. Private Key Format 269 Asymmetric Key Packages [RFC5958] describes how encode a private key 270 in a structure that both identifies what algorithm the private key is 271 for, but allows for the public key and additional attributes about 272 the key to be included as well. For illustration, the ASN.1 273 structure OneAsymmetricKey is replicated below. The algorithm 274 specific details of how a private key is encoded is left for the 275 document describing the algorithm itself. 277 OneAsymmetricKey ::= SEQUENCE { 278 version Version, 279 privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, 280 privateKey PrivateKey, 281 attributes [0] Attributes OPTIONAL, 282 ..., 283 [[2: publicKey [1] PublicKey OPTIONAL ]], 284 ... 285 } 287 PrivateKey ::= OCTET STRING 289 PublicKey ::= OCTET STRING 291 For the keys defined in this document, the private key is always an 292 opaque byte sequence. The ASN.1 type EdPrivateKey is defined in this 293 document to hold the byte sequence. Thus when encoding a 294 OneAsymmetricKey object, the private key is wrapped in an 295 EdPrivateKey object and then placed in the 'privateKey' field. 297 EdPrivateKey ::= OCTET STRING 299 To encode a EdDSA, X25519 or X448 private key, the "privateKey" field 300 will hold the encoded private key. The "privateKeyAlgorithm" field 301 uses the AlgorithmIdentifier structure. The structure is encoded as 302 defined above. If present, the "publicKey" field will hold the 303 encoded key as defined in [RFC7748] and [I-D.irtf-cfrg-eddsa]. 304 public key. 306 The following is an example of a private key encoded using the 307 textual encoding defined in [RFC7468]. 309 -----BEGIN PRIVATE KEY----- 310 MC4CAQAwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC 311 -----END PRIVATE KEY----- 313 8. Human Readable Algorithm Names 315 For the purpose of consistent cross-implementation naming this 316 section establishes human readable names for the algorithms specified 317 in this document. Implementations SHOULD use these names when 318 referring to the algorithms. If there is a strong reason to deviate 319 from these names -- for example, if the implementation has a 320 different naming convention and wants to maintain internal 321 consistency -- it is encouraged to deviate as little as possible from 322 the names given here. 324 Use the string "ECDH" when referring to a public key of type X25519 325 or X448 when the curve is not known or relevant. 327 When the curve is known, use the more specific string of X25519 or 328 X448. 330 Use the string "EdDSA" when referring to a signing public key or 331 signature when the curve is not known or relevant. 333 When the curve is known, use a more specific string. For the id- 334 EdDSA25519 value use the string "Ed25519". For the id-EdDSA25519ph 335 value use the string "Ed25519ph". For id-EdDSA448 use "Ed448". For 336 id-EdDSA448ph use "Ed448ph". 338 9. ASN.1 Module 340 For reference purposes, the ASN.1 syntax is presented as an ASN.1 341 module here. 343 -- ASN.1 Module 345 Safecurves-pkix-0 {1 3 101 120} 347 DEFINITIONS EXPLICIT TAGS ::= 348 BEGIN 350 IMPORTS 351 SIGNATURE-ALGORITHM, KEY-AGREE, PUBLIC-KEY, KEY-WRAP, 352 KeyUsage, AlgorithmIdentifier 353 FROM AlgorithmInformation-2009 354 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 355 mechanisms(5) pkix(7) id-mod(0) 356 id-mod-algorithmInformation-02(58)} 358 mda-sha512 359 FROM PKIX1-PSS-OAEP-Algorithms-2009 360 { iso(1) identified-organization(3) dod(6) internet(1) 361 security(5) mechanisms(5) pkix(7) id-mod(0) 362 id-mod-pkix1-rsa-pkalgs-02(54) } 364 kwa-aes128-wrap, kwa-aes256-wrap 365 FROM CMSAesRsaesOaep-2009 366 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 367 smime(16) modules(0) id-mod-cms-aes-02(38) } 368 ; 370 id-edwards-curve-algs OBJECT IDENTIFIER ::= { 1 3 101 } 371 id-X25519 OBJECT IDENTIFIER ::= { id-edwards-curve-algs 110 } 372 id-X448 OBJECT IDENTIFIER ::= { id-edwards-curve-algs 111 } 373 id-EdDSA25519 OBJECT IDENTIFIER ::= { id-edwards-curve-algs 112 } 374 id-EdDSA25519-ph OBJECT IDENTIFIER ::= { id-edwards-curve-algs 114 } 375 id-EdDSA448 OBJECT IDENTIFIER ::= { id-edwards-curve-algs 113 } 376 id-EdDSA448-ph OBJECT IDENTIFIER ::= { id-edwards-curve-algs 115 } 378 sa-EdDSA25519 SIGNATURE-ALGORITHM ::= { 379 IDENTIFIER id-EdDSA25519 380 PARAMS ARE absent 381 PUBLIC-KEYS {pk-EdDSA25519} 382 SMIME-CAPS { IDENTIFIED BY id-EdDSA25519 } 383 } 385 pk-EdDSA25519 PUBLIC-KEY ::= { 386 IDENTIFIER id-EdDSA25519 387 -- KEY no ASN.1 wrapping -- 388 PARAMS ARE absent 389 CERT-KEY-USAGE {digitalSignature, nonRepudiation, 390 keyCertSign, cRLSign} 391 PRIVATE-KEY EdPrivateKey 392 } 394 sa-EdDSA25519-ph SIGNATURE-ALGORITHM ::= { 395 IDENTIFIER id-EdDSA25519-ph 396 PARAMS ARE absent 397 HASHES { mda-sha512 } 398 PUBLIC-KEYS {pk-EdDSA25519-ph} 399 SMIME-CAPS { IDENTIFIED BY id-EdDSA25519-ph } 400 } 402 pk-EdDSA25519-ph PUBLIC-KEY ::= { 403 IDENTIFIER id-EdDSA25519-ph 404 -- KEY no ASN.1 wrapping -- 405 PARAMS ARE absent 406 CERT-KEY-USAGE {digitalSignature, nonRepudiation} 407 PRIVATE-KEY EdPrivateKey 408 } 410 kaa-X25519 KEY-AGREE ::= { 411 IDENTIFIER id-X25519 412 PARAMS ARE absent 413 PUBLIC-KEYS {pk-X25519} 414 UKM -- TYPE no ASN.1 wrapping -- ARE preferredPresent 415 SMIME-CAPS { 416 TYPE AlgorithmIdentifier{KEY-WRAP, {KeyWrapAlgorithms}} 417 IDENTIFIED BY id-X25519 } 419 } 421 pk-X25519 PUBLIC-KEY ::= { 422 IDENTIFIER id-X25519 423 -- KEY no ASN.1 wrapping -- 424 PARAMS ARE absent 425 CERT-KEY-USAGE { keyAgreement } 426 PRIVATE-KEY EdPrivateKey 427 } 429 KeyWrapAlgorithms KEY-WRAP ::= { 430 kwa-aes128-wrap | kwa-aes256-wrap, 431 ... 432 } 434 kaa-X488 KEY-AGREE ::= { 435 IDENTIFIER id-X448 436 PARAMS ARE absent 437 PUBLIC-KEYS {pk-X448} 438 UKM -- TYPE no ASN.1 wrapping -- ARE preferredPresent 439 SMIME-CAPS { 440 TYPE AlgorithmIdentifier{KEY-WRAP, {KeyWrapAlgorithms}} 441 IDENTIFIED BY id-X448 } 442 } 444 pk-X448 PUBLIC-KEY ::= { 445 IDENTIFIER id-X448 446 -- KEY no ASN.1 wrapping -- 447 PARAMS ARE absent 448 CERT-KEY-USAGE { keyAgreement } 449 PRIVATE-KEY EdPrivateKey 450 } 452 EdPrivateKey ::= OCTET STRING 454 END 456 10. Examples 458 This section contains illustrations of EdDSA public keys and 459 certificates, illustrating parameter choices. 461 10.1. Example Ed25519 Public Key 463 An example of a Ed25519 public key: 465 Public Key Information: 466 Public Key Algorithm: EdDSA25519 467 Algorithm Security Level: High 469 Public Key Usage: 471 Public Key ID: 9b1f5eeded043385e4f7bc623c5975b90bc8bb3b 473 -----BEGIN PUBLIC KEY----- 474 MCowBQYDK2VwAyEAGb9ECWmEzf6FQbrBZ9w7lshQhqowtrbLDFw4rXAxZmE= 475 -----END PUBLIC KEY----- 477 10.2. Example X25519 Certificate 479 An example of a PKIX certificate using Ed25519 to sign X25519 would 480 be: 482 0 30 300: SEQUENCE { 483 4 30 223: SEQUENCE { 484 7 A0 3: [0] { 485 9 02 1: INTEGER 2 486 : } 487 12 02 8: INTEGER 488 : 56 01 47 4A 2A 8D C3 30 489 22 30 5: SEQUENCE { 490 24 06 3: OBJECT IDENTIFIER 491 : EdDSA 25519 signature algorithm { 1 3 101 112 } 492 : } 493 29 30 25: SEQUENCE { 494 31 31 23: SET { 495 33 30 21: SEQUENCE { 496 35 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 497 40 0C 14: UTF8String (1997) 'IETF Test Demo' 498 : } 499 : } 500 : } 501 56 30 30: SEQUENCE { 502 58 17 13: UTCTime '160801121924Z' 503 73 17 13: UTCTime '401231235959Z' 504 : } 505 88 30 25: SEQUENCE { 506 90 31 23: SET { 507 92 30 21: SEQUENCE { 508 94 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 509 99 0C 14: UTF8String (1997) 'IETF Test Demo' 510 : } 511 : } 512 : } 514 115 30 42: SEQUENCE { 515 117 30 5: SEQUENCE { 516 119 06 3: OBJECT IDENTIFIER 517 : ECDH 25519 key agreement { 1 3 101 110 } 518 : } 519 124 03 33: BIT STRING 0 unused bits 520 : 85 20 F0 09 89 30 A7 54 74 8B 7D DC B4 3E F7 5A 521 : 0D BF 3A 0D 26 38 1A F4 EB A4 A9 8E AA 9B 4E 6A 522 : } 523 159 A3 69: [3] { 524 161 30 67: SEQUENCE { 525 163 30 15: SEQUENCE { 526 165 06 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) 527 170 01 1: BOOLEAN TRUE 528 173 04 5: OCTET STRING, encapsulates { 529 175 30 3: SEQUENCE { 530 177 01 1: BOOLEAN FALSE 531 : } 532 : } 533 : } 534 180 30 14: SEQUENCE { 535 182 06 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) 536 187 01 1: BOOLEAN FALSE 537 190 04 4: OCTET STRING, encapsulates { 538 192 03 2: BIT STRING 7 unused bits 539 : '1'B 540 : } 541 : } 542 196 30 32: SEQUENCE { 543 198 06 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14) 544 203 01 1: BOOLEAN FALSE 545 206 04 22: OCTET STRING 546 : 04 14 9B 1F 5E ED ED 04 33 85 E4 F7 BC 62 3C 59 547 : 75 B9 0B C8 BB 3B 548 : } 549 : } 550 : } 551 : } 552 230 30 5: SEQUENCE { 553 232 06 3: OBJECT IDENTIFIER 554 : EdDSA 25519 signature algorithm { 1 3 101 112 } 555 : } 556 237 03 65: BIT STRING 0 unused bits 557 : D1 EE DF 10 15 68 CA C2 4A C2 13 7F 45 C6 B7 6E 558 : 7C 11 E8 B3 AC D5 67 D3 1A 6E 90 EA 0F 8B F6 50 559 : 0F 91 66 BB EF BE 10 DE FA 37 7B 61 FC D7 C5 C6 560 : AB CF 3F 89 01 F9 BD 80 E8 1B 9D 21 DD 32 73 0A 561 : } 563 -----BEGIN CERTIFICATE----- 564 MIIBLDCB36ADAgECAghWAUdKKo3DMDAFBgMrZXAwGTEXMBUGA1UEAwwOSUVURiBUZXN0IERlbW8wHhcN 565 MTYwODAxMTIxOTI0WhcNNDAxMjMxMjM1OTU5WjAZMRcwFQYDVQQDDA5JRVRGIFRlc3QgRGVtbzAqMAUG 566 AytlbgMhAIUg8AmJMKdUdIt93LQ+91oNvzoNJjga9OukqY6qm05qo0UwQzAPBgNVHRMBAf8EBTADAQEA 567 MA4GA1UdDwEBAAQEAwIHgDAgBgNVHQ4BAQAEFgQUmx9e7e0EM4Xk97xiPFl1uQvIuzswBQYDK2VwA0EA 568 0e7fEBVoysJKwhN/Rca3bnwR6LOs1WfTGm6Q6g+L9lAPkWa7774Q3vo3e2H818XGq88/iQH5vYDoG50h 569 3TJzCg== 570 -----END CERTIFICATE----- 572 10.3. Example Ed25519 Private Key 574 An example of an Ed25519 private key: 576 -----BEGIN PRIVATE KEY----- 577 MC4CAQAwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC 578 -----END PRIVATE KEY----- 580 11. Acknowledgements 582 Text and/or inspiration were drawn from [RFC5280], [RFC3279], 583 [RFC4055], [RFC5480], and [RFC5639]. 585 The following people discussed the document and provided feedback: 586 Klaus Hartke, Ilari Liusvaara, Erwann Abalea, Rick Andrews, Rob 587 Stradling, James Manger, Nikos Mavrogiannopoulos, Russ Housley, and 588 Alex Wilson. 590 A big thank you to Symantec for kindly donating the OIDs used in this 591 draft. 593 12. IANA Considerations 595 None. 597 13. Security Considerations 599 The security considerations of [RFC5280], [RFC7748], and 600 [I-D.irtf-cfrg-eddsa] apply accordingly. 602 A common misconception may be that a Ed25519 public key can be used 603 to create Ed25519ph signatures, or vice versa. This leads to cross- 604 key attacks, and is not permitted. 606 14. References 607 14.1. Normative References 609 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 610 Requirement Levels", BCP 14, RFC 2119, 611 DOI 10.17487/RFC2119, March 1997, 612 . 614 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 615 Housley, R., and W. Polk, "Internet X.509 Public Key 616 Infrastructure Certificate and Certificate Revocation List 617 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 618 . 620 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 621 "Elliptic Curve Cryptography Subject Public Key 622 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 623 . 625 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 626 for Security", RFC 7748, DOI 10.17487/RFC7748, January 627 2016, . 629 [I-D.irtf-cfrg-eddsa] 630 Josefsson, S. and I. Liusvaara, "Edwards-curve Digital 631 Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-06 632 (work in progress), August 2016. 634 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 635 DOI 10.17487/RFC5958, August 2010, 636 . 638 14.2. Informative References 640 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 641 Identifiers for the Internet X.509 Public Key 642 Infrastructure Certificate and Certificate Revocation List 643 (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 644 2002, . 646 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 647 Algorithms and Identifiers for RSA Cryptography for use in 648 the Internet X.509 Public Key Infrastructure Certificate 649 and Certificate Revocation List (CRL) Profile", RFC 4055, 650 DOI 10.17487/RFC4055, June 2005, 651 . 653 [RFC5639] Lochter, M. and J. Merkle, "Elliptic Curve Cryptography 654 (ECC) Brainpool Standard Curves and Curve Generation", 655 RFC 5639, DOI 10.17487/RFC5639, March 2010, 656 . 658 [RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet 659 Attribute Certificate Profile for Authorization", 660 RFC 5755, DOI 10.17487/RFC5755, January 2010, 661 . 663 [RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. 664 Polk, "Internet X.509 Public Key Infrastructure: 665 Additional Algorithms and Identifiers for DSA and ECDSA", 666 RFC 5758, DOI 10.17487/RFC5758, January 2010, 667 . 669 [RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key 670 Structure", RFC 5915, DOI 10.17487/RFC5915, June 2010, 671 . 673 [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, 674 PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, 675 April 2015, . 677 Authors' Addresses 679 Simon Josefsson 680 SJD AB 682 Email: simon@josefsson.org 684 Jim Schaad 685 August Cellars 687 Email: ietf@augustcellars.com