diff --git a/.github/workflows/workspace.yml b/.github/workflows/workspace.yml index afbbf1304..7391786bf 100644 --- a/.github/workflows/workspace.yml +++ b/.github/workflows/workspace.yml @@ -25,7 +25,7 @@ jobs: components: clippy override: true profile: minimal - - run: cargo clippy --all-features + - run: cargo clippy doc: runs-on: ubuntu-latest diff --git a/Cargo.lock b/Cargo.lock index 8df39fae8..196c364d4 100644 --- a/Cargo.lock +++ b/Cargo.lock @@ -227,7 +227,7 @@ dependencies = [ [[package]] name = "const-oid" -version = "0.9.4" +version = "0.9.5" dependencies = [ "arbitrary", "hex-literal", diff --git a/const-oid/CHANGELOG.md b/const-oid/CHANGELOG.md index 51eed1e72..d6e604dfd 100644 --- a/const-oid/CHANGELOG.md +++ b/const-oid/CHANGELOG.md @@ -4,6 +4,12 @@ All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). +## 0.9.5 (2023-08-02) +### Added +- rfc8410 (curve25519) OIDS. ([#867]) + +[#867]: https://github.com/RustCrypto/formats/pull/867 + ## 0.9.4 (2023-07-10) ### Added - rfc8894 (SCEP) OIDs. ([#1114]) diff --git a/const-oid/Cargo.toml b/const-oid/Cargo.toml index 4f48a7561..90b6ad09e 100644 --- a/const-oid/Cargo.toml +++ b/const-oid/Cargo.toml @@ -1,6 +1,6 @@ [package] name = "const-oid" -version = "0.9.4" +version = "0.9.5" authors = ["RustCrypto Developers"] license = "Apache-2.0 OR MIT" description = """ diff --git a/const-oid/oiddbgen/rfc8410.txt b/const-oid/oiddbgen/rfc8410.txt new file mode 100644 index 000000000..2c4b96331 --- /dev/null +++ b/const-oid/oiddbgen/rfc8410.txt @@ -0,0 +1,1123 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Josefsson +Request for Comments: 8410 SJD AB +Category: Standards Track J. Schaad +ISSN: 2070-1721 August Cellars + August 2018 + + + Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 + for Use in the Internet X.509 Public Key Infrastructure + +Abstract + + This document specifies algorithm identifiers and ASN.1 encoding + formats for elliptic curve constructs using the curve25519 and + curve448 curves. The signature algorithms covered are Ed25519 and + Ed448. The key agreement algorithms covered are X25519 and X448. + The encoding for public key, private key, and Edwards-curve Digital + Signature Algorithm (EdDSA) structures is provided. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8410. + +Copyright Notice + + Copyright (c) 2018 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + +Josefsson & Schaad Standards Track [Page 1] + +RFC 8410 Safe Curves for X.509 August 2018 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Requirements Terminology . . . . . . . . . . . . . . . . . . 3 + 3. Curve25519 and Curve448 Algorithm Identifiers . . . . . . . . 3 + 4. Subject Public Key Fields . . . . . . . . . . . . . . . . . . 4 + 5. Key Usage Bits . . . . . . . . . . . . . . . . . . . . . . . 5 + 6. EdDSA Signatures . . . . . . . . . . . . . . . . . . . . . . 6 + 7. Private Key Format . . . . . . . . . . . . . . . . . . . . . 7 + 8. Human-Readable Algorithm Names . . . . . . . . . . . . . . . 8 + 9. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . 9 + 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 10.1. Example Ed25519 Public Key . . . . . . . . . . . . . . . 11 + 10.2. Example X25519 Certificate . . . . . . . . . . . . . . . 12 + 10.3. Examples of Ed25519 Private Key . . . . . . . . . . . . 14 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 12. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 + 13.2. Informative References . . . . . . . . . . . . . . . . . 16 + Appendix A. Invalid Encodings . . . . . . . . . . . . . . . . . 18 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 + +1. Introduction + + In [RFC7748], the elliptic curves curve25519 and curve448 are + described. They are designed with performance and security in mind. + The curves may be used for Diffie-Hellman and digital signature + operations. + + [RFC7748] describes the operations on these curves for the Diffie- + Hellman operation. A convention has developed that when these two + curves are used with the Diffie-Hellman operation, they are referred + to as X25519 and X448. This RFC defines the ASN.1 Object Identifiers + (OIDs) for the operations X25519 and X448 along with the associated + parameters. The use of these OIDs is described for public and + private keys. + + In [RFC8032] the elliptic curve signature system Edwards-curve + Digital Signature Algorithm (EdDSA) is described along with a + recommendation for the use of the curve25519 and curve448. EdDSA has + defined two modes: the PureEdDSA mode without prehashing and the + HashEdDSA mode with prehashing. The convention used for identifying + the algorithm/curve combinations is to use "Ed25519" and "Ed448" for + the PureEdDSA mode. This document does not provide the conventions + + + + + +Josefsson & Schaad Standards Track [Page 2] + +RFC 8410 Safe Curves for X.509 August 2018 + + + needed for the prehash versions of the signature algorithm. The use + of the OIDs is described for public keys, private keys and + signatures. + + [RFC8032] additionally defines the concept of a context. Contexts + can be used to differentiate signatures generated for different + purposes with the same key. The use of contexts is not defined in + this document for the following reasons: + + o The current implementations of Ed25519 do not support the use of + contexts; thus, if specified, it will potentially delay the use of + these algorithms further. + + o EdDSA is the only IETF algorithm that currently supports the use + of contexts; however, there is a possibility that there will be + confusion between which algorithms need to have separate keys and + which do not. This may result in a decrease of security for those + other algorithms. + + o There are still ongoing discussions among the cryptographic + community about how effective the use of contexts is for + preventing attacks. + + o There needs to be discussions about the correct way to identify + when context strings are to be used. It is not clear if different + OIDs should be used for different contexts or the OID should + merely note that a context string needs to be provided. + +2. Requirements Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +3. Curve25519 and Curve448 Algorithm Identifiers + + Certificates conforming to [RFC5280] can convey a public key for any + public key algorithm. The certificate indicates the algorithm + through an algorithm identifier. An algorithm identifier consists of + an OID and optional parameters. + + + + + + + + + +Josefsson & Schaad Standards Track [Page 3] + +RFC 8410 Safe Curves for X.509 August 2018 + + + The AlgorithmIdentifier type, which is included for convenience, is + defined as follows: + + AlgorithmIdentifier ::= SEQUENCE { + algorithm OBJECT IDENTIFIER, + parameters ANY DEFINED BY algorithm OPTIONAL + } + + The fields in AlgorithmIdentifier have the following meanings: + + o algorithm identifies the cryptographic algorithm with an object + identifier. Four such OIDs are defined below. + + o parameters, which are optional, are the associated parameters for + the algorithm identifier in the algorithm field. + + In this document, we define four new OIDs for identifying the + different curve/algorithm pairs: the curves being curve25519 and + curve448 and the algorithms being ECDH and EdDSA in pure mode. For + all of the OIDs, the parameters MUST be absent. + + It is possible to find systems that require the parameters to be + present. This can be due to either a defect in the original 1997 + syntax or a programming error where developers never got input where + this was not true. The optimal solution is to fix these systems; + where this is not possible, the problem needs to be restricted to + that subsystem and not propagated to the Internet. + + The same algorithm identifiers are used for identifying a public key, + a private key, and a signature (for the two EdDSA related OIDs). + Additional encoding information is provided below for each of these + locations. + + id-X25519 OBJECT IDENTIFIER ::= { 1 3 101 110 } + id-X448 OBJECT IDENTIFIER ::= { 1 3 101 111 } + id-Ed25519 OBJECT IDENTIFIER ::= { 1 3 101 112 } + id-Ed448 OBJECT IDENTIFIER ::= { 1 3 101 113 } + +4. Subject Public Key Fields + + In the X.509 certificate, the subjectPublicKeyInfo field has the + SubjectPublicKeyInfo type, which has the following ASN.1 syntax: + + SubjectPublicKeyInfo ::= SEQUENCE { + algorithm AlgorithmIdentifier, + subjectPublicKey BIT STRING + } + + + + +Josefsson & Schaad Standards Track [Page 4] + +RFC 8410 Safe Curves for X.509 August 2018 + + + The fields in SubjectPublicKeyInfo have the following meanings: + + o algorithm is the algorithm identifier and parameters for the + public key (see above). + + o subjectPublicKey contains the byte stream of the public key. The + algorithms defined in this document always encode the public key + as an exact multiple of 8 bits. + + Both [RFC7748] and [RFC8032] define the public key value as being a + byte string. It should be noted that the public key is computed + differently for each of these documents; thus, the same private key + will not produce the same public key. + + The following is an example of a public key encoded using the textual + encoding defined in [RFC7468]. + + -----BEGIN PUBLIC KEY----- + MCowBQYDK2VwAyEAGb9ECWmEzf6FQbrBZ9w7lshQhqowtrbLDFw4rXAxZuE= + -----END PUBLIC KEY----- + +5. Key Usage Bits + + The intended application for the key is indicated in the keyUsage + certificate extension. + + If the keyUsage extension is present in a certificate that indicates + id-X25519 or id-X448 in SubjectPublicKeyInfo, then the following MUST + be present: + + keyAgreement; + + one of the following MAY also be present: + + encipherOnly; or + decipherOnly. + + If the keyUsage extension is present in an end-entity certificate + that indicates id-Ed25519 or id-Ed448, then the keyUsage extension + MUST contain one or both of the following values: + + nonRepudiation; and + digitalSignature. + + + + + + + + +Josefsson & Schaad Standards Track [Page 5] + +RFC 8410 Safe Curves for X.509 August 2018 + + + If the keyUsage extension is present in a certification authority + certificate that indicates id-Ed25519 or id-Ed448, then the keyUsage + extension MUST contain one or more of the following values: + + nonRepudiation; + digitalSignature; + keyCertSign; and + cRLSign. + +6. EdDSA Signatures + + Signatures can be placed in a number of different ASN.1 structures. + The top level structure for a certificate is given below as being + illustrative of how signatures are frequently encoded with an + algorithm identifier and a location for the signature. + + Certificate ::= SEQUENCE { + tbsCertificate TBSCertificate, + signatureAlgorithm AlgorithmIdentifier, + signatureValue BIT STRING } + + The same algorithm identifiers are used for signatures as are used + for public keys. When used to identify signature algorithms, the + parameters MUST be absent. + + The data to be signed is prepared for EdDSA. Then, a private key + operation is performed to generate the signature value. This value + is the opaque value ENC(R) || ENC(S) described in Section 3.3 of + [RFC8032]. The octet string representing the signature is encoded + directly in the BIT STRING without adding any additional ASN.1 + wrapping. For the Certificate structure, the signature value is + wrapped in the "signatureValue" BIT STRING field. + + + + + + + + + + + + + + + + + + + +Josefsson & Schaad Standards Track [Page 6] + +RFC 8410 Safe Curves for X.509 August 2018 + + +7. Private Key Format + + "Asymmetric Key Packages" [RFC5958] describes how to encode a private + key in a structure that both identifies what algorithm the private + key is for and allows for the public key and additional attributes + about the key to be included as well. For illustration, the ASN.1 + structure OneAsymmetricKey is replicated below. The algorithm- + specific details of how a private key is encoded are left for the + document describing the algorithm itself. + + OneAsymmetricKey ::= SEQUENCE { + version Version, + privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, + privateKey PrivateKey, + attributes [0] IMPLICIT Attributes OPTIONAL, + ..., + [[2: publicKey [1] IMPLICIT PublicKey OPTIONAL ]], + ... + } + + PrivateKey ::= OCTET STRING + + PublicKey ::= BIT STRING + + For the keys defined in this document, the private key is always an + opaque byte sequence. The ASN.1 type CurvePrivateKey is defined in + this document to hold the byte sequence. Thus, when encoding a + OneAsymmetricKey object, the private key is wrapped in a + CurvePrivateKey object and wrapped by the OCTET STRING of the + "privateKey" field. + + CurvePrivateKey ::= OCTET STRING + + To encode an EdDSA, X25519, or X448 private key, the "privateKey" + field will hold the encoded private key. The "privateKeyAlgorithm" + field uses the AlgorithmIdentifier structure. The structure is + encoded as defined above. If present, the "publicKey" field will + hold the encoded key as defined in [RFC7748] and [RFC8032]. + + + + + + + + + + + + + +Josefsson & Schaad Standards Track [Page 7] + +RFC 8410 Safe Curves for X.509 August 2018 + + + The following is an example of a private key encoded using the + textual encoding defined in [RFC7468]. + + -----BEGIN PRIVATE KEY----- + MC4CAQAwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC + -----END PRIVATE KEY----- + + The following example, in addition to encoding the private key, has + an attribute included as well as the public key. As with the prior + example, the textual encoding defined in [RFC7468] is used. + + -----BEGIN PRIVATE KEY----- + MHICAQEwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC + oB8wHQYKKoZIhvcNAQkJFDEPDA1DdXJkbGUgQ2hhaXJzgSEAGb9ECWmEzf6FQbrB + Z9w7lshQhqowtrbLDFw4rXAxZuE= + -----END PRIVATE KEY------ + + NOTE: There exist some private key import functions that have not + picked up the new ASN.1 structure OneAsymmetricKey that is defined in + [RFC7748]. This means that they will not accept a private key + structure that contains the public key field. This means a balancing + act needs to be done between being able to do a consistency check on + the key pair and widest ability to import the key. + +8. Human-Readable Algorithm Names + + For the purpose of consistent cross-implementation naming, this + section establishes human-readable names for the algorithms specified + in this document. Implementations SHOULD use these names when + referring to the algorithms. If there is a strong reason to deviate + from these names -- for example, if the implementation has a + different naming convention and wants to maintain internal + consistency -- it is encouraged to deviate as little as possible from + the names given here. + + Use the string "ECDH" when referring to a public key of type "X25519" + or "X448" when the curve is not known or relevant. + + When the curve is known, use the more specific string of "X25519" or + "X448". + + Use the string "EdDSA" when referring to a signing public key or + signature when the curve is not known or relevant. + + When the curve is known, use a more specific string. For the id- + Ed25519 value use the string "Ed25519". For id-Ed448, use "Ed448". + + + + + +Josefsson & Schaad Standards Track [Page 8] + +RFC 8410 Safe Curves for X.509 August 2018 + + +9. ASN.1 Module + + For reference purposes, the ASN.1 syntax is presented as an ASN.1 + module here. + + -- ASN.1 Module + + Safecurves-pkix-18 + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-safecurves-pkix(93) } + + DEFINITIONS EXPLICIT TAGS ::= + BEGIN + + IMPORTS + SIGNATURE-ALGORITHM, KEY-AGREE, PUBLIC-KEY, KEY-WRAP, + KeyUsage, AlgorithmIdentifier + FROM AlgorithmInformation-2009 + {iso(1) identified-organization(3) dod(6) internet(1) security(5) + mechanisms(5) pkix(7) id-mod(0) + id-mod-algorithmInformation-02(58)} + + mda-sha512 + FROM PKIX1-PSS-OAEP-Algorithms-2009 + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-pkix1-rsa-pkalgs-02(54) } + + kwa-aes128-wrap, kwa-aes256-wrap + FROM CMSAesRsaesOaep-2009 + { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) + smime(16) modules(0) id-mod-cms-aes-02(38) } + ; + + + id-edwards-curve-algs OBJECT IDENTIFIER ::= { 1 3 101 } + + id-X25519 OBJECT IDENTIFIER ::= { id-edwards-curve-algs 110 } + id-X448 OBJECT IDENTIFIER ::= { id-edwards-curve-algs 111 } + id-Ed25519 OBJECT IDENTIFIER ::= { id-edwards-curve-algs 112 } + id-Ed448 OBJECT IDENTIFIER ::= { id-edwards-curve-algs 113 } + + + + + + + + + +Josefsson & Schaad Standards Track [Page 9] + +RFC 8410 Safe Curves for X.509 August 2018 + + + sa-Ed25519 SIGNATURE-ALGORITHM ::= { + IDENTIFIER id-Ed25519 + PARAMS ARE absent + PUBLIC-KEYS {pk-Ed25519} + SMIME-CAPS { IDENTIFIED BY id-Ed25519 } + } + + pk-Ed25519 PUBLIC-KEY ::= { + IDENTIFIER id-Ed25519 + -- KEY no ASN.1 wrapping -- + PARAMS ARE absent + CERT-KEY-USAGE {digitalSignature, nonRepudiation, + keyCertSign, cRLSign} + PRIVATE-KEY CurvePrivateKey + } + + kaa-X25519 KEY-AGREE ::= { + IDENTIFIER id-X25519 + PARAMS ARE absent + PUBLIC-KEYS {pk-X25519} + UKM -- TYPE no ASN.1 wrapping -- ARE preferredPresent + SMIME-CAPS { + TYPE AlgorithmIdentifier{KEY-WRAP, {KeyWrapAlgorithms}} + IDENTIFIED BY id-X25519 } + } + + pk-X25519 PUBLIC-KEY ::= { + IDENTIFIER id-X25519 + -- KEY no ASN.1 wrapping -- + PARAMS ARE absent + CERT-KEY-USAGE { keyAgreement } + PRIVATE-KEY CurvePrivateKey + } + + KeyWrapAlgorithms KEY-WRAP ::= { + kwa-aes128-wrap | kwa-aes256-wrap, + ... + } + + kaa-X448 KEY-AGREE ::= { + IDENTIFIER id-X448 + PARAMS ARE absent + PUBLIC-KEYS {pk-X448} + UKM -- TYPE no ASN.1 wrapping -- ARE preferredPresent + SMIME-CAPS { + TYPE AlgorithmIdentifier{KEY-WRAP, {KeyWrapAlgorithms}} + IDENTIFIED BY id-X448 } + } + + + +Josefsson & Schaad Standards Track [Page 10] + +RFC 8410 Safe Curves for X.509 August 2018 + + + pk-X448 PUBLIC-KEY ::= { + IDENTIFIER id-X448 + -- KEY no ASN.1 wrapping -- + PARAMS ARE absent + CERT-KEY-USAGE { keyAgreement } + PRIVATE-KEY CurvePrivateKey + } + + CurvePrivateKey ::= OCTET STRING + + + END + +10. Examples + + This section contains illustrations of EdDSA public keys and + certificates, illustrating parameter choices. + +10.1. Example Ed25519 Public Key + + An example of an Ed25519 public key: + + Public Key Information: + Public Key Algorithm: Ed25519 + Algorithm Security Level: High + + Public Key Usage: + + Public Key ID: 9b1f5eeded043385e4f7bc623c5975b90bc8bb3b + + -----BEGIN PUBLIC KEY----- + MCowBQYDK2VwAyEAGb9ECWmEzf6FQbrBZ9w7lshQhqowtrbLDFw4rXAxZuE= + -----END PUBLIC KEY----- + + + + + + + + + + + + + + + + + + +Josefsson & Schaad Standards Track [Page 11] + +RFC 8410 Safe Curves for X.509 August 2018 + + +10.2. Example X25519 Certificate + + An example of a self-issued PKIX certificate using Ed25519 to sign an + X25519 public key would be: + + 0 300: SEQUENCE { + 4 223: SEQUENCE { + 7 3: [0] { + 9 1: INTEGER 2 + : } + 12 8: INTEGER 56 01 47 4A 2A 8D C3 30 + 22 5: SEQUENCE { + 24 3: OBJECT IDENTIFIER + : Ed 25519 signature algorithm { 1 3 101 112 } + : } + 29 25: SEQUENCE { + 31 23: SET { + 33 21: SEQUENCE { + 35 3: OBJECT IDENTIFIER commonName (2 5 4 3) + 40 14: UTF8String 'IETF Test Demo' + : } + : } + : } + 56 30: SEQUENCE { + 58 13: UTCTime 01/08/2016 12:19:24 GMT + 73 13: UTCTime 31/12/2040 23:59:59 GMT + : } + 88 25: SEQUENCE { + 90 23: SET { + 92 21: SEQUENCE { + 94 3: OBJECT IDENTIFIER commonName (2 5 4 3) + 99 14: UTF8String 'IETF Test Demo' + : } + : } + : } + 115 42: SEQUENCE { + 117 5: SEQUENCE { + 119 3: OBJECT IDENTIFIER + : ECDH 25519 key agreement { 1 3 101 110 } + : } + 124 33: BIT STRING + : 85 20 F0 09 89 30 A7 54 74 8B 7D DC B4 3E F7 5A + : 0D BF 3A 0D 26 38 1A F4 EB A4 A9 8E AA 9B 4E 6A + : } + 159 69: [3] { + 161 67: SEQUENCE { + 163 15: SEQUENCE { + 165 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) + + + +Josefsson & Schaad Standards Track [Page 12] + +RFC 8410 Safe Curves for X.509 August 2018 + + + 170 1: BOOLEAN TRUE + 173 5: OCTET STRING, encapsulates { + 175 3: SEQUENCE { + 177 1: BOOLEAN FALSE + : } + : } + : } + 180 14: SEQUENCE { + 182 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) + 187 1: BOOLEAN FALSE + 190 4: OCTET STRING, encapsulates { + 192 2: BIT STRING 3 unused bits + : '10000'B (bit 4) + : } + : } + 196 32: SEQUENCE { + 198 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14) + 203 1: BOOLEAN FALSE + 206 22: OCTET STRING, encapsulates { + 208 20: OCTET STRING + : 9B 1F 5E ED ED 04 33 85 E4 F7 BC 62 3C 59 75 + : B9 0B C8 BB 3B + : } + : } + : } + : } + : } + 230 5: SEQUENCE { + 232 3: OBJECT IDENTIFIER + : Ed 25519 signature algorithm { 1 3 101 112 } + : } + 237 65: BIT STRING + : AF 23 01 FE DD C9 E6 FF C1 CC A7 3D 74 D6 48 A4 + : 39 80 82 CD DB 69 B1 4E 4D 06 EC F8 1A 25 CE 50 + : D4 C2 C3 EB 74 6C 4E DD 83 46 85 6E C8 6F 3D CE + : 1A 18 65 C5 7A C2 7B 50 A0 C3 50 07 F5 E7 D9 07 + : } + + -----BEGIN CERTIFICATE----- + MIIBLDCB36ADAgECAghWAUdKKo3DMDAFBgMrZXAwGTEXMBUGA1UEAwwOSUVURiBUZX + N0IERlbW8wHhcNMTYwODAxMTIxOTI0WhcNNDAxMjMxMjM1OTU5WjAZMRcwFQYDVQQD + DA5JRVRGIFRlc3QgRGVtbzAqMAUGAytlbgMhAIUg8AmJMKdUdIt93LQ+91oNvzoNJj + ga9OukqY6qm05qo0UwQzAPBgNVHRMBAf8EBTADAQEAMA4GA1UdDwEBAAQEAwIDCDAg + BgNVHQ4BAQAEFgQUmx9e7e0EM4Xk97xiPFl1uQvIuzswBQYDK2VwA0EAryMB/t3J5v + /BzKc9dNZIpDmAgs3babFOTQbs+BolzlDUwsPrdGxO3YNGhW7Ibz3OGhhlxXrCe1Cg + w1AH9efZBw== + -----END CERTIFICATE----- + + + + +Josefsson & Schaad Standards Track [Page 13] + +RFC 8410 Safe Curves for X.509 August 2018 + + +10.3. Examples of Ed25519 Private Key + + An example of an Ed25519 private key without the public key: + + -----BEGIN PRIVATE KEY----- + MC4CAQAwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC + -----END PRIVATE KEY----- + + The same item dumped as ASN.1 yields: + + 0 30 46: SEQUENCE { + 2 02 1: INTEGER 0 + 5 30 5: SEQUENCE { + 7 06 3: OBJECT IDENTIFIER + : Ed 25519 signature algorithm { 1 3 101 112 } + : } + 12 04 34: OCTET STRING + : 04 20 D4 EE 72 DB F9 13 58 4A D5 B6 D8 F1 F7 69 + : F8 AD 3A FE 7C 28 CB F1 D4 FB E0 97 A8 8F 44 75 + : 58 42 + : } + + Note that the value of the private key is: + + D4 EE 72 DB F9 13 58 4A D5 B6 D8 F1 F7 69 F8 AD + 3A FE 7C 28 CB F1 D4 FB E0 97 A8 8F 44 75 58 42 + + An example of the same Ed25519 private key encoded with an attribute + and the public key: + + -----BEGIN PRIVATE KEY----- + MHICAQEwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC + oB8wHQYKKoZIhvcNAQkJFDEPDA1DdXJkbGUgQ2hhaXJzgSEAGb9ECWmEzf6FQbrB + Z9w7lshQhqowtrbLDFw4rXAxZuE= + -----END PRIVATE KEY----- + + + + + + + + + + + + + + + + +Josefsson & Schaad Standards Track [Page 14] + +RFC 8410 Safe Curves for X.509 August 2018 + + + The same item dumped as ASN.1 yields: + + 0 114: SEQUENCE { + 2 1: INTEGER 1 + 5 5: SEQUENCE { + 7 3: OBJECT IDENTIFIER '1 3 101 112' + : } + 12 34: OCTET STRING, encapsulates { + : 04 20 D4 EE 72 DB F9 13 58 4A D5 B6 D8 F1 F7 69 + : F8 AD 3A FE 7C 28 CB F1 D4 FB E0 97 A8 8F 44 75 + : 58 42 + : } + 48 31: [0] { + 50 29: SEQUENCE { + 52 10: OBJECT IDENTIFIER '1 2 840 113549 1 9 9 20' + 64 15: SET { + 66 13: UTF8String 'Curdle Chairs' + : } + : } + : } + 81 33: [1] 00 19 BF 44 09 69 84 CD FE 85 41 BA C1 67 DC 3B + 96 C8 50 86 AA 30 B6 B6 CB 0C 5C 38 AD 70 31 66 + E1 + : } + +11. IANA Considerations + + For the ASN.1 module in Section 9, IANA has registered value 93 for + "id-mod-safecurves-pkix" in the "SMI Security for PKIX Module + Identifier" (1.3.6.1.5.5.7.0) registry. + + The OIDs are being independently registered in the IANA registry "SMI + Security for Cryptographic Algorithms" in [RFC8411]. + +12. Security Considerations + + The security considerations of [RFC5280], [RFC7748], and [RFC8032] + apply accordingly. + + The procedures for going from a private key to a public key are + different when used with Diffie-Hellman versus when used with Edwards + Signatures. This means that the same public key cannot be used for + both ECDH and EdDSA. + + + + + + + + +Josefsson & Schaad Standards Track [Page 15] + +RFC 8410 Safe Curves for X.509 August 2018 + + +13. References + +13.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, + . + + [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, + "Elliptic Curve Cryptography Subject Public Key + Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, + . + + [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, + DOI 10.17487/RFC5958, August 2010, + . + + [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves + for Security", RFC 7748, DOI 10.17487/RFC7748, January + 2016, . + + [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital + Signature Algorithm (EdDSA)", RFC 8032, + DOI 10.17487/RFC8032, January 2017, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + +13.2. Informative References + + [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and + Identifiers for the Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April + 2002, . + + + + + + + +Josefsson & Schaad Standards Track [Page 16] + +RFC 8410 Safe Curves for X.509 August 2018 + + + [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional + Algorithms and Identifiers for RSA Cryptography for use in + the Internet X.509 Public Key Infrastructure Certificate + and Certificate Revocation List (CRL) Profile", RFC 4055, + DOI 10.17487/RFC4055, June 2005, + . + + [RFC5639] Lochter, M. and J. Merkle, "Elliptic Curve Cryptography + (ECC) Brainpool Standard Curves and Curve Generation", + RFC 5639, DOI 10.17487/RFC5639, March 2010, + . + + [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, + PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, + April 2015, . + + [RFC8411] Schaad, J. and R. Andrews, "IANA Registration for the + Cryptographic Algorithm Object Identifier Range", + RFC 8411, DOI 10.17487/RFC8411, August 2018, + . + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson & Schaad Standards Track [Page 17] + +RFC 8410 Safe Curves for X.509 August 2018 + + +Appendix A. Invalid Encodings + + There are a number of things that need to be dealt with when a new + key part is decoded and imported into the system. A partial list of + these includes: + + o ASN.1 encoding errors: Two items are highlighted here. First, the + use of an OCTET STRING rather than a BIT STRING for the public + key. The use of OCTET STRING was a copy error that existed in a + previous draft version of this document; the structure is correct + in [RFC5958]. However, any early implementation may have this + wrong. Second, the value of the version field is required to be 0 + if the publicKey is absent and 1 if present. This is called out + in [RFC5958], but was not duplicated above. + + o Key encoding errors: Both [RFC7748] and [RFC8032] have formatting + requirements for keys that need to be enforced. In some cases, + the enforcement is done at the time of importing, for example, + doing masking or a mod p operation. In other cases, the + enforcement is done by rejecting the keys and having an import + failure. + + o Key mismatch errors: If a public key is provided, it may not agree + with the private key because either it is wrong or the wrong + algorithm was used. + + Some systems are also going to be stricter on what they accept. As + stated in [RFC5958], BER decoding of OneAsymmetricKey objects is a + requirement for compliance. Despite this requirement, some acceptors + will only decode DER formats. The following is a BER encoding of a + private key; it is valid, but it may not be accepted by many systems. + + -----BEGIN PRIVATE KEY----- + MIACAQAwgAYDK2VwAAAEIgQg1O5y2/kTWErVttjx92n4rTr+fCjL8dT74Jeoj0R1W + EIAAA== + -----END PRIVATE KEY----- + + What follows here is a brief sampling of some incorrect keys. + + In the following example, the private key does not match the masking + requirements for X25519. For this example, the top bits are set to + zero and the bottom three bits are set to 001. + + -----BEGIN PRIVATE KEY----- + MFMCAQEwBQYDK2VuBCIEIPj///////////////////////////////////////8/oS + MDIQCEfA0sN1I082XmYJVRh6NzWg92E9FgnTpqTYxTrqpaIg== + -----END PRIVATE KEY----- + + + + +Josefsson & Schaad Standards Track [Page 18] + +RFC 8410 Safe Curves for X.509 August 2018 + + + In the following examples, the key is the wrong length because an + all-zero byte has been removed. In one case, the first byte has been + removed; in the other case, the last byte has been removed. + + -----BEGIN PRIVATE KEY----- + MFICAQEwBQYDK2VwBCIEIC3GfeUYbZGTAhwLEE2cbvJL7ivTlcy17VottfN6L8HwoS + IDIADBfk2Lv/J8H7YYwj/OmIcDx++jzVkKrKwS0/HjyQyM + -----END PRIVATE KEY----- + + -----BEGIN PRIVATE KEY----- + MFICAQEwBQYDK2VwBCIEILJXn1VaLqvausjUaZexwI/ozmOFjfEk78KcYN+7hsNJoS + IDIACdQhJwzi/MCGcsQeQnIUh2JFybDxSrZxuLudJmpJLk + -----END PRIVATE KEY----- + +Acknowledgments + + Text and/or inspiration were drawn from [RFC5280], [RFC3279], + [RFC4055], [RFC5480], and [RFC5639]. + + The following people discussed the document and provided feedback: + Klaus Hartke, Ilari Liusvaara, Erwann Abalea, Rick Andrews, Rob + Stradling, James Manger, Nikos Mavrogiannopoulos, Russ Housley, David + Benjamin, Brian Smith, and Alex Wilson. + + A big thank you to Symantec for kindly donating the OIDs used in this + document. + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson & Schaad Standards Track [Page 19] + +RFC 8410 Safe Curves for X.509 August 2018 + + +Authors' Addresses + + Simon Josefsson + SJD AB + + Email: simon@josefsson.org + + + Jim Schaad + August Cellars + + Email: ietf@augustcellars.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson & Schaad Standards Track [Page 20] + diff --git a/const-oid/oiddbgen/src/main.rs b/const-oid/oiddbgen/src/main.rs index 7c36584f8..8840a093c 100644 --- a/const-oid/oiddbgen/src/main.rs +++ b/const-oid/oiddbgen/src/main.rs @@ -14,6 +14,7 @@ const RFCS: &[(&str, &str)] = &[ ("rfc6960", include_str!("../rfc6960.txt")), ("rfc7107", include_str!("../rfc7107.txt")), ("rfc7299", include_str!("../rfc7299.txt")), + ("rfc8410", include_str!("../rfc8410.txt")), ]; const MDS: &[(&str, &str)] = &[("rfc8894", include_str!("../rfc8894.md"))]; diff --git a/const-oid/src/db/gen.rs b/const-oid/src/db/gen.rs index d70e5e0fa..fbeb5dce0 100644 --- a/const-oid/src/db/gen.rs +++ b/const-oid/src/db/gen.rs @@ -2245,6 +2245,18 @@ pub mod rfc8284 { crate::ObjectIdentifier::new_unwrap("1.3.6.1.1.23.1"); pub const JID: crate::ObjectIdentifier = crate::ObjectIdentifier::new_unwrap("1.3.6.1.1.23.2"); } +pub mod rfc8410 { + pub const ID_EDWARDS_CURVE_ALGS: crate::ObjectIdentifier = + crate::ObjectIdentifier::new_unwrap("1.3.101"); + pub const ID_X_25519: crate::ObjectIdentifier = + crate::ObjectIdentifier::new_unwrap("1.3.101.110"); + pub const ID_X_448: crate::ObjectIdentifier = + crate::ObjectIdentifier::new_unwrap("1.3.101.111"); + pub const ID_ED_25519: crate::ObjectIdentifier = + crate::ObjectIdentifier::new_unwrap("1.3.101.112"); + pub const ID_ED_448: crate::ObjectIdentifier = + crate::ObjectIdentifier::new_unwrap("1.3.101.113"); +} pub mod rfc8894 { pub const ID_VERI_SIGN: crate::ObjectIdentifier = crate::ObjectIdentifier::new_unwrap("2.16.840.1.113733"); @@ -4205,6 +4217,11 @@ pub const DB: super::Database<'static> = super::Database(&[ ), (&rfc8284::JID_OBJECT, "JIDObject"), (&rfc8284::JID, "jid"), + (&rfc8410::ID_EDWARDS_CURVE_ALGS, "id-edwards-curve-algs"), + (&rfc8410::ID_X_25519, "id-X25519"), + (&rfc8410::ID_X_448, "id-X448"), + (&rfc8410::ID_ED_25519, "id-Ed25519"), + (&rfc8410::ID_ED_448, "id-Ed448"), (&rfc8894::ID_VERI_SIGN, "id-VeriSign"), (&rfc8894::ID_PKI, "id-pki"), (&rfc8894::ID_ATTRIBUTES, "id-attributes"),