Re: [Multiformats] Multiformats Considered Harmful

"Murray S. Kucherawy" <superuser@gmail.com> Wed, 06 September 2023 04:22 UTC

Return-Path: <superuser@gmail.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 7E47FC14CE5E for <multiformats@ietfa.amsl.com>; Tue, 5 Sep 2023 21:22:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.844
X-Spam-Level:
X-Spam-Status: No, score=-1.844 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, HTML_OBFUSCATE_05_10=0.26, 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=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 roKmv6w05q3r for <multiformats@ietfa.amsl.com>; Tue, 5 Sep 2023 21:22:17 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 3AF81C14CE52 for <Multiformats@ietf.org>; Tue, 5 Sep 2023 21:22:17 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id 38308e7fff4ca-2be4d132654so6251821fa.0 for <Multiformats@ietf.org>; Tue, 05 Sep 2023 21:22:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693974135; x=1694578935; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qywVW92c/sFmAME9F0R1y0veiKfNtM1vyj8VusZRVmA=; b=aSjADo7lZxSMvInG/+JpEfSHn2wpmxZC9UwaCArTTxyvBjR+6XO+fi/Hrejk8JVgrQ +K3tqikamfCWrAjRGFMD6JaaNYNgCTZgyU8qE3szL9zXpzB8bRk8DtqvJBWrQzQ7bej+ OFcP50LOwo9jMHWNlTC3K/EnYwqUg42vVvU93jsrl4meL+Q/3crIHssZoUku9Uh1IFiP Vphzxy4Zv1siBSzeDzfAjq1bDceIcWKJKX2uuGxrXg/0qXf91O0f/BDsXTjjKHpr2z4u YBz5l2mKs7ew365i2X0ZAkdbaKurdxjCiyAw/2q9+ynjMVIMxaETCqMdRZuKu8xAR3OJ JDGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693974135; x=1694578935; h=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=qywVW92c/sFmAME9F0R1y0veiKfNtM1vyj8VusZRVmA=; b=MS8ez6LsiUKthE1ZDAGP+FtNEHp9N4eP5ASz5GWJdhAgQBNWfXDbX5TPfPrB5qHeiW tuTE2mkGzpsNuOPwF22jNDEWukjIcCw6UFSPzghKKaF85b7kysSlfrIqjM7XkGMJT95i ohoU0nwJUYktucLnzogTvsEmvMNevjylpy7YAjVuy2LN8uTnHjLNkk8rET8gGLjD/Gvn Iy8iz/GF/+w3DziH0mFhEtCTz8ttwwczO/Srm+GFvJ1laC5j/MsxLUyGkZoZFwYdvpUK e8nvJZN13dx2VyFAlVZcI3FSSdI01qk6L7f16EFJ//QBopZ4U1beEkmlsTO6TmfWBlcm LJGQ==
X-Gm-Message-State: AOJu0YyrUMc8CAH2aZnGPWHiiV90NTbb/wkDA2LffzhykHp4UXUNAsNS jtMjr49X7Q8vY8lW3pCF18DzzWscroK1l0quljA=
X-Google-Smtp-Source: AGHT+IExWScF3JjYS6YkKaJ0nRoBaih7pUc/ew++1W0EkN2JMeH47B072CWU9kHD0+9q760VHR/K7Oygiq95VCVzVNI=
X-Received: by 2002:a19:c215:0:b0:500:d6ca:b3e5 with SMTP id l21-20020a19c215000000b00500d6cab3e5mr8914460lfc.4.1693974135005; Tue, 05 Sep 2023 21:22:15 -0700 (PDT)
MIME-Version: 1.0
References: <MW4PR02MB74285C15BBD628DD5F637C2EB7EFA@MW4PR02MB7428.namprd02.prod.outlook.com>
In-Reply-To: <MW4PR02MB74285C15BBD628DD5F637C2EB7EFA@MW4PR02MB7428.namprd02.prod.outlook.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Tue, 05 Sep 2023 21:22:02 -0700
Message-ID: <CAL0qLwa2unFCt3JrsGGHAbKjJ376krgpZjO81wDLBgzgsM4NAg@mail.gmail.com>
To: Michael Jones <michael_b_jones@hotmail.com>
Cc: "Multiformats@ietf.org" <Multiformats@ietf.org>, Barry Leiba <barryleiba@computer.org>, Francesca Palombini <francesca.palombini@ericsson.com>, Roman Danyliw <rdd@cert.org>, Paul Wouters <paul.wouters@aiven.io>
Content-Type: multipart/alternative; boundary="0000000000009364a80604a91647"
Archived-At: <https://mailarchive.ietf.org/arch/msg/multiformats/A4umoNCeMd6tq4VZJ6uUSzf66mc>
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: Wed, 06 Sep 2023 04:22:21 -0000

Hi,

Thanks for this feedback. I'm not taking a position on this at this point,
but I want to mention that the DISPATCH discussion about this work took
place at IETF 116, and the proceedings can be found here, in case reviewing
that discussion might be helpful:

https://datatracker.ietf.org/meeting/116/materials/minutes-116-dispatch-202303270030-00

-MSK, ART AD

On Tue, Sep 5, 2023 at 7:03 PM Michael Jones <michael_b_jones@hotmail.com>
wrote:

> While I usually reserve my time and energy for advancing good ideas, I’m
> making an exception to publicly state the reasons why I believe “
> multiformats <https://github.com/msporny/charter-ietf-multiformats/>”
> should not be considered for standardization by the IETF.
>
> 1. Multiformats institutionalize the failure to make a choice, which is
> the opposite of what good standards do. Good standards make choices about
> representations of data structures resulting in interoperability, since
> every conforming implementation uses the same representation. In contrast,
> multiformats enable different implementations to use a multiplicity of
> different representations for the same data, harming interoperability.
> https://datatracker.ietf.org/doc/html/draft-multiformats-multibase-03#appendix-D.1 defines
> 23 equivalent and non-interoperable representations for the same data!
>
> 2. The stated purpose of “multibase
> <https://www.ietf.org/archive/id/draft-multiformats-multibase-08.html>”
> is “*Unfortunately, it’s not always clear what base encoding is used;
> that’s where this specification comes in. It answers the question: Given
> data ‘d’ encoded into text ‘s’, what base is it encoded with?*”, which is
> wholly unnecessary. Successful standards DEFINE what encoding is used
> where. For instance,
> https://www.rfc-editor.org/rfc/rfc7518.html#section-6.2.1.2 defines that
> “x” is base64url encoded. No guesswork or prefixing is necessary or useful.
>
> 3. Standardization of multiformats would result in unnecessary and
> unhelpful duplication of functionality – especially of key representations.
> The primary use of multiformats is for “publicKeyMultibase” – a
> representation of public keys that are byte arrays. For instance, the only
> use of multiformats by the W3C DID spec <https://www.w3.org/TR/did-core/> is
> for publicKeyMultibase. The IETF already has several perfectly good key
> representations, including X.509, JSON Web Key (JWK), and COSE_Key. There’s
> not a compelling case for another one.
>
> 4. publicKeyMultibase can only represent a subset of the key types used in
> practice. Representing many kinds of keys requires multiple values – for
> instance, RSA keys require both an exponent and a modulus. By comparison,
> the X.509, JWK, and COSE_Key formats are flexible enough to represent all
> kinds of keys. It makes little to no sense to standardize a key format that
> limits implementations to only certain kinds of keys.
>
> 5. The “multihash
> <https://www.ietf.org/archive/id/draft-multiformats-multihash-07.html>”
> specification relies on a non-standard representation of integers called
> “Dwarf”. Indeed, the referenced Dwarf document lists itself as being at
> http://dwarf.freestandards.org/ – a URL that no longer exists!
>
> 6. The “Multihash Identifier Registry” at
> https://www.ietf.org/archive/id/draft-multiformats-multihash-07.html#mh-registry duplicates
> the functionality of the IANA “Named Information Hash Algorithm Registry”
> at
> https://www.iana.org/assignments/named-information/named-information.xhtml#hash-alg,
> in that both assign (different) numeric identifiers for hash functions. If
> multihash goes forward, it should use the existing registry.
>
> 7. It’s concerning that the draft charter
> <https://msporny.github.io/charter-ietf-multiformats/> states that “*Changing
> current Multiformat header assignments in a way that breaks backward
> compatibility with production deployments*” is out of scope. Normally
> IETF working groups are given free reign to make improvements during the
> standardization process.
>
> 8. Finally, as a member of the W3C DID and W3C Verifiable Credentials
> working groups, I will state that it is misleading for the draft charter to
> say that “*The outputs from this Working Group are currently being used
> by … the W3C Verifiable Credentials Working Group, W3C Decentralized
> Identifiers Working Group…*”. The documents produced by these working
> groups intentionally contain no normative references to multiformats or any
> data structures derived from them. Where they are referenced, it is
> explicitly stated that the references are non-normative.
>
>
>
>                                                 -- Mike
>
>
>
> P.S.  This was also posted at https://self-issued.info/?p=2408 and
> https://www.linkedin.com/posts/selfissued_github-mspornycharter-ietf-multiformats-activity-7105001423574077441-6tcS,
> referenced from https://twitter.com/selfissued/status/1699234431293370376,
> and filed as an issue at
> https://github.com/msporny/charter-ietf-multiformats/issues/2.
>
>
>