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

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Thu, 29 September 2022 14:37 UTC

Return-Path: <prvs=8271b4fe47=uri@ll.mit.edu>
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 EA9ADC14CF15; Thu, 29 Sep 2022 07:37:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.013
X-Spam-Level:
X-Spam-Status: No, score=-1.013 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MPART_ALT_DIFF=0.79, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=no autolearn_force=no
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 ZOrBB2nxuMw1; Thu, 29 Sep 2022 07:37:00 -0700 (PDT)
Received: from MX2.LL.MIT.EDU (mx2.ll.mit.edu [129.55.12.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC13C14F72C; Thu, 29 Sep 2022 07:36:59 -0700 (PDT)
Received: from LLEX2019-2.mitll.ad.local (llex2019-2.llan.ll.mit.edu [172.25.4.124]) by MX2.LL.MIT.EDU (8.17.1.5/8.17.1.5) with ESMTPS id 28TEai6e073103 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 29 Sep 2022 10:36:45 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=gkKqzjhP/84xfIp9ogcSVeJxLADJdaoKtBdBaSNkfspI0WYfj2hnPyxPGaI6yIGhB8Eztj2zhuXPdOhkoCiO3F3baUgX1Ga8ywVmze1QWssNEfZY+bXsFx2CH0maLqc8VaX/w5EzMIeNFeODA3TTiYM7jXRXtSp0EGHM7uyzv3DM8Ud3+pWII7EOSfp3nAqP/VAvWfn8SVyKYhEl57wTfetmFCivRyQgKnHbnCTWQ6Qrh48F7N1VyctucuIy/gLLaZ+Pe93XEVYeVvUImMcLdBGSOAKr1q/GUR95DPjsJrr6VDGpth2mvmTSmqCwmZfrLhHa+h7aPJ+YSpB81LWk/A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=n9GIcj0+ljWAP8RG19y6jys3cQLLv1wp/i6KneZbmx8=; b=HjK7OuVrcJSx0IsXRl5lZ7dkJ8S3WnV2RhuBaOEn8aNf1GCEA6YdXMrMv+62lIwchGDiVZM8l/6BqC221mxk28Itgh5VagYa20hIASLw0Ejws2hBOB04f3oFdfT/IJdXLjtRgJiCsJf4YfDbsPXCn92HHi45o0ErY9sRQ8v/+nvbXUYFAIZeC8jk/FxgaznmEJ2aoL81zYyseSjsVtgcbOrmhmJoHmh7ssnpC5sfQagt4uZiwJiK+BEYR/mC9X3LpolCim35VWZz/fxV2wZtmqHfDnqgRAg+JOmN+/sF/RkUUSkQ/s2PCzTJK3t9++np7upCVCYJguJHjwdR7PjuOg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ll.mit.edu; dmarc=pass action=none header.from=ll.mit.edu; dkim=pass header.d=ll.mit.edu; arc=none
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Tim Hollebeek <tim.hollebeek=40digicert.com@dmarc.ietf.org>
CC: Russ Housley <housley@vigilsec.com>, LAMPS <spasm@ietf.org>
Thread-Topic: [lamps] Multiple drafts with PQ algorithm key encodings that are not compatible.
Thread-Index: AdjTZgX3XvEwjK4GRXikwyp96JR57gAp2FQAAACUkYAAAEr0AA==
Date: Thu, 29 Sep 2022 14:36:55 +0000
Message-ID: <47B66544-735F-4AD4-BDF7-C14D6B242879@ll.mit.edu>
References: <SJ0PR14MB5489FB0CF47FC5530C5CA48883579@SJ0PR14MB5489.namprd14.prod.outlook.com>
In-Reply-To: <SJ0PR14MB5489FB0CF47FC5530C5CA48883579@SJ0PR14MB5489.namprd14.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BN0P110MB1419:EE_|BN0P110MB1734:EE_
x-ms-office365-filtering-correlation-id: 8b143827-c716-4da6-c563-08daa2280e95
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: BOukeADf8owi66w0NGsDgh/a2mZjbVKT5GAYNgESF11/eSjL/LvnCMYpUxHBAlfPvtCs0ZUplE6/XVKV5VFS1XpjxhKIrQVhJwQajp4FKm5wDnqcsx6rtMz6edGFO6b1NiDCTb9UmtKfkTY5AaJ0SzbNHERtgn5hIz7L9lx/gBEcvAWPVuNGO0SHcEMAL7sHjdbdYC9eHuC50bOMaQwHKisvuFXCBYw4vi90Tt+T6u+SUc5A+P0RGpRQbHA1LRnOjJS8i9FOkzAhllyL/CnaWCgYHOeXhAT1zjHFppEW7IVuYgsyd2buVXBI3AgpLwajXkb5sKmASETBc+tsO1uKYq9CrcqxRzG43hezAJ24yVqd3NifJX8qGCL4sv5wTgR+znQa/78EmeZ2XUOAMDRWLbVWzLo4PjUHcR3o6VgQB/EY1fHMdg1EWE1zcU9ELnQ1wbCjDvPq1GXceAhhptHU416iH95Ybuwl4GhpGbNuZMdEHeqwiLjAjYBpig+gOg8buKaFv4SUeoqjH2fFCNhjlzzcLjEGvHw9Lg/3tRUOjgOKSiNTCfN5/47zfKmtKFZNXEa3QQrKYlMb2xaO3q2cnReR2IXOm+5Ni9ZCnKwwXtRmgchUD42eTA/2b+vetcbbNgeCkY0UmqlP05/MuLQN2rz11rDrwt2JR4HzX4sRaoTToCI2RQyng6honGjGvBi+JKq6zN4Tc5B4kpK4Ef9X4FqUcC6QMycqLKUPGA3Ps4CbVVDUoNpM93O/5J0qZyVL
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230022)(366004)(451199015)(38070700005)(186003)(83380400001)(86362001)(2616005)(99936003)(122000001)(166002)(8936002)(5660300002)(64756008)(66446008)(66476007)(66556008)(66946007)(76116006)(4326008)(2906002)(53546011)(498600001)(966005)(6506007)(6512007)(54906003)(8676002)(71200400001)(75432002)(6486002)(33656002)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: mxh4M96EwDCFb261PiX43wP/2D4Rr9v3a8e4IO8y5L+2CFtpzXQSpPu6g7t2hYyq5ul69Yh3VBUVjiD0qpgvw1Ogu/biR+hfodIAO/7/3C0xJV9BUYHZGF0HxYquY3Ctq1vnrCFhd4JvzBIh51uubThDxb89q+j9qSmFsWcSDLKL0JEDV6yOgaMw0WGxrlZBOdRzdSYDOWPmf4QpYnJ+D87ODIsCnYQoK7Kr6VoHJAiRwXNYb+Ef8U9wiSs1Yv7FcBinkOT4qyaMSItPB8vCaNs3p+hOYjtHXrK3Qwx1BjO9fCGbFyDSEZu6khbLFT9i
Content-Type: multipart/signed; boundary="Apple-Mail-D7DE49C9-9858-413A-A598-DB2315B463AA"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 8b143827-c716-4da6-c563-08daa2280e95
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2022 14:36:55.2809 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 83d1efe3-698e-4819-911b-0a8fbe79d01c
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN0P110MB1734
X-Proofpoint-GUID: 6hpMQn0CSs2PA5Of2NXN0RZSuZXUXzbO
X-Proofpoint-ORIG-GUID: 6hpMQn0CSs2PA5Of2NXN0RZSuZXUXzbO
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1 definitions=2022-09-29_08,2022-09-29_03,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 malwarescore=0 phishscore=0 mlxscore=0 adultscore=0 mlxlogscore=999 suspectscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000 definitions=main-2209290090
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/bi2la4TeYAWJok8UN1w4J_PAXGI>
Subject: Re: [lamps] 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 14:37:05 -0000

I strongly support defining public keys as OCTET STRING, and concur with Russ that it's better to represent them as one OCTET STRING rather than a pair. 

Regards,
Uri

On Sep 29, 2022, at 10:29, Tim Hollebeek <tim.hollebeek=40digicert.com@dmarc.ietf.org> wrote:



Are you referring to the option for partial vs full encoding for some of the private keys, or something else?

 

-Tim

 

From: Spasm <spasm-bounces@ietf.org> On Behalf Of Russ Housley
Sent: Thursday, September 29, 2022 10:12 AM
To: LAMPS <spasm@ietf.org>
Subject: Re: [lamps] Multiple drafts with PQ algorithm key encodings that are not compatible.

 

Trimming the recipient list because the other messages needed moderation for "too many recipients"

 

draft-uni-qsckeys-01 makes the argument that for the private keys, one size does not fit every use case.  If there is consensus on this view, thenOPTIONAL fields or a CHOICE within the private key structure seems like a simple way forward.

 

I was really hoping that the public key would _always_ be an OCTET STRING.  No optional parts. 

 

Russ

 



On Sep 28, 2022, at 2:33 PM, John Gray <John.Gray=40entrust.com@dmarc.ietf.org> wrote:

 

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/" rel="nofollow">https://datatracker.ietf.org/doc/draft-massimo-lamps-pq-sig-certificates/

 

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/" rel="nofollow">https://datatracker.ietf.org/doc/draft-uni-qsckeys/01/

 

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/" rel="nofollow">https://datatracker.ietf.org/doc/draft-ietf-lamps-kyber-certificates/  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/" rel="nofollow">https://datatracker.ietf.org/doc/draft-uni-qsckeys/01/

 

   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/" rel="nofollow"> https://datatracker.ietf.org/doc/draft-uni-qsckeys/01/ 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.

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm" rel="nofollow">https://www.ietf.org/mailman/listinfo/spasm

 

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm