idnits 2.17.1 draft-turner-lamps-nist-pqc-kem-certificates-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (7 March 2022) is 781 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 225 -- Looks like a reference, but probably isn't: '1' on line 227 ** Downref: Normative reference to an Informational RFC: RFC 5912 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 None S. Turner 3 Internet-Draft sn3rd 4 Intended status: Standards Track P. Kampanakis 5 Expires: 8 September 2022 J. Massimo 6 AWS 7 B. Westerbaan 8 Cloudflare 9 7 March 2022 11 Algorithm Identifiers for NIST's PQC Algorithms for Use in the Internet 12 X.509 Public Key Infrastructure 13 draft-turner-lamps-nist-pqc-kem-certificates-01 15 Abstract 17 This document specifies algorithm identifiers and ASN.1 encoding 18 format for the US NIST's PQC KEM (United States National Institute of 19 Standards and Technology's Post Quantum Cryptography Key 20 Encapsulation Mechanism) algorithms. The algorithms covered are 21 Candidate TBD1. The encoding for public key and private key is also 22 provided. 24 [EDNOTE: This draft is not expected to be finalized before the NIST 25 PQC Project has standardized PQ algorithms. After NIST has 26 standardized its first algorithms, this document will replace TBD, 27 with the appropriate algorithms and parameters before proceeding to 28 ratification. The algorithm Candidate TBD1 has been added as an 29 example in this draft, to provide a more detailed illustration of the 30 content - it by no means indicates its inclusion in the final 31 version. This specification will use object identifiers for the new 32 algorithms that are assigned by NIST, and will use placeholders until 33 these are released.] 35 About This Document 37 This note is to be removed before publishing as an RFC. 39 Status information for this document may be found at 40 https://datatracker.ietf.org/doc/draft-turner-lamps-nist-pqc-kem- 41 certificates/. 43 Discussion of this document takes place on the Limited Additional 44 Mechanisms for PKIX and SMIME (lamps) Working Group mailing list 45 (mailto:spasm@ietf.org), which is archived at 46 https://mailarchive.ietf.org/arch/browse/spasm/. 48 Source for this draft and an issue tracker can be found at 49 https://github.com/ seanturner/draft-turner-lamps-nist-pqc-kem- 50 certificates. 52 Status of This Memo 54 This Internet-Draft is submitted in full conformance with the 55 provisions of BCP 78 and BCP 79. 57 Internet-Drafts are working documents of the Internet Engineering 58 Task Force (IETF). Note that other groups may also distribute 59 working documents as Internet-Drafts. The list of current Internet- 60 Drafts is at https://datatracker.ietf.org/drafts/current/. 62 Internet-Drafts are draft documents valid for a maximum of six months 63 and may be updated, replaced, or obsoleted by other documents at any 64 time. It is inappropriate to use Internet-Drafts as reference 65 material or to cite them other than as "work in progress." 67 This Internet-Draft will expire on 8 September 2022. 69 Copyright Notice 71 Copyright (c) 2022 IETF Trust and the persons identified as the 72 document authors. All rights reserved. 74 This document is subject to BCP 78 and the IETF Trust's Legal 75 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 76 license-info) in effect on the date of publication of this document. 77 Please review these documents carefully, as they describe your rights 78 and restrictions with respect to this document. Code Components 79 extracted from this document must include Revised BSD License text as 80 described in Section 4.e of the Trust Legal Provisions and are 81 provided without warranty as described in the Revised BSD License. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 86 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 87 3. Algorithm Identifiers . . . . . . . . . . . . . . . . . . . . 3 88 4. Candidate TBD1 . . . . . . . . . . . . . . . . . . . . . . . 4 89 5. Subject Public Key Fields . . . . . . . . . . . . . . . . . . 4 90 6. Key Usage Bits . . . . . . . . . . . . . . . . . . . . . . . 5 91 7. Private Key Format . . . . . . . . . . . . . . . . . . . . . 5 92 8. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . 6 93 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 94 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 96 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 97 11.2. Informative References . . . . . . . . . . . . . . . . . 7 98 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 101 1. Introduction 103 The US NIST PQC Project has selected the Candidate TBD1 algorithms as 104 winners of their PQC Project [PQCProj]. These algorithms are KEM 105 algorithms. NIST has also defined object identifiers for these 106 algorithms (TODO insert reference). 108 This document specifies the use of the Candidate TBD1 algorithms in 109 X.509 public key certifiates, see [RFC5280]. It also specifies 110 private key encoding. An ASN.1 module is included for reference 111 purposes. 113 These certificates could be used as Issuers in CMS where the public 114 key is used to encapsulate a shared secret used to derive a symmetric 115 key used to encrypt content in CMS [EDNOTE: Add reference draft- 116 perret-prat-lamps-cms-pq-kem]. To be used in TLS, these certificates 117 could only be used as end-entity identity certificates and would 118 require significant updates to the protocol [EDNOTE: Add reference 119 draft-celi-wiggers-tls-authkem]. 121 2. Conventions and Definitions 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in 126 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 3. Algorithm Identifiers 131 Certificates conforming to [RFC5280] can convey a public key for any 132 public key algorithm. The certificate indicates the algorithm 133 through an algorithm identifier. An algorithm identifier consists of 134 an object identifier and optional parameters. 136 The AlgorithmIdentifier type, which is included herein for 137 convenience, is defined as follows: 139 AlgorithmIdentifier ::= SEQUENCE { 140 algorithm OBJECT IDENTIFIER, 141 parameters ANY DEFINED BY algorithm OPTIONAL 142 } 143 | NOTE: The above syntax is from [RFC5280] and matches the 144 | version used therein, i.e., the 1988 ASN.1 syntax. See 145 | [RFC5912] for ASN.1 copmatible with the 2015 ASN.1 syntax. 147 The fields in AlgorithmIdentifier have the following meanings: 149 * algorithm identifies the cryptographic algorithm with an object 150 identifier. XXX such OIDs are defined in Sections Section 4. 152 * parameters, which are optional, are the associated parameters for 153 the algorithm identifier in the algorithm field. 155 In this document, TODO (specify number) new OIDs for identifying the 156 different algorithm and parameter pairs. For all of the object 157 identifiers, the parameters MUST be absent. 159 It is possible to find systems that require the parameters to be 160 present. This can be due to either a defect in the original 1997 161 syntax or a programming error where developers never got input where 162 this was not true. The optimal solution is to fix these systems; 163 where this is not possible, the problem needs to be restricted to 164 that subsystem and not propagated to the Internet. 166 4. Candidate TBD1 168 TODO insert object-identifiers 170 5. Subject Public Key Fields 172 In the X.509 certificate, the subjectPublicKeyInfo field has the 173 SubjectPublicKeyInfo type, which has the following ASN.1 syntax: 175 SubjectPublicKeyInfo ::= SEQUENCE { 176 algorithm AlgorithmIdentifier, 177 subjectPublicKey BIT STRING 178 } 180 | NOTE: The above syntax is from [RFC5280] and matches the 181 | version used therein, i.e., the 1988 ASN.1 syntax. See 182 | [RFC5912] for ASN.1 copmatible with the 2015 ASN.1 syntax. 184 The fields in SubjectPublicKeyInfo have the following meanings: 186 * algorithm is the algorithm identifier and parameters for the 187 public key (see above). 189 * subjectPublicKey contains the byte stream of the public key. The 190 algorithms defined in this document always encode the public key 191 as TODO pick format e.g., exact multiple of 8 bits?. 193 The following is an example of a TBD public key encoded using the 194 textual encoding defined in [RFC7468]. 196 -----BEGIN PUBLIC KEY----- 197 TODO insert example public key 198 -----END PUBLIC KEY------- 200 6. Key Usage Bits 202 The intended application for the key is indicated in the keyUsage 203 certificate extension; see Section 4.2.1.3 of [RFC5280]. 205 If the keyUsage extension is present in a certificate that indicates 206 Candidate TBD1 in SubjectPublicKeyInfo, then the following MUST be 207 present: 209 keyEncipherment; 211 7. Private Key Format 213 "Asymmetric Key Packages" [RFC5958] describes how to encode a private 214 key in a structure that both identifies what algorithm the private 215 key is for and allows for the public key and additional attributes 216 about the key to be included as well. For illustration, the ASN.1 217 structure OneAsymmetricKey is replicated below. The algorithm- 218 specific details of how a private key is encoded are left for the 219 document describing the algorithm itself. 221 OneAsymmetricKey ::= SEQUENCE { 222 version Version, 223 privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, 224 privateKey PrivateKey, 225 attributes [0] IMPLICIT Attributes OPTIONAL, 226 ..., 227 [[2: publicKey [1] IMPLICIT PublicKey OPTIONAL ]], 228 ... 229 } 231 PrivateKey ::= OCTET STRING 233 PublicKey ::= BIT STRING 234 | NOTE: The above syntax is from [RFC5958] and matches the 235 | version used therein, i.e., the 2002 ASN.1 syntax. The syntax 236 | used therein is compatible with the 2015 ASN.1 syntax. 238 For the keys defined in this document, the private key is always an 239 opaque byte sequence. The ASN.1 type PqckemPrivateKey is defined in 240 this document to hold the byte sequence. Thus, when encoding a 241 OneAsymmetricKey object, the private key is wrapped in a 242 PqckemPrivateKey object and wrapped by the OCTET STRING of the 243 "privateKey" field. 245 PqckemPrivateKey ::= OCTET STRING 247 The following is an example of a TBD private key encoded using the 248 textual encoding defined in [RFC7468]. 250 -----BEGIN PRIVATE KEY----- 251 TODO iser example private key 252 -----END PRIVATE KEY------- 254 The following example, in addition to encoding the TBD private key, 255 has an attribute included as well as the public key. As with the 256 prior example, the textual encoding defined in [RFC7468] is used. 258 -----BEGIN PRIVATE KEY----- 259 TODO insert example private key with attribute 260 -----END PRIVATE KEY------- 262 | NOTE: There exist some private key import functions that have 263 | not implemented the new ASN.1 structure OneAsymmetricKey that 264 | is defined in [RFC5958]. This means that they will not accept 265 | a private key structure that contains the public key field. 266 | This means a balancing act needs to be done between being able 267 | to do a consistency check on the key pair and widest ability to 268 | import the key. 270 8. ASN.1 Module 272 TODO ASN.1 Module 274 9. Security Considerations 276 The Security Considerations section of [RFC5280] applies to this 277 specification as well. 279 [EDNOTE: Discuss side-channels for Candidate TBD1.] 281 10. IANA Considerations 283 This document will have some IANA actions. 285 11. References 287 11.1. Normative References 289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 290 Requirement Levels", BCP 14, RFC 2119, 291 DOI 10.17487/RFC2119, March 1997, 292 . 294 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 295 Housley, R., and W. Polk, "Internet X.509 Public Key 296 Infrastructure Certificate and Certificate Revocation List 297 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 298 . 300 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 301 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 302 DOI 10.17487/RFC5912, June 2010, 303 . 305 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 306 DOI 10.17487/RFC5958, August 2010, 307 . 309 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 310 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 311 May 2017, . 313 11.2. Informative References 315 [PQCProj] National Insititue of Standards and Technology, "Post- 316 Quantum Cryptography Project", 20 December 2016, 317 . 320 [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, 321 PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, 322 April 2015, . 324 Acknowledgments 326 TODO acknowledge. 328 Authors' Addresses 330 Sean Turner 331 sn3rd 333 Email: sean@sn3rd.com 335 Panos Kampanakis 336 AWS 338 Email: kpanos@amazon.com 340 Jake Massimo 341 AWS 343 Email: jakemas@amazon.com 345 Bas Westerbaan 346 Cloudflare 348 Email: bas@westerbaan.name