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

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
>