From 2c11c28a851fe62c59f079a4c5970e9fc967ae8f Mon Sep 17 00:00:00 2001 From: ID Bot Date: Wed, 20 Dec 2023 14:53:06 +0000 Subject: [PATCH] Script updating gh-pages from eb09f31. [ci skip] --- .../draft-ietf-lamps-kyber-certificates.txt | 415 ----- ...urner-lamps-nist-pqc-kem-certificates.html | 1576 ---------------- ...turner-lamps-nist-pqc-kem-certificates.txt | 354 ---- index.html | 46 +- .../draft-ietf-lamps-kyber-certificates.html | 1633 ---------------- ...urner-lamps-nist-pqc-kem-certificates.html | 1576 ---------------- ...turner-lamps-nist-pqc-kem-certificates.txt | 354 ---- seanturner-asides/index.html | 50 - .../draft-ietf-lamps-kyber-certificates.html | 1635 ----------------- .../draft-ietf-lamps-kyber-certificates.txt | 415 ----- seanturner-md-fix/index.html | 50 - .../draft-ietf-lamps-kyber-certificates.html | 121 +- .../draft-ietf-lamps-kyber-certificates.txt | 86 +- ...urner-lamps-nist-pqc-kem-certificates.html | 24 +- ...turner-lamps-nist-pqc-kem-certificates.txt | 6 +- .../index.html | 10 +- 16 files changed, 137 insertions(+), 8214 deletions(-) delete mode 100644 draft-ietf-lamps-kyber-certificates-02/draft-ietf-lamps-kyber-certificates.txt delete mode 100644 draft-ietf-lamps-kyber-certificates-02/draft-turner-lamps-nist-pqc-kem-certificates.html delete mode 100644 draft-ietf-lamps-kyber-certificates-02/draft-turner-lamps-nist-pqc-kem-certificates.txt delete mode 100644 seanturner-asides/draft-ietf-lamps-kyber-certificates.html delete mode 100644 seanturner-asides/draft-turner-lamps-nist-pqc-kem-certificates.html delete mode 100644 seanturner-asides/draft-turner-lamps-nist-pqc-kem-certificates.txt delete mode 100644 seanturner-asides/index.html delete mode 100644 seanturner-md-fix/draft-ietf-lamps-kyber-certificates.html delete mode 100644 seanturner-md-fix/draft-ietf-lamps-kyber-certificates.txt delete mode 100644 seanturner-md-fix/index.html rename {draft-ietf-lamps-kyber-certificates-02 => seanturner-name-change}/draft-ietf-lamps-kyber-certificates.html (92%) rename {seanturner-asides => seanturner-name-change}/draft-ietf-lamps-kyber-certificates.txt (85%) rename {seanturner-md-fix => seanturner-name-change}/draft-turner-lamps-nist-pqc-kem-certificates.html (99%) rename {seanturner-md-fix => seanturner-name-change}/draft-turner-lamps-nist-pqc-kem-certificates.txt (98%) rename {draft-ietf-lamps-kyber-certificates-02 => seanturner-name-change}/index.html (78%) diff --git a/draft-ietf-lamps-kyber-certificates-02/draft-ietf-lamps-kyber-certificates.txt b/draft-ietf-lamps-kyber-certificates-02/draft-ietf-lamps-kyber-certificates.txt deleted file mode 100644 index e4dfe0b..0000000 --- a/draft-ietf-lamps-kyber-certificates-02/draft-ietf-lamps-kyber-certificates.txt +++ /dev/null @@ -1,415 +0,0 @@ - - - - -LAMPS S. Turner -Internet-Draft sn3rd -Intended status: Standards Track P. Kampanakis -Expires: 25 April 2024 J. Massimo - AWS - B. Westerbaan - Cloudflare - 23 October 2023 - - - Internet X.509 Public Key Infrastructure - Algorithm Identifiers for - Kyber - draft-ietf-lamps-kyber-certificates-latest - -Abstract - - Kyber is a key-encapsulation mechanism (KEM). This document - specifies algorithm identifiers and ASN.1 encoding format for Kyber - in public key certificates. The encoding for public and private keys - are also provided. - - \ [EDNOTE: This document is not expected to be finalized before the - NIST PQC Project has standardized PQ algorithms. This specification - will use object identifiers for the new algorithms that are assigned - by NIST, and will use placeholders until these are released. - -About This Document - - This note is to be removed before publishing as an RFC. - - The latest revision of this draft can be found at https://lamps- - wg.github.io/kyber-certificates/#go.draft-ietf-lamps-kyber- - certificates.html. Status information for this document may be found - at https://datatracker.ietf.org/doc/draft-ietf-lamps-kyber- - certificates/. - - Discussion of this document takes place on the Limited Additional - Mechanisms for PKIX and SMIME (lamps) Working Group mailing list - (mailto:spasm@ietf.org), which is archived at - https://mailarchive.ietf.org/arch/browse/spasm/. Subscribe at - https://www.ietf.org/mailman/listinfo/spasm/. - - Source for this draft and an issue tracker can be found at - https://github.com/lamps-wg/kyber-certificates. - -Status of This Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at https://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on 25 April 2024. - -Copyright Notice - - Copyright (c) 2023 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 Revised BSD License text as - described in Section 4.e of the Trust Legal Provisions and are - provided without warranty as described in the Revised BSD License. - -Table of Contents - - 1. Introduction - 1.1. ASN.1 and Kyber Identifiers - 1.2. Applicability Statement - 2. Conventions and Definitions - 3. Algorithm Identifiers - 4. Kyber Public Key Identifiers - 5. Subject Public Key Fields - 6. Private Key Format - 7. ASN.1 Module - 8. Security Considerations - 9. IANA Considerations - 10. References - 10.1. Normative References - 10.2. Informative References - Acknowledgments - Authors' Addresses - -1. Introduction - - Kyber is a key-encapsulation mechanism (KEM) standardized by the US - NIST PQC Project [PQCProj]. This document specifies the use of the - Kyber algorithm at three security levels: Kyber512, Kyber768, and - Kyber1024, in X.509 public key certificates; see [RFC5280]. Public - and private key encodings are also specified. - -1.1. ASN.1 and Kyber Identifiers - - An ASN.1 module [X680] is included for reference purposes. Note that - as per [RFC5280], certificates use the Distinguished Encoding Rules; - see [X690]. Also note that NIST defined the object identifiers for - the Kyber algorithms in an ASN.1 modulle; see (TODO insert - reference). - -1.2. Applicability Statement - - Kyber certificates are used in protocols where the public key is used - to generate and encapsulate a shared secret used to derive a - symmetric key used to encrypt a payload; see [I-D.ietf-lamps-kyber]. - To be used in TLS, Kyber certificates could only be used as end- - entity identity certificates and would require significant updates to - the protocol; see [I-D.celi-wiggers-tls-authkem]. - -2. Conventions and Definitions - - 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. 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 object identifier and optional parameters. - - The AlgorithmIdentifier type, which is included herein for - convenience, is defined as follows: - - AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::= - SEQUENCE { - algorithm ALGORITHM-TYPE.&id({AlgorithmSet}), - parameters ALGORITHM-TYPE. - &Params({AlgorithmSet}{@algorithm}) OPTIONAL - } - - | : The above syntax is from [RFC5912] and is compatible with the - | 2021 ASN.1 syntax [X680]. - - The fields in AlgorithmIdentifier have the following meanings: - - * algorithm identifies the cryptographic algorithm with an object - identifier. - - * parameters, which are optional, are the associated parameters for - the algorithm identifier in the algorithm field. - - Section 4 includes object identifiers for Kyber-512, Kyber-768, and - Kyber-1024. For all of these 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. - -4. Kyber Public Key Identifiers - - The AlgorithmIdentifier for a Kyber public key MUST use one of the - id-alg-kyber object identifiers listed below, based on the security - level. The parameters field of the AlgorithmIdentifier for the Kyber - public key MUST be absent. - - When any of the Kyber AlgorithmIdentifier appears in the - SubjectPublicKeyInfo field of an X.509 certificate, the key usage - certificate extension MUST only contain keyEncipherment - Section 4.2.1.3 of [RFC5280]. - - pk-kyber-512 PUBLIC-KEY ::= { - IDENTIFIER id-alg-kyber-512 - -- KEY no ASN.1 wrapping -- - PARAMS ARE absent - CERT-KEY-USAGE - { keyEncipherment } - --- PRIVATE-KEY no ASN.1 wrapping -- - } - - pk-kyber-768 PUBLIC-KEY ::= { - IDENTIFIER id-alg-kyber-768 - -- KEY no ASN.1 wrapping -- - PARAMS ARE absent - CERT-KEY-USAGE - { keyEncipherment } - --- PRIVATE-KEY no ASN.1 wrapping -- - } - - pk-kyber-1024 PUBLIC-KEY ::= { - IDENTIFIER id-alg-kyber-1024 - -- KEY no ASN.1 wrapping -- - PARAMS ARE absent - CERT-KEY-USAGE - { keyEncipherment } - --- PRIVATE-KEY no ASN.1 wrapping -- - } - - | : As noted in Section 3, the values for these object identifers - | will be assigned by NIST. Once assigned, they will be added to - | a future revision of this document. - -5. Subject Public Key Fields - - In the X.509 certificate, the subjectPublicKeyInfo field has the - SubjectPublicKeyInfo type, which has the following ASN.1 syntax: - - SubjectPublicKeyInfo {PUBLIC-KEY: IOSet} ::= SEQUENCE { - algorithm AlgorithmIdentifier {PUBLIC-KEY, {IOSet}}, - subjectPublicKey BIT STRING - } - - | : The above syntax is from [RFC5912] and is compatible with the - | 2021 ASN.1 syntax [X680]. - - The fields in SubjectPublicKeyInfo have the following meaning: - - * algorithm is the algorithm identifier and parameters for the - public key (see above). - - * subjectPublicKey contains the byte stream of the public key. The - algorithms defined in this document always encode the public key - as TODO pick format e.g., exact multiple of 8 bits?. - - The following is an example of a Kyber-512 public key encoded using - the textual encoding defined in [RFC7468]: - - -----BEGIN PUBLIC KEY----- - TODO insert example public key - -----END PUBLIC KEY------- - -6. 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 SEQUENCE { - algorithm PUBLIC-KEY.&id({PublicKeySet}), - parameters PUBLIC-KEY.&Params({PublicKeySet} - {@privateKeyAlgorithm.algorithm}) - OPTIONAL} - privateKey OCTET STRING (CONTAINING - PUBLIC-KEY.&PrivateKey({PublicKeySet} - {@privateKeyAlgorithm.algorithm})), - attributes [0] Attributes OPTIONAL, - ..., - [[2: publicKey [1] BIT STRING (CONTAINING - PUBLIC-KEY.&Params({PublicKeySet} - {@privateKeyAlgorithm.algorithm}) - OPTIONAL, - ... - } - - PrivateKey ::= OCTET STRING - - PublicKey ::= BIT STRING - - | : The above syntax is from [RFC5958] and is compatible with the - | 2021 ASN.1 syntax [X680]. - - For the keys defined in this document, the private key is always an - opaque byte sequence. The ASN.1 type PqckemPrivateKey is defined in - this document to hold the byte sequence. Thus, when encoding a - OneAsymmetricKey object, the private key is wrapped in a - PqckemPrivateKey object and wrapped by the OCTET STRING of the - "privateKey" field. - - PqckemPrivateKey ::= OCTET STRING - - The following is an example of a Kyber-512 private key encoded using - the textual encoding defined in [RFC7468]: - - -----BEGIN PRIVATE KEY----- - TODO iser example private key - -----END PRIVATE KEY------- - - The following example, in addition to encoding the Kyber-512 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----- - TODO insert example private key with attribute - -----END PRIVATE KEY------- - - | : There exist some private key import functions that have not - | implemented the new ASN.1 structure OneAsymmetricKey that is - | defined in [RFC5958]. 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. - -7. ASN.1 Module - - TODO ASN.1 Module - -8. Security Considerations - - The Security Considerations section of [RFC5280] applies to this - specification as well. - - [EDNOTE: Discuss side-channels for Kyber TBD1.] - -9. IANA Considerations - - This document will have some IANA actions. - -10. References - -10.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, - . - - [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the - Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, - DOI 10.17487/RFC5912, June 2010, - . - - [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, - DOI 10.17487/RFC5958, August 2010, - . - - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC - 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 2017, . - - [X680] ITU-T, "Information technology - Abstract Syntax Notation - One (ASN.1): Specification of basic notation", ISO/ - IEC 8824-1:2021, February 2021, - . - - [X690] ITU-T, "Information technology - Abstract Syntax Notation - One (ASN.1): ASN.1 encoding rules: Specification of Basic - Encoding Rules (BER), Canonical Encoding Rules (CER) and - Distinguished Encoding Rules (DER)", ISO/IEC 8825-1:2021, - February 2021, . - -10.2. Informative References - - [I-D.celi-wiggers-tls-authkem] - Wiggers, T., Celi, S., Schwabe, P., Stebila, D., and N. - Sullivan, "KEM-based Authentication for TLS 1.3", Work in - Progress, Internet-Draft, draft-celi-wiggers-tls-authkem- - 02, 18 August 2023, - . - - [I-D.ietf-lamps-kyber] - Prat, J. and M. Ounsworth, "Use of KYBER in the - Cryptographic Message Syntax (CMS)", Work in Progress, - Internet-Draft, draft-ietf-lamps-kyber-00, 10 November - 2022, . - - [PQCProj] National Institute of Standards and Technology, "Post- - Quantum Cryptography Project", 20 December 2016, - . - - [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, - PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, - April 2015, . - -Acknowledgments - - TODO acknowledge. - -Authors' Addresses - - Sean Turner - sn3rd - Email: sean@sn3rd.com - - - Panos Kampanakis - AWS - Email: kpanos@amazon.com - - - Jake Massimo - AWS - Email: jakemas@amazon.com - - - Bas Westerbaan - Cloudflare - Email: bas@westerbaan.name diff --git a/draft-ietf-lamps-kyber-certificates-02/draft-turner-lamps-nist-pqc-kem-certificates.html b/draft-ietf-lamps-kyber-certificates-02/draft-turner-lamps-nist-pqc-kem-certificates.html deleted file mode 100644 index 007d7d1..0000000 --- a/draft-ietf-lamps-kyber-certificates-02/draft-turner-lamps-nist-pqc-kem-certificates.html +++ /dev/null @@ -1,1576 +0,0 @@ - - - - - - -Algorithm Identifiers for NIST's PQC Algorithms for Use in the Internet X.509 Public Key Infrastructure - - - - - - - - - - - - - - - - - - - - - - - - - - -
Internet-DraftPQC KEM for CertificatesOctober 2023
Turner, et al.Expires 25 April 2024[Page]
-
-
-
-
Workgroup:
-
None
-
Internet-Draft:
-
draft-turner-lamps-nist-pqc-kem-certificates-latest
-
Published:
-
- -
-
Intended Status:
-
Standards Track
-
Expires:
-
-
Authors:
-
-
-
S. Turner
-
sn3rd
-
-
-
P. Kampanakis
-
AWS
-
-
-
J. Massimo
-
AWS
-
-
-
B. Westerbaan
-
Cloudflare
-
-
-
-
-

Algorithm Identifiers for NIST's PQC Algorithms for Use in the Internet X.509 Public Key Infrastructure

-
-

Abstract

-

This document specifies algorithm identifiers and ASN.1 encoding format -for the US NIST's PQC KEM (United States National Institute of Standards -and Technology's Post Quantum Cryptography Key Encapsulation Mechanism) -algorithms. The algorithms covered are Candidate TBD1. The -encoding for public key and private key is also provided.

-

[EDNOTE: -This draft is not expected to be finalized before the NIST PQC Project -has standardized PQ algorithms. After NIST has standardized its first -algorithms, this document will replace TBD, with the appropriate -algorithms and parameters before proceeding to ratification. The -algorithm Candidate TBD1 has been added as an example in this draft, to -provide a more detailed illustration of the content - it by no means -indicates its inclusion in the final version. This specification will -use object identifiers for the new algorithms that are assigned by NIST, -and will use placeholders until these are released.]

-
-
-

-About This Document -

-

This note is to be removed before publishing as an RFC.

-

- Status information for this document may be found at https://datatracker.ietf.org/doc/draft-turner-lamps-nist-pqc-kem-certificates/.

-

- Discussion of this document takes place on the - Limited Additional Mechanisms for PKIX and SMIME (lamps) Working Group mailing list (mailto:spasm@ietf.org), - which is archived at https://mailarchive.ietf.org/arch/browse/spasm/. - Subscribe at https://www.ietf.org/mailman/listinfo/spasm/.

-

Source for this draft and an issue tracker can be found at - https://github.com/seanturner/draft-turner-lamps-nist-pqc-kem-certificates.

-
-
-
-

-Status of This Memo -

-

- This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79.

-

- Internet-Drafts are working documents of the Internet Engineering Task - Force (IETF). Note that other groups may also distribute working - documents as Internet-Drafts. The list of current Internet-Drafts is - at https://datatracker.ietf.org/drafts/current/.

-

- Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress."

-

- This Internet-Draft will expire on 25 April 2024.

-
-
- - -
-
-

-1. Introduction -

-

The US NIST PQC Project has selected the Candidate TBD1 -algorithms as winners of their PQC Project [PQCProj]. These -algorithms are KEM algorithms. NIST has also defined object identifiers -for these algorithms (TODO insert reference).

-

This document specifies the use of the Candidate TBD1 -algorithms in X.509 public key certifiates, see [RFC5280]. -It also specifies private key encoding. -An ASN.1 module is included for reference purposes.

-

These certificates could be used as Issuers in CMS where the public key -is used to encapsulate a shared secret used to derive a symmetric key -used to encrypt content in CMS -[EDNOTE: Add reference draft-perret-prat-lamps-cms-pq-kem]. -To be used in TLS, these certificates could only be used as end-entity -identity certificates and would require significant updates to the -protocol -[EDNOTE: Add reference draft-celi-wiggers-tls-authkem].

-
-
-
-
-

-2. Conventions and Definitions -

-

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. 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 object -identifier and optional parameters.

-

The AlgorithmIdentifier type, which is included herein 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:

-
    -
  • -

    algorithm identifies the cryptographic algorithm with an object -identifier. XXX such OIDs are defined in Sections Section 4.

    -
    • -
  • -

    parameters, which are optional, are the associated parameters for -the algorithm identifier in the algorithm field.

    -
    • -
-

In this document, TODO (specify number) new OIDs for identifying the -different algorithm and parameter pairs. For all of the object -identifiers, 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.

-
-
-
-
-

-4. Candidate TBD1 -

-

TODO insert object-identifiers

-
-
-
-
-

-5. 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
-  }
-
-
- -

The fields in SubjectPublicKeyInfo have the following meanings:

-
    -
  • -

    algorithm is the algorithm identifier and parameters for the -public key (see above).

    -
    • -
  • -

    subjectPublicKey contains the byte stream of the public key. The -algorithms defined in this document always encode the public key -as TODO pick format e.g., exact multiple of 8 bits?.

    -
    • -
-

The following is an example of a TBD public key encoded using the -textual encoding defined in [RFC7468].

-
-
-  -----BEGIN PUBLIC KEY-----
-  TODO insert example public key
-  -----END PUBLIC KEY-------
-
-
-
-
-
-
-

-6. Key Usage Bits -

-

The intended application for the key is indicated in the keyUsage -certificate extension; see Section 4.2.1.3 of [RFC5280].

-

If the keyUsage extension is present in a certificate that indicates -Candidate TBD1 in SubjectPublicKeyInfo, then the following -MUST be present:

-
-
-  keyEncipherment;
-
-
-
-
-
-
-

-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 PqckemPrivateKey is defined in -this document to hold the byte sequence. Thus, when encoding a -OneAsymmetricKey object, the private key is wrapped in a -PqckemPrivateKey object and wrapped by the OCTET STRING of the -"privateKey" field.

-
-
-  PqckemPrivateKey ::= OCTET STRING
-
-
-

The following is an example of a TBD private key encoded using the -textual encoding defined in [RFC7468].

-
-
-  -----BEGIN PRIVATE KEY-----
-  TODO iser example private key
-  -----END PRIVATE KEY-------
-
-
-

The following example, in addition to encoding the TBD 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-----
-  TODO insert example private key with attribute
-  -----END PRIVATE KEY-------
-
-
- -
-
-
-
-

-8. ASN.1 Module -

-

TODO ASN.1 Module

-
-
-
-
-

-9. Security Considerations -

-

The Security Considerations section of [RFC5280] applies to this specification as well.

-

[EDNOTE: Discuss side-channels for Candidate TBD1.]

-
-
-
-
-

-10. IANA Considerations -

-

This document will have some IANA actions.

-
-
-
-

-11. References -

-
-
-

-11.1. Normative References -

-
-
[RFC2119]
-
-Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
-
-
[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, , <https://www.rfc-editor.org/rfc/rfc5280>.
-
-
[RFC5912]
-
-Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, , <https://www.rfc-editor.org/rfc/rfc5912>.
-
-
[RFC5958]
-
-Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 10.17487/RFC5958, , <https://www.rfc-editor.org/rfc/rfc5958>.
-
-
[RFC8174]
-
-Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
-
-
-
-
-
-
-

-11.2. Informative References -

-
-
[PQCProj]
-
-National Institute of Standards and Technology, "Post-Quantum Cryptography Project", , <https://csrc.nist.gov/projects/post-quantum-cryptography>.
-
-
[RFC7468]
-
-Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, , <https://www.rfc-editor.org/rfc/rfc7468>.
-
-
-
-
-
-
-
-

-Acknowledgments -

-

TODO acknowledge.

-
-
-
-
-

-Authors' Addresses -

-
-
Sean Turner
-
sn3rd
- -
-
-
Panos Kampanakis
-
AWS
- -
-
-
Jake Massimo
-
AWS
- -
-
-
Bas Westerbaan
-
Cloudflare
- -
-
-
- - - diff --git a/draft-ietf-lamps-kyber-certificates-02/draft-turner-lamps-nist-pqc-kem-certificates.txt b/draft-ietf-lamps-kyber-certificates-02/draft-turner-lamps-nist-pqc-kem-certificates.txt deleted file mode 100644 index 8ecd08c..0000000 --- a/draft-ietf-lamps-kyber-certificates-02/draft-turner-lamps-nist-pqc-kem-certificates.txt +++ /dev/null @@ -1,354 +0,0 @@ - - - - -None S. Turner -Internet-Draft sn3rd -Intended status: Standards Track P. Kampanakis -Expires: 25 April 2024 J. Massimo - AWS - B. Westerbaan - Cloudflare - 23 October 2023 - - -Algorithm Identifiers for NIST's PQC Algorithms for Use in the Internet - X.509 Public Key Infrastructure - draft-turner-lamps-nist-pqc-kem-certificates-latest - -Abstract - - This document specifies algorithm identifiers and ASN.1 encoding - format for the US NIST's PQC KEM (United States National Institute of - Standards and Technology's Post Quantum Cryptography Key - Encapsulation Mechanism) algorithms. The algorithms covered are - Candidate TBD1. The encoding for public key and private key is also - provided. - - [EDNOTE: This draft is not expected to be finalized before the NIST - PQC Project has standardized PQ algorithms. After NIST has - standardized its first algorithms, this document will replace TBD, - with the appropriate algorithms and parameters before proceeding to - ratification. The algorithm Candidate TBD1 has been added as an - example in this draft, to provide a more detailed illustration of the - content - it by no means indicates its inclusion in the final - version. This specification will use object identifiers for the new - algorithms that are assigned by NIST, and will use placeholders until - these are released.] - -About This Document - - This note is to be removed before publishing as an RFC. - - Status information for this document may be found at - https://datatracker.ietf.org/doc/draft-turner-lamps-nist-pqc-kem- - certificates/. - - Discussion of this document takes place on the Limited Additional - Mechanisms for PKIX and SMIME (lamps) Working Group mailing list - (mailto:spasm@ietf.org), which is archived at - https://mailarchive.ietf.org/arch/browse/spasm/. Subscribe at - https://www.ietf.org/mailman/listinfo/spasm/. - - Source for this draft and an issue tracker can be found at - https://github.com/seanturner/draft-turner-lamps-nist-pqc-kem- - certificates. - -Status of This Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at https://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on 25 April 2024. - -Copyright Notice - - Copyright (c) 2023 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 Revised BSD License text as - described in Section 4.e of the Trust Legal Provisions and are - provided without warranty as described in the Revised BSD License. - -Table of Contents - - 1. Introduction - 2. Conventions and Definitions - 3. Algorithm Identifiers - 4. Candidate TBD1 - 5. Subject Public Key Fields - 6. Key Usage Bits - 7. Private Key Format - 8. ASN.1 Module - 9. Security Considerations - 10. IANA Considerations - 11. References - 11.1. Normative References - 11.2. Informative References - Acknowledgments - Authors' Addresses - -1. Introduction - - The US NIST PQC Project has selected the Candidate TBD1 algorithms as - winners of their PQC Project [PQCProj]. These algorithms are KEM - algorithms. NIST has also defined object identifiers for these - algorithms (TODO insert reference). - - This document specifies the use of the Candidate TBD1 algorithms in - X.509 public key certifiates, see [RFC5280]. It also specifies - private key encoding. An ASN.1 module is included for reference - purposes. - - These certificates could be used as Issuers in CMS where the public - key is used to encapsulate a shared secret used to derive a symmetric - key used to encrypt content in CMS [EDNOTE: Add reference draft- - perret-prat-lamps-cms-pq-kem]. To be used in TLS, these certificates - could only be used as end-entity identity certificates and would - require significant updates to the protocol [EDNOTE: Add reference - draft-celi-wiggers-tls-authkem]. - -2. Conventions and Definitions - - 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. 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 object identifier and optional parameters. - - The AlgorithmIdentifier type, which is included herein for - convenience, is defined as follows: - - AlgorithmIdentifier ::= SEQUENCE { - algorithm OBJECT IDENTIFIER, - parameters ANY DEFINED BY algorithm OPTIONAL - } - - | NOTE: The above syntax is from [RFC5280] and matches the - | version used therein, i.e., the 1988 ASN.1 syntax. See - | [RFC5912] for ASN.1 copmatible with the 2015 ASN.1 syntax. - - The fields in AlgorithmIdentifier have the following meanings: - - * algorithm identifies the cryptographic algorithm with an object - identifier. XXX such OIDs are defined in Sections Section 4. - - * parameters, which are optional, are the associated parameters for - the algorithm identifier in the algorithm field. - - In this document, TODO (specify number) new OIDs for identifying the - different algorithm and parameter pairs. For all of the object - identifiers, 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. - -4. Candidate TBD1 - - TODO insert object-identifiers - -5. 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 - } - - | NOTE: The above syntax is from [RFC5280] and matches the - | version used therein, i.e., the 1988 ASN.1 syntax. See - | [RFC5912] for ASN.1 copmatible with the 2015 ASN.1 syntax. - - The fields in SubjectPublicKeyInfo have the following meanings: - - * algorithm is the algorithm identifier and parameters for the - public key (see above). - - * subjectPublicKey contains the byte stream of the public key. The - algorithms defined in this document always encode the public key - as TODO pick format e.g., exact multiple of 8 bits?. - - The following is an example of a TBD public key encoded using the - textual encoding defined in [RFC7468]. - - -----BEGIN PUBLIC KEY----- - TODO insert example public key - -----END PUBLIC KEY------- - -6. Key Usage Bits - - The intended application for the key is indicated in the keyUsage - certificate extension; see Section 4.2.1.3 of [RFC5280]. - - If the keyUsage extension is present in a certificate that indicates - Candidate TBD1 in SubjectPublicKeyInfo, then the following MUST be - present: - - keyEncipherment; - -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 - - | NOTE: The above syntax is from [RFC5958] and matches the - | version used therein, i.e., the 2002 ASN.1 syntax. The syntax - | used therein is compatible with the 2015 ASN.1 syntax. - - For the keys defined in this document, the private key is always an - opaque byte sequence. The ASN.1 type PqckemPrivateKey is defined in - this document to hold the byte sequence. Thus, when encoding a - OneAsymmetricKey object, the private key is wrapped in a - PqckemPrivateKey object and wrapped by the OCTET STRING of the - "privateKey" field. - - PqckemPrivateKey ::= OCTET STRING - - The following is an example of a TBD private key encoded using the - textual encoding defined in [RFC7468]. - - -----BEGIN PRIVATE KEY----- - TODO iser example private key - -----END PRIVATE KEY------- - - The following example, in addition to encoding the TBD 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----- - TODO insert example private key with attribute - -----END PRIVATE KEY------- - - | NOTE: There exist some private key import functions that have - | not implemented the new ASN.1 structure OneAsymmetricKey that - | is defined in [RFC5958]. 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. ASN.1 Module - - TODO ASN.1 Module - -9. Security Considerations - - The Security Considerations section of [RFC5280] applies to this - specification as well. - - [EDNOTE: Discuss side-channels for Candidate TBD1.] - -10. IANA Considerations - - This document will have some IANA actions. - -11. References - -11.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, - . - - [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the - Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, - DOI 10.17487/RFC5912, June 2010, - . - - [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, - DOI 10.17487/RFC5958, August 2010, - . - - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC - 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 2017, . - -11.2. Informative References - - [PQCProj] National Institute of Standards and Technology, "Post- - Quantum Cryptography Project", 20 December 2016, - . - - [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, - PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, - April 2015, . - -Acknowledgments - - TODO acknowledge. - -Authors' Addresses - - Sean Turner - sn3rd - Email: sean@sn3rd.com - - - Panos Kampanakis - AWS - Email: kpanos@amazon.com - - - Jake Massimo - AWS - Email: jakemas@amazon.com - - - Bas Westerbaan - Cloudflare - Email: bas@westerbaan.name diff --git a/index.html b/index.html index 329d56d..fcef599 100644 --- a/index.html +++ b/index.html @@ -17,8 +17,8 @@

Editor's drafts for main branch of saved issues, or the latest GitHub issues and pull requests in the repo.

- - + + @@ -31,43 +31,17 @@

Editor's drafts for main branch of draft-ietf-lamps-kyber-certificates-02

-
PQC Kyber in Certificatesplain textML-KEM in Certificatesplain text datatracker diff with last submission
+

Preview for branch seanturner-name-change

+
- - - + + + - - - - -
PQC Kyber in Certificatesplain textsame as mainML-KEM in Certificatesplain textdiff with main
PQC KEM for Certificatesplain textsame as main
-

Preview for branch seanturner-asides

- - - - - - - - - - - -
PQC Kyber in Certificatesplain textsame as main
PQC KEM for Certificatesplain textsame as main
-

Preview for branch seanturner-md-fix

- - - - - - - - - - + + +
PQC Kyber in Certificatesplain textdiff with main
PQC KEM for Certificatesplain textdiff with mainPQC KEM for Certificatesplain textdiff with main
- - diff --git a/seanturner-asides/draft-turner-lamps-nist-pqc-kem-certificates.html b/seanturner-asides/draft-turner-lamps-nist-pqc-kem-certificates.html deleted file mode 100644 index 007d7d1..0000000 --- a/seanturner-asides/draft-turner-lamps-nist-pqc-kem-certificates.html +++ /dev/null @@ -1,1576 +0,0 @@ - - - - - - -Algorithm Identifiers for NIST's PQC Algorithms for Use in the Internet X.509 Public Key Infrastructure - - - - - - - - - - - - - - - - - - - - - - - - - - -
Internet-DraftPQC KEM for CertificatesOctober 2023
Turner, et al.Expires 25 April 2024[Page]
-
-
-
-
Workgroup:
-
None
-
Internet-Draft:
-
draft-turner-lamps-nist-pqc-kem-certificates-latest
-
Published:
-
- -
-
Intended Status:
-
Standards Track
-
Expires:
-
-
Authors:
-
-
-
S. Turner
-
sn3rd
-
-
-
P. Kampanakis
-
AWS
-
-
-
J. Massimo
-
AWS
-
-
-
B. Westerbaan
-
Cloudflare
-
-
-
-
-

Algorithm Identifiers for NIST's PQC Algorithms for Use in the Internet X.509 Public Key Infrastructure

-
-

Abstract

-

This document specifies algorithm identifiers and ASN.1 encoding format -for the US NIST's PQC KEM (United States National Institute of Standards -and Technology's Post Quantum Cryptography Key Encapsulation Mechanism) -algorithms. The algorithms covered are Candidate TBD1. The -encoding for public key and private key is also provided.

-

[EDNOTE: -This draft is not expected to be finalized before the NIST PQC Project -has standardized PQ algorithms. After NIST has standardized its first -algorithms, this document will replace TBD, with the appropriate -algorithms and parameters before proceeding to ratification. The -algorithm Candidate TBD1 has been added as an example in this draft, to -provide a more detailed illustration of the content - it by no means -indicates its inclusion in the final version. This specification will -use object identifiers for the new algorithms that are assigned by NIST, -and will use placeholders until these are released.]

-
-
-

-About This Document -

-

This note is to be removed before publishing as an RFC.

-

- Status information for this document may be found at https://datatracker.ietf.org/doc/draft-turner-lamps-nist-pqc-kem-certificates/.

-

- Discussion of this document takes place on the - Limited Additional Mechanisms for PKIX and SMIME (lamps) Working Group mailing list (mailto:spasm@ietf.org), - which is archived at https://mailarchive.ietf.org/arch/browse/spasm/. - Subscribe at https://www.ietf.org/mailman/listinfo/spasm/.

-

Source for this draft and an issue tracker can be found at - https://github.com/seanturner/draft-turner-lamps-nist-pqc-kem-certificates.

-
-
-
-

-Status of This Memo -

-

- This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79.

-

- Internet-Drafts are working documents of the Internet Engineering Task - Force (IETF). Note that other groups may also distribute working - documents as Internet-Drafts. The list of current Internet-Drafts is - at https://datatracker.ietf.org/drafts/current/.

-

- Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress."

-

- This Internet-Draft will expire on 25 April 2024.

-
-
- - -
-
-

-1. Introduction -

-

The US NIST PQC Project has selected the Candidate TBD1 -algorithms as winners of their PQC Project [PQCProj]. These -algorithms are KEM algorithms. NIST has also defined object identifiers -for these algorithms (TODO insert reference).

-

This document specifies the use of the Candidate TBD1 -algorithms in X.509 public key certifiates, see [RFC5280]. -It also specifies private key encoding. -An ASN.1 module is included for reference purposes.

-

These certificates could be used as Issuers in CMS where the public key -is used to encapsulate a shared secret used to derive a symmetric key -used to encrypt content in CMS -[EDNOTE: Add reference draft-perret-prat-lamps-cms-pq-kem]. -To be used in TLS, these certificates could only be used as end-entity -identity certificates and would require significant updates to the -protocol -[EDNOTE: Add reference draft-celi-wiggers-tls-authkem].

-
-
-
-
-

-2. Conventions and Definitions -

-

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. 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 object -identifier and optional parameters.

-

The AlgorithmIdentifier type, which is included herein 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:

-
    -
  • -

    algorithm identifies the cryptographic algorithm with an object -identifier. XXX such OIDs are defined in Sections Section 4.

    -
    • -
  • -

    parameters, which are optional, are the associated parameters for -the algorithm identifier in the algorithm field.

    -
    • -
-

In this document, TODO (specify number) new OIDs for identifying the -different algorithm and parameter pairs. For all of the object -identifiers, 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.

-
-
-
-
-

-4. Candidate TBD1 -

-

TODO insert object-identifiers

-
-
-
-
-

-5. 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
-  }
-
-
- -

The fields in SubjectPublicKeyInfo have the following meanings:

-
    -
  • -

    algorithm is the algorithm identifier and parameters for the -public key (see above).

    -
    • -
  • -

    subjectPublicKey contains the byte stream of the public key. The -algorithms defined in this document always encode the public key -as TODO pick format e.g., exact multiple of 8 bits?.

    -
    • -
-

The following is an example of a TBD public key encoded using the -textual encoding defined in [RFC7468].

-
-
-  -----BEGIN PUBLIC KEY-----
-  TODO insert example public key
-  -----END PUBLIC KEY-------
-
-
-
-
-
-
-

-6. Key Usage Bits -

-

The intended application for the key is indicated in the keyUsage -certificate extension; see Section 4.2.1.3 of [RFC5280].

-

If the keyUsage extension is present in a certificate that indicates -Candidate TBD1 in SubjectPublicKeyInfo, then the following -MUST be present:

-
-
-  keyEncipherment;
-
-
-
-
-
-
-

-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 PqckemPrivateKey is defined in -this document to hold the byte sequence. Thus, when encoding a -OneAsymmetricKey object, the private key is wrapped in a -PqckemPrivateKey object and wrapped by the OCTET STRING of the -"privateKey" field.

-
-
-  PqckemPrivateKey ::= OCTET STRING
-
-
-

The following is an example of a TBD private key encoded using the -textual encoding defined in [RFC7468].

-
-
-  -----BEGIN PRIVATE KEY-----
-  TODO iser example private key
-  -----END PRIVATE KEY-------
-
-
-

The following example, in addition to encoding the TBD 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-----
-  TODO insert example private key with attribute
-  -----END PRIVATE KEY-------
-
-
- -
-
-
-
-

-8. ASN.1 Module -

-

TODO ASN.1 Module

-
-
-
-
-

-9. Security Considerations -

-

The Security Considerations section of [RFC5280] applies to this specification as well.

-

[EDNOTE: Discuss side-channels for Candidate TBD1.]

-
-
-
-
-

-10. IANA Considerations -

-

This document will have some IANA actions.

-
-
-
-

-11. References -

-
-
-

-11.1. Normative References -

-
-
[RFC2119]
-
-Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
-
-
[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, , <https://www.rfc-editor.org/rfc/rfc5280>.
-
-
[RFC5912]
-
-Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, , <https://www.rfc-editor.org/rfc/rfc5912>.
-
-
[RFC5958]
-
-Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 10.17487/RFC5958, , <https://www.rfc-editor.org/rfc/rfc5958>.
-
-
[RFC8174]
-
-Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
-
-
-
-
-
-
-

-11.2. Informative References -

-
-
[PQCProj]
-
-National Institute of Standards and Technology, "Post-Quantum Cryptography Project", , <https://csrc.nist.gov/projects/post-quantum-cryptography>.
-
-
[RFC7468]
-
-Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, , <https://www.rfc-editor.org/rfc/rfc7468>.
-
-
-
-
-
-
-
-

-Acknowledgments -

-

TODO acknowledge.

-
-
-
-
-

-Authors' Addresses -

-
-
Sean Turner
-
sn3rd
- -
-
-
Panos Kampanakis
-
AWS
- -
-
-
Jake Massimo
-
AWS
- -
-
-
Bas Westerbaan
-
Cloudflare
- -
-
-
- - - diff --git a/seanturner-asides/draft-turner-lamps-nist-pqc-kem-certificates.txt b/seanturner-asides/draft-turner-lamps-nist-pqc-kem-certificates.txt deleted file mode 100644 index 8ecd08c..0000000 --- a/seanturner-asides/draft-turner-lamps-nist-pqc-kem-certificates.txt +++ /dev/null @@ -1,354 +0,0 @@ - - - - -None S. Turner -Internet-Draft sn3rd -Intended status: Standards Track P. Kampanakis -Expires: 25 April 2024 J. Massimo - AWS - B. Westerbaan - Cloudflare - 23 October 2023 - - -Algorithm Identifiers for NIST's PQC Algorithms for Use in the Internet - X.509 Public Key Infrastructure - draft-turner-lamps-nist-pqc-kem-certificates-latest - -Abstract - - This document specifies algorithm identifiers and ASN.1 encoding - format for the US NIST's PQC KEM (United States National Institute of - Standards and Technology's Post Quantum Cryptography Key - Encapsulation Mechanism) algorithms. The algorithms covered are - Candidate TBD1. The encoding for public key and private key is also - provided. - - [EDNOTE: This draft is not expected to be finalized before the NIST - PQC Project has standardized PQ algorithms. After NIST has - standardized its first algorithms, this document will replace TBD, - with the appropriate algorithms and parameters before proceeding to - ratification. The algorithm Candidate TBD1 has been added as an - example in this draft, to provide a more detailed illustration of the - content - it by no means indicates its inclusion in the final - version. This specification will use object identifiers for the new - algorithms that are assigned by NIST, and will use placeholders until - these are released.] - -About This Document - - This note is to be removed before publishing as an RFC. - - Status information for this document may be found at - https://datatracker.ietf.org/doc/draft-turner-lamps-nist-pqc-kem- - certificates/. - - Discussion of this document takes place on the Limited Additional - Mechanisms for PKIX and SMIME (lamps) Working Group mailing list - (mailto:spasm@ietf.org), which is archived at - https://mailarchive.ietf.org/arch/browse/spasm/. Subscribe at - https://www.ietf.org/mailman/listinfo/spasm/. - - Source for this draft and an issue tracker can be found at - https://github.com/seanturner/draft-turner-lamps-nist-pqc-kem- - certificates. - -Status of This Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at https://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on 25 April 2024. - -Copyright Notice - - Copyright (c) 2023 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 Revised BSD License text as - described in Section 4.e of the Trust Legal Provisions and are - provided without warranty as described in the Revised BSD License. - -Table of Contents - - 1. Introduction - 2. Conventions and Definitions - 3. Algorithm Identifiers - 4. Candidate TBD1 - 5. Subject Public Key Fields - 6. Key Usage Bits - 7. Private Key Format - 8. ASN.1 Module - 9. Security Considerations - 10. IANA Considerations - 11. References - 11.1. Normative References - 11.2. Informative References - Acknowledgments - Authors' Addresses - -1. Introduction - - The US NIST PQC Project has selected the Candidate TBD1 algorithms as - winners of their PQC Project [PQCProj]. These algorithms are KEM - algorithms. NIST has also defined object identifiers for these - algorithms (TODO insert reference). - - This document specifies the use of the Candidate TBD1 algorithms in - X.509 public key certifiates, see [RFC5280]. It also specifies - private key encoding. An ASN.1 module is included for reference - purposes. - - These certificates could be used as Issuers in CMS where the public - key is used to encapsulate a shared secret used to derive a symmetric - key used to encrypt content in CMS [EDNOTE: Add reference draft- - perret-prat-lamps-cms-pq-kem]. To be used in TLS, these certificates - could only be used as end-entity identity certificates and would - require significant updates to the protocol [EDNOTE: Add reference - draft-celi-wiggers-tls-authkem]. - -2. Conventions and Definitions - - 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. 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 object identifier and optional parameters. - - The AlgorithmIdentifier type, which is included herein for - convenience, is defined as follows: - - AlgorithmIdentifier ::= SEQUENCE { - algorithm OBJECT IDENTIFIER, - parameters ANY DEFINED BY algorithm OPTIONAL - } - - | NOTE: The above syntax is from [RFC5280] and matches the - | version used therein, i.e., the 1988 ASN.1 syntax. See - | [RFC5912] for ASN.1 copmatible with the 2015 ASN.1 syntax. - - The fields in AlgorithmIdentifier have the following meanings: - - * algorithm identifies the cryptographic algorithm with an object - identifier. XXX such OIDs are defined in Sections Section 4. - - * parameters, which are optional, are the associated parameters for - the algorithm identifier in the algorithm field. - - In this document, TODO (specify number) new OIDs for identifying the - different algorithm and parameter pairs. For all of the object - identifiers, 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. - -4. Candidate TBD1 - - TODO insert object-identifiers - -5. 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 - } - - | NOTE: The above syntax is from [RFC5280] and matches the - | version used therein, i.e., the 1988 ASN.1 syntax. See - | [RFC5912] for ASN.1 copmatible with the 2015 ASN.1 syntax. - - The fields in SubjectPublicKeyInfo have the following meanings: - - * algorithm is the algorithm identifier and parameters for the - public key (see above). - - * subjectPublicKey contains the byte stream of the public key. The - algorithms defined in this document always encode the public key - as TODO pick format e.g., exact multiple of 8 bits?. - - The following is an example of a TBD public key encoded using the - textual encoding defined in [RFC7468]. - - -----BEGIN PUBLIC KEY----- - TODO insert example public key - -----END PUBLIC KEY------- - -6. Key Usage Bits - - The intended application for the key is indicated in the keyUsage - certificate extension; see Section 4.2.1.3 of [RFC5280]. - - If the keyUsage extension is present in a certificate that indicates - Candidate TBD1 in SubjectPublicKeyInfo, then the following MUST be - present: - - keyEncipherment; - -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 - - | NOTE: The above syntax is from [RFC5958] and matches the - | version used therein, i.e., the 2002 ASN.1 syntax. The syntax - | used therein is compatible with the 2015 ASN.1 syntax. - - For the keys defined in this document, the private key is always an - opaque byte sequence. The ASN.1 type PqckemPrivateKey is defined in - this document to hold the byte sequence. Thus, when encoding a - OneAsymmetricKey object, the private key is wrapped in a - PqckemPrivateKey object and wrapped by the OCTET STRING of the - "privateKey" field. - - PqckemPrivateKey ::= OCTET STRING - - The following is an example of a TBD private key encoded using the - textual encoding defined in [RFC7468]. - - -----BEGIN PRIVATE KEY----- - TODO iser example private key - -----END PRIVATE KEY------- - - The following example, in addition to encoding the TBD 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----- - TODO insert example private key with attribute - -----END PRIVATE KEY------- - - | NOTE: There exist some private key import functions that have - | not implemented the new ASN.1 structure OneAsymmetricKey that - | is defined in [RFC5958]. 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. ASN.1 Module - - TODO ASN.1 Module - -9. Security Considerations - - The Security Considerations section of [RFC5280] applies to this - specification as well. - - [EDNOTE: Discuss side-channels for Candidate TBD1.] - -10. IANA Considerations - - This document will have some IANA actions. - -11. References - -11.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, - . - - [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the - Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, - DOI 10.17487/RFC5912, June 2010, - . - - [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, - DOI 10.17487/RFC5958, August 2010, - . - - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC - 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 2017, . - -11.2. Informative References - - [PQCProj] National Institute of Standards and Technology, "Post- - Quantum Cryptography Project", 20 December 2016, - . - - [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, - PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, - April 2015, . - -Acknowledgments - - TODO acknowledge. - -Authors' Addresses - - Sean Turner - sn3rd - Email: sean@sn3rd.com - - - Panos Kampanakis - AWS - Email: kpanos@amazon.com - - - Jake Massimo - AWS - Email: jakemas@amazon.com - - - Bas Westerbaan - Cloudflare - Email: bas@westerbaan.name diff --git a/seanturner-asides/index.html b/seanturner-asides/index.html deleted file mode 100644 index 675ac79..0000000 --- a/seanturner-asides/index.html +++ /dev/null @@ -1,50 +0,0 @@ - - - - lamps-wg/kyber-certificates seanturner-asides preview - - - - -

Editor's drafts for seanturner-asides branch of lamps-wg/kyber-certificates

- - - - - - - - - - - -
PQC Kyber in Certificatesplain textsame as main
PQC KEM for Certificatesplain textsame as main
- - - diff --git a/seanturner-md-fix/draft-ietf-lamps-kyber-certificates.html b/seanturner-md-fix/draft-ietf-lamps-kyber-certificates.html deleted file mode 100644 index 7f2ad24..0000000 --- a/seanturner-md-fix/draft-ietf-lamps-kyber-certificates.html +++ /dev/null @@ -1,1635 +0,0 @@ - - - - - - -Internet X.509 Public Key Infrastructure - Algorithm Identifiers for Kyber - - - - - - - - - - - - - - - - - - - - - - - - - - -
Internet-DraftPQC Kyber in CertificatesNovember 2023
Turner, et al.Expires 8 May 2024[Page]
-
-
-
-
Workgroup:
-
LAMPS
-
Internet-Draft:
-
draft-ietf-lamps-kyber-certificates-latest
-
Published:
-
- -
-
Intended Status:
-
Standards Track
-
Expires:
-
-
Authors:
-
-
-
S. Turner
-
sn3rd
-
-
-
P. Kampanakis
-
AWS
-
-
-
J. Massimo
-
AWS
-
-
-
B. Westerbaan
-
Cloudflare
-
-
-
-
-

Internet X.509 Public Key Infrastructure - Algorithm Identifiers for Kyber

-
-

Abstract

-

Kyber is a key-encapsulation mechanism (KEM). This document specifies -algorithm identifiers and ASN.1 encoding format for Kyber in public -key certificates. The encoding for public and private keys are also -provided.

-

[EDNOTE: -This document is not expected to be finalized before the NIST PQC -Project has standardized PQ algorithms. This specification will use -object identifiers for the new algorithms that are assigned by NIST, -and will use placeholders until these are released.]

-
-
-

-About This Document -

-

This note is to be removed before publishing as an RFC.

-

- The latest revision of this draft can be found at https://lamps-wg.github.io/kyber-certificates/#go.draft-ietf-lamps-kyber-certificates.html. - Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-lamps-kyber-certificates/.

-

- Discussion of this document takes place on the - Limited Additional Mechanisms for PKIX and SMIME (lamps) Working Group mailing list (mailto:spasm@ietf.org), - which is archived at https://mailarchive.ietf.org/arch/browse/spasm/. - Subscribe at https://www.ietf.org/mailman/listinfo/spasm/.

-

Source for this draft and an issue tracker can be found at - https://github.com/lamps-wg/kyber-certificates.

-
-
-
-

-Status of This Memo -

-

- This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79.

-

- Internet-Drafts are working documents of the Internet Engineering Task - Force (IETF). Note that other groups may also distribute working - documents as Internet-Drafts. The list of current Internet-Drafts is - at https://datatracker.ietf.org/drafts/current/.

-

- Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress."

-

- This Internet-Draft will expire on 8 May 2024.

-
-
- - -
-
-

-1. Introduction -

-

Kyber is a key-encapsulation mechanism (KEM) standardized by the US NIST -PQC Project [PQCProj]. This document specifies the use of the Kyber -algorithm at three security levels: Kyber512, Kyber768, and Kyber1024, -in X.509 public key certificates; see [RFC5280]. Public and private -key encodings are also specified.

-
-
-

-1.1. ASN.1 and Kyber Identifiers -

-

An ASN.1 module [X680] is included for reference purposes. Note that -as per [RFC5280], certificates use the Distinguished Encoding Rules; -see [X690]. Also note that NIST defined the object identifiers for -the Kyber algorithms in an ASN.1 modulle; see (TODO insert reference).

-
-
-
-
-

-1.2. Applicability Statement -

-

Kyber certificates are used in protocols where the public key is used to -generate and encapsulate a shared secret used to derive a symmetric key used to -encrypt a payload; see [I-D.ietf-lamps-kyber]. To be used in -TLS, Kyber certificates could only be used as end-entity identity -certificates and would require significant updates to the protocol; see -[I-D.celi-wiggers-tls-authkem].

-
-
-
-
-
-
-

-2. Conventions and Definitions -

-

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. 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 object -identifier and optional parameters.

-

The AlgorithmIdentifier type, which is included herein for convenience, -is defined as follows:

-
-
-  AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::=
-    SEQUENCE {
-      algorithm   ALGORITHM-TYPE.&id({AlgorithmSet}),
-      parameters  ALGORITHM-TYPE.
-                    &Params({AlgorithmSet}{@algorithm}) OPTIONAL
-    }
-
-
- -

The fields in AlgorithmIdentifier have the following meanings:

-
    -
  • -

    algorithm identifies the cryptographic algorithm with an object -identifier.

    -
    • -
  • -

    parameters, which are optional, are the associated parameters for -the algorithm identifier in the algorithm field.

    -
    • -
-

Section 4 includes object identifiers for Kyber-512, Kyber-768, and -Kyber-1024. For all of these OIDs, the parameters MUST be absent.

- -
-
-
-
-

-4. Kyber Public Key Identifiers -

-

The AlgorithmIdentifier for a Kyber public key MUST use one of the -id-alg-kyber object identifiers listed below, based on the security -level. The parameters field of the AlgorithmIdentifier for the Kyber -public key MUST be absent.

-

When any of the Kyber AlgorithmIdentifier appears in the -SubjectPublicKeyInfo field of an X.509 certificate, the key usage -certificate extension MUST only contain keyEncipherment -Section 4.2.1.3 of [RFC5280].

-
-
-  pk-kyber-512 PUBLIC-KEY ::= {
-    IDENTIFIER id-alg-kyber-512
-    -- KEY no ASN.1 wrapping --
-    PARAMS ARE absent
-    CERT-KEY-USAGE
-      { keyEncipherment }
-    --- PRIVATE-KEY no ASN.1 wrapping --
-    }
-
-  pk-kyber-768 PUBLIC-KEY ::= {
-    IDENTIFIER id-alg-kyber-768
-    -- KEY no ASN.1 wrapping --
-    PARAMS ARE absent
-    CERT-KEY-USAGE
-      { keyEncipherment }
-    --- PRIVATE-KEY no ASN.1 wrapping --
-    }
-
-  pk-kyber-1024 PUBLIC-KEY ::= {
-    IDENTIFIER id-alg-kyber-1024
-    -- KEY no ASN.1 wrapping --
-    PARAMS ARE absent
-    CERT-KEY-USAGE
-      { keyEncipherment }
-    --- PRIVATE-KEY no ASN.1 wrapping --
-    }
-
-
- -
-
-
-
-

-5. Subject Public Key Fields -

-

In the X.509 certificate, the subjectPublicKeyInfo field has the -SubjectPublicKeyInfo type, which has the following ASN.1 syntax:

-
-
-  SubjectPublicKeyInfo {PUBLIC-KEY: IOSet} ::= SEQUENCE {
-      algorithm        AlgorithmIdentifier {PUBLIC-KEY, {IOSet}},
-      subjectPublicKey BIT STRING
-  }
-
-
- -

The fields in SubjectPublicKeyInfo have the following meaning:

-
    -
  • -

    algorithm is the algorithm identifier and parameters for the -public key (see above).

    -
    • -
  • -

    subjectPublicKey contains the byte stream of the public key. The -algorithms defined in this document always encode the public key -as TODO pick format e.g., exact multiple of 8 bits?.

    -
    • -
-

The following is an example of a Kyber-512 public key encoded using the -textual encoding defined in [RFC7468]:

-
-
-  -----BEGIN PUBLIC KEY-----
-  TODO insert example public key
-  -----END PUBLIC KEY-------
-
-
-
-
-
-
-

-6. 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      SEQUENCE {
-    algorithm                PUBLIC-KEY.&id({PublicKeySet}),
-    parameters               PUBLIC-KEY.&Params({PublicKeySet}
-                               {@privateKeyAlgorithm.algorithm})
-                                  OPTIONAL}
-    privateKey               OCTET STRING (CONTAINING
-                               PUBLIC-KEY.&PrivateKey({PublicKeySet}
-                                 {@privateKeyAlgorithm.algorithm})),
-    attributes           [0] Attributes OPTIONAL,
-    ...,
-    [[2: publicKey       [1] BIT STRING (CONTAINING
-                               PUBLIC-KEY.&Params({PublicKeySet}
-                                 {@privateKeyAlgorithm.algorithm})
-                                 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 PqckemPrivateKey is defined in -this document to hold the byte sequence. Thus, when encoding a -OneAsymmetricKey object, the private key is wrapped in a -PqckemPrivateKey object and wrapped by the OCTET STRING of the -"privateKey" field.

-
-
-  PqckemPrivateKey ::= OCTET STRING
-
-
-

The following is an example of a Kyber-512 private key encoded using the -textual encoding defined in [RFC7468]:

-
-
-  -----BEGIN PRIVATE KEY-----
-  TODO iser example private key
-  -----END PRIVATE KEY-------
-
-
-

The following example, in addition to encoding the Kyber-512 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-----
-  TODO insert example private key with attribute
-  -----END PRIVATE KEY-------
-
-
- -
-
-
-
-

-7. ASN.1 Module -

-

TODO ASN.1 Module

-
-
-
-
-

-8. Security Considerations -

-

The Security Considerations section of [RFC5280] applies to this specification as well.

- -
-
-
-
-

-9. IANA Considerations -

-

This document will have some IANA actions.

-
-
-
-

-10. References -

-
-
-

-10.1. Normative References -

-
-
[RFC2119]
-
-Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
-
-
[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, , <https://www.rfc-editor.org/rfc/rfc5280>.
-
-
[RFC5912]
-
-Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, , <https://www.rfc-editor.org/rfc/rfc5912>.
-
-
[RFC5958]
-
-Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 10.17487/RFC5958, , <https://www.rfc-editor.org/rfc/rfc5958>.
-
-
[RFC8174]
-
-Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
-
-
[X680]
-
-ITU-T, "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ISO/IEC 8824-1:2021, , <https://www.itu.int/rec/T-REC-X.680>.
-
-
[X690]
-
-ITU-T, "Information technology - Abstract Syntax Notation One (ASN.1): ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ISO/IEC 8825-1:2021, , <https://www.itu.int/rec/T-REC-X.690>.
-
-
-
-
-
-
-

-10.2. Informative References -

-
-
[I-D.celi-wiggers-tls-authkem]
-
-Wiggers, T., Celi, S., Schwabe, P., Stebila, D., and N. Sullivan, "KEM-based Authentication for TLS 1.3", Work in Progress, Internet-Draft, draft-celi-wiggers-tls-authkem-02, , <https://datatracker.ietf.org/doc/html/draft-celi-wiggers-tls-authkem-02>.
-
-
[I-D.ietf-lamps-kyber]
-
-Prat, J. and M. Ounsworth, "Use of KYBER in the Cryptographic Message Syntax (CMS)", Work in Progress, Internet-Draft, draft-ietf-lamps-kyber-00, , <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-kyber-00>.
-
-
[PQCProj]
-
-National Institute of Standards and Technology, "Post-Quantum Cryptography Project", , <https://csrc.nist.gov/projects/post-quantum-cryptography>.
-
-
[RFC7468]
-
-Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, , <https://www.rfc-editor.org/rfc/rfc7468>.
-
-
-
-
-
-
-
-

-Acknowledgments -

-

TODO acknowledge.

-
-
-
-
-

-Authors' Addresses -

-
-
Sean Turner
-
sn3rd
- -
-
-
Panos Kampanakis
-
AWS
- -
-
-
Jake Massimo
-
AWS
- -
-
-
Bas Westerbaan
-
Cloudflare
- -
-
-
- - - diff --git a/seanturner-md-fix/draft-ietf-lamps-kyber-certificates.txt b/seanturner-md-fix/draft-ietf-lamps-kyber-certificates.txt deleted file mode 100644 index 6a0a473..0000000 --- a/seanturner-md-fix/draft-ietf-lamps-kyber-certificates.txt +++ /dev/null @@ -1,415 +0,0 @@ - - - - -LAMPS S. Turner -Internet-Draft sn3rd -Intended status: Standards Track P. Kampanakis -Expires: 8 May 2024 J. Massimo - AWS - B. Westerbaan - Cloudflare - 5 November 2023 - - - Internet X.509 Public Key Infrastructure - Algorithm Identifiers for - Kyber - draft-ietf-lamps-kyber-certificates-latest - -Abstract - - Kyber is a key-encapsulation mechanism (KEM). This document - specifies algorithm identifiers and ASN.1 encoding format for Kyber - in public key certificates. The encoding for public and private keys - are also provided. - - [EDNOTE: This document is not expected to be finalized before the - NIST PQC Project has standardized PQ algorithms. This specification - will use object identifiers for the new algorithms that are assigned - by NIST, and will use placeholders until these are released.] - -About This Document - - This note is to be removed before publishing as an RFC. - - The latest revision of this draft can be found at https://lamps- - wg.github.io/kyber-certificates/#go.draft-ietf-lamps-kyber- - certificates.html. Status information for this document may be found - at https://datatracker.ietf.org/doc/draft-ietf-lamps-kyber- - certificates/. - - Discussion of this document takes place on the Limited Additional - Mechanisms for PKIX and SMIME (lamps) Working Group mailing list - (mailto:spasm@ietf.org), which is archived at - https://mailarchive.ietf.org/arch/browse/spasm/. Subscribe at - https://www.ietf.org/mailman/listinfo/spasm/. - - Source for this draft and an issue tracker can be found at - https://github.com/lamps-wg/kyber-certificates. - -Status of This Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at https://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on 8 May 2024. - -Copyright Notice - - Copyright (c) 2023 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 Revised BSD License text as - described in Section 4.e of the Trust Legal Provisions and are - provided without warranty as described in the Revised BSD License. - -Table of Contents - - 1. Introduction - 1.1. ASN.1 and Kyber Identifiers - 1.2. Applicability Statement - 2. Conventions and Definitions - 3. Algorithm Identifiers - 4. Kyber Public Key Identifiers - 5. Subject Public Key Fields - 6. Private Key Format - 7. ASN.1 Module - 8. Security Considerations - 9. IANA Considerations - 10. References - 10.1. Normative References - 10.2. Informative References - Acknowledgments - Authors' Addresses - -1. Introduction - - Kyber is a key-encapsulation mechanism (KEM) standardized by the US - NIST PQC Project [PQCProj]. This document specifies the use of the - Kyber algorithm at three security levels: Kyber512, Kyber768, and - Kyber1024, in X.509 public key certificates; see [RFC5280]. Public - and private key encodings are also specified. - -1.1. ASN.1 and Kyber Identifiers - - An ASN.1 module [X680] is included for reference purposes. Note that - as per [RFC5280], certificates use the Distinguished Encoding Rules; - see [X690]. Also note that NIST defined the object identifiers for - the Kyber algorithms in an ASN.1 modulle; see (TODO insert - reference). - -1.2. Applicability Statement - - Kyber certificates are used in protocols where the public key is used - to generate and encapsulate a shared secret used to derive a - symmetric key used to encrypt a payload; see [I-D.ietf-lamps-kyber]. - To be used in TLS, Kyber certificates could only be used as end- - entity identity certificates and would require significant updates to - the protocol; see [I-D.celi-wiggers-tls-authkem]. - -2. Conventions and Definitions - - 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. 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 object identifier and optional parameters. - - The AlgorithmIdentifier type, which is included herein for - convenience, is defined as follows: - - AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::= - SEQUENCE { - algorithm ALGORITHM-TYPE.&id({AlgorithmSet}), - parameters ALGORITHM-TYPE. - &Params({AlgorithmSet}{@algorithm}) OPTIONAL - } - - | NOTE: The above syntax is from [RFC5912] and is compatible with - | the 2021 ASN.1 syntax [X680]. - - The fields in AlgorithmIdentifier have the following meanings: - - * algorithm identifies the cryptographic algorithm with an object - identifier. - - * parameters, which are optional, are the associated parameters for - the algorithm identifier in the algorithm field. - - Section 4 includes object identifiers for Kyber-512, Kyber-768, and - Kyber-1024. For all of these OIDs, the parameters MUST be absent. - - | NOTE: 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. - -4. Kyber Public Key Identifiers - - The AlgorithmIdentifier for a Kyber public key MUST use one of the - id-alg-kyber object identifiers listed below, based on the security - level. The parameters field of the AlgorithmIdentifier for the Kyber - public key MUST be absent. - - When any of the Kyber AlgorithmIdentifier appears in the - SubjectPublicKeyInfo field of an X.509 certificate, the key usage - certificate extension MUST only contain keyEncipherment - Section 4.2.1.3 of [RFC5280]. - - pk-kyber-512 PUBLIC-KEY ::= { - IDENTIFIER id-alg-kyber-512 - -- KEY no ASN.1 wrapping -- - PARAMS ARE absent - CERT-KEY-USAGE - { keyEncipherment } - --- PRIVATE-KEY no ASN.1 wrapping -- - } - - pk-kyber-768 PUBLIC-KEY ::= { - IDENTIFIER id-alg-kyber-768 - -- KEY no ASN.1 wrapping -- - PARAMS ARE absent - CERT-KEY-USAGE - { keyEncipherment } - --- PRIVATE-KEY no ASN.1 wrapping -- - } - - pk-kyber-1024 PUBLIC-KEY ::= { - IDENTIFIER id-alg-kyber-1024 - -- KEY no ASN.1 wrapping -- - PARAMS ARE absent - CERT-KEY-USAGE - { keyEncipherment } - --- PRIVATE-KEY no ASN.1 wrapping -- - } - - | NOTE: As noted in Section 3, the values for these object - | identifers will be assigned by NIST. Once assigned, they will - | be added to a future revision of this document. - -5. Subject Public Key Fields - - In the X.509 certificate, the subjectPublicKeyInfo field has the - SubjectPublicKeyInfo type, which has the following ASN.1 syntax: - - SubjectPublicKeyInfo {PUBLIC-KEY: IOSet} ::= SEQUENCE { - algorithm AlgorithmIdentifier {PUBLIC-KEY, {IOSet}}, - subjectPublicKey BIT STRING - } - - | NOTE: The above syntax is from [RFC5912] and is compatible with - | the 2021 ASN.1 syntax [X680]. - - The fields in SubjectPublicKeyInfo have the following meaning: - - * algorithm is the algorithm identifier and parameters for the - public key (see above). - - * subjectPublicKey contains the byte stream of the public key. The - algorithms defined in this document always encode the public key - as TODO pick format e.g., exact multiple of 8 bits?. - - The following is an example of a Kyber-512 public key encoded using - the textual encoding defined in [RFC7468]: - - -----BEGIN PUBLIC KEY----- - TODO insert example public key - -----END PUBLIC KEY------- - -6. 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 SEQUENCE { - algorithm PUBLIC-KEY.&id({PublicKeySet}), - parameters PUBLIC-KEY.&Params({PublicKeySet} - {@privateKeyAlgorithm.algorithm}) - OPTIONAL} - privateKey OCTET STRING (CONTAINING - PUBLIC-KEY.&PrivateKey({PublicKeySet} - {@privateKeyAlgorithm.algorithm})), - attributes [0] Attributes OPTIONAL, - ..., - [[2: publicKey [1] BIT STRING (CONTAINING - PUBLIC-KEY.&Params({PublicKeySet} - {@privateKeyAlgorithm.algorithm}) - OPTIONAL, - ... - } - - PrivateKey ::= OCTET STRING - - PublicKey ::= BIT STRING - - | NOTE: The above syntax is from [RFC5958] and is compatible with - | the 2021 ASN.1 syntax [X680]. - - For the keys defined in this document, the private key is always an - opaque byte sequence. The ASN.1 type PqckemPrivateKey is defined in - this document to hold the byte sequence. Thus, when encoding a - OneAsymmetricKey object, the private key is wrapped in a - PqckemPrivateKey object and wrapped by the OCTET STRING of the - "privateKey" field. - - PqckemPrivateKey ::= OCTET STRING - - The following is an example of a Kyber-512 private key encoded using - the textual encoding defined in [RFC7468]: - - -----BEGIN PRIVATE KEY----- - TODO iser example private key - -----END PRIVATE KEY------- - - The following example, in addition to encoding the Kyber-512 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----- - TODO insert example private key with attribute - -----END PRIVATE KEY------- - - | NOTE: There exist some private key import functions that have - | not implemented the new ASN.1 structure OneAsymmetricKey that - | is defined in [RFC5958]. 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. - -7. ASN.1 Module - - TODO ASN.1 Module - -8. Security Considerations - - The Security Considerations section of [RFC5280] applies to this - specification as well. - - | To Do: Discuss side-channels for Kyber TBD1. - -9. IANA Considerations - - This document will have some IANA actions. - -10. References - -10.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, - . - - [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the - Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, - DOI 10.17487/RFC5912, June 2010, - . - - [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, - DOI 10.17487/RFC5958, August 2010, - . - - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC - 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 2017, . - - [X680] ITU-T, "Information technology - Abstract Syntax Notation - One (ASN.1): Specification of basic notation", ISO/ - IEC 8824-1:2021, February 2021, - . - - [X690] ITU-T, "Information technology - Abstract Syntax Notation - One (ASN.1): ASN.1 encoding rules: Specification of Basic - Encoding Rules (BER), Canonical Encoding Rules (CER) and - Distinguished Encoding Rules (DER)", ISO/IEC 8825-1:2021, - February 2021, . - -10.2. Informative References - - [I-D.celi-wiggers-tls-authkem] - Wiggers, T., Celi, S., Schwabe, P., Stebila, D., and N. - Sullivan, "KEM-based Authentication for TLS 1.3", Work in - Progress, Internet-Draft, draft-celi-wiggers-tls-authkem- - 02, 18 August 2023, - . - - [I-D.ietf-lamps-kyber] - Prat, J. and M. Ounsworth, "Use of KYBER in the - Cryptographic Message Syntax (CMS)", Work in Progress, - Internet-Draft, draft-ietf-lamps-kyber-00, 10 November - 2022, . - - [PQCProj] National Institute of Standards and Technology, "Post- - Quantum Cryptography Project", 20 December 2016, - . - - [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, - PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, - April 2015, . - -Acknowledgments - - TODO acknowledge. - -Authors' Addresses - - Sean Turner - sn3rd - Email: sean@sn3rd.com - - - Panos Kampanakis - AWS - Email: kpanos@amazon.com - - - Jake Massimo - AWS - Email: jakemas@amazon.com - - - Bas Westerbaan - Cloudflare - Email: bas@westerbaan.name diff --git a/seanturner-md-fix/index.html b/seanturner-md-fix/index.html deleted file mode 100644 index 9213591..0000000 --- a/seanturner-md-fix/index.html +++ /dev/null @@ -1,50 +0,0 @@ - - - - lamps-wg/kyber-certificates seanturner-md-fix preview - - - - -

Editor's drafts for seanturner-md-fix branch of lamps-wg/kyber-certificates

- - - - - - - - - - - -
PQC Kyber in Certificatesplain textsame as main
PQC KEM for Certificatesplain textsame as main
- - - diff --git a/draft-ietf-lamps-kyber-certificates-02/draft-ietf-lamps-kyber-certificates.html b/seanturner-name-change/draft-ietf-lamps-kyber-certificates.html similarity index 92% rename from draft-ietf-lamps-kyber-certificates-02/draft-ietf-lamps-kyber-certificates.html rename to seanturner-name-change/draft-ietf-lamps-kyber-certificates.html index 63e1820..b2dd06b 100644 --- a/draft-ietf-lamps-kyber-certificates-02/draft-ietf-lamps-kyber-certificates.html +++ b/seanturner-name-change/draft-ietf-lamps-kyber-certificates.html @@ -4,40 +4,41 @@ -Internet X.509 Public Key Infrastructure - Algorithm Identifiers for Kyber +Internet X.509 Public Key Infrastructure - Algorithm Identifiers for Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) - + @@ -1035,12 +1036,12 @@ - - + + - +
Internet-DraftPQC Kyber in CertificatesOctober 2023ML-KEM in CertificatesDecember 2023
Turner, et al.Expires 25 April 2024Expires 22 June 2024 [Page]
@@ -1053,12 +1054,12 @@
draft-ietf-lamps-kyber-certificates-latest
Published:
- +
Intended Status:
Standards Track
Expires:
-
+
Authors:
@@ -1080,13 +1081,14 @@
-

Internet X.509 Public Key Infrastructure - Algorithm Identifiers for Kyber

+

Internet X.509 Public Key Infrastructure - Algorithm Identifiers for Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM)

Abstract

-

Kyber is a key-encapsulation mechanism (KEM). This document specifies -algorithm identifiers and ASN.1 encoding format for Kyber in public -key certificates. The encoding for public and private keys are also -provided.

+

Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM), also +known as Kyber, is a key-encapsulation mechanism (KEM). This +document specifies algorithm identifiers and ASN.1 encoding +format for ML-KEM in public key certificates. The encoding for +public and private keys are also provided.

\ [EDNOTE: This document is not expected to be finalized before the NIST PQC Project has standardized PQ algorithms. This specification will use @@ -1128,7 +1130,7 @@

time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

- This Internet-Draft will expire on 25 April 2024.

+ This Internet-Draft will expire on 22 June 2024.

-
+
-

-4. Kyber Public Key Identifiers +

+4. ML-KEM Public Key Identifiers

-

The AlgorithmIdentifier for a Kyber public key MUST use one of the -id-alg-kyber object identifiers listed below, based on the security -level. The parameters field of the AlgorithmIdentifier for the Kyber +

The AlgorithmIdentifier for a ML-KEM public key MUST use one of the +id-alg-ml-kem object identifiers listed below, based on the security +level. The parameters field of the AlgorithmIdentifier for the ML-KEM public key MUST be absent.

-

When any of the Kyber AlgorithmIdentifier appears in the +

When any of the ML-KEM AlgorithmIdentifier appears in the SubjectPublicKeyInfo field of an X.509 certificate, the key usage certificate extension MUST only contain keyEncipherment Section 4.2.1.3 of [RFC5280].

-  pk-kyber-512 PUBLIC-KEY ::= {
-    IDENTIFIER id-alg-kyber-512
+  pk-ml-kem-512 PUBLIC-KEY ::= {
+    IDENTIFIER id-alg-ml-kem-512
     -- KEY no ASN.1 wrapping --
     PARAMS ARE absent
     CERT-KEY-USAGE
@@ -1332,8 +1335,8 @@ 

     --- PRIVATE-KEY no ASN.1 wrapping --
     }
 
-  pk-kyber-768 PUBLIC-KEY ::= {
-    IDENTIFIER id-alg-kyber-768
+  pk-ml-kem-768 PUBLIC-KEY ::= {
+    IDENTIFIER id-alg-ml-kem-768
     -- KEY no ASN.1 wrapping --
     PARAMS ARE absent
     CERT-KEY-USAGE
@@ -1341,8 +1344,8 @@ 

     --- PRIVATE-KEY no ASN.1 wrapping --
     }
 
-  pk-kyber-1024 PUBLIC-KEY ::= {
-    IDENTIFIER id-alg-kyber-1024
+  pk-ml-kem-1024 PUBLIC-KEY ::= {
+    IDENTIFIER id-alg-ml-kem-1024
     -- KEY no ASN.1 wrapping --
     PARAMS ARE absent
     CERT-KEY-USAGE
@@ -1389,7 +1392,7 @@ 

 as TODO pick format e.g., exact multiple of 8 bits?.

 
       
-
The following is an example of a Kyber-512 public key encoded using the
+
The following is an example of a ML-KEM-512 public key encoded using the
 textual encoding defined in [RFC7468]:

 

 
@@ -1453,7 +1456,7 @@ 

   PqckemPrivateKey ::= OCTET STRING
 

 

-
The following is an example of a Kyber-512 private key encoded using the
+
The following is an example of a ML-KEM-512 private key encoded using the
 textual encoding defined in [RFC7468]:

 

 
@@ -1462,7 +1465,7 @@ 

   -----END PRIVATE KEY-------
 

 

-
The following example, in addition to encoding the Kyber-512 private key,
+
The following example, in addition to encoding the ML-KEM-512 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:

 

@@ -1496,7 +1499,7 @@ 

 8. Security Considerations
       

 
The Security Considerations section of [RFC5280] applies to this specification as well.

-
[EDNOTE: Discuss side-channels for Kyber TBD1.]

+
[EDNOTE: Discuss side-channels for ML-KEM TBD1.]
@@ -1554,6 +1557,10 @@

10.2. Informative References

+
[DRAFTFIPS203]
+
+National Institute of Standards and Technology (NIST), "DRAFT Module-Lattice-based Key-Encapsulation Mechanism Standard", FIPS PUB 203, , <https://csrc.nist.gov/projects/post-quantum-cryptography>.
+
[I-D.celi-wiggers-tls-authkem]
Wiggers, T., Celi, S., Schwabe, P., Stebila, D., and N. Sullivan, "KEM-based Authentication for TLS 1.3", Work in Progress, Internet-Draft, draft-celi-wiggers-tls-authkem-02, , <https://datatracker.ietf.org/doc/html/draft-celi-wiggers-tls-authkem-02>.
@@ -1562,10 +1569,6 @@

Prat, J. and M. Ounsworth, "Use of KYBER in the Cryptographic Message Syntax (CMS)", Work in Progress, Internet-Draft, draft-ietf-lamps-kyber-00, , <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-kyber-00>.
-
[PQCProj]
-
-National Institute of Standards and Technology, "Post-Quantum Cryptography Project", , <https://csrc.nist.gov/projects/post-quantum-cryptography>.
-
[RFC7468]
Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, , <https://www.rfc-editor.org/rfc/rfc7468>.
diff --git a/seanturner-asides/draft-ietf-lamps-kyber-certificates.txt b/seanturner-name-change/draft-ietf-lamps-kyber-certificates.txt similarity index 85% rename from seanturner-asides/draft-ietf-lamps-kyber-certificates.txt rename to seanturner-name-change/draft-ietf-lamps-kyber-certificates.txt index e4dfe0b..8452498 100644 --- a/seanturner-asides/draft-ietf-lamps-kyber-certificates.txt +++ b/seanturner-name-change/draft-ietf-lamps-kyber-certificates.txt @@ -5,21 +5,22 @@ LAMPS S. Turner Internet-Draft sn3rd Intended status: Standards Track P. Kampanakis -Expires: 25 April 2024 J. Massimo +Expires: 22 June 2024 J. Massimo AWS B. Westerbaan Cloudflare - 23 October 2023 + 20 December 2023 Internet X.509 Public Key Infrastructure - Algorithm Identifiers for - Kyber + Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) draft-ietf-lamps-kyber-certificates-latest Abstract - Kyber is a key-encapsulation mechanism (KEM). This document - specifies algorithm identifiers and ASN.1 encoding format for Kyber + Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM), also known + as Kyber, is a key-encapsulation mechanism (KEM). This document + specifies algorithm identifiers and ASN.1 encoding format for ML-KEM in public key certificates. The encoding for public and private keys are also provided. @@ -62,7 +63,7 @@ Status of This Memo time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 25 April 2024. + This Internet-Draft will expire on 22 June 2024. Copyright Notice @@ -81,11 +82,11 @@ Copyright Notice Table of Contents 1. Introduction - 1.1. ASN.1 and Kyber Identifiers + 1.1. ASN.1 and ML-KEM Identifiers 1.2. Applicability Statement 2. Conventions and Definitions 3. Algorithm Identifiers - 4. Kyber Public Key Identifiers + 4. ML-KEM Public Key Identifiers 5. Subject Public Key Fields 6. Private Key Format 7. ASN.1 Module @@ -99,26 +100,27 @@ Table of Contents 1. Introduction - Kyber is a key-encapsulation mechanism (KEM) standardized by the US - NIST PQC Project [PQCProj]. This document specifies the use of the - Kyber algorithm at three security levels: Kyber512, Kyber768, and - Kyber1024, in X.509 public key certificates; see [RFC5280]. Public - and private key encodings are also specified. + Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM), also known + as Kyber, is a key-encapsulation mechanism (KEM) standardized by the + US NIST PQC Project [DRAFTFIPS203]. This document specifies the use + of the ML-KEM algorithm at three security levels: ML-KEM-512, ML-KEM- + 768, and ML-KEM-1024, in X.509 public key certificates; see + [RFC5280]. Public and private key encodings are also specified. -1.1. ASN.1 and Kyber Identifiers +1.1. ASN.1 and ML-KEM Identifiers An ASN.1 module [X680] is included for reference purposes. Note that as per [RFC5280], certificates use the Distinguished Encoding Rules; see [X690]. Also note that NIST defined the object identifiers for - the Kyber algorithms in an ASN.1 modulle; see (TODO insert + the ML-KEM algorithms in an ASN.1 modulle; see (TODO insert reference). 1.2. Applicability Statement - Kyber certificates are used in protocols where the public key is used - to generate and encapsulate a shared secret used to derive a + ML-KEM certificates are used in protocols where the public key is + used to generate and encapsulate a shared secret used to derive a symmetric key used to encrypt a payload; see [I-D.ietf-lamps-kyber]. - To be used in TLS, Kyber certificates could only be used as end- + To be used in TLS, ML-KEM certificates could only be used as end- entity identity certificates and would require significant updates to the protocol; see [I-D.celi-wiggers-tls-authkem]. @@ -158,8 +160,8 @@ Table of Contents * parameters, which are optional, are the associated parameters for the algorithm identifier in the algorithm field. - Section 4 includes object identifiers for Kyber-512, Kyber-768, and - Kyber-1024. For all of these OIDs, the parameters MUST be absent. + Section 4 includes object identifiers for ML-KEM-512, ML-KEM-768, and + ML-KEM-1024. For all of these 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 @@ -169,20 +171,20 @@ Table of Contents | be restricted to that subsystem and not propagated to the | Internet. -4. Kyber Public Key Identifiers +4. ML-KEM Public Key Identifiers - The AlgorithmIdentifier for a Kyber public key MUST use one of the - id-alg-kyber object identifiers listed below, based on the security - level. The parameters field of the AlgorithmIdentifier for the Kyber - public key MUST be absent. + The AlgorithmIdentifier for a ML-KEM public key MUST use one of the + id-alg-ml-kem object identifiers listed below, based on the security + level. The parameters field of the AlgorithmIdentifier for the ML- + KEM public key MUST be absent. - When any of the Kyber AlgorithmIdentifier appears in the + When any of the ML-KEM AlgorithmIdentifier appears in the SubjectPublicKeyInfo field of an X.509 certificate, the key usage certificate extension MUST only contain keyEncipherment Section 4.2.1.3 of [RFC5280]. - pk-kyber-512 PUBLIC-KEY ::= { - IDENTIFIER id-alg-kyber-512 + pk-ml-kem-512 PUBLIC-KEY ::= { + IDENTIFIER id-alg-ml-kem-512 -- KEY no ASN.1 wrapping -- PARAMS ARE absent CERT-KEY-USAGE @@ -190,8 +192,8 @@ Table of Contents --- PRIVATE-KEY no ASN.1 wrapping -- } - pk-kyber-768 PUBLIC-KEY ::= { - IDENTIFIER id-alg-kyber-768 + pk-ml-kem-768 PUBLIC-KEY ::= { + IDENTIFIER id-alg-ml-kem-768 -- KEY no ASN.1 wrapping -- PARAMS ARE absent CERT-KEY-USAGE @@ -199,8 +201,8 @@ Table of Contents --- PRIVATE-KEY no ASN.1 wrapping -- } - pk-kyber-1024 PUBLIC-KEY ::= { - IDENTIFIER id-alg-kyber-1024 + pk-ml-kem-1024 PUBLIC-KEY ::= { + IDENTIFIER id-alg-ml-kem-1024 -- KEY no ASN.1 wrapping -- PARAMS ARE absent CERT-KEY-USAGE @@ -234,7 +236,7 @@ Table of Contents algorithms defined in this document always encode the public key as TODO pick format e.g., exact multiple of 8 bits?. - The following is an example of a Kyber-512 public key encoded using + The following is an example of a ML-KEM-512 public key encoded using the textual encoding defined in [RFC7468]: -----BEGIN PUBLIC KEY----- @@ -286,14 +288,14 @@ Table of Contents PqckemPrivateKey ::= OCTET STRING - The following is an example of a Kyber-512 private key encoded using + The following is an example of a ML-KEM-512 private key encoded using the textual encoding defined in [RFC7468]: -----BEGIN PRIVATE KEY----- TODO iser example private key -----END PRIVATE KEY------- - The following example, in addition to encoding the Kyber-512 private + The following example, in addition to encoding the ML-KEM-512 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: @@ -318,7 +320,7 @@ Table of Contents The Security Considerations section of [RFC5280] applies to this specification as well. - [EDNOTE: Discuss side-channels for Kyber TBD1.] + [EDNOTE: Discuss side-channels for ML-KEM TBD1.] 9. IANA Considerations @@ -365,6 +367,13 @@ Table of Contents 10.2. Informative References + [DRAFTFIPS203] + National Institute of Standards and Technology (NIST), + "DRAFT Module-Lattice-based Key-Encapsulation Mechanism + Standard", FIPS PUB 203, August 2023, + . + [I-D.celi-wiggers-tls-authkem] Wiggers, T., Celi, S., Schwabe, P., Stebila, D., and N. Sullivan, "KEM-based Authentication for TLS 1.3", Work in @@ -380,11 +389,6 @@ Table of Contents 2022, . - [PQCProj] National Institute of Standards and Technology, "Post- - Quantum Cryptography Project", 20 December 2016, - . - [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, April 2015, . diff --git a/seanturner-md-fix/draft-turner-lamps-nist-pqc-kem-certificates.html b/seanturner-name-change/draft-turner-lamps-nist-pqc-kem-certificates.html similarity index 99% rename from seanturner-md-fix/draft-turner-lamps-nist-pqc-kem-certificates.html rename to seanturner-name-change/draft-turner-lamps-nist-pqc-kem-certificates.html index 666049c..6aed7eb 100644 --- a/seanturner-md-fix/draft-turner-lamps-nist-pqc-kem-certificates.html +++ b/seanturner-name-change/draft-turner-lamps-nist-pqc-kem-certificates.html @@ -26,24 +26,24 @@ use object identifiers for the new algorithms that are assigned by NIST, and will use placeholders until these are released.] " name="description"> - + @@ -1042,11 +1042,11 @@ Internet-Draft PQC KEM for Certificates -November 2023 +December 2023 Turner, et al. -Expires 8 May 2024 +Expires 22 June 2024 [Page] @@ -1059,12 +1059,12 @@
draft-turner-lamps-nist-pqc-kem-certificates-latest
Published:
- +
Intended Status:
Standards Track
Expires:
-
+
Authors:
@@ -1139,7 +1139,7 @@

time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

- This Internet-Draft will expire on 8 May 2024.

+ This Internet-Draft will expire on 22 June 2024.