Re: [Multiformats] Multiformats Considered Harmful

[Melvin Carvalho <[e-mail]>]

st 6. 9. 2023 v 4:03 odesílatel Michael Jones <[e-mail]>
napsal:

> 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.
>

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. The fediverse, a sizable social network
platform, relies heavily on publicKeyPem, with a deployment base exceeding
10 million accounts. Abrupt deprecation of such widely-used standards can
have significant and far-reaching consequences.

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.

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. 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.
https://github.com/w3c/vc-data-integrity/issues/74

[image: image.png]


>
>
>
>                                                 -- 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.
>
>
> --
> Multiformats mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multiformats
>