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