Subject: [Secdispatch] Pre-draft QSC Key Serialization and Identification

From: Christine van Vredendaal <[email-masked]>
Date: Wed, 14 Jul 2021 10:37:33 +0200

Hello all,

We (folks from NXP, IBM and Utimaco) have been working on a draft
specifying key serializations and OIDs for quantum-safe cryptography to
already start to prepare for the upcoming new public-key standard.

We shared this with the CFRG for feedback and recommendations and would now
also like to share it for the same purpose in this broader community.

At the moment this is a pre-draft in the sense that it is not in an IETF
format yet, but all the content is there.
You can find the link to a comment-only Google Docs version here
<https://docs.google.com/document/d/1MbSf7e9NIZ0XCEpJ9Kpdxe04Z5HlvvgOBTUX4uvM1i0/edit?usp=sharing>
.

The abstract of the document is as follows:

With the NIST standardization effort still in full swing, companies
implementing post-quantum cryptography now are running into multiple
issues, such as:

   1. Difficulty in managing algorithm versions and the compatibility of
   associated keys
   2. Difficulty in interoperability testing
   3. Difficulty in evaluating the impact of integrating algorithms with
   higher level standards

These difficulties result in delay of many follow-up activities for
algorithm integration and adoption.

The document `Quantum Safe Key Identification and Serialization’ specifies
the key formats of selected quantum safe algorithms, to hopefully resolve
some of these interoperability issues.

Additionally it should serve to make choices in future standard clear and
prevent delays in adaption.

To this end the document contains parameter identifiers for the Round 3
finalist parameter sets (specific OIDs in some cases to be added), as well
as key descriptions, byte sizes, and their ASN.1 formatting.

Open items that we would consider still adding (opinions are welcome) are
the addition of CBOR formats, and the serialization of signatures and
ciphertexts.

We also note that the current OIDs are not useable or filled in yet. We are
investigating adding temporary OIDs, and in the end permanent OIDs should
be assigned by NIST upon standardization of a set of algorithms.

*(Current) authors: *Dieter Bong (Utimaco), Joppe Bos (NXP), Silvio Dragone
(IBM), Basil Hess (IBM), Christopher Meyer (Utimaco), Mike Osborne (IBM),
Christine Cloostermans (NXP, f.k.a. van Vredendaal), Karen Willbrand
(Utimaco)

Looking forward to your thoughts and suggestions,

Cheers on behalf of the team,

Christine

---

From: "Markku-Juhani O. Saarinen" <[email-masked]>
Date: Wed, 14 Jul 2021 12:41:38 +0100

Hi,

Some of this commentary is already commented inline in the google doc, but
I'll paste it here too for the record.

The document proposes OID identifiers for public and private key
serialization draft Round3 PQC algorithms, which are likely to change when
the NIST standard-writing process.

The PQC algorithm specifications and reference implementations already
contain serialization methods (that can be used as simple octet strings).
The proposal is not using these serialization methods directly (as "octet
string blobs" or similar). Suggest including some additional justification
for proposing new serialization methods; either efficiency or security.

I'd also like to hear comments on the relationship between this proposal
and the "RawPublicKey" discussed in the new "KEM-based Authentication for
TLS 1.3" draft
https://datatracker.ietf.org/doc/draft-celi-wiggers-tls-authkem/

Each NIST Submission comes with a set of KAT test vectors that are used to
test compliance and also interoperability. Hence we already have de facto
serialization methods for these algorithms, which are efficient, and
created by the algorithm design teams (and hence have already had years of
security testing).  We have also used these serialization methods in
hardware modules.

If ASN.1 type encoding is desired, a transformation tool between the new
ASN.1 format and the standard ones should be provided. Additionally, ASN.1
may introduce serious input validation security issues that must be
carefully studied. Note that Elliptic Curve Cryptography has largely chosen
to go with simplified octet string encodings for implementation security
reasons. One could argue that new ASN.1 serialization a step backward in
terms of interoperability and also potentially creates unnecessary security
risks? The implementation security aspects arise e.g. in the input
validation and constant-time encoding and decoding of KEM public keys,
which are part of the PQC key exchange process.

Cheers,
- markku

Dr. Markku-Juhani O. Saarinen <[email-masked]> PQShield, Oxford UK.

On Wed, Jul 14, 2021 at 9:38 AM Christine van Vredendaal <[email-masked]>
wrote:

> We shared this with the CFRG for feedback and recommendations and would
> now also like to share it for the same purpose in this broader community.
>
>
> We also note that the current OIDs are not useable or filled in yet. We
> are investigating adding temporary OIDs, and in the end permanent OIDs
> should be assigned by NIST upon standardization of a set of algorithms.
>
>
> *(Current) authors: *Dieter Bong (Utimaco), Joppe Bos (NXP), Silvio
> Dragone (IBM), Basil Hess (IBM), Christopher Meyer (Utimaco), Mike Osborne
> (IBM), Christine Cloostermans (NXP, f.k.a. van Vredendaal), Karen
> Willbrand (Utimaco)
>
>
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: "Markku-Juhani O. Saarinen" <[email-masked]>
Date: Wed, 14 Jul 2021 16:06:21 +0100

I typed:

"The document proposes OID identifiers for public and private key
serialization draft Round3 PQC algorithms, which are likely to change when
the NIST standard-writing process."

trying again!

This document proposes OID identifiers for draft Round3 PQC algorithms,
together with an ASN.1 public and private key serialization mechanism that
diverges from the serialization methods used in the NIST PQC competition.
Since the algorithms are likely to change during the NIST standards-writing
process, the applicability and lifetime of this document is very limited
and it is unknown (and indeed, unlikely) that if it will be compatible with
NIST standards.

I should add that descriptive detail in the specification is insufficient
for interoperable implementation. Hence I was asking for a conversion tool
from the serialization format in algorithm specifications and
implementations to the proposed ASN.1 format.

Cheers,
-markku

On Wed, Jul 14, 2021 at 12:41 PM Markku-Juhani O. Saarinen <
[email-masked]> wrote:

> On Wed, Jul 14, 2021 at 9:38 AM Christine van Vredendaal <
> [email-masked]> wrote:
>
>> Hello all,
>>
>> The document `Quantum Safe Key Identification and Serialization’
>> specifies the key formats of selected quantum safe algorithms, to hopefully
>> resolve some of these interoperability issues.
>>