Re: [Multiformats] Multiformats Considered Harmful

Manu Sporny <msporny@digitalbazaar.com> Mon, 06 November 2023 14:07 UTC

Return-Path: <msporny@digitalbazaar.com>
X-Original-To: multiformats@ietfa.amsl.com
Delivered-To: multiformats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BF9C187704 for <multiformats@ietfa.amsl.com>; Mon, 6 Nov 2023 06:07:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, 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=digitalbazaar.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 Jzg8racgllAc for <multiformats@ietfa.amsl.com>; Mon, 6 Nov 2023 06:07:02 -0800 (PST)
Received: from mail-vk1-xa34.google.com (mail-vk1-xa34.google.com [IPv6:2607:f8b0:4864:20::a34]) (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 94A26C19846B for <Multiformats@ietf.org>; Mon, 6 Nov 2023 06:07:02 -0800 (PST)
Received: by mail-vk1-xa34.google.com with SMTP id 71dfb90a1353d-4ac20c41e82so652944e0c.1 for <Multiformats@ietf.org>; Mon, 06 Nov 2023 06:07:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digitalbazaar.com; s=google; t=1699279621; x=1699884421; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=1xRUUjyuAvPApqtnDi9glZEl34Y3RhpLsF8csNwNpKY=; b=gvY8w9CPl7U4sWEPGrYUc9j7ekXbAEZDev5C9Xz8+uiDv9oumzPeCqD7CopiAZrUu5 XNfAqeNVAQaMyeW1sgLfSSHKEMlY+m57TyOBINi0uez9buKC5BvvOiYl9VH91F12SHwX Y8HYB6bqecWNEiyu2t/HbHhtZ3bKyFRlWTv16t/PHrIukg7poTLMVfL+hGz1A17yl4Ex JUnJqueEjDh2GqjuEfjpEZ+OU0dlK27rHTmAh4nS9q5RHul5+ufDK3qlNQ6x7AW/AEzc Y2jaltlDAZLv73xx4gTJlZTeYKIIHsl66LO0l22LgmcK4DcNPzU23gvlwdmIFpC2WK4N h5Pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699279621; x=1699884421; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=1xRUUjyuAvPApqtnDi9glZEl34Y3RhpLsF8csNwNpKY=; b=UaWbav/8esKqnAjt66dFi1fY4J5jwa0jGPXXidtRAM3MF1gBAPf1sgV+48MVtksofC Ta237yA4SfOeSe6Ktr5VcVFxJayNcOCyD2NsI44sbXX2GizLHIdGE9LsLtf4h6z9ZeHI I1q34K82hhT10CDloNBuFGA3KM9LEqzaza5jPwgxFcPukIHWPL3IGwFCPTwR9/k2B/3m z67fqM8JocQzY8kpEstfgM2TI2Hn7XupvO4fpk67+TaPtMmatBC+jTLa7KC+/yRbUdz6 a6gt4jbFXmagciLXPvAU7cEHf1IBHrcLo/4tZVgDNaO5Gguilwnz1FbFfcZbcte4B1kn EHgQ==
X-Gm-Message-State: AOJu0YwTQIAc2Zx1VR/5mFt83RIEohcDvNE90/Hx6yU5PZjyboFs7cD4 iOStKMwZrroiz0/hi5sEUNFEpinAEwzkfTITcKuSVexXZQMW9gTf8Gw=
X-Google-Smtp-Source: AGHT+IHjFEWVIdN06XXRg6c2+HUM/7qx3LrGfILU7n+5RBKriWmTsUrWOioFm2BrSJzLkm2ByEexukBUe1pzvsW2blw=
X-Received: by 2002:a1f:b6d6:0:b0:4ac:22c7:89d5 with SMTP id g205-20020a1fb6d6000000b004ac22c789d5mr3811251vkf.2.1699279621017; Mon, 06 Nov 2023 06:07:01 -0800 (PST)
MIME-Version: 1.0
References: <MW4PR02MB74285C15BBD628DD5F637C2EB7EFA@MW4PR02MB7428.namprd02.prod.outlook.com> <CAKaEYhLJy8CW333ZwGujc1JpgpTqZR09_9yk3FQt7sPsFgXv+w@mail.gmail.com>
In-Reply-To: <CAKaEYhLJy8CW333ZwGujc1JpgpTqZR09_9yk3FQt7sPsFgXv+w@mail.gmail.com>
From: Manu Sporny <msporny@digitalbazaar.com>
Date: Mon, 06 Nov 2023 09:06:24 -0500
Message-ID: <CAMBN2CSTx_7RuDuqQbUXgoJbcj9k1a33Q575SbHU4_vNGrn5LA@mail.gmail.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>
Cc: Michael Jones <michael_b_jones@hotmail.com>, "Multiformats@ietf.org" <Multiformats@ietf.org>, Murray Kucherawy <superuser@gmail.com>, Barry Leiba <barryleiba@computer.org>, Francesca Palombini <francesca.palombini@ericsson.com>, Roman Danyliw <rdd@cert.org>, Paul Wouters <paul.wouters@aiven.io>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/multiformats/rS3-_olJYz3lNmp2-lRJxHoZ9zY>
Subject: Re: [Multiformats] Multiformats Considered Harmful
X-BeenThere: multiformats@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Discussion related to the various Multiformats data formats <multiformats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multiformats>, <mailto:multiformats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multiformats/>
List-Post: <mailto:multiformats@ietf.org>
List-Help: <mailto:multiformats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multiformats>, <mailto:multiformats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2023 14:07:06 -0000

On Sun, Nov 5, 2023 at 5:09 PM Melvin Carvalho <melvincarvalho@gmail.com> wrote:
> I would like to draw attention to potentially new information with broad impact, specifically regarding the proposed deprecation of publicKeyPem and the adoption of multiformats.

This is not new information, usage of `publicKeyPem` was deprecated a
very long time ago... none of the modern Data Integrity cryptosuites
use it. `publicKeyPem` also /has nothing to do with Multiformats/...
it's a W3C Data Integrity thing, not a Multiformats thing.

That said, it's easy to undeprecate it... you just need to see if the
fediverse community cares -- they rolled it out in 2018 and haven't
really touched it since. If they want to continue using it, they have
not made that clear, but if they do, I expect the property will be
undeprecated.

> Moreover, the adoption of multiformats has seemingly overlooked compatibility with prevalent key formats such as bech32, which may inadvertently lead to a dichotomy of 'winners and losers' in the space, rather than fostering inclusivity.

If you want a new key format, just write a spec and register it in the
Multiformats registry.

> In light of these considerations, I urge the IETF to reflect on whether the move towards multiformats genuinely embodies the principles of a universal standard or if it rather represents a narrowing of scope to well-established implementations.

We have had push-back from the IETF community regarding the
registration of a large number of Multiformats. Part of the desire
here is to have IETF have a more formal change control process over
the registry.

> It is my view that this transition may not only be premature but also potentially detrimental to systems that have achieved substantial network effect over time.  See the issue below which proposes deprecating publicKeyPem (in use over 10 million accounts) for very complex multiformats alternative.

Again, the deprecation of `publicKeyPem` has nothing to do with
Multiformats. Deprecating it does not cause the systems that are
deployed that are using it to fail or stop working. If the fediverse
community wants to keep the property alive, they can just say that
they intend to keep using it and we'll put it back into the spec
(though, I expect objections from the JOSE community if we don't
deprecate it).

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
https://www.digitalbazaar.com/