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

From: Christine van Vredendaal <[email-masked]>
Date: Sat, 3 Jul 2021 10:51:51 +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 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
<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 van Vredendaal (NXP), Karen Willbrand (Utimaco)

Looking forward to your thoughts and suggestions,

Cheers on behalf of the team,

Christine

---

From: Russ Housley <[email-masked]>
Date: Sat, 3 Jul 2021 11:31:40 -0400

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.

Russ

> On Jul 3, 2021, at 4:51 AM, Christine van Vredendaal <[email-masked]> 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 <https://docs.google.com/document/d/1MbSf7e9NIZ0XCEpJ9Kpdxe04Z5HlvvgOBTUX4uvM1i0/edit?usp=sharing>.
> 
> 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)
>

---

From: Michael StJohns <[email-masked]>
Date: Sat, 3 Jul 2021 13:28:52 -0400

Hi Christine -

As this isn't a crypto math document and is looking at at rest and 
on-the-wire formats for key material, AND your document language 
indicates a desire to progress through the IETF, it's probably better to 
throw this either at the LAMPS group (https://tools.ietf.org/wg/lamps), 
or to secdispatch or SAAG rather than solely at cfrg.   It's probably 
useful to include cfrg as a CC though as this will be of interest to 
most of the crowd.

Also, if you're actually getting OID assignments, and selecting encoding 
formats, as opposed to republishing formats and assignments decided 
elsewhere, its probably more appropriate to advance this in the 
standards track vs Informational.

I'll take a deeper look at the document later.

Later,Mike

On 7/3/2021 4:51 AM, Christine van Vredendaal wrote:
> specifying key serializations and OIDs for quantum-safe cryptography 
> to already start to prepare for the upcoming new public-key standard.
>
> 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.
> <https://docs.google.com/document/d/1MbSf7e9NIZ0XCEpJ9Kpdxe04Z5HlvvgOBTUX4uvM1i0/edit?usp=sharing>.
>
>
> 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.
>
> 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)
>
>
> _______________________________________________
> CFRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

---

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

Hi Russ,

Thanks for the feedback on the RFCs, we will look into that.

On the OIDs; I fully agree. We are looking into temporary OIDs, but the
final assignment of permanent OIDs should not leave room for
interpretation. This we should indeed be done after a final NIST Standard.

Cheers,

Christine

Op za 3 jul. 2021 om 17:31 schreef Russ Housley <[email-masked]>:

> 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.
>
> Russ
>
>
> 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.
>
> Dragone (IBM), Basil Hess (IBM), Christopher Meyer (Utimaco), Mike Osborne
> (IBM), Christine van Vredendaal (NXP), Karen Willbrand (Utimaco)
>