View saved issues, or the latest GitHub issues and pull requests in the repo.
| ML-KEM in Certificates | +plain text | +datatracker | +diff with last submission | ++ |
| PQC KEM for Certificates | plain text | @@ -23,37 +30,43 @@
| ML-KEM in Certificates | +plain text | +diff with main | +|||||
| ML-KEM in Certificates | -plain text | -datatracker | -diff with last submission | -+ | PQC KEM for Certificates | +plain text | +diff with main |
| PQC KEM for Certificates | -plain text | +ML-KEM in Certificates | +plain text | same as main |
| ML-KEM in Certificates | -plain text | +PQC KEM for Certificates | +plain text | same as main |
| PQC KEM for Certificates | -plain text | +ML-KEM in Certificates | +plain text | same as main |
| ML-KEM in Certificates | -plain text | +PQC KEM for Certificates | +plain text | same as main |
| Internet-Draft | +ML-KEM in Certificates | +October 2024 | +
| Turner, et al. | +Expires 18 April 2025 | +[Page] | +
Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a +quantum-resistant 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.¶
+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.¶
++ 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 18 April 2025.¶
++ Copyright (c) 2024 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.¶
+Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM), previously +known as known as Kyber, is a quantum-resistant key-encapsulation +mechanism (KEM) standardized by the US NIST PQC Project [NIST-PQC] +in [DRAFTFIPS203]. This document specifies the use of ML-KEM in Public +Key Infrastructure X.509 (PKIX) certificates [RFC5280] at three +security levels: ML-KEM-512, ML-KEM-768, and ML-KEM-1024, using object +identifiers assigned by NIST.¶
+This specification includes conventions for the subjectPublicKeyInfo +field within Internet X.509 certificates [RFC5280], like [RFC3279] +did for classic cryptography and [RFC5480] did for elliptic curve +cryptography. The private key format is also specified.¶
+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 ML-KEM algorithms in an ASN.1 module; see (TODO insert reference).¶
+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, 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].¶
+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.¶
+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.¶
+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 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-ml-kem-512 PUBLIC-KEY ::= {
+ IDENTIFIER id-alg-ml-kem-512
+ -- KEY no ASN.1 wrapping --
+ PARAMS ARE absent
+ CERT-KEY-USAGE { keyEncipherment }
+ --- PRIVATE-KEY no ASN.1 wrapping --
+ }
+
+ pk-ml-kem-768 PUBLIC-KEY ::= {
+ IDENTIFIER id-alg-ml-kem-768
+ -- KEY no ASN.1 wrapping --
+ PARAMS ARE absent
+ CERT-KEY-USAGE { keyEncipherment }
+ --- PRIVATE-KEY no ASN.1 wrapping --
+ }
+
+ pk-ml-kem-1024 PUBLIC-KEY ::= {
+ IDENTIFIER id-alg-ml-kem-1024
+ -- KEY no ASN.1 wrapping --
+ PARAMS ARE absent
+ CERT-KEY-USAGE { keyEncipherment }
+ --- PRIVATE-KEY no ASN.1 wrapping --
+ }
+¶
+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?.¶
+{example-public} contains an example of an id-alg-ml-kem-768 public key +encoded using the textual encoding defined in [RFC7468].¶
+"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 +¶ +
{example-private} contains an example of an id-alg-ml-kem-768 private key +encoded using the textual encoding defined in [RFC7468].¶
+TODO ASN.1 Module¶
+The Security Considerations section of [RFC5280] applies to this specification as well.¶
+ +This document will have some IANA actions.¶
+This appendix contains examples of ML-KEN public keys, private keys and certificates.¶
+The following is an example of a ML-KEM-512 public key:¶
++ -----BEGIN PUBLIC KEY----- + TODO insert example public key + -----END PUBLIC KEY------- +¶ +
The following is an example of a ML-KEM-512 private key:¶
++ -----BEGIN PRIVATE KEY----- + TODO insert example private key + -----END 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:¶
++ -----BEGIN PRIVATE KEY----- + TODO insert example private key with attribute + -----END PRIVATE KEY------- +¶ +
+ TODO insert ASN.1 Pretty Print +¶ +
+ -----BEGIN CERTIFICATE----- + TODO Certificate + -----END CERTIFICATE------- +¶ +
TODO acknowledge.¶
+| Internet-Draft | +PQC KEM for Certificates | +October 2024 | +
| Turner, et al. | +Expires 18 April 2025 | +[Page] | +
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.]¶
+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.¶
++ 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 18 April 2025.¶
++ Copyright (c) 2024 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.¶
+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].¶
+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.¶
+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.¶
+TODO insert object-identifiers¶
+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------- +¶ +
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; +¶ +
"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------- +¶ +
TODO ASN.1 Module¶
+The Security Considerations section of [RFC5280] applies to this specification as well.¶
+[EDNOTE: Discuss side-channels for Candidate TBD1.]¶
+This document will have some IANA actions.¶
+TODO acknowledge.¶
+| ML-KEM in Certificates | +plain text | +same as main | +
| PQC KEM for Certificates | +plain text | +same as main | +