idnits 2.17.1 draft-ietf-curdle-pkix-06.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 (September 12, 2017) is 2389 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 614 -- Looks like a reference, but probably isn't: '1' on line 622 -- Looks like a reference, but probably isn't: '3' on line 515 ** 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: March 16, 2018 August Cellars 6 September 12, 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-06 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 https://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 March 16, 2018. 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 (https://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 . . . . . . . . . . . . . . . 8 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. Examples of Ed25519 Private Key . . . . . . . . . . . . 13 68 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 69 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 70 13. Security Considerations . . . . . . . . . . . . . . . . . . . 14 71 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 14.1. Normative References . . . . . . . . . . . . . . . . . . 15 73 14.2. Informative References . . . . . . . . . . . . . . . . . 15 74 Appendix A. Invalid Encodings . . . . . . . . . . . . . . . . . 16 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 77 1. Introduction 79 In [RFC7748], the elliptic curves curve25519 and curve448 are 80 described. They are designed with performance and security in mind. 81 The curves may be used for Diffie-Hellman and Digital Signature 82 operations. 84 [RFC7748] describes the operations on these curves for the Diffie- 85 Hellman operation. A convention has developed that when these two 86 curves are used with the Diffie-Hellman operation, they are referred 87 to as X25519 and X448. This RFC defines the ASN.1 Object Identifiers 88 (OIDs) for the operations X25519 and X448 along with the parameters. 89 The use of these OIDs is described for public and private keys. 91 In [RFC8032] the elliptic curve signature system Edwards-curve 92 Digital Signature Algorithm (EdDSA) is described along with a 93 recommendation for the use of the curve25519 and curve448. EdDSA has 94 defined two modes, the PureEdDSA mode without pre-hashing, and the 95 HashEdDSA mode with pre-hashing. The convention used for identifying 96 the algorithm/curve combinations are to use the Ed25519 and Ed448 for 97 the PureEdDSA mode. The document does not provide the conventions 98 needed for the pre-hash versions of the signature algorithm. The use 99 of the OIDs is described for public keys, private keys and 100 signatures. 102 [RFC8032] additionally defined the concept of a context. Contexts 103 can be used to differentiate signatures generated for different 104 purposes with the same key. The use of contexts is not defined in 105 this document for the following reasons: 107 o The current implementations of Ed25519 do not support the use of 108 contexts, thus if specified it will potentially delay the use of 109 these algorithms further. 111 o The EdDSA algorithms are the only IETF algorithms that currently 112 support the use of contexts, however there is a possibility that 113 there will be confusion between which algorithms need have 114 separate keys and which do not. This may result in a decrease of 115 security for those other algorithms. 117 o There are still on going discussions among the cryptographic 118 community about how effective the use of contexts is for 119 preventing attacks. 121 o There needs to be discussions about the correct way to identify 122 when context strings are to be used. It is not clear if different 123 OIDs should be used for different contexts, or the OID should 124 merely not that a context string needs to be provided. 126 2. Requirements Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 3. Curve25519 and Curve448 Algorithm Identifiers 134 Certificates conforming to [RFC5280] can convey a public key for any 135 public key algorithm. The certificate indicates the algorithm 136 through an algorithm identifier. This algorithm identifier is an OID 137 and optionally associated parameters. 139 The AlgorithmIdentifier type, which is included for convenience, is 140 defined as follows: 142 AlgorithmIdentifier ::= SEQUENCE { 143 algorithm OBJECT IDENTIFIER, 144 parameters ANY DEFINED BY algorithm OPTIONAL 145 } 147 The fields in AlgorithmIdentifier have the following meanings: 149 o algorithm identifies the cryptographic algorithm with an object 150 identifier. This is one of the OIDs defined below. 152 o parameters, which are optional, are the associated parameters for 153 the algorithm identifier in the algorithm field. When the 1997 154 syntax for AlgorithmIdentifier was initially defined, it omitted 155 the OPTIONAL key word. The optionality of the parameters field 156 was later recovered via a defect report, but by then many people 157 thought that the field was mandatory. For this reason, a small 158 number of implementations may still require the field to be 159 present. 161 In this document we defined four new OIDs for identifying the 162 different curve/algorithm pairs. The curves being curve25519 and 163 curve448. The algorithms being ECDH and EdDSA in pure mode. For all 164 of the OIDs, the parameters MUST be absent. Regardless of the defect 165 in the original 1997 syntax, implementations MUST NOT accept a 166 parameters value of NULL. 168 The same algorithm identifiers are used for identifying a public key, 169 identifying a private key and identifying a signature (for the two 170 EdDSA related OIDs). Additional encoding information is provided 171 below for each of these locations. 173 id-X25519 OBJECT IDENTIFIER ::= { 1 3 101 110 } 174 id-X448 OBJECT IDENTIFIER ::= { 1 3 101 111 } 175 id-Ed25519 OBJECT IDENTIFIER ::= { 1 3 101 112 } 176 id-Ed448 OBJECT IDENTIFIER ::= { 1 3 101 113 } 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. The 194 algorithms defined in this document always encode the public key 195 as an exact multiple of 8-bits. 197 Both [RFC7748] and [RFC8032] define the public key value as being a 198 byte string. It should be noted that the public key is computed 199 differently for each of these documents, thus the same private key 200 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 MCowBQYDK2VwAyEAGb9ECWmEzf6FQbrBZ9w7lshQhqowtrbLDFw4rXAxZuE= 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-X25519 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-Ed25519 or id-Ed448, then the keyUsage extension 227 MUST contain one or both of the following values: 229 nonRepudiation; and 230 digitalSignature. 232 If the keyUsage extension is present in a certification authority 233 certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage 234 extension MUST contain one or more of the following values: 236 nonRepudiation; 237 digitalSignature; 238 keyCertSign; and 239 cRLSign. 241 6. EdDSA Signatures 243 Signatures can be placed in a number of different ASN.1 structures. 244 The top level structure for a certificate is given below as being 245 illustrative of how signatures are frequently encoded with an 246 algorithm identifier and a location for the signature. 248 Certificate ::= SEQUENCE { 249 tbsCertificate TBSCertificate, 250 signatureAlgorithm AlgorithmIdentifier, 251 signatureValue BIT STRING } 253 The same algorithm identifiers are used for signatures as are used 254 for public keys. When used to identify signature algorithms, the 255 parameters MUST be absent. 257 The data to be signed is prepared for EdDSA. Then, a private key 258 operation is performed to generate the signature value. This value 259 is the opaque value ENC(R) || ENC(S) described in section 3.3 of 260 [RFC8032]. The octet string representing the signature is encoded 261 directly in the BIT STRING without adding any additional ASN.1 262 wrapping. For the Certificate structure, the signature value is 263 wrapped in the "signatureValue" BIT STRING field. 265 7. Private Key Format 267 Asymmetric Key Packages [RFC5958] describes how encode a private key 268 in a structure that both identifies what algorithm the private key is 269 for, but allows for the public key and additional attributes about 270 the key to be included as well. For illustration, the ASN.1 271 structure OneAsymmetricKey is replicated below. The algorithm 272 specific details of how a private key is encoded is left for the 273 document describing the algorithm itself. 275 OneAsymmetricKey ::= SEQUENCE { 276 version Version, 277 privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, 278 privateKey PrivateKey, 279 attributes [0] IMPLICIT Attributes OPTIONAL, 280 ..., 281 [[2: publicKey [1] IMPLICIT PublicKey OPTIONAL ]], 282 ... 283 } 285 PrivateKey ::= OCTET STRING 287 PublicKey ::= BIT STRING 289 For the keys defined in this document, the private key is always an 290 opaque byte sequence. The ASN.1 type CurvePrivateKey is defined in 291 this document to hold the byte sequence. Thus when encoding a 292 OneAsymmetricKey object, the private key is wrapped in an 293 CurvePrivateKey object and wrapped by the OCTET STRING of the 294 "privateKey" field. 296 CurvePrivateKey ::= OCTET STRING 298 To encode a EdDSA, X25519 or X448 private key, the "privateKey" field 299 will hold the encoded private key. The "privateKeyAlgorithm" field 300 uses the AlgorithmIdentifier structure. The structure is encoded as 301 defined above. If present, the "publicKey" field will hold the 302 encoded key as defined in [RFC7748] and [RFC8032]. 304 The following is an example of a private key encoded using the 305 textual encoding defined in [RFC7468]. 307 -----BEGIN PRIVATE KEY----- 308 MC4CAQAwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC 309 -----END PRIVATE KEY----- 311 The following example, in addition to encoding the private key, 312 additionally has an attribute included as well as the public key. As 313 with the prior example, the textual encoding defined in [RFC7468] is 314 used. 316 -----BEGIN PRIVATE KEY----- 317 MHICAQEwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC 318 oB8wHQYKKoZIhvcNAQkJFDEPDA1DdXJkbGUgQ2hhaXJzgSEAGb9ECWmEzf6FQbrB 319 Z9w7lshQhqowtrbLDFw4rXAxZuE= 320 -----END PRIVATE KEY------ 321 NOTE: There exist some private key import functions that have not 322 picked up the new ASN.1 structure OneAsymmetricKey that is defined in 323 [RFC7748]. This means that they will not accept a private key 324 structure which contains the public key field. This means a 325 balancing act needs to be done between being able to do a consistency 326 check on the key pair and widest ability to import the key. 328 8. Human Readable Algorithm Names 330 For the purpose of consistent cross-implementation naming this 331 section establishes human readable names for the algorithms specified 332 in this document. Implementations SHOULD use these names when 333 referring to the algorithms. If there is a strong reason to deviate 334 from these names -- for example, if the implementation has a 335 different naming convention and wants to maintain internal 336 consistency -- it is encouraged to deviate as little as possible from 337 the names given here. 339 Use the string "ECDH" when referring to a public key of type X25519 340 or X448 when the curve is not known or relevant. 342 When the curve is known, use the more specific string of X25519 or 343 X448. 345 Use the string "EdDSA" when referring to a signing public key or 346 signature when the curve is not known or relevant. 348 When the curve is known, use a more specific string. For the id- 349 Ed25519 value use the string "Ed25519". For id-Ed448 use "Ed448". 351 9. ASN.1 Module 353 For reference purposes, the ASN.1 syntax is presented as an ASN.1 354 module here. 356 -- ASN.1 Module 358 Safecurves-pkix-0 -- TBD - IANA assigned module OID 360 DEFINITIONS EXPLICIT TAGS ::= 361 BEGIN 363 IMPORTS 364 SIGNATURE-ALGORITHM, KEY-AGREE, PUBLIC-KEY, KEY-WRAP, 365 KeyUsage, AlgorithmIdentifier 366 FROM AlgorithmInformation-2009 367 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 368 mechanisms(5) pkix(7) id-mod(0) 369 id-mod-algorithmInformation-02(58)} 371 mda-sha512 372 FROM PKIX1-PSS-OAEP-Algorithms-2009 373 { iso(1) identified-organization(3) dod(6) internet(1) 374 security(5) mechanisms(5) pkix(7) id-mod(0) 375 id-mod-pkix1-rsa-pkalgs-02(54) } 377 kwa-aes128-wrap, kwa-aes256-wrap 378 FROM CMSAesRsaesOaep-2009 379 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 380 smime(16) modules(0) id-mod-cms-aes-02(38) } 381 ; 383 id-edwards-curve-algs OBJECT IDENTIFIER ::= { 1 3 101 } 385 id-X25519 OBJECT IDENTIFIER ::= { id-edwards-curve-algs 110 } 386 id-X448 OBJECT IDENTIFIER ::= { id-edwards-curve-algs 111 } 387 id-Ed25519 OBJECT IDENTIFIER ::= { id-edwards-curve-algs 112 } 388 id-Ed448 OBJECT IDENTIFIER ::= { id-edwards-curve-algs 113 } 390 sa-Ed25519 SIGNATURE-ALGORITHM ::= { 391 IDENTIFIER id-Ed25519 392 PARAMS ARE absent 393 PUBLIC-KEYS {pk-Ed25519} 394 SMIME-CAPS { IDENTIFIED BY id-Ed25519 } 395 } 397 pk-Ed25519 PUBLIC-KEY ::= { 398 IDENTIFIER id-Ed25519 399 -- KEY no ASN.1 wrapping -- 400 PARAMS ARE absent 401 CERT-KEY-USAGE {digitalSignature, nonRepudiation, 402 keyCertSign, cRLSign} 403 PRIVATE-KEY CurvePrivateKey 404 } 406 kaa-X25519 KEY-AGREE ::= { 407 IDENTIFIER id-X25519 408 PARAMS ARE absent 409 PUBLIC-KEYS {pk-X25519} 410 UKM -- TYPE no ASN.1 wrapping -- ARE preferredPresent 411 SMIME-CAPS { 412 TYPE AlgorithmIdentifier{KEY-WRAP, {KeyWrapAlgorithms}} 413 IDENTIFIED BY id-X25519 } 414 } 415 pk-X25519 PUBLIC-KEY ::= { 416 IDENTIFIER id-X25519 417 -- KEY no ASN.1 wrapping -- 418 PARAMS ARE absent 419 CERT-KEY-USAGE { keyAgreement } 420 PRIVATE-KEY CurvePrivateKey 421 } 423 KeyWrapAlgorithms KEY-WRAP ::= { 424 kwa-aes128-wrap | kwa-aes256-wrap, 425 ... 426 } 428 kaa-X448 KEY-AGREE ::= { 429 IDENTIFIER id-X448 430 PARAMS ARE absent 431 PUBLIC-KEYS {pk-X448} 432 UKM -- TYPE no ASN.1 wrapping -- ARE preferredPresent 433 SMIME-CAPS { 434 TYPE AlgorithmIdentifier{KEY-WRAP, {KeyWrapAlgorithms}} 435 IDENTIFIED BY id-X448 } 436 } 438 pk-X448 PUBLIC-KEY ::= { 439 IDENTIFIER id-X448 440 -- KEY no ASN.1 wrapping -- 441 PARAMS ARE absent 442 CERT-KEY-USAGE { keyAgreement } 443 PRIVATE-KEY CurvePrivateKey 444 } 446 CurvePrivateKey ::= OCTET STRING 448 END 450 10. Examples 452 This section contains illustrations of EdDSA public keys and 453 certificates, illustrating parameter choices. 455 10.1. Example Ed25519 Public Key 457 An example of a Ed25519 public key: 459 Public Key Information: 460 Public Key Algorithm: Ed25519 461 Algorithm Security Level: High 463 Public Key Usage: 465 Public Key ID: 9b1f5eeded043385e4f7bc623c5975b90bc8bb3b 467 -----BEGIN PUBLIC KEY----- 468 MCowBQYDK2VwAyEAGb9ECWmEzf6FQbrBZ9w7lshQhqowtrbLDFw4rXAxZuE= 469 -----END PUBLIC KEY----- 471 10.2. Example X25519 Certificate 473 An example of a self issued PKIX certificate using Ed25519 to sign a 474 X25519 public key would be: 476 0 300: SEQUENCE { 477 4 223: SEQUENCE { 478 7 3: [0] { 479 9 1: INTEGER 2 480 : } 481 12 8: INTEGER 56 01 47 4A 2A 8D C3 30 482 22 5: SEQUENCE { 483 24 3: OBJECT IDENTIFIER 484 : Ed 25519 signature algorithm { 1 3 101 112 } 485 : } 486 29 25: SEQUENCE { 487 31 23: SET { 488 33 21: SEQUENCE { 489 35 3: OBJECT IDENTIFIER commonName (2 5 4 3) 490 40 14: UTF8String 'IETF Test Demo' 491 : } 492 : } 493 : } 494 56 30: SEQUENCE { 495 58 13: UTCTime 01/08/2016 12:19:24 GMT 496 73 13: UTCTime 31/12/2040 23:59:59 GMT 497 : } 498 88 25: SEQUENCE { 499 90 23: SET { 500 92 21: SEQUENCE { 501 94 3: OBJECT IDENTIFIER commonName (2 5 4 3) 502 99 14: UTF8String 'IETF Test Demo' 503 : } 504 : } 505 : } 506 115 42: SEQUENCE { 507 117 5: SEQUENCE { 508 119 3: OBJECT IDENTIFIER 509 : ECDH 25519 key agreement { 1 3 101 110 } 510 : } 511 124 33: BIT STRING 512 : 85 20 F0 09 89 30 A7 54 74 8B 7D DC B4 3E F7 5A 513 : 0D BF 3A 0D 26 38 1A F4 EB A4 A9 8E AA 9B 4E 6A 514 : } 515 159 69: [3] { 516 161 67: SEQUENCE { 517 163 15: SEQUENCE { 518 165 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) 519 170 1: BOOLEAN TRUE 520 173 5: OCTET STRING, encapsulates { 521 175 3: SEQUENCE { 522 177 1: BOOLEAN FALSE 523 : } 524 : } 525 : } 526 180 14: SEQUENCE { 527 182 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) 528 187 1: BOOLEAN FALSE 529 190 4: OCTET STRING, encapsulates { 530 192 2: BIT STRING 3 unused bits 531 : '10000'B (bit 4) 532 : } 533 : } 534 196 32: SEQUENCE { 535 198 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14) 536 203 1: BOOLEAN FALSE 537 206 22: OCTET STRING, encapsulates { 538 208 20: OCTET STRING 539 : 9B 1F 5E ED ED 04 33 85 E4 F7 BC 62 3C 59 75 540 : B9 0B C8 BB 3B 541 : } 542 : } 543 : } 544 : } 545 : } 546 230 5: SEQUENCE { 547 232 3: OBJECT IDENTIFIER 548 : Ed 25519 signature algorithm { 1 3 101 112 } 549 : } 550 237 65: BIT STRING 551 : AF 23 01 FE DD C9 E6 FF C1 CC A7 3D 74 D6 48 A4 552 : 39 80 82 CD DB 69 B1 4E 4D 06 EC F8 1A 25 CE 50 553 : D4 C2 C3 EB 74 6C 4E DD 83 46 85 6E C8 6F 3D CE 554 : 1A 18 65 C5 7A C2 7B 50 A0 C3 50 07 F5 E7 D9 07 555 : } 557 -----BEGIN CERTIFICATE----- 558 MIIBLDCB36ADAgECAghWAUdKKo3DMDAFBgMrZXAwGTEXMBUGA1UEAwwOSUVURiBUZX 559 N0IERlbW8wHhcNMTYwODAxMTIxOTI0WhcNNDAxMjMxMjM1OTU5WjAZMRcwFQYDVQQD 560 DA5JRVRGIFRlc3QgRGVtbzAqMAUGAytlbgMhAIUg8AmJMKdUdIt93LQ+91oNvzoNJj 561 ga9OukqY6qm05qo0UwQzAPBgNVHRMBAf8EBTADAQEAMA4GA1UdDwEBAAQEAwIDCDAg 562 BgNVHQ4BAQAEFgQUmx9e7e0EM4Xk97xiPFl1uQvIuzswBQYDK2VwA0EAryMB/t3J5v 563 /BzKc9dNZIpDmAgs3babFOTQbs+BolzlDUwsPrdGxO3YNGhW7Ibz3OGhhlxXrCe1Cg 564 w1AH9efZBw== 565 -----END CERTIFICATE----- 567 10.3. Examples of Ed25519 Private Key 569 An example of an Ed25519 private key without the public key: 571 -----BEGIN PRIVATE KEY----- 572 MC4CAQAwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC 573 -----END PRIVATE KEY----- 575 The same item dumped as asn1 yields: 577 0 30 46: SEQUENCE { 578 2 02 1: INTEGER 0 579 5 30 5: SEQUENCE { 580 7 06 3: OBJECT IDENTIFIER 581 : Ed 25519 signature algorithm { 1 3 101 112 } 582 : } 583 12 04 34: OCTET STRING 584 : 04 20 D4 EE 72 DB F9 13 58 4A D5 B6 D8 F1 F7 69 585 : F8 AD 3A FE 7C 28 CB F1 D4 FB E0 97 A8 8F 44 75 586 : 58 42 587 : } 589 Note that the value of the private key is: 591 D4 EE 72 DB F9 13 58 4A D5 B6 D8 F1 F7 69 F8 AD 592 3A FE 7C 28 CB F1 D4 FB E0 97 A8 8F 44 75 58 42 594 An example of the same Ed25519 private key encoded with an attribute 595 and the public key: 597 -----BEGIN PRIVATE KEY----- 598 MHICAQEwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC 599 oB8wHQYKKoZIhvcNAQkJFDEPDA1DdXJkbGUgQ2hhaXJzgSEAGb9ECWmEzf6FQbrB 600 Z9w7lshQhqowtrbLDFw4rXAxZuE= 601 -----END PRIVATE KEY----- 602 The same item dumped as asn1 yields: 604 0 114: SEQUENCE { 605 2 1: INTEGER 1 606 5 5: SEQUENCE { 607 7 3: OBJECT IDENTIFIER '1 3 101 112' 608 : } 609 12 34: OCTET STRING, encapsulates { 610 14 32: OCTET STRING D4 EE 72 DB F9 13 58 4A D5 B6 D8 F1 F7 611 69 F8 AD 3A FE 7C 28 CB F1 D4 FB E0 97 A8 8F 44 612 75 58 42 613 : } 614 48 31: [0] { 615 50 29: SEQUENCE { 616 52 10: OBJECT IDENTIFIER '1 2 840 113549 1 9 9 20' 617 64 15: SET { 618 66 13: UTF8String 'Curdle Chairs' 619 : } 620 : } 621 : } 622 81 33: [1] 00 19 BF 44 09 69 84 CD FE 85 41 BA C1 67 DC 3B 623 96 C8 50 86 AA 30 B6 B6 CB 0C 5C 38 AD 70 31 66 624 E1 625 : } 627 11. Acknowledgements 629 Text and/or inspiration were drawn from [RFC5280], [RFC3279], 630 [RFC4055], [RFC5480], and [RFC5639]. 632 The following people discussed the document and provided feedback: 633 Klaus Hartke, Ilari Liusvaara, Erwann Abalea, Rick Andrews, Rob 634 Stradling, James Manger, Nikos Mavrogiannopoulos, Russ Housley, David 635 Benjamin, Brian Smith, and Alex Wilson. 637 A big thank you to Symantec for kindly donating the OIDs used in this 638 draft. 640 12. IANA Considerations 642 IANA is requested to assign a module OID from the "SMI for PKIX 643 Module Identifier" registry for the ASN.1 module in Section 9. 645 13. Security Considerations 647 The security considerations of [RFC5280], [RFC7748], and [RFC8032] 648 apply accordingly. 650 The procedures for going from a private key to a public key are 651 different for when used with Diffie-Hellman and when used with 652 Edwards Signatures. This means that the same public key cannot be 653 used for both ECDH and EdDSA. 655 14. References 657 14.1. Normative References 659 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 660 Requirement Levels", BCP 14, RFC 2119, 661 DOI 10.17487/RFC2119, March 1997, 662 . 664 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 665 Housley, R., and W. Polk, "Internet X.509 Public Key 666 Infrastructure Certificate and Certificate Revocation List 667 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 668 . 670 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 671 "Elliptic Curve Cryptography Subject Public Key 672 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 673 . 675 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 676 DOI 10.17487/RFC5958, August 2010, 677 . 679 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 680 for Security", RFC 7748, DOI 10.17487/RFC7748, January 681 2016, . 683 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 684 Signature Algorithm (EdDSA)", RFC 8032, 685 DOI 10.17487/RFC8032, January 2017, 686 . 688 14.2. Informative References 690 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 691 Identifiers for the Internet X.509 Public Key 692 Infrastructure Certificate and Certificate Revocation List 693 (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 694 2002, . 696 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 697 Algorithms and Identifiers for RSA Cryptography for use in 698 the Internet X.509 Public Key Infrastructure Certificate 699 and Certificate Revocation List (CRL) Profile", RFC 4055, 700 DOI 10.17487/RFC4055, June 2005, 701 . 703 [RFC5639] Lochter, M. and J. Merkle, "Elliptic Curve Cryptography 704 (ECC) Brainpool Standard Curves and Curve Generation", 705 RFC 5639, DOI 10.17487/RFC5639, March 2010, 706 . 708 [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, 709 PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, 710 April 2015, . 712 Appendix A. Invalid Encodings 714 There are a number of things that need to be dealt with when a new 715 key part is decoded and imported into the system. A partial list of 716 these includes: 718 o ASN.1 encoding errors: Two items are highlighted here. First, the 719 use of an OCTET STRING rather than a BIT STRING for the public 720 key. This was an incorrect copy of the structure from [RFC5958] 721 which was corrected before publication. However, any early 722 implementation may have this wrong. Second, the value of the 723 version field is required to be 0 if the publicKey is absent and 1 724 if present. This is called out in [RFC5958] but is not duplicated 725 in the main text. 727 o Key encoding errors: Both [RFC7748] and [RFC8032] have formatting 728 requirements for keys that need to be enforced. In some cases the 729 enforcement is done at the time of importing, for example doing 730 masking or a mod p operation. In other cases the enforcement is 731 done by rejecting the keys and having an import failure. 733 o Key mismatch errors: If a public key is provided, it may not agree 734 with the private key either because it is wrong or the wrong 735 algorithm was used. 737 Some systems are also going to be stricter on what they accept. As 738 stated in [RFC5958], BER decoding of OneAsymmetricKey objects is a 739 requirement for compliance. Despite this requirement, some acceptors 740 will only decode DER formats. The following is a BER encoding of a 741 private key, as such is is valid, but it may not be accepted by many 742 systems. 744 -----BEGIN PRIVATE KEY----- 745 MIACAQAwgAYDK2VwAAAEIgQg1O5y2/kTWErVttjx92n4rTr+fCjL8dT74Jeoj0R1W 746 EIAAA== 747 -----END PRIVATE KEY----- 749 What follows here is a brief sampling of some incorrect keys. 751 In the following example, the private key does not match the masking 752 requirements for X25519. For this example the top bits are set to 753 zero and the bottom three bits are set to 001. 755 -----BEGIN PRIVATE KEY----- 756 MFMCAQEwBQYDK2VuBCIEIPj///////////////////////////////////////8/oS 757 MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg== 758 -----END PRIVATE KEY----- 760 In the following examples, the key is the wrong length because an all 761 zero byte has been removed. In one case the first byte has been 762 removed, in the other case the last byte has been removed. 764 -----BEGIN PRIVATE KEY----- 765 MFICAQEwBQYDK2VwBCIEIC3GfeUYbZGTAhwLEE2cbvJL7ivTlcy17VottfN6L8HwoS 766 IDIADBfk2Lv/J8H7YYwj/OmIcDx++jzVkKrKwS0/HjyQyM 767 -----END PRIVATE KEY----- 769 -----BEGIN PRIVATE KEY----- 770 MFICAQEwBQYDK2VwBCIEILJXn1VaLqvausjUaZexwI/ozmOFjfEk78KcYN+7hsNJoS 771 IDIACdQhJwzi/MCGcsQeQnIUh2JFybDxSrZxuLudJmpJLk 772 -----END PRIVATE KEY----- 774 Authors' Addresses 776 Simon Josefsson 777 SJD AB 779 Email: simon@josefsson.org 781 Jim Schaad 782 August Cellars 784 Email: ietf@augustcellars.com