Re: [CFRG] Pre-draft QSC Key Serialization and Identification

Russ Housley <> Sat, 03 July 2021 15:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DCB753A1941 for <>; Sat, 3 Jul 2021 08:31:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7mZAHlXSIdyi for <>; Sat, 3 Jul 2021 08:31:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F3E933A1944 for <>; Sat, 3 Jul 2021 08:31:49 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD0DB300A3B for <>; Sat, 3 Jul 2021 11:31:48 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id jfjGzx3JAu8I for <>; Sat, 3 Jul 2021 11:31:41 -0400 (EDT)
Received: from a860b60074bd.fios-router.home ( []) by (Postfix) with ESMTPSA id 4B090300B0C; Sat, 3 Jul 2021 11:31:41 -0400 (EDT)
From: Russ Housley <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D70B2E49-0712-4C37-B566-522BFA2D163D"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
Date: Sat, 03 Jul 2021 11:31:40 -0400
In-Reply-To: <>
To: Christine van Vredendaal <>
References: <>
X-Mailer: Apple Mail (2.3445.104.21)
Archived-At: <>
Subject: Re: [CFRG] Pre-draft QSC Key Serialization and Identification
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 03 Jul 2021 15:31:53 -0000

You seem to be changing the algorithmIdentifier definition from RFC 5280.  There is no need to do so.

For each of the OIDs that is assigned, the parameter can be assigned.  If the ALGORITHM class definition from RFC 5912 is followed, this should be very clear.

On the LAMPS WG mail list, there has been a discussion about when to assign OIDs to algorithms.  While some assignments to experiment will be very useful, it would be very harmful if the algorithm gets tweaked after the assignment of the OID.  For this reason, the final assignment of the OID should probably wait for the NIST specification.


> On Jul 3, 2021, at 4:51 AM, Christine van Vredendaal <> wrote:
> 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 would like to share this with this community for feedback and recommendations and also to see if CFRG is the right venue.
> 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 <>.
> 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:
> Difficulty in managing algorithm versions and the compatibility of associated keys
> Difficulty in interoperability testing
> 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 van Vredendaal (NXP), Karen Willbrand (Utimaco)
> Looking forward to your thoughts and suggestions,
> Cheers on behalf of the team,
> Christine