Re: [lamps] [EXTERNAL] Re: [Pqc] Multiple drafts with PQ algorithm key encodings that are not compatible.

Christine Cloostermans <cvvrede@gmail.com> Thu, 29 September 2022 09:47 UTC

Return-Path: <cvvrede@gmail.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F1DC1522A2; Thu, 29 Sep 2022 02:47:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.005
X-Spam-Level:
X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dn8j-MRka7cq; Thu, 29 Sep 2022 02:47:51 -0700 (PDT)
Received: from mail-oo1-xc2b.google.com (mail-oo1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07F22C14CE44; Thu, 29 Sep 2022 02:47:51 -0700 (PDT)
Received: by mail-oo1-xc2b.google.com with SMTP id u19-20020a4a9e93000000b004757198549cso107977ook.0; Thu, 29 Sep 2022 02:47:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=b5mOWh5lTBcN8ou264QQbSOxms7VT9ztB3CegdUYxVw=; b=Iv0TzvlGPiMeg0B3xe3mx5axYUgdBUtNcOv3atStLkMNaUQ3/Iw4Vln7OWhb03EFlZ MVKoawqw6HrztJrfEKkJQ9MOE1lqAlnSDvCKE79c7ruXzSlfWVO+i6OQFb85DjBKBi19 QAgxUmEzHKBpoxmShSRppP0OJkuEyR5ahga1wAyLS7HaRMrDuZxVBAjAoGjxAMryt3X9 1TjzjcVWw7bUXoSIUrBLdBVlKeS4r4uPGQtJwiPtghb3DqvN71ohxg5BSiIShndwRcoH XWXvewezbKwAr0dcS1BbbT0JjY9XMFo49+aia2Ger+mlo6Y6o+FsMY7cwpTQIAHITBn8 V/fQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=b5mOWh5lTBcN8ou264QQbSOxms7VT9ztB3CegdUYxVw=; b=0lCdfmCbRBQdAk7/fjSvyRdnKzWePZbe4jTPdxPTlVwotTZOgfmDg71Ng1cUCL1jDd SEqGqEb6VU/qLbXGwbswIJ2dByqetej9wDitq5WkaUq4PukD2rkzqBIc2PoLEAgxZjkL ZUysiVt30bq57WnSkD/rbi86SxKFXEy7HrdcFlLIYiAqXOpaqD7dTzwPEU+gwoM23wK2 nAB1B6aiH5NNNGUuoL2kkFj3d4UAbFN3BPOLm3+PZDiUTnigHRqAv9vnODYZoZDhQjPh SxXNYgVjhW+GFFi+UHyrcXW2cAXJAJ9ss4Q89XcmV8IW+U1ZmIHjUF9S43xmQE1cScdD cuSg==
X-Gm-Message-State: ACrzQf20xL61qMqrTg/t5xScoshKfRWdU4aWt7U6j61xYA1+RLGdU6SD 8ftbaZGY/PGVcP08t7AP7TCbxgOp4+auB/DuBUs=
X-Google-Smtp-Source: AMsMyM4rFSDXwz5jgKvOyVW9ZEcW0NFX2gsgeEhnnElz/jPg0dSpbeF7Idjc91ajSeq42iJGKExa0s/Rhvz+4dFPTMo=
X-Received: by 2002:a4a:8358:0:b0:475:910b:cbba with SMTP id q24-20020a4a8358000000b00475910bcbbamr938213oog.50.1664444870183; Thu, 29 Sep 2022 02:47:50 -0700 (PDT)
MIME-Version: 1.0
References: <574516F5-098F-4CB6-8D9C-F193BF1B1507@amazon.com> <2B8DF0B3-B79C-4688-B481-737BCCC9EFF1@westerbaan.name> <CH0PR11MB5739CCCC7C99CC2F194C06719F549@CH0PR11MB5739.namprd11.prod.outlook.com>
In-Reply-To: <CH0PR11MB5739CCCC7C99CC2F194C06719F549@CH0PR11MB5739.namprd11.prod.outlook.com>
From: Christine Cloostermans <cvvrede@gmail.com>
Date: Thu, 29 Sep 2022 11:47:39 +0200
Message-ID: <CAHzQBQWo9514PeeCatTcOv58muG9LLzihWr1+v9NOuAoPhTysg@mail.gmail.com>
To: Mike Ounsworth <Mike.Ounsworth@entrust.com>
Cc: Bas Westerbaan <bas@westerbaan.name>, "Massimo, Jake" <jakemas@amazon.com>, John Gray <John.Gray=40entrust.com@dmarc.ietf.org>, "pqc@ietf.org" <pqc@ietf.org>, "spasm@ietf.org" <spasm@ietf.org>, "cfrg@ietf.org" <cfrg@ietf.org>, "Panos Kampanakis (pkampana)" <pkampana@cisco.com>, Sean Turner <sean@sn3rd.com>, "sid@zurich.ibm.com" <sid@zurich.ibm.com>, "bhe@zurich.ibm.com" <bhe@zurich.ibm.com>, "tvi@zurich.ibm.com" <tvi@zurich.ibm.com>, "osb@zurich.ibm.com" <osb@zurich.ibm.com>, "dieter.bong@utimaco.com" <dieter.bong@utimaco.com>, "joppe.bos@nxp.com" <joppe.bos@nxp.com>, "Markku-Juhani O. Saarinen" <mjos@pqshield.com>
Content-Type: multipart/alternative; boundary="0000000000003c4eec05e9cdc54e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/xFbrKQQxV8HXP-S6KuJ8_v4GKJc>
X-Mailman-Approved-At: Thu, 29 Sep 2022 06:51:29 -0700
Subject: Re: [lamps] [EXTERNAL] Re: [Pqc] Multiple drafts with PQ algorithm key encodings that are not compatible.
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Sep 2022 09:47:55 -0000

Hi,

Fielding a couple of the questions at once:

- The plan is to publish it as an RFC. At the last IETF meeting it was
decided it would make sense to split it into multiple RFCs (one per
winner). We are working on the split.
- The split includes a Sphincs+ document. Initially we considered only the
finalists, but now also added Sphincs+ as it is now a winner.
- Splitting between a seed and the full key is intesting. This might be a
problem to be fielded in LMS/XMSS as well. Different OIDs seems like it
would become a long list, but I am not sure whether that is a problem.

Cheers,

Christine

Op wo 28 sep. 2022 om 23:39 schreef Mike Ounsworth <
Mike.Ounsworth@entrust.com>:

> > So I’d propose as format either storing the opaque private key (as
> specified by the CRYSTALS team) or the seed.
>
>
>
> I like the idea. What’s the easiest way for a parser trying to read this
> off disk to know the difference between:
>
>
>
>    dilithiumPrivateKey OCTET STRING
>
> and
>
>     dilithiumPrivateKeySeed OCTET STRING
>
> ?
>
>
>
> Different PrivateKeyAlgorithmIdentifier OIDs?
>
>
>
> ---
> Mike Ounsworth
> Software Security Architect, Entrust
>
>
>
> *From:* Bas Westerbaan <bas@westerbaan.name>
> *Sent:* September 28, 2022 4:31 PM
> *To:* Massimo, Jake <jakemas@amazon.com>
> *Cc:* Mike Ounsworth <Mike.Ounsworth@entrust.com>; John Gray <John.Gray=
> 40entrust.com@dmarc.ietf.org>; pqc@ietf.org; spasm@ietf.org; cfrg@ietf.org;
> Panos Kampanakis (pkampana) <pkampana@cisco.com>; Sean Turner <
> sean@sn3rd.com>; cvvrede@gmail.com; sid@zurich.ibm.com; bhe@zurich.ibm.com;
> tvi@zurich.ibm.com; osb@zurich.ibm.com; dieter.bong@utimaco.com;
> joppe.bos@nxp.com; Markku-Juhani O. Saarinen <mjos@pqshield.com>
> *Subject:* [EXTERNAL] Re: [Pqc] Multiple drafts with PQ algorithm key
> encodings that are not compatible.
>
>
>
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know the
> content is safe.
> ------------------------------
>
>      DilithiumPrivateKey ::= SEQUENCE {
>
>          version                               Version,
>
>          privateKeyAlgorithm      PrivateKeyAlgorithmIdentifier,
>
>          privateKey                        OCTET STRING,
>
>          publicKey                            [0] IMPLICIT
> DilithiumPublicKey OPTIONAL
>
>      }
>
>
>
> PQC private keys are typically rather large and, for many schemes can be
> generated cheaply from a small seed (such as with Dilithium). That’s
> helpful if you store many private keys or are rather constrained in storage.
>
>
>
> So I’d propose as format either storing the opaque private key (as
> specified by the CRYSTALS team) or the seed.
>
>
>
> Best,
>
>
>
>  Bas
>
>
>
>
>
>
>
>
>
>
>
>
> i.e., the parameters are defined/contained within privateKeyAlgorithm.
> This means we can support the byte array encoding for the private key
> proposed by the algorithm designers in privateKey an OCTET STRING.
>
>
>
> Thoughts?
>
>
>
> Cheers,
>
> Jake
>
>
>
> *From: *Mike Ounsworth <Mike.Ounsworth@entrust.com>
> *Date: *Wednesday, 28 September 2022 at 13:26
> *To: *John Gray <John.Gray=40entrust.com@dmarc.ietf.org>, "pqc@ietf.org" <
> pqc@ietf.org>, "spasm@ietf.org" <spasm@ietf.org>, "cfrg@ietf.org" <
> cfrg@ietf.org>
> *Cc: *"Massimo, Jake" <jakemas@amazon.com>, "Panos Kampanakis (pkampana)"
> <pkampana@cisco.com>, Sean Turner <sean@sn3rd.com>, "bas@westerbaan.name"
> <bas@westerbaan.name>, "cvvrede@gmail.com" <cvvrede@gmail.com>, "
> sid@zurich.ibm.com" <sid@zurich.ibm.com>, "bhe@zurich.ibm.com" <
> bhe@zurich.ibm.com>, "tvi@zurich.ibm.com" <tvi@zurich.ibm.com>, "
> osb@zurich.ibm.com" <osb@zurich.ibm.com>, "dieter.bong@utimaco.com" <
> dieter.bong@utimaco.com>, "joppe.bos@nxp.com" <joppe.bos@nxp.com>
> *Subject: *RE: [EXTERNAL][Pqc] Multiple drafts with PQ algorithm key
> encodings that are not compatible.
>
>
>
> *CAUTION*: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
>
>
> My curiosity is about the procedural aspect of draft-uni-qsckeys. Is this
> attached to a working group? Are you indenting to publishing this as an
> RFC, or is this just to bridge prototyping work until NIST publishes real
> standards?
>
>
>
> ---
> Mike Ounsworth
> Software Security Architect, Entrust
>
>
>
> *From:* Pqc <pqc-bounces@ietf.org> *On Behalf Of *John Gray
> *Sent:* September 28, 2022 1:34 PM
> *To:* pqc@ietf.org; spasm@ietf.org; cfrg@ietf.org
> *Cc:* Massimo, Jake <jakemas@amazon.com>; Panos Kampanakis (pkampana) <
> pkampana@cisco.com>; Sean Turner <sean@sn3rd.com>; bas@westerbaan.name;
> cvvrede@gmail.com; sid@zurich.ibm.com; bhe@zurich.ibm.com;
> tvi@zurich.ibm.com; osb@zurich.ibm.com; dieter.bong@utimaco.com;
> joppe.bos@nxp.com
> *Subject:* [EXTERNAL] [Pqc] Multiple drafts with PQ algorithm key
> encodings that are not compatible.
>
>
>
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know the
> content is safe.
> ------------------------------
>
> We are doing some interoperability testing with different vendors using
> the new Dilithium, Falcon and SPHINCS+ algorithms.   We have come across at
> least two drafts which are trying to specify the ASN.1 encoding formats for
> these algorithms.   However, the encoding formats are not compatible with
> each other.   I imagine the authors of these drafts should get together and
> come up with a common format (I have copied them on this email).   This
> means we must choose one or the other, or even worse, support multiple
> formats (which can lead to bugs).   Initially I started more than a year
> ago using my own encoding format for internal prototyping, but now need to
> interoperate with others outside of our organization, so a common format is
> definitely needed at this point.   😊
>
>
>
> We fully realize the OID values will be changing once official OIDs are
> registered, (changing those are trivial), but the ASN.1 formats of the
> public and private keys is kind of important as well…  😊
>
>
>
> For example:
>
>
>
> The LAMPS group has a specification of Dilithium public keys in this draft:
>
> https://datatracker.ietf.org/doc/draft-massimo-lamps-pq-sig-certificates/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-massimo-lamps-pq-sig-certificates/__;!!FJ-Y8qCqXTj2!eSTwME-1IjQkfjJFS0X7lRzbYJ1PhEzSelmmUcLwF9JaceAAKFQwvLRif4O6vS8ijYlK0TG2cYO4rpBHtq5AG1OZQAKxlou-rKXm$>
>
>
>
> the public key format is this:
>
>
>
> The Dilithium public key MUST be encoded using the ASN.1 type
>
>    DilithiumPublicKey:
>
>
>
>      DilithiumPublicKey ::= OCTET STRING
>
>
>
> The private key format is this:
>
>
>
>      DilithiumPrivateKey ::= SEQUENCE {
>
>          rho         BIT STRING,         - nonce/seed
>
>          K           BIT STRING,         - key/seed
>
>          tr          BIT STRING,         - PRF bytes (CRH in spec.)
>
>          s1          BIT STRING,         - vector l
>
>          s2          BIT STRING,         - vector k
>
>          t0          BIT STRING,         - encoded vector
>
>          PublicKey   IMPLICIT DilithiumPublicKey OPTIONAL
>
>      }
>
>
>
>
>
> In this draft:
>
> https://datatracker.ietf.org/doc/draft-uni-qsckeys/01/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-uni-qsckeys/01/__;!!FJ-Y8qCqXTj2!eSTwME-1IjQkfjJFS0X7lRzbYJ1PhEzSelmmUcLwF9JaceAAKFQwvLRif4O6vS8ijYlK0TG2cYO4rpBHtq5AG1OZQAKxlnAfHtmn$>
>
>
>
> Dilithium keys have this encoding:
>
>
>
>
>
>    DilithiumPublicKey ::= SEQUENCE {
>
>        rho         OCTET STRING,
>
>        t1          OCTET STRING
>
>    }
>
>
>
>
>
>   DilithiumPrivateKey ::= SEQUENCE {
>
>        version     INTEGER {v0(0)}     -- version (round 3)
>
>        nonce       BIT STRING,         -- rho
>
>        key         BIT STRING,         -- key/seed/D
>
>        tr          BIT STRING,         -- PRF bytes (CRH in spec)
>
>        s1          BIT STRING,         -- vector(L)
>
>        s2          BIT STRING,         -- vector(K)
>
>        t0          BIT STRING,
>
>        publicKey  [0] IMPLICIT DilithiumPublicKey OPTIONAL
>
>                                        -- see next section
>
>    }
>
>
>
> The draft-uni-qsckeys does not cover SPHINCS+,  it does cover Falcon, but
> I don’t know of another draft that specifies Falcon.
>
>
>
> There are also encodings for Kyber mentioned in two documents that I see.
> There is an early
> https://datatracker.ietf.org/doc/draft-ietf-lamps-kyber-certificates/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-lamps-kyber-certificates/__;!!FJ-Y8qCqXTj2!eSTwME-1IjQkfjJFS0X7lRzbYJ1PhEzSelmmUcLwF9JaceAAKFQwvLRif4O6vS8ijYlK0TG2cYO4rpBHtq5AG1OZQAKxlubO7POn$>
>  draft which mentions it is up to the document defining Kyber to give more
> details.    In the draft-uni-qsckeys draft it is more specific.
>
>
>
> https://datatracker.ietf.org/doc/draft-uni-qsckeys/01/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-uni-qsckeys/01/__;!!FJ-Y8qCqXTj2!eSTwME-1IjQkfjJFS0X7lRzbYJ1PhEzSelmmUcLwF9JaceAAKFQwvLRif4O6vS8ijYlK0TG2cYO4rpBHtq5AG1OZQAKxlnAfHtmn$>
>
>
>
>    KyberPrivateKey ::= SEQUENCE {
>
>        version     INTEGER {v0(0)}   -- version (round 3)
>
>        s           OCTET STRING,     -- sample s
>
>        publicKey   [0] IMPLICIT KyberPublicKey OPTIONAL,
>
>                                      -- see next section
>
>        hpk         OCTET STRING      -- H(pk)
>
>        nonce       OCTET STRING,     -- z
>
>    }
>
>
>
> Partial public key encoding:
>
>
>
> KyberPrivateKey ::= SEQUENCE {
>
>        version     INTEGER {v0(0)}   -- version (round 3)
>
>        s           OCTET STRING,     -- EMPTY
>
>        publicKey   [0] IMPLICIT KyberPublicKey OPTIONAL,
>
>                                      -- see next section
>
>        hpk         OCTET STRING      -- EMPTY
>
>        nonce       OCTET STRING,     -- d
>
>    }
>
>
>
> Full public key encoding:
>
>
>
>    KyberPublicKey ::= SEQUENCE {
>
>        t           OCTET STRING,
>
>        rho         OCTET STRING
>
>    }
>
>
>
> Is https://datatracker.ietf.org/doc/draft-uni-qsckeys/01/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-uni-qsckeys/01/__;!!FJ-Y8qCqXTj2!eSTwME-1IjQkfjJFS0X7lRzbYJ1PhEzSelmmUcLwF9JaceAAKFQwvLRif4O6vS8ijYlK0TG2cYO4rpBHtq5AG1OZQAKxlnAfHtmn$>
> meant to become the document that defines the key formats for all the PQ
> keys that will be standardized?    If not, then it should probably just
> refer to whatever documents will define the formats so that we can at least
> agree on one common format for the PQ keys.
>
>
>
>
>
> Cheers,
>
>
>
> John Gray
>
> Entrust
>
> *Any email and files/attachments transmitted with it are confidential and
> are intended solely for the use of the individual or entity to whom they
> are addressed. If this message has been sent to you in error, you must not
> copy, distribute or disclose of the information it contains. Please notify
> Entrust immediately and delete the message from your system.*
>
>