Re: [Mathmesh] [Pqc] let's move beyond X.509 for PQC transition...

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 03 February 2023 14:53 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: mathmesh@ietfa.amsl.com
Delivered-To: mathmesh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D52FC1BE87F for <mathmesh@ietfa.amsl.com>; Fri, 3 Feb 2023 06:53:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Hqf63YsLWgRa for <mathmesh@ietfa.amsl.com>; Fri, 3 Feb 2023 06:53:39 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F52EC14CE4D for <mathmesh@ietf.org>; Fri, 3 Feb 2023 06:53:39 -0800 (PST)
Received: from dyas.sandelman.ca (unknown [109.190.253.13]) by relay.sandelman.ca (Postfix) with ESMTPS id C44EF1F4C0; Fri, 3 Feb 2023 14:38:28 +0000 (UTC)
Received: by dyas.sandelman.ca (Postfix, from userid 1000) id 5455DA1E60; Fri, 3 Feb 2023 07:49:00 -0500 (EST)
Received: from dyas (localhost [127.0.0.1]) by dyas.sandelman.ca (Postfix) with ESMTP id 519EDA1E5C; Fri, 3 Feb 2023 13:49:00 +0100 (CET)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Phillip Hallam-Baker <phill@hallambaker.com>, Erik Andersen <era@x500.eu>, mathmesh@ietf.org
In-reply-to: <CAMm+Lwgx7EiqfQsgxMXc6Cm2qJwc7OfSuBA7MnRhoAK7G3+K_Q@mail.gmail.com>
References: <7466301a-cacf-716b-f88d-df6df9e37672@cs.tcd.ie> <Y9m7Ft9LIhG0AVqf@kduck.mit.edu> <1513c056-778e-8953-0a24-35815cb78e3e@cs.tcd.ie> <1887772.1675320213@dyas> <BFDA6238-B977-4F48-9BE4-882F22DD5E9E@ll.mit.edu> <000001d9372e$b49e0b20$1dda2160$@x500.eu> <CAMm+Lwgx7EiqfQsgxMXc6Cm2qJwc7OfSuBA7MnRhoAK7G3+K_Q@mail.gmail.com>
Comments: In-reply-to Phillip Hallam-Baker <phill@hallambaker.com> message dated "Thu, 02 Feb 2023 13:09:43 -0500."
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Fri, 03 Feb 2023 13:49:00 +0100
Message-ID: <2026621.1675428540@dyas>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mathmesh/NE7bl_2AJXxpzdPH6onQhZCuKBw>
Subject: Re: [Mathmesh] [Pqc] let's move beyond X.509 for PQC transition...
X-BeenThere: mathmesh@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Mathematical Mesh <mathmesh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mathmesh>, <mailto:mathmesh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mathmesh/>
List-Post: <mailto:mathmesh@ietf.org>
List-Help: <mailto:mathmesh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mathmesh>, <mailto:mathmesh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Feb 2023 14:53:40 -0000

Phillip Hallam-Baker <phill@hallambaker.com> wrote:
    >> Just to remind you. The Issuer and sequence number together are used
    >> to uniquely identify a particular certificate.

    > I am trying to be mindful of Paul's request here. But you are
    > illustrating a part of the reason why it is hard to do the right thing
    > for PQC in the context of PKIX.

Just to re-iterate: Yes, the IssuerDN is required because of the interaction
with unique certifiates. This is exactly the thing of nonsense that is making stuff hard.

And it's not even the DER encoding of the IssuerDN, it's the semantic meaning
of the DN.

    > I don't have a unique identifier for a certificate (assertion) in my
    > work.  If I did, I guess it would be the fingerprint of the
    > certificate.

Even here, "fingerprint" can mean different things.
Is it the sha256sum of the certificate, or the SPKI?

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-