Subject: [lamps] Fwd: New Version Notification for draft-turner-lamps-nist-pqc-kem-certificates-01.txt

From: Sean Turner <[email-masked]>
Date: Tue, 15 Mar 2022 13:31:59 -0400

Hi! Here’s a 1st draft [0] of the I-D [1] we discussed @ IETF 112 (and that we will discuss again @ IETF 113) that will document algorithm identifiers and ASN.1 encoding format for the US NIST's PQC KEM algorithms. A couple of things to note:

- I want to welcome my co-authors:
Panos Kampanakis, Jake Massimo, and Bas Westerbaan

- Reminder: We are planning to use the algorithm identifiers assigned by NIST

- Based on some comments from Mike O. I updated the key usage section to show “keyEncipherment” vs “keyAgreement”.

While discussing this I-D with my co-authors they wonder whether we should include all of NISTs PQ algorithms, not just the KEM ones but also the signature algorithms, in one I-D or have separate I-Ds for each. While I like the idea of a one stop I-D that doesn’t really seem like an iron clad rationale nor does "that’s we did for RFC 3279". I know Panos and Jake has some other reasons for wanting to keep them separate (I don’t want to steal their thunder). So, this version of the I-D, despite it’s name, does take the one candidate, Candidate TBD1, approach.

Thoughts the one I-D to rule them all or separate I-Ds?

In this I-D, I also included the Private Key format, like RFC 8410 did. Panos wondered whether we really need the Private Key section, and frankly we don’t because these are not sent on wire and I was just trying to avoid another I-D to do the RFC 7468 textual encodings. Granted Bas also pointed out [2] that there are likely some choices to be made. I am certainly not wed to having the section in the I-D.

Thoughts on including the private key format (aka textual format)?

For the next version, I suspect we’ll pick one of the candidate and start filling it in.

Cheers,
spt

[0] You’ll note this is a -01. I had to make minor corrections from the -00.
[1] https://github.com/seanturner/draft-turner-lamps-nist-pqc-kem-certificates
[2] https://github.com/seanturner/draft-turner-lamps-nist-pqc-kem-certificates/issues/1

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-turner-lamps-nist-pqc-kem-certificates-01.txt
> Date: March 7, 2022 at 14:20:47 EST
> To: "Bas Westerbaan" <[email-masked]>, "Jake Massimo" <[email-masked]>, "Panos Kampanakis" <[email-masked]>, "Sean Turner" <[email-masked]>
> 
> 
> A new version of I-D, draft-turner-lamps-nist-pqc-kem-certificates-01.txt
> has been successfully submitted by Sean Turner and posted to the
> IETF repository.
> 
> Name:		draft-turner-lamps-nist-pqc-kem-certificates
> Revision:	01
> Title:		Algorithm Identifiers for NIST's PQC Algorithms for Use in the Internet X.509 Public Key Infrastructure
> Document date:	2022-03-07
> Group:		Individual Submission
> Pages:		8
> URL:            https://www.ietf.org/archive/id/draft-turner-lamps-nist-pqc-kem-certificates-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-turner-lamps-nist-pqc-kem-certificates/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-turner-lamps-nist-pqc-kem-certificates
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-turner-lamps-nist-pqc-kem-certificates-01
> 
> 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.]
> 
> 
> 
> 
> The IETF Secretariat
> 
>

---

From: Mike Ounsworth <[email-masked]>
Date: Tue, 15 Mar 2022 18:03:44 +0000

Thank you for starting this work Sean, Panos, Jake, and Bas!

Comments:

> Thoughts the one I-D to rule them [sigs + kems] all or separate I-Ds?

No strong opinion, though while we’re all eagerly awaiting NIST PQC Round 3 results, I expect KEMs will move to standardization after Round 3, while signatures will go to a Round 4 or even a new call for proposals. So I would vote for moving forward with KEMs while the signature mess sorts itself out.

> Private keys

Are there any examples in any LAMPS-owned standard where a private key goes over the wire? Certainly those encodings needs to be standardizes for the benefit of PKCS#12, PEM, etc, but I guess the question is whether LAMPS is the right body to do it?

---
Mike Ounsworth

From: Spasm <[email-masked]> On Behalf Of Sean Turner
Sent: March 15, 2022 12:32 PM
To: SPASM <[email-masked]>
Subject: [EXTERNAL] [lamps] Fwd: New Version Notification for draft-turner-lamps-nist-pqc-kem-certificates-01.txt

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
Hi! Here’s a 1st draft [0] of the I-D [1] we discussed @ IETF 112 (and that we will discuss again @ IETF 113) that will document algorithm identifiers and ASN.1 encoding format for the US NIST's PQC KEM algorithms. A couple of things to note:

Cheers,
spt

[0] You’ll note this is a -01. I had to make minor corrections from the -00.
[1] https://github.com/seanturner/draft-turner-lamps-nist-pqc-kem-certificates<https://urldefense.com/v3/__https:/github.com/seanturner/draft-turner-lamps-nist-pqc-kem-certificates__;!!FJ-Y8qCqXTj2!L5wYU9IKBlHF5uXUSY_y-BMiFFfeDf2s_VuZTY-A7fWiemd45_3R1dPrTRfEtJeHFZgvYUtfgg$>
[2] https://github.com/seanturner/draft-turner-lamps-nist-pqc-kem-certificates/issues/1<https://urldefense.com/v3/__https:/github.com/seanturner/draft-turner-lamps-nist-pqc-kem-certificates/issues/1__;!!FJ-Y8qCqXTj2!L5wYU9IKBlHF5uXUSY_y-BMiFFfeDf2s_VuZTY-A7fWiemd45_3R1dPrTRfEtJeHFZjXESduTQ$>

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: New Version Notification for draft-turner-lamps-nist-pqc-kem-certificates-01.txt
Date: March 7, 2022 at 14:20:47 EST
To: "Bas Westerbaan" <[email-masked]<mailto:[email-masked]>>, "Jake Massimo" <[email-masked]<mailto:[email-masked]>>, "Panos Kampanakis" <[email-masked]<mailto:[email-masked]>>, "Sean Turner" <[email-masked]<mailto:[email-masked]>>

Name:                 draft-turner-lamps-nist-pqc-kem-certificates
Revision:            01
Title:                    Algorithm Identifiers for NIST's PQC Algorithms for Use in the Internet X.509 Public Key Infrastructure
Document date:              2022-03-07
Group:                Individual Submission
Pages:                 8
URL:            https://www.ietf.org/archive/id/draft-turner-lamps-nist-pqc-kem-certificates-01.txt<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-turner-lamps-nist-pqc-kem-certificates-01.txt__;!!FJ-Y8qCqXTj2!L5wYU9IKBlHF5uXUSY_y-BMiFFfeDf2s_VuZTY-A7fWiemd45_3R1dPrTRfEtJeHFZj-8P8bng$>
Status:         https://datatracker.ietf.org/doc/draft-turner-lamps-nist-pqc-kem-certificates/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-turner-lamps-nist-pqc-kem-certificates/__;!!FJ-Y8qCqXTj2!L5wYU9IKBlHF5uXUSY_y-BMiFFfeDf2s_VuZTY-A7fWiemd45_3R1dPrTRfEtJeHFZgeM3fjyg$>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-turner-lamps-nist-pqc-kem-certificates<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-turner-lamps-nist-pqc-kem-certificates__;!!FJ-Y8qCqXTj2!L5wYU9IKBlHF5uXUSY_y-BMiFFfeDf2s_VuZTY-A7fWiemd45_3R1dPrTRfEtJeHFZgiSMCHwg$>
Diff:           https://www.ietf.org/rfcdiff?url2=draft-turner-lamps-nist-pqc-kem-certificates-01<https://urldefense.com/v3/__https:/www.ietf.org/rfcdiff?url2=draft-turner-lamps-nist-pqc-kem-certificates-01__;!!FJ-Y8qCqXTj2!L5wYU9IKBlHF5uXUSY_y-BMiFFfeDf2s_VuZTY-A7fWiemd45_3R1dPrTRfEtJeHFZinQ3XAFA$>

Abstract:

The IETF Secretariat

Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 15 Mar 2022 18:06:03 +0000

Hi Sean,

On 15/03/2022 17:31, Sean Turner wrote:
  [snip]
> In this I-D, I also included the Private Key format, like RFC 8410 
> did. Panos wondered whether we really need the Private Key section, 
> and frankly we don’t because these are not sent on wire and I was just 
> trying to avoid another I-D to do the RFC 7468 textual encodings. 
> Granted Bas also pointed out [2] that there are likely some choices to 
> be made. I am certainly not wed to having the section in the I-D.
>

Yes, please. This would be needed by implementations that use PEM-like 
formats.

Best Regards,

Alexey

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 15 Mar 2022 18:09:27 +0000

Strongly agree.  It's not just wire format but configuration

On 3/15/22, 2:06 PM, "Alexey Melnikov" <[email-masked]> wrote:

    Hi Sean,

    Best Regards,

    Alexey

    _______________________________________________
    Spasm mailing list
    [email-masked]
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!GjvTz_vk!BWAD95jczCEq6ySyvRqmCncBjsHBke73Picf7RBkRpxzkYg4lcx_iNtYqwqG$

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 15 Mar 2022 21:33:26 +0200

On Tue, Mar 15, 2022 at 01:31:59PM -0400, Sean Turner wrote:
> 
> While discussing this I-D with my co-authors they wonder whether we
> should include all of NISTs PQ algorithms, not just the KEM ones but
> also the signature algorithms, in one I-D or have separate I-Ds for
> each. While I like the idea of a one stop I-D that doesn’t really seem
> like an iron clad rationale nor does "that’s we did for RFC 3279". I
> know Panos and Jake has some other reasons for wanting to keep them
> separate (I don’t want to steal their thunder). So, this version of
> the I-D, despite it’s name, does take the one candidate, Candidate
> TBD1, approach.
>

For one I-D to rule them all, wouldn't you also need to define how to
perform hybrid KEM and hybrid signatures in that document?

One really needs hybrid KEM to actually use this: The algorithms just
are not trustworthy enough otherwise. I consider lack of hybrid KEM
hard blocker for this.

And then I see email from today that contains an attack against the
hybrid KEM construction from another draft...

-Ilari

---

From: Russ Housley <[email-masked]>
Date: Tue, 15 Mar 2022 15:40:19 -0400

> On Mar 15, 2022, at 3:33 PM, Ilari Liusvaara <[email-masked]> wrote:
> 

This document is intended to be the use of a single PQC algorithm.  The hybrid be covered in other drafts.

Russ

---

From: Sean Turner <[email-masked]>
Date: Wed, 16 Mar 2022 12:50:02 -0400

> On Mar 15, 2022, at 14:03, Mike Ounsworth <[email-masked]> wrote:
> > Private keys
>  

Yes and no. The curdlle WG produced RFC 8410. I would say they probably included the textual formats because Simon was author of both RFC 7468 and RFC 8410. I would also of bet that had LAMPS been around when draft-josefsson-pkix-textual was being worked on Sean Leonard, at least, would have come knocking on the door.

In terms of format, luckily those formats have already been defined in PKCS#8, PKCS#12 (in OASIS), PEM. I picked PKCS#8 because it’s the defacto “Private Key Format” (defined in RFC 5208 and later obsoleted by 5958). Luckily, there’s are plenty of tools to convert from 8->12.

As far a sending the private key on the wire, I need to add a security consideration to make sure that the considerations from RFC 5958 get pulled in.

spt

---

From: Russ Housley <[email-masked]>
Date: Wed, 16 Mar 2022 13:07:59 -0400

> On Mar 16, 2022, at 12:50 PM, Sean Turner <[email-masked]> wrote:
> 
> 
> 

In addition to the places that Sean points, PKCS#1 defines RSAPrivateKey.  (See RFC 2437 --> RFC 3447 -->  RFC 8017.)  Support for more than two primes was added along the way.

Russ

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 17 Mar 2022 09:02:09 -0400

> Strongly agree.  It's not just wire format but configuration

Count me as another advocate for explicitly declaring the private key
format.  Even doing interoperability testing is difficult if there's no
standard, commonly-adopted way to load a private key into the software.

If the goal of the IETF is to produce interoperable standards, we can't
ignore private key formats.

On a different topic, I appreciate that this draft is looking like it
will have sample keys in it.  I recommend that the authors place each
sample key in a separate subsection for easier reference.

I also hope that when the actual samples end up in this document, there
will be a sample private key that corresponds to each sample public
key.  I assume that will be the case, but the text as currently written
doesn't imply that the samples are related to one another, so i just
wanted to explicitly encourage that.

       --dkg

---

From: Sean Turner <[email-masked]>
Date: Thu, 17 Mar 2022 14:15:13 -0400

> On Mar 17, 2022, at 09:02, Daniel Kahn Gillmor <[email-masked]> wrote:
> 

Interesting, I had forgot those To Dos were there. I will make sure that the examples (however many we have) end up having a public-private key pair that correspond.

spt