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

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

Dr. Markku-Juhani O. Saarinen <mjos@pqshield.com> PQShield, Oxford UK.

On Wed, Jul 14, 2021 at 12:41 PM Markku-Juhani O. Saarinen <
mjos@pqshield.com> wrote:

> 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 <mjos@pqshield.com> PQShield, Oxford UK.
>
>
> On Wed, Jul 14, 2021 at 9:38 AM Christine van Vredendaal <
> cvvrede@gmail.com> 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 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
>> _______________________________________________
>> Spasm mailing list
>> Spasm@ietf.org
>> https://www.ietf.org/mailman/listinfo/spasm
>>
>